Thanks for reporting this! Strange that I did not observe this at all but it could have been because I did this during one of the alpha versions.
Edited the first posts to change the code!
@rafale77 I wondering if you could provide some advice, since implementing most of your recommendations on 7.30, I’m noticing that if I move Z-wave devices around and run a global update neighbors from the z-wave menu I don’t get devices showing updated neighbors that I’d expect to see from a logical POV.
I’m basing my logic on what I know are logical hops from my Plus to devices I know would be on the route to them. eg Plus → Main bedroom Dual nano → garage door controller.
Instead, my Garage door controller is showing no Neighbors at all and I know from past experience it needs a neighbor to connect back to the plus.
If that is the case you can go straight to that particular Garage door controller and get it to update neighbors. The command is in the advanced/device options menu of the device.
I tried that too, still no neighbors listed … it’s very odd. Not sure if it’s a 7.30 issue or something else as it is working normally. The odd thing is I’d expect it to at least say “1” for the controller as some of my other devices do.
Where are you looking for the neighbor’s list?
I was just looking at my setup and found few devices with either an empty neighbor list and even one with no such variable all together. The devices work just fine. I am guessing that for the vera UI to display it, the device needs to be polled. The neighbors list is managed at the zwave chip firmware level and at the devices zwave chip themselves. What the UI does with it is secondary. It is likely that it all works fine and that the UI is just not updating.
So far they do seem ok, although yesterday I had a bunch of devices showing “cant connect” which eventualy came good after toggling them through the UI.
The can’t detect device is triggered automatically when:
for AC powered devices, a poll has failed or timed out or the vera did not receive an ack frame from the device when the vera sent a command to it. Could it be that some scenes tried to actuate these devices when you were moving them?
for battery operated devices, when the vera fails to receive the wakeup frame from the device per the wakeup interval parameter 2x in a row. If you set the device to never wakeup, you will never see that message on battery operated devices.
As described at the top of this post, overwhelming overhead communication will perturb these wakeup and ack or polling commands and is the reason why most people see these.
It was hours later and well after I’d run a NNU which was why I was so puzzled. Today everything seems to be working very well again. The 2 devices that had the issue hadnt even been moved but where in the vicinity of a couple that had been.
Thanks for this tread, its great. I want some opinions on what I’m seeing since disabling polling for powered devices… I use all GE/Jasco Zwave switches (no instant status) and Ive noticed since disabling polling, that my device status is wrong about as often as it is right. Would you expect to see that behavior from devices without instant status? I was under the impression that if the switch was physically turned off or on, it would report that status change to vera (even without instant status) but that doesnt seem to be the case. As much as I dont want polling back on, Im thinking I dont have much of a choice if I want accurate status’ in Vera. Am I missing something?
It really all depends on your device… There was a diversity of solution to work around the instant status patent that it is difficult for me to have a complete answer. There are several generations of the GE/Jasco firmwares. I got rid of all of mine and replaced them with Levitons and Coopers.
If the device indeed has no instant status then no, it will not ever report its status to the vera and the vera would rely on polling to get it’s status which means that the delay before you get the status accurate would vary greatly. Most of the patent workaround relies on some variant of polling and disabling polling would prevent status updates and you might be right that you may need to enable polling for these specific devices. As I said, I still poll some devices. Just not all across the network like what the vera defaults to.
Thanks the answer I didnt want to hear but expected. I’ve got a mix of all the Ge/Jasco generations of devices, So i would guess Ill just need to turn polling back on.I 'm up to about 20 switches that would need replacement, so Im pretty sure the wife would kill me if i replaced them all with Levitons or Coopers.
A couple of thoughts. As the “enable polling” check box in the zwave menu remains a mystery to me maybe try to enable that first if it is not already on. If it is then you will have to change the “PollSettings” variable on the specific devices to something like 600 (seconds).
So I am testing that now… enabling the zwave poll from the zwave menu. I will report back what I find. This has caused a luup reload for my vera which had not had one for 10 days.
Edit: So “poll nodes” in the zwave option menu enables the AC powered device polling variable “PollSettings”. If that checkbox is not enabled, the AC powered devices and FLiRs will just not be polled even if the PollSettings is not zero. It however has 0 effect on the battery operated devices which get polled every time they wakeup regardless of this attribute. Turns out that I have had this disabled since 2016. So if you do need polling on these specific devices, this option needs to be ticked.
Thanks! I actually still had that on, and had just used your code to set everything to not poll. I have since reused your code to set polling to 600 sec. In zwave options i expanded out the times so it waits 20 sec to poll, only if the network has been idle for 60 seconds, poll each node at most every 600 seconds and poll a node every 100 seconds. I’m hoping this will give me the status updates i need after family using physical switches, without actually killing my zwave network. I dont need instant, but I dont want to see my kids light showing as on when i know hes been passed out for the last hour either.
i have 2 vera plus one vera edge one vera lire. Have a number of zigbee stuff not implemented with vera, i used to work for a security comp that mainly uses zigbee ha but they are closing their doors as of February 5th. at home i have 45 devices mostly z-wave a few zwave plus some i use for testing.
Just a huge thank you for laying this out in such clear terms and keeping it updated with the latest info. I have just implemented the suggested changes and look forward to tracking the difference (especially reducing the drain on rechargeable batteries!!)
It has been night and day for my setup. I am continuing to spend time scrubbing my logs to look for problems and opportunities for improvement.
At the moment my focus is on the got CAN/tardy callbacks which appear to be from a very old bug in the vera’s customized zwave handling causing some problems mostly with secure class devices…
As for the concerns about the Xmas light mode, I hope they get addressed soon. I don’t suffer from it because I run my production vera “unplugged”. Having replaced all the mios server services with local or more reliable equivalents.
Thanks for explanation, what is strange is that my network perfectly works with 25 battery powered devices and wakeup interval still set to 1800s. I dont have any error messages “Cant detect device” or something else.
Should I also in my case set wakeup interval of all my batrery powered devices to 43200s? Thanks!
This is strange as you said. Not having can’t detect devices is a matter of luck and I did not have much of these to be honest. What was more obvious was the lag for my scenes and commands and the battery consumption which I thought to be normal and now that I have something to compare to, realize that it was insane. Then there are the luup reloads which, if you don’t do much with your automation probably will go unnoticed but since I have announcements and scenes associated to every sensors, to me it is obvious when something is bad. I closely monitored my luup uptime and get it to send me a phone notification at every reload so I am pretty sensitive… Not sure how your setup is.
In any case you will benefit from these changes. The default vera settings are absurd and insufficiently tested. (meaning not tested in a real life setup at the specifications of the units: 150+ zwave nodes worst case with FLiRs and battery operated devices with scenes running etc…)