I’m not sure I 100% understand what you mean, but if you mean that the API should be able to delete/exclude nodes, then yes, this should work. The big question is what happens if you’re deleting nodes through another controller… Clearly here I’m less clear and am only going on the documentation…
I think what this refers to is if you delete a device using a controller, and the primary controller doesn’t know and is still trying to route traffic via this router/repeater, then it will break the system (at least, that’s how I interpret that).
Their support is normally pretty responsive - the issue will be that the support is in the US, and the people who do the programming are in China and there seems to be some issues getting information from China to the US… I’m sure they will try and get the info though, so let’s see - it might provide another piece of the puzzle…
Yes, this is what I meant. So then this is possible, wow! But it is no support for this in the binding/UI I presume?
In turn, I am unsure what you mean by
In the end, what I have now, is a primary controller that has zombie nodes. While I got them by using button-exclude on the same controller, shouldn’t make difference should it? I mean if they where exluded by another controller, they would still be zombies on my primary. i.e. it is only the nodes themselves that are wiped, not the node information on the stick. (at least this is how I understands it, without having any fact of course).
But also, and perhaps worse; nodes that are on the outside of this routing slave, may not know how to reach the controller if it disappears some hops away?
Yes - you can include, and exclude, and remove nodes with the UI.
To include, use the Discovery button in OH2
To exclude, select the controller, go to Tools, select “Advanced Settings”, then select the exclude option. This will put the controller into exclude mode for 30 seconds.
To remove zombi nodes, you will need to add the device as a thing. Then go to the Tools menu, select advanced settings, and then you will have options to “move the node to the failed nodes list” and to “delete the node”. You can only remove nodes that the controller thinks has failed, so if the controller thinks the device is still alive (which is normal for battery devices!) then you need to move to the failed list first, then you can (hopefully!) delete the node. Again, the controller can decide itself not to do this if it thinks the device is really still alive.
I misunderstood what you were doing - I previously thought that you were removing nodes using a second controller - hence the idea that the SUC should help.
The mech network is meant to sort itself out using discovery frames, but this relies on having enough nodes in the network, and they need to support the discovery frames (which isn’t especially new, but probably is only available on devices that are a few years old).
The function to synchronise the controller with the SUC is now implemented -:
This adds a menu option to the controller to synchronise it with the SUC. This obviously only works if there is an SUC/SIS in the network, and also only if the OH controller is not the SUC.
Great! Will try this. I just got reply from aeon that they have open a ticket for my issue. I can actually see that some nodes has been removed from the stick, while others has not. Not sure if it is related to gen5 nodes being the issue, or something else.
Aeon suggested to use the zensys tool to remove nodes, but doing it through habmin is much easier of course.
Just the same as any other device - when a message times out three times. However, messages are not sent when the device is sleeping, so it won’t show DEAD when sleeping. Likewise, if you remove the battery, it won’t show dead since the device will not wake up so no messages get sent to it.
