I think this is a bug.
I have a fresh emonPi from the shop for dev. purposes.
I connect the AC-AC adaptor, a CT, ethernet and then the USB last.
I create an emoncms account and view the input page. I have NULLs all the way down.
This normal? I need the Vrms and Current values so I can send them places with MQTT.
Seems on repeat.
Jul 15 22:45:42 emonpi systemd[1]: emonhub.service: Service RestartSec=100ms expired, scheduling restart.
Jul 15 22:45:42 emonpi systemd[1]: emonhub.service: Scheduled restart job, restart counter is at 3.
Jul 15 22:45:42 emonpi systemd[1]: Stopped emonHub service description.
Jul 15 22:45:42 emonpi systemd[1]: Starting emonHub service description...
Jul 15 22:45:42 emonpi systemd[1]: Started emonHub service description.
Jul 15 22:45:42 emonpi emonhub.py[428]: Traceback (most recent call last):
Jul 15 22:45:42 emonpi emonhub.py[428]: File "/usr/local/bin/emonhub/emonhub.py", line 23, in <module>
Jul 15 22:45:42 emonpi emonhub.py[428]: import emonhub_setup as ehs
Jul 15 22:45:42 emonpi emonhub.py[428]: File "/opt/openenergymonitor/emonhub/src/emonhub_setup.py", line 13, in <mod
Jul 15 22:45:42 emonpi emonhub.py[428]: from configobj import ConfigObj
Jul 15 22:45:42 emonpi emonhub.py[428]: ModuleNotFoundError: No module named 'configobj'
Jul 15 22:45:42 emonpi systemd[1]: emonhub.service: Main process exited, code=exited, status=1/FAILURE
Jul 15 22:45:42 emonpi systemd[1]: emonhub.service: Failed with result 'exit-code'.
Jul 15 22:45:42 emonpi systemd[1]: emonhub.service: Service RestartSec=100ms expired, scheduling restart.
It is an update problem we thought was fixed. Have you just run one? Is there anything in the update log? Try running just the emonhub update.
got it
sudo apt update
sudo apt install python3-pip
sudo pip3 install configobj
sudo pip3 install serial "I also did pyserial, so am not confident on what met the requirement there"
sudo pip3 install paho-mqtt
emonhub logs have started rolling, inputs page now showing the values.
I’d run the update. Here’s the log -
emonpiupdate.txt (10.1 KB)
“sudo: pip3: command not found”
Just try running the update again.
Strictly, you should not use sudo with pip3.
K, it’s fixed now anyway. See what happens…
I HAD to run them as sudo for the modules to be found.
emonpiupdate.txt (15.9 KB)
That log file suggests that apt was already being used when it tried to install pip:
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
sudo: pip3: command not found
The script should retry, or fail, if that happens, rather than continuing with a broken system.
@borpin Is there a reason not to install python modules to the system path?
Makes sense it should pause and retry a few times, I was doing nothing with apt.
@bwduncan Do you think the update would have worked if I’d tried 5 minutes later?
IMHO the correct solution is to do all this the other way round. Make a set of deb packages which depend on the appropriate python packages, which have config files which can be updated in the post-install scripts. That’s a much more reliable way to get the system either fully working or fully broken in an obvious way (e.g. the emonhub package just won’t install if it can’t install python3-configobj).
Hard to say… If you weren’t using apt manually yourself then it seems likely. How long you (or the script) should have to wait is one of the unanswerable questions in computing, though!
Well if you are offering…
I suspect trying to keep all that up to date is not an insignificant task.
This problem had never been identified previously, hence why the scripts have not checked for that. Is there an easy way to determine if apt is busy? I think there is a routine service that checks apt.
[edit]
I have created an issue for further discussion
Highly likely. It would have been one of these running;
systemctl status {apt-daily-upgrade.timer,apt-daily.timer}
Discussing this with the team it seems I was handed these two emonPi that hadn’t been updated properly in the lab.
All emonPi are typically allowed to do an update before shipping – this first update can take a long time (20 minutes is sometimes allowed) – so clearly I hadn’t the patience to wait. In my defence the update logs weren’t rolling, so it was confusing…