I have had a lot of instability as of late and Vera support said the deadlocks are being caused by PLEG. I have 2 PLEG devices none of which are huge but do have some complex conditions. I am not very good at reading the Vera logs but was hoping someone here could help guide me as to what to look for in determining what is actually causing the deadlocks.
One of my PLEGS sole purpose is to control the lights in my house via motion. I have several motion sensors in each area of the house and some lights get triggered by more than one sensor. What I suspect is happening is as I walk through an area and trip 3 sensors the condition is coming true 3 times very quickly. In my logic the condition only comes true if the light is off but I may be tripping more than one sensor before the light has a chance to report as on.
My other PLEG does just a few miscellaneous things but one of which is controlling my thermostats. The logic on this is somewhat complex taking into consideration the temperature from multiple sensors around my house and the reported external temperature. Every time these temperatures change by even 1/10th of a degree the condition would be reevaluated.
So I suspect one of these one of those are causing the issues but as I said I am not very good at reading the logs. It would be helpful if someone could post some sample log entries of conditions becoming true and actions firing.
I just got a new file for one of the PLEG .js files from support that supposedly fixes the saving issue. I was going to wait to hear from Richard on this before giving it a whirl.
I had removed all my PLEG devices (have backups) to see if that helped system stability since I couldn’t save changes. I still see a ton of crashes, but no crashes while I’m driving the GUI… So definitely other issues in play.
PLEG will not deadlock … but if you are sending actions to a device faster than they can be processed by the target device, the target device my have a queue overflow.
Most devices can only have a couple (that’s 2) commands outstanding.
If you have multiple triggers causing evaluations in a very short period of time, and each sends commands to the same device … that can cause Vera to think it has a deadlock.
There is NOT an .js file that will fix an overflow. The over flow is detected on the Vera itself. A .js files is run in the browser as part of the UI.
Please send me what they sent you … they have not contacted me.
Thanks Richard. I understood that a queue backup was a potential cause but after your explanation I am positive I am on the right track. I am going to rethink my logic and redo the motion lights.
If you have updated your plugins … you already have the latest copy (Released in Sept 2015)
MCV support just sent one file from that release, maybe because the file was corrupted on their machine.
I am the definitive source for the PLEG/PLTS/PLC software. And the versions in the APP store are the latest versions.
On occasion I released a single file as a HOT-FIX to a serious bug I did not catch during testing.
I had to release a single-file for those people that were on a frozen version of UI7, yet they updated the PLEG/PLTS/PLC software that had a UI7-Version specific change in it.
I am pretty sure that certain conditions are firing rapidly because I have a light set to turn on based on multiple sensors being triggered. The condition currently looks like this
TurnOnKitchenLights !KitchenLightsOn and (MotionSensor1 or MotionSensor2 or MotionSensor3 or MotionSensor4)
There are several way to approach the kitchen and I want the lights to turn on as you approach not once you are in the room. It’s a somewhat open concept so sometimes you are tripping more than one of those sensors as you walk which is causing the condition to become true multiple times very quickly. One of my ideas is to add logic to the condition that references itself but I am not sure if that will just cause more issues or not. Here is what I am thinking
TurnOnKitchenLights !KitchenLightsON and TurnOnKitchenLights>30 and (MotionSensor1 or MotionSensor2 or MotionSensor3 or MotionSensor4)
So if the last time stamp for the condition coming true would have to of been more than 30 seconds ago for it to fire again. So I am not sure my expression is exactly correct and I am not sure if you are allowed to reference a condition name within it’s own logic.
So I use a PLEG structure I call “confirmative” that eliminated my deadlocks. I essentially built them so no two conditions could fire at the same time as the other conditions are checked (confirmed in my mind) to make sure they are not currently true.
So instead of a condition referencing itself like you suggested, I reference the other conditions in that PLEG. You mentioned a TurnOnKitchenLights. If you also had one called TurnOnKitchenFan, then TurnOnKitchenLights might need to be:
!KitchenLightsOn and (MotionSensor1 or MotionSensor2 or MotionSensor3 or MotionSensor4) and NOT TurnOnKitchenFan.
They have to be conditions that turn false once they execute (as your TurnOnKitchenLights is), and obviously you don’t want too many conditions in a PLEG, or they get cumbersome. I wait to find those that conflict and cause a deadlock, and then add in the logic so they can’t trigger at the same time…
I believe the queue issue is per PLEG instance, not across all PLEG instances - it was in my testing, and hence smaller PLEGs, each with “confirmative” logic so as it can’t be triggering multiple z-wave calls at the same time, works great for me.
[quote=“KewlRobD, post:1, topic:191491”]I have had a lot of instability as of late and Vera support said the deadlocks are being caused by PLEG. I have 2 PLEG devices none of which are huge but do have some complex conditions. I am not very good at reading the Vera logs but was hoping someone here could help guide me as to what to look for in determining what is actually causing the deadlocks.
One of my PLEGS sole purpose is to control the lights in my house via motion. I have several motion sensors in each area of the house and some lights get triggered by more than one sensor. What I suspect is happening is as I walk through an area and trip 3 sensors the condition is coming true 3 times very quickly. In my logic the condition only comes true if the light is off but I may be tripping more than one sensor before the light has a chance to report as on.
My other PLEG does just a few miscellaneous things but one of which is controlling my thermostats. The logic on this is somewhat complex taking into consideration the temperature from multiple sensors around my house and the reported external temperature. Every time these temperatures change by even 1/10th of a degree the condition would be reevaluated.
So I suspect one of these one of those are causing the issues but as I said I am not very good at reading the logs. It would be helpful if someone could post some sample log entries of conditions becoming true and actions firing. [/quote]
According to Richard’s statement there is no queue issue with PLEG. The queue issue is when you send multiple commands to a single device. So in my example if I trip 3 of the sensors before the light has a chance to report as on then the condition becomes rapidly becomes true 3 times thus sending the action to the light 3 times and causing the deadlock. Based on what your saying if I had 4 conditions and each referenced MotionSensor1 when I tripped that motion sensor and the 4 conditions become true then we will see a deadlock. I think that disagrees with what Richard said.
[quote=“RichardTSchaefer, post:3, topic:191491”]PLEG will not deadlock … but if you are sending actions to a device faster than they can be processed by the target device, the target device my have a queue overflow.
Most devices can only have a couple (that’s 2) commands outstanding.
If you have multiple triggers causing evaluations in a very short period of time, and each sends commands to the same device … that can cause Vera to think it has a deadlock.
There is NOT an .js file that will fix an overflow. The over flow is detected on the Vera itself. A .js files is run in the browser as part of the UI.
Please send me what they sent you … they have not contacted me.[/quote]
Not exactly what I am saying. Multiple triggers can become true but the condition would only become true once, and then false once its action was completed.
The queue issue is in z-wave not PLEG, but I am convinced it is tjat the same device (PLEG instance) can’t queue more than 2-3 z-wave calls, not that there can’t be that many queued across multiple PLEG instances.
Based on your example I don’t think the issue is multiple calls from a PLEG to a single device, but a call from a PLEG to multiple devices. Maybe a status report and the lua upnp log 30 seconds before the deadlock would let us diagnose. I am now stuck in Jury Duty on my cell, so no help the rest of today…
[quote=“RichardTSchaefer, post:14, topic:191491”]A better approach to multiple relatively concurrent triggers is:
MotionInputForLight1 (Motion1 or Motion2 or … MotionN) (Repeats enabled)
CommandForLight1 (MotionInputForLight1 @ 2 > 5) and … The rest of the logic
This will only allow an event once every 5 second.[/quote]
Thanks. I will give that a try if I ever get my Vera to start sating again. It’s pretty bad at the moment and I can’t get changes to stick.
In regards to that I was tailing my logs while making the edits. When I entered the device I see that error I previously posted. I would make my changes and then let things sit for 5 to 10 minutes before reloading the LUUP in hopes of having the changes stick. I would notice the LUUP restarting on it’s own before I would get a chance to do it myself. Afterwords my changes would be gone. According to Vera Support these restarts are because of deadlocks caused by PLEG but I currently have all my PLEG devices set to bypass to avoid the deadlocks. So this kind of goes against my theory of multiple actions causing the deadlocks. I now want to prove or disprove that disprove that PLEG is the culprit so I made a backup and then uninstalled PLEG. So far I have not seen a LUUP restart in 20 minutes. Somehow PLEG is causing the restarts but it’s nothing to do with conditions or actions since they have been turned off all day.
The saving problem is independent of any potential deadlock problem and you are correct, setting your PLEGs to bypass will eliminate ANY chance of a deadlock, since it disables ALL actions.
I do believe the Vera has a Saving problem.
But it does not effect everyone, and it does not effect just PLEG, but clearly PLEG seems to help to trigger the problem.
There should be NOTHING short of running out of memory that should keep Vera from saving the changes.
And some people are seeing this on a Plus that has lots of memory.
This is like one of the most important parts of the system, and needs to work even when other parts are failing, i.e. they need to save state just before they restart for ANY reason!
The fact that Vera has extensive diagnostics in the log files when it attempts to save the changes indicates they know they have a problem, but have not been able to identify/resolve it.
These diagnostics are NOT in UI5, and UI5 was rock solid as far as saving changes.
I had no restarts for an hour after uninstalling PLEG so I restored my backup and realized I was mistaken there was one PLEG Device armed. It is a very small configuration but very complex. It controls my HVAC system using multiple temp sensors inside and out. These sensors report down to the tenth of a degree so changes in temp are frequent. I am now thinking my logic is bad and every change is firing an action. I bypassed that for a bit to see if the restarts cease and if they do I will then enable it and see if they begin again. If they do I will have to analyze my logic a bit.
[quote=“RichardTSchaefer, post:14, topic:191491”]A better approach to multiple relatively concurrent triggers is:
MotionInputForLight1 (Motion1 or Motion2 or … MotionN) (Repeats enabled)
CommandForLight1 (MotionInputForLight1 @ 2 > 5) and … The rest of the logic
This will only allow an event once every 5 second.[/quote]
I am still pretty much a newb with Pleg so can you explain to me what the MotionINputForLight1 @ 2 > 5 does? Based on the Pleg basics document a similar example, SoundSiren MotionDetector @ 3 < 5:00, becomes true if MotionDetector becomes true three times in a five minute period. So we are counting the MotionINputForLight1 as twice in more than 5 minute? I am having trouble wraping my head around this.
I start a five minute timer after I make a similar change, and don’t allow the condition to become true again until the timer expires. In my case for a ceiling fan and a thermostat. That way I adjust the fan speed no more often than once every five minutes…
Here is an example of one of my confirmative PLEGs - that is every condition that has a z-wave call for an action, and which is also expected to fire frequently, is also making sure another similar condition isn’t already true and hence already making a z-wave call…