Best way to do State Enforcement?

Configuration
, ,
1

Hey all! One of the things I constantly strive for in my setup is to have everything Just Work, even though my setup is, uh, slightly more complex than “WiFi bulb”.

--------------------------

The two main issues that bug me (which thankfully only happen occasionally) are when:

  1. A device needs to react once to a changing state and it does not respond the first try. E.g blink an LED when something starts, turn something on when you walk in.

I fixed this one using a reusable script which accepts a list of entities and then repeats the action every X seconds up to X repeats or until the state matches the desired state.

  1. A device needs to be on when X=true. For example, consider a light that needs to be on from 17:00-22:00. But at 17:00, HA is restarting, Zigbee socket:// is offline, or the device is busy, or a power outage, etc.

This is the one currently stumping me. Of course, I can write it all out in my periodic checks automation using if statements that loop in parallel, but that sounds like mild torture for me.

--------------------------

The ideal implementation IMO is a state editor which allows you to say something like when x=y, make foo=bar. Of course, it would be very, very nice to have this natively, but there are more pressing things in HA development.

So I wanted to ask all of you folks: has anyone found a good way to do this either natively or in a custom app? If not, I might try to use AI to develop my own app so I can program easily and actually see visually what is set up to happen, but I wanted to ask first.

Thanks in advance!

2

There are three primary components to be considered:

  • Sensors
  • HA iIself
  • Outputs

Sensors

If HA never receives an update from a sensor (dead battery or communication issue) state enforcement won’t help you, since you can only really do state enforcement for HA and outputs.

In most cases I just double up sensors, that doesn’t mean I place 2 in every location, instead I use sensors who’s physical location is close, so I might use a door opening and a presence sensor to turn on a hallway light.

Sure lights might come on unnecessarily, but it also has the advantage you don’t walk into a dark room - typically the light comes on before you get there.

HA Itself

Frankly, I don’t have enough issues with HA being down to really worry about it.

If something absolutely had to be on or off in a given time range I would add multiple triggers to the automation for example every 30 minutes, heck if it was that critical I would probably use dedicated hardware to do it (I haven’t needed to look into it, but it must exist).

Outputs

Every time that I have had issues, its been a hardware issue.

Specifically there is nothing I can do from HA, I have to:

  • Power cycle the device.
  • Change a battery.
  • Let something cool off.
  • Replace hardware with either another similar item or find a different manufacture.

Other than those cases Zigbee has its own retry mechanism, so I might have a “slow” bulb that occasionally takes 3 seconds to come on (it was retried automatically by Zigbee).

Again you can mitigate this with redundancy - add addition “accent” lights or turn on lights close to the room in question, again the goal is so your not completely in the dark if something goes wrong.

If it was the only bulb in the room the hardware would get replaced after the first offense, if its in a cluster I typically don’t notice.

Q1

This seems to be a hardware issue, you shouldn’t need to repeat commands - at least it should be so rare that is not worth the effort.

Q2

It may be worth playing with “bulky” automation specifically:

  • Take a bunch of automations and combine them into one.
  • Throw all the triggers conditions in, but don’t do anything with them.
  • Instead you interrogate the state in the body of the automation and decide what to do.

I do this for all motion activated lights, if any motion sensor fires all lights get “updated” that doesn’t mean all lights are turned on, it means all lights get corrected even if a different sensor triggers.

3

Basically same as David I’ve never had an issue of this class that wasn’t solvable by tracing root cause and fixing that (usually misconfiguration or hw fail) and prefer to put my time and energy into that as opposed to workarounds.

4

I share similar sentiments. Back when I was learning to program (as a hobby), I often came across the advice that a well-written program continues to function correctly even when unexpected things happen. I view HA as a program with many plugins - i.e., the program concept extends to the entire house controlled by HA. And the fact that it is generally based on the assumption that things just work (e.g. there’s no “exception block” for scripts) makes me a bit uncomfortable :slight_smile:

Having said all that, I must agree with the views expressed by the previous speakers.
Setting aside technical difficulties, it is not really feasible to enforce rigid states, because an unforeseen situation might require the state to be different on a particular day. So in a situation like that, having an independent subroutine monitoring the states, you would also have to fight that thing.

In these more critical cases, I usually do two things to (somewhat) safeguard against HA shutdowns and failed actions:

  • checking the status after HA starts up
  • a notification to my phone stating that “it failed to…”
  • if one or two failures aren’t yet a problem, I save the number of unsuccessful attempts and report it, for example, after the third one in a row.