Z-wave node issues

Add-ons Bindings
1

In one of my rooms, I have a node (it is a gen 5 roller Qubino shutter, ZMNHCD), which does not work very good.
It will proably very seldom have contact with the zstick (gen 5 from aeon).

First I tried to heal the node, which made no difference, (did not check if the node actually got the heal message, probably not). Then I healed two neighbours, and finally I selected re-initialize on the bad node.

Anyway, for days it has now been offline, so I decided to investigate a little again.
What I did was to heal one of the very nearest neighbours, which revealed that it saw the bad node (it was in its neighbor list).
I then excluded/included the bad node again, in the hope that something good would come out. It didn’t.

Now, when I start up oh2, the zwave binding reports that the controller has a new node (67) that ought to be the bad device. However, no longer does it have node 66, which incidently is also a qubino gen 5 (but a dimmer) on the second floor just above the shutter.
The old shutter node address (60) is still in the controller list, however.

13:44:54.761 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 1: Node found
13:44:54.761 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 2: Node found
13:44:54.761 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 3: Node found
13:44:54.761 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 4: Node found
13:44:54.761 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 5: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 6: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 7: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 8: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 9: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 11: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 12: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 14: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 15: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 16: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 17: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 18: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 19: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 20: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 21: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 22: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 23: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 25: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 26: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 27: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 28: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 29: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 30: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 31: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 32: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 33: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 34: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 35: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 36: Node found
13:44:54.762 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 37: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 38: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 39: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 40: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 41: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 42: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 43: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 46: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 47: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 48: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 53: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 54: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 56: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 57: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 58: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 59: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 60: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 61: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 62: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 63: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 64: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 65: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 67: Node found
13:44:54.763 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 68: Node found
13:44:54.764 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 69: Node found
13:44:54.764 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller using Controller API
13:44:54.769 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller is Primary Controller
13:44:54.769 [INFO ] [age.SerialApiGetInitDataMessageClass] - ------------Number of Nodes Found Registered to ZWave Controller------------
13:44:54.769 [INFO ] [age.SerialApiGetInitDataMessageClass] - # Nodes = 58
13:44:54.775 [INFO ] [age.SerialApiGetInitDataMessageClass] - ----------------------------------------------------------------------------

Still 67 does not come online. But also (naturaly) 66 does show as off line.

Is this a bug in the Aeon stick? I used the sticks own exclude/include function, and while it seamed to work, the exclusion happened after 3 clicks on the node button after power on, not after 5 clicks as the manual said.
Edit: Reading the manual in detail, it says changes, so I think one click is two changes, which explains this.
So if I understand this correctly, it removed the wrong device. ?? Seams very fragile to me.

Then I look further down the log, and I see something that confuses me, but I guess this is something not related, but it is versy strange to see that node 66 is referenced in the same line as ‘online’.

13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Controller status changed to ONLINE.
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Controller is ONLINE. Starting device initialisation.
13:44:55.136 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising Thing Node...
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising channel zwave:device:controller:node66:switch_binary
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:switch_binary
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:switch_binary
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising state channel zwave:device:controller:node66:switch_binary
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising channel zwave:device:controller:node66:switch_dimmer
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:switch_dimmer
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:switch_dimmer
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:switch_dimmer
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:switch_dimmer
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising state channel zwave:device:controller:node66:switch_dimmer
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising channel zwave:device:controller:node66:sensor_binary
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:sensor_binary
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:sensor_binary
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising state channel zwave:device:controller:node66:sensor_binary
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising channel zwave:device:controller:node66:sensor_temperature
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:sensor_temperature
13:44:55.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:sensor_temperature
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising state channel zwave:device:controller:node66:sensor_temperature
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising channel zwave:device:controller:node66:meter_kwh
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:meter_kwh
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:meter_kwh
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising state channel zwave:device:controller:node66:meter_kwh
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising channel zwave:device:controller:node66:meter_watts
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:meter_watts
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:meter_watts
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising state channel zwave:device:controller:node66:meter_watts
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising channel zwave:device:controller:node66:alarm_general
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:alarm_general
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:alarm_general
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising state channel zwave:device:controller:node66:alarm_general
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising channel zwave:device:controller:node66:switch_binary1
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:switch_binary1
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:switch_binary1
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising state channel zwave:device:controller:node66:switch_binary1
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising channel zwave:device:controller:node66:switch_dimmer1
13:44:55.137 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 40: Restore from config: Ok.
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:switch_dimmer1
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:switch_dimmer1
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:switch_dimmer1
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:switch_dimmer1
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising state channel zwave:device:controller:node66:switch_dimmer1
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising channel zwave:device:controller:node66:meter_kwh1
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:meter_kwh1
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:meter_kwh1
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising state channel zwave:device:controller:node66:meter_kwh1
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising channel zwave:device:controller:node66:meter_watts1
13:44:55.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:meter_watts1
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:meter_watts1
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising state channel zwave:device:controller:node66:meter_watts1
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising channel zwave:device:controller:node66:sensor_binary2
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:sensor_binary2
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:sensor_binary2
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising state channel zwave:device:controller:node66:sensor_binary2
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising channel zwave:device:controller:node66:alarm_general2
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:alarm_general2
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:alarm_general2
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising state channel zwave:device:controller:node66:alarm_general2
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising channel zwave:device:controller:node66:sensor_binary3
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:sensor_binary3
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:sensor_binary3
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising state channel zwave:device:controller:node66:sensor_binary3
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising channel zwave:device:controller:node66:alarm_general3
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising cmd channel zwave:device:controller:node66:alarm_general3
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising poll channel zwave:device:controller:node66:alarm_general3
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Initialising state channel zwave:device:controller:node66:alarm_general3
13:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Polling intialised at 1800 seconds - start in 1800000 milliseconds.

So I guess I will now exclude both the dimmer (66) and the shutter (60/67).
@chris is this something you have seen, or can explain?

Edit: And later on, I see a poll on 66!?

14:44:55.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Polling...
14:44:55.139 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 66: Polling deferred until initialisation complete
2

I don’t see anything too strange here. Inclusion and exclusion can be a bit random, so I think I have seen this sort of thing where you end up with phantom nodes.

This is simply stating that the controller is online - not that node 66 is working. It’s associated with the initialisation of the thing handler - not the device.

Regarding heal, the theory is that healing should be autonomous within the network. The heal function only configures some routes and checks for neighbors, but I don’t know that it will really fix a dead node if it’s really dead - if the controller can’t automatically heal it itself, then running the binding heal probably won’t help a lot.

3

But isn’t it strange that another node just disappeard from the stick, just like that? I mean, nodes that I exclude normally does not get removed from the stick - their bit is still set. But this node is just gone.

Now i excluded both the dimmer(66) and the shutter(60/67) again. And the shutter came online as node 70. But now the dimer(66), which I guess is now 71 does not. I guess I will wait a while, but the zwave log says it is Dead, so I guess I will have to exclude again and hope the shutter will not disappear this time.

4

To be honest, it’s hard to follow what you’ve done, and hard to verify without a log. If you exclude a device, and add it back, it will have a different node address - this is normal.

They should be removed - this is the way it works. If you exclude a device using the controller exclusion function, it will remove it from the stick and it will be gone - all perfectly normal.

5

I excluded one device, but lost two.

Well, all the nodes that I have removed using the stick is still marked in stick the node bitmap. The only node that has disappeared from the stick bitmap is the one that I never excluded, the one that disappeard when exlucing another. This has to be a bug in the Aeon stick, not normal.

Remeber, in zwave, you can use any controller to exclude a node, so there’s no way for the ‘main controller’ to know this.
Of course there may be a special function that allows the controller to clear the bit from its own bitmap. But Aeon gen 5 does not do this, which can be seen on the log snippets above. Both node address 60, 67 and later 70 are marked in the bitmap. Same node after multiple exclusions/inclusion.

6

That’s not correct. The main controller should receive updates from other controllers. I forget if this is automatic or if it needs to be requested - for sure there is a function to do it manually, but I think it’s also meant to happen automatically for the primary controller.

This is also the purpose of the SUC - and the SIS - to make sure that the system doesn’t loose sync.

Maybe you have a more complex configuration, but in any case, as I said above it’s hard to follow without logs.

7

I confirmed that the network update should be automatic so long as you have the SUC configured in your network.

8

Well, if the node where online in the first case, and all was well, it could. But not if the node is marked dead. Let’s say I take my controller over to your house, exclude one of your nodes which are dead - now how can your controller to know the node has been deleted. My controller is not within your network, and your network does not see the missing node.

Anyway, there’s only fact with regards to my Aeon - bits are still there as can be readily seen. And there’s nothing to log, since I used exclusion with the button on the stick. i.e. binding is not around.

9

Ok - if you’re taking devices to another network to exclude them, then yes, I agree that the main network will simply think the device is dead. But if that’s what you’re doing, then I’d suggest you are working well outside of the envelope on which the system is designed!

However, if you’re excluding devices using a secondary controller that is part of a properly configured network, then the primary controller should automatically update. This is part of the system design.

10

No, I am not doing that. I am using my stick which are my main master controller, to remove the nodes. I was just trying to prove that I don’t think bits are supposed to be removed from the master controller. Maybe I’m wrong, but then so is the Aeon firmware, since it simply does not do this. Only on the node it removed by itself, which I found strange.

I remember this was also like this on the Vera.

11

Do you have an SUC in your network? If so, and if it’s the Gen5, then I believe this should work. If you don’t have an SUC, then you are correct and it won’t work.

12

My only controller is not SUC. So if I configure it to be SUC, will it then delete the bits? I can try this the next time, since my dimmer (71) still has not arrived (marked dead).

13

I believe so - at least this is how I read the (slightly old!) ZWave documentation I have :wink:

A Z-Wave network consists of slaves, a primary controller and secondary controllers. New nodes can only be added and removed to/from the network by using the primary controller. It could cause secondary controllers and routing slaves to misbehave, if for instance a preferred repeater node is removed. Without automatic network update, a new replication has to be made from the primary controller to all secondary controllers, and routing slaves should also be manually updated with the changes. In networks with several controller and routing slave nodes, this process will be cumbersome.

To automate this process, an automatic network update scheme has been introduced to the Z-Wave protocol. To use this scheme a static controller must be available in the network. This static controller is dedicated to hold a copy of the network topology and the latest changes that have occurred to the network. The static controller used in the Automatic update scheme is called the Static Update Controller (SUC).

Each time a node is added, deleted or a routing change occurs, the primary controller will send the node information to the SUC. Secondary controllers can then ask the SUC if any updates are pending. The SUC will then in turn respond with any changes since last time this controller asked for updates.

From this, I would say that if your Gen5 is the SUC, then it should be updated automatically. There are also methods available to force this manually which aren’t implemented in the binding - I can probably add this reasonably easily (feel free to create an issue if you like).

14

Made my Aeon5 stick SUC, saved waited about 5 minutes, exited oh, picked up the stick, and excluded the dead node (71).
Now after starting again 71 are still shown in the nodelist of the stick.

Maybe SUC needs to be selected from first start, I don’t know. Anyway, I entered an issue for that manual solution - I certainly need it, maybe that will clear a lot of problems I have had.
I hope I added the isse at the correct place, new to github… :worried:

Also, once you have added this, (I’m hoping :slight_smile: ), is there a way to kick the ‘automatic update scheme’ from the docs of yours, also ? I think maybe my larg-ish network with its routing slaves might love this spa-treatment.

As a side note, I tried for the first time, network wide inclusion, for this node - it did’nt work, should it? Is network wide also working outside of the direct range of the controller?

15

Yes - that’s what I would implement. I’d probably make it a manual option, but possibly also do a nightly update as well.

Well, it should, but I don’t think I’ve ever tried it as I’ve not got devices to support it.

Yes - that’s the theory (otherwise it would just be normal inclusion :wink: ).

16

Once you mention it… :slight_smile:
Anyway, there are probably many reasons that this failed, so I’m going to ignore it. I normally like manual stick include anyway.

17

So, FYI I implemented this method and found it didn’t work on my system. I then re-read the explanation and found that it doesn’t work if the controller in question is SUC -:

Returns FALSE If the requesting controller is the SUC node or the SUC node is unknown.

So, I don’t think this will help you. It points to the fact that this should already work if the controller is the SUC.

Anyway, I’ll add the feature to the binding and we can see if it works in other situations…

18

Well, since SUC or not did not change the behavior on my Aeon5 stick, I can try to make it non-SUC again, and then try the feature?
It might be that the controller have to be SUC when finding the node for the first time (why, I don’t know, but that is the one explanation I can come to think of).
Or rather - Aeon has a button, don’t think anyone else do - maybe they did not implement this properly when using the button exclusion method?

Anyway, I’d like to test as non-SUC. Will it arrive in the advanced menu? And will I be able to select nodes to remove, or will it just wipe the once that are not around (fully online)?

19

You will of course need to have a different controller that is configured as a static update controller. Do you have another static controller (I guess not as it’s only possible to have one). If so, you could try this.

Your other guesses are as good as any - who knows… The documentation I have is quite old - certainly not Gen5/ZWPlus, but you’d expect this to be backward compatible which ZWave is in general…

I’ll merge this in the next day or so.

20

No, I don’t. I thought perhaps it was possible to tell the controller to wipe out certain nodes over the API, but I guess you are saying it needs to be managed between two controllers. And reading the citation again confirms this. So ok.

I was mostly interested in the part

It could cause secondary controllers and routing slaves to misbehave, if for instance a preferred repeater node is removed.

i.e. the routing slave part. To me it sounds as only a primary controller along with routing slaves could break things.

Well, after yet another exlusion/inclusion all my devices (except one in the basement) are online again, so I’m good for now. But I must say zwave is rather fragile, and I dread for adding more devices, which I know I need to, since I’m missing a few. And at least during start-up all the zombie nodes on the stick uses energy and time for the binding to start up, so if for nothing else it would be nice to not having them.

I’ll ask Aeon if it was their intention to leave the old nodes on the stick when doing button-exclusion. Who knows, maybe they will answer, they has surprised me before…