Looks like the download link is down at the moment - I’m getting 503: Service Unavailable.
I uninstalled zwave binding and the zwave controller itself from things shutdown, moved the JAR, started service back up, and then installed the zwave controller back, set port then reinstalled the binding itself.
James. What do you mean when you say you re-installed the binding itself?
After you uninstall the existing binding from PaperUI or Habmin. Stop OH2 and then add the JAR file to your addons folder. That is all. You do not actually than re-install the binding, and that is likely causing a conflict.
And just in case the binding in the addon’s folder doesn’t start, look towards the top of the topic on how to log into Karaf and manually start it.
it wouldn’t work until I deleted the zwave controller from things
Deleted the binding from extensions
moved the jar into add ons and totally re added, set serial port and had to exclude and re add the lock many times.
Your still not correct. Follow these steps.
- Delete all Zwave Things from Habmin.
- Uninstall the Zwave binding from Habmin. - You will NOT reinstall it.
- Stop OH2
- Copy the JAR file to your /usr/share/openhab2/addons folder.
- Start OH2.
- log into Karaf ie… ssh openhab@localhost -p 8101 password is habopen
- Start the zwave binding with: bundle:start org.openhab.binding.zwave
- If get an error, you need to install the serial binding first: feature:install openhab-transport-serial
- Now got back to Habmin, and Readd a Zwave Controller. Do NOT re-install the 2.0 Zwave Binding.
- Set your USB port and rescan for devices.
9 Likes
it works now the way I did it, I am afraid to touch it and break it. lol
Yes, you have your zwave working. But are you showing it with a secure paired lock? That is the main purpose of this experimental binding.
yes secured, door unlocks, just no unlock status in openhab, so I don’t know if it is locked or not.
@chris - Thanks for looking. Should I see any attributes listed for the controller? My lock shows no attributes either when using this version of the binding. This is what I see:
Another thing I noticed is that whenever I try to add a symlink as the port, it fails with the port not found message but pointing it directly to the device works. The symlink is owned by the root user and group but has permissions to allow anyone to read/write/execute it.
@jaydee73 - I have and it seems to work. Unfortunately, I only have locks at the moment, so I cannot fully test functionality without the security features added.
ptmuldoon - I didn’t delete them at first but I ended up removing them and adding them after a restart.
you won’t see attributes for security on the zwave controller, just the added things like locks once they are successfully securely included
1 Like
just a few notes:
- removed all my things like you described
- my wallplugs FGWP101 all show ‘Node initialising: UPDATE_DATABASE’ for hours, but they work
- my aeontec DSD37 range extenders don’t get recognised, but they did in the ‘normal’ build
- everything else seems to work
- will you provide daily test-builds on your site?
- is your website down?
bye fonz
Hi Chris, thanks for the update.
My observations.
- Security communication works, I can confirm it for Danalock / Gerdalock. No need to re-include the lock, the old OH1.9 network security key worked.
- On Habmin, in the network layout tab, I see only the z-stick controller, no device nodes. With older version there was a whole network mesh.
- I noted that with the the responsiveness of nodes is really bad. It takes sometimes more than 20 seconds to switch on the lamp. I ran OH on a virtual server, so reverted to the snapshot with zwave 2.0.0 provided in kar with Release Distribution, and the response is instant. So I do not relate it to my platform (cpu <30% most of the time, zwave network works just fine with the older binding) Below the log from the transaction on node 42, switch was toggled off at 08:25:30.303 and the light went off at 08:25:52.008, nearly 22 seconds later. I noted that upon the switch toggle there was a timer created (Start transaction timer to Fri Feb 03 08:25:51 CET 2017 - 21663ms) which exactly matches the delay.
Is this an expected behavior?
Thanks for letting us test @chris!Great work! I was planning to upload xml for the idlock door lock, but I believe your website is down(?).
One thing:I also had problems with attributes not showing although the device was successfully included. Deleting thing and discover again fixed this. It took some time (several minutes) for the system to generate new xml for the door lock, fresh install with only two nodes.
If you have a debug log it would be good to see what’s happening.
I think these devices have no channels so the database wouldn’t let me export the config. I’ll sort this out but not quite top of the priority list…
Yes - maybe not daily, but as things are updated I’ll update the JAR.
Yes - we had a long power cut yesterday and my UPS only lasted a couple of hours. Unfortunately when things came back up this afternoon there was a corrupt disk so I’ve spent the last couple of hours recovering things 
. It seems RAID isn’t quite as tolerant to errors as I’d liked!
Should be up now.
No - I’d like to see the log. It likely means that there are timeouts. It might also be linked to startup since in the new code there are some transactions that have a long timeout - they should only happen during initialisation, but there could well be a bug here, or some condition that we’re not handling properly if a device is responding different that I expect…
Log should be accessible under the link in my previous post.
I also cannot add some Things, they are reported as Unknown Devices. Related log messeages, lots checks againts different devices and finally failure warning:
2017-02-03 21:39:37.400 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 52: Checking zwave:zwaveme_zme06437_00_000
2017-02-03 21:39:37.400 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 52: Checking zwave:zwaveme_zme06443_00_000
2017-02-03 21:39:37.400 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 52: Checking zwave:zwaveme_zme06443_00_000
2017-02-03 21:39:37.400 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 52: Checking zwave:zwaveme_zmeft_00_000
2017-02-03 21:39:37.400 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 52: Checking zwave:zwaveme_zmerc2_00_000
2017-02-03 21:39:37.400 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 52: Checking zwave:zwaveme_zweather_00_000
2017-02-03 21:39:37.400 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 52: Checking zwave:zyxel_st812_00_000
2017-02-03 21:39:37.400 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 52: Device discovery could not resolve to a thingType! 7FFFFFFF:7FFFFFFF:7FFFFFFF::0.0
After some time (hours) the missing data finally appears.
The 7FFF means that the device hasn’t initialised. I guess these are probably battery devices and they will take time to wake up and initialise - this is normal for battery devices.
True, but some of them are line powered, like Fibaro dimmers or binary sensors. I have not experienced such problems with 1.x, have been running great for over a year.
I will try to move the z-stick to another location to see if it helps. Need to move the VM to another box, much closer to the rest of the devices. Not sure if it will help, as one Fibaro binary sensor that is 4 feet away from the stick is causing the problems too.
The log is a bit short to see what’s happening.