i believe all wemo bulbs are wifi. so obviously they would not be repeaters.
I did a little more digging after pondering your comment. Both of these Wemo bulbs seem to take forever to shutoff. They fade from full to off automatically in about 4 seconds (just a rough count in my head).
I found a Generic ZigBee RGBW Light for hubitat, loaded it and started testing. I modified the name on line 33, so I could easily spot the modified driver. Then, I changed the driver for one of the Wemo bulbs to this test driver.
I've never written (or looked at) one of these groovy files before. It looks like line 209 is what performs the 'off' routine. I'd suspect that "he cmd" sets the device based on the arguments, and "he rattr" retrieves the attribute in the arguments. In between the 'cmd' and 'retr' is a delay.
It's obvious what I did next... When I changed the delay from the original 1000 to 3000, the test bulb still failed. I watched the bulb do the fade routine and noticed it stutter from the normally smooth fade to off. It must have done that because the hub had just requested a status update, so the bulb's CPU became busy for a moment.
Since it didn't work, I tried adjusting the delay to 6000 - Bingo, the state is detected 100% of the time. That seemed to be a big time to wait, so I lowered the number a few times. It seemed like 3200 worked most of the time, but 3500 worked consistently.
Is there a Generic Zigbee White driver that I could modify and use? I could just pull the RGB stuff out of this one, but changing a single line is so much easier.
Would it be possible to setup a while loop inside of off() to check the bulb state as it transitions to off (with some sort of timeout, of course), or would that be too chatty?
Last question: I'd suspect that there might be a config option that the bulb has that might change the shutoff fade to a smaller time window. Is there a zigbee cmd that works on most bulbs to adjust that setting? It might be easier to change that to 500ms instead of (roughly) 3000ms that it currently is.
Is there a similar device for zigbee that you like? It sounds like a lot of people that like to tinker with zigbee have xbee devices.
not a good idea
try the Sengled Element Plus driver, it works differently than the generic and has some reporting options that may help.
Just gave this a try. The bulb state update never completes:
However, if I were a little more brave, I might update the transition time and switch back to the generic driver. I just don't want to break something on the bulb that I can set back if the arguments don't line up.
It still might be fun to modify/write a driver for this, just to learn a little bit about it.
Do the drivers maintain variables between runs? Would I be able to rattr the transition timer for the bulb, then use that stored info as during the delay before rattr (and add a few hundred ms for network lag)? If I can get that to work, I'd submit that as a feature request for the generic driver.
Interesting, it looks like I'm not the first person to have this issue.
1 Like
You might try @bertabcd1234 's modified RGBW driver Hubitat/Generic-Zigbee-RGBW-Light-Tamed.groovy at master · RMoRobert/Hubitat · GitHub and see if it also fixes the issue.
def off() {
def cmd = [
"he cmd 0x${device.deviceNetworkId} 0x${device.endpointId} 0x0006 0 {}",
"delay 1500",
"he rattr 0x${device.deviceNetworkId} 0x${device.endpointId} 0x0006 0 {}"
]
return cmd
}
It looks like this one might have the same results as the stock code, based on the delay command. I might try it anyway to see if I can adjust the bulb's settings to not take 3 seconds to shutdown.
EDIT: tried, misses the off event as expected. Also tried updating the preference, save and configure, no go there either. I think I'll just run with the driver that "worked" at 3.5 second delay.
@bertabcd1234 has made some great apps (CoCoHue being just one) and drivers. Maybe he would be willing to give you some direction/help.
I’ve read that hitting configure may override the preferences and that preferences should be saved last.
Just went back and tried again, no luck with just 'save'. I'm guessing the bulb doesn't have the transition time implemented, or it's a different command.
My understanding is that Hubitat has some changes/additions for bulb drivers planned for 2.2.5 (whenever that happens), which I'm hoping will help with issues like these, though I don't know exactly what those changes are supposed to be yet. 
Increasing the delay between commands is just something that helped some of my directly-paired Zigbee bulbs work a bit better, but it was just one guess/attempt on my part. (Moving them back to the Hue Bridge was my long-term solution.)
Which bulbs do you use? Any recommendations?
The Sengled bulbs I have seem to be no-frills, always working, and the plain white ones are cheap. The Ikea bulbs are a little more expensive, repeat, and don't seem to give me any issues either.
I use mostly Hue bulbs on a Hue Bridge, but I have a few others on the Hue Bridge as well (including a few Cree Connected since Hue doesn't make a cool-white-only model and they do, and color/CT was overkill for these locations). This ended up being a lot more reliable for me than Zigbee bulbs paired directly to a Hubitat hub, even one I dedicated exclusively to Zigbee bulbs (which can be problematic in other ways on mixed networks). A Hue Bridge is almost cheap but worth it as long as there are still problems with Zigbee bulbs, IMHO. Hue bulbs are...not as cheap, but any Zigbee Light Link or Zigbee 3.0 bulb should also work (just not ZHA-only bulbs like Sengled or North American Osram/Sylvania).
I don't have particular bulb recommendations beyond the above, but maybe someone who has had good luck with directly-paired bulbs can chime in if they've found any to work well.
I love my Hue bulbs as well. I had them directly connected briefly and it was terrible. I also love my recessed Sylvania rgbws, but the A-19 rgbws seem to overheat and it destroys them. I have been slowly replacing them with Hue bulbs.
I only have a couple of Sengled, and they work OK for my uses. Thanks to @bertabcd1234 and others I can set the Sengled to closely match the color from my Hue lights in the same room.
I use one for reading light and occassional "color notifications" and the other is 99% color notifications (not used often just for lighting).
The only issue I've seen is they can be a little "slow" taking multiple commands in a row. I have an automation that turns one on to red, and back off to it's original setting (CT 2750) and if that automation doesn't include a delayin the command speed the bulb may not complete turning off after going back to CT 2750.
This speed issue has not been a problem w/normal on/off automations, only when sending multiple commands quickly in a row.
Based on this, I think your procedure worked to join without S0 enabled. I guess I'll find out if this bulb brings down the z-wave mesh like it did before.
Update from 1 hour later: Nope, didn't work. Including the Inovelli bulb caused all z-wave devices to become unresponsive. Weird that one seemed fine, but adding the second messed up all the zwave stuff.
I just swapped them out for a cheap pair of wifi bulbs.
I generally avoid zigbee or zwave bulbs because of all the routing issues they can cause. I've had good luck with the TP-Link Kasa wifi bulbs and the Innovelli Red Dimmers with the "local load control" disabled and the "smart bulb" preference enabled. Allows for controlling the bulbs from the switch without killing power to the bulbs. The kids like having the color changing bulbs in their room. Also work great for sending them notification like get your ■■■ to the bus stop.
I guess this would work for zwave and zigbee bulbs too but I don't like having bulbs doing any mesh routing.
Oh, they look cheap enough. I've been using the Wiz bulbs that costco sells at $16 for 2 for wifi bulbs. https://www.costco.com/wiz-wi-fi-color-a19-smart-bulb%2C-2-pack.product.100672222.html
The HE driver is very manual - set the IP of the local bulb, and make a static reservation in your router. When I was on ST, they had cloud-to-cloud integration (or something), so the bulbs would just show up. A few of them flash when off, almost as if there is an activity LED inside. It's only visible after your eyes have been adjusted to darkness. Weird.
It would seem bulb preference is Ford vs. Chevy, Coke vs. Pepsi, Peperoni vs Sausage. Nobody agrees, or they just get what works for them.
I bought the TP-Link ones because they had a native integration for them but ended up not using it because the kids wanted to use their phones and the Kasa app to change the colors instead. But at least there's the option in the future. I can still do anything I want to the bulbs via RM4 or whatever so I don't care one way or the other.
