emonPi stopped recognising CT clamps

xyleth · 2025-01-02T14:27:05.974Z

I’m having a odd issue with my emonPi / emonTx setup that I can’t get to the bottom of, nor can I find the right combination of search terms to find any hints here.

The emonPi boots and emonCMS starts and works fine. Feeds that are provided externally via MQTT are working just fine, but it has stopped recognising all of the CT clamp based feeds be they from the two directly connected clamps or the three on my emonTX.

The feeds just seem…stuck. They haven’t updated since September 28th and nothing I have done seems to bring them back to life.

I have checked all the physical connections. I’ve upgraded to the latest versions of all firmware, OS and emonCMS. It reboots fine, just always this problem with the CT Clamps.

Can any one please point me in the right direction of where this might be going wrong, or tell me what additional information I can provide to help with that determination? As you can see I’ve been working on this for a while to no avail!

rupert · 2025-01-02T15:38:48.503Z

@xyleth

Assuming that you have an emonPi1 (silver aluminium box with a LCD and a button on the top) plus an emonTx3 or emonTx4:

The measurement/radio receiver board in the emonPi1 originally used the DS (discrete sampling) method and the Jeelib radio protocol by default. In February 2023 new firmware became available for the measurement board which used the more accurate CM (continuous measurement) method, and the LPL (Low Power Labs) radio protocol. The LPL protocol has now become the default for new models. Note:

the CM method can not be used with the Jeelib radio protocol - it has to use the LPL protocol.
there was an intermediate JeelibNative radio format that could be used with CM measurements, but LPL was adopted as the default.

If the emonPi1 measurement/radio receiver board firmware was updated to CM/LPL then:

The emonPi1 would stop receiving data from emonTx3/4s that were still using the Jeelab protocol. This could be fixed by either updating the emonTx3/4s to the LPL firmware #, or reverting the emonPi1 to the emonPi1 DS/Jeelab firmware #.
2) Because the data sent from the CM/LPL EmonPi measurement board to the Pi over the serial port ttyAMA0 was now different (both in content and baud rate) #, the Pi could not understand the voltage, power and radio # etc measurements sent from the board. For CM/LPL this could be fixed by updating the emonHub configuration. For DS/Jeelib this could be fixed by reverting the emonPi1 to the emonPi1 DS/Jeelab firmware and the corresponding emonHub configuration #.

For more details, see below and posts 3 and 7 #

Should I update Emon Pi firmware to CM, and how? emonPi

I have just an emonpi, no other kit, so I don’t use radio to transfer info. I regularly update the software on the pi via the admin page on its website. I do a “full update”. I recently noticed that this doesn’t update the firmware, so after a bit of reading, I decided to update to the Continuous monitoring version, chosing port ttyAMA0, hardware emonpi, radio format RFM69 Low power labs, Firmware …continuous monitoring… V1.1.4. The update process shows on screen, then it appears to load an…

From memory, the things that changed in the CM/LPL update were

the /dev/ttyAMA0 baud rate increased from 38400 (DS/JeeLib) # to 115200 (CM/LPL), which affected the emonHub Interfacer settings #
the emonHub Node settings # for the emonPi changed as the CM/LPL format included a message number at the beginning of the data and extra pulse2count,E1,E2 measurements
the CM node name for the emonPi in emonHub was originally suggested as emonpiCM. As the original DS node name was emonpi, this meant that the CM data did not appear in the original inputs, unless the CM node name was changed back to emonpi.
there were problems with incorrect results showing oh the emonPi LCD

So you might want to check whether any software and firmware updates you’ve done are compatible and have the correct emonHub interfacer and node settings.

Don’t know if this helps! Apologies in advance for any mistakes! # edited for clarity

@TrystanLea Perhaps something on this could be included in the emonPi1 Docs?

Robert.Wall · 2025-01-02T16:32:13.575Z

Just to add you CANNOT use the LPL Library (and hence the LPL protocol) with the very early RFM12B radio modules, normally found on emonTx V2, emonTx V3.2, some early emonTx V3.4, and early emonTHs.

xyleth · 2025-01-02T16:37:17.143Z

It is an emonPi 1 and a emonTX 3, yes.

I’ve reset the firmware to DS/Jeelab but that doesn’t seem to have made a difference. And would that affect the two onboard CT clamps as well?

This is the current server information - the feedwriter seems stuck constantly with these points waiting for write.

Server Information

Services

emonhub :- Active Running
emoncms_mqtt :- Active Running
feedwriter :- Active Running - sleep 300s 185 feed points pending write
service-runner :- Active Running
emonPiLCD :- Active Running
redis-server :- Active Running
mosquitto :- Active Running
demandshaper :- Active Running
emoncms_sync :- Active Running

Emoncms

Version :- low-write 11.6.10
Git :-
- URL :- GitHub - emoncms/emoncms: Web-app for processing, logging and visualising energy, temperature and other environmental data
- Branch :- * stable
- Describe :- 11.6.10
Components :- Emoncms Core v11.6.10 | App v3.0.1 | EmonHub Config v2.1.5 | Dashboard v2.4.1 | Device v2.2.6 | Graph v2.2.4 | Network Setup v1.0.5 | WiFi v2.1.1 | Backup v2.3.4 | DemandShaper v2.2.3 | Postprocess v2.4.7 | Sync v3.2.0 | Usefulscripts v2.3.11 | Emonhub v2.7.1 | EmonPi v3.0.3 | EmonScripts v1.8.7 | RFM2Pi v1.4.2

Server

CPU :- 1 Threads(s) | 4 Core(s) | 1 Sockets(s) | Cortex-A53 | 76.80MIPS |
OS :- Linux 4.19.75-v7+
Host :- emonpi | emonpi | (10.170.1.76)
Date :- 2025-01-02 16:34:59 UTC
Uptime :- 16:34:59 up 2:56, 0 users, load average: 0.05, 0.07, 0.05

Memory

RAM :- Used: 19.59%
- Total :- 975.62 MB
- Used :- 191.17 MB
- Free :- 784.45 MB
Swap :- Used: 0.00%
- Total :- 100 MB
- Used :- 0 B
- Free :- 100 MB

Disk

**** :- - / :- Used: 53.76%
- Total :- 3.92 GB
- Used :- 2.11 GB
- Free :- 1.62 GB
- Read Load :- 1.33 KB/s
- Write Load :- 207.03 B/s
- Load Time :- 2 hours 22 mins
/boot :- Used: 20.55%
- Total :- 252.05 MB
- Used :- 51.79 MB
- Free :- 200.26 MB
- Read Load :- 0 B/s
- Write Load :- 0 B/s
- Load Time :- 2 hours 22 mins
/var/opt/emoncms :- Used: 13.90%
- Total :- 9.98 GB
- Used :- 1.39 GB
- Free :- 8.09 GB
- Read Load :- 0 B/s
- Write Load :- 46.59 B/s
- Load Time :- 2 hours 22 mins
/var/log :- Used: 2.79%
- Total :- 50 MB
- Used :- 1.39 MB
- Free :- 48.61 MB
- Read Load :- n/a
- Write Load :- n/a
- Load Time :- n/a

HTTP

Server :- Apache/2.4.38 (Raspbian) HTTP/1.1 CGI/1.1 80

MySQL

Version :- 5.5.5-10.3.17-MariaDB-0+deb10u1
Host :- 127.0.0.1 (127.0.0.1)
Date :- 2025-01-02 16:34:58 (UTC 00:00‌)
Stats :- Uptime: 11228 Threads: 15 Questions: 32659 Slow queries: 0 Opens: 49 Flush tables: 1 Open tables: 43 Queries per second avg: 2.908

Redis

Version :-
- Redis Server :- 5.0.3
- PHP Redis :- 5.0.2
Host :- localhost:6379
Size :- 514 keys (896.94K)
Uptime :- 0 days

MQTT Server

Version :- Mosquitto 1.5.7
Host :- localhost:1883 (127.0.0.1)

PHP

Version :- 7.3.9-1~deb10u1 (Zend Version 3.3.9)
Run user :- User: www-data Group: www-data video Script Owner: pi
Modules :- apache2handlercalendar Core ctype curl date dom v20031129exif fileinfo filter ftp gd gettext hash iconv json v1.7.0libxml mbstring mosquitto v0.4.0mysqli mysqlnd vmysqlnd 5.0.12-dev - 20150407 - $Id: 7cc7cc96e675f6d72e5cf0f267f48e167c2abb23 $openssl pcre PDO pdo_mysql Phar posix readline redis v5.0.2Reflection session shmop SimpleXML sockets sodium SPL standard sysvmsg sysvsem sysvshm tokenizer wddx xml xmlreader xmlwriter xsl Zend OPcache zlib

Pi

Model :- Raspberry Pi 3 Model B Rev 1.2 - 1GB (Stadium)
Serial num. :- A6BFBF88
CPU Temperature :- 36.48°C
GPU Temperature :- 36.5°C
emonpiRelease :- emonSD-17Oct19
File-system :- read-write

Robert.Wall · 2025-01-02T17:02:07.174Z

If your SDS card is 4 years old, it could be failing. It’s probably worth getting a new one, writing the ‘latest’ SD download to it and then backup the data on your present SD card and restore it to the new one. Then continue with the original problem. (You’ll need a card reader, either attached to your emonPi or to your Laptop.)

If your emonTx V3 has the RFM69CW in it (see Docs: RFM12B & RFM69CW Wireless Transceiver Modules — OpenEnergyMonitor 0.0.1 documentation) I’d suggest updating it and use the LPL version in both it and your emonPi.

xyleth:

And would that affect the two onboard CT clamps as well?

You need to set the baud rate for communication between the RPi and the ‘emon’ front end (or ensure it’s correct) in your emonhub.conf file. This affects everything coming in via Radio and the currents and voltage measured by the ‘emon’ part.
This what @rupert inferred by:

rupert:

the /dev/ttyAMA0 baud rate increased from 38400 to 115200

xyleth · 2025-01-02T18:30:21.896Z

That’s got it!

Thank you so much

rupert · 2025-01-02T18:44:46.019Z

The emonPi1 measurement board can use either the CM/LPL or DS/JeeLib versions of firmware; however each firmware version requires different Pi emonHub entries.

For clarity, here’s the two sets of emonHub entries for the CM/LPL and DS/JeeLib versions of firmware for the emonPi1 measurement board. Hope I’ve got this right! Any corrections welcome!

A) emonHub Settings for emonPi measurement board with CM/LPL firmware:

Interfacer (n.b. com_baud = 115200)

[[emonpi]]
    Type = EmonHubOEMInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 115200
    [[[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

Node

[[5]]
    nodename = emonpi
    [[[rx]]]
       names = Msg, power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulse1count,pulse2count,E1,E2
       datacodes = L, h, h, h, h, h, h, h, h, h, h, L, L, l, l
       scales = 1, 1,1,1, 0.01, 0.01,0.01,0.01,0.01,0.01,0.01, 1, 1, 1,1
       units = n,W,W,W,V,C,C,C,C,C,C,p,p,Wh,Wh

B) emonHub Settings for emonPi measurement board with Jeelib firmware:

Interfacer (n.b. com_baud = 38400)

[[emonpi]]
    Type = EmonHubOEMInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 38400
    [[[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

Node

[[5]]
    nodename = emonpi
       [[[rx]]]
        names = power1,power2,power1_plus_power2,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