Initially I didn’t recognize some of the serial output such as
handleInput69() start
I have since found and older post by you and suspect you are using LowPowerLabs rather than JeeLib. As far as I’m aware this isn’t an issue on JeeLib based emonPi’s so I would suggest looking closer at the code and Lib. But if you cannot get it sorted, or prefer to have a manual reset option (IMO the emonpi image should have one) all you need to do is pulse the reset line of the emonpi addon board (used for programming) to 0v via the Pi’s GPIO pin 7, here’s a little script I use
#!/usr/bin/env python
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)
can also be downloaded and installed with
#rpi-rw # not required on latest emonpi image
sudo wget https://openenergymonitor.org/forum-archive/sites/default/files/reset_rfm2pi.txt -O /usr/bin/reset_rfm2pi
sudo chmod +x /usr/bin/reset_rfm2pi
after which just issuing the command reset_rfm2pi from the commandline (any cwd) will reset the emonpi board.
It would be good to see this triggered from a button in emoncms to save you ssh’ing in and/or so that users could “find” a newly attached AC or CT sensors etc.
I should have added “The FAQ has a note about this, because many users are completely bewildered when the front end doesn’t reset when they reboot the Pi.”
If we ever go to the front end accumulating kWh, then there’s an argument to not automatically restart the front end. Until then, the expectation seems to be that the front end resets when the Pi is rebooted. But it doesn’t.
I agree, IMO there is rarely a good argument for rebooting, resetting or restarting things. In the case of the emonpi, the discovery portion of the startup() could be wrapped in a function and triggered from a serial command (as well as called during startup), but that would demand some work in emonhub as it has sole access to the emonpi serial port under normal running.
But this reset would work as a stop gap and also for debugging issues and special circumstances like this thread and/or when rfm2pi/emonpi “lock ups” occur.