search

openhab / openhab1-addons

Add-ons for openHAB 1.x
Eclipse Public License 2.0
3.43k stars 1.69k forks source link

zwave stops broadcasting commands #1044

Closed petrklus closed 10 years ago

petrklus commented 10 years ago

State right after OH restart, log when flipping a switch (and the light goes on and off):

12:48:48.930 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Kitchen' with value 'ON'.
12:48:48.933 DEBUG o.o.b.z.i.p.c.ZWaveBinarySwitchCommandClass[:135]- Creating new message for application command SWITCH_BINARY_SET for node 2
12:48:48.934 DEBUG o.o.b.z.i.protocol.ZWaveNode[:551]- NODE 2: Encapsulating message, instance / endpoint 1
12:48:48.935 DEBUG o.o.b.z.i.p.c.ZWaveMultiInstanceCommandClass[:499]- NODE 2: Creating new message for application command MULTI_CHANNEL_ENCAP endpoint 1
12:48:48.935 DEBUG o.o.b.z.i.p.ZWaveController[:598]- Callback ID = 21
12:48:48.936 DEBUG o.o.b.z.i.p.ZWaveController[:361]- Enqueueing message. Queue length = 1
12:48:48.936 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:771]- Took message from queue for sending. Queue length = 0
12:48:48.938 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:800]- Sending Message = 01 0E 00 13 02 07 60 0D 01 01 25 01 FF 25 15 61 
12:48:48.944 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:971]- Receive Message = 01 04 01 13 01 E8 
12:48:48.945 DEBUG o.o.b.z.i.p.ZWaveController[:150]- Message: class = SendData (0x13), type = Response (0x01), payload = 01 
12:48:48.972 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:971]- Receive Message = 01 05 00 13 15 00 FC 
12:48:48.973 DEBUG o.o.b.z.i.p.ZWaveController[:150]- Message: class = SendData (0x13), type = Request (0x00), payload = 15 00 
12:48:48.975 DEBUG o.o.b.z.i.p.ZWaveController[:376]- Notifying event listeners
12:48:48.975 DEBUG o.o.b.z.i.ZWaveActiveBinding[:286]- ZwaveIncomingEvent
12:48:48.976 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:846]- Response processed after 38ms/216ms.
12:48:49.729 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Kitchen' with value 'OFF'.
12:48:49.732 DEBUG o.o.b.z.i.p.c.ZWaveBinarySwitchCommandClass[:135]- Creating new message for application command SWITCH_BINARY_SET for node 2
12:48:49.733 DEBUG o.o.b.z.i.protocol.ZWaveNode[:551]- NODE 2: Encapsulating message, instance / endpoint 1
12:48:49.733 DEBUG o.o.b.z.i.p.c.ZWaveMultiInstanceCommandClass[:499]- NODE 2: Creating new message for application command MULTI_CHANNEL_ENCAP endpoint 1
12:48:49.733 DEBUG o.o.b.z.i.p.ZWaveController[:598]- Callback ID = 22
12:48:49.734 DEBUG o.o.b.z.i.p.ZWaveController[:361]- Enqueueing message. Queue length = 1
12:48:49.734 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:771]- Took message from queue for sending. Queue length = 0
12:48:49.735 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:800]- Sending Message = 01 0E 00 13 02 07 60 0D 01 01 25 01 00 25 16 9D 
12:48:49.741 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:971]- Receive Message = 01 04 01 13 01 E8 
12:48:49.742 DEBUG o.o.b.z.i.p.ZWaveController[:150]- Message: class = SendData (0x13), type = Response (0x01), payload = 01 
12:48:49.754 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:971]- Receive Message = 01 05 00 13 16 00 FF 
12:48:49.755 DEBUG o.o.b.z.i.p.ZWaveController[:150]- Message: class = SendData (0x13), type = Request (0x00), payload = 16 00 
12:48:49.756 DEBUG o.o.b.z.i.p.ZWaveController[:376]- Notifying event listeners
12:48:49.757 DEBUG o.o.b.z.i.ZWaveActiveBinding[:286]- ZwaveIncomingEvent
12:48:49.757 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:846]- Response processed after 21ms/216ms.

However, later it stops working (same command issued, however, no corresponding zwave binding activity):

13:15:30.486 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Hallway' with value 'ON'.
13:15:31.958 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Hallway' with value 'OFF'.

What is going on? Why does the binding not create and enqueue the new commands?

The PING goes through just fine:

13:15:35.103 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:277]- NODE 2: Sending periodic PING.
13:15:35.103 DEBUG o.o.b.z.i.p.c.ZWaveNoOperationCommandClass[:75]- NODE 2: Creating new message for application command No Operation
13:15:35.104 DEBUG o.o.b.z.i.p.ZWaveController[:598]- Callback ID = 44
13:15:35.104 DEBUG o.o.b.z.i.p.ZWaveController[:361]- Enqueueing message. Queue length = 1
13:15:35.104 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:771]- Took message from queue for sending. Queue length = 0
13:15:35.105 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:800]- Sending Message = 01 08 00 13 02 01 00 25 2C EE 
13:15:35.110 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:971]- Receive Message = 01 04 01 13 01 E8 
13:15:35.111 DEBUG o.o.b.z.i.p.ZWaveController[:150]- Message: class = SendData (0x13), type = Response (0x01), payload = 01 
13:15:35.122 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:971]- Receive Message = 01 05 00 13 2C 00 C5 
13:15:35.123 DEBUG o.o.b.z.i.p.ZWaveController[:150]- Message: class = SendData (0x13), type = Request (0x00), payload = 2C 00 
13:15:35.124 DEBUG o.o.b.z.i.p.ZWaveController[:376]- Notifying event listeners
13:15:35.124 DEBUG o.o.b.z.i.ZWaveActiveBinding[:286]- ZwaveIncomingEvent
13:15:35.124 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:846]- Response processed after 19ms/216ms.

Why is the ping still working but normal commands are not sent out?

petrklus commented 10 years ago

Full logs:

http://cnktmp.s3.amazonaws.com/logs.zip

I would also like to add that my setup could not be simpler - it's just a controller + one node (double relay switch)

cdjackson commented 10 years ago

The ping is generated internally within the binding - the switch message comes externally. Either the problem is in the REST interface, or very early in the ZWave binding (or something to do with the comms between them. Basically, we’re only seeing the log entries from the REST side - not the zwave side. If you can add TRACE logging to zwave, then there is a log entry when the zwave binding receives the command from the message bus so this will help.

Chris

cdjackson commented 10 years ago

This is actually very useful - thanks. Does this happen every time you start? If so, can you enable TRACE logging please.

petrklus commented 10 years ago

Yes, it happens every time - fine for a few minutes then stops responding.

Where do I enable TRACE logging? Is it in the .xml logging setup file?

On Sun, May 4, 2014 at 1:44 PM, Chris Jackson notifications@github.comwrote:

This is actually very useful - thanks. Does this happen every time you start? If so, can you enable TRACE logging please.

— Reply to this email directly or view it on GitHubhttps://github.com/openhab/openhab/issues/1044#issuecomment-42131030 .

cdjackson commented 10 years ago

Yes - in the logback.xml file. If you add <logger name="org.openhab.binding.zwave" level=“TRACE" /> to the file it should sort it. Note though that if you’re running in debug mode anyway, then the file is logback_debug.xml.

Cheers Chris

petrklus commented 10 years ago

Done! Seeing TRACE messages now.. Will post the new one once the issue manifests itself again..

On Sun, May 4, 2014 at 2:11 PM, Chris Jackson notifications@github.comwrote:

Yes - in the logback.xml file. If you add <logger name="org.openhab.binding.zwave" level=“TRACE" /> to the file it should sort it. Note though that if you’re running in debug mode anyway, then the file is logback_debug.xml.

Cheers Chris

— Reply to this email directly or view it on GitHubhttps://github.com/openhab/openhab/issues/1044#issuecomment-42131485 .

cdjackson commented 10 years ago

Thanks.

petrklus commented 10 years ago

Update - took a bit longer to happen but happened in the end I got there. Here are the logs:

http://cnktmp.s3.amazonaws.com/logs_trace.zip

Was working for the most part, the problem was in last 5-10m. Tried flipping a switch a few times but no action, only relevant stuff I could see in the log was:

22:02:08.347 TRACE o.o.b.z.i.ZWaveActiveBinding[:145]- internalReceiveCommand(itemname = ZWave_Light_IND_Hallway, Command = ON)

Thank you very much!

petrklus commented 10 years ago

Also, to clarify, here are my details:

Aeon Z-stick Fibaro Dual relay switch Odroid U3 board

Items:

Switch ZWave_Light_IND_Hallway  "Hallway main"      (IND_Hallway, Lights) {zwave="2:2:command=switch_binary"} 
Switch ZWave_Light_IND_Kitchen  "Kitchen main"      (IND_Kitchen, Lights) {zwave="2:1:command=switch_binary"}

Config (was default when problems started, tried playing with the numbers to see if it helps:

################################ Z-Wave  Binding ######################################
#
# The Z-Wave controller port. Valid values are e.g. COM1 for Windows and /dev/ttyS0 or
# /dev/ttyUSB0 for Linux
zwave:port=/dev/zwave

# Z-Wave binding refresh value (optional, defaults to 10000)
zwave:refresh=5000
# Z-Wave binding refresh interval threshold (optional, defaults to every 6 times)
zwave:refreshThreshold=3

I am running 1.5 SNAPSHOT from CloudBees build (also had same issue with what I've build locally from latest sources).

My addons:

root@odroid:~/openhab-test/addons# ls -lha *.jar
-rw-r--r-- 1 root root  63K May  3 23:42 org.openhab.binding.exec-1.5.0-SNAPSHOT.jar
-rw-r--r-- 1 root root  19K May  3 23:42 org.openhab.binding.http-1.5.0-SNAPSHOT.jar
-rw-r--r-- 1 root root  97K May  3 23:42 org.openhab.binding.mpd-1.5.0-SNAPSHOT.jar
-rw-r--r-- 1 root root  10K May  3 23:42 org.openhab.binding.ntp-1.5.0-SNAPSHOT.jar
-rw-r--r-- 1 root root 408K May  3 23:42 org.openhab.binding.systeminfo-1.5.0-SNAPSHOT.jar
-rw-r--r-- 1 root root  75K May  3 23:42 org.openhab.binding.tcp-1.5.0-SNAPSHOT.jar
-rw-r--r-- 1 root root 825K May  4 10:47 org.openhab.binding.zwave-1.5.0-SNAPSHOT.jar
-rw-r--r-- 1 root root 2.5M May  3 15:53 org.openhab.io.myopenhab-1.4.0-SNAPSHOT.jar
-rw-r--r-- 1 root root 2.3M May  3 23:43 org.openhab.persistence.db4o-1.5.0-SNAPSHOT.jar
-rw-r--r-- 1 root root 6.1K May  3 23:43 org.openhab.persistence.exec-1.5.0-SNAPSHOT.jar
-rw-r--r-- 1 root root 7.3K May  3 23:43 org.openhab.persistence.logging-1.5.0-SNAPSHOT.jar
-rw-r--r-- 1 root root 604K May  3 23:43 org.openhab.persistence.rrd4j-1.5.0-SNAPSHOT.jar
cdjackson commented 10 years ago

I get an access denied error with this link…

Chris

On 4 May 2014, at 21:18, petrklus notifications@github.com wrote:

http://cnktmp.s3.amazonaws.com/logs_trace.zip

petrklus commented 10 years ago

My bad - added EVERYONE ACL, should work now!

cdjackson commented 10 years ago

Yep - got it - thanks.

petrklus commented 10 years ago

Btw. I've now dropped your latest copy from habmin to see if anything changes. Also, is there any more comprehensive guide on how to configure habmin? For example, I cannto see any logs in system->log viewer etc.

cdjackson commented 10 years ago

Also, is there any more comprehensive guide on how to configure habmin? For example, I cannto see any logs in system->log viewer etc.

There’s just the wiki. The log viewer isn’t implemented yet - it’s not something I’ve been able to work out how to intercept the logs and forward them to an HTTP interface...

petrklus commented 10 years ago

Thanks! Maybe I will be able to contribute once my initial setup is done and my family is not afraid to push a switch in order not to break anything :D. (just a hyperbole, that's what I like about most z-wave switches - they still work even if the central hub is somehow incapacitated).

On Mon, May 5, 2014 at 10:33 AM, Chris Jackson notifications@github.comwrote:

Also, is there any more comprehensive guide on how to configure habmin? For example, I cannto see any logs in system->log viewer etc.

There’s just the wiki. The log viewer isn’t implemented yet - it’s not something I’ve been able to work out how to intercept the logs and forward them to an HTTP interface...

— Reply to this email directly or view it on GitHubhttps://github.com/openhab/openhab/issues/1044#issuecomment-42168109 .

petrklus commented 10 years ago

Update:

Same issue with the latest ZWAVE extension (from habmin repo):

This time it happened sooner, so the logs are a bit lighter:

http://cnktmp.s3.amazonaws.com/logs_habminzwave.zip

We can see me issuing commands and nothing happening, yet PING goes through just fine:

11:01:20.777 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Kitchen/' with value 'OFF'.
11:01:20.779 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Kitchen, Command = OFF)
11:01:22.237 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Kitchen/' with value 'ON'.
11:01:22.240 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Kitchen, Command = ON)
11:01:23.804 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Kitchen/' with value 'OFF'.
11:01:23.806 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Kitchen, Command = OFF)
11:01:24.421 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Hallway/' with value 'ON'.
11:01:24.423 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Hallway, Command = ON)
11:01:27.221 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Hallway/' with value 'OFF'.
11:01:27.224 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Hallway, Command = OFF)
11:01:29.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads
11:01:33.516 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Hallway, Command = ON)
11:01:35.607 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Hallway, Command = OFF)
11:01:36.585 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Kitchen, Command = ON)
11:01:39.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads
11:01:41.073 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Kitchen, Command = OFF)
11:01:49.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads
11:01:59.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads
11:02:09.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads
scr11:02:19.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads
11:02:29.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads
11:02:39.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads
11:02:49.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads
11:02:59.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads
11:03:09.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads
11:03:14.853 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:277]- NODE 2: Sending periodic PING.
11:03:14.853 DEBUG o.o.b.z.i.p.c.ZWaveNoOperationCommandClass[:75]- NODE 2: Creating new message for application command No Operation
11:03:14.854 DEBUG o.o.b.z.i.p.ZWaveController[:653]- Callback ID = 32
11:03:14.854 DEBUG o.o.b.z.i.p.ZWaveController[:364]- Enqueueing message. Queue length = 1
11:03:14.854 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:826]- Took message from queue for sending. Queue length = 0
11:03:14.855 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:855]- Sending Message = 01 08 00 13 02 01 00 25 20 E2
11:03:14.857 TRACE o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1031]- Received ACK
11:03:14.860 TRACE o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1025]- Reading message finished
11:03:14.860 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1026]- Receive Message = 01 04 01 13 01 E8
11:03:14.861 TRACE o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:949]- Message is valid, sending ACK
11:03:14.862 TRACE o.o.b.z.i.p.ZWaveController[:152]- Incoming message to process
11:03:14.862 DEBUG o.o.b.z.i.p.ZWaveController[:153]- Message: class = SendData (0x13), type = Response (0x01), payload = 01
11:03:14.862 TRACE o.o.b.z.i.p.ZWaveController[:207]- Message type = RESPONSE
11:03:14.872 TRACE o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1025]- Reading message finished
11:03:14.872 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1026]- Receive Message = 01 05 00 13 20 00 C9
11:03:14.873 TRACE o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:949]- Message is valid, sending ACK
11:03:14.874 TRACE o.o.b.z.i.p.ZWaveController[:152]- Incoming message to process
11:03:14.874 DEBUG o.o.b.z.i.p.ZWaveController[:153]- Message: class = SendData (0x13), type = Request (0x00), payload = 20 00
11:03:14.874 TRACE o.o.b.z.i.p.ZWaveController[:173]- Message type = REQUEST
11:03:14.875 DEBUG o.o.b.z.i.p.ZWaveController[:379]- Notifying event listeners
11:03:14.875 TRACE o.o.b.z.i.p.ZWaveController[:381]- Notifying org.openhab.binding.zwave.internal.ZWaveActiveBinding@174a09b
11:03:14.875 DEBUG o.o.b.z.i.ZWaveActiveBinding[:362]- ZwaveIncomingEvent
11:03:14.876 TRACE o.o.b.z.i.p.ZWaveController[:381]- Notifying org.openhab.binding.zwave.internal.ZWaveNetworkMonitor@1dc48dd
11:03:14.876 TRACE o.o.b.z.i.p.ZWaveController[:381]- Notifying org.openhab.binding.zwave.internal.config.ZWaveConfiguration@82d97
cdjackson commented 10 years ago

I got sidetracked with something else I’ve found in your log and forgot to look at the original problem (you have some interesting ‘dead node’ stuff which I’ll probably post back into a separate thread shortly.

I’ll take a look at this, but clearly the logs show that the data is getting to the binding, but for some reason it stops. I’ll add some more debug and send out a new version at some stage today.

On 5 May 2014, at 10:06, petrklus notifications@github.com wrote:

Update:

Same issue with the latest ZWAVE extension (from habmin repo):

This time it happened sooner, so the logs are a bit lighter:

http://cnktmp.s3.amazonaws.com/logs_habminzwave.zip

We can see me issuing commands and nothing happening, yet PING goes through just fine:

11:01:20.777 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Kitchen/' with value 'OFF'. 11:01:20.779 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Kitchen, Command = OFF) 11:01:22.237 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Kitchen/' with value 'ON'. 11:01:22.240 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Kitchen, Command = ON) 11:01:23.804 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Kitchen/' with value 'OFF'. 11:01:23.806 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Kitchen, Command = OFF) 11:01:24.421 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Hallway/' with value 'ON'. 11:01:24.423 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Hallway, Command = ON) 11:01:27.221 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Hallway/' with value 'OFF'. 11:01:27.224 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Hallway, Command = OFF) 11:01:29.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads 11:01:33.516 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Hallway, Command = ON) 11:01:35.607 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Hallway, Command = OFF) 11:01:36.585 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Kitchen, Command = ON) 11:01:39.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads 11:01:41.073 TRACE o.o.b.z.i.ZWaveActiveBinding[:199]- internalReceiveCommand(itemname = ZWave_Light_IND_Kitchen, Command = OFF) 11:01:49.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads 11:01:59.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads 11:02:09.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads scr11:02:19.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads 11:02:29.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads 11:02:39.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads 11:02:49.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads 11:02:59.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads 11:03:09.592 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads 11:03:14.853 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:277]- NODE 2: Sending periodic PING. 11:03:14.853 DEBUG o.o.b.z.i.p.c.ZWaveNoOperationCommandClass[:75]- NODE 2: Creating new message for application command No Operation 11:03:14.854 DEBUG o.o.b.z.i.p.ZWaveController[:653]- Callback ID = 32 11:03:14.854 DEBUG o.o.b.z.i.p.ZWaveController[:364]- Enqueueing message. Queue length = 1 11:03:14.854 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:826]- Took message from queue for sending. Queue length = 0 11:03:14.855 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:855]- Sending Message = 01 08 00 13 02 01 00 25 20 E2 11:03:14.857 TRACE o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1031]- Received ACK 11:03:14.860 TRACE o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1025]- Reading message finished 11:03:14.860 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1026]- Receive Message = 01 04 01 13 01 E8 11:03:14.861 TRACE o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:949]- Message is valid, sending ACK 11:03:14.862 TRACE o.o.b.z.i.p.ZWaveController[:152]- Incoming message to process 11:03:14.862 DEBUG o.o.b.z.i.p.ZWaveController[:153]- Message: class = SendData (0x13), type = Response (0x01), payload = 01 11:03:14.862 TRACE o.o.b.z.i.p.ZWaveController[:207]- Message type = RESPONSE 11:03:14.872 TRACE o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1025]- Reading message finished 11:03:14.872 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1026]- Receive Message = 01 05 00 13 20 00 C9 11:03:14.873 TRACE o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:949]- Message is valid, sending ACK 11:03:14.874 TRACE o.o.b.z.i.p.ZWaveController[:152]- Incoming message to process 11:03:14.874 DEBUG o.o.b.z.i.p.ZWaveController[:153]- Message: class = SendData (0x13), type = Request (0x00), payload = 20 00 11:03:14.874 TRACE o.o.b.z.i.p.ZWaveController[:173]- Message type = REQUEST 11:03:14.875 DEBUG o.o.b.z.i.p.ZWaveController[:379]- Notifying event listeners 11:03:14.875 TRACE o.o.b.z.i.p.ZWaveController[:381]- Notifying org.openhab.binding.zwave.internal.ZWaveActiveBinding@174a09b 11:03:14.875 DEBUG o.o.b.z.i.ZWaveActiveBinding[:362]- ZwaveIncomingEvent 11:03:14.876 TRACE o.o.b.z.i.p.ZWaveController[:381]- Notifying org.openhab.binding.zwave.internal.ZWaveNetworkMonitor@1dc48dd 11:03:14.876 TRACE o.o.b.z.i.p.ZWaveController[:381]- Notifying org.openhab.binding.zwave.internal.config.ZWaveConfiguration@82d97 — Reply to this email directly or view it on GitHub.

petrklus commented 10 years ago

Great, looking forward to your reply!

By the way - what timezone are you in?

cdjackson commented 10 years ago

I’m in the UK - it’s a holiday here today :)

cdjackson commented 10 years ago

One thing I’ve found is that the command will silently ‘fail’ (as you see) if the node stage is not = DONE (e.g. if it goes DEAD or reinitialises for some reason). While this doesn’t appear to be the case here it seems that every other path should result in another log entry after the one we see. I’ll add debug into this area and see what it shows.

petrklus commented 10 years ago

OK, let me know when I can update the extension and see.. On 5 May 2014 12:07, "Chris Jackson" notifications@github.com wrote:

One thing I’ve found is that the command will silently ‘fail’ (as you see) if the node stage is not = DONE (e.g. if it goes DEAD or reinitialises for some reason). While this doesn’t appear to be the case here it seems that every other path should result in another log entry after the one we see. I’ll add debug into this area and see what it shows.

— Reply to this email directly or view it on GitHubhttps://github.com/openhab/openhab/issues/1044#issuecomment-42174213 .

cdjackson commented 10 years ago

I’m just compiling, will give it a quick try here to make sure there’s no silly errors then will post it to the openhab list under the "Re: Z-Wave Philio Multi-Sensor PSM02” thread since it will also have a fix (hopefully) for the binary sensor enhancements (and Git won’t allow posting of binaries here I think).

petrklus commented 10 years ago

Just downloaded it, let the testing start :)

petrklus commented 10 years ago

.. and here we go:

13:34:34.765 TRACE o.o.b.z.i.ZWaveActiveBinding[:211]- internalReceiveCommand(itemname = ZWave_Light_IND_Hallway, Command = OFF)
13:34:34.766 TRACE o.o.b.z.i.c.ZWaveConverterHandler[:340]- 2 stage is node DONE: DEAD
13:34:38.124 TRACE o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1089]- Watchdog: Checking Serial threads
13:34:38.376 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Hallway/' with value 'ON'.
13:34:38.377 TRACE o.o.b.z.i.ZWaveActiveBinding[:211]- internalReceiveCommand(itemname = ZWave_Light_IND_Hallway, Command = ON)
13:34:38.378 TRACE o.o.b.z.i.c.ZWaveConverterHandler[:340]- 2 stage is node DONE: DEAD
13:34:40.266 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Hallway/' with value 'OFF'.
13:34:40.268 TRACE o.o.b.z.i.ZWaveActiveBinding[:211]- internalReceiveCommand(itemname = ZWave_Light_IND_Hallway, Command = OFF)
13:34:40.268 TRACE o.o.b.z.i.c.ZWaveConverterHandler[:340]- 2 stage is node DONE: DEAD
13:34:43.888 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Kitchen/' with value 'ON'.
13:34:43.890 TRACE o.o.b.z.i.ZWaveActiveBinding[:211]- internalReceiveCommand(itemname = ZWave_Light_IND_Kitchen, Command = ON)
13:34:43.890 TRACE o.o.b.z.i.c.ZWaveConverterHandler[:340]- 2 stage is node DONE: DEAD
13:34:45.193 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Kitchen/' with value 'OFF'.
13:34:45.195 TRACE o.o.b.z.i.ZWaveActiveBinding[:211]- internalReceiveCommand(itemname = ZWave_Light_IND_Kitchen, Command = OFF)
13:34:45.195 TRACE o.o.b.z.i.c.ZWaveConverterHandler[:340]- 2 stage is node DONE: DEAD
13:34:46.352 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Kitchen/' with value 'ON'.
13:34:46.353 TRACE o.o.b.z.i.ZWaveActiveBinding[:211]- internalReceiveCommand(itemname = ZWave_Light_IND_Kitchen, Command = ON)
13:34:46.354 TRACE o.o.b.z.i.c.ZWaveConverterHandler[:340]- 2 stage is node DONE: DEAD
13:34:47.489 DEBUG o.o.i.r.i.r.ItemResource[:196]- Received HTTP POST request at 'items/ZWave_Light_IND_Kitchen/' with value 'OFF'.
13:34:47.491 TRACE o.o.b.z.i.ZWaveActiveBinding[:211]- internalReceiveCommand(itemname = ZWave_Light_IND_Kitchen, Command = OFF)
13:34:47.491 TRACE o.o.b.z.i.c.ZWaveConverterHandler[:340]- 2 stage is node DONE: DEAD

Full logs: http://cnktmp.s3.amazonaws.com/logs_4.zip

image

cdjackson commented 10 years ago

Ok - that’s what I thought. The problem is the node is going dead, and then the binding doesn’t talk to it :(

I’m going to remove this check - my concept for handling dead nodes is still to send a frame to them, but only 1 (i.e. no retries). I don’t know if you saw my other post about the stuff I’ve seen in your log with node 2 going dead? It’s strange...

cdjackson commented 10 years ago

I’ll attach an update here - if Git removes the file I’ll post it to the openhab list.

petrklus commented 10 years ago

Thanks!

I suppose that is going to work in the interim, what can I do to help debug the healing behaviour? On 5 May 2014 14:10, "Chris Jackson" notifications@github.com wrote:

I’ll attach an update here - if Git removes the file I’ll post it to the openhab list.

— Reply to this email directly or view it on GitHubhttps://github.com/openhab/openhab/issues/1044#issuecomment-42181170 .

cdjackson commented 10 years ago

I suppose that is going to work in the interim, what can I do to help debug the healing behaviour? Well, that’s the big question…. Take a look at my post in the forum about what I’ve seen in your logs. Unfortunately I don’t understand what’s happening, so it’s difficult to combat it, and it also seems that OZW has the same, or similar, problem (I think the OH binding used OZW as a reference, so it’s probably not a surprise).

ZWave information is scarce - I have quite a bit that I’ve dredged up off the net, but it’s all quite old.

Any thoughts are welcome. I might dig my Vera out and see if I can get it talking to the net to see what they send and see if it’s different to the binding, but this isn’t a 5 minute task unfortunately…

The other option is to ‘have a play’ with options etc and see what helps. It’s a bit ‘trial and error’ which isn’t nice, but in the absence of documentation there’s probably limited alternative.

petrklus commented 10 years ago

I am slowly getting my grips from various sources too.. (this one was especially helpful - https://groups.google.com/forum/#!topic/openhab/h3beXlo5iKU).

My question is - what initially triggers node to be dead? Is it when it is not responding to PING?

Also, where does the 15s lockup come from?

petrklus commented 10 years ago

Lastly, what was your motivation to using zwave api VS interfacing with Vera? As a person at the beginning of the integration, is there any advantage to having it directly in OH, compared to interfacing with fibaro or vera? I understand the underlying concepts but if the protocol continues to be a mystery (and on top of that can be update without our knowledge), how can we "guarantee" a reliable system?

cdjackson commented 10 years ago

My question is - what initially triggers node to be dead? Is it when it is not responding to PING?

Not responding to 3 consecutive requests will cause it to be marked DEAD - these might be a ping, or anything else (commands or whatever).

Also, where does the 15s lockup come from?

This is the 3 consecutive requests mentioned above - each request (currently) uses a 5 second timeout. I have some information that indicates that a shorter time might be ok (2.5 seconds is mentioned) so I have made this a configurable parameter.

cdjackson commented 10 years ago

Lastly, what was your motivation to using zwave api VS interfacing with Vera?

The zwave binding was already written before I started with OH. I’ve added to it over the past 6 months or so and added all the configuration type stuff, but the underlying binding and fundamental communications was already there and I’ve not changed that much at all. Previously when nodes went DEAD (which happened quite often) they stayed DEAD until you restarted the binding. The recovery stuff that I’ve added is trying to cope with this to make things more robust, but at the end of the day, DEAD nodes should be a ‘once in a blue moon’ event and not something that’s happening often...

As a person at the beginning of the integration, is there any advantage to having it directly in OH, compared to interfacing with fibaro or vera?

Personally, I wouldn’t go for a Vera. While its zwave integration is ok, you will potentially still find similar issues with it. Additionally, MCV are very unresponsive to fixing problems. When I first got my Vera 3 years ago I raised a request to add decimal places to temperatures - people are still complaining about that issue now and it’s soooo easy to fix. If you integrate to a Vera, you will still have these issues and there will be nothing you can do about it.

I understand the underlying concepts but if the protocol continues to be a mystery (and on top of that can be update without our knowledge), how can we "guarantee" a reliable system?

I don’t think it will be updated. One nice thing about zwave is that Sigma are the only chip manufacturer, so it’s basically guaranteed compatible and it won’t change. They have a standard API, and any changes they make they always retain backward compatibility. At the end of the day, they can’t just got and change this or everyones devices will stop working.

I agree that there are issues here, however if you read the other forums (MCV Vera for example) you will still find people complaining about nodes that they can’t communicate with etc. A lot of this might be underlying communications issues. Even Vera, Fibaro etc all use the same stick as we are all using - it’s just embedded into their units, but the API is still the same.

I don’t know much about the Fibaro unit, but I do like Fibaro stuff, so if I were going to go for another unit, I’d probably look there (just my opinions of course!).

petrklus commented 10 years ago

I think it makes sense - I would definitely go with Fibaro if faced the choice.. but in the meantime I will see if I can help make the binding stable and working for me.

One more side note - in the previous case, when the node is declared DEAD, it is marked RED in HABmin. When I go and flip the switch, I saw the colour in Habmin to change to yellow - what at the conditions to be fulfilled for the node to be green?

Will try the latest binding now..

Thank you very much for your replies!

On Mon, May 5, 2014 at 3:14 PM, Chris Jackson notifications@github.comwrote:

Lastly, what was your motivation to using zwave api VS interfacing with Vera?

The zwave binding was already written before I started with OH. I’ve added to it over the past 6 months or so and added all the configuration type stuff, but the underlying binding and fundamental communications was already there and I’ve not changed that much at all. Previously when nodes went DEAD (which happened quite often) they stayed DEAD until you restarted the binding. The recovery stuff that I’ve added is trying to cope with this to make things more robust, but at the end of the day, DEAD nodes should be a ‘once in a blue moon’ event and not something that’s happening often...

As a person at the beginning of the integration, is there any advantage to having it directly in OH, compared to interfacing with fibaro or vera?

Personally, I wouldn’t go for a Vera. While its zwave integration is ok, you will potentially still find similar issues with it. Additionally, MCV are very unresponsive to fixing problems. When I first got my Vera 3 years ago I raised a request to add decimal places to temperatures - people are still complaining about that issue now and it’s soooo easy to fix. If you integrate to a Vera, you will still have these issues and there will be nothing you can do about it.

I understand the underlying concepts but if the protocol continues to be a mystery (and on top of that can be update without our knowledge), how can we "guarantee" a reliable system?

I don’t think it will be updated. One nice thing about zwave is that Sigma are the only chip manufacturer, so it’s basically guaranteed compatible and it won’t change. They have a standard API, and any changes they make they always retain backward compatibility. At the end of the day, they can’t just got and change this or everyones devices will stop working.

I agree that there are issues here, however if you read the other forums (MCV Vera for example) you will still find people complaining about nodes that they can’t communicate with etc. A lot of this might be underlying communications issues. Even Vera, Fibaro etc all use the same stick as we are all using - it’s just embedded into their units, but the API is still the same.

I don’t know much about the Fibaro unit, but I do like Fibaro stuff, so if I were going to go for another unit, I’d probably look there (just my opinions of course!).

— Reply to this email directly or view it on GitHubhttps://github.com/openhab/openhab/issues/1044#issuecomment-42185976 .

cdjackson commented 10 years ago

One more side note - in the previous case, when the node is declared DEAD, it is marked RED in HABmin. When I go and flip the switch, I saw the colour in Habmin to change to yellow - what at the conditions to be fulfilled for the node to be green?

Red = dead, Green = ok, grey = uninitialised…

Yellow means one of two things -: Either, it was dead in the past 24 hours, OR, the number of retries on this node is >5% (I think it’s 5%). Basically, it indicates that this node might be dodgy.

petrklus commented 10 years ago

Ok, looks like the latest binding allows me to send commands to "DEAD" nodes - however, even after happily communicating with the nodes, the habmin still states:

image

cdjackson commented 10 years ago

Interesting. This (might) mean that even though the command got through to the node, the response didn’t come back. If the response had come back, then the binding should mark it alive again. Do you have a log?

petrklus commented 10 years ago 
16:04:19.007 TRACE o.o.b.z.i.ZWaveActiveBinding[:211]- internalReceiveCommand(itemname = ZWave_Light_IND_Hallway, Command = OFF)
16:04:19.008 DEBUG o.o.b.z.i.p.c.ZWaveBinarySwitchCommandClass[:135]- Creating new message for application command SWITCH_BINARY_SET for node 2
16:04:19.009 DEBUG o.o.b.z.i.protocol.ZWaveNode[:551]- NODE 2: Encapsulating message, instance / endpoint 2
16:04:19.010 DEBUG o.o.b.z.i.p.c.ZWaveMultiInstanceCommandClass[:499]- NODE 2: Creating new message for application command MULTI_CHANNEL_ENCAP endpoint 2
16:04:19.010 DEBUG o.o.b.z.i.p.ZWaveController[:653]- Callback ID = 24
16:04:19.011 DEBUG o.o.b.z.i.p.ZWaveController[:364]- Enqueueing message. Queue length = 1
16:04:19.011 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:826]- Took message from queue for sending. Queue length = 0
16:04:19.014 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:855]- Sending Message = 01 0E 00 13 02 07 60 0D 01 02 25 01 00 25 18 90 
16:04:19.016 TRACE o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1031]- Received ACK
16:04:19.019 TRACE o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1025]- Reading message finished
16:04:19.020 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1026]- Receive Message = 01 04 01 13 01 E8 
16:04:19.021 TRACE o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:949]- Message is valid, sending ACK
16:04:19.022 TRACE o.o.b.z.i.p.ZWaveController[:152]- Incoming message to process
16:04:19.022 DEBUG o.o.b.z.i.p.ZWaveController[:153]- Message: class = SendData (0x13), type = Response (0x01), payload = 01 
16:04:19.022 TRACE o.o.b.z.i.p.ZWaveController[:207]- Message type = RESPONSE
16:04:19.032 TRACE o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1025]- Reading message finished
16:04:19.033 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1026]- Receive Message = 01 05 00 13 18 00 F1 
16:04:19.035 TRACE o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:949]- Message is valid, sending ACK
16:04:19.035 TRACE o.o.b.z.i.p.ZWaveController[:152]- Incoming message to process
16:04:19.035 DEBUG o.o.b.z.i.p.ZWaveController[:153]- Message: class = SendData (0x13), type = Request (0x00), payload = 18 00 
16:04:19.035 TRACE o.o.b.z.i.p.ZWaveController[:173]- Message type = REQUEST
16:04:19.037 DEBUG o.o.b.z.i.p.ZWaveController[:379]- Notifying event listeners
16:04:19.037 TRACE o.o.b.z.i.p.ZWaveController[:381]- Notifying org.openhab.binding.zwave.internal.ZWaveActiveBinding@1df177b
16:04:19.037 DEBUG o.o.b.z.i.ZWaveActiveBinding[:374]- ZwaveIncomingEvent
16:04:19.037 TRACE o.o.b.z.i.p.ZWaveController[:381]- Notifying org.openhab.binding.zwave.internal.ZWaveNetworkMonitor@17eaaf2
16:04:19.037 TRACE o.o.b.z.i.p.ZWaveController[:381]- Notifying org.openhab.binding.zwave.internal.config.ZWaveConfiguration@d8a49d
16:04:19.038 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:901]- Response processed after 24ms/218ms.
16:04:19.038 TRACE o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:902]- Acquired. Transaction completed permit count -> 0
16:04:19.038 TRACE o.o.b.z.i.p.ZWaveController[:182]- Released. Transaction completed permit count -> 0

Looks like it's getting the reply, am I right?

Habmin still the same: image

cdjackson commented 10 years ago

Thanks. Have you removed anything out of this log? I don’t see a bunch of stuff from the SendDataMessage class?

petrklus commented 10 years ago

Yes, I filter for ZWAVE string (case-insensitive). Here are full logs: https://dl.dropboxusercontent.com/u/7395199/logs_5.zip

cdjackson commented 10 years ago

Thanks. The filter I use for this is o.o.b.z - this gets all the zwave binding stuff…

petrklus commented 10 years ago

cool! Also, I've got zwave:healtime unset - what should I set it to?

cdjackson commented 10 years ago

I have mine set to 2 (or 3?). This is the hour at which the binding will do a heal on the network. It reads all the neighbours and sets up any routes for associations that have changed…

cdjackson commented 10 years ago

Hmmm - so in the case that you send a command like this to a DEAD node, the response won’t make it come alive. It will only come alive when it receives a command class update which we don’t get in your case. I guess the devices don’t send out an update unless (maybe) associations are set of something like that…

I’ll change this so that at least it comes alive again, but as a question, do you have associations set on node 2?

petrklus commented 10 years ago

No, I've really not done anything to the configuration apart from following steps:

  1. unplug dongle, walk over to the freshly installed fibaro unit
  2. flip the light switch 3 times and watch association LED flash
  3. plug the unit back, use ozwcp to try out connections
  4. create items in OH and use those

So unless any of the above steps create associations, nothing like that has been done.

Lastly, why is the node marked as DEAD during the UPDATENEIGHBORS function (that is what I see in the heal status).

On Mon, May 5, 2014 at 4:32 PM, Chris Jackson notifications@github.comwrote:

Hmmm - so in the case that you send a command like this to a DEAD node, the response won’t make it come alive. It will only come alive when it receives a command class update which we don’t get in your case. I guess the devices don’t send out an update unless (maybe) associations are set of something like that…

I’ll change this so that at least it comes alive again, but as a question, do you have associations set on node 2?

— Reply to this email directly or view it on GitHubhttps://github.com/openhab/openhab/issues/1044#issuecomment-42193822 .

cdjackson commented 10 years ago

So unless any of the above steps create associations, nothing like that has been done. Nope - ok, that explains it… You might want to think about that at some stage.

Lastly, why is the node marked as DEAD during the UPDATENEIGHBORS function (that is what I see in the heal status). I’m not sure - is it in one of your logs?

petrklus commented 10 years ago

What is the purpose of the association groups?

Re. the message - this is the text I see in Habmin: image

Is it now in the assoc. group? Should I add every new node there when I get them? image

(after I did that, the node colour changed to YELLOW, heal status still the same though). Also, the controller update settings do not stick for node 2 - only for node 1 - does it make sense as only node 1 is controller?

cdjackson commented 10 years ago

What is the purpose of the association groups?

They allow a device to tell another device (or the controller) that something has happened. Eg, you can link two light switches so that pressing one will turn on another, or link a motion sensor to turn on the lights (associations can be set so the devices talk directly to each other - i.e. they don’t need the controller in the middle). They are also useful so that the device can tell OH that something has happened - e.g. when you turn on the lights, OH knows about it, and your GUI says the lights are on. Fibaro devices have a separate association group for this, but whatever group is used, you need to set an association to your controller (Node 1).

Re. the message - this is the text I see in Habmin:

Ok, this doesn’t mean the device went DEAD during the node neighbour update - it means the heal failed though. Neighbor updates seem a bit dodgy - especially if this is your controller. This (probably) isn’t an issue with the binding since I’ve been told the same happens with OZW. I don’t know why it fails - it seems to fail on the controller after about a minute, but I don’t really know what’s happening at the protocol level - it should do a search for all nodes it can hear, but I don’t know what happens at RF…

I’m looking at getting a packet sniffer - if I’m successful I might learn some more about this sort of thing...

petrklus commented 10 years ago

Ok, sounds interesting when I get more zwave devices, that I will link them together internally. Also, how come that my light switches on OH user interface got updated even without the association groups?

On Mon, May 5, 2014 at 5:00 PM, Chris Jackson notifications@github.comwrote:

What is the purpose of the association groups?

They allow a device to tell another device (or the controller) that something has happened. Eg, you can link two light switches so that pressing one will turn on another, or link a motion sensor to turn on the lights (associations can be set so the devices talk directly to each other

  • i.e. they don’t need the controller in the middle). They are also useful so that the device can tell OH that something has happened - e.g. when you turn on the lights, OH knows about it, and your GUI says the lights are on. Fibaro devices have a separate association group for this, but whatever group is used, you need to set an association to your controller (Node 1).

Re. the message - this is the text I see in Habmin:

Ok, this doesn’t mean the device went DEAD during the node neighbour update - it means the heal failed though. Neighbor updates seem a bit dodgy

  • especially if this is your controller. This (probably) isn’t an issue with the binding since I’ve been told the same happens with OZW. I don’t know why it fails - it seems to fail on the controller after about a minute, but I don’t really know what’s happening at the protocol level - it should do a search for all nodes it can hear, but I don’t know what happens at RF…

I’m looking at getting a packet sniffer - if I’m successful I might learn some more about this sort of thing...

— Reply to this email directly or view it on GitHubhttps://github.com/openhab/openhab/issues/1044#issuecomment-42196797 .

cdjackson commented 10 years ago

On 5 May 2014, at 16:07, petrklus notifications@github.com wrote:

Ok, sounds interesting when I get more zwave devices, that I will link them together internally. Also, how come that my light switches on OH user interface got updated even without the association groups?

Maybe you have polling enabled? Or some switches will send a message even without associations - these mostly seem to be used in the USA from what I’ve seen (I’m guessing you’re in Europe somewhere?).

petrklus commented 10 years ago

If I have, it needs to be the default setting :). Yes, Europe - Spain to be specific (bought from zwave.es).

On Mon, May 5, 2014 at 5:11 PM, Chris Jackson notifications@github.comwrote:

On 5 May 2014, at 16:07, petrklus notifications@github.com wrote:

Ok, sounds interesting when I get more zwave devices, that I will link them together internally. Also, how come that my light switches on OH user interface got updated even without the association groups?

Maybe you have polling enabled? Or some switches will send a message even without associations - these mostly seem to be used in the USA from what I’ve seen (I’m guessing you’re in Europe somewhere?).

— Reply to this email directly or view it on GitHubhttps://github.com/openhab/openhab/issues/1044#issuecomment-42198071 .