I’ve got 2 heat pumps, they heat the house and hot water based on thermostat, sensor and Octopus energy target sensors. It works nicely most of the time.
But - if something reboots, like the router, or the power goes out for a short while (I live in the sticks, so short 90-second power outs are reasonably regular). for example, then the “state” of something hasnt changed, but the fail safe of the zigbee switches it off on power up.
Last night, we had a very short power interrupt, so the Heat pumps zigbee switches defaulted to off. but becasue the demand from the Tado thermostat remained at 100 percent (The thermostat is on a small UPS), the logic that turns on the heat pumps never got refreshed, and so the heat pumps remained off. Woke up cold!
I am thinking of setting a 5 minute recurring timer, and using this as a sort of polling trigger to refresh the logic selection, but it doesnt feel like an elegant answer - or is it?
One thought I have is that this would be actually simpler to enact in logic terms, as it would simply do something on the timed trigger and entity state, rather than managing the state changes in both directions (and between each state)…
I understand - and this is what I initially thought.
The catch is, this wasnt a ha restart - this was a minor power out that wasnt noticed by HA. The switched entity simply turned off - there was no sign of problem otherwise.
Normal control system theory (in automotive / aerospace etc) is to act on the “monitor” of the item being controlled, and to act on that monitor not matching the intended control input.
In my case, the state machine thought it was in one state, but it wasnt.
I suppose I could look for the state change of the driven entity that doesnt match the expected state. While this would cover the issue, its a lot more complex than is needed.
One of my Zigbee 4 way switching units just failed.
Switch (and feedback) said “on” - but output wasnt.
Grrrrrr…
On the plus side - thanks to all who contribute here. We love to complain about when things go wrong, but not enough do we compliment the great work done here, and the fabulous thing that HA is thanks to this work.
Was the state of the switched entity properly reflected in HA? If it wasn’t, then there is a hardware issue that needs resolving. If it was: Use that as an additional trigger for your automation.
To make robust automations, it requires a little extra thinking as to all the things that should trigger the logic to be executed again. Yes, many people just resort to a time pattern trigger because they don’t know how, or don’t want to, think through the steps. But that isn’t the right way to do it. Think about it this way: HA knows the state of everything, and it knows exactly when everything changes. Why have it poll itself on some time-based interval when you can instead have it react immediately when the relevant thing(s) changed?
In your case, the switched entity changed and you didn’t want it to. So monitor the state of that entity as a trigger for your automation. Using the HA startup is a trigger that should also be commonly used, since automation triggers aren’t “armed” until the startup process is nearly complete, and also because the entities could have changed during shutdown.
Simple example: if you want a light to be on when a door is open, no matter what, (and don’t control the state when the door is closed) then you should have the following triggers:
state of light changes to off
HA starts up
door opens
And the following conditions:
door is open
light is off
And the following action:
turn light on
That is a bit more involved than what most people would do (they’d trigger only on the door opening, with no conditions, and use the same action). But robustness, if it is important, requires more thought.
Have an automation (or a trigger in your current automation) where the switch is off and a condition that the thermostat is on/heating.
Action turn on switch.
This is the automation that will catch this fault.
One thing you should consider is that the switch may need to be off for x seconds to make sure it doesn’t become turn on when the thermostat says off because of timing issues with the states.
I’ve been looking at that - the catch is this:-
The entities are sometimes set by a script - in order to time valves and pumps.
And - there are two heat pumps, an immersion heater and three valves.
So I cant simply run the “turn the light on if it was off” logic, as there are timers and conflicting possible states I want to check.
I originally set a timed refresh of the automations, every minute as a work-around,
I’ve been rearranging and making this a lot sleeker, as I add in the selection of heat source based on electricity price.
i’ve tidied it up a lot, but it’s still a bit of a puzzle.
That is the correct way to do it: When you want to execute an action only when multiple things are simultaneously true, you add each one as separate triggers and also add them all as conditions. Any time one becomes true, the automation will check to see if they are all true.
Triggers are OR by default. Conditions are AND by default.
You don’t need to add that logic.
Edit: to expand on that: triggers are instantaneous moments in time, like the firing of the starting pistol in a race. It is not realistic for two triggers to occur simultaneously.
We do need the “and” conditional logic if we also have a “turn the light off” automation, and want to confirm that the light is actually coming on/off properly.
This is the trap we end up in:-
We open the door, and the light is turned on.
We close the door, so the light is turned off.
But - since the “on” automation is triggered by the light being turned off, it gets turned on, and since the “off” automation is triggered byt he light being turned on, it turns the light off - repeatedly…
This is a weird problem I have with the heating controls - but it’s a niggly little one.
I’m not following you. The automation as I specified it is correct. It will not turn the light back on. Yes the trigger fires when the light is turned off, but there is a condition (door must be open) the prevents the actions from running. The light will not turn on & off repeatedly if you create a similar “turn off” automation. (Though, I would personally put it all in one automation and put the conditions in a choose: block in the actions, but that is personal preference.)
To restate what I said previously: Every condition is AND by default. Each condition must evaluate to true in order for the automation to continue. The only reason the “AND” logic block even exists is so that it can be used when it is nested inside an OR block. A very specific use case.
And for triggers, you won’t even find any logic blocks available in the triggers section, because it wouldn’t make any sense.
I think we are sort of agreeing, but in different ways of explaining it.
The Triggers use OR logic.
So the light being turned off will trigger the automation that turns on the light regardless of the state of the door - unless you have “door open” both as a trigger and a condition.
I correct my earlier post - you only need “door open” as a condition as well as a trigger.
In terms of the example, I have to both make sure that the desired light remains off when the door is closed, and on when the door is open.
So I trigger on a change of state for the door and the light, but with the state of the door as a condition.
This way, if the light ever ends up in the wrong state, then the logic will catch it and correct it.
I’ll look at “Choose”, and have a play - thank you. I’m very new to this, and while im doing really well, do stub my toe on a few oddities like this.
The responses and feedback are really welcome - thank you.