Dimmer sending the same event twice -- help!

For some reason, my GE Dimmer is sending an “off” event twice when I turn it off.

4:58:21 PM: debug Parse returned [Switch - Dimmer - Track Lights was turned off]
4:58:14 PM: debug Parse returned [Switch - Dimmer - Track Lights was turned off]
4:58:07 PM: debug Parse returned [Switch - Dimmer - Track Lights was turned on, Switch - Dimmer - Track Lights dimmed 67 %]

Any idea what could be causing this/how I can stop it? It’s coming through as a physical event but there was never a second press. It only happens when the lights were on and then turned off.

Exact model of dimmer? And what device type are you using for it?

And is this new behavior for a dimmer that’s been installed for a while? Or is it a new device?

It’s a GE Zwave Dimmer Model 12724

It’s relatively new, but I’ve been using it for a couple weeks. I didn’t notice it doing this until today. I have an app that re-purposes the “off” button as a toggle for other lights and it worked fine until today. Now when I turn the main lights off it triggers the app because of this duplicate event being sent.

This is happening with the stock “Dimmer Switch” device type.

It’s weird, it seems to happen pretty much at exactly 7 seconds after the first “off” event. Here’s another log:

5:41:26 PM: debug event from: Switch - Dimmer - Track Lights, value: off, source: DEVICE, description: zw device: 04, command: 2003, payload: 00
5:41:19 PM: debug event from: Switch - Dimmer - Track Lights, value: off, source: DEVICE, description: zw device: 04, command: 2003, payload: 00

Only happening with my dimmer switch, my standard GE switches don’t send the duplicate event

In addition to the duplicate “off” event being sent, I’ve now discovered another situation where the switch sends an inappropriate physical off event.

If I dim the lights down to 0 using my PHONE i.e., a virtual event, the switch sends a PHYSICAL “off” event once the lights go completely off.

Anyone have any thoughts on this? Or would somebody at least mind testing their dimmer switches to see if they have the same behavior? It would help to know if this is expected behavior or a bug with the device itself or if there’s some problem with my account.

This is normal behavior. For example, when an app that turns lights on / off from motion sends the device.off() command, once the light is actually off the device sends PHYSICAL Off. And, setLevel(0) is interpreted as .off().

Ah. So this must also be the explanation for the “duplicate” off events as well. An “off” event is set to the lights, which then dim slowly down to 0, at which point another “off” event is sent.

So, here’s my dilemma. I am the author of the app “Double Duty” which lets you use redundant “off” and “on” presses of a light switch to toggle other lights/switches/devices. What it does is checks the incoming event to see if it was redundant (by using the event.isChangedState() method) and, if so, it triggers the toggle. But with dimmers, these extra physical “off” events cause the app to toggle when you don’t necessarily want it to (the first one is sent with changedState = true while the second event it comes through as changedState = false).

Do you have any recommendations on how I can go about working around this? My first thought is that perhaps I can use separate logic for dimmers that essentially says to “ignore” duplicate events that are sent within a certain window, like, say, 10 seconds. Or maybe I can look for a setLevel(0) event that precedes an “off” event and ignore it based on that criteria? Feels kind of crude though, I’m open to any suggestions!

Thank you for the feedback

Can of worms. By that I mean there is no good answer. The number of scenarios that can create the off event is beyond anything as simple as ignoring events. As soon as you ignore some event based on some logic, you will inevitably miss one you shouldn’t miss. Some apps throw extra on() and off() events, that are essentially redundant, but have to be responded to nevertheless. An app like yours is vulnerable to this.

At one point I was fighting with this issue also. There was some discussion about the ability to tell when a particular SmartApp instance was the source of an off() or on() command, but it didn’t work right.

Are these extra “offs” reporting isChangedState(), even though the light was already off?

1 Like

Yeah, “can of worms” is exactly the gut feeling I have had about this.

The first “off” event comes through with isChangedState() == true, but the second ones comes through as isChangedState() == false. I would be ok if the second event reported true again, but it doesn’t :frowning:

Perhaps my best course of action is to simply include a disclaimer about using this app with dimmers. “On” always seems to work just fine though. It’s only “off” that gives me these problems. The few users I have, and myself, have not run into this problem with regular non-dimming switches.

And yet, this is exactly what it should be. The device is reporting off, and the device type knows it’s off already.

Yeah, no objection from me there. I totally understand what is going on with these extra events now, I really appreciate your information.

I am going to simply include a disclaimer with my app about using it with dimmers. These events result in some quirky behavior, but also not something you can’t learn to live with. At least it’s predictable and you can account for it in your daily usage.

Have you ever tried to sit in a flexible chair? WAF is going to suffer…

Well, I guess my “public” version could just not allow dimmers. But I personally am specifically using this app with a dimmer so I need that functionality. My wife is the one that reported the behavior to me, now she knows how to live with it :slight_smile: