Individual Zigbee lights go unresponsive

Hi there. I'm in the process of migrating devices from Smartthings to Hubitat. I have three SYLVANIA SMART+ ZigBee Full Color Accent Lights (Ledvance under the hood) that I've recently moved over to Hubitat.

I've had them all working as designed, called from a Webcore piston that will change colors every 10 seconds as a test. Today one of the three was offline. I've read about Zigbee messages not getting there due to poor repeaters and whatnot, but what's odd is I don't see the hub sending commands to the device at all. If they were getting lost from point A to point B, I should still see the device commands in the hub log?

I bring up the device in the portal and none of the commands appear in the log except 'configure' which you can see below. I can share the WebCore piston, but I don't think its relevant to this issue.

Any help is greatly appreciated.

[dev:111]( 09:56:43.124 pm [debug]( options testing...

[dev:111]( 09:56:40.107 pm [warn](

[dev:111]( 09:56:39.939 pm [warn](

[dev:111]( 09:56:39.787 pm [warn](

[dev:111]( 09:56:39.634 pm [warn](

[dev:111]( 09:56:39.490 pm [warn](

[dev:111]( 09:56:39.315 pm [warn](

[dev:111]( 09:56:39.155 pm [warn](

[dev:111]( 09:56:39.003 pm [warn](

[dev:110]( 09:56:31.390 pm [info]( Front Landscape color is White

[dev:110]( 09:56:31.387 pm [info]( Front Landscape saturation was set to 0%

[dev:110]( 09:56:31.384 pm [info]( Front Landscape hue was set to 0%

[dev:112]( 09:56:31.189 pm [info]( Back Landscape color is Azure

[dev:112]( 09:56:31.185 pm [info]( Back Landscape saturation was set to 92%

[dev:112]( 09:56:31.182 pm [info]( Back Landscape hue was set to 56%

[dev:110]( 09:56:31.076 pm [info]( Front Landscape level was set to 41%

[dev:112]( 09:56:30.867 pm [info]( Back Landscape level was set to 75%

[dev:110]( 09:56:21.149 pm [info]( Front Landscape color is Orange

[dev:110]( 09:56:21.145 pm [info]( Front Landscape hue was set to 11%

[dev:112]( 09:56:20.996 pm [info]( Back Landscape color is White

[dev:112]( 09:56:20.993 pm [info]( Back Landscape saturation was set to 0%

[dev:112]( 09:56:20.987 pm [info]( Back Landscape hue was set to 0%

[dev:110]( 09:56:20.667 pm [info]( Front Landscape level was set to 85%

[dev:112]( 09:56:20.593 pm [info]( Back Landscape level was set to 96%

[dev:110]( 09:56:10.869 pm [info]( Front Landscape saturation was set to 100%

Do you have anything besides bulbs on your zigbee mesh?

1 Like

Most drivers don't log when you send commands, though some of their newer ones do, and "configure" is somewhat of an oddball command that I think most drivers have logged. (I personally find it helpful when drivers do log any commands you send to them if you have debug logging enabled--it helps with debugging. :slight_smile: ) In any case, if you're sending the command from the device page directly, you don't have to worry too much about that: you're sending the command, so you know it's being executed.

What you'll normally find in the logs if you have debug logging enabled is messages that come in from the device. Without debug logging enabled and just description text logging enabled (this is the default, or at least it is after debug logging self-disables 30 minutes after enabling it or adding the device), what you'll see is generally just the events that Hubitat parses out of this information. Your logs actually appear to be full of those--I see lots for color and level. Unless those aren't the problematic bulbs, my guess would be that they are communicating fine.

Here's a guess: did you happen to enable prestaging on these bulbs? On most older drivers for devices that support this, this is a preference you can find on the device page. What it does is prevent the lights from turning on with a "Set Color" or "Set Color Temperature" command (if color prestaging is enabled) or "Set Level" (if level prestaging is enabled...can't remember if any stock drivers did that). These commands normally turn the bulb on in addition to setting the color/level. With them enabled, you'd need an explicit "On" afterwards (unless the device is already on). Most apps don't expect this and don't play well with these settings, so automations, including webCoRE pistonsm aren't like to work as you expect, but you can use the device page to play around and see if that's your problem. (With webCoRE, this would be easy to solve: just add an "on" afterwards. But it sounds like you didn't want this feature enabled, so I'd just disable it otherwise.)

1 Like

Hi all, apologies for the delay in returning and updating this. Turned out to be a combination of a Zwave outlet not turning in when expected, a hardware failure on one of the lights, and user error on me not figuring this out.

I moved the Zwave outlet from Smartthings to to Hubitat (and rejiggered my outlets so the light set in question wasn't on the smart switch anyway). The other set I replaced the Zigbee hardware and power transformer with a spare and it started working.

It looks like if the device isn't available on the network, no commands get set or logged. First thing to check it to see if it has power, which in both cases it didn't which caused nothing to show up in the log.

I ended up figuring out it was power issues, but I did go down the zigbee rabbit hole and found the zigbee hub settings where I can look at my devices.

I ended up figuring out it was 2 different power issues, but I've had to fiddle with my Zigbee drivers for a few other bulbs get them to work correctly. Hubitat seems to default to CT drivers that hasn't worked for me in a couple instances.

Download the Hubitat app