Exactly that. It may be you’ve run out of space
C
1 Like
I may (a bit strongly) urge you to migrate the following plug-ins:
PLEG ► Reactor
VeraAlerts ► Reactor
HouseModes ► Reactor
Dark Sky Weather ► SiteSensor
Virtual Switches ► Switchboard (built-in import!)
All of @rigpapa’s plug-ins are very resource-friendly and well-maintained!
2 Likes
The big suspect for me here is WWN. I banished that plugin a long time ago. It really wreaked havoc with my system. I wasn’t happy, because I have Nest thermostats exclusively in my house, but having my Vera tanking all the time was worse. That was my experience. For the record, my system got a lot more stable when I stopped using PLEG, and that’s a big part of the reason I wrote DelayLight, and then Reactor.
2 Likes
Agreed - I’ve moved 95% of my pleg stuff in Reactor. I’ll need to learn more about sitesensor for replacing darksky. I use it to determine cloud cover for gloomy conditions (which turns on more lights, and turns off if sun returns, etc.)
Yeah WWN very well could be causing issues - I use ecobee for thermostat, and this is all for the Next Protects… but I like the idea of having them tied into the automation for turning on lights, disabling hvac in event of alarm, etc.
But I’m seeing small things like using Autovera (via tasker) trigger a single virtual switch, which only does 2 things: Disarm the alarm panel and then unlock deadbolt. Even that tiny activity triggered a restart the other day. That was probably the worst “easy” thing that triggered it. The other large scenes (both native scene or using Reactor to carry actions) is almost 100% restart occurrence. But those scenes (morning and goodnight) run many things, harmony, alarm (only goodnight), ecobee, etc.
I think DarkSky is low on my list of suspects. It’s supported and developed by a well-known and very skilled developer here.
2 Likes
Recalling that my own Vera Plus was randomly doing Luup reloads as recently as last month, I can tell you the two (and probably only two) things I did that quited it down:
I (re-)ran the code by @rafale77 which (re-)enabled “Reload on Time Jumps”…
…and I rebooted my Vera using Settings > Network > Reboot. I have a strong suspicion that this second move was the more effective of the two. It had been a mighty long time since doing a restart of that nature.
No random restarts (ok, maybe one) since then! I realize all of this may not help with your particular issue, but it can’t hurt, eh??
Ran that code via test luup code, hopefully that was the right way lol
And then rebooted - fingers crossed. I’ll know within a few hours haha
thanks!
You did good, son. 
1 Like
Ok, here’s my memory/space readout:
No dice on this resolving as the restarts continue during scenes/activities.
I will add that I think it’s tied mostly to a change in house mode, fwiw
1 Like
Space looks OK
What have you got set to change when house mode changes?
C
Not much - a handful of sensors change arm/disarm state, but there are no actions like lights on/off/dim/etc.
I’ve got 206 devices so think it might get hairy doing that through mode changes
We know that Vera generally degrades the larger your Z-Wave network becomes, and ironically, it has been shown that leaving the stacking of (many) multiple jobs in a row will cause her to behave erratically.
May I suggest porting some of those Arm/Disarm toggles over to Reactor (maybe a dozen at a time, until the problem abates), since you can there introduce a [Delay] action between batches.
This advice comes on the heels of a separate discussion in which we all essentially agree that such delays are key to keeping Vera from puking on long chains of actions (i.e. Mode change panel).
If you’ve confirmed it’s house mode changes, try stopping the sensor changes?
Or stop the house mode changes? See if that narrows it down?
C
@LibraSun - yes, and agreed - but my head scratching is that everything was fine a couple weeks ago with the same configs. I had moved a ton of stuff to Reactor months back and it has been noticeably more stable throughout the day. I dare say that I would even go a few days in a row with no restarts. But something must be hosed to create such a dramatic and recent change in stability…
@Catman Yes, that was my next step as well - just delete the house mode change and see if it executes ok.
@rigpapa One of the many things that is so incredible about Reactor is the ability to continue activity executions even factoring in restarts - But I’ve noticed that with this recent issue that even Reactor is not completing some (not all) tasks following a delay and with the restart occurring. Does that shed any light on it?
I’m going to try removing the house mode changes next and report back.
Thanks to all of you guys (and this community in general) for the pro-bono help we all provide each other!
Ryan
1 Like
LOL
treatise
1 Like
Ironically - I just did this as my first troubleshooting step. I had the housemodes plugin, and had ‘clicking the button’ as an action in the scene. I removed that and used Reactor’s built-in “change house mode” as a replacement.
1 Like
I would also study your LuaUPnP.log file carefully. If you find a lot of red and yellow in there, and the infamous “got CAN” messages, that’s an indicator that ZWave commands are being dropped or ignored by the engine. There’s no way for Reactor to know that. It speaks the health of your mesh and devices. Depending on the structure of the mesh, a single device changing neighbors or dropping out can big problems that result in delays and other issues, and very often lead to “got CANs”.
2 Likes
The only ‘red’ lines I’m seeing (and not sure how far back to go, this is all within the last 5 minutes or so)
I don’t know what device 277 is, can’t find it. Device 134 is a motion detector.
LuaInterface::CallFunction_Timer device 277 refreshCache took 10 seconds (multiple instances of this entry)
ZWaveNode::HandlePollUpdate_Alarm node 59 device 134 v1type: 0 v1level: 0 source: 0 status: 255 type: 7 event: 0 parms_len: 0 parms: 0 code: (null)
Update that I just ‘caught’ another restart in the log:
01 04/24/20 16:16:30.306 FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://apps.mios.com/get_plugin_version2.php?plugin=4086&accesspoint=50061111&platform=mt7621_Luup &firmware=*1.7.4970*&oem=1 response: <0x7706c520> 01 04/24/20 16:16:30.307 JobHandler_LuaUPnP::GetPluginVersionOnline iPlugin: 4086 buffer empty <0x7706c520>
This restart was triggered by running a scene which contained only one plugin (which is also in the others that have been triggering it) - Harmony.
Edit 2: I have tried Harmony interaction same activity, manually and it all worked fine. Ugh this is driving me nuts.