Help needed with excluding a device

I have this new ZWave device, ABUS SHBW10000 PIR Mulitsensor, which at first seemed to work fine, but now behaves really weird. I wanted to exclude it, remove it from OH, reset it to factory defaults and start over from scratch (with the device). It should be easy, but I have no fricking idea how this is supposed to work. I tried to “remove from controller”, I tried to set it failed, I restarted OH, I soft reset the controller, this and that, over and over. It always comes back in the Inbox… I tried “Exlcude Devices” in the controller config. Nothing.
It certainly doesn’t help that I can’t see it’s state at the device itself (included or excluded). I don’t even see if it is powered or not. But in any case it’s current view of the world should be visible in the OH ZWave config. I should get clear feedback. I remove the device in different ways, it seems gone, but apparently this is not true. ZWave Binding, Controller, OH - it’s unclear, I see no feedback, but something still knows the device and shows it again in the Inbox.
Quite frankly, it’s just super unintuitive and utterly confusing! Frustrating…

What is the difference between the (+) in the Inbox and the little antenna symbol? Both search or scan, but what for? Which one is responsible for ZWave inclusion? And then what does the other one do?
What means “Set device as FAILed”? Not a hint in the UI…
What means “Remove device from controller”? Not a hint in the UI… Does it start the exclusion process for this device?
What is the controller option “Exclude devices”? Exclusion mode, yes… but compared to the above? If the above means “exclude this single device”, then is “Exclude devices” removing all my devices when I hit the button? I better not do that…
I can delete the Thing, I expect it force removes the ZWave device from the controller. But it comes back.
Did I exclude the device? No idea. How can I be sure the device is really excluded? I hit (+) in the Inbox, it’s back…

All I got so far is the device now found with a new node id, and a zombie Thing with the previous node id of the device. Which I have even less a clue how to get rid of…

Any help appreciated how to permanently get rid of the two things and get to a defined state again!

I’ve only ever done this from Habmin. Excluding works the same as inclusion. You put the controller into exclusion mode, which I do in Habmin but think might be possible in PaperUI now (that’s what the Exclude Devices would be), and then you need to press the button or flip the switch or do what ever the manual for the device says you need to do to exclude it. Usually you do the same thing you would do to include it in the first place.

NOTE: The device does not need to be a member of the controller to exclude it.

The scan button will look for any undiscovered devices using the selected binding. The + symbol will initiate a scan using the selected binding but also give you the option to manually create an Thing which is required in a number of cases (e.g. to create the Zwave Controller Thing).

Any undiscovered devices handled by the selected binding.

I think both will work for Zwave but am not certain. But initiating a scan using either the + or the antenna icon and selecting the zwave binding will put the controller into inclusion mode for 30 seconds IIRC.

Zwave, as with any technology that OH supports, has to make the assumption that the users have at least a basic understanding about how the underlying technology works. If a device is not working, you can manually set it as failed prior to removing the device from the controller. But I think the controller need to have tried to communicate with the device a bunch of times and failed to get a response before it will let you mark it as failed. If it’s working you can’t set it as failed. In that case you need to exclude the device.

Exclusion mode is like inclusion mode. It puts the controller into a state where it listens for messages from devices that may or may not be a part of it’s network. In inclusion mode, when it gets that message it will add that device to it’s network. In exclusion mode, it will essentially factory reset the device. But in both cases, you put the controller into the mode and then you press the button on the device you want to include/exclude.

The node is part of the controller. As long as the controller has that node included as part of it’s network it will be discovered as a Thing by the binding.

Then you didn’t exclude the device. If you have a controller with a light, often the light will turn on when it’s in one of the modes and then blink a few times when the device is included/excluded. You can be sure it’s included when it doesn’t show up in the Inbox.

The zombie nodes are almost certainly not working so you should be able to mark them as failed and then remove them from the controller. To remove the working node you need to put the controller into exclusion mode and then press the button or take the action described in the device manual to reset the device.

If I’ve messed up any of my explanations above I’m sure someone will come and correct me.

1 Like

Thanks for your detailed answer!

Yea, I even suspect the zombie node is what “broke” the device. It always get’s stuck after a short time working. (Or it’s really broken. But I’ll get to that once I got rid of the zombie node)
I was actually able to successfully exclude the “new” node now. But I still fail at the zombie node.

Set failed, remove from controller, delete Thing, let sit over night and wait for magic stuff to happen … no effect. It always comes back.

When I try to set FAILed:

2020-04-21 14:14:37.265 [DEBUG] [essage.ReplaceFailedNodeMessageClass] - NODE 4: Marking node as having failed.
...
2020-04-21 14:14:37.271 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 4: Replace failed node failed as node is functioning!
...
2020-04-21 14:14:38.036 [DEBUG] [rialmessage.IsFailedNodeMessageClass] - NODE 4: Is currently marked as healthy by the controller

Your suggestion below to exclude it does not work, as the device thinks it’s excluded already. And when I include again I get a new node…

When I try to “Remove device from controller”

2020-04-21 14:13:41.466 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 4: Remove failed node failed as node not found

Conclusion: it’s working fine, but it’s not found… hmm…

Any other idea how to force remove that node from the controller?

Still not sure what this is supposed to do :slight_smile:

Yes, in general this is understood. It was just not clear to me how to do it in OH. And how the above option (“Exclude devices”) relates to the “Remove from controller option”. Maybe “Exclude devices” just kicks out all devices? After all it sits next to other internal options like soft or hard reset. That was my thinking, and why I was not sure whether I should really hit that button :wink:

I believe inclusion/exclusion of devices is such a common task with Zwave that it should be more prominent. Maybe with OH 3.0? With an obvious place to start the process, a dialog, asking you to do the needful at the device within 30s and then tell me the result. Currently it looks rather like a debug or failure mitigation thing in the UI.

The point is that I don’t see that anywhere. I only see the Thing. And when I delete it, it seems gone.
If it’s not able to remove it from the controller, then it should tell me that removal failed and not remove it, instead of pretending that it has been removed. Or something like that.

Problem was that the feedback at the device is the same for inclusion and exclusion, LED lights up for 2s. And at some point I had no clear idea what current state was. And: I did not know what I should see where in OH. So clear user guidance of the process in OH would help a lot.

The error is showing you that somehow Node 4 is still responding. Maybe try excluding the device again. Are you certain node 4 is this same device? Is this a battery powered device? Maybe it needs to be disconnected longer.

It couldn’t mark the node as failed because the controller still thinks it’s working. And since it’s not marked as failed, the binding can’t find a failed node to remove from the controller.

  1. If a node is not working (based on what the controller thinks) mark it as failed and then you can remove it from the controller. Only a failed node can be “removed from the controller.”
  2. If a node is working (based on what the controller thinks) go into exclusion mode and press the button on the device.

In both cases the steps remove the node from the controller. You cannot do 1 if the node is “working”. You cannot do 2 if the node is “not working”.

But openHAB is built to support hundreds of different technologies. There is necessarily a lowest common denominator in what is made prominent and what is not and in how it all works. I’ve no doubt that the binding developer made this as prominent as was possible given the constraints of OH overall. In short, I would count on it. Just about all the binding developers have to squeeze how one interacts with the technology into the visual “language” OH provides for all the bindings.

And Inclusion and Exclusion of devices are common up front when first setting up OH but for most of us something that is very rarely done after that. It’s been years since the last time I did either.

This is/should all be explained in the binding docs.

Which takes me back to what I said previously. You have to have a basic understanding of how the technology works. This is part of that basic knowledge of the technology that OH can only do so much to help you with. Stuff that is specific to the technology like this is either documented in the binding docs or it is part of the base knowledge that you have to come to OH with in order to use it successfully.

The Zwave binding is one of around 350 supported bindings, each of which connects to a different API or technology and each of which has it’s own conventions and ways of discovery and integration with OH.

The Thing isn’t the Node. A Thing is an openHAB concept and has nothing to do with Zwave. And given how Zwave works, deleting the node from the controller when you delete the thing is impossible because you have to perform a physical action on the device to complete an exclusion.

The Thing is a representation of the node in openHAB. If you delete the Thing you’ve only deleted the representation.

All I can suggest is to file an issue on the zwave binding docs to add some clarification.

But also realize, the Zwave binding works will lots and lots of controllers from lots of different vendors. They all visually work differently. For example, my controller doesn’t have a light at all. Also, the meanings of the lights on the controller are explained in the manual for the controller. Given that it’s already documented, is it really fair to force the developers to duplicate and keep up to date that information in the binding docs? I personally would rather they spend their time on the code that duplicating documentation you already have and should have already read.

It’s normally battery powered, but connect to USB power currently. I had it disconnected from power for >48h now, but it didn’t lead to anything. Actually it sits there for a week or so now. And the controller is still telling me the device is online and healthy.

I also tried to exclude it several times. But as I said it rather looks like the device thinks it’s excluded. I can include it as a new node. But it doesn’t seem to have any relation anymore to that zombie node 4…

Just found another thread here about ghost nodes. And it seems it’s simply not possible to get rid of them with OH.

Sure! I don’t doubt that either. That’s why I was pointing towards OH 3.0, where, as I understood, the UI is completely overhauled :wink: And from a users perspective it should not only be a lowest common denominator thing. But bindings should be allowed to go beyond that and interact with the user if needed, through API callbacks, custom dialogs or whatever. And ZWave is certainly one of the more prominent of the hundreds of technologies.

Yes, of course. But when you are setting up or modifying your setup, then it’s a common task. After all this is often all a quick start guide of a device contains. Compared to setting devices failed, resetting controllers or such options.

Well, as I said, my problem was not so much the understanding, but that certain information is simply not shown in the UI. So how should I know about it and base decisions on it? How much knowledge should I need to do something as basic as adding/removing a ZWave node?
OH as a framework should allow the bindings to interact with the user and present information in a meaningful way.

Exactly, it’s a representation. And it should tied to the object it represents and not be removable as long as the object it represents is still there. As written above there could be API hooks to interact with the bindings when a thing is added or removed. OH would call a hook in the binding to tell: “I want to remove that Thing you are responsible for!” Then the binding could say: “Wait, you can’t just remove it, the node needs to be excluded from the network first!”. Yes, please! Next it pops up a dialog giving instructions what to do, like: within 30s do what your device manual says. When exclusion is successful, it tells me, and allows OH to remove the Thing representation. If it fails however it also tells, but the Thing will remain. Another binding might do something else, or nothing at all, depending on the technology.

No, I certainly didn’t mean that OH should tell what button to press, LED to watch or whatever for every ZWave device on this planet. General guidances would be enough. A clear way to start the process, instead of a tiny knob hidden somewhere in the advanced settings of the controller, and a “now do what the manual of your device says to confirm exclusion”.