Condition not firing sine PLEG update to 5.6 and 5.7

Since the update to PLEG 5.6 and now 5.7 i have noticed one condition not firing. It took me a while to pin it down, but i think i found the problem in the condition. I am not sure if i am just not seeing something. But before the update(s) it worked fine, and i have not changed anything. On the other hand since the update i have yet to have a schedule missing the off time, or an action not firing, so not sure if it is me not seeing a problem.

This is (in short) the problem

Porchopen Porchdooropen false 2014-01-28 22:05:18.442 2014-01-28 22:05:37.983
Junmute (Porchopen and Justhome) or NopingJ false 2014-01-28 15:33:38.451 2014-01-28 22:05:37.985
Munmute (Porchopen and Mikehome) or NopingM false 2014-01-28 22:05:18.447 2014-01-28 22:05:37.987

In my opinion Junmute should have gone true at the same time as Munmute (it used to)

In case it is needed i have attached the full status report.

And i still have not managed to get my usb logging working so i have a normal log but without PLEG debugging enabled…
The error is reproducable though, as most of the time the porch door is opened Munmute is true and my iphonelocator unmuted, while my wifes isnt.

I thought i just enable PLEG debugging and open the door to catch the error… obviously this time the condition fired…

Porchopen Porchdooropen false 2014-01-28 22:25:17.608 2014-01-28 22:25:22.146
Junmute (Porchopen and Justhome) or NopingJ false 2014-01-28 22:25:17.614 2014-01-28 22:25:22.148
Munmute (Porchopen and Mikehome) or NopingM false 2014-01-28 22:25:17.621 2014-01-28 22:25:22.151

I kept trying opening the door… now i’ve caught one on the log…

Porchopen Porchdooropen false 2014-01-28 22:37:47.874 2014-01-28 22:37:51.029
Junmute (Porchopen and Justhome) or NopingJ true 2014-01-28 22:37:47.883 2014-01-28 22:33:45.466
Munmute (Porchopen and Mikehome) or NopingM false 2014-01-28 22:33:41.726 2014-01-28 22:37:51.055

this time it is Munmute which should have been true at the same time as Junmute ?

Whichever condition stopped firing, simply rename it with an underscore in front of it. Ex: _ConditionName

Let us know happens…

-TC

Look carefully at your status report.

If the condition is already true … and you continue to get triggers … they will not fire … In that case you WANT to be able to trigger when already true.
In that case rename your condition with an underscore as the first character.

There were bugs pre-5.6 that set conditions to false in-appropriately. So when the trigger came again … it would seem to transition from false to true.
If fixed the bugs … and now you are seeing your dependence on this bug.