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.
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?
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!
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.
I have created an issue for further discussion
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…