My UI5 Vera3 frequently restarts when two or more PLEG actions (z-wave jobs) trigger at the same time. I had a previous thread on it here [url=http://forum.micasaverde.com/index.php/topic,30874.0.html]http://forum.micasaverde.com/index.php/topic,30874.0.html[/url] And while I am not sure it is really a PLEG problem - more of a z-wave message queuing issue, I think robust PLEGs are likely the main way that such message queues would stack up.
Just as background, the z-wave network is dense, with approximately 40 devices. Most of the 40 are GE/Jasco light switches, along with 4 Leviton fan controllers, 3 Honeywell thermostats, 3 Intermatic outlets, and one GE/Jasco plug-in outlet. The only battery power devices are two Yale deadbolts. I did the antenna mod with 3db L-Com antenna, and most devices talk directly to Vera. For the most part polling happens without issue - there are only occasional "x"s in the auto-routes. The triggers for the PLEG actions are generally either DSC alarm devices (motion/doors) using the DSC plug-in, or EnOcean Occupancy Sensors using the EnOcean plug-in.
Maybe I could use the “LastConditionChange” attribute of PLEG devices to slow down/space out PLEG actions?
I can definitely try that, but I don’t think I am seeing problems between my PLEGs - My Climate and Security PLEGs don’t trigger z-wave actions that often. Now they do start timers a lot.
I think the issues are within the lighting PLEG. So multiple triggers in the same PLEG…
I am warming up to putting them all into one PLEG. During the last two crashes, while only one PLEG (lighting) was sending z-wave commands, two of them (lighting and climate) would have been trying to start timers at exactly the same due to a common trigger…
Combining the PLEGs did not resolve the stability issues, but I do think it helped some. I also re-located Vera, and made about a dozen other changes, and restarts are less frequent. Still a work in progress.
Vera Technical Support just doesn’t understand what we are doing with PLEG. I disabled their remote access and asked them to close my ticket - honestly they have been zero help, despite being in my system a dozen times…
Well, proving what others have said - Vera Technical Support is top-rate. Instead of closing my ticket, they (apparently) escalated, and a new guy e-mailed me he thinks the problem is the processor is maxing out and triggering an over-heat fail-safe. Apparently the fail safe is to restart… I have re-enabled their access to check further…
I am pulling my hair out trying to get the z-wave restarts under control.
Richard, what do you think about me creating a self-retrigger timer “ZWaveCoolDown” with a two second interval, and have every single z-wave action start that timer, and add to every single condition “and NOT ZWaveCoolDown”? Meaning while I can’t space out z-wave actions directly, in theory I could make it such that conditions are effectively spaced out two seconds apart…
Implementing “ZWaveCoolDown” was much harder than expected. Since every condition has to respect it, that means conditions which previously remained true until complete now turn false after the cooling down period, so conditions had to be updated so they didn’t try to repeat after the two seconds (the conditions reference their own previous timestamp)…
And while there is some positive impact, as actions and z-wave commands get queued better and that makes the log easier to read, it has not brought the system stability desired. Some conditions are just too hard to make sure they are the only one that will trigger on a given evaluation cycle. The possibility of repeating conditions caused a lot of restarts, and while that is now eliminated, it means there are situations where a light or outlet might get stuck on or off indefinitely if a restart happens during execution.
But the real problem is that even with slowing down z-wave commands to just one every three seconds or so, deadlocks still happen several times a day. Upon occasion, a single active z-wave command can deadlock. I am extremely frustrated.
Any more thought about making a PLEG option to confirm a job (or jobs) were complete from the previous evaluation cycle before starting another? I don’t think there is a good way to build a flow-control process into the existing PLEG framework like I was trying to do with ZWaveCoolDown… At least not if you have as many automations as I do…
So I thought up another way to get PLEG to wait until one z-wave job is finished before it starts the next one. It is ugly. You just check to make sure no other condition (ones that start z-wave jobs anyhow) is true. You can’t use the “edit” button any more as the conditions are too long for the edit box (at least in Chrome)…
So for example if you want to turn the stairs light on, it is just a simple condition for “Stairs2ndto3rdNeedsLightsOn”
Occupancy2ndto3rd and !Lights2ndto3rdOn and IsNight and (NOT Lights2ndto3rdManualOperation or
(NOT Lights2ndto3rdManual1H and (Lights2ndto3rdManualOperation; Lights2ndto3rdManual1H))) and
NOT QuietTime and NOT AlarmArmedAway and NOT BackYardNeedsLightsOn and NOT
BackYardNeedsLightsOff and NOT LRNeedsLampOn and NOT LRNeedsLampOff and NOT
Stairs1stto2ndNeedsLightsOnDay and NOT Stairs1stto2ndNeedsLightsOnNight and NOT
Stairs1stto2ndNeedsLightsOff and NOT GarageNeedsLightOn and NOT GarageNeedsLightOff and NOT
OfficeNeedsFanLightsOn and NOT OfficeNeedsFanLightsOff and NOT BedroomClosetNeedsLightsOn
and NOT BedroomClosetNeedsLightsOff and NOT BedroomNeedsFanLightsOn and NOT
BedroomNeedsFanLightsOff and NOT KitchenNeedsCabinetsLightsOn and NOT
KitchenNeedsCabinetsLightsOff and NOT FirstFloorBathroomNeedsSinkLightsOn and NOT
FirstFloorBathroomNeedsSinkLightsOff and NOT FirstFloorBathroomNeedsFanOn and NOT
FirstFloorBathroomNeedsFanOff and NOT SecondFloorBathroomNeedsLightsOn and NOT
SecondFloorBathroomNeedsSinkLightsOff and NOT SecondFloorBathroomNeedsFanOn and NOT
SecondFloorBathroomNeedsFanOff and NOT ThirdFloorWaterClosetNeedsLightOn and NOT
ThirdFloorWaterClosetNeedsLightOff and NOT ThirdFloorWaterClosetNeedsFanOn and NOT
ThirdFloorWaterClosetNeedsFanOff and NOT ThirdFloorBathroomNeedsCamLightsOn and NOT
ThirdFloorBathroomNeedsCamLightsOff and NOT KitchenNeedsSinkLightOn and NOT
KitchenNeedsSinkLightOff and NOT LaundryRoomNeedsLightOn and NOT
LaundryRoomNeedsLightOff and NOT ThirdFloorBathroomNeedsSinkLightsOff
I hate this, but it did seem to reduce the restarts… And unfortunately did slow down overall performance a noticeable amount…
I was never serious about the convoluted condition above, it was just for test, but it DID lead to my “ah ha” moment - when it slowed the entire PLEG down.
You CAN build a PLEG with so many conditions that is slows your VERA down to the point it will cause restarts. I am not talking about bad logic causing looping -just trying to automate a whole house with numerous devices on a single PLEG with good logic can cause so much overhead on that PLEG that is regularly crashes.
So while this combining the PLEGS did serialize the z-wave commands:
I also made the system less reliable. The right answer was to break down the lighting PLEG into multiple PLEGs, not to combine the PLEGs and make things even worse…
Now you may be asking why I think that is - best I can tell the problem isn’t sending too many z-wave commands at one time - it is sending too many on the same thread. When they back up on a single thread deadlocks occur - when they back up on multiple threads they queue and complete…
Have you tried making Vera scenes and calling them from the PLEG? I have only one PLEG with about 30 conditions, 4-5 of them are complex. However, each condition only has one action … calling a standard Vera scene. I configured my PLEGs this way because I noticed that the actions would complete faster from the standard Vera scene rather than actions in the PLEG itself.
Have you tried making Vera scenes and calling them from the PLEG? I have only one PLEG with about 30 conditions, 4-5 of them are complex. However, each condition only has one action … calling a standard Vera scene. I configured my PLEGs this way because I noticed that the actions would complete faster from the standard Vera scene rather than actions in the PLEG itself.[/quote]
I did try that, and I didn’t see a change in response or stability. Breaking up the PLEG into smaller PLEGs, however, did dramatically improve the speed of actions…