Integrating EmonTx V4 with EmonBase

Hi all. I’m looking for some help to get a system up and running. I’m trying to get some support directly from Glyn and Trystan, but I have no solution yet. I’m not a whiz with the whole system, but I can connect locally (using the web interface and/or using PuTTy).

Any suggestions on what I could try next?

I previously had an EmonPi + EmonTx V3 (with ACAC adapter) + Current Clamp. I had to replace the EmonTx V3, and I purchased the V4 (naively) assuming it was a drop-in replacement for the V3. Subsequently, I had to get an ACAC adapter PCB, and a voltage clamp for the V4.

So, now my system is:

Voltage O/P: 100A Clip-on CTEmonTx V4 (with ACAC adapter, and USB power supply)EmonPi

I can connect the EmonTx V4 directly to the EmonPi via USB and I can see data from Node 17. But, I don’t see USB + Radio data in this configuration. According to the OEM wiki ‘If you have connected the emonTx4 to the emonBase directly via USB it will appear twice, first under the emonTx4_xx node name corresponding to data received over radio and second under the ‘emonTx4’ node name corresponding to data received directly over USB.’. I’ve tried running LowPower and Jeelibs classic firmware and I see no difference.

Ultimately, I would like communicate with the V4 via the radio link only, and not USB.

Summary:

  1. Config file: updated to include node 17 info.
  2. Config file: added interfacer to allow USB communication.
  3. Direct USB connection from EmonPi → EmonTx V4 – shows valid data.
  4. Tried LowPower and Jeelibs Classic to see if radio link worked.
  5. When the USB cable is removed, there is no radio link/comms.

And this is my current config file:

#######################################################################
####################### emonhub.conf #########################
#######################################################################
### emonHub configuration file, for info see documentation:
### https://github.com/openenergymonitor/emonhub/blob/emon-pi/configuration.md
#######################################################################
####################### emonHub settings #######################
#######################################################################

[hub]
### loglevel must be one of DEBUG, INFO, WARNING, ERROR, and CRITICAL
loglevel = DEBUG
### Uncomment this to also send to syslog
# use_syslog = yes
#######################################################################
####################### Interfacers #######################
#######################################################################

[interfacers]
### 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 = 433
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)
[[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 = 1
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/

[[emoncmsorg]]
Type = EmonHubEmoncmsHTTPInterfacer
[[[init_settings]]]
[[[runtimesettings]]]
pubchannels = ToRFM12,
subchannels = ToEmonCMS,
url = https://emoncms.org
apikey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
senddata = 1 # Enable sending data to Emoncms.org
sendstatus = 1 # Enable sending WAN IP to Emoncms.org MyIP > https://emoncms.org/myip/list
sendinterval= 30 # Bulk send interval to Emoncms.org in seconds

#######################################################################
####################### Nodes #######################
#######################################################################

[nodes]

## See config user guide: https://github.com/openenergymonitor/emonhub/blob/emon-pi/conf/emonhub.conf

[[5]]
nodename = emonpi
[[[rx]]]
names = power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulsecount
datacodes = h, h, h, h, h, h, h, h, h, h, L
scales = 1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units = W,W,W,V,C,C,C,C,C,C,p

[[6]]
nodename = emontxshield
[[[rx]]]
names = power1, power2, power3, power4, vrms
datacode = h
scales = 1,1,1,1,0.01
units = W,W,W,W,V

[[7]]
nodename = emontx4
[[[rx]]]
names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
units = W,W,W,W,V,C,C,C,C,C,C,p

[[8]]
nodename = emontx3
[[[rx]]]
names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
units = W,W,W,W,V,C,C,C,C,C,C,p

[[9]]
nodename = emontx2
[[[rx]]]
names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
units = W,W,W,W,V,C,C,C,C,C,C,p

[[10]]
nodename = emontx1
[[[rx]]]
names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
units = W,W,W,W,V,C,C,C,C,C,C,p

[[11]]
nodename = 3phase
[[[rx]]]
names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
units = W,W,W,W,V,C,C,C,C,C,C,p

[[12]]
nodename = 3phase2
[[[rx]]]
names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
units = W,W,W,W,V,C,C,C,C,C,C,p

[[13]]
nodename = 3phase3
[[[rx]]]
names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
units = W,W,W,W,V,C,C,C,C,C,C,p

[[14]]
nodename = 3phase4
[[[rx]]]
names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
units = W,W,W,W,V,C,C,C,C,C,C,p

[[15]]
nodename = emontx3cm15
[[[rx]]]
names = MSG, Vrms, P1, P2, P3, P4, E1, E2, E3, E4, T1, T2, T3, pulse
datacodes = L,h,h,h,h,h,l,l,l,l,h,h,h,L
scales = 1,0.01,1,1,1,1,1,1,1,1,0.01,0.01,0.01,1
units = n,V,W,W,W,W,Wh,Wh,Wh,Wh,C,C,C,p
whitening = 1

[[16]]
nodename = emontx3cm16
[[[rx]]]
names = MSG, Vrms, P1, P2, P3, P4, E1, E2, E3, E4, T1, T2, T3, pulse
datacodes = L,h,h,h,h,h,l,l,l,l,h,h,h,L
scales = 1,0.01,1,1,1,1,1,1,1,1,0.01,0.01,0.01,1
units = n,V,W,W,W,W,Wh,Wh,Wh,Wh,C,C,C,p
whitening = 1

[[19]]
nodename = emonth1
[[[rx]]]
names = temperature, external temperature, humidity, battery
datacode = h
scales = 0.1,0.1,0.1,0.1
units = C,C,%,V

[[20]]
nodename = emonth2
[[[rx]]]
names = temperature, external temperature, humidity, battery
datacode = h
scales = 0.1,0.1,0.1,0.1
units = C,C,%,V

[[21]]
nodename = emonth3
[[[rx]]]
names = temperature, external temperature, humidity, battery
datacode = h
scales = 0.1,0.1,0.1,0.1
units = C,C,%,V

[[22]]
nodename = emonth4
[[[rx]]]
names = temperature, external temperature, humidity, battery
datacode = h
scales = 0.1,0.1,0.1,0.1
units = C,C,%,V

[[23]]
nodename = emonth5
[[[rx]]]
names = temperature, external temperature, humidity, battery, pulsecount
datacodes = h,h,h,h,L
scales = 0.1,0.1,0.1,0.1,1
units = C,C,%,V,p

[[24]]
nodename = emonth6
[[[rx]]]
names = temperature, external temperature, humidity, battery, pulsecount
datacodes = h,h,h,h,L
scales = 0.1,0.1,0.1,0.1,1
units = C,C,%,V,p

[[25]]
nodename = emonth7
[[[rx]]]
names = temperature, external temperature, humidity, battery, pulsecount
datacodes = h,h,h,h,L
scales = 0.1,0.1,0.1,0.1,1
units = C,C,%,V,p

[[17]]
nodename = emonTx4_17
[[[rx]]]
names = MSG, Vrms, P1, P2, P3, P4, P5, P6, E1, E2, E3, E4, E5, E6, T1, T2, T3, pulse
datacodes = L, h, h, h, h, h, h, h, l, l, l, l, l, l, h, h, h, L
scales = 1.0, 0.01, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 0.01, 0.01, 0.01, 1.0
units = n, V, W, W, W, W, W, W, Wh, Wh, Wh, Wh, Wh, Wh, C, C, C, p

[[26]]
nodename = emonth8
[[[rx]]]
names = temperature, external temperature, humidity, battery, pulsecount
datacodes = h,h,h,h,L
scales = 0.1,0.1,0.1,0.1,1
units = C,C,%,V,p

Welcome, Alan, to the OEM forum.

If your emonPi dates from the time you got your emonTx V3, then it’s going to be using JeeLib ‘Classic’ radio protocol.

Your emonTx 4 uses the LoPowerLabs protocol - and naturally, they’re not compatible. If you’ve got no other OEM devices. you need to change the emonPi to use RFM69 LowPowerLabs.

I can’t immediately see another reason for it not working.

Hi Robert. Thanks! Is there a quick way to check the version that the EmonPi and EmonTx are currently running? (So I can ensure they’re both aligned with the classic version)

This is what I see when I connect USB from Pi to EmonTx:

OpenEnergyMonitor.org
2024-02-01 21:07:48,985 DEBUG USB0 No EEPROM config
2024-02-01 21:07:49,088 DEBUG USB0 Settings:
2024-02-01 21:07:49,192 DEBUG USB0 Band 433 MHz, Group 210, Node 17, 7 dBm
2024-02-01 21:07:49,294 DEBUG USB0 Calibration:
2024-02-01 21:07:49,397 DEBUG USB0 vCal = 807.86
2024-02-01 21:07:49,499 DEBUG USB0 assumedV = 240.00
2024-02-01 21:07:49,602 DEBUG USB0 i1Cal = 300.30
2024-02-01 21:07:49,704 DEBUG USB0 i1Lead = 3.20
2024-02-01 21:07:49,806 DEBUG USB0 i2Cal = 150.15
2024-02-01 21:07:49,908 DEBUG USB0 i2Lead = 3.20
2024-02-01 21:07:50,010 DEBUG USB0 i3Cal = 150.15
2024-02-01 21:07:50,112 DEBUG USB0 i3Lead = 3.20
2024-02-01 21:07:50,214 DEBUG USB0 i4Cal = 60.06
2024-02-01 21:07:50,317 DEBUG USB0 i4Lead = 3.20
2024-02-01 21:07:50,419 DEBUG USB0 i5Cal = 60.06
2024-02-01 21:07:50,521 DEBUG USB0 i5Lead = 3.20
2024-02-01 21:07:50,623 DEBUG USB0 i6Cal = 60.06
2024-02-01 21:07:50,726 DEBUG USB0 i6Lead = 3.20
2024-02-01 21:07:50,828 DEBUG USB0 datalog = 9.80
2024-02-01 21:07:50,930 DEBUG USB0 pulses = 1
2024-02-01 21:07:51,032 DEBUG USB0 pulse period = 100
2024-02-01 21:07:51,134 DEBUG USB0 RF on
2024-02-01 21:07:51,242 DEBUG USB0 temp_enable = 1
2024-02-01 21:07:51,344 DEBUG USB0 JSON Format Off
2024-02-01 21:07:51,448 DEBUG USB0 RFM69CW Freq: 433MHz Group: 210 Node: 17
2024-02-01 21:07:51,551 DEBUG USB0 RadioFormat: LowPowerLabs
2024-02-01 21:07:51,655 DEBUG USB0 Reference voltage calibration: 1.0263
2024-02-01 21:07:51,759 DEBUG USB0 Temperature Sensors found = 0 of 3
2024-02-01 21:07:51,862 DEBUG USB0 Temperature measurement is enabled.
2024-02-01 21:07:52,068 DEBUG USB0 No temperature sensors detected, disabling temperature
2024-02-01 21:07:52,172 DEBUG USB0 AC present - Real Power calc enabled
2024-02-01 21:07:52,280 DEBUG USB0 ---------------------------------------------------------------------
2024-02-01 21:07:53,281 DEBUG USB0 Config format: new
2024-02-01 21:07:55,383 DEBUG USB0 ---------------------------------------------------------------------
2024-02-01 21:08:01,436 DEBUG USB0 40 NEW FRAME : MSG:2,Vrms:195.47,P1:-1,P2:0,P3:0,P4:0,P5:0,P6:0,E1:0,E2:0,E3:0,E4:0,E5:0,E6:0,pulse:0
2024-02-01 21:08:01,436 DEBUG USB0 40 Timestamp : 1706821681.435327
2024-02-01 21:08:01,437 DEBUG USB0 40 From Node : emonTx4
2024-02-01 21:08:01,437 DEBUG USB0 40 Values : [2, 195.47, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
2024-02-01 21:08:01,438 DEBUG USB0 40 Sent to channel(start)’ : ToEmonCMS
2024-02-01 21:08:01,438 DEBUG USB0 40 Sent to channel(end)’ : ToEmonCMS
2024-02-01 21:08:01,549 INFO MQTT Connecting to MQTT Server
2024-02-01 21:08:01,607 DEBUG emoncmsorg Buffer size: 1
2024-02-01 21:08:01,652 INFO MQTT connection status: Connection successful
2024-02-01 21:08:01,653 DEBUG MQTT CONACK => Return code: 0
2024-02-01 21:08:01,755 INFO MQTT on_subscribe
2024-02-01 21:08:11,208 DEBUG USB0 41 NEW FRAME : MSG:3,Vrms:195.44,P1:0,P2:1,P3:0,P4:0,P5:0,P6:0,E1:0,E2:0,E3:0,E4:0,E5:0,E6:0,pulse:0
2024-02-01 21:08:11,209 DEBUG USB0 41 Timestamp : 1706821691.208169
2024-02-01 21:08:11,210 DEBUG USB0 41 From Node : emonTx4
2024-02-01 21:08:11,210 DEBUG USB0 41 Values : [3, 195.44, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.0]
2024-02-01 21:08:11,211 DEBUG USB0 41 Sent to channel(start)’ : ToEmonCMS
2024-02-01 21:08:11,211 DEBUG USB0 41 Sent to channel(end)’ : ToEmonCMS
2024-02-01 21:08:11,502 DEBUG MQTT Publishing: emon/emonTx4/MSG 3
2024-02-01 21:08:11,503 DEBUG MQTT Publishing: emon/emonTx4/Vrms 195.44
2024-02-01 21:08:11,504 DEBUG MQTT Publishing: emon/emonTx4/P1 0
2024-02-01 21:08:11,506 DEBUG MQTT Publishing: emon/emonTx4/P2 1
2024-02-01 21:08:11,507 DEBUG MQTT Publishing: emon/emonTx4/P3 0
2024-02-01 21:08:11,508 DEBUG MQTT Publishing: emon/emonTx4/P4 0
2024-02-01 21:08:11,509 DEBUG MQTT Publishing: emon/emonTx4/P5 0
2024-02-01 21:08:11,511 DEBUG MQTT Publishing: emon/emonTx4/P6 0
2024-02-01 21:08:11,512 DEBUG MQTT Publishing: emon/emonTx4/E1 0
2024-02-01 21:08:11,513 DEBUG MQTT Publishing: emon/emonTx4/E2 0
2024-02-01 21:08:11,515 DEBUG MQTT Publishing: emon/emonTx4/E3 0
2024-02-01 21:08:11,516 DEBUG MQTT Publishing: emon/emonTx4/E4 0
2024-02-01 21:08:11,517 DEBUG MQTT Publishing: emon/emonTx4/E5 0
2024-02-01 21:08:11,518 DEBUG MQTT Publishing: emon/emonTx4/E6 0
2024-02-01 21:08:11,519 DEBUG MQTT Publishing: emon/emonTx4/pulse 0
2024-02-01 21:08:11,520 DEBUG MQTT Publishing: emon/emonTx4/missed 0
2024-02-01 21:08:11,522 DEBUG MQTT Publishing: emon/emonTx4/missedprc 0.0
2024-02-01 21:08:11,523 INFO MQTT Publishing ‘node’ formatted msg
2024-02-01 21:08:11,523 DEBUG MQTT Publishing: emonhub/rx/emonTx4/values 3,195.44,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0.0
2024-02-01 21:08:20,988 DEBUG USB0 42 NEW FRAME : MSG:4,Vrms:195.44,P1:0,P2:1,P3:0,P4:0,P5:0,P6:0,E1:0,E2:0,E3:0,E4:0,E5:0,E6:0,pulse:0
2024-02-01 21:08:20,989 DEBUG USB0 42 Timestamp : 1706821700.988244
2024-02-01 21:08:20,990 DEBUG USB0 42 From Node : emonTx4
2024-02-01 21:08:20,990 DEBUG USB0 42 Values : [4, 195.44, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.0]
2024-02-01 21:08:20,991 DEBUG USB0 42 Sent to channel(start)’ : ToEmonCMS
2024-02-01 21:08:20,992 DEBUG USB0 42 Sent to channel(end)’ : ToEmonCMS
2024-02-01 21:08:21,213 DEBUG MQTT Publishing: emon/emonTx4/MSG 4
2024-02-01 21:08:21,214 DEBUG MQTT Publishing: emon/emonTx4/Vrms 195.44
2024-02-01 21:08:21,215 DEBUG MQTT Publishing: emon/emonTx4/P1 0
2024-02-01 21:08:21,216 DEBUG MQTT Publishing: emon/emonTx4/P2 1
2024-02-01 21:08:21,217 DEBUG MQTT Publishing: emon/emonTx4/P3 0
2024-02-01 21:08:21,218 DEBUG MQTT Publishing: emon/emonTx4/P4 0
2024-02-01 21:08:21,219 DEBUG MQTT Publishing: emon/emonTx4/P5 0
2024-02-01 21:08:21,221 DEBUG MQTT Publishing: emon/emonTx4/P6 0
2024-02-01 21:08:21,222 DEBUG MQTT Publishing: emon/emonTx4/E1 0
2024-02-01 21:08:21,223 DEBUG MQTT Publishing: emon/emonTx4/E2 0
2024-02-01 21:08:21,224 DEBUG MQTT Publishing: emon/emonTx4/E3 0
2024-02-01 21:08:21,225 DEBUG MQTT Publishing: emon/emonTx4/E4 0
2024-02-01 21:08:21,226 DEBUG MQTT Publishing: emon/emonTx4/E5 0
2024-02-01 21:08:21,227 DEBUG MQTT Publishing: emon/emonTx4/E6 0
2024-02-01 21:08:21,228 DEBUG MQTT Publishing: emon/emonTx4/pulse 0
2024-02-01 21:08:21,229 DEBUG MQTT Publishing: emon/emonTx4/missed 0
2024-02-01 21:08:21,230 DEBUG MQTT Publishing: emon/emonTx4/missedprc 0.0
2024-02-01 21:08:21,231 INFO MQTT Publishing ‘node’ formatted msg
2024-02-01 21:08:21,232 DEBUG MQTT Publishing: emonhub/rx/emonTx4/values 4,195.44,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0.0

Why the ‘classic’ version? As far as I know, no decision has been made when, or indeed whether, JeeLib will no longer be supported. However I anticipate this will happen at some point. I believe there’s little active development in JeeLib, whereas LPL appears to be actively supported by its own group, which I believe was one consideration when the decision to change was made.

If you have no other OEM kit, I strongly advise you to convert to LPL. This is the ‘native’ protocol the emonTx4 is shipped with, and you can update the emonPi via Setup → Admin → update.

I had changed the Tx V4 to classic after Trystan suggested rolling back to that (in case the Pi was running ‘older jeelib firmware’). I have reverted back to LPL.

When we say the Pi ‘firmware’, is there a way check just that? From AdminSystem InfoEmonCMSComponents:

Components: Emoncms Core v11.4.5 | App v2.8.1 | EmonHub Config v2.1.5 | Dashboard v2.3.3 | Device v2.2.3 | Graph v2.2.3 | Network Setup v1.0.2 | WiFi v2.1.1 | Backup v2.3.3 | DemandShaper v2.2.3 | Postprocess v2.4.7 | Sync v2.1.5 | Usefulscripts v2.3.11 | EmonScripts v1.6.33 | RFM2Pi v1.4.2 | Emonhub v2.6.2 | EmonPi v3.0.3

Is there an indication from that that the Pi is running the correct firmware to interface with the LPL firmare on the Tx V4?

Anyone out there know if this is how I indetify that the EmonPi is running the ‘low power’ firmware (so I can interface with the EmonTx V4)?

I’m not running any other OEM equipment, just Pi + EmonTx V4.

If anyone has a record of what software is supplied and when, it will be ‘The Shop’ [email protected]
I’m afraid I gave up long ago trying to find my way around Github, I’ve never found any record there of when different versions have been published and only exceptionally rarely any indication of which and when is the “shipped” version for the hardware.

I have suggested that now it’s become possible to have incompatible libraries, the version used by both transmitting node and receiving node should be part of the data that’s printed at startup, but that seems to have fallen on deaf (or “too busy”) ears.

As far as I’m aware, the only sure way is to upload known pieces of software (which use the same library - I suggest LPL) to both the emonTx4 and the emonPi’s front end, where the radio receiver lives.

Thanks Robert, I really appreciate the help here… it’s not an inexpensive system, so I’m quite surprised by the lack of ‘official’ help. I’ve been trying since early January to resolve this with the team, but there has been very little support.

I’ve upgraded the EmonTx to LPL, and I’m trying to update the EmonPi via Admin → Update.

I’m connected locally (via WiFi) to the Pi, and on the update page I’m using the following settings:

UPDATE FIRMWARE ONLY

Select your hardware type and firmware version
Select port: ttyAMA0
Hardware: EmonPi
Radio Format: RFM69 LowPowerLabs
Firmware: emonPi continuous sampling firmware, lowpowerlabs, v1.1.4

But I’m getting sync and broken pipe errors:

avrdude-original: stk500_getsync() attempt 10 of 10: not in sync: resp=0xc7
avrdude-original done. Thank you.
strace: |autoreset: Broken pipe
ERROR: Not in sync
Restarting EmonHub

Any ideas what could be wrong here…?

emonpiRelease: emonSD-24Jul20

Unfortunately that error message only tells us that avrdude couldn’t communicate with the “emon” part of the emonPi. It gives us no clue as to why - it could one of many things.

But one slightly worrying thing is the emonSD version - we normally recommend staying up-to-date with the latest release. I don’t think this is the cause of the problem, however; as far as I know, the protocol for uploading the code has not changed. It’s probably worth updating emonCMS in any case.

@A_H @TrystanLea Some thoughts from my experiences which may help. Various changes that have happened during/since the emonTx4 launch may be causing your problems.

You need to have both the emonTx4 and the emonPi using the same radio format, either Jeelib or LPL. LPL is the latest format and is necessary for continuous monitoring (CM) on the emonPi (i.e. emonPi continuous sampling firmware, lowpowerlabs, v1.1.4).

If you have an emonPI (not an emonPi2), you might want to look at:

Updating an emonPi to emonPi_CM
and
Should I update Emon Pi firmware to CM, and how?
which may help.

In particular, from the first:

I don’t know if this is causing your firmware update problem … You may wish to try updating your emonPi scripts … I don’t know if this would cause more problems!

And assuming that you have the emonPi CM LPL firmware installed, from the second

It looks like you need to update your emonhub config file for the RFM2Pi (i.e. emonPi) interfacer, and for node 5 (emonPi)

Hope something here helps!

Thanks for the inputs Robert and Rupert.

@rupert - I can confirm that it’s an emonPi I’m using here.

I’ve updated the config file (interfacers and node for emonPi), emonCMS, and emonScripts (it was already up to date). The baud rate was definitely wrong in the interfacer. But, I still don’t see the radio data inputs.

So, I believe the issue is, as Rupert suggested, that the Pi cannot understand the V1.1.4 data.

One other warning in the update log for emonPi is:

avrdude-original: Using autoreset DTR on GPIO Pin 7
avrdude-original: stk500_recv(): programmer is not responding

I think the next step is to bring emonSD up to date…

Can either of you suggest the most reliable way to do this…?

All I can say is, for the emonPi I used when developing emonLibDB, I started with the SD card image downloaded. I tried the RFM2Pi update to that yesterday evening for you, and it went through without any problem. This was really my grounds for suggesting you update your emonCMS.

But starting with a download didn’t give me a problem with historic data because there wasn’t any! In your case, if you have data that’s precious, you need to back it up, then restore it when the new image is working.

Otherwise, I suggest doing the full update via the Admin menu. This has never failed for me so far. I’d still back up existing data unless you don’t mind risking losing it.

This seems to work on my emonPi, no guarantees though :blush:

for emonPiCM LPL check Go to:
setup/admin/serial monitor
next to start button, choose ttyAMA0 (port), choose 115200 (baud rate)
click Stop EmonHub. terminal response:
service-runner trigger sent for '/var/www/emoncms/Modules/admin/../../scripts/service-action.sh emonhub.service stop'
click Start (starting serial comms resets the atmega328 and it sends the start up messages). terminal response:

emonPiCM V1.1.4
OpenEnergyMonitor.org
Radio format: LowPowerLabs
LCD found i2c 0x27

and then it sends the measurement results:

OK 14 193 225 1 0 147 94 137 0 0 0 0 0 0 0 0 0 138 0 151 17 1 0 10 0 0 0 201 255 255 255 134 0 0 0 17 93 0 0 34 144 0 0 151 4 126 4 138 4 198 16 1 0 (-86)
OK 15 55 16 1 0 204 96 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 48 117 48 117 48 117 1 0 0 0 (-45)

also you can interrupt the results and send the version command (amongst others):
in ‘enter command’ box type v (version command)
click Send. terminal response:

emonPi CM V1.1.4

to finish:
click Stop. terminal response:

serialmonitor stop command sent
Serialmonitor service is not running, click start to start!

click Start EmonHub. terminal response:

service-runner trigger sent for '/var/www/emoncms/Modules/admin/../../scripts/service-action.sh emonhub.service start'

for emonPi_DS_jeelib_classic check (I don’t have this so can’t try it)
as above but choose 38400 (baud rate)
start up message (from looking at code):

emonPi V2.93
OpenEnergyMonitor.org
startup...

I’m guessing from the code that the version command v should work and give:
[emonPi.2.93]

Hope this helps (and works!)

@Robert.Wall - I don’t have data that I need to keep, so ran a full update, and I still see the same issue - is this a clearer indicatiom that the emonPi SW is the main cause of interface disagreement?

@rupert - I can repeatably start/stop the serial monitor etc., but it only works with the ‘older’ baud rate of 38400. When I start it, I see this:

service-runner trigger sent for '/var/www/emoncms/scripts/serialmonitor/start.sh 38400 /dev/ttyAMA0'
Loading configuration, list (l) command sent:

[RF12demo.13] E i5 g210 @ 433 MHz q1

Available commands:
  <nn> i     - set node ID (standard node ids are 1..30)
  <n> b      - set MHz band (4 = 433, 8 = 868, 9 = 915)
  <nnnn> o   - change frequency offset within the band (default 1600)
               96..3903 is the range supported by the RFM12B
  <nnn> g    - set network group (RFM12 only allows 212, 0 = any)
  <n> c      - set collect mode (advanced, normally 0)
  t          - broadcast max-size test packet, request ack
  ...,<nn> a - send data packet to node <nn>, request ack
  ...,<nn> s - send data packet to node <nn>, no ack
  <n> q      - set quiet mode (1 = don't report bad packets)
  <n> x      - set reporting format (0: decimal, 1: hex, 2: hex+ascii)
  123 z      - total power down, needs a reset to start up again
Remote control commands:
  <hchi>,<hclo>,<addr>,<cmd> f     - FS20 command (868 MHz)
  <addr>,<dev>,<on> k              - KAKU command (433 MHz)
Current configuration:
 E i5 g210 @ 433 MHz q1

So… is that ‘RF12demo.13’ version what I’m running on the emonPi…? And that’s older than anything you expected to see? :sweat_smile:

It looks like you might need to change your emonPi’s baud rate in emonhub.conf.

It’s here:

[interfacers]
### 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,
...

Well, according to the Docs,
https://docs.openenergymonitor.org/emonpi/firmware.html
the current firmware versions for the emonPi are:
emonPi_CM (uses 115200 baud rate on ttyAMA0 port to talk to the Pi) which is the LPL version,
and emonPi_DS_jeelib_classic (uses 38400 baud rate)

Looking in github at the emonPi firmware

the nearest candidate to what you have is in the archive folder (!) and is

RF12demo_RFM68CW_Test

which has a startup message of [RF12demo.12] from the code. I can’t obviously see anything that has your [RF12demo.13] message. It would seem that you have pretty old Jeelib firmware in your atmega328, and it’s not compatible with the LPL format that you put in the emonTx4. Out of interest, when did you get your emonPi?

I don’t know why you can’t program your atmega328 with the LPL firmware, after your full update.

The only thing I have noticed is that the RF12demo_RFM68CW_Test has an option for an atTiny84 processor instead of an atmega328, but I don’t think you have that as the startup message would likely be similar to [RF12demo.12 Tiny]

As a last effort, you could try flashing a new SD card to try in the emonPi, using
https://docs.openenergymonitor.org/emonsd/download.html
You’ll have to remove the end cover at the the button end of the Pi to change the card.
The see if you can program the atmega328 with the LPL firmware.

One last question to make sure we’re talking about the same thing - you have an emonPi (with LCD display, button, silver case, two CT and one voltage inputs) and not an emonBase (NO LCD display, button, silver case, two CT or voltage inputs)?

1 Like

As far as I know, there’s never been an emonPi with a RFM12B radio in it. But if all else fails, it’s worth checking, there are pictures in Docs to identify the different modules. An RFM12B cannot work with LPL, nor can your emonPi do CM and receive data by radio with an RFM12B or when using Classic JeeLib – not without an horrendous error rate. It needs the RFM69CW to process the radio messages itself to give the processor enough time to run CM.

@A_H
If 38400 baud in emonhub.conf doesn’t work (restart emonHub each time you change it), start at 9600 baud and try every value upwards as far as 115200. Watch the log as emonHub starts - it will immediately error if it’s not talking, or you’ll see it respond when it does.