Hi,
i have upgraded recently to
built=Fri Jun 20 07:32:45 CEST 2014
but i have very big issues with the bridge library.
Does anyone have the April build ? (the first release of openwrt yun)
I have deleted the file but the new version is too unstable.....
Thanks
Ettore
I use the PHP client for the bridge and i receive for >60% of times "connection refused".
Meanwhile, my sketch get resetted by the watchdog...
I think the problem is the bridge.py because my sketch was not changed (also the IDE version is the same) but i changed openwrt release.....
http://downloads.arduino.cc/openwrtyun/1/YunSysupgradeImage_v1.zip
I'm very interested in what you have discovered. Please keep us posted
Came by to say that, indeed, I'm seeing the exact same behavior in plotly's log on my Yun with the newest image. It gets a few datapoints through to Plotly's server, then I see string of "Connection Refused" errors and nothing gets sent.
Again, if you can downgrade and confirm that 1.0 is working better, please report back. Unfortunately, just saying that "it was working better" doesn't help spotting the bug
Sorry for the delay in my answer, i can now explain exactly what happened.
I have a sketch that upon reception of a certain message over a software serial (connected to a PIC microcontroller) triggers a php script via Process.Run() (is a "php-cli myscript.php " command).
That php script can take long to execute (it waits for a certain action executed by the PIC), and it was an higher time than the watchdog set on the 32u4 (8 seconds).
Reading the forum i discovered that Process.Run waits for the output of the command (while Runasincronously does not) but what is very important is that if the Process object is destroyed, also the started process is destroyed too.
So at first i tried with run.asyncronously ....the sktech was not resetting anymore but as soon as i returned from the function (destroynd the Process object) the linux command was destroyed too.
With this first change i was not getting anymore the connection refused error (because sketch was always running) but my script was not running entirely.
At last, when i discovered Process behaviour i executed my script with "nohup" command at beginning to avoid disruption of the process.
May i suggest to add an option to the Process.Run to destroy or not destroy the process ?
Hope to be helpful for somebody....
Ettore
PS: of course last version, at least for me, seems ok!
c++ calls destructors as soon the an object scope is closed ("closed" ? I'm not sure of the term, anyway...)
To avoid that, the easy way is to declare the object in a wider scope. With Arduino sketches, you can declare the object outside of any function.
Yes, i can do it but i think that as soon as i use Process.begin() my previous command would be destroyed....
since i need to execute lots of commands (can be 2-3 at the same time) i need a way to avoid disruption of the linux process....
Instantiate as many Process objects as you need (and yes, begin calls close)
I understand but i can not know the max number of process: it is an error detection system so i may have zero errors or 10 concurrent errors (wiith scripts to be executed) so it has been easier to avoid linux SIGTERM the process!