›
This is the forum archive of Homey. For more information about Homey, visit the Official Homey website.

The Homey Community has been moved to https://community.athom.com.

This forum is now read-only for archive purposes.
Closed

Bindings between 'friendly' z-wave names/values and byte values

mderumderu Member
in Archive
I just finished the Devolo Home Connect Radiator Thermostat driver for Homey.

I used a lot of examples, existing drivers and trail-error to make it. Main reason was available documentation, or lack of it.

In the Sigma docs you can find all the details and byte values (http://z-wave.sigmadesigns.com/wp-content/uploads/2016/08/SDS12657-12-Z-Wave-Command-Class-Specification-A-M.pdf and http://z-wave.sigmadesigns.com/wp-content/uploads/2016/08/SDS12652-13-Z-Wave-Command-Class-Specification-N-Z.pdf).

For me however, it is completely unclear how to know when to use 'Properties1' or 'Level'. And why for instance 'Heating 1' is not 'Heating #1'. See the example below:

command_get_parser: () => {
return {
'Level': {
'Setpoint Type': 'Heating 1',
}
};
},

Can anyone please help me with the Homey specific documentation regarding these binding so I can speed up my driver development?

Comments

  • casedacaseda Member
    edited October 2016
    there is no documentation about when it is properties, and when it is level,
    it is just these 2 so you can just do trial and error,
    you will get an error message in the CLI:
    missing object/number/string ["NAME"]
    where NAME is either level, or properties, or any other information a module would like before even giving/setting any information.

    the "Heating 1" is a bit more difficult thing, and you need to look at how the Command Class is implemented by athom (not documented yet)
    you can use a raw information buffer/hexadecimal value and see what the module gives you back in information in the report.
    IE: "Level": <Buffer 01> for "Level": { "Setpoint Type": "Heating 1" }

    there is an "easier" way of finding it all... but you will need a Z-Wave sniffer, and those are
    1 not cheap
    2 not getable without Signing a NDA
  • mderumderu Member
    Thanks @caseda for the raw information buffer suggestion. If I understand correctly that means I can just use the documentation of Sigma in the mean time. That will indeed make life easier until we have documentation between the buffer - Homey naming.
  • casedacaseda Member
    With the buffer values you can indeed use the documentation of sigma's values,

    homey will convert these values to the proper "Setpoint Type": "Heating 1" when it reports back (after receiving information from the module)
    so it will just need the initial first get command to be buffer, after that you can change it to what homey gives you in report.
    and use that in the GET/SET commands
  • EmileEmile Administrator, Athom
    I've contacted Sigma Designs (the company behind Z-Wave) if we're free to distribute the internal files we base the API on. In the meantime, I've found this file for you: https://raw.githubusercontent.com/Z-Wave-Me/ExpertUI/master/storage/data/ZWave_cmd_classes.xml

    Homey generates it's API based on a similar file (maybe different version). So all properties can be found there.

    If Sigma Designs reports back positively, I'll release our own JSON files that describe the API as well. Should make it a lot easier :-)

  • mderumderu Member
    Thanks a lot @Emile, I'll definitely take a look at it.
    Curious to hear what Sigma says also!
    Cheers, have a great weekend. 
This discussion has been closed.