Well you are awesome - the HABmin reinitialisation fixed it. Thank you!
Ok, thanks. Iāll keep an eye on restarts and see if I continue to see this or if it happened to be a fluke thing or not. At this point honestly, it isnāt actually causing issues, it still seems to be loading despite the error seen. Will report back if I run into any issues.
Got it!
I havenāt found the reason. My gut says timeout and possibly related to missed events (which a new controller hasnāt fixed 
). I see lots of various timeouts in the log that might be related but thatās just a WAG. Like TIMEOUT_WAITING_FOR_CONTROLLER. But what I experience is that the devices donāt get stuck again after reinit. Sometimes Iāll have nodes marked dead, like after a battery dies and is replaced, and a reinit brings back. Yes, something is wrong and reinit is a bandaid, but it would be nice if the medicine cabinet wasnāt locked at times.
No. When theyāre stuck, they rarely get unstuck on their own. Usually a manual wakeup helps, but if not then the next step for me is a restart or reinit.
Curiousā¦ Iāll need to look into this further. After a startup, Habmin shows all of my devices go through Node Initialising stages.I havenāt noticed a difference in the logs between this and a reinit.
Are you running in a VM? Thatās the only way I could see you can miss events - unless the mesh is just not too good.
Yes, but it skips 95% of the initialisation and jumps straight to the dynamic stages - it doesnāt do all the time consuming static stuff - this gets read from the XML.
No, I run on a decent but older PC. Every room has at least one dimmer and OH1 didnāt have the issue, so I believe the mesh is OK. And it happens with devices that are neighbors with the controller.
I will study the logs next restart, and monitor for when the devices are getting hung in initialization.
Can you provide a log that shows the problem please. I find it very strange that the binding would miss events. Is it always a specific device, or certain type of device, or all devices, or???
I only notice it when the lights donāt come on or go off, so motion (WAPIRZ-1) or dimmer (VRMX1-1LZ) devices are definitely affected. I donāt think it is device specific. I have some older logs but will get some new ones and consolidate the info into a ticket for easier tracking.
I would try and work out if thereās any pattern. Eg certain types of commands. Find something repeatable - if itās not repeatable, then itās going to be very difficult to solve, and Iād also suspect that itās not the binding and would be more likely related to RF or other issuesā¦
Anyway, get the log of the miss handled events and Iāll take a lookā¦
Hi Chris,
I moved a bunch of old monoprice door/window sensors today and encountered a problem. It doesnāt update the status in openhab at all. I have new door/window sensors from monoprice and theyāre fine but those are zwave plus. The old ones that donāt work are just zwave. When I open/close the window there is a reaction from the binding. See the log below:
2017-07-01 16:36:12.908 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: Application Command Request (ALIVE:DONE)
2017-07-01 16:36:12.909 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 65: resetResendCount initComplete=true isDead=false
2017-07-01 16:36:12.911 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 65: Incoming command class COMMAND_CLASS_BASIC, endpoint 0
2017-07-01 16:36:12.912 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 65: SECURITY not supported
2017-07-01 16:36:12.913 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 65: Received COMMAND_CLASS_BASIC V1 BASIC_SET
2017-07-01 16:36:12.915 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 65: Basic report, value = 255
2017-07-01 16:36:12.917 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 65: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2017-07-01 16:36:12.918 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 65: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_BASIC, value = 255
2017-07-01 16:36:12.920 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: Commands processed 1.
2017-07-01 16:36:12.921 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@c9fc34.
2017-07-01 16:36:13.004 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: Application Command Request (ALIVE:DONE)
2017-07-01 16:36:13.007 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 65: resetResendCount initComplete=true isDead=false
2017-07-01 16:36:13.010 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 65: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2017-07-01 16:36:13.013 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 65: SECURITY not supported
2017-07-01 16:36:13.015 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 65: Received COMMAND_CLASS_ALARM V2 NOTIFICATION_REPORT
2017-07-01 16:36:13.016 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 65: NOTIFICATION report - 7 = 255, event=2, status=255, plen=0
2017-07-01 16:36:13.016 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 65: Alarm Type = BURGLAR (7)
2017-07-01 16:36:13.018 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 65: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2017-07-01 16:36:13.018 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 65: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2017-07-01 16:36:13.022 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: Commands processed 1.
2017-07-01 16:36:13.023 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@11b9620.
2017-07-01 16:36:14.778 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: Application Command Request (ALIVE:DONE)
2017-07-01 16:36:14.779 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 65: resetResendCount initComplete=true isDead=false
2017-07-01 16:36:14.780 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 65: Incoming command class COMMAND_CLASS_BASIC, endpoint 0
2017-07-01 16:36:14.781 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 65: SECURITY not supported
2017-07-01 16:36:14.782 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 65: Received COMMAND_CLASS_BASIC V1 BASIC_SET
2017-07-01 16:36:14.783 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 65: Basic report, value = 0
2017-07-01 16:36:14.785 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 65: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2017-07-01 16:36:14.786 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 65: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_BASIC, value = 0
2017-07-01 16:36:14.787 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: Commands processed 1.
2017-07-01 16:36:14.789 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1e7a6c2.
2017-07-01 16:36:14.994 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: Application Command Request (ALIVE:DONE)
2017-07-01 16:36:14.995 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 65: resetResendCount initComplete=true isDead=false
2017-07-01 16:36:14.997 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 65: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2017-07-01 16:36:14.999 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 65: SECURITY not supported
2017-07-01 16:36:15.000 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 65: Received COMMAND_CLASS_ALARM V2 NOTIFICATION_REPORT
2017-07-01 16:36:15.002 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 65: NOTIFICATION report - 7 = 0, event=2, status=255, plen=0
2017-07-01 16:36:15.004 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 65: Alarm Type = BURGLAR (7)
2017-07-01 16:36:15.007 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 65: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2017-07-01 16:36:15.008 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 65: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2017-07-01 16:36:15.013 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: Commands processed 1.
2017-07-01 16:36:15.015 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1711a50.
Okay I fixed it by modifying the binding to:
"binding:*:OpenClosedType": "COMMAND_CLASS_BASIC,COMMAND_CLASS_ALARM"
Originally it was:
"binding:*:OpenClosedType": "COMMAND_CLASS_ALARM;type\u003dACCESS_CONTROL"
It seems that the new Monoprice ZWave Plus Door/Window Sensor is detected as the old ZWave version but the binding is different. I looked in the XML under /var/lib/openhab2/zwave of both the new and old sensors and their type ids are identical. So I donāt think that we could automatically distinguish between them.
The device is sending BASIC commands, so it wonāt work without the ābasicā command class. Maybe this is a setting in the device - itās very unlikely itās related to zwave plus.
I have a problem with the FGBS001 Universal Binary Sensor, it fails too often with
NODE 56: Is currently marked as failed by the controller!
and the sensor readings are not transmitted reliably therefore. The failed node is not getting recovered by the binding. When it is ānot failedā, a ārefreshā in habmin gives me sometimes readings of the sensor, most of the times the node āfailsā again. I didnāt have this problem with the 2.1.0 release.
I noticed that if the sensor reading is changing, it does most of the time transmit one of the 2 sensor readings, the one that changed, but just to fail right away again. It just transmits the sensor reading not all the time.
@chris - going to chime in and add another vote for creating a separate channel for now to grab the info. If we can at least have the details available, we can always concatenate and create our own items that can be updated with both pieces of detail. In my case though, Iām just going to be using it in an alert/notification to indicate WHO is opening the door. So Iāll be looking for the Alarm Number to change to a specific # indicating a successful PIN entry unlock. Then in the body of the rule, look to simply grab the Alarm Level # to indicate who the user is.
Iām operating on similar model as @crimsondr - a Yale YRD240 (no key cylinder), runs the same as the YRD220 it seems just physically different. Happy to test whatever is needed, or input any needed info to the DB.
Downside to not having any type of descriptor system setup somewhere, is I donāt have an easy way to let OH reference which # pin code resolves to the name of the person, but thankfully I only have a handful. Basic idea of how iād use it is below. This is rudimentary, but hopefully helps paint the picture of itās usability. (I use a lambda function for the notifications hence the simplistic nature of the notification)
rule "Door PIN Notification"
when
Item door_alarm_number changed
then
{
switch(door_alarm_level.state){
case 1 : {notification.apply("bot1","Door unlocked by User1"}
case 2 : {notification.apply("bot1","Door unlocked by User2"}
case 3 : {notification.apply("bot1","Door unlocked by User3"}
}
}
As mentioned already, this version handles the offline state differently than the master version. It uses the controller to decide the node state but the controller reports offline too often so I will change this back when I get a chance.
The reason Iām hesitant to use separate channels for this sort of thing is you then need to correlate the information from different channels, and this is likely to be unreliable. If you have 2 channels - one with the user and one with the open closed state for example, how do you combine these reliably? They could come in different order due to threading so you canāt for example just assume that each time you receive the user, that the current status is the status from that user as the status may not have changed yet.
I think itās better to keep all attributes for an event together to avoid any ambiguity. Unfortunately ESH doesnāt have a way to do this - I tried to start a discussion on the ESH forum, but had no response! From other discussions the best option seems to be to create items using strings and put all the information in the string.
I agree it would be best to keep them together to avoid confusion.
1 Like
So I had a disk crash here about a week ago and finally got the computer up and running again. Having some problems including my lock securely. Went very good at first try last time with the lock 5+ meters away. Now I have tried everything it feels like, including moving the lock 1 cm from my UZB-stick in my server. Tried hard resetting my controller a few times as well as reseting the lock and reinstalling openHAB.
Getting this error right now. Installed unstable build from repo a few days ago along with the binding from 26th or 27th of June. Any suggestions?
Lock is a Danalock V2, worked perfectly before my setup crashed.
2017-07-02 22:29:12.557 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:d70bfb6a:node2' to inbox.
2017-07-02 22:29:13.834 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 2: Using Scheme0 Network Key for Key Exchange since we are in inclusion mode.
2017-07-02 22:30:23.241 [ERROR] [alization.ZWaveNodeInitStageAdvancer] - NODE 2: SECURITY_INC State=FAILED
UPDATE: The bug fix for this was apparently that I needed to type a long forum post explaining my problems and try again for the 54th time the third day of having problems. Just in case someone else gets the same problem. Literally worked 5 seconds after doing these simple stepsā¦
1 Like
Hmm, I think I understand this now. Interesting as I have I think a similar case or two in some of my rules where I use this methodology and it has worked. But your point makes me think so far Iāve been in good shape, but itās possible this could fail me at some point! 
So for that reason, I guess I would agree, it would be good to keep them together. I guess I wonāt be able to see whoās opening the door anytime soon ā¦ 
Oh well - Iāll have to suffice with camera review if I need to know who it is 
I havenāt had to do a secure inclusion for a while. When I was setting up my secure devices, I tried everything over and over without any success. I had even put OH on my laptop so that I could walk around with my zstick attached (same security settings) and pair my locks without taking them off the door and garage openers off the ceiling. Nothing worked, literally, for weeks. I was very frustrated, so I finally setup Domoticz (uses OpenZwave) on my laptop and BAM had three locks paired on their first try. Took the laptop into the garages and BAM paired up the door openers. No retries, no resets, just worked. Popped the zstick into the OH server and all was golden. Iām not suggesting this is the best long term solution (using something other than OH) for secure pairing, but it worked very well for me. Iām very hesitant to send this post out as I donāt want to offend Chris or anyone else who has worked on this binding by offering an alternative for secure inclusion. But knowing how frustrating it was, maybe this info will help someone whoās ready to give up on OH.
If secure inclusion is still as difficult as it was, there could be a lot of unhappy campers if this rolled out to a larger audience. Maybe I just lucked out with secure devices that are finicky with timing during inclusion. I have a couple uninstalled BE469s that Iāll test the secure inclusion on this week, using the current binding, and see if it goes any smoother.
For me, the answer is absolutely YES. I have a small z-wave network - 3 deadbolt - plus a thermostat and repeater added so there were neighbour nodes to improve the reachability of my garage deadbolt.
I have been using the security version of the binding on one deadbolt to trial it since March and my opinion is Zwave through OpenHAB is more reliable and it functions my locks much quicker than my Vera Lite setup. Once you added the lock alarm codes so i could get lock status updates, I transferred my entire z-wave network over to OpenHAB and have unplugged my Vera with no regrets.
Thanks for all the work you put into this Chris.