emonTx not sending CT data

haffle · 2021-03-03T11:17:48.026Z

Thanks @Robert.Wall The (OEM shop) AC & DC power bricks are plugged in, and the light in the RPi (which is powered via jumper wires from the emonTx) is showing green. The CT is plugged in to CT1, and I had restarted the emonTx after having done so. Swapping over to the CT2 output (& restarting emonHub) didn’t change things.

This is the RPIZero’s emonHub log - from this it would appear that no Input data is getting to the emonSD on the RPi.

2021-03-03 11:06:50,490 DEBUG    SerialTx   4 Timestamp : 1614769610.476852
2021-03-03 11:06:50,492 DEBUG    SerialTx   4 From Node : Serial_PiZero_barn
2021-03-03 11:06:50,493 DEBUG    SerialTx   4    Values : [19437, 0, 0, 0, 0, 0, 0, 1]
2021-03-03 11:06:50,495 DEBUG    SerialTx   4 Sent to channel(start)' : ToEmonCMS
2021-03-03 11:06:50,497 DEBUG    SerialTx   4 Sent to channel(end)' : ToEmonCMS
2021-03-03 11:06:50,653 INFO     MQTT       Publishing 'node' formatted msg
2021-03-03 11:06:50,655 DEBUG    MQTT       Publishing: emonhub/rx/Serial_PiZero_barn/values 19437,0,0,0,0,0,0,1
2021-03-03 11:06:50,665 DEBUG    MQTT       Publishing: emon/Serial_PiZero_barn {"MSG": 19437, "Vrms": 0, "P1": 0, "E1": 0, "T1": 0, "T2": 0, "T3": 0, "pulse": 1, "time": 1614769610.4768522}
2021-03-03 11:06:54,059 DEBUG    emoncmsorg Buffer size: 3

I do know that power(?) is flowing out of the inverter (as evidenced by the inverter display showing a generating value, and my emonPi also shows “negative use” (ie exporting power).

So, and sorry to being a bit thick here, but what is “in-between” the CT sensor and SerialTx Values line?

I do have a programmer, but TBH am not very au-fait with using it

Robert.Wall · 2021-03-03T11:55:10.649Z

Is the emonTx connected serially to the Pi then? You didn’t say that initially. We always assume a standard configuration using the built-in radios unless you say otherwise.

Has it ever worked?

borpin · 2021-03-03T13:22:21.324Z

Robert.Wall:

And you restarted the emonTx after plugging the c.t. in?

i.e. completely powered down, not just hitting the reset.

haffle:

AC & DC power bricks are plugged in

Switch both off.

Unplug CT. Plug it back in. Power AC first then DC.

borpin · 2021-03-03T13:23:33.733Z

Robert.Wall:

Is the emonTx connected serially to the Pi then?

haffle:

I have an emonTx / RPiZero combo in a barn

And there have been threads by Julian about this being done previously.

Robert.Wall · 2021-03-03T13:30:35.818Z

borpin:

And there have been threads by Julian about this being done previously.

If it’s a new thread, I don’t expect to have to search back to see if there is a historic thread that just might be about the same problem.

borpin:

i.e. completely powered down, not just hitting the reset.

That’s the first time I’ve heard that resetting an emonTx and powering down are not the same.

borpin · 2021-03-03T13:58:09.264Z

Robert.Wall:

That’s the first time I’ve heard that resetting an emonTx and powering down are not the same.

I’ve noticed it and mentioned it to you when I was fiddling with the serial setup ages ago. I noticed that the CT outputs were odd/unexpected. The solution was that I unplugged the TX completely, unplugged the CT and then reconnected everything to restore the expected output.

[edit]
Found the thread emonTX CT channel stopped reporting after reboot - #7 by borpin

Robert.Wall · 2021-03-03T14:13:18.643Z

The reset pushbutton (accessible through the pin-hole in the case) resets the processor, which restarts the sketch and detects the hardware again. These lines work by virtue of the fact that a c.t. socket without a plug removes the bias voltage:

  // Check connected CT sensors ------------------------------------------------------------
  if (analogRead(1) > 0) {CT1 = 1; CT_count++;} else CT1=0;               // check to see if CT is connected to CT1 input
  if (analogRead(2) > 0) {CT2 = 1; CT_count++;} else CT2=0;               // check to see if CT is connected to CT2 input
  if (analogRead(3) > 0) {CT3 = 1; CT_count++;} else CT3=0;               // check to see if CT is connected to CT3 input
  if (analogRead(4) > 0) {CT4 = 1; CT_count++;} else CT4=0;               // check to see if CT is connected to CT4 input

Those lines are in setup( ) which is run once at startup, no matter how that start is triggered.

borpin · 2021-03-03T14:15:52.160Z

All I can say is that, by observation, there has been an occasion when the EmonTX needed to be completely disconnected and re-powered to get data back on CT1.

It could also have been I plugged into a different CT and then back to CT1 (but I definitely needed to power down completely).

“when you have eliminated the impossible, whatever remains, however improbable, must be the truth?”

haffle · 2021-03-03T15:34:32.041Z

Thanks both; I powered down the emonTx / RPiZero combo (the PiZero gets its power & sends data to/from the emonTx via 5 jumper wires), removed the CT sensor, re-attached two CT sensors (surrounding different brown wires) in CT1 & CT2, plugged the AC back in, then the DC. But still nothing shows up in any Input within the emonHub on the emonTx, nor does anything come through to the emonPi in my office (an adjacent, but electrically connected) barn.

This is the emonTx / RPiZero emonHub log

2021-03-03 15:24:33,283 DEBUG    SerialTx   228 Timestamp : 1614785073.269315
2021-03-03 15:24:33,285 DEBUG    SerialTx   228 From Node : Serial_PiZero_barn
2021-03-03 15:24:33,287 DEBUG    SerialTx   228    Values : [237, 0, 0, 0, 0, 0, 0, 0, 0, 1]
2021-03-03 15:24:33,288 DEBUG    SerialTx   228 Sent to channel(start)' : ToEmonCMS
2021-03-03 15:24:33,290 DEBUG    SerialTx   228 Sent to channel(end)' : ToEmonCMS
2021-03-03 15:24:33,569 INFO     MQTT       Publishing 'node' formatted msg
2021-03-03 15:24:33,572 DEBUG    MQTT       Publishing: emonhub/rx/Serial_PiZero_barn/values 237,0,0,0,0,0,0,0,0,1
2021-03-03 15:24:33,579 DEBUG    MQTT       Publishing: emon/Serial_PiZero_barn {"MSG": 237, "Vrms": 0, "P1": 0, "P2": 0, "E1": 0, "E2": 0, "T1": 0, "T2": 0, "T3": 0, "pulse": 1, "time": 1614785073.2693155}

And this is the emonPi Inputs page

Screenshot 2021-03-03 at 15.27.312024×1100 128 KB

From these, I presume that I am right to think that no CT data is being generated at the Serial level, ie within the emonTx / RPiZero combo, so it is not the “fault” of the MQTT or other comms.

I am running three other emonTx / RPiZero combos in other places on my LAN, and they have all been working faultlessly for months. I did initially have an issue with this one in the barn, but I had thought that I had solved the (unknown) problem a couple of weeks ago. But only this week was my Inverter put back online, so I have only just realised that there was an issue.

As to why the Vrms is zero I know not …

borpin · 2021-03-03T15:45:11.529Z

Can you SSH in and then

$ miniterm --rtscts /dev/ttyAMA0 115200

Press the reset button on the EmonTX and you will get some startup messages appearing before any data. Can you capture and post here please.

Robert.Wall · 2021-03-03T16:56:54.558Z

Which sketch is your emonTx using? (That should be part of those messages.)

haffle · 2021-03-04T08:42:13.851Z

I loaded emonSD-24Jul20.img on to the RPiZero, and emonTx V3.4 EmonLibCM on to the emonTx.

jjb@MacBook-Pro ~ % ssh pi@192.168.2.54
pi@192.168.2.54's password: 
Linux emonpi 5.4.51+ #1333 Mon Aug 10 16:38:02 BST 2020 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Mar  4 08:30:17 2021 from 192.168.2.33
pi@emonpi:~ $ miniterm --rtscts /dev/ttyAMA0 115200
--- Miniterm on /dev/ttyAMA0  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
emonTx V3.4 EmonLibCM Continuous Monitoring V2.00
OpenEnergyMonitor.org
ERROR EEPROM config contains 3 invalid values
Consider restoring defaults and re-applying config.
Loaded EEPROM config
Settings:
Group 210, Node 15, Band 433 MHz

Calibration:
vCal = 0.00
assumedV = 224.00
i1Cal = 0.00
i1Lead = 0.00
i2Cal = 0.00
i2Lead = 0.00
i3Cal = 0.00
i3Lead = 3.00
i4Cal = 8.33
i4Lead = 3.00
datalog = 8.94
pulses = 1
pulse period = 100
�����enable = 0
����������������������������������enable = 0 of 1
����������������������������������������������������������������������������������������������������������������enable =  NOT��������������������������������������������������������������������������������������������������������������������������enable = 

RF whitened
RFM69CW only Node: 15 Freq: 433MHz Group: 210
 
POST.....wait 10s
'+++' then [Enter] for config mode
CT1 detected, i1Cal:0.00
CT2 detected, i2Cal:0.00
AC present 
MSG:1,Vrms:0.00,P1:0,P2:0,E1:0,E2:0,T1:0.00,T2:0.00,T3:0.00,pulse:0
MSG:2,Vrms:0.00,P1:0,P2:0,E1:0,E2:0,T1:0.00,T2:0.00,T3:0.00,pulse:0
MSG:3,Vrms:0.00,P1:0,P2:0,E1:0,E2:0,T1:0.00,T2:0.00,T3:0.00,pulse:0
MSG:4,Vrms:0.00,P1:0,P2:0,E1:0,E2:0,T1:0.00,T2:0.00,T3:0.00,pulse:0
MSG:5,Vrms:0.00,P1:0,P2:0,E1:0,E2:0,T1:0.00,T2:0.00,T3:0.00,pulse:0
MSG:6,Vrms:0.00,P1:0,P2:0,E1:0,E2:0,T1:0.00,T2:0.00,T3:0.00,pulse:0
MSG:7,Vrms:0.00,P1:0,P2:0,E1:0,E2:0,T1:0.00,T2:0.00,T3:0.00,pulse:0
MSG:8,Vrms:0.00,P1:0,P2:0,E1:0,E2:0,T1:0.00,T2:0.00,T3:0.00,pulse:0
MSG:9,Vrms:0.00,P1:0,P2:0,E1:0,E2:0,T1:0.00,T2:0.00,T3:0.00,pulse:0
MSG:10,Vrms:0.00,P1:0,P2:0,E1:0,E2:0,T1:0.00,T2:0.00,T3:0.00,pulse:0

Is the EEPROM error important here?

I don’t know what the black question mark characters mean. It looks like both CT sensors are being picked up. Does assumedV mean it is seeing that voltage, or just assuming it?

TIA

Robert.Wall · 2021-03-04T12:36:08.538Z

What is important there is your current and voltage calibration values are all zero. therefore, whatever value it’s reading has been multiplied by zero, hence zero out.

Start your emonTx again, when it invites you enter +++ for Config mode, you’ll get a menu of commands, then r to reset it to the sketch defaults, and that should give you the default calibration and hopefully, you’ll see something sensible.

borpin · 2021-03-04T13:11:02.864Z

Robert.Wall:

then r to reset it to the sketch defaults, and that should give you the default calibration and hopefully, you’ll see something sensible.

Do you need to do a save as well or does the r do the save?

[edit]
I’d also note @haffle you should not get all those bad characters either. Could just be corrupted EEPROM that a reset should fix.

To be sure, stop emonhub (sudo systemctl stop emonhub.service) and press reset again.

Might be worth checking the physical serial connections.

[edit2]

haffle:

and emonTx V3.4 EmonLibCM on to the emonTx.

Did you recompile or use the pre-built Hex?

Robert.Wall · 2021-03-04T13:56:51.306Z

borpin:

does the r do the save?

r does not save anything, because there is nothing to save. The EEPROM has been wiped. That is how the reset works. With nothing to load from EEPROM, the sketch falls back to the default values. Here is the relevant code:

struct eeprom {byte nodeID, RF_freq, networkGroup; 
      float vCal, i1Cal, i1Lead, i2Cal, i2Lead, i3Cal, i3Lead, i4Cal, i4Lead, period; 
      bool pulse_enable; int pulse_period; bool temp_enable; byte temp_sensors[48]; int rf_whitening;
      } data;

//----------------------------
        case 'r': // restore sketch defaults
          wipe_eeprom();
          softReset();
          break;

//----------------------------

static void wipe_eeprom(void)
{
  Serial.println(F("Erasing EEPROM..."));
  
  for (byte j=0; j<sizeof(data); j++)
    EEPROM[j] = 255;
    
  Serial.println(F("Done. Sketch will now restart using default config."));
  delay(200);
}

How will restarting emonHub affect the calibration in the emonTx? I don’t think emonHub sends the calibration values automatically, yet or indeed if it ever will. Is it not obvious that with zero values in the calibration, that accounts for the symptoms that Julian has seen - an incrementing message count but solid zero values in both voltage and current, when both voltage and current calibration constants are zero?

borpin · 2021-03-04T13:58:54.239Z

Robert.Wall:

How will restarting emonHub affect the calibration in the emonTx?

It doesn’t, but the bad characters might have been because both emonhub and miniterm were reading off the serial input at the same time.

I have usually found they coexist happily, but just in case, it is safer to stop emonhub.

Robert.Wall:

r does not save anything, because there is nothing to save. The EEPROM has been wiped.

Ok, that’s fine, just wanted to be sure I undertood what r was actually doing

Robert.Wall · 2021-03-04T14:24:16.889Z

borpin:

Ok, that’s fine, just wanted to be sure I undertood what r was actually doing

You could have looked at the code…

A week or two ago, Bill found a ‘wear levelling’ library for the EEPROM. I’ve incorporated that into my oemEProm library and yesterday, I sent him a copy to test. If it works, that offers protection against this sort of problem, because the sketch will check that the EEPROM data is signed - if the signature isn’t OEM’s and the one the sketch expects, the EEPROM is ignored. On top of that, it also saves the energy and pulse count values so that they can be restored at start-up - thus the emonTx (and possibly the emonPi) will behave much more like the supplier’s meter in the event of a power cut. By saving those values only every 200 Wh, the monetary value of the potentially ‘lost’ energy is minimal but the projected life of the EEPROM comes to something in excess of 50 years, which should be enough.

Of course, the idea of a signature won’t work if it’s not administered centrally and universally - or if there are “forgeries” or impostors - i.e. a sketch uses one signature but the EEPROM data format belongs to another. A degree of discipline will be needed all round.

haffle · 2021-03-05T08:40:54.172Z

Some success, in that the Vrms is now showing a value, but neither CT1 nor CT2 are reporting data.

I powered down the emonTx c/w RPiZero, unplugged the 2 CTs, plugged them back in again, connected AC, then DC, then ssh’d in and ran the minterm command, followed by the reset button & “+++” and “r”.

jjb@MacBook-Pro ~ % ssh pi@192.168.2.54
pi@192.168.2.54's password: 
Linux emonpi 5.4.51+ #1333 Mon Aug 10 16:38:02 BST 2020 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Mar  5 08:27:57 2021 from 192.168.2.33
pi@emonpi:~ $ miniterm --rtscts /dev/ttyAMA0 115200
--- Miniterm on /dev/ttyAMA0  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
MSG:4,Vrms:245.28,P1:0,P2:0,E1:0,E2:0,pulse:0
MSG:5,Vrms:245.20,P1:0,P2:0,E1:0,E2:0,pulse:0
emonTx V3.4 EmonLibCM Continuous Monitoring V2.00
OpenEnergyMonitor.org
No EEPROM config
Settings:
Group 210, Node 15, Band 433 MHz

Calibration:
vCal = 268.97
assumedV = 240.00
i1Cal = 90.90
i1Lead = 4.20
i2Cal = 90.90
i2Lead = 4.20
i3Cal = 90.90
i3Lead = 4.20
i4Cal = 16.67
i4Lead = 6.00
datalog = 9.96
pulses = 1
pulse period = 100
�����enable = 1
����������������������������������enable = 0 of 1
����������������������������������������������������������������������������������������������������������������enable =  NOT��������������������������������������������������������������������������������������������������������������������������enable = 

RF whitened
RFM69CW only Node: : 210
 
POST.....wait 10s
'+++' then [Enter] for config mode
Entering config mode...

Available commands for config during start-up:
  b<n>      - set r.f. band n = a single numeral: 4 = 433MHz, 8 = 868MHz, 9 = 915MHz (may require hardware change)
  g<nnn> p  nnn - an integer (OEM default = 210)
  i<nn>     - set node ID i= an integer (standard node ids are 1..30)
  r         - restore sketch defaults
  s         - save config to EEPROM
  v         - show firmware version
  w<x>      - turn RFM Wireless data on or            - x = 0 for OFF, x = 1 for ON, x = 2 for ON with whitening
  x         - exit and continue
  ?         - show this text again

Available commands only when running:
  k<x> <yy.y> <zz.z>
            - Calibrate an analogue input channel:
            - x = a single numeral: 0 = voltage calibration, 1 = ct1 calibration, 2 = ct2 calibration, etc
            - yy.y = a floating point number for the voltage/current calibration constant
            - zz.z = a floating point number for the phase calibration for this c.t. (z is not needed, or ignored if supplied, when x = 0)
            -  e.g. k0 256.8
            -       k1 90.9 2.00
  a<xx.x>   - xx.x = a floating point number for the assumed voltage if no a.c. is detected
  l         - list the config values
  m<x> <yy> - meter pulse counting:
               x = 0 for OFF, x = 1 for ON, <yy> = an integer for the pulse minimum period in ms. (y is not needed, or ignored when x = 0)
  p<xx.x>   - xx.x = a floating point number for the datalogging period
  s         - save config to EEPROM
  t0 <y>    - turn temperature measurement on or off:
     
  t<x> <yy> <yy> <yy> <yy> <yy> <yy> <yy> <yy>
            - change a temperature sensor's address or position:
            - x = a single numeral: the position of the sensor in the list (1-based)
            - yy = 8 hexadecimal bytes representing the sensor's address
               e.g.  28 81 43 31 07 00 00 D9
               N.B. Sensors CANNOT be added.
  ?         - show this text again
Erasing EEPROM...
Done. Sketch will now restart using default config.
emonTx V3.4 EmonLibCM Continuous Monitoring V2.00
OpenEnergyMonitor.org
No EEPROM config
Settings:
Group 210, Node 15, Band 433 MHz

Calibration:
vCal = 268.97
assumedV = 240.00
i1Cal = 90.90
i1Lead = 4.20
i2Cal = 90.90
i2Lead = 4.20
i3Cal = 90.90
i3Lead = 4.20
i4Cal = 16.67
i4Lead = 6.00
datalog = 9.96
pulses = 1
pulse period = 100
�����enable = 1
����������������������������������enable = 0 of 1
����������������������������������������������������������������������������������������������������������������enable =  NOT��������������������������������������������������������������������������������������������������������������������������enable = 

RF whitened
RFM69CW only Node: 15 Freq: 433MHz Group: 210
 
POST.....wait 10s
'+++' then [Enter] for config mode
CT1 detected, i1Cal:90.90
CT2 detected, i2Cal:90.90
AC present 
MSG:1,Vrms:245.32,P1:0,P2:0,E1:0,E2:0,pulse:0
MSG:2,Vrms:245.46,P1:0,P2:0,E1:0,E2:0,pulse:0
MSG:3,Vrms:245.59,P1:0,P2:0,E1:0,E2:0,pulse:0
MSG:4,Vrms:245.35,P1:0,P2:0,E1:0,E2:0,pulse:0
MSG:5,Vrms:245.50,P1:0,P2:0,E1:0,E2:0,pulse:0

borpin · 2021-03-05T09:24:54.475Z

I think you need to reflash the EmonTX. I’d be concerned about the serial output that is shown here as ?.

I did this successfully via the PIO method on a PiZero (I updated the docs), but you need the RTS line connected and change the pin number, else Robert’s way with a programmer and Arduino IDE.

[edit]
Also note if you use the PIO method, you need to install the library first. The docs were written with this line in the platformio.ini file

lib_deps_external =
  https://github.com/openenergymonitor/EmonLibCM.git

But @glyn.hudson changed it back to just EmonLibCM @2.4.1, but this means you need to install it manually rather than have the PIO package manager do it for you.

Robert.Wall · 2021-03-05T13:33:31.899Z

@haffle
Did it go through the startup twice or more (“POST…wait 10s” … etc) after you reset it? If it did, that must have been the watchdog firing, in which case Brian’s assumption that the sketch is corrupted is all but proven.

borpin:

I think you need to reflash the EmonTX.

I’d go along with that. But if you use platformio, I can’t help you with that - as I’ve written here so many times, it destroyed my system so I won’t touch it ever again.