This is really disappointing, as is the explanation that it’s “broken by design” and new template sensors can’t be supported using packages. I can understand that a particular design would lead to that problem, but since when was the packages feature not deemed something that has first-class support? Shouldn’t new features like this be designed with the thought that the packages feature exists, has been around for years, and is frequently used by users that have large or complex Home Assistant configurations?
Packages is a feature to allows Home Assistant use to scale out to more complex, larger use-cases. It’s a differentiator that makes the cost-of-ownership lower, even in the face of moving more and more data into opaque persistent state storage. It would seem that packages is something that would naturally go along with blueprints as a means to distribute units of functionality to Home Assistant users, and that it would become more important as time went on, not less.
I just see it as an automation with a timed trigger. Both equally valid as a requirements. I’ve long since stopped looking at HA as simply an automation tool but now see it as a comprehensive home management tool.
You’ve slightly lost the thread. This reply thread was more about you jumping all over someone else’s suggestion simply because it didn’t fit with your definition of HA purpose.
I would love to see an option to group automations. I could see groups for Christmas lighting, Pool automations, Lighting automations, etc. The list grows very quickly and with no ability to group them it gets ugly.
You just made my day. I didn’t realize this happened, fantastic. I have quite a few terrible templates to turn into much cleaner auto-off triggers now lol
I do the same but once you get dozens and dozens of them it gets a bit ugly. It would be nice to have tabs or something to better segregate them. Also, ideally, it would allow you to enable/disable an entire group with a single switch.
Very interesting video. The UI/UX team should definitely take a look at that. This kind of experience feedback is very valuable. At my job, that’s exactly the kind of feedback we, the dev team, love. You have a guy who is a neophyte with HA but at the same time a very technical user. So when he hits a stumbling block, it doesn’t just stop there, he actually explains the reasoning behind why he had problems and what could have prevented him from experiencing the usability issues.
In terms of streamlining things, a few things I’d like to see:
I’d love it if you could rename all the zwave entities of a device when adding it. When I add a zwave device, I usually have to go and change about 6-8 friendly names and another 6-8 device ID’s, and all I’m doing is changing them to the same exact thing with the same suffix that’s already there. Why can’t I just be asked to do this in the UI and have it replace all the names with the name I choose and append the suffix for each of the device ID’s and friendly names? It would save so much time. As it stands, I hate adding zwave devices for this reason.
Please fix the zwave migration tool to zwavejs2mqtt, I really want to use it.
I’d like themes to be able to work for card-mod and also custom:button-card. Most really nice UI’s I see involve quite a bit of customizations of those two things in addition to the theme, and it would be so nice if we could simply install a theme which gave us the full look without often many mandays of tweaking in all the various customizations which are needed.
You can already do this. Rename the device and it will rename the associated entities. BTW, this is how all devices work. Rename the device and it will rename the entities as long as the entities share a common name with the device, which they do after initial setup.
