Bug: multiple zwave networks, only first client used

[firstof9]

          #372 didn't fix this for me. I am in a probably unusual situation where I have 2 separate Z-Wave JS networks, one running under the `Z-Wave JS` add-on, and the other under the `Z-Wave JS UI` add-on, each with their own Z-Wave stick. The door lock is connected to Z-Wave JS UI, which appears to load 2nd.

zwave_loaded_entries = [
    entry
    for entry in self.hass.config_entries.async_entries(ZWAVE_JS_DOMAIN)
    if entry.state == ConfigEntryState.LOADED
]
zwave_entry = zwave_loaded_entries[0] if zwave_loaded_entries else None

That appears to grab a list of all the loaded Z-Wave JS entries, then arbitrarily pick the first one. On most people's setup, there would just be one, so that is fine. But in my case, there are 2 loaded & running controllers, but only one contains the lock. I think the code needs to find which entry contains the lock and use that one, not the first one. I have no idea how to do that or I would submit a PR.

Originally posted by @DAVe3283 in https://github.com/FutureTense/keymaster/issues/369#issuecomment-2163352510

[DAVe3283]

Thanks, was about to submit this. Here is some additional info if it helps:

Describe the bug Since updating to Home Assistant 2024.6.x and keymaster 0.0.95, I have been unable to add/remove PINs from my lock. I believe this is due to a somewhat unusual setup I have, where I have 2 separate Z-Wave sticks and I run both Z-Wave JS and Z-Wave JS UI add-ons.

Previously, this worked fine, but now it doesn't. I believe this is a side effect of #372 trying to fix #369. It appears Home Assistant used to store the Z-Wave client per entity ID, so my multi-client setup worked fine. But now we just get a list, and I am not sure how to know which client to pick for the lock. The new method of using the first loaded client is only viable when there is exactly one Z-Wave client. (To be fair, I imagine this works for 99% of users.)

It might be necessary to go through the list of clients, checking if the client has the lock in it, then using that one. Or perhaps Home Assistant has some other way of getting which Z-Wave client is associated with a given entity ID than how it used to work?

Environment (please complete the following information):

• OS: HassOS 12.3
• Type of system that HA is running on: Virtual Machine
• Home Assistant version: 2024.6.2
• Hassio
• Component version: 0.0.95
• Z-Wave integration name: zwave_js and zwave_js_ui
• Lock make and model: Schlage BE469ZP

Logs

2024-06-11 14:45:38.137 ERROR (MainThread) [homeassistant.components.binary_sensor] keymaster: Error on device update!
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 729, in _async_add_entity
await entity.async_device_update(warning=False)
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1289, in async_device_update
await self.async_update()
File "/config/custom_components/keymaster/binary_sensor.py", line 154, in async_update
await async_update_zwave_js_nodes_and_devices(
File "/config/custom_components/keymaster/helpers.py", line 174, in async_update_zwave_js_nodes_and_devices
lock.zwave_js_lock_node = client.driver.controller.nodes[node_id]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^
KeyError: 2

Screenshots

Additional context Z-Wave JS doesn't have a node 2, and the door lock is node 2 on the Z-Wave JS UI controller. So it looked up the right node ID, but is trying to use the wrong client. In my case, this causes a crash, but if there was a node 2 on the other controller, I wonder what other error would occur?

[firstof9]

Looks like we should be able to pull the correct config_entry from the lock entity.

[firstof9]

@DAVe3283 if you're game, could you try the files from PR #375 ?

[DAVe3283]

I edited the files in /homeassistant/custom_components/keymaster/ then restarted Home Assistant. Hopefully that is the right procedure.

The binary_sensor change is throwing an error on startup for me:

2024-06-12 18:11:58.790 ERROR (MainThread) [homeassistant.helpers.entity] Update for binary_sensor.frontdoor_network fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 941, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1289, in async_device_update
await self.async_update()
File "/config/custom_components/keymaster/binary_sensor.py", line 128, in async_update
lock_ent_config = entity_id.config_entry_id
^^^^^^^^^
UnboundLocalError: cannot access local variable 'entity_id' where it is not associated with a value

I don't get an error from helpers.py, but I am not sure if it just didn't get that far in the startup or if it worked.

[DAVe3283]

I think I have a working patch for this. Not sure it is the best way to do this, but it is in the spirit of what was already happening.

Want me to post the files here, or should I try and push the changes to your branch, or what is the easiest way to get that to you?

[DAVe3283]

@firstof9 can you test if PR #376 works on your setup? It fixes the issue for me.

[firstof9]

It does in fact work. Thanks!