createEventDevice is not what I expect


#1

1) Give a description of the problem
I want to know which lock has a low battery but when I log currenteventdevice, it lists the name of my hub, not either of the locks

2) What is the expected behaviour?
one of the names of the two lock devices that triggered the event should be printed

3) What is happening/not happening?
the name of the hub ‘home’ is printed.

**4) Post a Green Snapshot of the piston

5) Attach logs after turning logging level to Full
4/19/2020, 7:36:47 AM +593ms
+1ms ╔Received event [Home].test = 1587307007593 with a delay of 0ms
+92ms ║RunTime Analysis CS > 18ms > PS > 52ms > PE > 21ms > CE
+94ms ║Runtime (37688 bytes) successfully initialized in 52ms (v0.3.110.20191009) (92ms)
+95ms ║╔Execution stage started
+114ms ║║Comparison (integer) 30 is_less_than (integer) 50 = true (2ms)
+116ms ║║Condition #2 evaluated true (16ms)
+117ms ║║Condition group #1 evaluated true (state did not change) (18ms)
+120ms ║║Cancelling statement #3’s schedules…
+127ms ║║Calculating (string) Home + (string) is low battery >> (string) Home is low battery
+131ms ║║Home is low battery
+132ms ║║Executed virtual command log (2ms)
+134ms ║╚Execution stage complete. (39ms)
+136ms ╚Event processed successfully (136ms)


#2

neither contact sensor is named ‘home’. they are named “dining room lock” and “front door lock”


#3

My educated guess is that by you pressing Test, the $currentEventDevice is the hub. Perhaps just wait awhile for one of the battery levels to change… Then, the piston should run normally.


#4

Your logs show that you pressed the ‘Test’ button in webCoRE, so the event that fired the piston was generated by webCoRE and came from your Location.

If you want to use $currentEventDevice you need to wait for an actual battery event from the locks.

However you might just want to delve into the settings of your condition and save the matching device(s) to a device variable and use that instead.