|
2 | 2 |
|
3 | 3 | All notable changes to this project will be documented in this file. |
4 | 4 |
|
| 5 | +## [2.10.34] - 2026-01-27 |
| 6 | + |
| 7 | +### 🚀 API-based automation & script management + Security fix |
| 8 | + |
| 9 | +**Breaking the file structure barrier: Now works with ALL automations and scripts, regardless of where they live** |
| 10 | + |
| 11 | +#### The Problem We Solved |
| 12 | + |
| 13 | +Previously, the agent could only see and manage automations and scripts that were stored in the traditional `automations.yaml` and `scripts.yaml` files. This created a frustrating limitation for users with mature Home Assistant setups: |
| 14 | + |
| 15 | +- **Users with packages**: If you organized your config using `packages/*.yaml` files (a common practice for larger installations), the agent couldn't see those automations/scripts |
| 16 | +- **UI-created automations**: Automations created through Home Assistant's web interface are stored in `.storage` and were completely invisible to the agent |
| 17 | +- **Mixed setups**: Many users have a mix of file-based and UI-created automations, but the agent could only work with the file-based ones |
| 18 | + |
| 19 | +**Real-world impact**: A user reported having 159 automations in their system, but the agent could only see 4 of them (the ones in `automations.yaml`). The other 155 automations were invisible and unmanageable through the agent. |
| 20 | + |
| 21 | +#### The Solution |
| 22 | + |
| 23 | +We've completely rebuilt how the agent interacts with automations and scripts. Instead of reading and writing YAML files directly, the agent now uses Home Assistant's official WebSocket API (`config/automation/list`, `config/script/list`, etc.). This means: |
| 24 | + |
| 25 | +- ✅ **See everything**: `list_automations` and `list_scripts` now return ALL automations/scripts that Home Assistant knows about, regardless of where they're stored: |
| 26 | + - From `automations.yaml` / `scripts.yaml` (traditional files) |
| 27 | + - From `packages/*.yaml` files (organized configs) |
| 28 | + - Created via UI (stored in `.storage`) |
| 29 | +- ✅ **Get individual items**: You can now fetch a specific automation or script by ID using `get_automation` or `get_script`, without loading entire YAML files |
| 30 | +- ✅ **List IDs only**: Both endpoints support `ids_only=true` parameter to get just a list of IDs without full configurations, saving tokens and context |
| 31 | +- ✅ **Create/update/delete via API**: All write operations now go through Home Assistant's API, so they work regardless of your file structure |
| 32 | +- ✅ **Smart Git versioning**: After each operation, the agent exports the current state of all automations/scripts to Git in `export/automations/<id>.yaml` and `export/scripts/<id>.yaml` format, creating a complete history |
| 33 | +- ✅ **Intelligent rollback**: When rolling back to a previous Git commit, the agent detects exported automations/scripts and applies them via API, ensuring consistent restoration |
| 34 | +- ✅ **Backwards compatible**: Old Git commits (without the export/ structure) still work via file-based rollback, so your existing backups remain functional |
| 35 | + |
| 36 | +**Result**: That user with 159 automations? Now all 159 are visible and manageable. No more file structure limitations. |
| 37 | + |
| 38 | +#### Security Fix (from PR #22) |
| 39 | + |
| 40 | +- ✅ **Secure API key regeneration**: The `/api/regenerate-key` endpoint now requires authentication (valid API key in `Authorization: Bearer <key>` header) to prevent unauthorized key regeneration from arbitrary web pages. Previously, any website could call this endpoint and regenerate your API key without authentication, creating a critical security vulnerability. The UI still works seamlessly by passing the current key in the request header when regenerating keys. |
| 41 | + |
5 | 42 | ## [2.10.33] - 2026-01-27 |
6 | 43 |
|
7 | 44 | ### 🚀 API-based automation & script management + Security fix |
|
0 commit comments