Has anyone else seen this? I can add zwave or zigbee devices to my hub, but i'm unable to control them. State might stay in pending for a long time, sometimes not. I also noticed that the remove dialog box doesn't have a remove button. I've tried soft reset and restoring a couple of old versions... even one from 3 months ago and I get the same behavior - Can add a new device, finds it correctly - device details etc. But no control at all, no further activity. Also the newly added zigbee device will show up correctly in the device list, but do not appear in the zigbee radio devices list.
Very unusual. Could you please share more details?
- Hub model
- Platform version
- Device make and model
- Screenshot of any logs
1 Like
sorry should have put that in the original post.
Platform Version
2.3.3.122
Hardware Version
Rev C-7
When a new Zigbee device is added I see this in the log
deviceJoin New Zigbee device joined 662
but once joined, when I go to the device details, I'm unable to turn on/off.
What is the make and model of your device, and what driver type does it get assigned?
1 Like
the behavior occurs with any device but in this case its a sengled color bulb here is the log from discovery to join
At the top - here is a Turn off command that do no work.
dev:6622022-09-25 04:22:16.876 pminfoSengled Element Color Plus was turned off
dev:6622022-09-25 04:22:16.833 pmdebugdescMap:[raw:CB320100060800001000, dni:CB32, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:10, command:0A, value:00, clusterInt:6, attrInt:0]
dev:6622022-09-25 04:22:16.777 pmwarnskipped:[raw:catchall: 0000 8021 00 00 0040 00 CB32 00 00 0000 00 00 2A00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:CB32, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[2A, 00]]
dev:6622022-09-25 04:22:16.769 pmdebugdescMap:[raw:catchall: 0000 8021 00 00 0040 00 CB32 00 00 0000 00 00 2A00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:CB32, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[2A, 00]]
dev:6622022-09-25 04:22:16.582 pmdebugdescMap:[raw:catchall: 0104 0006 01 01 0040 00 CB32 00 00 0000 07 01 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:CB32, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00]]
sys:12022-09-25 04:22:16.519 pminfoZigbee Discovery Stopped
dev:6622022-09-25 04:22:16.370 pmwarnskipped:[raw:catchall: 0000 8021 00 00 0040 00 CB32 00 00 0000 00 00 2600, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:CB32, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[26, 00]]
dev:6622022-09-25 04:22:16.361 pmdebugdescMap:[raw:catchall: 0000 8021 00 00 0040 00 CB32 00 00 0000 00 00 2600, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:CB32, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[26, 00]]
sys:12022-09-25 04:22:16.259 pminfoCreated Zigbee Device Sengled Element Color Plus
dev:6622022-09-25 04:22:16.236 pmtracerefresh() called...
dev:6622022-09-25 04:22:16.073 pmwarnconfigure...
sys:12022-09-25 04:22:15.204 pminfoInitializing Zigbee Device B0CE18140017E6E9, CB32
Please send me a private message along with your hub ID so we can check your engineering logs for more clues.
2 Likes
Thanks for the message. From a hardware perspective, your hub is looking great. I don't see any issues with the Zigbee radio, and just minimal issues with a few Z-Wave devices that were included with S2 and are unable to communicate properly with the hub. I do, however, recommend updating the Z-Wave firmware at your earliest convenience.
Regarding the particular Zigbee device, I noticed that you have a significant number of Zigbee bulbs connected to your hub. Depending on their brand, these are likely the culprit for Zigbee devices not working properly. We know that some bulbs are not good repeaters for other Zigbee devices.
thanks for researching - but its more than devices not working properly, if I can't add new devices and then control them it's pretty much the end of this hub. I understand that bulbs might not be the best repeaters but this behavior is different. Are you saying the during the join the neighbors are relaying correctly, but once added, subsequent communications are hindered by a repeater problem with a bulb? and rolling back to a backup from 3 months ago, with the devices removed would fix it - but it doesn't something doesn't add up.
Restoring a backup doesn't help with radio issues. You may no longer see devices (because when you restore, you may not have the same drivers in the old backup, but devices connected to the radio remain connected to the radio, you just don't see them. If you are trying to add the same devices back they are just re-join the network.
1 Like
ok - so it's a lost cause then? I would have hoped there was some way to recover or go device by device and solve the problem.
You should be able to. My recommendation is to reload the most recent backup that has all devices and corresponding drivers. Restoring a backup will never fix a radio problem. Then run Zigbee discovery (may need to reset devices to force them to rejoin). Then shut down the hub from Settings. When the LED on the hub is red, unplug the hub for 30 min (from the wall outlet).
1 Like
There are three separate databases:
The hub database, and then each of the radios (zigbee, zwave) has its own database. Going back to an older hub database doesn’t touch the radio databases.
My suggestion would be to reset the zigbee radio (from settings). Pair back your zigbee devices starting with powered repeaters. Don’t pair the bulbs.
Pair the bulbs to a Hue bridge and bring them into Hubitat using the built-in Hue integration or CoCoHue.
1 Like
Thats a lot of devices to go back to square one on, I think 130+ on at this location. Is there a way to access/edit the radio databases to root out the problem device?
Hue - does Hue work better with zigbee devices than Hubitat?, I wish I'd known that before investing in Hubitat and all of these "supported" devices.
Not to my knowledge.
This is true only for bulbs that use the ZLL profile (ZLL = zigbee light link).
Basically, ZLL bulbs are poor repeaters for non-ZLL devices, so they should be on a mesh by themselves. It even could be another Hubitat hub. Most people prefer to put them on a Hue bridge because those are available on eBay for $15-30.
2 Likes
Where can I see the profile listed for each device ? I'd like to remove all the "ZLL" devices from my network if they are don't work correctly with Hubitat
1 Like
Can you list the bulbs (brand, model)? It would be listed in the manual. Or if you post the list here, people will be happy to help out.
1 Like
Mostly OSRAM and Sengled - but surely there must be somewhere to see the ZLL profile type in the hub?
I don't see a profile in the manual for the Sengled E21-N1EA i'm using, and thats probably the most popular product they sell. It's not listed on the box. It is however listed on the Hubitat web pages as a compatible product.
These are fine. However, these bulbs don't work as repeaters at ALL. As @bobbyD asked a while back, can you list ALL your devices?
It is usually good to have one repeater for every 4-6 non-repeaters. Maybe the issue is that you don't have enough repeaters.
I believe that @bobbyD reviewed my device list, I wasn't asked to provide one but I'm happy to do so if that helps. If you are SURE that I need more repeaters, I'll go install some switches but at $45 each it would be great if it were more than a maybe/guess.
1 Like
