I see. I currently have about 25 z-wave units, where 5 is sensors, so i suppose its not that big (yet)…
I have to admit, since 7.30 my vera edge is more solid than ever before (might also have to do with additions from @rafale77). Only thing nasty is that some device do not return their status back to Vera anymore…
@Sorin
When is this beta going to be a real release ( GA level )?
Yes, I would like to know this as well, since I haven’t updated the firmware on my Vera Plus for over a year and would like to do so. Thanks
Same, I’ve now configured Reactor to bounce my Plus twice a week - the main symptom is devices not receiving commands (doesnt matter if it’s Wifi or Z-wave).
I’m not sure how to check why it’s reloading…
C
For kicks, this is what I run on the current unrotated log to see what is going on, based on my analysis of logs, I am able to practically identify the cause of all of my problems:
cat /tmp/log/cmh/LuaUPnP.log | grep "poll\|CAN\|tardy\|flood\| time\|Exit"
If I can’t figure out what is happening then I actually go and open the log to look for additional keywords.
Long explanation:
This command filters the log and only displays line containing the words poll, CAN, tardy, time, Exit.
“poll” can be the source of vera freeze when too many of them are present. It helps me verify that my polling interval and wakeup interval settings change are working by looking at frequency and timing.
“CAN” is the dreaded “got CAN” event which is very frequent on my network and seems to correspond to transmission from my zooz ZSE040/vision ZP5111 4in1 secure class sensors and can be source of…
tardy call backs indicating that the vera has frozen
“flood” shows me the NONCE_Get Flood events at the source of the timeout below.
“time”, I noticed shows me the timeout which also is often a source of tardiness.
“Exit” gives me the line showing the Exit code of the luup reload.
Note that I am rotating my logs only once a day. I have also modified my rotate logs script to do that so it gives me some time to review them.
6 Likes
are you using vera’s scene controller for anything?
That explains a lot! I see quite a few of these:
ZWaveSerial::Send m_iFrameID 2277 got a CAN -- Dongle is in a bad state. Wait 1 second before continuing to let it try to recover. <0x77112520>
I had a reload last night. Will try this
C
So is it possible that (time variance excluded) is it possible the error is logged after the restart?
I got an (email) notification 2311 last night of a restart.
The only log errors thrown by that set of greps is
Device_Basic::AddPoll 80 poll list full, deleting old one
Which seems pretty consistent with the logs in general but at (log time) 2314 I get a series of got CAN / Dongle is in a bad state
I’ve found what I think is the restart:
|04|01/28/20 23:10:21.720|<Job ID="3772" Name="Wakeup done 63" Device="228" Created="2020-01-28 23:10:21" Started="2020-01-28 23:10:21" Completed="2020-01-28 23:10:21" Duration="0.78446000" Runtime="0.77719000" Status="Successful" LastNote="SUCCESS! Transmit was OK" Node="63" NodeType="ZWaveMultiEmbedded" NodeDescription="Fibaro Smoke CO 1"/>|
|---|---|---|
|03|01/28/20 23:10:25.703|LuaUPNP: starting bLogUPnP 0 <0x77b33320>|
But there’s nothing obvious showing before that…
C
Anyone know what this may be? for about 2 full seconds i have a stream of these messages happening about twice per millisecond. Device 474 is a battery powered motion sensor that seems to have started acting up in the last couple of days.
35 01/29/20 7:21:51.289 Device_Basic::RateWakeups 474 wakeup time 1577386675 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.289 Device_Basic::RateWakeups 474 wakeup time 1577388482 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.290 Device_Basic::RateWakeups 474 wakeup time 1577390292 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.290 Device_Basic::RateWakeups 474 wakeup time 1577392098 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.291 Device_Basic::RateWakeups 474 wakeup time 1577393904 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.292 Device_Basic::RateWakeups 474 wakeup time 1577395711 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.292 Device_Basic::RateWakeups 474 wakeup time 1577397517 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.293 Device_Basic::RateWakeups 474 wakeup time 1577399322 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.293 Device_Basic::RateWakeups 474 wakeup time 1577401127 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.294 Device_Basic::RateWakeups 474 wakeup time 1577402932 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.294 Device_Basic::RateWakeups 474 wakeup time 1577404737 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.295 Device_Basic::RateWakeups 474 wakeup time 1577406542 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.295 Device_Basic::RateWakeups 474 wakeup time 1577408347 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.296 Device_Basic::RateWakeups 474 wakeup time 1577410153 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.296 Device_Basic::RateWakeups 474 wakeup time 1577411959 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.297 Device_Basic::RateWakeups 474 wakeup time 1577413765 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.297 Device_Basic::RateWakeups 474 wakeup time 1577415574 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.298 Device_Basic::RateWakeups 474 wakeup time 1577415574 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.298 Device_Basic::RateWakeups 474 wakeup time 1577417379 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.299 Device_Basic::RateWakeups 474 wakeup time 1577419186 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.299 Device_Basic::RateWakeups 474 wakeup time 1577420994 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.300 Device_Basic::RateWakeups 474 wakeup time 1577422801 is before last time check 1579554778, continuing <0x76a26520>
35 01/29/20 7:21:51.300 Device_Basic::RateWakeups 474 wakeup time 1577424609 is before last time check 1579554778, continuing <0x76a26520>
very stable
I tried updating another vera plus but i got this error msg:
Wrong firmware for current platform: Vera4Lite. Intended for mt7621
Hi @Jumeira,
The Lite models are end of support and will no longer get new firmware sadly.
Cheers Rene
But I am trying to download the vera plus firmware!
…to a Vera plus! (If I’m reading you right)
C
Sounds like you are using the wrong link for a Vera Plus.
No, i used the same link for vera plus… which i used before for upgrading my vera+, the link seems not working now!!
try to use http and not https i think they are still having some issues with the Https link/server
http://dl.mios.com/rl/731/mt7621_Luup_ui7-1.7.4903-en-mios.squashfs for V+
Still having the same error msg.