Not a secure pairing issue this time.
GE, in their infinite wisdom, actually use CRC16 in some of their firmware revs. I have no idea why, as it is deprecated in the first place.
In fact, they even ADDED CRC16 encapsulation to a few models that did not have it before in a recent firmware update.
Updated to 1.4. Hopefully last update for quite a while, as I'm using this as the basis for my updated motion dimmer driver.
I tried the 26933 motion dimmer driver from your repository on my GE motion dimmers. I could turn the light on but not off so I am guessing that that driver has not been completed. The double tap feature worked really well so I can't wait for this to be completed. I do have a few GE 14291 switches and will add this driver as soon as I can get those switches migrated.
Many thanks for your work.
The motion switch/dimmer drivers are somewhat broken. I'm working on those next. Will try to get them done this week, I just need an hour or two (doesn't take that long).
Note, I do NOT have a motion switch/dimmer device with the new firmware that requires CRC16 to work right. So it is possible that the motion drivers will not work even after I get them done.
Also note, that the motion switch/dimmer devices DO NOT support doubletap at all in hardware (like the non-motion switch/dimmer do). So that won't be a feature in those drivers.
That is very interesting. When I change the dimmer to use your driver, it shows up as button controller. Although it takes a whole lot of hammering on the off switch to actually get it to turn off, the second up on the dimmer performs the expected action. Perhaps that is the problem, but it had me charged.
Just to be clear, which dimmer driver - the motion or non-motion one?
Your GH 26933 dimmer driver on a 26933 motion dimmer.
Ok, that makes sense. That driver is screwed up. Hopefully the replacement will work better.
I should take that down off GitHub until I replace it I guess
Going out on a limb here...but is there a way to create child devices like the inovelli drivers do for other branded dimmers or is that a hardware specific thing? If you're not familiar with their switches/drivers... you can set the default dimmer levels through RM using the child devices so the switch doesn't need to cycle on/off to save the last level. I'm sure someone would have already thought of this if it were possible, but figured I'd ask anyway
That's a hardware specific thing.
It would certainly be possible for any device driver to catch the on or off when turned on or off from HE, and then go to a specified level.
It would also be possible to catch on or off events from the switch, and then force the switch to a predefined level. The light would initially go to whatever the last dimmer level was, and then go to the predefined level, which kind of sucks.
But that's about all the options if the device does not support setting on level in hardware.
If you're controlling from HE, don't turn the switch on and then set the level....just set the level. The switch shouldn't come on to the last level first, it should just ramp to the level that you set. But that is only controlling with HE. If controlling locally, the switch is always going to come on to the last level that was set since that is the only level that it "knows". Some other dimmers have a "double up" for 100% (like the Quibino flush dimmer).
The other problem with capturing the "on" event in HE to dim the light after it has been turned on...the switch won't report back to HE that it's "on" until it completes its ramp to the value that it is trying to reach. So, HE won't know the switch is on till it's at the level that you're trying to avoid.
The way I've gotten around this is just avoiding ever having to turn switches on manually. If you control from motion, then the switch only has to be used to adjust the level or turn it off early.
Cool. You have one of the new firmware devices that uses CRC16. I don't have any of those, so it doesn't surprise me that it doesn't work. I tried 3x to order one and get the new firmware revisions, but no luck.
I'll take a look and see if I can try something else. But not having any of that firmware revision, I'm not sure how much progress I'll make.
Does it actually do anything in terms of turning on/off or dimming when you ask it to? Just curious.
@jon1 I think I know what the problem is (based on some help from mike maxwell).
If you have a minute could you use the driver, turn ON debug logging, do the same thing again, and send me the log?
Also: I updated the version to incorporate the info Hubitat gave me on CRC16. Should fix/remove a lot of those messages you were seeing.
v 1.6 uploaded. Another attempt to get CRC16 encapsulated commands working properly on devices with the latest firmware rev.
OK, I just (5 seconds ago) uploaded an updated version of 1.6 (1.6.1...) that theoretically should fix the CRC16 part.
If you get time try it, and let me know. Thanks for your help.
Yep no more crc16 messages.
I do see this wan log every time I turn it on or off
dev:2402019-03-03 13:50:10.781 warnParse returned null for zw device: 21, command: 2603, payload: 2A
Also I dont think I see an actual plain Info log of the dimmer going on and off and the level its at like the standard dimmer driver.
I typically make my drivers to log NOTHING by default, as it just pollutes the logs. The device event history is really where 'normal' things should show up - not the log.
I'll go look for the warning log, that shouldn't be in there either...
I feel its more "standard" to have the device log on and off events and dimmer levels to Info. At least pretty much every other device I have does this.
Download the Hubitat app
