Device status not updating

Click on the shield in the upper right.

image

Then uncheck S0

image

After you get the PC Controller software installed and the device recognized you pair it to your hub by starting a new zwave device pairing on the hub and then going to pc controller, clicking on learn mode and then nwi.

After the stick is joined as a secondary controller you can use nwi to add devices and they will join to the hub mesh.

If we're talking about Zigbee devices on the compatible list, using inbuilt drivers, then this for sure is a weak mesh issue.

Actually, on the zigbee side, it appears to be only a single device type (and it's using the generic driver). It's only the wemo bulbs that are having the issue. With the other issues I had, I assumed it was more widespread initially. The DH in ST shows 4 states for power (on, off, turningOn, turningOff). I wonder if the "Generic Zibee bulb" driver that I'm using in Hubitat doesn't understand the 'turningOff' state and just reports the bulb as the last known state, or if there is a different driver I could switch to that is close enough.

Ah, so the dongle will act as a secondary controller in the existing mesh? I figured there'd have to be some software that would need to exist to connect the two networks together. If that's all it is, it doesn't sound so difficult.

In Hubitat and for all actual devices there's no such thing as turning on or turning off, this is because this usually takes 100ms or less to happen...
This is an st construct designed to make you feel better when your lights take 10 years to turn on...

2 Likes

@mike.maxwell are the wemo bulbs as problematic for repeating as GE Links and Crees?

The PC Controller v5 software is used when you actually want to do something with the UZB stick. Otherwise I just leave the device disabled.

1 Like

No idea, never even tried one.

How about the Ikea bulbs? One appears to be very popular in getChildAndRouteInfo table.

I hope not. They did seem to work well in ST and really filled in my mesh nicely.

i believe all wemo bulbs are wifi. so obviously they would not be repeaters.

Here are the zigbee properties:

2 Likes

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:
image
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.