Zigbee2mqtt: Ubisys S1 and S2 (probably C4, J1 and D1 too) default bindings

[sjorge]

At least the S1 and S2 have are bound to themselves by default
S1: ep2 -> ep1
S2: ep3 -> ep1 + ep4 -> ep2

Can we somehow record this information in the database.db so that things like z2m show the correct default bindings?
(Similar to the ikea on/off remote)

[Koenkk]

Also involving @felixstorm, but I think we can achieve this by doing this in the devices.js configure() (just bind again)

[sjorge]

Won’t the bind fail because it is already bound?

[felixstorm]

@Koenkk I am a bit hesitant to modify potentially purposely changed device configurations in configure() (e.g. in case an already existing device has been unbound from itself already or configureKey needs to be increased), but it might be possible to get around these problems by passing the old configureKey and force parameters to configure() and then have logic only work on "brand new" devices.

I see two more options, but both have their own pros and cons:

• Add a fake parameter to endpoint.bind() in zigbee-herdsman that only saves the binding to the database but not sends a request to the device.
  To avoid user confusion, this should also only be done if the device is "brand new", which would basically lead to similar issues as trying to bind it again for real.
• Query the device's bindings on joining and save them to the database.
  Would be more effort since it will need to be implemented inside the zigbee-herdsman adapters (but on the other hand it should not really be more effort than getting active endpoints or the simple descriptor). Would probably be the cleanest and most generic way to do it.
• Another one just came to my mind: Add another property to the device definitions that defines the default bindings and use them to populate the database binds on joining.
  Seems also a pretty clean option and generic option and might be less effort (and less error-prone) than actually querying the devices.

@sjorge You could try that out by forcing the default binding again using pure MQTT syntax (not using the UI). And if that works out, you will have a fix for yourself already without any changes to the code ;-)

But I agree that it would be nicer to have the default bindings correctly represented in the UI (and database) automatically - so maybe we should wait until somebody else comes up with the same issue? And if not, we could still document the manual MQTT way (in case it does work)...

[sjorge]

@sjorge You could try that out by forcing the default binding again using pure MQTT syntax (not using the UI). And if that works out, you will have a fix for yourself already without any changes to the code ;-)

You get an error back, I forgot which one exactly but basically it complains you can't bind because it was already bound IIRC.

Still doesn't solve the problem that the new frontend can't handle it. I mean just using straight up mqtt to unbind and then bind the one I want works fine, which is what I did before the frontend and did with the latest set because the frontend couldn't be used. The manual way is already documented btw.

But I still think this information should end up in the database.

Query the device's bindings on joining and save them to the database.
Would be more effort since it will need to be implemented inside the zigbee-herdsman adapters (but on the other hand it should not really be more effort than getting active endpoints or the simple descriptor). Would probably be the cleanest and most generic way to do it.

Seems like a pretty nice way to go about it, this should also work for other devices that have default bindings setup!

Another one just came to my mind: Add another property to the device definitions that defines the default bindings and use them to populate the database binds on joining.
Seems also a pretty clean option and generic option and might be less effort (and less error-prone) than actually querying the devices.

Would probable indeed be easier, but discovering it automatically is probably better in the long run.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[sjorge]

Did we ever decide on how to best get this info added?

[Koenkk]

I think this fits best in the configure (and not bumping the configureKey) which calls a new method addBinding() that adds the binding to this._binds.

[sjorge]

I think this fits best in the configure (and not bumping the configureKey) which calls a new method addBinding() that adds the binding to this._binds.

I was stubbing out where I would need to make changes, I don't think configure is really going to work. If we ever do bump the configure key... the bind will get re-added. I wonder if there is a way to use the onEvent hook and detect the device is in the interviewing stage, it should be safe to add the binds then. As they get reset to the default when the device is reset.

Meanwhile I'll finish adding the new addBinding(), well try at least.

[sjorge]

Did some of the prep work for addBinding() here https://github.com/Koenkk/zigbee-herdsman/pull/256, but not sure it's ready yet as I was unable to do a real world test.

[sjorge]

Looking promising using onEvent as the device object has the info for interviewing!

Edit: I got it working, time to clean up the code! It's easier than I thought as there is even a nice deviceInterviewing event that only fires ones! So that even eliminated multi addBinding calls during other 'message' events during the interviewing <3

[felixstorm]

I'll update the converters for the other ubisys devices as soon as https://github.com/Koenkk/zigbee-herdsman/pull/256 has been released since most of the devices I only have in my "production" environment and therefore it's a lot easier for me to just edit devices.js instead trying to pull the dev build of zigbee-herdsman into my HA add-on :wink: