Hard to believe, that such fundamental functionality, which was well supported in OH1, is still not available and not even designed. OH2 looks nice, but in my opinion it’s far away from a stable and easy to use system. Everything should be managed via UI(s), which results in klicking one or two hours in the Paper-UI for the configuration of more than 30 z-wave devices. And after this there are a lot of text file for defining site maps, persistences, maps or rules.
After spending so much time for setting up the system, there is no (official) possibility to make a backup (it’s not sure that restoring conf and userdata directories really work) or transfer a configuration to another system (e.g. when upgrading from Raspi2 with raspbian to a Raspi3 with DietPi).
I’m back to OH1, forget about using new z-wave devices like the FGS-223 and still have a look on OH2, how work is going on.
I really like the idea of version controlling all of my configuration. @sipvoip what version are you working with? I’m using openhab2-2.2.0.20170715040819-1.noarch and openhab2-addons-2.2.0.20170715040819-1.noarch but I’m not having too much luck. I’m seeing my zwave things discovered and I’m seeing the things I defined in paper. The ones I defined are stuck with INITIALIZING as their status. Is this things file heading in the right direction?
Bridge zwave:serial_zstick:controller "ZWave Controller" [ port="/dev/ttyACM0", controller_softreset="false", controller_master="true", controller_inclusiontimeout=60, heal_enable="true", heal_time=2, security_networkkey="D2 CF 58 21 07 4C 10 AA 29 22 25 55 CB 7F A1 B3"]
Thing zwave:aeon_zw100_00_000:controller:node3 "Z-Wave Node 3: ZW100 MultiSensor 6" (zwave:serial_zstick:controller) [ node_id=3 ] {
Channels:
Type sensor_binary : sensor_binary [ config_scale=1 ]
Type sensor_relhumidity : sensor_relhumidity [ config_scale=1 ]
Type sensor_ultraviolet : sensor_ultraviolet [ config_scale=1 ]
Type sensor_temperature : sensor_temperature [ config_scale=1 ]
Type sensor_luminance : sensor_luminance [ config_scale=1 ]
Type alarm_general : alarm_general [ config_scale=1 ]
Type battery-level : battery-level [ config_scale=1 ]
}
Thing zwave:ge_45606_00_000:controller:node4 "Z-Wave Node 4: 45606 2-Way Dimmer Switch" (zwave:serial_zstick:controller) [ node_id=4 ] {
Channels:
Type switch_dimmer : switch_dimmer [ config_scale=1 ]
}
Thing zwave:aeon_zw100_00_000:controller:node7 "Z-Wave Node 7: ZW100 MultiSensor 6" (zwave:serial_zstick:controller) [ node_id=7 ] {
Channels:
Type sensor_binary : sensor_binary [ config_scale=1 ]
Type sensor_relhumidity : sensor_relhumidity [ config_scale=1 ]
Type sensor_ultraviolet : sensor_ultraviolet [ config_scale=1 ]
Type sensor_temperature : sensor_temperature [ config_scale=1 ]
Type sensor_luminance : sensor_luminance [ config_scale=1 ]
Type alarm_general : alarm_general [ config_scale=1 ]
Type battery-level : battery-level [ config_scale=1 ]
}
I am working with 2.2.0-SNAPSHOT Build #986 and a pull from yesterday for
the zwave binding.
<>
nathan stratton
Note that this version doesn’t allow things to be configured manually. Only the development version has this functionality.
haha that makes more sense. Are there nightly generated rpms? If not what is the recommended steps for deploying the snapshots?
Sorry - snapshot versions don’t have this feature - only the bleeding edge development version -:
OK so meaning I need to download and build from github to get this functionality. I can do that. Thanks for the direction. What is the target release for this functionality?
What I do is:
service openhab2 stop
yum -y update openhab2
cd /user/share/openhab2/addons/
rm -f org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar
wget http://www.cd-jackson.com/downloads/openhab2/org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar
rm -f /var/log/openhab2/*
service openhab2 start
@sipvoip This is perfect. Now I see what I need. You’re using the latest snapshot RPM along with the latest output from the build @chris is working with. I’ll give this a shot.
Yep! Only thing bugging me is that paper also detects all the zwave things, I just ignore them since I like manual setup MUCH better.
I kinda cheat. I put together a python script that looks at jsondb/org.eclipse.smarthome.core.thing.Thing.json and generates a zwave.things file with the content I pasted above. I was trying to just go through and add them once via paper , then generate a things file. Later I just clean the contents of jsondb.
No - there is a prebuilt version linked at the top of the thread I linked above. I’d suggest to read the first 1/2 dozen messages or so in this thread to see how to install the binding.
Hi @chris,
has this feature been released to the production version? If so, since which version?
thanks
Sorry - what feature do you mean? If you mean manual thing configuration via text files, then no, this isn’t in the production version.
Hi @chris,
yes, I meant the manual ZWAVE thing configuration.
If I may ask, what is preventing the deployment of this change in the production version?
This change is currently in the development version, so it’s usable there if you want to use . This version is a very large change so it’s not easy to just migrate this single issue into the master version.
Hi @chris,
thanks for your reply.
Maybe a stupid question, but if the development jar version is working, why can’t it be distributed with the master version? The binding itself is a standalone file, isn’t it?
Do you have a forecast for merging it into the master version?
The development version is a breaking change version. It will require users to completely change the configuration and set the system up again. I want to avoid making people do this more than needed as it will be painful.
Hi @chris,
do you mean that this version will never go in production, or that you are just waiting for the test to complete?
Considering your concern, I suggest to merge it as earliest as possible because the bigger the user base, the higher will be the impact. 
what do think?
do you mean that this version will never go in production
No. Not at all. It will go into the master.
or that you are just waiting for the test to complete?
I mean that I want to ensure that I have all breaking changes in one version. I don’t want to merge a change that requires everyone to reinstall their system, then a few weeks later to do it again, and maybe again! It needs (hopefully!) to be done once.
Considering your concern, I suggest to merge it as earliest as possible because the bigger the user base, the higher will be the impact.
what do think?
As above - I don’t want to merge code the might cause people issues into the master branch - well - I will, but I only want to annoy everyone once. I’m currently looking at a few things and the possibility of a bit of restructuring to accommodate some later changes. Currently, if people want to use the development version to get new features like the text file configuration, or security, then they do so knowing that the code might change. I want to limit major changes on master branch.
I hope that makes sense?