Philips Hue Wall-modules & dependency on the hub (what to do when the hardware fails?)

Hardware
1

Recently I realized I may have broken my own rule to never make anything in my home depended on a smart device by installing the Philips Hue Wall-modules behind most of my light-switches. These are of course depended on the Hub. And while the Hub itself is not depended on the Internet to work if the Hub ever breaks…

I was curious what would be a good course of action here. What others would recommend doing here:

  • Getting a second ‘backup hub’ you can just plugin when the other one dies late at night?
    Can you however in someway ‘copy’ or export the settings to this?

  • Any way to depended on the Bluetooth functionality as a backup

  • Remove the Wall-modules but somehow keep their functionality as is.
    I will say we are quite used to the physical switches working and controlling the lights. Mostly in combination with motion sensors. Walk into a room the lights go on, but using a physical switch to turn it off when you leave, not having lights burn for another 5 to 10 minutes. And the advantage of the Hue module is that it actually controls the bulb. Not like some solutions the power to and from the light.

  • another other good ideas? (aside from getting a good flashlight? :relaxed: )

2

Same here. I would hope that ZHA would be able to bind switches directly to lights or groups.
I couldn’t manage to do that with Hue Switches and Remotes so far.

But I have been successful with the small Ikea On/Off remote.
Now they turn on/off the group without going through the ZHA hub.

3

I got my Hue Wall Modules over the weekend and managed to bind them directly to a group using ZHA. The thread is quite old, but I thought of documenting it here in case someone encounters the same issue.

TL;DR: The modules have a custom implementation for bindings. Every time the module is reset, it creates a binding to a random group ID. Creating a group with the same ID and removing the bindings to the coordinator allows to control devices directly.

In order to achieve this, the custom ZHA Toolkit integration is required. Turning on debug logging for the component allows to get the response from each command in the log.

  1. Identify the correct group ID from the bindings table
    • Use the :toolbox: ZHA Toolkit: Get Binding Table (zha_toolkit.binds_get) service to obtain the current binding table, e.g.:
      service: zha_toolkit.binds_get
data:
 ieee: sensor.hue_module_battery
      When calling the service, make sure you wake up the module by pressing the switch.
    • The log should now contain the binding table. It should have 4 entries, the first one a binding to a group and the remaining ones to the coordinator. Take note of the group ID from the first entry (e.g. "dst": { "addrmode": 1, "group": "0x1234" }
    • It seems like ZHA toolkit (or the Zigbee Python library) has problems with larger group IDs. If the decimal representation of the group ID (treating it as a hex value) is larger than the maximum value of an uint16 (65535), you will run into issues. If the group ID from the logs is <= 9999, it should be fine. If it’s larger, reset the module and repeat the steps to see the new group ID.
  2. Add other device to the group
    • Use the :toolbox: ZHA Toolkit: Add device to group (zha_toolkit.add_to_group) service to create a new group with the same ID and add the target device to it, e.g.:
       service: zha_toolkit.add_to_group
 data:
   ieee: light.my_light
   command_data: 1234
    • Note: If you’re using the UI mode, the command_data parameter shows “Group id to remove” for me, but that seems to be a typo and refers to the group to add the device to.
  3. Remove bindings to coordinator
    • Use the :toolbox: ZHA Toolkit: Remove All Bindings from Device (zha_toolkit.binds_remove_all) service to remove all existing bindings, e.g.:
      service: zha_toolkit.binds_remove_all
data:
  ieee: sensor.hue_module_battery
      Again, remember to wake up the module by pressing the switch.
    • Note: ZHA Toolkit also has a service “Remove Bindings to Coordinator (unbind_coordinator)”, but it always results in an error for me. The same happens when specifying the endpoint parameter for the binds_remove_all action. But simply removing everything seems to work.
1 Like