So I think there are many of us that have had stability issues on UI7 for quite a while, and VeraPlus has in my case made things much worse. On top of that, support isn’t help and quite honestly, is probably not equipped to solve the overall problem thru a sequence of individual fixes.
I wanted to start a thread so we can share experiences as people try to work thru their issues themselves. Looking thru the luaUPnP.log is a bit of a interesting experience, and there are a lot of things in there which seem to scream ‘This is a problem, fix me!’. While these may be problems, most of these don’t seem to ‘the’ problem for many of us.
Thus the ‘is this normal’ thread. I’d like to avoid this becoming debugging for a specific device or plugin, but general issues which may affect reliability, health or stability of the Vera system or zwave network.
For reference, the easiest ways to view your log is with AltUI using the OS command capability and to tail the luaUPnP.log, or go to http://your_ip/cgi-bin/cmh/log.sh?Device=LuaUPnP.
[quote=“xeinth”]Kicking this off, is this normal? For every poll, I see the following note in the log, in yellow. It seems to imply some sort of overflow.
Device_Basic::AddPoll 144 poll list full, deleting old one <0x76cb4520>
X[/quote]
As you may know I’ve also been trying to determine the best polling scenario. Mostly under the assumption this message in the log is not normal.
Regardless of any settings I’ve tried I still get this message eventually. I’ve read many threads on polling and cannot determine how to resolve it or even if it needs to be.
At this point I reset all my polling settings to the defaults and decided this message is “normalish”. Maybe @Z-waver can chime in. I saw several really good posts by that user in researching, but can’t seem to find it now.
Sorry to disappoint you, but I can’t say for sure if this message is a problem or not. That’s a question you’ll have to ask Vera support. I haven’t seen it, but you may have a lot of devices.
Yellow log entries, more specifically log level 02 entries, are informational and warning messages. They may suggest a problem but frequently they are just informational. You can see the various log levels and their meanings on the LUUP Debugging wiki page.
By my reading, I feel that this particular message is more informational than a real problem. As I read it, the polling queue has a finite size - I have no idea what that size is - and older jobs must be removed before new ones can be added. It seems normal to me, but…
@MLeBaugh - I’m a strong proponent of leaving the polling settings at default, except for rare instances with specific devices. For instance there are times that completely disabling polling may be advisable, like a handheld remote, but the need to alter polling is rare.
The important thing to realize - and that most people miss - is that the polling settings on devices are a maximum limit and not an actual frequency. It says ‘poll no more frequently than 60 seconds’. But based on Vera’s global polling configuration and the number of devices being polled and the busyness of the network a device might go 5 minutes before it gets polled. This is an extreme example with 60-90 seconds being far more normal.
You can’t reliably increase the frequency of polling. Even if you increase the frequency at a global level, it can/is still slowed by other factors like device count and busyness.
[quote=“Z-Waver, post:4, topic:191462”]… @MLeBaugh - I’m a strong proponent of leaving the polling settings at default, except for rare instances with specific devices. For instance there are times that completely disabling polling may be advisable, like a handheld remote, but the need to alter polling is rare.
…[/quote]
I agree. I have only messed up my system by shortening polling frequency.
01 03/11/16 12:53:08.261 AlarmManager::Run callback for alarm 0xcfa2a0 entry 0x1d391d8 type 308 id 4162 param=(nil) entry->when: 1457722199 time: 1457722388 tnum: 1 slow 0 tardy 189 <0x76c08520>
01 03/11/16 12:53:08.262 AlarmManager::Run callback for alarm 0xcfa2a0 entry 0x1faf930 type 402 id 4163 param=(nil) entry->when: 1457722199 time: 1457722388 tnum: 1 slow 0 tardy 189 <0x76c08520>
01 03/11/16 12:53:08.262 AlarmManager::Run callback for alarm 0xcfa2a0 entry 0x1f94ca8 type 12 id 4535 param=(nil) entry->when: 1457722199 time: 1457722388 tnum: 1 slow 0 tardy 189 <0x76c08520>
01 03/11/16 12:53:08.263 AlarmManager::Run callback for alarm 0xcfa2a0 entry 0x254a3f8 type 309 id 4637 param=(nil) entry->when: 1457722199 time: 1457722388 tnum: 1 slow 0 tardy 189 <0x76c08520>
01 03/11/16 12:53:08.264 AlarmManager::Run callback for alarm 0xcfa2a0 entry 0x1c9c300 type 404 id 4638 param=(nil) entry->when: 1457722199 time: 1457722388 tnum: 1 slow 0 tardy 189 <0x76c08520>
01 03/11/16 12:53:08.264 AlarmManager::Run callback for alarm 0xcfa2a0 entry 0x1b241f8 type 73 id 4665 param=(nil) entry->when: 1457722199 time: 1457722388 tnum: 1 slow 0 tardy 189 <0x76c08520>
01 03/11/16 12:53:08.265 AlarmManager::Run callback for alarm 0xcfa2a0 entry 0x1f254e0 type 301 id 4666 param=(nil) entry->when: 1457722199 time: 1457722388 tnum: 1 slow 0 tardy 189 <0x76c08520>
01 03/11/16 12:53:08.265 AlarmManager::Run callback for alarm 0xcfa2a0 entry 0x24ed8f8 type 400 id 4667 param=(nil) entry->when: 1457722199 time: 1457722388 tnum: 1 slow 0 tardy 189 <0x76c08520>
01 03/11/16 12:53:08.266 AlarmManager::Run callback for alarm 0xcfa2a0 entry 0x1c15950 type 15 id 4676 param=(nil) entry->when: 1457722199 time: 1457722388 tnum: 1 slow 0 tardy 189 <0x76c08520>
01 03/11/16 12:53:08.266 AlarmManager::Run callback for alarm 0xcfa2a0 entry 0x1d9d6c0 type 52 id 4687 param=(nil) entry->when: 1457722199 time: 1457722388 tnum: 1 slow 0 tardy 189 <0x76c08520>
01 03/11/16 12:53:08.270 AlarmManager::Run callback for alarm 0xcfa2a0 entry 0x1f3a8a0 type 51 id 4683 param=(nil) entry->when: 1457722214 time: 1457722388 tnum: 1 slow 0 tardy 174 <0x76c08520>
This seems to happen once every hour or so, and immediately preceding this time the Zwave network seems to go quiet, i.e. nothing is getting polled for the time ‘tardy’. In this case around 174 to 189 seconds.
It seems that all my restarts occur when the delay is more than 300 seconds or so. The problem is nothing above this (specifically around 174 seconds earlier in this case) seems to be indicating a problem.