Zwave detects things that are manually configured

sipvoip · July 17, 2017, 5:17pm

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

jcustenborder · July 17, 2017, 5:20pm

@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.

sipvoip · July 17, 2017, 5:21pm

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.

jcustenborder · July 17, 2017, 5:25pm

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.

chris · July 17, 2017, 5:26pm

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.

oppo1967p · August 31, 2017, 1:05pm

Hi @chris,
has this feature been released to the production version? If so, since which version?
thanks

chris · August 31, 2017, 1:21pm

Sorry - what feature do you mean? If you mean manual thing configuration via text files, then no, this isn’t in the production version.

oppo1967p · August 31, 2017, 1:37pm

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?

chris · August 31, 2017, 1:56pm

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.

oppo1967p · August 31, 2017, 2:05pm

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?

chris · August 31, 2017, 2:51pm

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.

oppo1967p · August 31, 2017, 3:30pm

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?

chris · August 31, 2017, 4:34pm

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?

oppo1967p · September 1, 2017, 8:43am

Hi @chris ,
yes it makes sense.

Any idea when it will be merged?

shorty707 · October 8, 2017, 7:09am

hey - since

github.com/eclipse-archived/smarthome

Introduce a differentiation between handler and device configuration

opened 11:24AM - 18 May 17 UTC

kaikreuzer

enhancement Core

Currently, the config descriptions on Things are meant to define what configurat…ion a handler requires in order to access and use a device. It is a common misconception that those configurations should represent the configuration of a remote device itself. Device configuration management is clearly a need for many (not externally managed) device bindings, though. This issue is meant as a follow-up on the discussion at https://www.eclipse.org/forums/index.php?t=msg&th=1079343 and https://github.com/eclipse/smarthome/pull/3245.

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

chris · October 8, 2017, 8:40am

Yes, unfortunately that’s correct.

oppo1967p · December 5, 2017, 9:34pm

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

chris · December 5, 2017, 11:06pm

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…

oppo1967p · December 6, 2017, 10:01am

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

chris · December 6, 2017, 10:12am

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.