dastrix80
January 8, 2019, 8:09pm
433
Hi @chris
Overnight these devices have popped back up after removing them from the controller using the thing.
How can I remove them? Node 17,21 are duplicates of the working node 22. There is also node 227, no idea where that came from! Node 7 was the one I excluded, its the same device also.
The nodes go offline after a while but as soon as I remove them from the controller they come back online.
Also, did you by any chance have any time to look at the Zwave Map we discussed when using two controllers and the lack of map when using two controllers?
Cheers
chris
January 9, 2019, 7:48am
434
In the thing configuration, there is a boolean option called “Remove device from controller”. You need to enable this and save the thing. This may or may not work (it is still up to the controller to decide!) - if it doesn’t you may need to use the Zensys tool.
dastrix80
January 9, 2019, 7:54am
435
Hi chris yes i tried that. fails for these nodes. Whats odd is they are online but are old versions of the real thing. I looked into zensys but even it cant even see them.
The UI’s are showing Nodes that arent even on the Controller
Node 2, 7, 17, 21
dastrix80
January 9, 2019, 8:49am
436
Even deleting the XML files makes no difference, they return back into the UI
chris
January 9, 2019, 9:55am
437
Correct - it is not related to the binding. The problem is the devices need to be removed from the controller.
c_nagel
January 9, 2019, 10:04am
438
Hi @chris ,
my actual problem occurred after the recently applied z-wave binding upgrade. I followed your instructions step by step. Every single z-wave component of my little smarthome was re-recognized and I could use my existing sitemap, item definitions, and rules.
And, yes: I checked that the default region is set properly.
But now the thermostat setpoints for the Danfoss Living Connect thermostats which I change via sitemap are not transferred to the thermostats anymore unless I wake them up twice (!) manually.
In contrast: the Comet Z thermostat is working absolutely reliable, I have no problems at all changing the temperature setpoint.
I wanted to ask you to have a look at the log file. It starts at the point when I started debug mode today at around 5:35 p.m.
openhab.log (341.9 KB)
Node 27: Comet Z thermostat
Node 21: one of the Danfoss Living Connect thermostats
First you’ll see the successful change of the Comet Z thermostat setpoint (between 5:25 an 5:41 p.m.).
The next event was to try to change the setpoint for node 21 without waking up the thermostat manually (between 5:38 an 5:43 p.m.).
At last I changed the setpoint again via sitemap (iPhone App) but did a double manual wakeup (from 5:48 to 5:49 p.m.).
Thanks a lot in advance for your comment and recommendation on that phenomenon!
Many regards from Berlin
Christoph
dastrix80
January 9, 2019, 10:06am
439
But the devices are not known to the controller because under NODES on Zensys they are not present. So how do you remove a node not on the controller? Am I right in saying that if I factory reset the controller it will wipe all inclusions and reset the node ID so I can start again? I think thats what I may need to do.
I will of course need to reinclude all my devices and revise my items files with the new IDs
chris
January 9, 2019, 10:42am
440
If they are not on the controller, then they will not appear during startup in the inbox, so just remove the things.
dastrix80
January 9, 2019, 10:43am
441
They aren’t on the controller - see the screenshots above. Yet they are in PaperUI.
It sounds so simple but it’s clearly not or I’m totally retarded.
Node 227, another one…Let me assure you, its appearing in the inbox
chris
January 9, 2019, 10:44am
442
Sorry - you’ve probably posted this somewhere, but is there a description of your problem? I scrolled up a few days, but haven’t seen anything.
c_nagel
January 9, 2019, 10:48am
443
@chris , the description is in the same post a few lines further down:
chris
January 9, 2019, 10:53am
444
Ah - ok, from the way it was worded I thought you were referring to something above. No problem - just my (mis)understanding
I’ll take a look at the log
c_nagel
January 9, 2019, 10:55am
445
chris:
Ah - ok, from the way it was worded I thought you were referring to something above.
Oh, yes, you’re right - sorry for the confusion …
1 Like
chris
January 9, 2019, 12:21pm
446
It looks to me like the data is being transferred through ok after the device wakes up -:
Here we see a command to set the setpoint to 22 -:
The device wakes up almost immediately, and the command to set the temperature is sent, and read back, and the state updated. This all happens within 1/2 second of the wakeup.
This command gets received just fine, and is queued. The device doesn’t wake up before you send it another command, so this is overridden by the command above to set the temperature to 25.
Again, I don’t see any problem. I’m not sure what your wakeup period is - you don’t say you manually woke the device up at this time (5:43) so I assume this is the device waking up normally, which is fine.
Or maybe I miss something?
Selter
January 9, 2019, 8:23pm
447
Just to make sure …
When updating oH 2.3 to 2.4: one has to do the update first - and after that remove z-wave things via Paper UI - right?
sihui
January 9, 2019, 8:28pm
448
Selter:
right?
Yes, in whatever sequence. You may also do it the other way around.
dastrix80
January 9, 2019, 11:33pm
449
Hi All
Ive factory reset all devices, deleted ALL things, deleted all the XMLs and still, using the latest Zwave snapshot issues.
This is with the Fibaro Dimmer FGD212.
The pairing works fine, the thing is online and the controller are online. I cannot set the LifeLine and this is reflected in the log as:
10-Jan-2019 10:17:00.484 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Command received zwave:device:08bf3c5b:node4:switch_dimmer1 --> OFF [OnOffType]
10-Jan-2019 10:17:00.511 [DEBUG] [.internal.converter.ZWaveMultiLevelSwitchConverter] - NODE 4: Command class SWITCH_MULTILEVEL not found when processing command on endpoint 1
10-Jan-2019 10:17:00.511 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: No messages returned from converter
10-Jan-2019 10:19:09.910 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Configuration update received
10-Jan-2019 10:19:09.911 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Configuration update set group_1 to controller (String)
10-Jan-2019 10:19:09.911 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Unknown association group 1
10-Jan-2019 10:20:35.837 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Command received zwave:device:08bf3c5b:node4:switch_dimmer1 --> ON [OnOffType]
10-Jan-2019 10:20:35.838 [DEBUG] [.internal.converter.ZWaveMultiLevelSwitchConverter] - NODE 4: Command class SWITCH_MULTILEVEL not found when processing command on endpoint 1
10-Jan-2019 10:20:35.839 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: No messages returned from converter
10-Jan-2019 10:22:12.586 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Channel zwave:device:08bf3c5b:node4:meter_watts unlinked - polling stopped.
10-Jan-2019 10:22:12.588 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Channel zwave:device:08bf3c5b:node4:switch_dimmer1 unlinked - polling stopped.
10-Jan-2019 10:22:12.589 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Channel zwave:device:08bf3c5b:node4:switch_dimmer1 unlinked - polling stopped.
10-Jan-2019 10:22:12.590 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Channel zwave:device:08bf3c5b:node4:meter_kwh unlinked - polling stopped.
10-Jan-2019 10:22:12.591 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Channel zwave:device:08bf3c5b:node4:meter_watts unlinked - polling stopped.
10-Jan-2019 10:22:12.591 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Channel zwave:device:08bf3c5b:node4:switch_dimmer1 unlinked - polling stopped.
10-Jan-2019 10:22:12.592 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Channel zwave:device:08bf3c5b:node4:meter_kwh unlinked - polling stopped.
10-Jan-2019 10:22:12.593 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Channel zwave:device:08bf3c5b:node4:switch_dimmer1 unlinked - polling stopped.
10-Jan-2019 10:26:01.604 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Channel zwave:device:08bf3c5b:node4:switch_dimmer1 linked - polling started.
10-Jan-2019 10:26:01.605 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Channel zwave:device:08bf3c5b:node4:switch_dimmer1 linked - polling started.
10-Jan-2019 10:26:01.605 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Channel zwave:device:08bf3c5b:node4:meter_watts linked - polling started.
10-Jan-2019 10:26:01.606 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Channel zwave:device:08bf3c5b:node4:meter_kwh linked - polling started.
10-Jan-2019 10:28:05.744 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Configuration update received
10-Jan-2019 10:28:05.745 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Configuration update set group_1 to controller (String)
10-Jan-2019 10:28:05.745 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Unknown association group 1
Does anyone know why?
I’m also seeing issues on a Aeotec device still, but it seems to work (STUCK IN GET_CONFIGURATION)
None of these devices are Battery
10-Jan-2019 10:16:06.049 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_BASIC, value = 96
10-Jan-2019 10:16:06.050 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Updating channel state zwave:device:08bf3c5b:node2:switch_dimmer to 96 [PercentType]
10-Jan-2019 10:16:06.050 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: Commands processed 1.
10-Jan-2019 10:16:06.051 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@545251cc.
10-Jan-2019 10:16:06.897 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling...
10-Jan-2019 10:16:06.898 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling deferred until initialisation complete
10-Jan-2019 10:16:09.491 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Command received zwave:device:08bf3c5b:node2:switch_dimmer --> OFF [OnOffType]
10-Jan-2019 10:16:09.492 [TRACE] [.internal.converter.ZWaveMultiLevelSwitchConverter] - NODE 2: Converted command 'OFF' to value 0 for channel = zwave:device:08bf3c5b:node2:switch_dimmer, endpoint = 0.
10-Jan-2019 10:16:09.492 [DEBUG] [col.commandclass.ZWaveMultiLevelSwitchCommandClass] - NODE 2: Creating new message for command SWITCH_MULTILEVEL_SET
10-Jan-2019 10:16:09.493 [TRACE] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 2: Encapsulating message, endpoint 0
10-Jan-2019 10:16:09.493 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 2: SECURITY not supported
10-Jan-2019 10:16:09.494 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 2: Command Class COMMAND_CLASS_SWITCH_MULTILEVEL is NOT required to be secured
10-Jan-2019 10:16:09.494 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: Adding to device queue
10-Jan-2019 10:16:09.494 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: Added 408 to queue - size 3
10-Jan-2019 10:16:09.495 [TRACE] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 2: listening == true, frequentlyListening == false, awake == false
10-Jan-2019 10:16:09.496 [TRACE] [nhab.binding.zwave.internal.protocol.SerialMessage] - NODE 2: Creating empty message of class = SendData (0x13), type = Request
10-Jan-2019 10:16:09.497 [DEBUG] [g.openhab.binding.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 0A 00 13 02 03 26 01 00 25 6D 88
10-Jan-2019 10:16:09.499 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling intialised at 86400 seconds - start in 1500 milliseconds.
10-Jan-2019 10:16:09.510 [DEBUG] [ternal.protocol.serialmessage.SendDataMessageClass] - NODE 2: sentData successfully placed on stack.
10-Jan-2019 10:16:09.511 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: TID 408: Transaction not completed
10-Jan-2019 10:16:09.526 [DEBUG] [ternal.protocol.serialmessage.SendDataMessageClass] - NODE 2: SendData Request. CallBack ID = 109, Status = Transmission complete and ACK received(0)
10-Jan-2019 10:16:09.527 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: Response processed after 30ms
10-Jan-2019 10:16:09.527 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: TID 408: Transaction completed
10-Jan-2019 10:16:09.528 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: notifyTransactionResponse TID:408 DONE
10-Jan-2019 10:16:09.528 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
10-Jan-2019 10:16:10.235 [TRACE] [nhab.binding.zwave.internal.protocol.SerialMessage] - NODE 2: Message payload = 00 02 03 20 03 00
10-Jan-2019 10:16:10.237 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: Application Command Request (ALIVE:GET_CONFIGURATION)
10-Jan-2019 10:16:10.237 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 2: Incoming command class COMMAND_CLASS_BASIC, endpoint 0
10-Jan-2019 10:16:10.237 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 2: SECURITY not supported
10-Jan-2019 10:16:10.237 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 2: Received COMMAND_CLASS_BASIC V1 BASIC_REPORT
10-Jan-2019 10:16:10.238 [DEBUG] [ernal.protocol.commandclass.ZWaveBasicCommandClass] - NODE 2: Basic report, value = 0
10-Jan-2019 10:16:10.238 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
10-Jan-2019 10:16:10.238 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_BASIC, value = 0
10-Jan-2019 10:16:10.238 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Updating channel state zwave:device:08bf3c5b:node2:switch_dimmer to 0 [PercentType]
10-Jan-2019 10:16:10.239 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: Commands processed 1.
10-Jan-2019 10:16:10.239 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@5cfbbb03.
10-Jan-2019 10:16:10.999 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling...
10-Jan-2019 10:16:10.999 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling deferred until initialisation complete
10-Jan-2019 10:16:32.805 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 2: ZWaveCommandClassTransactionPayload - send to node
10-Jan-2019 10:16:32.805 [TRACE] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 2: Encapsulating message, endpoint 0
10-Jan-2019 10:16:32.805 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 2: SECURITY not supported
10-Jan-2019 10:16:32.806 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 2: Command Class COMMAND_CLASS_CONFIGURATION is NOT required to be secured
10-Jan-2019 10:16:32.806 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: sendTransaction org.openhab.binding.zwave.internal.protocol.transaction.ZWaveCommandClassTransactionPayload@68289a35
10-Jan-2019 10:16:32.807 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: Adding to device queue
10-Jan-2019 10:16:32.807 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: Added 409 to queue - size 3
10-Jan-2019 10:16:32.808 [TRACE] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 2: listening == true, frequentlyListening == false, awake == false
10-Jan-2019 10:16:32.809 [TRACE] [nhab.binding.zwave.internal.protocol.SerialMessage] - NODE 2: Creating empty message of class = SendData (0x13), type = Request
10-Jan-2019 10:16:32.809 [DEBUG] [g.openhab.binding.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 0A 00 13 02 03 70 05 7A 25 6E A3
10-Jan-2019 10:16:32.824 [DEBUG] [ternal.protocol.serialmessage.SendDataMessageClass] - NODE 2: sentData successfully placed on stack.
10-Jan-2019 10:16:32.825 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: TID 409: Transaction not completed
10-Jan-2019 10:16:32.844 [DEBUG] [ternal.protocol.serialmessage.SendDataMessageClass] - NODE 2: SendData Request. CallBack ID = 110, Status = Transmission complete and ACK received(0)
10-Jan-2019 10:16:32.845 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: TID 409: Transaction not completed
10-Jan-2019 10:16:37.846 [DEBUG] [ocol.ZWaveTransactionManager$ZWaveTransactionTimer] - NODE 2: TID 409: Timeout at state WAIT_DATA. 3 retries remaining.
10-Jan-2019 10:16:37.846 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
10-Jan-2019 10:16:37.846 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 2: notifyTransactionResponse TID:409 CANCELLED
10-Jan-2019 10:16:37.848 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 2: Node Init response (8) org.openhab.binding.zwave.internal.protocol.ZWaveTransactionResponse@7163e3e0
10-Jan-2019 10:16:37.848 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 2: No data from device, but it was ACK'd. Possibly not supported? (Try 8)
dastrix80
January 10, 2019, 9:48am
450
I had to factory reset things a few times and eventually it all came back… what a darn nightmare!
Hopefully with a clean slate things will improve, it would appear the inclusion process was problematic at least a few times before I finally got it right.
dopeyr
January 10, 2019, 12:42pm
451
Hi @chris , I’ve updated openhab to 2.4 stable and I’ve installed snapshot version of the binding. Here’s the output https://pastebin.com/uyUSH6ze (Node 24) - I see the message:
2019-01-10 12:31:07.463 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 24: Alarm converter NOTIFICATION event is 23, channel alarm_access is not implemented.
Interestingly, I noticed I do see the channel listed in PaperUI:
Snapshot version:
openhab> bundle:list -s|grep zw
263 x Active x 80 x 2.5.0.201901092308 x org.openhab.binding.zwave
Please let me know if there’s anything else you need.
Thanks,
jwiseman
January 10, 2019, 8:37pm
452
Hi Chris!
Can you point me in the right direction if there is one?
I have a zWave network at home working great with your v2.5 build. At work; I’d like to add a few zWave devices and have them send their status over the Internet to my controller at home.
I know natively zWave is NOT IP based but I thought I’d ask the best way to accomplish this? I have control of the firewall on both sides of the equation.
I saw this on the Internet about “maybe” how this could be done but it’s a bit over my head.
Best, Jay
.
