Lock connected to software bridge detected as NukiDevice

[franfos]

I've just updated Home Assistant to latest version (0.111), and now the Nuki lock is not detected (connected to Android Nuki bridge).
I've seen that bridge.locks is empty, due to the software bridge doesn't return "deviceType" in list command and then is append as a NukiDevice to the devices list.
[{"nukiId":XXXXXX"name":"Cerradura","lastKnownState":{"state":1,"stateName":"locked","batteryCritical":false,"timestamp":"2020-06-11T07:26:03+02:00"}}]
So, I think for backwards compatibility, if there is no "deviceType" when retrieving _get_devices, it should be created as NukiLock instead of a NukiDevice.
What do you think?

[pschmitt]

Oh. I haven't thought about the software bridge at all when I implemented the fallback to NukiDevice. I don't particularly like the idea of defaulting to a specific device type when none is sent. Hm, a different fallback mechanism just for the sw bridge might be a "meh" option. Are you using the latest software bridge version, or are you on an older release? Have you reported this to Nuki?

[franfos]

Yes, I'm using the latest version (1.4.6).
No, I didn't contact Nuki to report this. I guess they will update the soft bridge sometime, but this behaviour should be the same with hardware bridges not updated, isn't?
So I think that this situation has to be taken into account.
I finally made it work, but it was a fast and dirty solution (all the request to _get_devices with lock parameter are set to none parameter, and also I had to append data["deviceType"] = 0 when unknown device detected).
Maybe a solution is to check for the firmware or app version in the list command. According to this, use or not the deviceType filter.

[franfos]

Do you have any idea on how to solve it? If you want me to test something, just let me know.

[pschmitt]

AFAIK the software bridge has been discontinued by Nuki. Closing.