Multiple Trigger Expressions not behaving the same way in UI7 as UI5

Plugins & Plugin Development Program Logic (PLEG)
#1

I have a trigger and condition that behaves differently on UI7 than it did on UI5, and the upshot is that right now I can’t replicate the same functionality.

The trigger is an Occupancy Sensor that sends a motion trigger roughly every 30 seconds, and then stops with no motion. PLEG causes one set of overhead lights to come on with the initial motion, and then off after two minutes of no motion (actually the trigger itself has 130 second timeout which is controlled by a variable on the parent device, the EnOcean plug-in)

The advantage of 30 second additional motion even with some overhead lighting already on is that I can use a Multiple Trigger counter to determine if there is a lot of on-going motion (person using the sink to get ready) and then turn on the sink lights. Lots of activity, bright incandescent lights - but someone just occasionally passing thru, just use overhead florescents.

IN UI5, the additional positive triggers of the Occupancy Sensor - meaning even though the device is already triggered in the GUI, the additional triggers caused PLEG to update and re-evaluate logic - and hence the Multiple Trigger Expression condition would update and the action fire. In UI7, however, PLEG seems to only be listening for tripped and un-tripped - not additional trips of a device already tripped.

I attached the status, as well as the Event Watcher data showing the Occupancy Sensor physical device is sending the trigger messages to Vera as expected, but for some reason they are not processed all the way to PLEG.

The trigger is ThirdFloorBathroomRightSinkOccupancy, and the associated condition that will not evaluate to true is ThirdFloorBathroomNeedsSinkLightsOn. I added in a new condition specific to the Multiple Trigger Expression to isolate it, and that is ThirdFloorBathroomBusy, which is simply “ThirdFloorBathroomRightSinkOccupancy @ 3 < 00:02:00”. Per the below, that should have turned true at 11:31am, but it did not.

41	2018-01-09, 11:30:03.350	S	58	3rd Bath Right Occ	Tripped	1	
44	2018-01-09, 11:30:33.526	S	58	3rd Bath Right Occ	Tripped	1	
47	2018-01-09, 11:31:00.021	S	58	3rd Bath Right Occ	Tripped	1	
51	2018-01-09, 11:31:26.580	S	58	3rd Bath Right Occ	Tripped	1	
56	2018-01-09, 11:31:53.169	S	58	3rd Bath Right Occ	Tripped	1	
59	2018-01-09, 11:32:19.760	S	58	3rd Bath Right Occ	Tripped	1	
62	2018-01-09, 11:32:46.323	S	58	3rd Bath Right Occ	Tripped	1	
63	2018-01-09, 11:33:13.185	S	58	3rd Bath Right Occ	Tripped	1	
76	2018-01-09, 11:34:26.325	S	58	3rd Bath Right Occ	Tripped	1	
89	2018-01-09, 11:36:37.116	S	58	3rd Bath Right Occ	Tripped	0

UI7 1.7.3454, PLEG 8.11, PLC 8.21
UI5 1.5.622, PLEG 7.47, PLC 7.48

#2

Because these are send only/one-way Occupancy Sensors, they are working concurrently on both my UI5 and UI7 Veras. So here is the same status from my UI5, showing the later trigger timestamp. Note how a different multiple trigger condition based on the same sensor, ThirdFloorBathroomHumanEvent, is true in one system and not the other.

#3

Developed a work-around. Added an input on the “LastTriped” device property. It gets updated with each subsequent trip of the sensor. (“LastTrip” device property gets updated as well, but also updates on the state change to untripped.)

ThirdFloorShowerOccupancyLastTripped 3rd Shower Occupy[59] LastTriped[urn:micasaverde-com:serviceId:SecuritySensor1

So “ThirdFloorBathroomRightSinkOccupancyLastTripped @ 3 < 00:02:00” works as expected.

Only real downside is this might force an additional evaluation of the PLEG when the sensor first trips - once for the change from untripped to tripped, and then again for the change to the LastTriped device property…

#4

Strange - those conditions containing one of these sensors and which are set to Repeat are firing the action on subsequent triggers.

So it SEEMS as if the only issue is the Multiple Trigger Expressions (@ <> hh:mm:ss). Richard, could that mean there was a change in PLEG such that Multiple Triggers now only store a new timestamp when changing from tripped to untripped?

#5

Would setting the “repeats” option on the conditions solve this?

#6

The problem, as far as I can tel, is specific to triggers. There would likely be a work-around you could build - create a condition with just the trigger expression and enable repeats. Then refer to the condition in the “@ 3 < 02:00” instead of the trigger itself. This might be better than my work-around as it might not force an extra evaluation of the PLEG.

#7

Did you enter the trigger on UI7 ?
Vera changed trigger definitions for some device types in UI7 … so they do not behave the same. Just recreate the trigger definition.

Sent from my SAMSUNG-SM-G935A using Tapatalk

#8

[quote=“RichardTSchaefer, post:7, topic:198235”]Did you enter the trigger on UI7 ?
Vera changed trigger definitions for some device types in UI7 … so they do not behave the same. Just recreate the trigger definition.[/quote]

Yes, manually (cut-and-paste) recreated all of my PLEGs in UI7 from status reports from UI5. Deleting and recreating the triggers do not change functionality.

I can make a work-around permanent, but I want to warn users - a Multiple Trigger Expression on a device trigger (device trigger @ # <> hh:mm:ss) in current UI7 firmware does not seem to reference the last # of trips of the sensor within the hh:mm:ss timeframe - but instead the last # of changes of state (untripped to tripped) of the sensor within the hh:mm:ss timeframe.

#9

You can control this by setting the repeats …
Repeats ON – Last # of Trips reported ON
Repeats OFF — Last # of transitions to On

#10

[quote=“RichardTSchaefer, post:9, topic:198235”]You can control this by setting the repeats …
Repeats ON – Last # of Trips reported ON
Repeats OFF — Last # of transitions to On[/quote]

Repeats setting for “Device Triggers”? The Device Trigger definition section does not have a Repeats option. Only “Conditions (Automation Logic)” has such an option.