@Ha20 If I understand you right, you want an option included for devices to select if they should be remanent or not? (like used in Industrial PLC setups)
I love that idea! 
2 Likes
They do but my point was that volunteers are major contributors to the project (especially for documentation which is what your bullet points focused on).
Even well before the formation of Nabu Casa, the âroadmapâ has always been controlled by Paulus and a small group of trusted volunteer developers. Many of those original volunteers are now employees of Nabu Casa.
Youâve made useful suggestions for improving the documentation. You can wait for someone else (paid employee or volunteer) to eventually implement them or you can submit them as PRs to the docs repo where theyâre likely to be well received and merged into the official documentation.
@Domoticon you are right.
Looking for an opinion that automations are always completely run and finished.
So even after on a reboot, temporary instability of a system or power failure. Not depending on a âHelper device â timers with more automations users must create.
Users should trust on the system when a device needs to switch off after 5 minutes. Thatâs my goal case.
1 Like
Too many edge cases to cater for. What if you need to take your HA system down for a long time, perhaps for a hardware update?
At least with the current setup, you know how itâs going to behave. The more âsmartsâ you try to give it to compensate for unknown reboot / downtime situations, the more complex and unpredictable itâd get.
To make this proposal / request work, someone would need to come up with a firm ruleset for how it should operate.
1 Like
@Ha20 Hear, hear!
Just a small explanation about remanent, what is used by PLC setups. When enabled the last value/state is stored and when not updated, it will ârememberâ that value/state, even when offline or (re)booted.
Maybe simmilar like MQTT Retained messages.
EDIT: BTW, I use Virtual MQTT device/entities, added to HA, to get simmilar managed as you mentioned in your first topic-post.
That wouldnât help an automation with timers that was running and then the system was rebooted.
There would need to be a global state machine for devices (which they have) and then a global state machine for automations and timers. Then you need bulletproof logic to handle every complex case. Which will require creating a new system of doing things and people will need to learn how to use that system effectively, aka reading, implementing, troubleshooting, etc.
Sounds pretty straightforward for the ops use case, but what about the millions of others? Thatâs why, in some cases, itâs up to the user to implement these things themselves, so they have complete control over what happens.
As an example, how does one learn about programming PLCs and the intricacies? Do you download a free OSS software and configure it using the GUI without reading any docs whatsoever? Or did it take learning, reading, implementing, troubleshooting, etc. ?