Name of group Scenes will be overwritten

[Nastras]

Hello Erik,

I need your help. For some time now, the name of group scenes in Homekit is overwritten.

Example: the group scene is called in Hue App Alarm Light in Homekit is displayed to me the scenes under the group with the name Living Room Alarm Light.

If I change this name in Homekit and delete the word living room is so that only alarm light is there after a certain time this is overwritten again. Then there is again living room alarm light.

It looks like homebridge-hue keeps overwriting the name and adding the room. I am sure that it was not like this before. Do you have any idea?

Thanks a lot!

[ebaauw]

Yes, this behaviour was changed due to changes in iOS 16. I'm afraid I cannot solve your issue in Homebridge Hue; you would have to migrate to Homebridge deCONZ (or to Homebridge Hue2, when that will be available) to stop this from happening.

Before iOS 16, HomeKit accessory and service names were managed by HomeKit apps (through the HomeKit framework) independently from, and invisible to, HomeKit accessories (through the HomeKit Accessory Protocol, HAP). Upon pairing an accessory, HomeKit would initialise (copy) the accessory and service names from HAP, but after that, they lived a life of their own.

iOS 16 has changed this logic in two ways:

• HomeKit service names are no longer initialised from the service name exposed over HAP, but rather from the accessory name. Consequently, all scenes in HomeKit are now initialised from the group name, rather than from the scene name, making it impossible to understand which HomeKit service corresponds to which scene is which;
• When a HomeKit service contains Configured Name, the HomeKit service name is synced to that characteristic, which is visible to the accessory over HAP.

Do deal with these iOS 16 changes, I changes all my plugins to expose Configured Name, so HomeKit would initialise the service name correctly. For my newer plugins this works without issues. These use the dynamic platform accessory setup, in which the accessories are persisted (in cachedAccessories) across Homebridge restarts, preserving the value of Configured Name. Homebridge Hue however, still uses the old static platform accessories setup, in which the accessories are re-initialised on each restart, resetting Configured Name.

[Nastras]

Thanks for the super explanation 👌 That was not yet known to me. Pretty dumb from Apple 😅.

I would love to switch to your new apps. If I see it correctly the deconz plugin is most ready to go. Hue2 still needs development time before it can be used productively or?

Does the group scenes function already exist in the deconz plugin? I'm looking at the wiki right now and can't find an entry for it?

[ebaauw]

Yeah Hue2 is still just a placeholder.

Homebridge deCONZ is functional, but not yet complete. I've switched my lights, Hue motion sensors, and Stakvind over to Homebridgde deCONZ. Groups and scenes should work fine - note that you need to expose these through the dynamic configuration API, see https://github.com/ebaauw/homebridge-deconz/wiki/Dynamic-Configuration.

[Nastras]

Good morning, just got a notification that you replied after you closed the case. Therefore the late answer. Sorry for that.

I will reset my Homekit as soon as the next iOS update is released. I will then switch to your new deconz plugin. I am considering whether I should try again to register all Hue Zigbee devices via deconz and remove the Hue Bridge for it.

I had a few years ago this attempt with deconz already made and negative experience. The performance was not very good with over 150 devices. Many delays. Meanwhile, I have determined 200 devices but I have read that Dresden Elektronik now says that up to 500 devices are supported. We had written to my negative experiences also because the light switches had a big delay maybe you remember?

If that would work it would be in many things a big advantage for me. Is of course a lot of work therefore the question to you specialists 😉

What do you think it is worth a try to integrate all Zigbee devices via deconz to create a network with 200 devices + or do you think the performance will still be poor?

Regards Nastra

[ebaauw]

I think the only sensible answer to your performance question is "your mileage may vary". I can give some qualitative arguments, but I wouldn't know how to quantify these, in general, and specially not in your setup.

With the same devices in the same topology, a deCONZ gateway easily outperforms a Hue bridge:

• The hardware running a deCONZ gateway is more powerful than the Hue bridge hardware;
• deCONZ supports more rules than the Hue bridge, allowing for more extensive automations;
• deCONZ sets up attribute reporting for devices that support this. All ZigBee-3 Hue lights do support attribute reporting, even though the Hue bridge doesn't use this feature;
• For ZLL Hue lights that don't support attribute reporting, deCONZ uses FC02 cluster (exposed with recent light firmware), to poll on/off, brightness, and colour in one ZIgbee message, rather than in three.
• deCONZ provides real-time notifications, where the Hue bridge collects notifications and only issues them once a second.

A smaller, more dense Zigbee network outperforms a larger, more spread out Zigbee network:

• The bridge/gateway only polls one light per second; the more lights, the longer it takes for a light to be polled next. Mitigation: use attribute reporting instead of polling;
• The more hops a unicast Zigbee message requires, the longer it takes. While this is probably negligible in practice, route discovery becomes more elaborate, not just from the bridge/gateway to the device, but also from the device to the bridge/gateway. Mitigation: use groups commands (preferably from bridge/gateway rules); keep your network stable - don't use wall switches to cut power to Zigbee routers requiring new routes to be discovered;
• Broadcast messages take a little longer to propagate through the network, blocking other other commands a little longer. This is probably negligible, in practice.

A single-vendor network outperforms a multi-vendor network:

• Different vendors use different Zigbee stacks, and they don't always play nice together. The Zigbee specs leave room for interpretation, and some devices simply don't adhere to the standards. The Zigbee certification isn't waterproof.
  Mitigation: use recent, Zigbee-3 devices from reputable vendors, move asocial devices to their own network. On the longer term: move to Thread, as every vendor uses the same OpenThread stack.
• This could cause issues with route discover, see previous section;
• This could cause issues with end-devices not finding a new parent router, when the previous parent is no longer available. Mitigation: Keep your network stable - don't use wall swicthes to cut power to Zigbee routers.

I moved all my devices to deCONZ. My network includes 121 Zigbee devices (some 55 routers, a few ZGP switches, and the rest end devices). I still have a second deCONZ installation with a separate network with only 9 end devices that keep getting lost when connected to the large network.

[Nastras]

Thank you very much for the very detailed answer. Since you realize that you know what you're talking about 👌

I think I will try it out. Maybe I will also split it between two deconz bridges to make sure the networks are not too big.

If it wasn't so much work I would just give it a try 😅

I can understand your statement about your second deconz instance. I have the same behavior with the square Xiaomi Temp sensors and Xiaomi vibration sensors in my deconz setup. They need to be reconnected frequently. Why was a mystery to me until now. But if it is the same for you then I am reassured.

I thank you again and will soon report how it runs with your new deconz plugin 😉

[ebaauw]

I have the same behavior with the square Xiaomi Temp sensors and Xiaomi vibration sensors in my deconz setup.

These (lumi.weather and lumi.vibration) tend to be very stable, in my experience (at least until their battery starts running low). Note that they won't switch parents, so be sure to pair them near the physical location where you will be using them, and do not cut power to their parent routers (or power down any routers behind traditional wall switches, before pairing them, forcing them to select an always powered parent).

I have issues with the Xiaomi shade driver E1 (lumi.curtain.acn002), the IKEA Fyrtur, and the the Xiaomi mmWave presence sensor (lumi.motion.ac01). The first two are light sleepers (polling their parent every 5 seconds, so they are always reachable), the latter are Reduced Feature Devices, but have Receiver on When Idle, so they don't poll a parent router at all.