Agent skill
home-assistant-manager
Expert-level Home Assistant configuration management with efficient deployment workflows (git and rapid scp iteration), remote CLI access via SSH and hass-cli, automation verification protocols, log analysis, reload vs restart optimization, and comprehensive Lovelace dashboard management for tablet-optimized UIs. Includes template patterns, card types, debugging strategies, and real-world examples.
Install this agent skill to your Project
npx add-skill https://github.com/aiskillstore/marketplace/tree/main/skills/komal-skynet/home-assistant-manager
SKILL.md
Home Assistant Manager
Expert-level Home Assistant configuration management with efficient workflows, remote CLI access, and verification protocols.
Core Capabilities
- Remote Home Assistant instance management via SSH and hass-cli
- Smart deployment workflows (git-based and rapid iteration)
- Configuration validation and safety checks
- Automation testing and verification
- Log analysis and error detection
- Reload vs restart optimization
- Lovelace dashboard development and optimization
- Template syntax patterns and debugging
- Tablet-optimized UI design
Prerequisites
Before starting, verify the environment has:
- SSH access to Home Assistant instance (
root@homeassistant.local) hass-cliinstalled locally- Environment variables loaded (HASS_SERVER, HASS_TOKEN)
- Git repository connected to HA
/configdirectory - Context7 MCP server with Home Assistant docs (recommended)
Remote Access Patterns
Using hass-cli (Local, via REST API)
All hass-cli commands use environment variables automatically:
# List entities
hass-cli state list
# Get specific state
hass-cli state get sensor.entity_name
# Call services
hass-cli service call automation.reload
hass-cli service call automation.trigger --arguments entity_id=automation.name
Using SSH for HA CLI
# Check configuration validity
ssh root@homeassistant.local "ha core check"
# Restart Home Assistant
ssh root@homeassistant.local "ha core restart"
# View logs
ssh root@homeassistant.local "ha core logs"
# Tail logs with grep
ssh root@homeassistant.local "ha core logs | grep -i error | tail -20"
Deployment Workflows
Standard Git Workflow (Final Changes)
Use for changes you want in version control:
# 1. Make changes locally
# 2. Check validity
ssh root@homeassistant.local "ha core check"
# 3. Commit and push
git add file.yaml
git commit -m "Description"
git push
# 4. CRITICAL: Pull to HA instance
ssh root@homeassistant.local "cd /config && git pull"
# 5. Reload or restart
hass-cli service call automation.reload # if reload sufficient
# OR
ssh root@homeassistant.local "ha core restart" # if restart needed
# 6. Verify
hass-cli state get sensor.new_entity
ssh root@homeassistant.local "ha core logs | grep -i error | tail -20"
Rapid Development Workflow (Testing/Iteration)
Use scp for quick testing before committing:
# 1. Make changes locally
# 2. Quick deploy
scp automations.yaml root@homeassistant.local:/config/
# 3. Reload/restart
hass-cli service call automation.reload
# 4. Test and iterate (repeat 1-3 as needed)
# 5. Once finalized, commit to git
git add automations.yaml
git commit -m "Final tested changes"
git push
When to use scp:
- ๐ Rapid iteration and testing
- ๐ Frequent small adjustments
- ๐งช Experimental changes
- ๐จ UI/Dashboard work
When to use git:
- โ Final tested changes
- ๐ฆ Version control tracking
- ๐ Important configs
- ๐ฅ Changes to document
Reload vs Restart Decision Making
ALWAYS assess if reload is sufficient before requiring a full restart.
Can be reloaded (fast, preferred):
- โ
Automations:
hass-cli service call automation.reload - โ
Scripts:
hass-cli service call script.reload - โ
Scenes:
hass-cli service call scene.reload - โ
Template entities:
hass-cli service call template.reload - โ
Groups:
hass-cli service call group.reload - โ
Themes:
hass-cli service call frontend.reload_themes
Require full restart:
- โ Min/Max sensors and platform-based sensors
- โ New integrations in configuration.yaml
- โ Core configuration changes
- โ MQTT sensor/binary_sensor platforms
Automation Verification Workflow
ALWAYS verify automations after deployment:
Step 1: Deploy
git add automations.yaml && git commit -m "..." && git push
ssh root@homeassistant.local "cd /config && git pull"
Step 2: Check Configuration
ssh root@homeassistant.local "ha core check"
Step 3: Reload
hass-cli service call automation.reload
Step 4: Manually Trigger
hass-cli service call automation.trigger --arguments entity_id=automation.name
Why trigger manually?
- Instant feedback (don't wait for scheduled triggers)
- Verify logic before production
- Catch errors immediately
Step 5: Check Logs
sleep 3
ssh root@homeassistant.local "ha core logs | grep -i 'automation_name' | tail -20"
Success indicators:
Initialized trigger AutomationNameRunning automation actionsExecuting step ...- No ERROR or WARNING messages
Error indicators:
Error executing scriptInvalid data for call_serviceTypeError,Template variable warning
Step 6: Verify Outcome
For notifications:
- Ask user if they received it
- Check logs for mobile_app messages
For device control:
hass-cli state get switch.device_name
For sensors:
hass-cli state get sensor.new_sensor
Step 7: Fix and Re-test if Needed
If errors found:
- Identify root cause from error messages
- Fix the issue
- Re-deploy (steps 1-2)
- Re-verify (steps 3-6)
Dashboard Management
Dashboard Fundamentals
What are Lovelace Dashboards?
- JSON files in
.storage/directory (e.g.,.storage/lovelace.control_center) - UI configuration for Home Assistant frontend
- Optimizable for different devices (mobile, tablet, wall panels)
Critical Understanding:
- Creating dashboard file is NOT enough - must register in
.storage/lovelace_dashboards - Dashboard changes don't require HA restart (just browser refresh)
- Use panel view for full-screen content (maps, cameras)
- Use sections view for organized multi-card layouts
Dashboard Development Workflow
Rapid Iteration with scp (Recommended for dashboards):
# 1. Make changes locally
vim .storage/lovelace.control_center
# 2. Deploy immediately (no git commit yet)
scp .storage/lovelace.control_center root@homeassistant.local:/config/.storage/
# 3. Refresh browser (Ctrl+F5 or Cmd+Shift+R)
# No HA restart needed!
# 4. Iterate: Repeat 1-3 until perfect
# 5. Commit when stable
git add .storage/lovelace.control_center
git commit -m "Update dashboard layout"
git push
ssh root@homeassistant.local "cd /config && git pull"
Why scp for dashboards:
- Instant feedback (no HA restart)
- Iterate quickly on visual changes
- Commit only stable versions
Creating New Dashboard
Complete workflow:
# Step 1: Create dashboard file
cp .storage/lovelace.my_home .storage/lovelace.new_dashboard
# Step 2: Register in lovelace_dashboards
# Edit .storage/lovelace_dashboards to add:
{
"id": "new_dashboard",
"show_in_sidebar": true,
"icon": "mdi:tablet-dashboard",
"title": "New Dashboard",
"require_admin": false,
"mode": "storage",
"url_path": "new-dashboard"
}
# Step 3: Deploy both files
scp .storage/lovelace.new_dashboard root@homeassistant.local:/config/.storage/
scp .storage/lovelace_dashboards root@homeassistant.local:/config/.storage/
# Step 4: Restart HA (required for registry changes)
ssh root@homeassistant.local "ha core restart"
sleep 30
# Step 5: Verify appears in sidebar
Update .gitignore to track:
# Exclude .storage/ by default
.storage/
# Include dashboard files
!.storage/lovelace.new_dashboard
!.storage/lovelace_dashboards
View Types Decision Matrix
Use Panel View when:
- Displaying full-screen map (vacuum, cameras)
- Single large card needs full width
- Want zero margins/padding
- Minimize scrolling
Use Sections View when:
- Organizing multiple cards
- Need responsive grid layout
- Building multi-section dashboards
Layout Example:
// Panel view - full width, no margins
{
"type": "panel",
"title": "Vacuum Map",
"path": "map",
"cards": [
{
"type": "custom:xiaomi-vacuum-map-card",
"entity": "vacuum.dusty"
}
]
}
// Sections view - organized, has ~10% margins
{
"type": "sections",
"title": "Home",
"sections": [
{
"type": "grid",
"cards": [...]
}
]
}
Card Types Quick Reference
Mushroom Cards (Modern, Touch-Optimized):
{
"type": "custom:mushroom-light-card",
"entity": "light.living_room",
"use_light_color": true,
"show_brightness_control": true,
"collapsible_controls": true,
"fill_container": true
}
- Best for tablets and touch screens
- Animated, colorful icons
- Built-in slider controls
Mushroom Template Card (Dynamic Content):
{
"type": "custom:mushroom-template-card",
"primary": "All Doors",
"secondary": "{% set sensors = ['binary_sensor.front_door'] %}\n{% set open = sensors | select('is_state', 'on') | list | length %}\n{{ open }} / {{ sensors | length }} open",
"icon": "mdi:door",
"icon_color": "{% if open > 0 %}red{% else %}green{% endif %}"
}
- Use Jinja2 templates for dynamic content
- Color-code status with icon_color
- Multi-line templates use
\nin JSON
Tile Card (Built-in, Modern):
{
"type": "tile",
"entity": "climate.thermostat",
"features": [
{"type": "climate-hvac-modes", "hvac_modes": ["heat", "cool", "fan_only", "off"]},
{"type": "target-temperature"}
]
}
- No custom cards required
- Built-in features for controls
Common Template Patterns
Counting Open Doors:
{% set door_sensors = [
'binary_sensor.front_door',
'binary_sensor.back_door'
] %}
{% set open = door_sensors | select('is_state', 'on') | list | length %}
{{ open }} / {{ door_sensors | length }} open
Color-Coded Days Until:
{% set days = state_attr('sensor.bin_collection', 'daysTo') | int %}
{% if days <= 1 %}red
{% elif days <= 3 %}amber
{% elif days <= 7 %}yellow
{% else %}grey
{% endif %}
Conditional Display:
{% set bins = [] %}
{% if days and days | int <= 7 %}
{% set bins = bins + ['Recycling'] %}
{% endif %}
{% if bins %}This week: {{ bins | join(', ') }}{% else %}None this week{% endif %}
IMPORTANT: Always use | int or | float to avoid type errors when comparing
Tablet Optimization
Screen-specific layouts:
- 11-inch tablets: 3-4 columns
- Touch targets: minimum 44x44px
- Minimize scrolling: Use panel view for full-screen
- Visual feedback: Color-coded status (red/green/amber)
Grid Layout for Tablets:
{
"type": "grid",
"columns": 3,
"square": false,
"cards": [
{"type": "custom:mushroom-light-card", "entity": "light.living_room"},
{"type": "custom:mushroom-light-card", "entity": "light.bedroom"}
]
}
Common Dashboard Pitfalls
Problem 1: Dashboard Not in Sidebar
- Cause: File created but not registered
- Fix: Add to
.storage/lovelace_dashboardsand restart HA
Problem 2: "Configuration Error" in Card
- Cause: Custom card not installed, wrong syntax, template error
- Fix:
- Check HACS for card installation
- Check browser console (F12) for details
- Test templates in Developer Tools โ Template
Problem 3: Auto-Entities Fails
- Cause:
card_paramnot supported by card type - Fix: Use cards that accept
entitiesparameter:- โ
Works:
entities,vertical-stack,horizontal-stack - โ Doesn't work:
grid,glance(without specific syntax)
- โ
Works:
Problem 4: Vacuum Map Has Margins/Scrolling
- Cause: Using sections view (has margins)
- Fix: Use panel view for full-width, no scrolling
Problem 5: Template Type Errors
- Error:
TypeError: '<' not supported between instances of 'str' and 'int' - Fix: Use type filters:
states('sensor.days') | int < 7
Dashboard Debugging
1. Browser Console (F12):
- Check for red errors when loading dashboard
- Common: "Custom element doesn't exist" โ Card not installed
2. Validate JSON Syntax:
python3 -m json.tool .storage/lovelace.control_center > /dev/null
3. Test Templates:
Home Assistant โ Developer Tools โ Template
Paste template to test before adding to dashboard
4. Verify Entities:
hass-cli state get binary_sensor.front_door
5. Clear Browser Cache:
- Hard refresh: Ctrl+F5 or Cmd+Shift+R
- Try incognito window
Real-World Examples
Quick Controls Dashboard Section
{
"type": "grid",
"title": "Quick Controls",
"cards": [
{
"type": "custom:mushroom-template-card",
"primary": "All Doors",
"secondary": "{% set doors = ['binary_sensor.front_door', 'binary_sensor.back_door'] %}\n{% set open = doors | select('is_state', 'on') | list | length %}\n{{ open }} / {{ doors | length }} open",
"icon": "mdi:door",
"icon_color": "{% if open > 0 %}red{% else %}green{% endif %}"
},
{
"type": "tile",
"entity": "climate.thermostat",
"features": [
{"type": "climate-hvac-modes", "hvac_modes": ["heat", "cool", "fan_only", "off"]},
{"type": "target-temperature"}
]
}
]
}
Individual Light Cards (Touch-Friendly)
{
"type": "grid",
"title": "Lights",
"columns": 3,
"cards": [
{
"type": "custom:mushroom-light-card",
"entity": "light.office_studio",
"name": "Office",
"use_light_color": true,
"show_brightness_control": true,
"collapsible_controls": true
}
]
}
Full-Screen Vacuum Map
{
"type": "panel",
"title": "Vacuum",
"path": "vacuum-map",
"cards": [
{
"type": "custom:xiaomi-vacuum-map-card",
"vacuum_platform": "Tasshack/dreame-vacuum",
"entity": "vacuum.dusty"
}
]
}
Common Commands Quick Reference
# Configuration
ssh root@homeassistant.local "ha core check"
ssh root@homeassistant.local "ha core restart"
# Logs
ssh root@homeassistant.local "ha core logs | tail -50"
ssh root@homeassistant.local "ha core logs | grep -i error | tail -20"
# State/Services
hass-cli state list
hass-cli state get entity.name
hass-cli service call automation.reload
hass-cli service call automation.trigger --arguments entity_id=automation.name
# Deployment
git add . && git commit -m "..." && git push
ssh root@homeassistant.local "cd /config && git pull"
scp file.yaml root@homeassistant.local:/config/
# Dashboard deployment
scp .storage/lovelace.my_dashboard root@homeassistant.local:/config/.storage/
python3 -m json.tool .storage/lovelace.my_dashboard > /dev/null # Validate JSON
# Quick test cycle
scp automations.yaml root@homeassistant.local:/config/
hass-cli service call automation.reload
hass-cli service call automation.trigger --arguments entity_id=automation.name
ssh root@homeassistant.local "ha core logs | grep -i 'automation' | tail -10"
Best Practices Summary
- Always check configuration before restart:
ha core check - Prefer reload over restart when possible
- Test automations manually after deployment
- Check logs for errors after every change
- Use scp for rapid iteration, git for final changes
- Verify outcomes - don't assume it worked
- Use Context7 for current documentation
- Test templates in Dev Tools before adding to dashboards
- Validate JSON syntax before deploying dashboards
- Test on actual device for tablet dashboards
- Color-code status for visual feedback (red/green/amber)
- Commit only stable versions - test with scp first
Workflow Decision Tree
Configuration Change Needed
โโ Is this final/tested?
โ โโ YES โ Use git workflow
โ โโ NO โ Use scp workflow
โโ Check configuration valid
โโ Deploy (git pull or scp)
โโ Needs restart?
โ โโ YES โ ha core restart
โ โโ NO โ Use appropriate reload
โโ Verify in logs
โโ Test outcome
Dashboard Change Needed
โโ Make changes locally
โโ Deploy via scp for testing
โโ Refresh browser (Ctrl+F5)
โโ Test on target device
โโ Iterate until perfect
โโ Commit to git when stable
This skill encapsulates efficient Home Assistant management workflows developed through iterative optimization and real-world dashboard development. Apply these patterns to any Home Assistant instance for reliable, fast, and safe configuration management.
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
perigon-backend
Perigon ASP.NET Core + EF Core + Aspire conventions
perigon-agent
Pointers for Copilot/agents to apply Perigon conventions
perigon-angular
Angular 21+ standalone/Material/signal conventions for Perigon WebApp
fastapi-mastery
Comprehensive FastAPI development skill covering REST API creation, routing, request/response handling, validation, authentication, database integration, middleware, and deployment. Use when working with FastAPI projects, building APIs, implementing CRUD operations, setting up authentication/authorization, integrating databases (SQL/NoSQL), adding middleware, handling WebSockets, or deploying FastAPI applications. Triggered by requests involving .py files with FastAPI code, API endpoint creation, Pydantic models, or FastAPI-specific features.
context7-efficient
Token-efficient library documentation fetcher using Context7 MCP with 86.8% token savings through intelligent shell pipeline filtering. Fetches code examples, API references, and best practices for JavaScript, Python, Go, Rust, and other libraries. Use when users ask about library documentation, need code examples, want API usage patterns, are learning a new framework, need syntax reference, or troubleshooting with library-specific information. Triggers include questions like "Show me React hooks", "How do I use Prisma", "What's the Next.js routing syntax", or any request for library/framework documentation.
browser-use
Browser automation using Playwright MCP. Navigate websites, fill forms, click elements, take screenshots, and extract data. Use when tasks require web browsing, form submission, web scraping, UI testing, or any browser interaction.
Didn't find tool you were looking for?