I just migrated from OpenHAB1 to v2 as I had been growing too frustrated with the growing lag of OpenHAB 1. It was not the easiest thing to do, but I got mostly through it. I have however a few devices not working. Some are thermostats that I know had issues with v1.8.
On the other hand, I have a bunch of ZW500D In-wall Dimmer Switches that all work. I also have a single ZW500DM In-wall Smart Meter Dimmer Switch that worked perfectly under v1.8.
The Z-Wave binding sees it with the full name above. However in terms of the channels, it does not show a āDimmerā option. Only a switch option. Worse, even the switch channel has no effect.
Is the database mis-populated for this device? How can I help correct this? Can I override the database or get around it?
The database may be misconfigured. You can check here and verify the info for your device is correct. You can also request editing rights to correct the entry if it is wrong.
There really isnāt much you can do to get around it.
You will likely want to move to the 2.2 snapshot as well. Particularly if the DB looks correct on the website. It might be the case that the DB was fixed after the 2.1 release.
I have not worked on the database before. But comparing the entry for ZW500D and ZW500DM hints that the latter is probably incorrect.
In the D version, there is a line for SWITCH_MULTILEVEL where āBasicā and āUnSecā are ticked. This line is absent in the DM version. There, there is a line of āSWITCH_BINARYā where āBasicā, āNIFā and āUnSecā are ticked. The D version does not have the SWITCH_BINARY entry.
So I think the SWITCH_BINARY should be replaced with SWITCH_MULTILEVEL (itās a dimmer), but I donāt know if the āNIFā should be on or not. So I donāt think I would need to move to the 2.2 snapshot, as I think that until this is corrected, I wonāt get the correct behavior.
Isnāt there a way to force my installation to associate a different configuration for this āthingā on my system, rather than the one in the database? How does one debug entry changes otherwise? This is probably a very basic question, but I hope the answer is yes.
Correct, if the current DB is incorrect moving to 2.2 snapshot will not fix it now. However, once the DB is corrected, you will need to move at a minium the zwave binding to the 2.2 snapshot to pick up the changes.
No
Usually, the entry is populated based on the information provided in the deviceās manual and/or based on the XML you will find in /var/lib/openhab2/zwave (I think).
If the DB entry is wrong, as it appears, the only way to make it work will be to correct the DB.
Thanks for your quick response, Rich. I think that the impossibly of easily hacking into the entry used is rather contrary to the spirit of open-source software. OpenHAB is a complex system and my frustration with it as a developer is due to those kinds of decisions that make it very much an all or nothing black box.
I will submit a correction to the entry, but find it ridiculous that I will, if I understand correctly, have no way of making sure it will correct my issue.
The software is open source - so you can of course hack and compile a version of the code yourself. This is no problem - you can update the database files and create your own software - itās all open source .
To be a bit more detailed (anal) about it, one could want to just work on the database and never have to recompile another version. I must say I dread having to recompile the whole thing. A few months back, I tried to install all the eclipse stuff but it failed to install properly on my Mac and I gave up after a full weekend of frustration.
Iāll give it a try again.
Failure again. I must say my frustration is growing againā¦
Just the headline:
An error was detected while performing the engine operation and the changes are being rolled back. See the log for details.
ERROR: org.eclipse.equinox.p2.engine code=4 An error occurred while collecting items to be installed
ā¦
ERROR: org.eclipse.equinox.p2.engine code=0 session context was:(profile=_Users_michel_Development_SmartHome_OpenHAB2_openhab2-master_Eclipse.app_Contents_Eclipse, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
ERROR: org.eclipse.equinox.p2.artifact.repository code=0 Failed to transfer artifact canonical: osgi.bundle,org.eclipse.epp.mpc.help.ui,1.6.1.v20170817-1804.
ERROR: org.eclipse.equinox.p2.artifact.repository code=13 Retry another mirror
ERROR: org.eclipse.equinox.p2.transport.ecf code=1002 HTTP Server āService Unavailableā: http://mirror.switch.ch/eclipse/releases/oxygen/201709271000/plugins/org.eclipse.epp.mpc.help.ui_1.6.1.v20170817-1804.jar
ERROR: org.eclipse.ecf.identity code=0 HttpComponents connection error response code 503.
And then things seem to repeat forever.
PS I finally got it to download, but the build keeps two errors. Furthermore, I donāt even see the source of the Z-Wave binding. I see the zway one but not z-wave. This is the most difficult open source code Iāve ever tried to jump in. And right now I donāt even know what else to doā¦
Unfortunately the database exposes features in the binding so the two go hand in hand. Often when we add something to the database, we also have to change the binding. In any case, this is how ESH currently works so thereās limited options.
Your other option is to make the changes to the database, and it will update the binding, and just use that. Yes, the cycle is a day or two longer, but maybe itās easiest, maybe itās quicker if you canāt get the compiler working.
I was able to get the compiler working eventually yesterday. But donāt know
where the zwave bindings are. Are they separate on github? How do I
integrate them?
I run OpenHAB on a linux mini box and develop on a Mac. How do I transfer
the current setting files created by the Paper UI to the development
system, in particular whatās related to ZWave.
I finally got it working without touching the database.
I edited userdata/jsondb/org.eclipse.smarthome.core.thing.Thing.json and changed the entry for this device. I changed from āswitchā to ādimmerā wherever appropriate, and switch_binary into switch_dimmer. I also added a property (copied from a system-populated dimmer entry):
The measurement features of the device still donāt seem to be working, but at least I can control that light now.
Hopefully @Chris can correct the database entry so that all this is done automatically.
So it does indeed look like the device was probably added using a wrong XML or something. There are two options - remove the old one and add a new one, or just update the existing entry. If all the configuration is correctly defined, then Iāll remove all the endpoint definitions and you can upload a new XML file and that should resolve the issue. Please let me know if thatās the case?
When you say upload a new XML, I am not sure I know exactly what you mean. Is it the auto-generated one? In that case, is the one I uploaded on the dev site ticket not what you need?
Well, yes, probably (I didnāt look that closely to be honest). However it would really be appreciated if you could take the time to update the database. If everyone leaves it to me to do, I would spend my whole life working on the database. This is what happened in the past (for OH1) when people had to edit the XML files directly and produce PRs into Github, so I spent some time to produce an editor that anyone should be able to use (I know itās not the best UI in the world, but itās generally usable I think ).
If you want me to do it, then it will likely take longer as Iām quite busy at the moment - sorry for that.
I think Iāve done the necessary corrections. At least I think it should work as a dimmer. I will explore if I can get the measurement aspect to do something. Maybe it is a question of setting up the correct parameter for when the device should report?
Thanks. Iāve removed the swithc_binary and Iāll get this into the binding tonight hopefully. Once thatās done, Iād suggest to get a log of the sensor data and we can work out whatās up thereā¦
Quick update: I am getting wattage measurement after manually adding the items and restarting OpenHAB.
meter_kwh is showing, sensor_powerr and meter_kwh as well.
The last two seem to actually give almost the same number (0.01 difference. Not sure what the difference is between the two.
I am not getting the numbers to update actually. I saw that there is no auto-reporting by default, so I tried to change the parameters. However whenever trying to save them in the Paper UI, I get:
2017-10-14 14:59:42.210 [ERROR] [ome.io.rest.core.thing.ThingResource] - Exception during HTTP PUT request for update config at āthings/zwave:device:xxxx:node41/configā for thing āzwave:devicexxxx:node41ā: For input string: āorg.openhab.binding.zwave.internal.protocol.ZWaveAssociationGroup@yyyyā
Two questions:
Is there something I can fix?
Is there a way to force a poll of the values?
PS: I guess polling from a rule has been marked as against OH design in some other rule. How does one set a periodic polling in OH2 like it was possible with thermostats in OH1?
PPS: I was able to change the parameter for reporting in HABmin. I also put the association groups to include the openHAB controller. Now I get up to date power values a few seconds after changes to the dimmer level.
In openHAB 1, this particular device was one of the few whereby changing the level with the physical paddle would get reflected in the UI after a reasonably short time.
Could there be another association missing? Iāve sent all the existing one to the openHAB controller.
.
).