Background: I have some code that runs ok when testing it in the Vera context, however when I schedule the code there seems to be an issue whereby LUUP crashes and restarts. The code was scheduled every 5 minutes. The issue is Vera LUUP keeps crashing and resetting but I don’t get to see any LUA stack trace for the error (assuming this is what it was).
Question: Is there a way to “trap” an error so it won’t trigger a LUA restart? And then log/email the error say? So something the equivalent of:
try {
Lua code to run
catch e
print/email the exception e
end
If not any other ideas to work out what is going wrong? Just put lots of print/log statements through the code to see where it got to before the issues that trigger a LUUP restart?
You could try using Lua’s pcall(…) function. Quote from the Lua manual:
pcall (f, arg1, ???)
Calls function f with the given arguments in protected mode. This means that any error inside f is not propagated; instead, pcall catches the error and returns a status code. Its first result is the status code (a boolean), which is true if the call succeeds without errors. In such case, pcall also returns all results from the call, after this first result. In case of any error, pcall returns false plus the error message.
This would catch a runtime error in your code but that may not be what is causing your crash.
Are you running UI7? It has been reported that using short interval schedules causes UI7 to crash due to memory leaks.
If your code can run for more than 30 seconds it could trigger Vera’s watchdog and cause a restart. Using sleep(…) commands of more than a few seconds can be fatal…
If your code is making http calls, make sure you set a sensible timeout so that the code will not freeze if the called node does not respond.
Ensure that your code can deal properly with any error or nil values returned from function calls. Most Lua functions can handle being called with nil arguments but some can do strange things. Check that there is no possibility of calling Vera’s luup functions with bad arguments!
It is possible to trigger a restart by calling several actions in a short period if those actions are implemented in a plugin as run rather than job. Vera has only a small queue for run actions.
re UI7 - I’m running UI 6 I believe - I see “You are running the latest version: 1.6.641” so I assume this is UI6 then?
re “It is possible to trigger a restart by calling several actions in a short period if those actions are implemented in a plugin as run rather than job. Vera has only a small queue for run actions.” => I’ve basically got a short amount of code that does a “require” to my main code below and runs it from here. So the code is effectively one piece in a Scene in the LUA area, and the 2nd is just an uploaded LUA file. So this shouldn’t apply to me in this case then?
actually Rex I just made a minor change to the logging file and uploaded, and I see something in a separate test LUA file/scene/schedule I had running seems to have triggering the cyclic LUUP restart which I’ve got no way of stopping (that I know of) without a factory reset. A key section of the logging (whilst I’m still logged on via ssh) that repeats is below.
PS. In the log files it seems LUUP is running the scheduled code (which was every 10 minutes) every 3 seconds in fact…that would be a Vera issue no? Even if there was an issue in your scene code and it has an error, it shouldn’t immediate re-run it should it?
re "It is possible to trigger a restart by calling several actions in a short period if those actions are implemented in a plugin as run rather than job. Vera has only a small queue for run actions." => I've basically got a short amount of code that does a "require" to my main code below and runs it from here. So the code is effectively one piece in a Scene in the LUA area, and the 2nd is just an uploaded LUA file. So this shouldn't apply to me in this case then?
It will apply regardless of how the actions are called. The problem normally only happens when calling actions for a plugin device rather than an actual Z-Wave one. Some plugins use run processing for actions. This is usually OK if the action is very quick - like changing a few variables. It can cause problems if the action results in hardware interaction or anything else that takes more than a few milliseconds. You can see the difference in the log messages for the actions.
PS. In the log files it seems LUUP is running the scheduled code (which was every 10 minutes) every 3 seconds in fact...that would be a Vera issue no? Even if there was an issue in your scene code and it has an error, it shouldn't immediate re-run it should it?
I haven’t heard of that problem with UI6 but it is possible. Are you sure your code is not calling itself? Are there any other triggers for that scene?
Anything come to mind here?
Strange entries but restarts are often caused by stuff that happens up to two minutes before the crash.
[quote=“RexBeckett, post:6, topic:184348”]It will apply regardless of how the actions are called. The problem normally only happens when calling actions for a plugin device rather than an actual Z-Wave one. Some plugins use run processing for actions. This is usually OK if the action is very quick - like changing a few variables. It can cause problems if the action results in hardware interaction or anything else that takes more than a few milliseconds.[/quote]So perhaps just copy/pasting all my code into the scene LUA area of the UI might be better than referencing the bulk of it via a “requires” do you think?
[quote=“RexBeckett, post:6, topic:184348”]I haven’t heard of that problem with UI6 but it is possible. Are you sure your code is not calling itself? Are there any other triggers for that scene?[/quote]not calling the code itself & don’t have any other triggers as such
[quote=“RexBeckett, post:6, topic:184348”]Strange entries but restarts are often caused by stuff that happens up to two minutes before the crash.[/quote]but would it be true to say however that it should only trigger one crash, not repeating crashes? (i.e. crashing occurring every few seconds)
So perhaps just copy/pasting all my code into the scene LUA area of the UI might be better than referencing the bulk of it via a "requires" do you think?
I don’t know if that would make any difference. It may be easier to debug if its all in one place. If you are attempting tricky stuff in your code, you may want to consider getting a licence for ZeroBrane Studio for Vera. This would allow you to run your scene code in debug mode and see what is happening step by step. ZBSV also allows you to have your scene code call the debugger at run time which might help track down the repeated running.
but would it be true to say however that it should only trigger one crash, not repeating crashes? (i.e. crashing occurring every few seconds)
If the same set of circumstances keep occurring, you may well get the same result.
I’ve actually already got this Rex and it has been useful. The code works fine here. Also works in the scene too, but at some point (not sure what starts it) I get the repeating crash thing starting…
I’ll attach the code I’ve got currently if you’re interested…the idea is that I:
*.main code: upload this to VeraLite
*.client code: I copy paste this into the Scene & then put a 5 or 10 minute schedule against it
Update: I’m wondering if it’s the way I “require” the *.main file and use it? I’m assuming each schedule run the instances should be completely separate the way I wrote it…
Update2: Meanwhile my veralite LUUP engine keeps on crashing restarting I’ll have to do the “factory reset” process again…
It might be worth putting your main Lua functions in Startup Lua to see if that makes any difference. That way you can be sure that there is only one copy active…
If UI6 scene scheduling is causing your issue, you could also set up a luup.call_timer(…) in Startup Lua and place your client code in the callback function. It would be sensible to include a test for a virtual switch in the callback function so you can enable or disable it to help with debugging.
Are you running UI7? It has been reported that using short interval schedules causes UI7 to crash due to memory leaks.
Actually, I believe this is a UI6 problem that has not yet been fixed in UI7. However, it should run for awhile before the loss of memory causes an issue.
[quote=“RexBeckett, post:11, topic:184348”]If UI6 scene scheduling is causing your issue, you could also set up a luup.call_timer(…) in Startup Lua and place your client code in the callback function. It would be sensible to include a test for a virtual switch in the callback function so you can enable or disable it to help with debugging.[/quote]thanks Rex - this method sounds good
[quote=“aa6vh, post:12, topic:184348”]Actually, I believe this is a UI6 problem that has not yet been fixed in UI7. However, it should run for awhile before the loss of memory causes an issue.[/quote]That’s exactly what I’m seeing, in terms of the schedule works for some period of time and then things run off the tracks. Can I ask, to try to better understand, re “this is a UI6 problem that has not yet been fixed in UI7” - this kind of reads like micasaverde aren’t going to try to fix it in UI6, but rather just try to get it sorted in UI7? Does this mean they’ve pretty much finished proactive fixes in UI6 now, so really I should be looking at moving to UI7 as soon as the plugins I use work ok in UI7?
Is there a way to print/log the memory usage of LUUP to help identify is this is the issue one is seeing?
Update - Everything seems to be working like a charm after I have stopped using the VeraLite scheduler. Using the luup.call_timer in startup script suggestion from Rex - thanks Rex
Seems like the UI6 interface should not offer the scheduling option itself then if it is faulty no? Or at least have an obvious indication to a user there are issues with it…
Best Home Automation shopping experience. Shop at Ezlo!
I’ll have to do the “factory reset” process again…