'Save matching device' - odd behaviour on subsequent executions

⚙️ Custom Apps and Drivers webCore
1

So, I have a simple 'alarm' piston for my 'garden office' that I'm trying to improve, but it's giving a strange output when it runs twice in a short period of time.

When it is initially triggered by the first event (either a door opening or a motion sensor detection) - I get a message naming the matching device. When another sensor then detects further movement, or a different door opens, I get a message with 'EMPTY DEVICE LIST' vs the expected triggering device.

Logs below.

Suggestions? Thanks in advance.

image
image1178×750 42.1 KB

logs

6/18/2024, 2:49:19 PM +907ms
+3ms ╔Received event [New Front Door].contact = open with a delay of 27ms, canQueue: true, calledMyself: false
+110ms ║Runtime (8682 bytes) initialized 107 LockT > 0ms > r9T > 1ms > pistonT > 0ms (first state access 101 m:5 4 103) (v0.3.114.20240115_HE)
+112ms ║╔Execution stage started
+118ms ║║Comparison (enum) :db51cd17b1529242205547665623a183: is (string) :db51cd17b1529242205547665623a183: = true (2ms)
+119ms ║║Condition #4 evaluated true (4ms)
+121ms ║║Condition group #1 evaluated true (condition did not change) (6ms)
+130ms ║║Comparison (enum) open changes_to (string) open = true (0ms)
+131ms ║║Comparison changes_to = false (event device/attr eXcluded)
+135ms ║║Condition #2 evaluated true (13ms)
+146ms ║║Comparison changes_to = false (event device/attr eXcluded)
+147ms ║║Comparison changes_to = false (event device/attr eXcluded)
+151ms ║║Condition #3 evaluated false (16ms)
+153ms ║║Condition group #1 evaluated true (condition did not change) (31ms)
+163ms ║║Calculating (string)Ahem. My apologies for disturbing you. The alarm has been triggered by the + (string)Empty device list >> (string)Ahem. My apologies for disturbing you. The alarm has been triggered by the Empty device list
+166ms ║║Executed virtual command executePiston (7ms)
+173ms ║║Calculating (string)Empty device list + (string) at >> (string)Empty device list at
+175ms ║║Calculating (string)Empty device list at + (string)14:49 >> (string)Empty device list at 14:49
+179ms ║║Empty device list at 14:49
+182ms ║║Executed virtual command log (3ms)
+189ms ║╚Execution stage complete. (77ms)
+195ms ╚Event processed successfully (192ms)

6/18/2024, 2:49:00 PM +719ms
+3ms ╔Received event [Office Motion].motion/physical = active with a delay of 34ms, canQueue: true, calledMyself: false
+24ms ║Runtime (8568 bytes) initialized 19 LockT > 1ms > r9T > 2ms > pistonT > 0ms (first state access 13 m:3 4 15) (v0.3.114.20240115_HE)
+26ms ║╔Execution stage started
+34ms ║║Comparison (enum) :db51cd17b1529242205547665623a183: is (string) :db51cd17b1529242205547665623a183: = true (2ms)
+35ms ║║Condition #4 evaluated true (5ms)
+37ms ║║Condition group #1 evaluated true (condition changed) (7ms)
+43ms ║║Comparison changes_to = false (event device/attr eXcluded)
+44ms ║║Comparison changes_to = false (event device/attr eXcluded)
+47ms ║║Condition #2 evaluated false (8ms)
+52ms ║║Comparison changes_to = false (event device/attr eXcluded)
+54ms ║║Comparison (enum) active changes_to (string) active = true (0ms)
+58ms ║║Condition #3 evaluated true (10ms)
+59ms ║║Condition group #1 evaluated true (condition did not change) (21ms)
+69ms ║║Calculating (string)Ahem. My apologies for disturbing you. The alarm has been triggered by the + (string)Office Motion >> (string)Ahem. My apologies for disturbing you. The alarm has been triggered by the Office Motion
+73ms ║║Executed virtual command executePiston (8ms)
+80ms ║║Calculating (string)Office Motion + (string) at >> (string)Office Motion at
+82ms ║║Calculating (string)Office Motion at + (string)14:49 >> (string)Office Motion at 14:49
+86ms ║║Office Motion at 14:49
+90ms ║║Executed virtual command log (3ms)
+97ms ║╚Execution stage complete. (71ms)
+104ms ╚Event processed successfully (101ms)

2

Just from a quick look…
You need to set the value of message in the piston, rather than in the declarations. With it set in the declarations, it will include the value of the device variable when the piston started, so this will probably be the device from the previous execution or on first execution null.
Variables given values in the declarations act more like constants.

1 Like
3

I thought you had it there - but no :frowning:

I changed to setting the message variable just before i call the messaging/pushover subroutine in the body of the piston, but same result. First message, correct triggering device, 2nd message 'Empty device list'.

Curiously, I let in run on, and subsequent (ie 3rd. 4th) triggers by the motion sensor give a correct message.

Hmmm.

4

I haven't played much with this in a while, but if I remembered correctly, I had two device variables, triggeredMotion and triggeredContact. In the final message I combine those two into something like.. "Blah blah blah, the alarm has been triggered by {triggeredMotion + triggeredContact}" then reset the device variables at the end of the piston.

1 Like
5

Can you post the latest piston and the log?

6

Your point (which is what I have in other pistons) got me to thinking. I had a play with some variations - and here's what's interesting - the device type in the 2nd IF , is the device that reports correctly. I swapped the order of the motion and the contact, and when motion is first, then contact opening gives a correct message, while a motion event reports as Empty Device list.

It's as though the 2nd IF 'save matching devices' over-writes the first IF 'save matching devices' with empty string.

I can fix by having a more generic message and using two variables to save to.

Who's the best to flag this to as a potential bug - or confirm this is by design

Sd.

7

@nh.schottfam maybe can help you figure it out more. Full logs would be needed though.

8

I’m not sure how it would cause the issue you have, but…
Once you have a trigger on a device, the whole piston will run from top to bottom. All statements will be executed, unless blocked by a condition. So for example if you check for a contact opening, the piston will also run when the contact closes.
so
if door changes to open
code runs when door opens
end-if
code runs when door opens or closes

9

I would try using separate variables, or separate if statements.

Basically, doing matches disables condition optimizations, so all are evaluated., thus last one wins...

1 Like