ebaauw / homebridge-hue

Homebridge plugin for Philips Hue
Apache License 2.0
897 stars 91 forks source link

Homebridge-Hue plugin registers devices, but devices do not show up in Homebridge. #1117

Closed philkunz closed 1 year ago

philkunz commented 1 year ago

Weird issue: Hue Plugin registers all devices in log, also prints update information from sensors, but homebridge UI does not show them any more, and Homekit shows all lights as "No response"... Any idea?

ebaauw commented 1 year ago

For accessories to show up in the Homebridge UI, you need to run Homebridge in insecure mode. Note that the Homebridge UI only shows accessories exposed by Homebridge. It cannot show native HomeKit accessories (e.g. lights exposed natively by the Hue bridge).

No Response issues are caused by issues between HomeKit on your Apple device and the HAP server on the accessory (or HomeKit bridge, like Homebridge). HomeKit uses mDNS for accessory discovery. This protocol cannot be routed, as it uses a local link multicast address. Make you run Homebridge in the same network as your Apple devices. And make sure your routers, switches, and access points don’t do IGMP snooping. Make sure all your Apple devices are on the latest firmware version, including your home hubs. On large HomeKit homes, it might take a considerable time for configuration changes (newly exposed accessories) to be synced over iCloud across all your Apple devices. “Large” as in: the configuration no longer fits a single 1MB CKRecord. In my experience, this typically happens somewhere between 150 and 200 accessories.

philkunz commented 1 year ago

insecure mode is on: Also I'm getting: [Hue] homebridge: error: Cannot add a bridged Accessory with the same UUID as another bridged Accessory: 9786ff8d-f8df-45e5-9478-f119de77b0c9, but it doesn't state the name of the accessory that is causing it.

I also see devices from other plugins in the UI (also from Hue until last week). But somehow this is now broken...

ebaauw commented 1 year ago

On startup, Homebridge Hue creates a list of accessories to be exposed and passes that back to Homebridge. Homebridge then processes the entries on this list one by one, creating the actual accessory and publishing it. The error is thrown by Homebridge while processing the list, causing the accessories for the erroneous entry and any remaining entries not to be exposed.

You would have to check the log for the last accessory that was exposed successfully: the next entry on the list is causing this. You probably need to run Homebridge in DEBUG mode to have Homebridge Hue log what accessories it wants exposed in order.

The (duplicate) accessory UUID is generated by Homebridge from the uuid_base passed by Homebridge Hue, basically the Zigbee MAC address of the device. This is by design, so you can move a device from one bridge/gateway to another, without breaking your HomeKit setup.

Do you have multiple Hue bridges and/or deCONZ gateways? Did you move a device to a new bridge/gateway, without properly deleting it from the old gateway?

philkunz commented 1 year ago

I do have two bridges. Disconnecting 1 of them solves the issues. I didn't assign any devices last night though. Can't this deduplication be done within the plugin though? Stating like a duplicate device mac or something in the logs?

ebaauw commented 1 year ago

I didn't assign any devices last night though.

The error would only appear after restarting Homebridge.

Can't this deduplication be done within the plugin though?

No, I don't know which was the old vs the new bridge for the device.

Attach the debug dump file (when both bridges are connected) if you need help figuring out which is the duplicate device.

philkunz commented 1 year ago

I'll do that. I don't get though why a deduplication check can't be performed within the plugin, at least for all accessories that are coming from the same plugin?.

ebaauw commented 1 year ago

It could be, I suppose, but I won't be doing that. Too much work for a rare use case, that can easily be prevented by properly deleting devices from the old bridge/gateway before resetting them and pairing them with another bridge/gateway.

philkunz commented 1 year ago

It is an almost empty bridge though. I'm almost sure there is no duplicate device stuff going on. What about rooms and exposing them as lights from 2 bridges? How are their UUIDs computed?

ebaauw commented 1 year ago

From the bridge ID and resource ID. Same for other non-Zigbee virtual devices.

philkunz commented 1 year ago

So the same room name on two Hue Bridges causes a collision or not?

ebaauw commented 1 year ago

No, it does not.

philkunz commented 1 year ago

ok, found the bad actor. Thank you so much for the explanations. You don't have a "buy me coffee" button though, which I'd like to do, to show some appreciation. :)