Thanks! I think that has cracked it, and more importantly, i have a much better understanding of where i went wrong. Thanks again!
Me Again! 
I had a Vera crash at 5am this morning. This would have been the time my hot water and heating comes on.
As such (i assume as a direct result), neither have run today.
My PLEG conditions have not changed sin the last post and they have been working great all week, but today they just failed to run. I am assuming because of the crash at 5am to the time stamp never occurred so the condition is not longer true. So ever time the criteria is evaluated now, HeatOnMorning is false as is HotWMorning.
Can you confirm if that is correct if you get a moment, and if so, is there anything I can do that would help with crashes?:
The only thing i have been playing with is another PLEG instance for setting my cameras to arm or disarm based on who’s phones are pingable.
I have deleted this instance now as maybe my logic on this caused the issue to make LuaUPNP crash?
Log is her: http://pastebin.com/QGtupRfJ
It looks as though PLEG 185 had turned on your heating at 05:00 as expected but was delayed in updating its database by PLEG 199 triggers firing. So when recovering from the crash, its database shows that Weekly5 was last true at 0500 on March 1st. It is now after 05:00 on the 2nd so Weekly5 will not fire until 05:00 on the third. The HeatOnMorning condition will also not fire at the next Periodic because it is now more than 4 hours since the last time Weekly5 was true (according to its database).
I don’t know whether it is just coincidence but you had a lot of stuff happening at 05:00 and it was not a great time for Luup to crash.
I’m not certain, but I think my technique of re-sending the last SetModeTarget to the relay might have kept the heating on for you. Sorry but I don’t intend to deliberately crash my system in the wee-small-hours to find out.
How to prevent it happening again? It might be worth separating key trigger schedules by a minute or two to ensure each PLEG gets time to complete its evaluations and database update before the next one grabs the CPU’s attention.
I suppose you could add a backup schedule and logic that runs a few minutes after the main one to catch a similar situation. Trying to navigate around possible crash scenarios is likely to cause Murphy’s law to fire, though. PLxx already does a pretty good job of saving and restoring its states but this crash hit at just the wrong moment.
If you use conditions like:
FiveAM = 00:00:00; NOW > 5:00:00
Then it would fire EVEN if you restart at the same time as an ABSOLUTE timer would trigger.
But it does not have a conditional day behaivior.
I will look into to the timer initialization. I can detect if the last occurrence did not fire because of a Vera restart.
I had the same problem when I bought and installed as a compete noob to all things Vera. What a headache for a total novice that was.
What i understand is that if the boiler control is not fed a control message within 30 minutes it goes into fail safe mode and shuts off. Regardless of the zwave network and if you have two relays, ie heat and water they both need a “keep alive” signal. What i done was have a regular 20min schedule that reads the state of the boiler relay and then vera repeats that back to the boiler device to maintain the current state and keep the system alive to avoid fail safe timeout conditions.
I have the luup code somewhere and can paste it here if you like?
Hope it helps you quicker than it took me.
[quote=“RexBeckett, post:9, topic:174358”]@andyvirus
You’ve probably got this all bolted down now but it may help others. I decided to add the refresh logic to my system (belt, suspenders and a length of string… ;D). Simple is good so I went with the following additions to my existing heating control logic:
Inputs Schedule
I30M: Interval, 30 minutes
Inputs Device Properties
HWRelayMode: Hot Water Relay, Mode Target
Conditions
HWRelayPulse: I30M
Actions
HWRelayPulse: Hot Water Relay, NewModeTarget {(HWRelayMode)}
All it does is resend the last set mode (Off or Heat) every 30 minutes. As long as the HWRelayPulse condition expression is below any condition that changes the state of Hot Water Relay, it should not interfere with existing logic.[/quote]
Hi RexBecket,
I excluded and re-included the relay and now I can see the mode in TargetMode. So now i want to do the above but how are you doing the above Action? Are you doing that in Advanced?
Attached is a screenshot of what i have done (substitute HeatMode for you HWRelayMode). Is this how you achieved it?
Resending the last sent mode will be ok unless the device has had its state changed locally, in which case re-transmitting the last “sent” state may conflict with what has been manually selected. Just a thought as I this was my first solution. At least by transmitting/repeating the current state of the device it will be as true “keep alive” signal
Yes you define the action in the advanced tab. Select the relay device, then SetModeTarget and put the {( … )} expression in the final field. Your screenshot looks fine.
I don’t find this a problem. If I want to change the relay state manually, I do it through Vera. This causes the PLxx to update the Device Property so it will be resent correctly until the logic calls for a change of state - or I switch it manually again.