Race Conditions, Execution Order, and other of life's mysteries...

In my never ending quest to add-to and tweak my PLEG based Security & Occupancy system I often run into Race Conditions.

Example: Value1 trigger occurs… Condition1 evaluates correctly, quickly followed by Condition2 executing before all the changes can be made by the first Condition. Thus Condition2 sees Value1 changed - and executes before Value2 can be changed by Condition1

This primarily happens with Occupancy & Alarm… we track Persons home/away then set Occupancy State - which is monitored by the Alarm Logic which changes the Alarm State/Devices

Luckily, this usually does not create a loop but it does cause issues.

btw I use PLEG for the state logic, and to execute native Vera Scenes (where the actual device settings/on/off changes are executed)

Any suggestions on how to easily avoid this problem?


I’m no PLEG expert, but what about the sequence “Value1;Condition1” for Condition2?

I don’t follow how that would be implemented?

How would I tell PLEG to wait for a specific Vera Scene to complete before re-running Condition checks on that PLEG device?

I believe you have a 2 conditions that contain the same trigger. They will be evaluated at the same time based off changes.

The trick will be to serialize the logic.

PLEG or Vera can’t tell if a scenes is finished from another scene unless the last thing you do in the scene is change a variable somewhere. You could use a variable container or PLEG state variables to cycle through your sequence. If it’s a binary state, you could use a virtual switch to keep it simple for testing.

For example, using binary state like a virtual switch:

Condtion1 = Value1 and State
Condtion1 = Value1 and !State

If you need more states than two, you would use:
Value1 and (State eq “MyState1”)

Just make sure the last delay in a scene flips the virtual switch or sets the variable.