openhab/org.openhab.binding.zigbee

Trying to make things easier

pmknowles opened this issue · 9 comments

pmknowles commented

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 commented
pmknowles commented

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 commented

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 commented

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 commented

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 commented
cdjackson commented

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 commented
cdjackson commented