emonPi stopped recognising CT clamps

@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:

  1. the CM method can not be used with the Jeelib radio protocol - it has to use the LPL protocol.
  2. 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:

  1. 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 #

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

  1. the /dev/ttyAMA0 baud rate increased from 38400 (DS/JeeLib) # to 115200 (CM/LPL), which affected the emonHub Interfacer settings #
  2. 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
  3. 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.
  4. 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?