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.
Ok - strange, but without a log it’s impossible to say what’s happening. All I can say is that the 7FFF indicates that the device hasn’t yet been initialised. There are two phases where devices are added to the inbox - the first one will show this value (before initialisation), and the next one (after initialisation) should show the right value.
Well, it was too long to be posted on board.
Ok, I prepared 10 minutes long log with TRACE on weighting 15MB. Please look at event on
22:16:27.812, NODE 28: Command received zwave:device:controller:node28:switch_binary --> ON
then at the same second, few lines below
Start transaction timer to Fri Feb 03 22:16:43 CET 2017 - 15369ms
and finally after 15 seconds the lamp finally goes on at:
22:16:43.269 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 28: SendData Request. CallBack ID = 77, Status = Transmission complete and ACK received(0)
It doesn’t seem to download in the browser - can you zip it and email it to me (chris -at- cd-jackson.com).
As I said above, there are some transactions during initialisation that have longer timeouts so this is fine in itself - the question is what is happening around this…
Thanks.
I have sent the log as requested.
How long this initialization takes place? My network has ca 40 nodes. Maybe I am just not patient enough 
Kind regards,
Jj
@Chris, I’m getting a parse error on the xml (door lock, idl 101) I’m trying to upload/update the device list. The already existing entry in the device list has no channels assigned and is not approved. Can the device list accept xml’s from dev-branch of the binding? Also the manufacturer id 0230 is registered as “Alphonsus”, but I am pretty sure it should be named ID Lock (website: www.idlock.no). Thanks!
It will take a little while first time up as it will need to reinitialise every node… Let’s see - the initialisation has changed quite a bit in the new code so it’s quite possible that there’s a bug in there…
Can you mail me the XML (or post here).
I currently use the official manufacturer names registered with ZWave - some of them are ‘different’ than expected…
Just mailed you the xml. Thanks for checking it out!