GE Dimmer Switch Not Turning Off

[rsmith179]

Trying to pick someone’s brains here regarding why my GE dimmer switch doesn’t shut off my light. This problem only happens once a night, usually around 2200 hrs. I’m using a webcore piston to run the lights based on motion. They turn on fine and turn off fine throughout the whole day, but I always see my light left on right around 10pm.

Checking the event list, I see that the lights off command was sent to the switch and .200 seconds later the physical device is showing off. However, the light stays on. At this time, a setLevel command is also sent to the switch, but the level is not set like it normally is.

Not sure what type of troubleshooting information you guys need, but I have a copy of the piston I’m using, the events list from this device, etc. If anyone is willing to look at this I’d really appreciate it. By the way, I’m using the DTH created by @nuttytree .

For now, I’ve just created another piston to make sure that all of my lights are turned off at 0030 when my mode changes to Asleep but this isn’t the optimal solution for me.

[rsmith179]

webCoRE
Logs
1/17/2018, 12:43:58 AM +119ms
+5ms ╔Received event [Home].time = 1516167839155 with a delay of -1037ms
+152ms ║RunTime Analysis CS > 32ms > PS > 30ms > PE > 86ms > CE
+167ms ║Runtime (40727 bytes) successfully initialized in 30ms (v0.2.0ff.20171129) (161ms)
+172ms ║╔Execution stage started
+373ms ║║Executed physical command [Kitchen Center Light].off() (167ms)
+374ms ║║Executed [Kitchen Center Light].off (169ms)
+380ms ║║Skipped execution of physical command [Kitchen Fan Light].off([]) because it would make no change to the device. (3ms)
+381ms ║║Executed [Kitchen Fan Light].off (4ms)
+384ms ║╚Execution stage complete. (214ms)
+396ms ╚Event processed successfully (397ms)
1/17/2018, 12:42:58 AM +983ms
+1ms ╔Received event [Kitchen Motion/Temp Sensor].motion = inactive with a delay of 95ms
+114ms ║RunTime Analysis CS > 16ms > PS > 26ms > PE > 73ms > CE
+124ms ║Runtime (40743 bytes) successfully initialized in 26ms (v0.2.0ff.20171129) (122ms)
+125ms ║╔Execution stage started
+132ms ║║Comparison (enum) inactive changes_to (string) active = false (0ms)
+133ms ║║Cancelling condition #12’s schedules…
+134ms ║║Condition #12 evaluated false (5ms)
+135ms ║║Cancelling condition #1’s schedules…
+136ms ║║Condition group #1 evaluated false (state changed) (7ms)
+141ms ║║Comparison (enum) inactive changes_to (string) active = false (1ms)
+142ms ║║Cancelling condition #30’s schedules…
+143ms ║║Condition #30 evaluated false (5ms)
+144ms ║║Condition group #26 evaluated false (state did not change) (5ms)
+149ms ║║Comparison (enum) inactive changes_to (string) inactive = true (0ms)
+150ms ║║Cancelling condition #36’s schedules…
+150ms ║║Condition #36 evaluated true (4ms)
+161ms ║║Comparison (enum) on is (string) on = true (1ms)
+163ms ║║Condition #37 evaluated true (11ms)
+163ms ║║Cancelling condition #32’s schedules…
+164ms ║║Condition group #32 evaluated true (state changed) (18ms)
+166ms ║║Cancelling statement #33’s schedules…
+170ms ║║Executed virtual command [Kitchen Center Light, Kitchen Fan Light].wait (1ms)
+171ms ║║Requesting a wake up for Wed, Jan 17 2018 @ 12:43:59 AM EST (in 60.0s)
+175ms ║╚Execution stage complete. (50ms)
+177ms ║Setting up scheduled job for Wed, Jan 17 2018 @ 12:43:59 AM EST (in 59.996s)
+193ms ╚Event processed successfully (193ms)

[Mike1616]

To me that one looks like it’s doing exactly what you want it to do.

I see in the logs that it detected that the motion sensor changed to inactive. Then I see it going though your piston to see what to run. Then it sets a timer for 1 minute in the future. Then the piston wakes up again a minute later and tries to turn off the lights. It skips turning off one of them as it was already off (the fan light). So from what you’ve posted I don’t see where the failure is. Did it work that time, or did it fail?

Is there anything else which might be changing that light?

Also, just an aside, in your Inactive IF block, there’s really not much advantage to testing to see if the lights are ON before trying to turn them off. Unless you change it, pistons are going to do what you see in the logs here anyway which is to only send the commands to the devices that will change them. So if the lights are already off they won’t get told to turn off again. Now there might be times when you want them to get sent the command regardless and there’s a setting in a piston to make it do that…but I wouldn’t think you’d need to use that here.

If you can, get and post some full logs when the light did not turn off and also include the device events from the same exact time. That way it will be easier to match them up and find out where the problem is happening. To me those logs looks like it succeeded, but I can’t confirm that w/o the device logs from the same event.

Also, for troubleshooting it’s never a bad idea to log some of your own messages into the Log files. I use that rather extensively to help me figure out when things are not working properly.

[Mike1616]

There is one hole in your piston though…but it should really affect turning the lights ON rather than turning them off. if someone walks into the kitchen between 9:59:01 and 9:59:59 then the lights really should not turn ON as neither “time” condition will be met. Yes, it’s an edge case, but it’s there.

To avoid this, what you should do would be to restructure this IF clause so that you only care first about the motion changing to ON, then look at the time next and use the ELSE part to do the other time.

If Motion changes to Active
If time is between 7AM and 10PM Then
Turn on both Lights and set their level
ELSE
Just turn on the 1 light and set the level

That way you no longer have a time hole that could prevent the piston from turning on the lights as you wish.

That does not seem to me like that it should affect the light turning back OFF again, but it’s certainly odd that i’s happening right around the same time as you state in your opening.

[rsmith179]

Thanks @Mike1616 ! I saw that hole too while going through the code. I updated the code to use modes instead of times. That should work better for my case anyways.

I’ll start live logging tonight around that time to see if this happens again, that way I have some good information about what’s going on. What’s really weird is that the switch “thinks” it is off. The way I know this is that the LED indicator light on the switch actually turns back on when the off command is passed to the switch. However, the light itself stays on. I’m hoping with the few tweaks I made to the code today will help fix this issue.

[Mike1616]

Yeah, it’s odd that it seems time related. You’d think that if there was a problem it would happen all the time no matter what time of day it was, but then you probably wouldn’t be posting and asking for help if that was the case… Good mystery this one is that’s for sure.

[rsmith179]

Very strange indeed. Ran into the exact same deal this evening, again. What I find interesting is that my device logs show the setLevel command being successfully sent to the device and then shows the device actually setting the level. It does that fine all day long and then every time after 2115 it still sends the setLevel command, however, the level is not being actually set by the device.

[Yelnoc4]

Was there any resolution to this?

I’ve got a GE Dimmer switch that works fine, except…

If I press my GoodNight routine in the app, the app turns off a virtual switch and a piston then sees that and turns off the Dimmer Switch. Only when I use the GoodNight routine does turning off the virtual switch sometimes (half the time?) fail to turn off that light (and onlythat light). On every other occasion (thus far) turning off the virtual switch works perfectly. I will look over the logs tonight.

It seems odd to me that how a switch is being turned off seems to matter. Perhaps that is part of the OP’s problem as well?

[rsmith179]

My dimmers do work now and I haven’t run into any other issues with them not turning off when they should be. I don’t know exactly why they didn’t work, but I know what I did to fix them. When they turn on, I send a “turn on” command to the switch along with an emulated “Set switch to on”. When they turn off, I send a “Set switch to off” emulated command and then send the “turn off” command to the physical switch. I have absolutely no idea how/why this works by adding the emulated commands, but it does. 100% of the time now. I’ll paste a copy of the piston below for you.