I have in parallel to my many Homematic devices started to deploy some zwave devices to my home.
They work fine so far, mainly because I did find helpful information in this thread:
But this raises the question to me (to understand the topic more deeper). Where do I find the endPointIds mentionen in these item descriptions normally? I have to Fibaro devices and in their manuals, I do not see any information about this.
The RGBW actor for instance, endPoint 2 seems to be for Red, 3 for Green etc… But where do I find those information? Is there some kind of reference somewhere? Or did I overlook these information in habmin?
You’ve stumbled upon one of the more difficult parts of ZWave. Unfortunately, this isn’t generally documented in manufacturer documentation (although sometimes it is) and there’s no good resource for this…
Generally, zwave systems would be expected to derive part of this from the device discovery process, however due to the manual nature of openHAB-1, this isn’t automated. There is the XML files that are produced by the binding (in the /etc/zwave folder) which stores the result of the bindings discovery process. In here, you can find out what endpoints are supported by looking in the MULTI_INSTANCE class.
However, this is still only half the story - the XML will tell you that there are a certain number of endpoints, and that they support certain classes, however it won’t tell you that endpoint 2 is red, endpoint 3 is green (or whatever) - that you need to do for yourself, or look in the forum (as you’ve done ). This is all part of the OH1 fun experience (or not!)
In the OH2 binding, this will be simplified. Here we put more information in the database, and once this information is derived, it will be available for all and you won’t need to guess. Devices will be automatically discovered and items etc generated for you…
But that’s all for the (near) future - for now you’ll need to work it out for yourself, or ask on here…
Z-wave has done a decent job of enforcing devices to talk to each other. What they haven’t done is a good job of a minimum documentation set criteria, or how things are programmed. Some registers are in hex, some are not, and if the vendor does not tell you, it is trial and error, if they even tell you what the registers are.
Completely agree - I wonder if this comes from their closed source policy. A lot of (older) documentation provided very little information on configuration - it’s better now for config parameters at least, but still not brilliant… Maybe if you pay the big bucks and get the license, you get access to a nice device database that gives this info…
I guess you’re talking about the documentation is in hex, not the registers themselves
How about this way: The documentation may as well be in HEX
I have a device (not recalling exactly which) that when I went through the doc for it, some of the configuration values were boolean, some were in HEX and some were decimal. It made creating the DB entry a royal pain though.
I think in OH2 we should make this easier - I’ve added multiselect options so we don’t need to do all this binary/hex to decimal math when you want to combine options - well - at least that’s the hope!