Contact items switching from CLOSED to OPEN on their own

I don’t know why it would be any slower than before - it’s fundamentally doing the same thing so I can’t see any reason why it would take more time. If you want to provide the log I’ll take a look - maybe the device still isn’t responding to some calls…

Here’s the log, node 16. In line 501 you can see the channel gets updated to OPEN (14:50:49.534) and back to CLOSED in line 592 (14:50:49.714). I didn’t touch the sensor (I’m really not THAT fast :wink: )
log.xml (85.8 KB)

Christian

Ok - I’m a little confused now, but lets deal with this latest issue first since it’s simple. This is caused because there’s no filtering on the event. This device supports multiple events so the binding requests them, and when the response is received, the two events send multiple updates. I will need to look at why the first event requested (16) is responded with an event 0 where the second one doesn’t, but I’ll look at that when I get a chance.

However, I thought that the problem was that it was taking 10 hours to get an initial update of the state? I assumed (maybe incorrectly) that since you’d previously mentioned that the device showed no state, that we were talking about the time to update from “no" state, to “some” state. Is this the case? It seems that in this short log the state has updated - the fact that it updated multiple times, and possibly incorrectly is a different though - right? Or am I misunderstanding the problem (sorry if so)?

Yeah, sorry, I have to disable persistence and restart openHAB to get a log for this issue. The above log was taken with enabled and working persistence. I’ll get back to you as soon as I have the log without persistence!

Christian

OK, I’ll check the log later tonight, but one (maybe) strange thing I already noticed:

...
2017-01-10 15:55:15.244 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Got an event from Z-Wave network: ZWaveInitializationStateEvent
2017-01-10 15:55:15.244 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 17: Node advancer: loop - DYNAMIC_VALUES try 0: stageAdvanced(true)
2017-01-10 15:55:15.244 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 17: Node advancer: DYNAMIC_VALUES - checking SENSOR_BINARY
2017-01-10 15:55:15.244 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 17: Node advancer: DYNAMIC_VALUES - found    SENSOR_BINARY
2017-01-10 15:55:15.244 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 17: Found 0 instances of SENSOR_BINARY
2017-01-10 15:55:15.244 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 17: Node advancer: DYNAMIC_VALUES - checking BASIC
2017-01-10 15:55:15.244 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 17: Node advancer: DYNAMIC_VALUES - checking BATTERY
2017-01-10 15:55:15.244 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 17: Node advancer: DYNAMIC_VALUES - found    BATTERY
2017-01-10 15:55:15.244 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 17: Found 1 instances of BATTERY
2017-01-10 15:55:15.244 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 17: Creating new message for application command BATTERY_GET
...

The binding found the SENSOR_BINARY, but logs this afterwards:

Found 0 instances of SENSOR_BINARY

Shouldn’t it start with

...
Found 1 instances of SENSOR_BINARY
Creating new message for application command SENSOR_BINARY_GET
...

right away? Just guessing…

Regards, Christian

I think we can dismiss this issue, I’ve got the states of almost all contacts in the last 2 hours. No idea what happened last night.

But if you find the time, you could have a look at the CLOSED-OPEN-CLOSED issue.

Thanks a lot, Christian

This is specific to the way that notification events work for door/window events - and probably is specific to this device. There are 3 events at play - open, closed, and event finished - I need to have a look at this a bit more when I get home (and I have one of these Vision devices so I can play with it).

FTR. This is likely caused by the converter still using the V1 alarm value when processing the event 0.

Nice! I’ll try it as soon as it’s merged! :slight_smile:

Hi Chris,

it seems to work! I restarted openHAB2 3 hours ago with the new zwave binding including this commit, no state changes so far!

Thanks a lot,
Christian