I have a new Vera Plus that Customer Care updated to the latest firmware about a week and a half ago. It has been running fine.
For no apparent reason this morning I received a cannot write user data - system error. The only thing I had done prior to the error (but not immediately proximate to the error) this morning was run a simple PLEG trigger in which turning on one light switch triggered another light. I’ve run this trigger a lot with no issues.
I run System Monitor and when I’ve checked Available Memory in the past I’m always between 190 MB and 195 MB. CPU load ranges between .09 and .28. I’m only running one PLEG, several virtual switches, Day and Night, and a Countdown Timer app.
I restarted Vera from Reboot in the menus. Should I write this off as a fluke or is this definitely a sign of bad memory chips? This is the first time I’ve received the error.
Check history data for free memory instead of available memory. If the problem is growing cache, then it is not reflected in available memory variable.
Details are in your thread with question about scheduled reboots.
I am experimenting with a PLEG Action to clear the cache from time to time to see if reduces my LUUP restarts. It may help you figure out if cache was the issue.
Thanks kwieto and Don. I went back to the thread on auto reboots and created a PLEG that is supposed to clear the cache when free memory drops below 50MB. Fingers crossed.
Sorry this is a bit off topic. Don - I noticed that you’re using the VeraMate app to push iOS alerts if the clear cache action is run. How do you like the VerMate app vs the Vera app? Do you use it for geofencing as well?
Love the VeraMate app. The author seems to have dropped off but it has been workingfor me.
I do not use the Vera app much at all. VeraMate allows me to create a page to display exactly what I want. Here is an example. I have a few Virtual Switches to tell me when an iPhone is home, or both are away, or when the cameras are armed, etc.
I have been using iPhone Locator for years. I could not get geofencing to work reliably.
From my experience, cache has nothing to do with luup reloads.
About month ago I’ve had serious issue with luup reloads (like: 100 in 24h) but memory readings were fine during that time. See screenthot: I’ve had c.a. 300 luup reloads between 21st and 25th Jan (black line); during that time free memory (purple line) was between 120 and 160Mb (bigger jumps are related to vera reboots which I performed hoping that it will solve the problem); cached memory (red line) between 28 and 58Mb.
From the other hand, when I’ve had issues with cached memory, there were only 4 luup reloads at time when memory was steadily drained (see second screenshot)
But amount of free memory has much to do with “can’t write user data” error and the risk of your controller being bricked.
If memory gets overloaded (cache is probably not the only potential reason, I’ve seen also memory Buffers unreasonably growing, but it seems to be most common one), then it can’t save data (this is why you’re getting “can’t write user data” error). More important, it also get unresponsive and the only way to get it back is to perform reboot (by unpluging it from the power or pressing reset button, as you can’t access it via interface). And I’ve found this procedure as risky: my Edge survived such procedure twice, third time went into rebooting loop and even Customer Care couldn’t get it back to work (had to issue RMA).
What I have done is to use the memory free as a trigger to a scene. If it drops below a critical value do a luup.reload(). This way you avoid a hard reset.
The thing is that luup reload seems to not solve the issue.
As you see on second screenshot above, luup reloaded couple of times when amount of cached memory was increasing and it didn’t stop the process.
As I reported the problem to Cutsomer Care after the problem repeated next day, I’ve got from them a code which should clear the cache:
os.execute("echo 3 > /proc/sys/vm/drop_caches")
But I didn’t have opportunity to really test the code, as for now everything is back to normal and since 7th Feb I have no issues with memory.
[quote=“kwieto, post:10, topic:198594”]The thing is that luup reload seems to not solve the issue.
As you see on second screenshot above, luup reloaded couple of times when amount of cached memory was increasing and it didn’t stop the process.
As I reported the problem to Cutsomer Care after the problem repeated next day, I’ve got from them a code which should clear the cache:
os.execute("echo 3 > /proc/sys/vm/drop_caches")
But I didn’t have opportunity to really test the code, as for now everything is back to normal and since 7th Feb I have no issues with memory.[/quote]
Ha! Now I’m in the same position of having added the code, but not being able to test it. Nonetheless, given the potential for bricking if the cache does get out of control, it seems like it is a valuable part of a preventive toolkit.
From my experience, cache has nothing to do with luup reloads.
About month ago I’ve had serious issue with luup reloads (like: 100 in 24h) but memory readings were fine during that time. See screenthot: I’ve had c.a. 300 luup reloads between 21st and 25th Jan (black line); during that time free memory (purple line) was between 120 and 160Mb (bigger jumps are related to vera reboots which I performed hoping that it will solve the problem); cached memory (red line) between 28 and 58Mb.[/quote]
That may be true for your particular setup. I noticed in the last 24 hours, about 3 cache clears but no LUUP restart. So I added a Cache counter to my test PLEG. Saturday, I will reset my LUUP restart and Cache counters and let it run for a week to see if my system has a correlation between clearing the cache and reduced LUUP starts. Mine has been average a couple of LUUP restarts a day before adding the cache clearing.
This is why I wrote about “my experience”.
Anyway, the real problem is somewhere else, growing cache and/or luup reloads are only the symptoms.
In my case support pointed to plugins as most probable cause.
You mean, triggered by the logic “if free memory is less than…”?
Then I would contact Customer Care as something is definitely not right.
The only case when memory was drained that regularly in my case was when I had mistakenly enabled saving Vera logs to USB at the same time as datamine plugin saving data on the same USB (it is not recommended by manual).
Update on my experiment with clearing the cache. The number of LUUP restarts went down from about 2 per day to 1 per day, and I cleared the cache about twice a day. I was not having any specific issues - just checking it out.
So I created a manual scene to run it - if I ever need it. With a Vera 3, it may be handy when updating the firmware.
Best Home Automation shopping experience. Shop at Ezlo!
