I just moved 5 Osram Lightify A19 RGBW bulbs and 4 Osram Lightify BR RGBW bulbs from the Osram controler and directly paired them to Hassio.
Everything worked fine for a couple of days, but now I’m getting lights reporting unavailable. I’ve power cycled the lights and Hass, but it appears I’m going to have to re-pair them.
Any suggestions to prevent this in the future or is this a known issue?
I’ve seen similar. I migrated these over after getting a quirk that supports setting the default state on them like Lightify does. mine are in a lot of lamps that are power cycled regularly - used more for the custom white color my wife likes.
FYI
I was able to get the Xfinity door sensors to pair/work with huzbzb-1 stick on a Raspberry Pi 3b+. It was the same procedure for pairing the Samsung door sensors. 1. Remove battery
2. Tell HA to look for new devices
3. While depressing the tamper switch reinsert battery
4. Let go of the tamper switch after a few seconds (5-10 seconds for me)
I put the cover back on after I tested it.
Remember that it takes a while for the device list to update. 
Is there a hard or soft limit on the number of zigbee devices supported by HA or controllers in general? I’m sitting at about 12 or so right now, and am thinking about adding 4 more leak sensors.
on a side note, I actually had a real water leak alert the other day, and was able to catch it immediately. Which was awesome. I’ve had a few false alarms over the last few months, but it was almost always a false alert after a restart, or when losing connectivty to all zha devices. zha has been super stable for me lately, so I’m so happy I want to buy some more.
EZSP radios (HUSBZB-1) are configured to support 32 directly connected “End Devices”. Battery Operated devices (like leak sensors) usually are “Zigbee End Devices” – meaning they require a “parent” device to communicate with the rest of the network.
There’s a limit how many “Router” neighbors each device can have and each “Router” in turn may have other “End Devices” registered with. So if for example you exceed 32 “End Devices” coordinator capacity, you may add a Zigbee Router which can accept additional End devices.
In other words, adding more router allows you more battery operated devices to be on the network. Currently in my environment I have about 70 devices and the only problem I have are caused by some xiaomi devices loosing network from time to time.
2 Likes
This is great news as those are the only devices I still have on my smartthings hub (well and my samsung TV that isn’t needed) Might see if I can get them working next time I have a chance to play with HA.
As another note is it expected behavior to lose all ZHA devices when I update HA (in a docker if it matters) All my other entities (Zwave & MQTT discovered devices) stick around but I need to manually go and repair the 4 Sengled bulbs that I have. After I update it shows no devices in my ZHA integration until I repair them.
Nope, it is not expected. Are the entities there, just unavailable? Do the spring back to life if you physically trigger the light?
PS: Bosch ISW-ZPR1-WP13 and Nyce door/tilt sensors were supported since HA 0.88.0
I’ve wondered about this, and did some searches but was unable to find an answer:
Is there some way to display a network diagram, map or list of which Zigbee devices are connected to which?
For example, how would I know if one of my devices has a built-in router and if so, that it’s being used?
Check FAQ: Mapping your ZigBee network with Digi's XCTU - FAQ - SmartThings Community
Usually mains powered Zigbee devices are Zigbee routers. Sengled bulbs being an exception.
1 Like
They aren’t there and they don’t come back if I toggle the light.
The devices do not show up under integrations or under the zha “control panel”. I’ve currently only repaired 3/4 bulbs (2 are outside lights so not that urgent) the last one doesn’t show up in HA in anyway.
Of note when I do repair them HA knows they are the same bulbs cause it uses the names without me having to set them.
Also this is only when I update the docker they persist if I just restart it.
Wow, thanks!.That looks great, if I had a large network. Not sure I’m ready to spring $40-$50 on hardware just to satisfy my curiosity though.
Yes, that’s what I thought, too. Until I did some more reading on my Sylvania 72922 smart plug. It turns out it’s really a “72922-A” which reportedly doesn’t include the routing function.
Did you ever find out what caused this?
I just migrated everything over from a Wink Hub 2 and I have had 2 lights do the same thing. I had to remove them then re add them. Hoping it is nothing serious
I had similar issues. I ended up removing a CentraLite plug from my zigbee network and things have gotten a lot more stable. My osram lights are all staying connected and when someone kills them via a switch they are coming right back. (for the most part I just noticed I had lost one). but overall seeing a lot of improvement. I think it comes down to the different devices being picky about routers they are connected too.or some routers not being up to snuff.
I ended up having to re-pair them. So far I haven’t lost any more lights, but now I had one of my old Wink/GE Outlinks drop off and will need to re-pair it. Oddly, it’s been the one device that hasn’t dropped before.
I used to have this problem with Wink all the time, so far Hass has been better with the Outlinks, but I just added the lights so time will tell.
I’ll fix the outlet tomorrow and see if anything else drops.
That is exactly what I did,
I am trying to get the WAF (Wife Approval Factor) lol so I am hoping for some stability. The Wink app was just horrific on our Android devices. I just love HA and have learnt a great deal in the last couple of weeks. On the whole I have been really pleased, it was super easy to migrate everything from the Wink, I did this on the weekend just passed then unplugged the Wink hub so this week is the first real test with all 30 bulbs and 2 Z-Wave plugs
Since I just updated over the weekend it happened again. I repaired 2 of the 4 bulbs because they get used more often. The remaining 2 bulbs are exterior lights and just turn on/off with sunset so they staying on is less of an issue.
So exactly what data would be useful to help debug this issue? I’d love to be able to update the HA docker without needing to repair the zigbee bulbs (I currently only have the 4 Sengled bulbs for zigbee devices connected directly to HA partly because of this issue). None of my other devices (Wifi/MQTT/Zwave) get lost when I update HA and I’m not sure if its a permission thing but the Zigbee db file (to my very novice linux eye) looks to be correct.
Start with “definition” of “loosing” a Zigbee device
The device doesn’t show up in HA. It isn’t under configuration > integrations > ZHA or under configuration > ZHA . From what I can tell the device does not exist in any way HA.
When I repair the device it gets the same name that I defined the first time I added it however.
The only way this would happen if zigbee.db from your /config folder is deleted/not preserved.
Does this happen on every restart or only on updates?
It only happens after updates. I’m not sure why it would be getting deleted it should have the same permissions as all the other files that HA makes (known_devices.yaml sticks around)
Would it help to manually delete the file before the next time I update and then let HA remake it from scratch?
I’m not at my server right now so can’t pull logs or check file permissions right now.