How do you get that from this?
It appears that the rule is running twice. But it's hard to tell because you didn't have events and triggers enabled for logging.
Maybe you do have that enabled. It was triggered in the middle two lines you just showed, which has nothing to do with the delay on the bottom line.
It was triggered twice within 2 seconds. 12:51.414 and 12:53.590
Oh good point, the rule running twice confused me.
Are you able to shed light on why it is running twice despite the Private boolean logic being included which should prevent that?
Not really, although it appears to be timing related, as it hasn't written out state (along with PB) by the 240 msecs later that it is tested again.
First trigger is from Night Mode, and second trigger is from Day_Max_Temp changing. Get rid of double triggers, and your problems would go away. This is just odd logic structure. You've got some other rule doing something at the same time that is setting mode to Night, or responding to that mode change, and hitting that variable, so you're just clobbering yourself. Reorganize ...
3 Likes
Done, I'll see how that goes.
I'll re-test the other rule (Rule 2 in OP) that was failing (the manually triggered one) and see if that is still behaving.
And it is, which is puzzling as it was consistently failing previously. 
So I ditched the double setpoint sends and had failures again - I'm wondering if it's a Zigbee contention issue (I have 2 Zen Thermostats + a Sensibo) ? I've added a 2-second in-line delay into the start of the rule for the Upstairs thermostat so the rules aren't trying to send Zigbee commands at the same time (assuming that is the issue).
I'm still having issues with these 2x Zen thermostats not responding fully to a single mode & setpoint command. So I've replaced the batteries with Duracell Ultra's just to rule them out - I might switch to Energizer Lithium's if I can find them at the supermarket.
All the delay failures seem to have vanished tho, so that's good.
