I have been searching for the whole afternoon for the syntax of ZWAVE .things OH2 file with no success.
I have tried the following:
Bridge zwave:serial_zstick:controller [ port="/dev/ttyACM0" controller_softreset="false" controller_master="true" security_networkkey="00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF"]
Thing zwave:device:controller:node3 (zwave:serial_zstick:controller) [ zwave_nodeid="3" ]
But had no success: meaning that the BRIDGE works, but the THING is discovered but remains in INITIALIZING state forever.
If I add the THING using PAPER UI it works, so it must be something with the syntax of the .things file.
The same configuration was working perfectly with OH1.
If I remember and interpreted @chris’s comments on a different thread correctly, I don’t think the OH 2 Zwave binding supports defining your own Things in a .things file. I could be wrong, I often am when it comes to zwave.
Just be aware that you are not required to use the 2.0 version of the zwave binding in OH 2. You can happily run with the 1.9 SNAPSHOT. You may need to enable the “Include Legacy 1.x Bindings” in Configurations-> System -> Extension Management in PaperUI it to show up in the list if you don’t see it.
Beyond the consistency of being able to use text files for Things, what is the benefit/capability that pushes you to need to define them by hand?
In my admittedly limited experience, if the zwave 2.0 binding can’t autodiscover the Thing and initialize it, it isn’t going to work anyway. Its the same as in OH 1.x when the binding doesn’t produce the node.xml file.
yes, that’s another way. And it works.
But it does not answer the original question.
In other words, I would like to know what is the syntax for the .things files for the zwave binding.
This could help others to build their system with text files if they want to.
As reported, Kay is confirming that configuring using text files is guaranteed to be working, so it’s just a question of understanding the syntax…
I have seen the syntax for linking items to channels somewhere, but can’t remember where right now, so that allows one more level of control from a text file.
Re: defining things and channels, I think this might be bit more difficult as the core data is from a zwave database that the binding is linked to. So unless you have all the info you need to define the channel etc, then this will be way more work than simply letting the system discover the thing.
@chris has done some work on developing an alternative storage option to mapDB that makes this data easier to look at , maybe edit, and backup. However we are still waiting for this to be added as an option for openHAB 2.
Text files can be used to configure the thing, but you won’t be able to configure the device. This means that you won’t be able to change any device parameters, associations, wakeup period etc. To me, this is quite a large issue, but I leave it to others to decide their individual needs.
The syntax is the same as any other binding - I can’t write this specifically for ZWave.
I need to try and find a way to add channel information into the documentation. I want to automatically generate this from the source otherwise it’s a nightmare to keep them consistent as there are a lot of channels in this binding.
You can however find the information on the channels, and their configuration, in this file. As above, the syntax itself is the standard syntax.
I did see a recent comment from Kai that indicated he was considering this, but yes, at the moment it’s not included. To me, this is a useful solution as I think it provides a good compromise between the utility of the UI configuration, and the ability to see what is in the database, edit it and copy it. Oh, and it’s significantly faster than mapDB as well!
Adding some other considerations.
It’s not true that the syntax of the .things file is the same as any other binding.
Every single binding has it’s own syntax.
Infact looking in the documentation section of openHAB2, there are THINGS definitions for many of the bindings (not for Zwave, thou).
So for example for the squeezebox server, it tells you that for the Bridge you should specify the ipaddress and the webport, while for the Thing you should specify the mac address:
So the question regarding the syntax of the THINGS file is what are the parameters that I should put inside the square brackets for configuring the Bridge and for the Thing?
I assume that only @Chris can answer this, as he’s the developer.
In the meantime I will test the suggestion made by Mark.
Can you give me an example please?
All bindings have different ways of writing the things file.
The overall syntax should be the same for every binding in OH2 - sure - channels and options etc will be different between bindings, but surely the overall syntax is the same?
Unfortunately I can’t give an example as I use the UI to configure the system - I’ve never used items files in OH2. Sorry. There is a thread somewhere on the forum that describes it though, but as I’m travelling I don’t have access.
As I said I don’t use this so I can’t provide any concrete examples. I do all my configuration through the UI due to the major limitations of the text files (i.e. not being able to configure devices, so you will need to find other software to do this). I provided the reference to the XML file that defines all the channels used by the system, and the options available. There are literally hundreds of devices, and dozens of channel types - I can’t provide documentation on all of this - sorry - I would spend my whole time writing documentation for devices.
As said earlier, there is a thread on the forum that describes the format from memory.
Not only considering - if it as as good as you claim, we will use it for sure. It’s just still on my to-do list to be reviewed and merged, sorry…
Not that the contribution guidelines ask for such an example and I think we have it on every binding with the exception of Z-Wave. So even if you are not using it yourself, I would strongly encourage to add textual configuration examples - this might be even helpful for yourself for testing, so that you might notice issues yourself, before the binding users stumble across it. And this thread here seems to indicate that such an example is strongly desired!