Zwave detects things that are manually configured

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. :slight_smile:

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. :slight_smile:

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?

1 Like

Hi @chris ,
yes it makes sense.

Any idea when it will be merged?

hey - since


is still Open - I guess manually created zwave things still dont support config parameter changes?

Yes, unfortunately that’s correct.

Hi @chris,
any plan to release the .things textual configuration into the masters?
Maybe into 2.2?

It certainly won’t be merged into 2.2 - I won’t be making any further changes other than database updates before 2.2 is released. I might look at this after the 2.2 release…

Hi @chris,
It’s a shame that one of the most important bindings does not support textual configuration (and therefore is not fully compliant with OH guidelines).
Actually, if I am not wrong, it’s the only binding that does not support full textual configuration.

If I may, please reconsider your schedule and apply this change into master as earliest as possible.

thanks for your work

1 Like

I’ve already said that I will not merge it into 2.2 - sorry, but I won’t change this as the timescale is too short and if there are any problems there will be no time to resolve them. As said, I will look at it after the 2.2 release.