Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Trying to make things easier #784

Open
pmknowles opened this issue Oct 27, 2022 · 9 comments
Open

Trying to make things easier #784

pmknowles opened this issue Oct 27, 2022 · 9 comments

Comments

@pmknowles
Copy link

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
Copy link
Contributor

cdjackson commented Oct 27, 2022 via email

@pmknowles
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

pmknowles commented Oct 27, 2022 via email

@cdjackson
Copy link
Contributor

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
Copy link
Author

pmknowles commented Oct 28, 2022 via email

@cdjackson
Copy link
Contributor

cdjackson commented Oct 28, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@cdjackson @pmknowles