Cannot access the web page on old EmonSD version

I am able to SSL logon to my active RPi 2B running an ancient EmonSD-13-08-14.img, but I cannot access the web page via a browser. I tried several browsers and power reset the RPi, still no response. It’s a rather old image but its still functioning fine sending EmonTxV3 data to EmonCMS.org. I want to enable local data for a number of the minor inputs/feeds and retain key feeds to EmonCMS.org for external access. I flashed EmonSD-01-Feb-24.img to a spare RPi 3 and can access its web page fine, so its not a network or browser issue. Thank you in advance for any pointers, its been an interesting time relearning everything after 10 years of faultless operation. I have 2 questions please.

  1. Any thoughts before I rebuild everything on the later image and RPi3? As it stands it will be a complete rebuild of everything, configuring the inputs and feeds exactly the same and replicate the current API’s somehow. (Or do my EmonCMS.org login credentials sort that?)

  2. Will the new EmonSD-01-Feb-24.img on the newer RPi3 recognize the old RFM12Pi wireless module if I shift it onto the RPi3? Edit: Tried and Failed, looks like it defaults to the later RFM69 radio module.

The old adage is don’t fix what ain’t broke, I just broke my working RFM12Pi module.

I fired up a RPi 3 with the EmonSD-01-Feb-24.img and used the Update function thinking I was adding RFM12 capability. Wrong. It seems I have instead changed the RFM12 firmware with rfm12pi_jeelib firmware which is incompatible with my ancient emonTXv3 and other Tx devices. I am now stuck, on a slightly positive note I can still SSH to the Rpi, but I’ll need help to revert the firmware. Help.

I’m not sure how much the Admin →Update function replaces - it’s never been clear to me, @Trystan should be able to tell you. I think you might have replaced the JeeLib software in the “emon” part of your emonPi with the LPL software, which needs a RFM69CW radio module to work, Failing that, to the JeeLib software but with the RFM69 flag set.

What you need to do first is check which RFM you have in your emonPi. The pictures here RFM12B & RFM69CW Wireless Transceiver Modules — OpenEnergyMonitor 0.0.1 documentation should tell you.

Then you need to get & compile the appropriate sketch for the “emon” part of the emonPi. If it really is a RFM12B, I think you’ll need to dig deep into Github to find the appropriate sketch, or change a RFM69CW sketch back to work the RFM12B. If it’s a RFM69CW, things are a lot easier.
Start reading here Firmware — OpenEnergyMonitor 0.0.1 documentation

I DON’T recommend loading platfomio on your normal computer - when I tried it, it screwed up and moved my files around, and broke my scripts for updating from Github etc. It might be OK if it’s sandboxed in the RPi.
I use the Arduino IDE on my laptop, always.

 

For what it’s worth, here is my script for updating the emonPi front end software, after compiling it on this laptop using the Arduino IDE.
Be sure to check it carefully and change what applies to you before you try to use it. I don’t know if there’s a standard/preferred temporary place for the file in the Pi (and if there is, I’ve never found where it’s documented), so the directory I’ve used seemed a good idea at the time!

[You don’t need to set up the pair of key files, you could type the commands & passwords instead. I find it a lot easier to have this laptop rather than me authorised to communicate.]

#!/bin/bash

# Needs SSH enabling on emonPi / emonBase. For emonPi only, use front panel LCD menu & pushbutton. For both, add an empty file named "SSH" in the root partition.
#
# Generate a SSH key pair with "ssh-keygen" Don't set a password
# Keys are in /home/r/.ssh  files are private key: id_rsa; public key: id_rsa.pub
# Copy to the Pi with "ssh-copy-id [remote id]  e.g.remote-id = '[email protected]', password "emonpi2016" is required ]
# Needs SSH & SCP on source machine. Avrdude should exist on the Pi.
#
# Old RFM12Pi with RFM69CW has 38400 baud rate for serial comms, or possibly 9600. The rest: 115200
# Programming baud rate is always 115200

remotemachine='[email protected]'
sourcefile='/home/r/OpenEnergy/Software/rfmNATIVE/EmonPiCM/emonPiFrontEndCM/emonPiFrontEndCM.ino.standard.hex'
targetfile='/opt/openenergymonitor/emonpi/firmware/compiled/emonPiFrontEndCM.ino.standard.hex'

echo This can take about 45 seconds to complete
echo
echo Remote machine is $remotemachine
echo

scp $sourcefile $remotemachine:$targetfile

ssh $remotemachine sudo service emonhub stop

ssh $remotemachine avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:$targetfile

ssh $remotemachine sudo service emonhub start

exit

Thankyou @Robert.Wall you have given me some pointers and research to do. Its definitely a RFM12Pi as I looked at the original purchase invoice from 2014. The update function has changed firmware on the RFM12B AtMega 328 sub board because it no longer functions when installed on my original RPi running the original image. I have 3 x emonTH, 1 x emonTxV3 and 1 x Mk 2 PV router so reverting to the original RFM firmware is the path of least resistance. I guess its a learning experience.

image

Firmware update is a separate item.

Chances are, the log partition was full.

OK, so you have an emonBase, it wasn’t clear initially.

@borpin So a “Full update” is a full update except it doesn’t update everything. :roll_eyes:

@porboynz
If you did the “Not Full update”, and didn’t follow it up with the ‘JeeLib RFM69’ or the ‘LPL RFM69’ updates, then according to the words on the Update page of emonCMS, you should still have the ‘JeeLib RFM12B’ software in your RFM12Pi module.

I did some work on the emonBase to get a “rfmNATIVE” version, and you need to tread very carefully as a comment in the file indicates. I suggest you check the exact processor version:

*********************************************************************************************
*                                                                                           *
*                                  IMPORTANT NOTE                                           *
*                                                                                           *
* When compiling for the RFM2Pi:                                                            * 
*  In IDE, set Board to "Arduino Pro or Pro Mini" & Processor to "ATmega328P (3.3V, 8MHz)"  *
* When compiling for the RFM69Pi:                                                           *
*  In IDE, set Board to "Arduino Uno"                                                       *
*                                                                                           *
* The output file used must NOT be the "with_bootloader" version, else the processor will   *
*  be locked.                                                                               *
*********************************************************************************************

I’ve also got this file in a directory called “Original” - I can’t remember now if it really is what it says. The file name “src.ino” is not exactly helpful. :worried:
src.ino (17.6 KB)
It looks as if this too is set up for the RFM69CW radio, but can be changed back:

``#define RF69_COMPAT 1 // define this to use the RF69 driver i.s.o. RF12
Comment the line or set it to zero (false).

I think you really need @TrystanLea’s help to identify the correct sketch for your RFM12Pi.

Full software update - pretty clear what it does.

Regarding the log partition, I am not sure what I am looking for but ran the DU and DF commands as follows, the log sizes do not look outrageous as I am posting to emoncms.org? I am using the original 4GB SD card from 2014 so perhaps it’s failing.

@Robert.Wall first off thank you for your assistance so far, I have done some more research as advised and I am becoming more familiar with the terminology and understand better the problem I most definitely caused. I did action the JeeLib RFM69 update in error, I wrongly thought I was adding RFM12Pi capability to the emonBase sketch, not overwriting the actual RFM12Pi module.

I did some more searching and found a thread from Oct 2018 where you assisted @Frans who apparently did exactly what I did. More searching and I think I have found the hex file I need called ‘RF12_Demo_atmega328.cpp.hex’

Here are the suggested commands from the 2018 post using avrdude to write to the ATMega328.

sudo service emonhub stop

avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 -U flash:w:/home/pi/RFM2Pi/firmware/old/RF12_Demo_atmega328/RF12_Demo_atmega328.cpp.hex

sudo service emonhub start

Q. Probably a daft question, but how do I get the downloaded hex file from my laptop into the RPi3 and where should it be located so that avrdude can upload it.

Does that exist on your downloaded SD card? When I mount the Feb 24 image on here, it’s at
/opt/openenergymonitor/RFM2Pi/firmware/old/RF12_Demo_atmega328
It’s worth looking, and if it is, fast-forward to the avrdude command to write it into the RFM12Pi.

I think this is the right one - I succeeded in finding it only yesterday RFM2Pi/firmware/old/RF12_Demo_atmega328/RF12_Demo_atmega328.cpp.hex at master · openenergymonitor/RFM2Pi · GitHub

What does your laptop run? I use Ubuntu, and all the commands you need are in the script in post no. 3, you must change the source and target files as necessary. If you use Windoze, I don’t know. I gave it up when Win8 appeared.

One way is “scp” (or a derivative) or any file transfer utility, another is to take the SD card to your laptop and copy the file across, another is to SSH into the RPi and fetch it from Github (wget or I think you may have Github in emonCMS, so git fetch if you understand it - I don’t), and there must be more.

I don’t know. I used what looked to be a sensible place, which was

'/opt/openenergymonitor/emonpi/firmware/compiled/emonPiFrontEndCM.ino.standard.hex'

Your file name is of course different, and you tell it where to look [$targetfile] in the command to avrdude, viz

ssh $remotemachine avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:$targetfile

rootfs is at 95% is your problem.

/home/pi/data is at 4% so there is space.

/var/log filling up - system stops has some suggested solutions.

[edit]
Try looking elsewhere as well for a large file, but I suspect it is just too small now.

Use the USB ‘upgrade’ method to move to move to a new card.

@Robert.Wall SUCCESS! I now have a working RF module on my original emonHub sending data to emoncms.org. Grateful thanks for your patience guiding me through the Linux processes. My next step is to move the RFM12Pi module onto the newer RPi3 running the latest version of emonHub, which is basically where I was a few days ago. I will stay well away from that Update function until I have a better understanding.

1 Like

Thanks for these suggestions. Now that the RFM12Pi issue is resolved I can look at repairing my old emonbase from 2014, although my preference is to migrate to a newer image on a RPi 3. (with a 32GB SD)

Despite your desire to not fix it (until it’s broke :roll_eyes: ), it always pays to stay more-or-less up to date with emonCMS versions, because we don’t and can’t maintain backwards compatibility for ever.

I have installed the functioning RFM12Pi module in a RPi 3 with a fresh 01 Feb 24 image. I am uncertain how to modify the interfacer config to recognise this old RFM module, the default config assumes I have a later RFM69.

[interfacers]
    ### This interfacer manages the RFM12Pi/RFM69Pi/emonPi module
    [[EmonPi2]]
        Type = EmonHubOEMInterfacer
        [[[init_settings]]]
            com_port = /dev/ttyAMA0
            com_baud = 115200
        [[[runtimesettings]]]
            pubchannels = ToEmonCMS,
            subchannels = ToRFM12,
    
    [[USB0]]
        Type = EmonHubOEMInterfacer
        [[[init_settings]]]
            com_port = /dev/ttyUSB0
            com_baud = 115200
        [[[runtimesettings]]]
            pubchannels = ToEmonCMS,
            subchannels = ToRFM12,
            nodename = emonTx4
    
    [[SPI]]
        Type = EmonHubRFM69LPLInterfacer
        [[[init_settings]]]
            nodeid = 5
            networkID = 210
            resetPin = 24
            selPin = 16
        [[[runtimesettings]]]
            pubchannels = ToEmonCMS,
    
    
    [[MQTT]]
        Type = EmonHubMqttInterfacer
        [[[init_settings]]]
            mqtt_host = 127.0.0.1
            mqtt_port = 1883
            mqtt_user = emonpi
            mqtt_passwd = emonpimqtt2016
        
        [[[runtimesettings]]]
            pubchannels = ToRFM12,
            subchannels = ToEmonCMS,
            
            # emonhub/rx/10/values format
            # Use with emoncms Nodes module
            node_format_enable = 0
            node_format_basetopic = emonhub/
            
            # emon/emontx/power1 format - use with Emoncms MQTT input
            # http://github.com/emoncms/emoncms/blob/master/docs/RaspberryPi/MQTT.md
            nodevar_format_enable = 1
            nodevar_format_basetopic = emon/
            
            # Single JSON payload published  - use with Emoncms MQTT
            node_JSON_enable = 0
            node_JSON_basetopic = emon/
```

Here is what I have

### This interfacer manages the RFM12Pi/RFM69Pi/emonPi module
[[RFM2Pi]]
    Type = EmonHubJeeInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 38400                        # 9600 for old RFM12Pi
    [[[runtimesettings]]]
        pubchannels = ToEmonCMS,
        subchannels = ToRFM12,

        group = 210
        frequency = 868
        baseid = 5                              # emonPi / emonBase nodeID
        calibration = 230V                      # (UK/EU: 230V, US: 110V)
        quiet = true                            # Disable quite mode (default enabled) to enable RF packet debugging, show packets which fail crc
        # interval =  300                         # Interval to transmit time to emonGLCD (seconds)

868 (MHz is probably wrong for you), as might be 38400 (baud) - it says 9600 in here RF12_Demo_atmega328.ino, otherwise try other values until it works.

Use the old emonhub config. Should work.

433MHz and 9600 Baud worked, I can now see inputs. Now the challenge is sorting the correct templates to match the inputs, I suspect I’ll need to create custom templates for some.

Have you migrated your old setup across?

Count the bytes for the node you require the data format (always an even number, ignore the RSSI), then look in here:
RF Payloads.ods (47.1 KB)
RF Payloads.xls (31.5 KB)