Trying to make things easier

[pmknowles]

I have several devices which ZigBee2MQTT recognises but the ZigBee binding doesn't seem to which is halting my move over to the binding. In ZigBee2MQTT there is a procedure to create and add your own 'converter'. The way they do it is to modify the yaml. However, in reality, the converter is very similar to how we add channels to Things in the MQTT binding. As long as the scan can see the device we can then add our own channels to the device (rather than having to rely on a central repository) - the interview generally would inform users what endpoints were available and it's just a matter of making sense of them. As users add and define the devices they could then upload the code from the channels building a resource which can then be combined into the releases. It might reduce the requests to support particular devices too. It's just an idea...

[cdjackson]

Im not completely sure what you are suggesting here, but the binding also has the ability to do a similar thing. The thing xml files provide some ability to define a thing and define certain functions.

However depending on the functionality required it may also require code changes since it’s obviously not possible that this sort of thing is defined in an xml or yaml etc file without code to support the required function.

Sent from my iPhone

On 28 Oct 2022, at 04:32, pmknowles @.***> wrote:

 I have several devices which ZigBee2MQTT recognises but the ZigBee binding doesn't seem to which is halting my move over to the binding. In ZigBee2MQTT there is a procedure to create and add your own 'converter'. The way they do it is to modify the yaml. However, in reality, the converter is very similar to how we add channels to Things in the MQTT binding. As long as the scan can see the device we can then add our own channels to the device (rather than having to rely on a central repository) - the interview generally would inform users what endpoints were available and it's just a matter of making sense of them. As users add and define the devices they could then upload the code from the channels building a resource which can then be combined into the releases. It might reduce the requests to support particular devices too. It's just an idea...

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[pmknowles]

I have a TRV which the binding sees but it says there are no end point clusters so it's unusable. It obviously has because it works on ZigBee2MQTT. MQTT Things have channels added to them by specifying what it is (switch for instance) and the relevant MQTT topic that goes with it. ZigBee has standard 'topics' which the devices use so it should be a matter of linking channels that openHAB understands to endpoints that ZigBee understands. This is the code for the MQTT input from ZigBee2MQTT for a TRV `channels:

• id: Bedroom2Set channelTypeUID: mqtt:number label: Bedroom 2 Set description: null configuration: commandTopic: zigbee2mqtt/Bedroom2R/set/current_heating_setpoint postCommand: true unit: '"C"' stateTopic: zigbee2mqtt/Bedroom2R transformationPattern: JSONPATH:$.current_heating_setpoint
• id: Bedroom2Open channelTypeUID: mqtt:number label: Berdoom 2 Open description: null configuration: stateTopic: zigbee2mqtt/Bedroom2R transformationPattern: JSONPATH:$.position postCommand: `false`` If I could do something similar I could create my own template for the TRV and, as new devices come on stream, users could create templates that we could add into our installations rather than waiting for an update (which might never come for some devices). It may be possible to do this already but there doesn't seem to be anything in the docs.

[cdjackson]

I have a TRV which the binding sees but it says there are no end point clusters so it's unusable.

This means there is no functionality the binding knows about, so there's no functionality it can provide to the user.

Without knowing the device, it's impossible for me to comment, but probably it's not as simple as just defining an XML file (or any other sort of file).

I certainly won't be adding a new yaml format if that's what you're suggesting here? It might be possible to do something with the current definition, but without more information it's impossible for me to comment further. You say it's "a TRV" - but WHAT TRV? And what clusters etc does it support?

[pmknowles]

https://www.zigbee2mqtt.io/devices/TS0601_thermostat.html#tuya-ts0601_thermostat It comes up with 15 properties but no end points zigbee_logicaltype END_DEVICE zigbee_powerlevel FULL zigbee_manufacturercode 0x1002 modelId TS0601 zigbee_networkaddress 18135 zigbee_powersource MAINS zigbee_datecode zigbee_stkversion 0 zigbee_zclversion 3 vendor _TZE200_cwnjrr72 zigbee_powermode RECEIVER_ON_IDLE zigbee_powersources [MAINS] hardwareVersion 1 zigbee_applicationVersion 87 zigbee_device_initialised true I'm not saying yaml - that's just what ZigBee2MQTT uses.

[cdjackson]

Ok, so this probably isn't a zigbee device - ie it's not using the cluster library that allows devices to communicate in a standard way. These sort of devices require custom code to manage them - z2mqtt already has this for these devices where the binding doesn't. Some of these devices have been added already, but it will require code to support, or a much more complex definition file to allow the various bits to be extracted.

[pmknowles]

Which is where I came in. A lot of the hard work has been done in Home Assistant and ZigBee2MQTT. When the device is interviewed it must give a list of its endpoints (whether the binding understands them or not). In openHAB we have a list of channel types (like dimmer and rollershutter). The TRV needs a setpoint if I could ‘link’ the setpoint to, say, a rollershutter (with a transformation to shift the 0-100 to 5-35) so it tells the TRV what setpoint it needs there’s no need for writing special code for every device. The same goes for auto/manual – it’s a switch as far as openHAB is concerned – temperature is a number. We sort of already do that when we add a channel with the radio buttons for type – we just don’t have the ZigBee endpoints to link to. Often we will end up ignoring endpoints we don’t need or use. I’m not saying it’s easy but a structure like that might make expansion easier in the future

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows

From: Chris @.> Sent: 27 October 2022 19:53 To: @.> Cc: @.>; @.> Subject: Re: [openhab/org.openhab.binding.zigbee] Trying to make things easier (Issue #784)

Ok, so this probably isn't a zigbee device - ie it's not using the cluster library that allows devices to communicate in a standard way. These sort of devices require custom code to manage them - z2mqtt already has this for these devices where the binding doesn't. Some of these devices have been added already, but it will require code to support, or a much more complex definition file to allow the various bits to be extracted.

— Reply to this email directly, view it on GitHubhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenhab%2Forg.openhab.binding.zigbee%2Fissues%2F784%23issuecomment-1293935119&data=05%7C01%7C%7Ca0e5ce858f6046f86de008dab84c7de5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638024935911577533%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6AtnvNJFUgFoHXVLXAfP88mXknSsiG57pzVUdPNg98E%3D&reserved=0, or unsubscribehttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAI5KPM7BS554TYRS3MLYLNLWFLFRLANCNFSM6AAAAAARQGBKLY&data=05%7C01%7C%7Ca0e5ce858f6046f86de008dab84c7de5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638024935911577533%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=40Rgy%2BkS4pkiRFimoac%2B7cUsv7zbGMXwrk7dZlszL6U%3D&reserved=0. You are receiving this because you authored the thread.Message ID: @.***>

[cdjackson]

The interview retrieves the list of endpoints - sure - but thats the thin end of the wedge. On top of this is also interviews the clusters, and from there the attributes/channels.

When a device doesn't follow ANY standards at the application level, it generally requires custom code to support. The binding has a kind of description language like you suggest, but it is designed to support custom attributes for devices that follow this paradigm. IT could of course be extended, and if you want to provide a PR, then I'm certainly happy to take a look at it. The underlying libraries provide all the information from the interview, and you can of course get access to this.

This sort of description is not something I would personally look to add as for it to be truely universal it would require a LOT of work. I don't believe this is done in zigbee2mqtt either - they have (I believe) a split functionality system where parts are written in code, and parts are then defined by the user. That is what is done here at the moment, but it does require code updates to support more of these non-standard functions from Tuya which are simply not zigbee.

[pmknowles]

So does openHAB store the result of the device interview somewhere? It would be useful to compare with what I can see in ZigBee2MQTT’s logs.

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows

From: Chris @.> Sent: 27 October 2022 22:08 To: @.> Cc: @.>; @.> Subject: Re: [openhab/org.openhab.binding.zigbee] Trying to make things easier (Issue #784)

The interview retrieves the list of endpoints - sure - but thats the thin end of the wedge. On top of this is also interviews the clusters, and from there the attributes/channels.

When a device doesn't follow ANY standards at the application level, it generally requires custom code to support. The binding has a kind of description language like you suggest, but it is designed to support custom attributes for devices that follow this paradigm. IT could of course be extended, and if you want to provide a PR, then I'm certainly happy to take a look at it. The underlying libraries provide all the information from the interview, and you can of course get access to this.

This sort of description is not something I would personally look to add as for it to be truely universal it would require a LOT of work. I don't believe this is done in zigbee2mqtt either - they have (I believe) a split functionality system where parts are written in code, and parts are then defined by the user. That is what is done here at the moment, but it does require code updates to support more of these non-standard functions from Tuya which are simply not zigbee.

— Reply to this email directly, view it on GitHubhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenhab%2Forg.openhab.binding.zigbee%2Fissues%2F784%23issuecomment-1294063344&data=05%7C01%7C%7C344c95fd11c8478b212808dab85f620b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638025017043033807%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2xb2xeFd1v2jsKNi6Rh5aH%2FQmSjO1e4ihdTSkVvuwVc%3D&reserved=0, or unsubscribehttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAI5KPM45QARZBDZSQOZLJELWFLVMNANCNFSM6AAAAAARQGBKLY&data=05%7C01%7C%7C344c95fd11c8478b212808dab85f620b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638025017043033807%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RJZmyxhtEGMK1TE91NksOdyPSaxV3QM2qIbQwQ4CPEk%3D&reserved=0. You are receiving this because you authored the thread.Message ID: @.***>

[cdjackson]

Yes, but the interview probably won’t find much if the device is not using standard functionality.

In any case you can find the xml files in the user data folder.

Sent from my iPhone

On 28 Oct 2022, at 19:54, pmknowles @.***> wrote:

 So does openHAB store the result of the device interview somewhere? It would be useful to compare with what I can see in ZigBee2MQTT’s logs.

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows

From: Chris @.> Sent: 27 October 2022 22:08 To: @.> Cc: @.>; @.> Subject: Re: [openhab/org.openhab.binding.zigbee] Trying to make things easier (Issue #784)

The interview retrieves the list of endpoints - sure - but thats the thin end of the wedge. On top of this is also interviews the clusters, and from there the attributes/channels.

When a device doesn't follow ANY standards at the application level, it generally requires custom code to support. The binding has a kind of description language like you suggest, but it is designed to support custom attributes for devices that follow this paradigm. IT could of course be extended, and if you want to provide a PR, then I'm certainly happy to take a look at it. The underlying libraries provide all the information from the interview, and you can of course get access to this.

This sort of description is not something I would personally look to add as for it to be truely universal it would require a LOT of work. I don't believe this is done in zigbee2mqtt either - they have (I believe) a split functionality system where parts are written in code, and parts are then defined by the user. That is what is done here at the moment, but it does require code updates to support more of these non-standard functions from Tuya which are simply not zigbee.

— Reply to this email directly, view it on GitHubhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenhab%2Forg.openhab.binding.zigbee%2Fissues%2F784%23issuecomment-1294063344&data=05%7C01%7C%7C344c95fd11c8478b212808dab85f620b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638025017043033807%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2xb2xeFd1v2jsKNi6Rh5aH%2FQmSjO1e4ihdTSkVvuwVc%3D&reserved=0, or unsubscribehttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAI5KPM45QARZBDZSQOZLJELWFLVMNANCNFSM6AAAAAARQGBKLY&data=05%7C01%7C%7C344c95fd11c8478b212808dab85f620b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638025017043033807%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RJZmyxhtEGMK1TE91NksOdyPSaxV3QM2qIbQwQ4CPEk%3D&reserved=0. You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.