Hello. I am new to Home Assistant (HA), but not so new to Home Automation (H/auto).
I am intending to migrate all my disparate systems (Veras with PLEG, Domoticz, various proprietary cloud etc.) under the one glorious HA local umbrella and binning off the other ‘brains’. So far, I’ve migrated a few devices of various types that the wife doesn’t use or notice and am trying to get to grips with the HA ways of defining, scripting, automation etc.
I have some very definite implementation requirements which have come about through being burnt several times with H/auto. To try and give a flavour of this, I always have additional fields that contain the date/time of last on, last off and last change of a boolean as standalone fields that survive reboots of the state engine. I insist on having multiple sensors and actuators for security critical elements to provided redundancy. I also never have a button/switch directly control an actuator. A button/switch or other input will adjust a ‘request’ or ‘desired’ state which then gets processed through the system to affect other aspects of the system according to schedules and other inputs. Caretaker automations compare the desired state(s) with actual state(s) to action change. With a typical device MTBF of 100,000 hours and having around 160 devices I have come to expect device failure every month, so the system needs to survive these failures and allow for easy replacement of the affected parts without bringing the whole system down. My initial playing with HA suggests that HA seems naturally more resilient to this, but still…
To put this into context, I’ll discuss my garage door.
The garage door is a sectional door with standard momentary NO contacts to make it operate in the opposite direction to last time or stop if it is currently moving. The actual end stop positions of the door are managed and self-calibrated by the door without recourse to H/Auto. I have 3 tilt sensors on the door (bottom, upper middle and top sections). The change of state of one of these tilt sensors gives an indication of the position and direction of the door. Under normal circumstances, the 3 sensors will all open and close in sequence – of the 8 possible combinations of these sensors, 4 are valid and 4 are invalid. With the addition of last change open and close times it is easy to identify which sensor(s) may be failing to operate and communicate effectively to report on their replacement but also to continue to operate the whole system in a degraded state.
I have 2 relays to cause the momentary close action to invoke the door movement. Each open/close action is directed to the least recently used relay. Should no movement be detected in the garage door after a preset time, the other relay can be invoked to get the door moving and the failing relay reported.
Occasionally the garage door actual state may deviate from the expected state due to safety cut-out or inputs from outside of the H/auto system.
Using the above allows my garage caretaker automation to ensure that, to the best of its ability, it has commanded and confirmed that the garage door is in the state it should be.
Gone are the days of an automated midnight “shut the door if it is still open” type rule accidentally opening an already closed door, leaving garage contents unsecured through the night… yes that used to happen before I upgraded my thinking.
All this, I know, will be overkill to many and I don’t attempt to convince anyone to my way of thinking.
However, given that this is how I roll, I do ask for recommendations how to make this in HA as efficient and reliable as possible. The sheer power and flexibility of HA is causing me some confusions over the best way to go about this. With other less capable systems, there is only one way.
For example, in the same way one can set a global customisation
homeassistant:
customize_glob:
binary_sensor.*_door_sensor_any:
device_class: door
is it also possible to define date/time helpers for last_on, last_change and last_off rather than having to define them all manually? The more standardised everything is, the less opportunity for typos to cause hard-to-diagnose problems.
Template sensors could be used to define the last_on and last_off via an SQL command. A template sensor for last_change could either be SQL or based on the last_on and last_off. These template sensors have many of the attributes of mini automations but without cluttering up the automations or script sections of the UI. However, is there any technical difference between these two routes – either in performance or, say, atomicity? And it would be great if the format of the definition of these template sensors meant that adding a new door sensor, for example, and after necessary re-load(s), automatically created these helpers rather than having to manually copy and paste some boiler plate code, again, just like the device_class override above means the new devices get the correct door icon automatically.
The nature of the 3 tilt sensors on the garage door would suggest that I would have a single automation to manage the sensing of the position, direction and validity of these sensors which would be totally independent of the door operation automation that manages firing of the relays which would also be separate from the caretaker automation that ensures that the current state of the door matches the current desired state. In that case, it would be possible to have a single automation that is triggered on the change of any of the 3 tilt sensors and within that automation set the state of the helpers. Whilst a local variable could contain now().timestamp() which is applied to the individual helpers to ensure that they had the same millisecond value, it does not guarantee that another script using their value is correct – there will be a finite period of time that the first helper to be updated will have the new value before the second helper is updated. If a further automation was monitoring 2 of these helpers, it would, presumably, cause 2 triggers of that automation when in reality a single trigger would be sufficient. Do template sensors provide any protection in this area? Ie. does a template sensor defined from input sensors obtain its value prior to any normal automation triggers being considered?
Also, if it is possible to define a standard set of last change helpers then it would seem more appropriate to manage those in their own automation or config that is separate from the garage door sensing automation (in this Using a single automation for multiple devices - #10 by anon43302295 ) type of arrangement to update one entity from a different trigger entity, for example.
I’m sorry that this is a long rambling post and am concerned that I still haven’t got across a full flavour of my dilemma(s)… but hopefully it triggers some interesting discussion.
In short, I’m wondering what the best way of going about creating a suite of additional variables for each sensor, switch, light, etc. which automatically hold the correct value without having to paste loads of code each time a new device is added to the system and without causing race conditions and cooking the CPU with many unnecessary invocations of automations.