Piston triggers on both switch and level change instead of only switch

#1

1) Give a description of the problem
The piston should only get triggered when it is turned on, however it appears to get triggered even upon manual dimmer level change. In other words, I turn on the light and it goes to 99% because it is daytime. When I try to dim it back down it fights me and keeps trying to go back up to 99%.

2) What is the expected behavior?
When I turn on the light, the dimmer goes to the low or high dim preset level depending on the time of day. If I then opt to decrease or increase the dimmer level, it should leave my change.

3) What is happening/not happening?
The trigger seems to fire when I am simply changing dimmer level. My intent was for it to fire only when it goes from OFF to ON.

4) Post a Green Snapshot of the pistonimage

Night%20Dimming%20Piston
Night Dimming Piston.png1178Ă—1259 145 KB

5) Attach any logs (From ST IDE and by turning logging level to Full)

4/11/2019, 6:36:33 AM +535ms
+1ms â•”Received event [Master Bathroom Light].switch = on with a delay of 111ms
+116ms â•‘RunTime Analysis CS > 13ms > PS > 47ms > PE > 55ms > CE
+119ms â•‘Runtime (46395 bytes) successfully initialized in 47ms (v0.3.10a.20190223) (116ms)
+120ms â•‘â•”Execution stage started
+134ms â•‘â•‘Comparison (enum) on is (string) on = true (2ms)
+136ms â•‘â•‘Condition #20 evaluated true (12ms)
+137ms â•‘â•‘Condition group #null evaluated true (state did not change) (13ms)
+180ms â•‘â•‘Comparison (enum) on changes_to (string) on = true (0ms)
+183ms â•‘â•‘Cancelling condition #3's schedules...
+184ms â•‘â•‘Condition #3 evaluated true (44ms)
+185ms â•‘â•‘Cancelling condition #1's schedules...
+187ms â•‘â•‘Condition group #1 evaluated true (state changed) (46ms)
+198ms â•‘â•‘Comparison (dynamic) Master Bathroom Light is_equal_to (dynamic) Upstairs Bathroom Light = false (1ms)
+200ms â•‘â•‘Condition #27 evaluated false (9ms)
+201ms â•‘â•‘Condition group #24 evaluated false (state did not change) (12ms)
+220ms â•‘â•‘Comparison (time) 23793740 is_after (time) 75600000 = false (8ms)
+222ms â•‘â•‘Condition #10 evaluated false (18ms)
+239ms â•‘â•‘Comparison (time) 23793760 is_before (time) 21600000 = false (9ms)
+241ms â•‘â•‘Condition #22 evaluated false (17ms)
+243ms â•‘â•‘Condition group #21 evaluated false (state did not change) (18ms)
+244ms â•‘â•‘Condition group #6 evaluated false (state did not change) (40ms)
+247ms â•‘â•‘Cancelling statement #14's schedules...
+281ms â•‘â•‘Executed physical command [Master Bathroom Light].setLevel([99]) (25ms)
+282ms â•‘â•‘Executed [Master Bathroom Light].setLevel (28ms)
+286ms â•‘â•šExecution stage complete. (167ms)
+287ms â•šEvent processed successfully (287ms)
4/11/2019, 6:36:31 AM +62ms
+2ms â•”Received event [Master Bathroom Light].switch = off with a delay of 195ms
+167ms â•‘RunTime Analysis CS > 31ms > PS > 75ms > PE > 61ms > CE
+169ms â•‘Runtime (46390 bytes) successfully initialized in 75ms (v0.3.10a.20190223) (166ms)
+170ms â•‘â•”Execution stage started
+186ms â•‘â•‘Comparison (enum) on is (string) on = true (2ms)
+188ms â•‘â•‘Condition #20 evaluated true (13ms)
+189ms â•‘â•‘Condition group #null evaluated true (state did not change) (14ms)
+230ms â•‘â•‘Comparison (enum) off changes_to (string) on = false (1ms)
+234ms â•‘â•‘Cancelling condition #3's schedules...
+236ms â•‘â•‘Condition #3 evaluated false (43ms)
+237ms â•‘â•‘Cancelling condition #1's schedules...
+238ms â•‘â•‘Condition group #1 evaluated false (state changed) (46ms)
+241ms â•‘â•šExecution stage complete. (71ms)
+242ms â•šEvent processed successfully (243ms)
4/11/2019, 6:35:13 AM +741ms
+2ms â•”Received event [Master Bedroom Light].switch = on with a delay of 179ms
+158ms â•‘RunTime Analysis CS > 28ms > PS > 68ms > PE > 63ms > CE
+161ms â•‘Runtime (46394 bytes) successfully initialized in 68ms (v0.3.10a.20190223) (158ms)
+162ms â•‘â•”Execution stage started
+177ms â•‘â•‘Comparison (enum) on is (string) on = true (2ms)
+179ms â•‘â•‘Condition #20 evaluated true (12ms)
+180ms â•‘â•‘Condition group #null evaluated true (state did not change) (14ms)
+220ms â•‘â•‘Comparison (enum) on changes_to (string) on = true (1ms)
+224ms â•‘â•‘Cancelling condition #3's schedules...
+225ms â•‘â•‘Condition #3 evaluated true (41ms)
+226ms â•‘â•‘Cancelling condition #1's schedules...
+227ms â•‘â•‘Condition group #1 evaluated true (state changed) (45ms)
+239ms â•‘â•‘Comparison (dynamic) Master Bedroom Light is_equal_to (dynamic) Upstairs Bathroom Light = false (1ms)
+241ms â•‘â•‘Condition #27 evaluated false (10ms)
+242ms â•‘â•‘Condition group #24 evaluated false (state did not change) (12ms)
+262ms â•‘â•‘Comparison (time) 23713987 is_after (time) 75600000 = false (8ms)
+264ms â•‘â•‘Condition #10 evaluated false (17ms)
+281ms â•‘â•‘Comparison (time) 23714007 is_before (time) 21600000 = false (8ms)
+283ms â•‘â•‘Condition #22 evaluated false (16ms)
+284ms â•‘â•‘Condition group #21 evaluated false (state did not change) (19ms)
+285ms â•‘â•‘Condition group #6 evaluated false (state did not change) (40ms)
+289ms â•‘â•‘Cancelling statement #14's schedules...
+334ms â•‘â•‘Executed physical command [Master Bedroom Light].setLevel([99]) (36ms)
+336ms â•‘â•‘Executed [Master Bedroom Light].setLevel (38ms)
+339ms â•‘â•šExecution stage complete. (177ms)
+341ms â•šEvent processed successfully (341ms)
#2

According to that log, this piston did not do anything when your level changed.
The only triggers were:

6:35:13 AM  Received event [Master Bedroom Light].switch = on    (stuff happened)
6:36:31 AM  Received event [Master Bathroom Light].switch = off  (nothing happened)
6:36:33 AM  Received event [Master Bathroom Light].switch = on   (stuff happened)

Perhaps it is one of your other pistons?

#3

I hope I copied the right log… I think I did as I tested it repeatedly and it kept doing the same thing. The issue is that the event should not have been switch = on as the switch was already on. I was trying to dim the light back down, and the dimmer kept trying to push me back up. I paused the piston and it immediately stopped so it has to be this piston.

Could it have anything to do with the dimmer sending an “on” event instead of a level change event when I manually change the dimmer level?

The dimmer is a Homeseer WD200+. I believe I get the same effect on the GE Motion Dimmer but I need more testing to confirm.

#4

As far as I can see, nothing you are describing is in this piston (or log). I would be tempted to load the IDE, and check the logs on the misbehaving light.
(IDE > Devices > Peculiar Light > List Events)

I suspect another piston was triggering, and the time stamps should help pinpoint which piston.

Otherwise, I’d need to see fresh logs on this piston showing the activity you describe.

#5

Only if the light was off changing to on. But that activity is not shown in this log.

First trigger was Bedroom light. turning on
Second trigger was Bathroom Light turning on a minute later

#6

I will enable the piston tomorrow and do more testing. I will also ensure I get the correct log but when I reviewed it, I could not match it up with the fact the dimmer kept fighting my manual dimming. I would not exclude that it is a hardware/firmware issue that has little or nothing to do with webCore itself. I need to do more testing with another dimmer to see if it happens with it as well, or it is just happening with the Wd200+.

#7

I really suspect another piston is to blame.
If not, then perhaps other programming logic you may have done outside of webCoRE.
(Routines, SmartApps etc)

#8

I’ll check, and I will test using one of the dimmers that has no other automation associated to it, however if I pause this piston, the dimmer stops fighting me immediately. Good to know the code looks ok so I can focus on other aspects.

#9

I’ll be honest. I have not analyzed all of your code. I just know that there is no trigger for levels changing, and no indication in your logs that the piston ran additional times. That leads me to the conclusion that something else is controlling the light.

#10

I tested it again and confirmed that when you hold the down paddle to dim the lights, an “off” event is sent and then an “on” event quickly follows. I do not believe either event should be sent, and in fact doing the same with the up paddle does not send anything. The piston malfunctions as it sees this on event as if the light had just been turned on when in reality it was already on.

Now I have to dig in the DTH to figure out where the error is.

Screenshot_20190420-120142_SmartThings
Screenshot_20190420-120142_SmartThings.jpg1080Ă—4592 1020 KB

#11

Do you have another paddle with the same model number? It sounds like a hardware flaw, but testing an identical device is the way to verify that.

(it reminds me of certain screen doors that go closed, open, closed when the door slams)

#12

My entire house is outfitted with HomeSeer WS200+ and WD200+ switches and dimmers. I tested others and they all behave the same way. I strongly suspect the DTH but not being a programmer it will take a bit for me to digest the code to figure out what is happening. At first glance it appears that it is interpreting the hold down as a push down which is “off”, however once passed a certain time threshold it understands it is a hold down (thus dimming) and so it sends out another event for “on” and sets the dimmer to the appropriate value. Since this is only happening with the down button and only when it is physically pressed, I should be able to find the issue eventually. In my screenshot, the chicken scratched P is for Physical button press, the D is for Digital dimming via ST app, and !! just points out where the issue is happening.

EDIT: The DTH I am using is a modified version of ST’s “Dimmer Switch” DTH. The ST STH works as desired so by comparing code I might be able to fix the issue in the enhanced DTH which also supports all the RGB LED goodness of the HomeSeer 200 series.

#13

Yes, I agree. If the button presses are all sending opposing commands with a single press, the easiest solution is likely to use another Device Handler (or if you want a challenge, modify the one you’re currently using)

If memory serves me right, I think someone has created a DH for those devices already.

#14

I believe I am using the one you are thinking of by Darwin. I modified it to support the lower dim level that was introduced with firmware 5.14 and I may have fixed the issue with ON / OFF events too. There were a number of sendEvent commands in the Scene section that once commented out fixed the issue. I am not sure whether I broke something else but everything appears to be working.

Edit: The scenes seem to be working fine. I do not use the multiple taps much but there are a couple dimmers where I did and they worked when I tested them last night. The piston is now behaving as expected. I guess this thread goes to show that when pistons do not work as intended, it may still be due to bad input to it… in this case caused by the device’s DTH.