That is not automation, it is remote control with a delay.
Does that matter?
Only that HA is an automation platform, not a remote control platform.
Interesting, I never thought about those two as all that distinct.
Yeah I am probably being a bit pedantic, but automations are where its at.
Within that, I accept that there is a need sometimes for some people to turn a light or heater or whatever on for a user set but variable amount of time.
I hope that Zigbee network + Zigbee Coordinator backups in the ZHA integration are also part of what Home Assistant founders indirectly thought about in this blog-post about “Streamlining Experiences”, especially now that Home Assistant Yellow hardware will contain a Zigbee Coordinator as standard:
Another thing needing streamlined experience is an official integration for a DIY security alarm system.
manual alarm control panel platform enables you to create an alarm system but it is not simple.
Could be much easier if has an official built-in native integration similar to “Alarmo” custom component:
If motion-activated lights is considered part of intro to home automation 101 then alarm system is 201?
We need a streamlined experience for recorder, history, and statistics. My current database file is 33gigs and I actually want a long history (currently set at 900 day purge) but probably some of it can become statistics.
There is currently no good UX for seeing and controlling MY data. I’d love to see which devices/entities are creating the most data and have control over retention down to the entity level.
Please consider streamlining the recorder/statistics into a new storage configuration screen so I can easily manage MY data.
Well you can control what is recorded down to entity level.
As far as detecting what is creating the most data, the database can be queried using standard sql, but I agree that is not intuitive.
Indeed…I’ve been waiting for the next month of what the heck to post this!
I know it isn’t automation, but it would be super helpful.
Enocean is keeping me from using it for all of my smarthome devices. I switched from homee and hue … zigbee and zwave already running. But enocean is the hell. Worse experience. Fhem and node red way better. And that is sad.
- my Hora SmartDriveMx heater valves not supported
- 10 bit EEP for enocean temp/humidity sensors not supported
- without custom components to emulate at least some of the features I would be lost
Some of the former homee devs would contribute, if pull requests for enocean would be allowed. As of today, the lack of support there is sad. I know there are more urgent topics, but enocean is not that bad for sensors… as the energy harvesting is working pretty well and not changing a battery a good thing.
Automations are too basic in the UI, needs to be improved. Easier handling for light Szenen and motion detectors. Avoid multiple automations (on / off automation) and define it in one automation with on and off condition
Add more graphs and history (as available for the energy management) for temperatures, etc. customizable, comparable. That would help.
Possibility to defrag database. Combine historical data, instead of saving single values per minute, do it as medians of an hour or so. That would reduce the amount of disk space.
These are my thoughts… a lot of potential.
With the focus on moving everything to the UI and trying to make this consumer-friendly HA really needs SAFE defaults, built in cleanup / maintenance functions, etc all exposed in the UI… Also UI ways to do filters etc for Logbook (mostly useless noise unless you filter things in YAML), History Needs more filters views etc right now it is an ugly list of graphs (needs grouping options by type, area etc), Recorder (also needs UI for filter controls and maintenance currently are all YAML)
That is not the focus, where in the first post did it say that?
It is the overall focus of the devs not specific to this month.
There is one, super-missing thing in HA, that would make many user’s lifes easier - easy setup of schedules. I really believe this is the most common automation use cases. The more detailed use cases for this include heating (time range per day, temperature-driven), lights control (time and lux sensor-driven), water sprinklers / valves control (humidity driven). There’s a custom component for this with a quite good UI and UX (Scheduler card/custom component), but would be great to see it integral part of HA.
Of course all of this may be done using HA automation, but in most cases this is awkward from the UI point of view (not easy and intiutive config change, no clear schedule overview UI) and I understand the goal is to make it easy, quick and user friendly.
Sample UIs for this, posted in the Feature Requests section of HA Community, which propose even better UI:
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.
Am I missing something? I thought this was fixed in 2021.8.2.
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.
I use a few new style template sensors in packages and they work fine.