However if you look at the Archive.zip content there is an emonhub.log.1 and an emonhub.log.2 where the log file has been rotated out.
I had a very brief look (as I’m doing other stuff today) and there deosn’t appear to be anything of huge concern towards the end of the file, the last packet received was fully processed, it simply looks like the packets to stopped coming, therefore everything (emonhub, emoncms and the log files) just appears to have stopped because there isn’t anything to process.
Can you confirm the LED on the rfm2pi is flashing (when running ok and when “stopped”)?
Try creating this little script as /home/pi/reset_rfm2pi.py, you will need to use the rpi-rw command first to make the filesytem writable.
#!/usr/bin/env python
"""
"""
__author__ = 'Paul Burnell (pb66)'
__date__ = '14-05-2015'
# http://openenergymonitor.org/emon/node/5549
import RPi.GPIO as GPIO
import time
pin = 7 # P1-7 (BCM pin 4 or WiringPi pin 7)
try:
GPIO.setmode(GPIO.BOARD)
GPIO.setup(pin, GPIO.OUT)
GPIO.output(pin, GPIO.HIGH)
time.sleep(0.12)
GPIO.output(pin, GPIO.LOW)
GPIO.cleanup()
except Exception as e:
print(e)
make it executable
sudo chmod +x /home/pi/reset_rfm2pi.py
and next time it stops try running it with
sudo /home/pi/reset_rfm2pi.py
It simply pulses the reset line for the rfnm2pi causing the processor to restart.
If this kickstarts everything back off then it is the RFM2Pi that is freezing and restarting emonhub is simply resetting the serial port and the rfm2pi in the process. (See RFM69Pi stops updating/freezes and the many linked threads on the old forum for further info on this)
However! I have never seen a lockout rfm2pi restart of it’s own accord. This makes me think this might be an RF collision issue. Although I have never experienced it, in theory it might be possible the last received packet was the last packet transmitted in “clean air”, the next packet may have started transmitting (or deferred transmitting) before this one had finished and the next before this one finished, effectively getting a rolling blockage. 4hrs seems along time, but with 20 nodes?
You can also check the rfm2pi is seated correctly (square and straight) and it’s not shorting on the unused gpio pins below the antenna wire.