OH2 Z-Wave refactoring and testing... and SECURITY

There is definitely some bug with this binding (running the 2-5 now); I just tried to add a pretty common device (GE binary switch) and it goes into the same unknown device state. I have 11 others of these working that were previously added.

Stopped and restarted the openhab2 service and still unknown device. Deleted and rediscovered device and then it worked fine.

Yes - this seems to be the workaround. It looks like the second stage of discovery where the inbox gets updated with the ā€˜fullā€™ information isnā€™t working correctly. Iā€™ll look at it when I get some time - not right now though Iā€™m afraidā€¦

I canā€™t get this workaround working though :slight_smile: :disappointed:-

I donā€™t know why - if you can provide a log Iā€™ll try and take a look. It may be something completely differentā€¦

Ok finally got around to loading this up and taking it for a spin - needed to freshen up my zwave inclusion so far anyhow after the last lock mishap, so this is a fresh setup. Unfortunately some negative happenings to report here:

  1. When I was adding the items from the thing screen in HABmin, I noticed there was a weird ghost item appearing for many of them as I added. A simple refresh fixed this. Not sure if this is a HABmin thing or a ZWave thing. (not in the sense of openhanded Things).
  2. I canā€™t seem to get my lock to even talk to the ZStick it seems. I know itā€™s functionally connecting to ZWave devices, but unfortunately I canā€™t seem to make the lock work with it. I hate ā€œattemptsā€ at pairing since I have to dislodge the lock from the front door everytime. So hopefully someone can give me some educated pointers on how to identify my bottleneck?
  • I took the time to learn my way around getting to the Karaf Console for my Docker container, and then changed logs over to Debug level. I was able to validate that the logs were now kicking out DEBUG level messages. There is a lot of chatter at regular intervals, but I canā€™t make heads/tails of anything specific that looks like communication with this device. Any particular lines I should be looking for?
  • Happy to try and supply the logs if it would help to let someone else more trained view it.
  1. Iā€™m ending up with a few of the Unknown Device errors as well. The devices were successfully included with the regular binding without issue. For some reason this time, Iā€™m getting stuck.
  • First attempt, I was given 2 devices (identical devices), and 1 had the Initialise option under Advanced Options, while the second didnā€™t. They also did not show any of the data I believe for the attributes section other than Node and Neighbors.
  • Second attempt (I removed the devices, and re-enrolled them), I was left with the same Unknown Devices, yet I can see this time in the Attributes Iā€™m getting the name, model, detailed info, etc, just not the channels and successful addition.

First, a question; am I really running your binding? Listing the installed bundles shows

209 | Active   |  80 | 2.1.0.201702061819    | ZWave Binding

Second, Iā€™ve noticed delays in reacting to commands; it seems that the first command to a device will work immediately, but a subsequent one wonā€™t. Hereā€™s a chunk of logs between when I sent the command (to NODE 51) and when the node actually reacted:

2017-02-07 21:58:19.426 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 51: Command received zwave:device:69d7d64d:node51:switch_dimmer --> ON
2017-02-07 21:58:19.426 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 51: Creating new message for command SWITCH_MULTILEVEL_SET
2017-02-07 21:58:19.427 [DEBUG] [ommandClassTransactionPayloadBuilder] - At build null
2017-02-07 21:58:19.427 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 51: Encapsulating message, endpoint 0
2017-02-07 21:58:19.427 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 51: SECURITY not supported
2017-02-07 21:58:19.427 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 51: Command Class COMMAND_CLASS_SWITCH_MULTILEVEL is NOT required to be secured
2017-02-07 21:58:19.427 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 51: Adding to device queue
2017-02-07 21:58:19.427 [DEBUG] [e.internal.protocol.ZWaveTransaction] - >>>>> transaction node Id is different
2017-02-07 21:58:19.427 [DEBUG] [e.internal.protocol.ZWaveTransaction] - >>>>> transaction node Id is different
2017-02-07 21:58:19.427 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 51: Added to queue - size 27
2017-02-07 21:58:19.428 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start
2017-02-07 21:58:19.428 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction lastTransaction outstanding...
2017-02-07 21:58:19.428 [DEBUG] [nal.protocol.ZWaveTransactionManager] - STOP transaction timer
2017-02-07 21:58:19.428 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Start transaction timer to Tue Feb 07 21:58:35 CST 2017 - 15579ms
2017-02-07 21:58:26.060 [DEBUG] [rialmessage.IsFailedNodeMessageClass] - NODE 25: Requesting IsFailedNode status from controller.
2017-02-07 21:58:26.060 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: sendTransaction org.openhab.binding.zwave.internal.protocol.ZWaveSerialPayload@6e575513
2017-02-07 21:58:26.060 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: Adding to controller queue
2017-02-07 21:58:26.061 [DEBUG] [e.internal.protocol.ZWaveTransaction] - >>>>> transaction payload is NOT the same
2017-02-07 21:58:26.061 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: Added to queue - size 28
2017-02-07 21:58:26.061 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start
2017-02-07 21:58:26.061 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction lastTransaction outstanding...
2017-02-07 21:58:26.061 [DEBUG] [nal.protocol.ZWaveTransactionManager] - STOP transaction timer
2017-02-07 21:58:26.061 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Start transaction timer to Tue Feb 07 21:58:35 CST 2017 - 8946ms
2017-02-07 21:58:35.007 [DEBUG] [sactionManager$ZWaveTransactionTimer] - XXXXXXXXX Timeout.......... 1 outstanding transactions
2017-02-07 21:58:35.008 [DEBUG] [sactionManager$ZWaveTransactionTimer] - NODE 65: XXXXXXX Timeout at state WAIT_DATA. 3 retries remaining.
2017-02-07 21:58:35.008 [DEBUG] [sactionManager$ZWaveTransactionTimer] - Transaction is current transaction, so clearing!!!!!
2017-02-07 21:58:35.008 [DEBUG] [e.internal.protocol.ZWaveTransaction] - Transaction 265 CANCELLED
2017-02-07 21:58:35.008 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
2017-02-07 21:58:35.008 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 65: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2017-02-07 21:58:35.008 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: notifyTransactionResponse 265
2017-02-07 21:58:35.009 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
2017-02-07 21:58:35.009 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 9 -- 265
2017-02-07 21:58:35.009 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 10 -- 265
2017-02-07 21:58:35.009 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 11 -- 265
2017-02-07 21:58:35.009 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 51: listening == true, frequentlyListening == false, awake == false
2017-02-07 21:58:35.009 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 12 -- 265
2017-02-07 21:58:35.009 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 13 -- 265
2017-02-07 21:58:35.009 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 14 -- 265
2017-02-07 21:58:35.009 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 15 -- 265
2017-02-07 21:58:35.009 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 16 -- 265
2017-02-07 21:58:35.009 [DEBUG] [e.internal.protocol.ZWaveTransaction] - >>>>> transaction payload is the same [[38, 1, -1]] == [[38, 1, -1]]
2017-02-07 21:58:35.009 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 17 -- 265
2017-02-07 21:58:35.009 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction from sendQueue
2017-02-07 21:58:35.009 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 18 -- 265
2017-02-07 21:58:35.009 [DEBUG] [nal.protocol.ZWaveTransactionManager] - getTransactionToSend 6
2017-02-07 21:58:35.009 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 19 -- 265
2017-02-07 21:58:35.010 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 20 -- 265
2017-02-07 21:58:35.010 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 21 -- 265
2017-02-07 21:58:35.010 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 22 -- 265
2017-02-07 21:58:35.010 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 23 -- 265
2017-02-07 21:58:35.010 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 33 03 26 01 FF 25 B1 9A 
2017-02-07 21:58:35.010 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 24 -- 265
2017-02-07 21:58:35.010 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 25 -- 265
2017-02-07 21:58:35.010 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 51: Sending REQUEST Message = 01 0A 00 13 33 03 26 01 FF 25 B1 9A 
2017-02-07 21:58:35.010 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 26 -- 265
2017-02-07 21:58:35.010 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 36 -- 265
2017-02-07 21:58:35.010 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 37 -- 265
2017-02-07 21:58:35.010 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 38 -- 265
2017-02-07 21:58:35.010 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 39 -- 265
2017-02-07 21:58:35.010 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 40 -- 265
2017-02-07 21:58:35.010 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 41 -- 265
2017-02-07 21:58:35.010 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 42 -- 265
2017-02-07 21:58:35.010 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 264 -- 265
2017-02-07 21:58:35.011 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 265 -- 265
2017-02-07 21:58:35.011 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 265 -- DONE -- CANCELLED WAIT_DATA
2017-02-07 21:58:35.011 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: -- To notify -- TIMEOUT_WAITING_FOR_DATA
2017-02-07 21:58:35.011 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 266 -- 265
2017-02-07 21:58:35.011 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 267 -- 265
2017-02-07 21:58:35.011 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 268 -- 265
2017-02-07 21:58:35.011 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction event listener 270 -- 265
2017-02-07 21:58:35.011 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2017-02-07 21:58:35.011 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction Response Complete 265 -- 
2017-02-07 21:58:35.011 [DEBUG] [e.internal.protocol.ZWaveTransaction] - transactionStart type SendData 
2017-02-07 21:58:35.011 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID:269 [WAIT_RESPONSE] callback: 177
2017-02-07 21:58:35.011 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 65: Node Init response (0) TIMEOUT_WAITING_FOR_DATA
2017-02-07 21:58:35.012 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: expected cmd class: null
2017-02-07 21:58:35.012 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 65: No data from device, but it was ACK'd. Possibly not supported? (Try 0)
2017-02-07 21:58:35.012 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: expected cmd: 0
2017-02-07 21:58:35.012 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage Transactions outstanding: 1
2017-02-07 21:58:35.012 [DEBUG] [nal.protocol.ZWaveTransactionManager] - STOP transaction timer
2017-02-07 21:58:35.012 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Start transaction timer to Tue Feb 07 21:58:37 CST 2017 - 2000ms
2017-02-07 21:58:35.012 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage lastTransaction: TID:269 [WAIT_RESPONSE] callback: 177
2017-02-07 21:58:35.012 [DEBUG] [nal.protocol.ZWaveTransactionManager] - STOP transaction timer
2017-02-07 21:58:35.012 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Start transaction timer to Tue Feb 07 21:58:37 CST 2017 - 2000ms
2017-02-07 21:58:35.012 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2017-02-07 21:58:35.012 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage inputMessage: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
2017-02-07 21:58:35.012 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lockMessage: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
2017-02-07 21:58:35.018 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8 
2017-02-07 21:58:35.018 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
2017-02-07 21:58:35.019 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage inputMessage: class=SendData[0x13], type=Response[0x01], dest=255, callback=0, payload=01 
2017-02-07 21:58:35.019 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lockMessage: class=SendData[0x13], type=Response[0x01], dest=255, callback=0, payload=01 
2017-02-07 21:58:35.036 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 B1 00 00 03 59 
2017-02-07 21:58:35.038 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
2017-02-07 21:58:35.038 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage inputMessage: class=SendData[0x13], type=Request[0x00], dest=0, callback=177, payload=B1 00 00 03 
2017-02-07 21:58:35.038 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lockMessage: class=SendData[0x13], type=Request[0x00], dest=0, callback=177, payload=B1 00 00 03 
2017-02-07 21:58:36.347 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: sendTransaction org.openhab.binding.zwave.internal.protocol.ZWaveSerialPayload@6ec2b270
2017-02-07 21:58:36.347 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: Adding to device queue
2017-02-07 21:58:36.348 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 65: Added to queue - size 28
2017-02-07 21:58:36.348 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start
2017-02-07 21:58:36.348 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction lastTransaction outstanding...
2017-02-07 21:58:36.348 [DEBUG] [nal.protocol.ZWaveTransactionManager] - STOP transaction timer
2017-02-07 21:58:36.348 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Start transaction timer to Tue Feb 07 21:58:37 CST 2017 - 664ms
2017-02-07 21:58:37.012 [DEBUG] [sactionManager$ZWaveTransactionTimer] - XXXXXXXXX Timeout.......... 1 outstanding transactions
2017-02-07 21:58:37.013 [DEBUG] [sactionManager$ZWaveTransactionTimer] - NODE 51: XXXXXXX Timeout at state WAIT_RESPONSE. 3 retries remaining.
2017-02-07 21:58:37.013 [DEBUG] [sactionManager$ZWaveTransactionTimer] - Aborting Transaction!
2017-02-07 21:58:37.013 [DEBUG] [e.internal.protocol.ZWaveTransaction] - Transaction 269 ABORTED
2017-02-07 21:58:37.013 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 03 00 16 EA 
2017-02-07 21:58:37.013 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 255: Sending REQUEST Message = 01 03 00 16 EA 
2017-02-07 21:58:37.014 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2017-02-07 21:58:37.015 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start
2017-02-07 21:58:37.015 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction lastTransaction outstanding...
2017-02-07 21:58:37.015 [DEBUG] [nal.protocol.ZWaveTransactionManager] - STOP transaction timer
2017-02-07 21:58:37.015 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2017-02-07 21:58:37.016 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage inputMessage: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
2017-02-07 21:58:37.016 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Start transaction timer to Tue Feb 07 21:58:49 CST 2017 - 11998ms
2017-02-07 21:58:37.016 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lockMessage: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
^C

Third, I have three Kwikset locks which have worked with OpenHAB 1.8, but arenā€™t doing well with OpenHAB 2.x. Iā€™ve tried repairing them, with limited successā€¦ help?

Ok, posting an update here relative to the lock woes (being the target of this binding). It seems I had a few things in my way that were causing issues, and to help anyone who may have similar issues, listing the problems (or potential problems) and the resolution.

  1. Initial problem of even getting any real communication - The ZStick (Aeon 5th Gen) has a weird (to me, coming from Vera world) issue where if you have included the device even once, it basically wonā€™t talk to the device again when you try to do inclusion. It turns out, the one thing I forgot to fully exclude, was the lock.
  2. Now I started getting somewhere and the lock actually took a little longer and then would error out. I was having some interference from a recent update I made to the host where-in I was mapping the ZStick with the right permissions and such using a udev rule (etc/udev/rules.d/) for mapping a symlink. Well I recently plugged in another device, that got in the mix.
  • first attempt to resolve this was remove the rules file in the udev/rules location. well this was a bust as now I started getting i/o write error messages.
  • second attempt was to put the file back but remove the new rule for the second new device - no dice here as we still had the error on inclusion with the lock
  • third attempt - revert to known good condition, remove the extra rule, and unplug the extra USB device, now weā€™re getting somewhere
  1. Finally - I got to go back and include the device again, and this time I saw positive news in the logs. Indication of the secure inclusion completed, device was added, and thing discovered. Yay! :smiley:
  • now I did have to wait for a bit for the device initialization to kick in, and Iā€™m glad I waited around before trying to kick it and start over again before calling it quits for the night - in defeat - but about a moment before I was ready to do it, I deleted the Thing and then hit the include/discover button again ā€¦ what did appear but a message that a device was added with the actual name instead of Unknown Device!! Woohoo!! :grin:

As a side note, DEBUG logs were giving me WAY too much stuff. So I dropped down to INFO level logs instead. This gave me enough information to see that stuff was happening, but not every individual thing the ZWave binding is doing and communicating. That was too difficult to follow or make heads/tails of. INFO logs helped me start to pick out the issues and chase them down 1 by 1.

@chris - I say it many times over, and I canā€™t thank you enough for your work on this binding. Itā€™s made OH extremely operable and the core thing we canā€™t live without in our house. Screencap below of a working BE469 - Schlage Camelot Keypad. Now, just need the unknown device issue for the others fixed and Iā€™ll be in mint shape. Will let you know how the binding goes overall - PIN entries, lock/unlock stats, rules, etc.

I too have to add that I notice severe delays in a second zwave command being sent, first one is near instant.

Also I notice that if you manually flip a smart switch the zwave binding is not updating to the new state.

Hi Chris

Another case of an unknown device using this experimental binding. This is a new Aeotec MultiSensor 6. It took serveral restarts and thing deletes to get the Manufacturer/Type / ID show. Is this a problem with the new binding or a database/version issue?

network_ebf17a9e__node_2.xml (9.9 KB)

Iā€™m not sure this helps, but here are logs during an attempt to include a kwikset lock. I had done my best to exclude the lock and then factory reset it prior to this.

I noticed my Aeon Multisensor 6 also not working with the experimental binding. I have reverted back to the release version of the binding and updated it last night to the latest snapshot and the same issue is present so I think the database import into the binding got confused. It looks like the info is correct on Chrisā€™ website so Iā€™m assuming the info in the latest binding got messed up on the import?
node35.xml (9.7 KB)

edit:
This device was working with an earlier version of the 2.0 binding

I havenā€™t done much testing with the binding, but I notice last night that I was also seeing some pretty good delays in sending a command to turn on/off powered light switches.

And also have both my battery powered garage and door sensors reporting as dead although I did go and wake up both devices manually.

The thread is getting longer, but I think the latest binding is the one update and posted I think Monday 2/7 (post 127)?

exactly the same here, like Mike_Bagdanoff ā€¦

Thanks. Iā€™m aware of this problem and have a few logs. Thereā€™s possibly a lock condition between the receive thread and the transaction processing thread - if this happens then all transactions time out and thereā€™s a 2 second delay on the next frame (which if you send a number of frames at the same time will quickly add up to longer delays).

Iā€™ll look at this more over the next few days.

Now if I could get alarms setup to sense when the lock is open or closed, that would be the bees knees.

What kwikset lock? My 916 works greatā€¦

lol. I would like that to James. But I think its low priority at the moment till some of these other issues with delayed light activity, reported dead nodes being a higher issue.

When the Alarm Type channel makes it in, I think weā€™ll need a good rule to both update the status in OH2 when triggered and also to ensure you check/poll the Alarm type on a system start.

I want all the stuff Back to the Future promised me, too.

Hi guys

Just a stupid noob question. Iā€™m running a more recent oh2.1 snapshot build. Is there a z-wave binding version that works with my aeotec multisensor6 with these builds? Or do I need to wait till these above issues are sorted?

I preferred not returning back to the oh2 stable build.

Clearly there are a couple of issues to resolve here so I would probably suggest to hold on before changing to this version.

If your problem is the MS not detecting, I might have found a bug there - if confirmed Iā€™ll update the 2.1 snapshot tomorrow.