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