Recently I had occasion to exclude a device. I went to the device control panel, hit the trash can icon, and chose unpair. Vera dutifully put itself into exclusion mode, and the next thing I know, it reports that it’s excluding a node, before I even touched the switch I intended to exclude. On my server I’ve got a daily report generated of installed devices and health, so it was quick work to figure out what got dropped–the motion sensor in my son’s bedroom. I guess he moved right about the same time.
Given that I started the process by intending to remove a specific device, and launched the process from that device, I’m wondering why/how another device ended up being the victim.
Is this a Vera defect in that it accepts an exclusion from a device other than the one from which one starts the exclusion process? That is, does the Z-Wave chip tell Vera that a particular device signaled while in exclusion mode, but Vera doesn’t compare the node number of the reported device to that of the intended device and tells the chip to go ahead and exclude the reported device anyway?
Is this a Z-Wave defect/limitation in which exclusion is an autonomous mode of the chip and there’s no opportunity for Vera to filter out unintended devices that may become active at the wrong moment? That is, in exclusion mode the chip simply excludes the first (or every) device to talk to it and tells Vera what it did after the fact? I know exclusion mode works on any device, even devices that aren’t registered in the network, but is there a handshake that could be used to restrict which node gets excluded?
Is there a “best practice” (other than extreme caution–nobody move!) to focusing exclusion on a single device and ensuring nothing else is unintentionally caught in the net?
Excellent questions! I suspect that your item 2 is the answer, based on my own experience. I would appreciate a definitive statement on this from the Vera team, including your item 3.
That’s becoming my default method, too. The problem is that some devices don’t seem to have a factory reset option. I’ve also found that the soft delete doesn’t always work and may require several attempts.
That has been my usual habit as well, but much of the time when I soft delete, the device still does not go away, but I’ve found that quite reliably, if I just leave it, it disappears overnight (hmmm… related to the much-hated nightly heal?).
When the controller is in exclude mode, it will exclude the first device (or all device while it is in that mode) which wakes up. It should not exclude a sensor because it tripped. Well at least I don’t know of any but you may have a screwy device which may wakeup when tripped. It may however exclude a sensor if that one sensor happens to wakeup before you got to wakeup the device you actually wanted to exclude. Manually operated devices are always on and do not do this wakeup thing. Only battery operated and non FLiRS devices do. Nothing the vera can do about this…
Yes you are correct in the fact that if you factory reset a device, it will lose its homeID and therefore may get tagged as failed during the nightly heal. You would still have to run a “delete failed device” command to the zwave dongle to delete it but I don’t know that this is automatically done during the heal. You need to trigger it by deleting the device from your user_data.json list and do a luup reload. During the reload the vera checks its user_data.json device list against the list it obtains through the zwaveserial API interface and automatically deletes the devices with missing node ids or adds devices it founds on the dongle to the user list.
He’s not lying. HS has an inclusion/exclusion process that is far faster, more reliable, works at more range…its so nice. It even tells you what is happening as it happens. Useful for battery powered devices that go to sleep halfway through pairing. The second time around you know to activate it part way through pairing.
Yeah, the vera convolutes the device exclusion with the nasty luup reload which takes quite some time because of all the nonsensical bloatware functions it runs. It reloads at every device excluded…
The zwave exclusion proper is actually the same and is run by the zwave dongle firmware. The range is an antenna problem…
This doesn’t have much to do with @rigpapa’s question though. Which is no, you cannot target a specific device for exclusion. It is part of the zwave sdk. Exclusion is a mode for the controller which excludes every device which wakes up while in that mode. You can specifically delete a device which needs to first be tagged as failed but if the nose itself did not reset its homeid, it will come back on the network the next time it transmits.
The exclusion will set the controller into exclusion mode and the first NIF frame received from a node in the network in that time will count as a device to be excluded.
Typically devices do not send this frame unless you toggle the inclusion/exclusion procedure.
