What can I do to find the reason for these crashes?
Mem Available 25708kilo bytes
Last CMH Reboot16:41:02 Fri 21 Mar 2014
Last Vera Restart16:43:44 Fri 21 Mar 2014
Last Luup Restart00:10:06 Thu 20 Mar 2014
I suspect USB Logging is the problem…
You can use a tool like datawatcher and syslog most variables off to a third party.
You can also datamine to log to a CIFS (windows) share.
I experienced this before when running plugins on VERA that have background services that create memory problems or just crash. I just removed all my plugins and started from scratch. Honestly, I was not able to pin-point the issue. But I had installed so many unused plugins that I just wanted to test at one point in time.
I seem to have the same issue but with
local http = require("socket.http")
http.TIMEOUT = 5
local status, result = http.request("http://www.domain.com/index.htm")
How can I get the same result (variable) with this:
os.execute("wget -q -T=5 -t 10 -O /dev/null 'http://www.domain.com/index.htm'")
Is there any downside to use this?
No crashes for days if using os.execute.
How can I get a result back with this commands?
I found the cause for this:
http://forum.micasaverde.com/index.php/topic,17466.msg167716.html#msg167716
[quote=“dawiinci, post:4, topic:180313”]How can I get the same result (variable) with this:
os.execute("wget -q -T=5 -t 10 -O /dev/null 'http://www.domain.com/index.htm'")
[/quote]
You can use [tt]popen[/tt] to get content back from the launched OS command.
Lua 5.1 Reference Manual
I will try this thanks.
So a webpage containing the Text 123 will return this to io.popen or is there more processing needed?
[tt]io.popen[/tt] runs the OS command and gives you the unfiltered results, as a string.
It’ll be good for stuff that only retrieves a small amount of content, and where you don’t need “extra” stuff (like response headers, for example)
Thanks.
However it also crashes with wget…
Micasaverde really shows how buggy software can be. >:(
How often are you doing a wget ?
How long does each wget take ?
I’m not a fan of launching processes on this type of embedded device, especially when you can do it directly in it’s scripting language (for HTTP requests). Vera itself does this in a bunch of places, and it’s not the best model for an embedded device (where you want to keep resource consumption fairly-constant)
If your Vera is ‘close to the limits’ then this type of thing is not recommended, due to the surge in resources it triggers. You haven’t described the symptoms of how it’s crashing, so it’s hard to comment on what’s going on.
According to the support it is a memory leak. I can reproduce it by starting the scene several times. Since this can happen in real life I had to test this.
Vera just restarts luup if this happens. I’ve seen it live.
I am using it with a 30 second timeout. Two calls per scene, every 10 minutes. After a few hours or sometimes earlier luup restarts.
In UI5, TOTAL scene execution time cannot exceed 60 seconds. In UI4, it cannot exceed 30 seconds.
And if you’re anywhere near that time, you’re in dangerous territory. When this limit is reached, Vera assumes there’s a deadlock and restarts the LuaUPnP process altogether.
You need to rethink your execution strategy if you have things that need that long of a timeout (you’ve indicated 2x calls, 30s timeout).
For example, an external/OS-level schell script write the value back into Vera when it’s ready (using variableset).
You can “launch” this shell script in your Vera’s startup Lua using [tt]os.execute()[/tt] with the background “&” option on your command)… but that’ll require that you write a shell script (or similar) to loop over the long running OS commands… you’re 1/2 way there, since you’re already using the OS version of [tt]wget[/tt].
There are a few more details to do this type of thing, like having the script exit if it’s already running, but this is a rough outline if you cannot predictably have the service URL return in a reasonable amount of time (like 5s or less)
I split/merged your forum posts, to keep everything together and not touch the OP’s thread.
Thanks, this is getting a lot clearer.
So in rare cases it had to wait close to 30 seconds for a respond and therefore crashed. With two requests per scene there is not a lot of spare time.
I lowered the timeout to 1 second and the status is not received. The command on the Arduino is already triggered but the response just takes some time. 10 seconds seems to be the absolute minimum in an optimal (network) case. Several of such scenes will possibly be started at the same time.
Any advice?
Any advice?
I suggest that you revisit your Arduino code. I have a Pro Mini linked to Vera by Wifi. I get a response back within 600 ms of sending a command including all the Arduino processing, Wifi/serial conversion, network latency and Vera’s overhead.
In general:
a) If you control the thing you’re calling, and the conduit you’re using to call it, then make it go faster.
b) If you don’t control the thing you’re calling, then rely upon timeouts to guard the caller.
In both cases, always protect the caller with timeouts, the callee should similarly guard itself against the caller.
It’s the same reason that Vera keeps copies of “current state” information for Z-Wave devices. When you write scenes (etc), you’re working against that current-state definition. This avoids having to call-out to the actual Z-Wave device (or other physical entity) in real time, since that adds an unpredictable amount of time to the call and often adds reliability problems.
If you control it, then the Arduino thing can [internally] use the same strategy with wherever it’s getting the data from (async get, local cache, requests for data from it only come from cache).
I like to think of the Timeouts as a car’s rev-limiter. When it goes off, you don’t just increase the limit, you work out why you’re hitting it and fix that problem… unless you don’t like your engine 8)
I think you are right. I just restarted the Yun and now it gives feedback much faster. I didn’t change the code though. Maybe it was due to my excessive calling of code by http?
With a 20 s timeout per scene I should be without issues for now.
For all I know the delay could also come from the Wifi network.