I am encountering Luup re-loads every 2-3 days. I think it could be a memory issue. Vera support have done bits and bobs a number of times which has stretched out the time between re-loads (from 2 to 3 days at best). What is reasonable and is it preventable? I don’t think I have a lot of apps installed, but I notice in the Luup files there appear to be a lot of files which from their file names are associated with apps I removed a long time ago. Can anyone suggest some solutions, either to free up memory, or where to look to find what is causing the memory leakage. You can see from the attached graph (if it uploads) where the re-loads are occurring (small jump in free memory).
Thanks.
From these graphs it doesn’t look to me like memory is ever dropping low enough to be an issue. The difference between before reload and after seems to be about 10-15K, which isn’t much at all, and the minimum free isn’t even close to dropping below 100KB. I don’t think a memory leak is the cause of your reloads.
Well, that means I am wasting my time (and that of vera support) looking to free up more space.
The re-loads do not seem to follow any obvious pattern / time of day. Is searching for the reason a black art or something a simple soul like me can work out?
What free memory do other folks on this forum have (just out of interest)?
About par for the course, I’d say.
Here’s memory and CPU statistics for two of my Veras for the last month…
I don’t have super-sexy graphs like @akbooer, but…
- My “production” Vera Plus runs around 98M free memory (of 256MB total) on average; uses Reactor, DelayLight, Rachio, SiteSensor, DeusExMachinaII, Sonos, HTD Lync (my own version), LuaView, Emby, Switchboard, and Virtual Sensor. As of 7.0.29, it’s not unusual for it to go 3-4 days without reloading.
- My development Vera Plus runs around 120M free memory on average currently with only Reactor, Switchboard, DelayLight, and the Onkyo Receiver plugins running. It has no Z-Wave devices at all. I think the longest unbroken run I’ve seen is just over 5 days, on 7.0.29, but I’m so busy on it that I rarely don’t force a reload several times a day…
- My development Vera 3 runs around 42M free memory (of 128MB) with Reactor, DelayLight, Switchboard, SiteSensor, LuaView, Yeelight, and Emby plugins; firmware 7.0.27. This machine, too, will run for days without a reload if I’m not doing anything with it.
Thanks for your responses Gents.
I run the following:
Virtual ON/OFF Switch
Day or Night
Ping Sensor
HouseModes Plugin
System Monitor
Onkyo Reciever (AVR)
Multistring
SiteSensor
HomeWave Push Notifications
Reactor
So it seems that I am not short of memory compared with you guys and my CPU load is much less than akbooer.
I do run some lup code in Reactor to do some calculations and move data around in multistrings.
So can I just ask if in your opinion a reboot every 2 to 3 days is acceptable or for want of a better term ‘about as good as it gets’?
I think it’s acceptable for now. It’s a big step forward from 7.0.27, where I would get several per day on my spouse-facing system. I hope they’ll continue the trend in that direction with future releases.
Having gone through the same goose chase with the vera, I am now managing mine to have a luup reload every 10-15 days in average unless I am adding or reconfiguring a device. I concur that free memory does not appear to be the problem. Note that you should see a sudden increase of free memory also every time your logs rotate. I use a notification sent from my startup lua to record when I get a luup reload.
There is a luup reload on the 1st of each month at midnight.
From the launch script of the luup engine, I can also see that a luup reload can be also a luup crash.
It can be caused by the network monitor program which will trigger whenever you have certain network changes. I have disabled this on my unit, since it is properly useless… the network changes don’t affect the vera and the luup reload it triggers doesn’t fix anything. I already sent a note to the dev to eliminate this mechanism.
The mios servers are also capable of reloading the luup engine which is also what drove me to isolate my vera from the mios servers. (See my my take it off the grid thread)
Plugin autoupdate can also trigger unwanted luup reloads. I disabled auto update on all my plugins.
I am still trying to chase every last bit of luup reloads… looking at logs and I am currently looking for what causes error245…
I have a Vera 3 since 2013 running well, with, perhaps, 1 or 2 restarts per day. With PLEG, I have not had issues so I have not done much goose chasing.
About once a week, my Exterior Lights On/Off schedule in PLEG will not fire. A manual on/off corrects it and the next schedule executes just fine without further intervention.
About once every 2 or 3 weeks, I lose connectivity to the Hue Hub so I have to re-link it, and then it works fine.
Overall, minor annoyances.
I was thinking about a script disabling them and then to be run every 1st of month (since the luup engine is restarting anyway).
Have you managed to find something similar?
I partially remove a couple of services and usually my luup engine is stable (I can get from 5 to 15 days of uptime), and reload are mainly related to plug-ins updates. But I have just of couple of them and offloaded a lot of things to a linux box.
If that attribute was accessible from lua code, it would be easy. I think it likely is accessible through the luup api and it is what ALTUI calls. I could look into it.
The auto update flag is held in the InstalledPlugins2 table in user_data. It is not, AFAIK, accessible from within Luup, but populated by information set by the plugin developer in the MiOS repository.
I’ve always distrusted auto update, and never set any of my own plugins to do that. You can, of course, manually request a plugin update at any time through either the UI or by an action initiated by HTTP request or luup.call_action().
Thanks AK. May save me some time. I knew I saw this flag in the user-data.json. I was just wondering how ALTUI accesses it on a vera. It may actually edit it directly without going through a function of the luup engine…
It uses the ModifyUserData action, which you could do yourself, but it means retrieving the whole user_data, pulling out the relevant plugin information, carefully modifying it and using it in the request.
So, plan is to disable all plug-in updates manually.
Then write a script requesting updates to be run on 1st day of month. Since I can’t find a single command, we have to get the plug-ins, but the code to force update seems trivial.
Not sure what you mean here? You were looking for an “Update All” command? Or is your problem finding out which plugins to update?
The first one. I want to disable auto update and run un update for all the plug-ins on the 1st day of every month (or totally disable it and run manually from time to time). I guess it doesn’t matter if there’s an update or not.
Bear in mind that each update will cause a reload…
That’s fine. I want to consolidate them and avoid a reload when I know my Vera has something to do. At 4 am, for example, the system is pretty light on load.
Since I moved to less and less plug-ins, I will start with just disabling auto update and monitor them. Maybe I will write an alert or similar and then update them by hand.
These graphs are amazing! How did you get them?
I have sporadic “offline” or restarts just about every day.
I’ve set up an inexpensive electronic timer, which restarts my Vera in the middle of the night to “clean it up” It has helped but not eliminated reboots (I also do this for my modem and routers and that has improved stability as well)
Would love to know how to get your graphs. Thanks!
