My system stopped on 14 Oct 2023 and today I had some time to look at fixing it.
Overview (as at time of issue occurring)
Raspberry Pi 2B v1.1 with a RFM69Pi (SKU: RFM69Pi_433), software up to date as of 13/10/2023
Pi Power: PoE splitter from a POE+ TP Link switch
1 x emonTx (SKU: emonTxV3) with 2 x 100A max clip-on current sensor CT (SKU: SCT013-000), Optical Utility Meter LED Pulse Sensor, Power Supply & RJ45 DS18B20
2 x emonTH (SKU: emonTH_V2), one with 2 x DS18B20 (SKU: ERTSK)
After resolving several issues, some of my own making (not really relevant to my ultimate issue but might help others in the future):
Using a 60W mobile phone PSU which was swapped out for a genuine Raspberry Pi PSU due to power supply issues (i.e. crashed soon after boot).
Running the latest Raspberry Pi OS (Legacy) with the RFM69Pi attached which failed to completely boot on 2 x Pi 2B v1.1’s, removing the RFM69Pi resolved this.
My actual issue:
On watching the boot-up of the original SD card, it stopped at 70% of disk 1 progress check (after a message of ‘random: 7 urandom warning(s) missed due to ratelimiting’, this is after a start failure of the Uncomplicated Firewall.
I have created a new SD using the latest emonSD image (emonSD-10Nov22 (Stable)) by following the instructions here:
The import appears to have been successful with the original user/password login and the input definitions looking correct.
However there is no current data received on the ‘Inputs’ GUI.
I have attached the EmonHub debug log file.
Before I start to spend any more time looking into whether I need to perform any firmware updates to accommodate the CM operational mode, please could someone assist in the easiest way forward for me to restore my set-up.
Sorry I cannot upload the emonhub.txt file because I get the error: Sorry, the file you are trying to upload is not authorised (authorised extensions: jpg, jpeg, png, gif, zip, tar, ino, ico, txt, pdf, sch, brd, odt, gz, mp4, mov, ods, csv, doc, webm, bin, hex, webp, xlsx, xls).
Did you mean emonhub.conf? Failing that, zip it and upload the zipped file.
I’m afraid I can’t help with MQTT - I know nothing about it.
“WARNING MQTT Connection refused - not authorised” would imply to me a password is missing, or has been overwritten when you restored the backup.
If you have mixed radio protocols, that’s a big problem. You must consistently use either JeeLib ‘Classic’ (the original) OR JeeLib ‘Native’ OR LPL with each radio module in your installation. There is no interoperability between any of the three.
JeeLib ‘Classic’ and JeeLib ‘Native’ can be used with both the RFM12B and the RFM69CW radios.
LPL can only be used with RFM69 radios.
The emonPi can only do CM when using either JeeLib ‘Native’ or LPL.
Oddly even though I followed the instructions not to change the default username of ‘pi’ when I created the SD card image, there seems to be an issue with that user as well as the ‘emon’ username. Also I know the ‘emon’ username was active on 1st power up because I struggled to find the default password for it.
Emoncms Log
2023-11-05 20:46:12.057|ERROR|user_model.php|Login: Username does not exist username:pi ip:192.168.0.20
2023-11-05 20:49:13.123|ERROR|user_model.php|Login: Username does not exist username:emon ip:192.168.0.20
It looks as if you might have the wrong baud rate for the RFM2Pi / RFM69Pi
2023-11-05 21:03:15,089 ERROR MainThread Could not open serial port: /dev/ttyUSB0 @ 115200 bits/s (retry every 10s)
…
2023-11-05 21:03:15,223 ERROR MainThread Could not connect to RFM69 module
Try 115200 or 9600 for /dev/ttyAMA0 (just restart emonhub after editing in emonhub.conf)
@Robert.Wall I agree that it looks like users could have been overwritten, hopefully someone can advise on how to re-add them because it will only re-occur if I redo the SD card & import.
As for the radio protocols, originally I would have been running JeeLib ‘Classic’ because I have a emonTxV3, do you know how I can tell what is now set on the Pi’s RFM69Pi?
Looking at the emonhub log, it appears to be using LPL, please can you confirm either way. Also is it then just a case of updating the firmware via the GUI if this is the case?
I might switch to LPL later once I get this issue sorted.
I was replying and saw your additional response about the baud rate, therefore I had a look at the logs and noticed that error occurred twice and then no longer appeared. I have changed it from 38400 to 115200 but it has not fixed the issue even after a reboot (yes I initially tried a emonhub restart).
I won’t now get an opportunity to look at this again until tomorrow evening at the earliest.
I can’t confirm for certain, but I believe there’s a push to move to LPL, therefore if it appears to be LPL, it probably is LPL. There’s no way LPL will receive anything other than data from another LPL radio.
You should be able to ‘downgrade’ your Pi to using JeeLib Classic, but you won’t be able to have CM on the Pi, that will need to downgrade to the DS version.
It’s probably best long-term to stay with LPL on your Pi and change the emonTx V3 and anything else to LPL.
Issue resolved by replacing the MQTT password with the default (emonpimqtt2016).
I hadn’t changed it previously and it looks like the ‘Archive Export’ encrypts the MQTT credentials (as it looks to be in that format), and then on import it is not decrypted.
Also after an Emonhub restart, the inputs were not reliably being read, a full reboot seems to have resolved this additional issue.