If there isn’t more than my expectation of a single door opener model that happens to use an overloaded byte as a state for all communication then I guess I wouldn’t worry too much about appeasement.
Most of my expectation was set by a one pic that supposedly was working but it was an older model from an openhab 1.x binding showing all those channels.
Long/short… don’t let my misunderstanding make work for you. I can make it work for me as-is. I’m sure you have bigger fish to fry. If I get to feeling punchy maybe I’ll take a stab at understanding the code well enough to try it myself.
Just confirming that these steps work perfectly for my Danalock V3, except that the Zensys controller didn’t let me change its security (a “resmissing received” error??) so instead I copied the Zensys security code into Habmin.
I sometimes get this too, but it usually works fine on the second try. The first time I tried putting in the key, I couldn’t get it to work at all. There seemed to be a trick to pasting it in… when pasting, delete the 00 and leave the whitespace at the end. Shutting the app down, pulling the stick, and starting over helps too, for a lot of things. Zensys Tools definitely has some bugs!
I guess, have not had chance yet? Or did try to, but no luck? Nevertheless, I have some news. Got little longer time to play around today … out of curiosity inserted home assistant hass.io sd card into raspberry. Z-Wave controller stayed plugged in, untouched. Hass booted up, configured ZWave port and there were both binary sensors channels - reacting/showing the trigger state. Was little jealous, thought of coming back and asking if I can steal the debug info somehow so it would help.
So did insert back the old openhab card, booted it up. And getting both binary1 and binary2 events. No other changes done on openhab. Have had it restarted with system:shutdown numerous times.
And it is even not with the most-most recent debug versions (since I had it ‘downgraded’ last week)
219 | Active | 80 | 2.2.0.201711192127 | ZWave Binding
So sorry for our hours spent trying to fix it. and confused what has changed, why it’s working now
Sorry - I didn’t get a chance to look at this over the weekend as I had to finish some work on ZigBee… I did buy some plugs to allow me to configure a better test system, so I’m in a position to test again…
Do you have a log of the initialisation after you restarted? It’s possible that the home assistant has configured the device and that’s why it’s now working. It would be good if you could delete the XML and restart the binding and send the log - OH might change the configuration back, but I should be able to see how it was configured before it does!
Somehow the device didn’t reinitialise. If you’ve done things in the order you state it won’t work as the XML file is saved when the binding stops. So, you need to stop the binding, switch on debug, delete the XML, then start the binding.
Hey guys -
I’ve been running OH2 with the zwave binding 2.1.0.201705102317 since the summer, which per the post below (which is old, but so is my jar), was the zwave dev jar:
I upgraded to the jar from post #1 (now 2.2.0-SNAPSHOT) and removed the old jar.
But when I start OH2 I see this error:
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [213]
Another singleton bundle selected: osgi.identity; osgi.identity=“org.openhab.binding.zwave”; type=“osgi.bundle”; version:Version=“2.1.0.201705102317”; singleton:=“true”
at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
checking the version via ssh I see 2 versions, with the old apparently the active one
The file name of the jar changed, and you have the older version cached. There have been some updates to OH too, which may cause some trouble for older installs, but start here::
You will also want to delete your Things or xmls to get the database updates.
Thanks @Austris_V and @5iver , I was able to remove the old binding via ssh.
I then realized I needed to upgrade the main OH2 to 2.1 which I did. After that I was able to get the 2.2.0-SNAPSHOT jar from this thread to work.
I remembered that I deleted all my things the first time I upgraded. Seems like things are working so far.
but this makes the “you can configure your stuff through config files instead through the paperUi” useless, as soon as u need a single one of these params?
==> /var/log/openhab2/openhab.log <==
2017-11-29 21:38:41.300 [INFO ] [ome.io.rest.core.thing.ThingResource] - Received HTTP PUT request for update configuration at 'things/zwave:fibaro_fgms001_03_002:Razberry:node3/config' for an unmanaged thing 'zwave:fibaro_fgms001_03_002:Razberry:node3'.
No - you can configure “stuff” through both options, but not everything can be done like this. Some configuration is considered to be installation/administrative, and that is done manually.
Connecting channels to everything would make a confusing mess for users as there would be dozens of channels for every device.
If there are config channels that are user oriented, then we can add a channel.
hmm. im quite new to the openhab2 architecture with things link by channels to their items, so I can’t argue with you on that level
But as far as i tested, your theory that i can use both methods seems wrong:
I configured node3 via config file and tried to change one of the advanced params. The result is an error, which states OH2 can’t change this param because the thing is unmanaged.
Or do u mean I have to manage some items by configfile (the ones without the need to change options) and some others in the paperUI?
