I bought a Miniplug AN181 from Everspring. Upon inclusion I get errors, see below. On Openhab 3.3.0
Would this error go away if 1 is also defined as a valid option in the source code, see below?
And - how can I install the z-wave binding from source code, overriding the debian package installation? I am fluent in some other languages but not Java.
HANDLER_CONFIGURATION_PENDING
{config_4_2=Der Wert 1 ist nicht in den erlaubten Optionen enthalten. Erlaubte Optionen sind:
[ParameterOption [value="0", label="Does not report automatically"]],
config_5_2=Der Wert 60 ist nicht in den erlaubten Optionen enthalten. Erlaubte Optionen sind:
[ParameterOption [value="0", label="Does not report automatically"]]}
Translation: The value 1 is not one of the allowed options
The source code says:
<parameter name="config_4_2" type="integer" groupName="configuration">
<label>4: Interval for wattage auto report</label>
<description>Set the interval for wattage auto report in minutes</description>
<default>1</default>
<options>
<option value="0">Does not report automatically</option>
</options>
</parameter>
The limitToOptions needs to be set to false in the database.
You can find the database here -:
You don’t need to install from source - this is not easy. You can simply install the snapshot binding directly into the addons folder after uninstalling it in the UI.
It’s not a bug as such. As I said above, the database configuration simply needs to change to remove the restriction that only the options can be set.
They are not daily - normally once or twice a week as there is a manual process to check that the changes made are acceptable and approve them for release.
Only if these are the only options possible. If other options can be set, as I think is the case here, then you cant set 200 options…
the diff shows a LOT of structural changes, at first glance without changing semantics. Like “commandclasses” being renamed to “commandclass”. Obviously the JSON definition changed, and diff compares the old JSON format with the current JSON format. Would it be possible to convert all database entries into the new format with one big commit such that a diff like mine today will only show relevant changes? Or do that on-the-fly before diffing? Maybe do that right after every format change. I am sure that could be automatized.
this seems especially helpful to me since the development cycle (edit-test-edit-test) is so long - as you said it might take up to a week until I can test my changes. Is there really no way to make and test changes locally? Like defining a JSON file in /etc overriding the database entry?
I changed the obvious entries param 4,5,6,7 (Database entry 306). Maybe more should be changed, maybe less changes are needed to get my specific device with the specific openhab version running
everspring has a new version of the PDF reference. At first glance I cannot see semantic changes, just a lot of formatting changes. How to proceed here? everspring download
I’m not really sure what diff you are talking about? Do you mean the github files? These are XML exported from the database.
You would really need to set up a development system. It is also possible to edit files within the JAR if you want to try that, but it is a bit error prone.
Unfortunately openHAB doesn’t support this sort of thing.
You’d need to compare the files to see if there are changes to parameter configuration. If there is then a new database entry needs to be created for the new version.
This post is dated (based on OH2) and is for a device that has user defined channels, however, the general process to setting up a development testing environment is outlined. I use the github desktop with a Z-wave binding fork and VSC on a windows machine with maven to compile test jars. This method can handle XML changes and java code changes.
Another post, also dated (OH2) outlines a jar update process if only XML changes are needed. I have used this in the past on both a windows machine and my Pi. For a recent use look towards the end of (June 1 2022) this post.
Obviously after you finish local testing the device DB needs to reflect your changes or the whole system breaks down.
One more Quirk. After you edit the DB (and are satisfied with the changes) you need to “Request Review” on the Overview tab or the device will be deleted from the snapshot. I noticed this device was deleted from the pending DB update #1790.
I’m just reporting the fact. (I’m surprised you did not know that). Although the docs are clear, it is occasionally missed by new DB editors. I also do not know what would be required to implement your idea. It seems there would have to be two versions retained (unmodified & modified-not approved) for some time and some logic on the extraction process that updates the binding.
Yes, it should, but it’s not that easy. In the past (ie the old database) we did this, and that caused a load of other problems, so now we have this instead - it causes it’s own issues and upsets a different group of people.
I appreciate it’s not ideal, but that’s how it is - sorry.
Yeah, I would think it’s non-trivial to do. I don’t have an issue with it the way it is. I was just surprised it worked that way.
Ok, then that must be what I was remembering. I haven’t done much editing using the new DB. Most all the devices I’m using are in the database already (thanks to the hard work of many others).
