Similar behaviors have been reported but when using the Edison's SPI interface. Do you use SPI on your scripts? In case you don't, could you share your script with us? I would like to check it to see if I can find something out.
A workaround for this issue, might be to restart the scripts from time to time. You could set a timer to restart your script every couple of hours or so. Do you think that this could be a viable "solution" for your project?
Here is the code for the redis connection: [Python] import redis import urllib2 import urllib import requests import time r = - Pastebin.com
I am currently logging every message the redis connection receives and I am also monitoring the "edipy-ack" channel on redis. I will probably have to wait until tomorrow to have more results.
As for your suggestion, I already tried re-connecting to redis at a certain interval. I didnt think about just restarting the service every few hours. After I have the results from my current test and can be 100% sure that it is in fact the redis connection that is faulty, I'll give that a shot.
A quick update:
I was able to test both methods today. My logging showed me that the connection did not receive any messages via redis, so my guess is that it is either timed out (python is not throwing any exceptions, though) or the connection is frozen (as in not receiving any updates, polling forever). Restarting the service did not help, only everytime I reconnect to my edison via ssh I can use the redis connection after a few seconds again. This probably means that it is some misconfiguration, but I really don't know whats going on.
I see, I have never experienced anything like this before. I'd like to run a simple test to see if my Edison loses its connectivity as well. How long does it take your Edison to go to this "sleep" mode?
This is the script I'm going to run in the background:
#!/bin/sh declare -i cont=0 while true do cont=$cont+1 echo -e "\n\nCicle: $cont\n" >> log.txt ping www.google.com -c 2 >> log.txt echo -e "\n\nDate & Hour\n" >> log.txt date >> log.txt sleep 5m done
I invite you to test it again to see if we get similar results.
Started it on mine too.
This usually happens when I get back from work, so roughly 8 hours.
I left my Edison almost 24 hours on and I was not able to replicate the issue, the worst case-scenario I was able to see in the log is that the Edison occasionally lost one of the packets. How was your test? Did you see any different behavior?
Had mine running until now, too. No issues with it. So at this point I am almost 100% certain that it is a problem with the redis-py lib rather than my edison itself. I found a similar issue in the library (Long running listen expires after certain days · Issue #705 · andymccurdy/redis-py · GitHub). I will try the solution(s) posted there and if I cant get it to work I'll open an issue on their github. I highly doubt at this point that it is the edisons fault.