emonTX v3 - potential radio interference from EVSE

Hardware emonTx
1

I’ve recently moved house, and gradually putting my system back in place.

I have an emonPi, and emonTx v3, the Tx doing the input monitoring and the Pi hosting emoncms only. I have noticed some really strange weirdness happening when I’m looking in the some the app graphs that never occurred in the previous house.

Now I have the solar operational, it seems to be much more pronounced - and I believe it’s down to interference from the EV Charger kit (Hypervolt, with Garo PEN-Loss detection right next to the CU & OEM kit).
image

That image is not a true reflection of what’s happening - it should be a nice graph of the consumption tracking the solar. On a night, I would see similar strangeness, the graph would hold the same value for a long time, then have zero input for another few minutes.
It only ever occurs when the car was charging - which leads me to believe I have some sort of interference going on…

I’ve just started logging the emontx rssi to a feed so I can see what’s going on, but are there any tips from the community that may have something similar?

I did briefly look at hardwiring the emontx and emonpi, but believe that’s not straight forward as the serial connection is used in the emonPi, so would need to remove bits of kit - and would like to confirm it is interference between the Tx and Pi first rather than elsewhere.

2

I wouldn’t bet on that, until proven otherwise, you should suspect all possible paths and mechanisms. It might well be r.f. interference blocking the receiver in the emonPi, it might also be mains-borne and getting in via the power supply.

You say the emonPi is hosting emonCMS only - in this case you could easily remove the “emon” hat (it’s 3 screws and unplug it), leaving just the Raspberry Pi, and make a direct wired serial connection between the emonTx and the Pi’s GPIO. You’d need a different power lead to go directly to the RPi.

You also write

so if it’s easier, put some distance between the two as a first step.

3

I think if you have a TTL converter, you can just connect via USB (as it is a different serial connection) and then just configure emonhub to read from the correct serial/USB input. Thop seems to be out of stock, but I believe this should do it

https://www.amazon.co.uk/UART-CP2102-Module-Serial-Converter/dp/B00AFRXKFU/

Have a search for emonTX(3) and USB here. Something will turn up.

4

So, I’ve not yet had time to dig out a USB serial adaptor (I have loads… somewhere in the mess of moving!) but I did a few more simple things through the week to no avail.

I’ve adjusted the CT positioning as much as I can, I’ve temporarily moved the emonTX right next to the Pi, I’ve even changed the EVSE used - same circuit - but still get this data loss issue.
Having logged the RSSI to a feed, I’ve noted there is no update during periods when the EVSE is in use (much like any other input from the emonTX)… the quicker I find the USB adaptor the better.

Today I noticed another strange data glitch, not quite on the level of when using the EVSE but only affecting some feeds. The image below shows the solar feed going awol for a minute after turning the immersion on… in real life this didn’t occur and it was continuous output. But it didn’t seem to affect the other two feeds this time.

image
image1050×191 17.5 KB

5

I don’t quite understand this - are you saying that when the EVSE is in use, there is no radio input from any source on your emonPi, but there is radio input from somewhere when the EVSE is not powered, or powered but not supplying current to the car?

Have you checked the earthing on the EVSE, and does the OEM equipment share the same earth?

If this is the case, it sounds very much as if there is conducted or radiated interference, presumably generated by the charger in the car, that is completely swamping the radio receiver inside your emonPi.

It should be possible to turn down the radio sensitivity in the Pi software, but it would need a bit of research to tell you what needed changing. And there’s no guarantee it would be a cure.

If you have a mains filter power extension lead, it would be worth trying that to power the emon kit.

1 Like
6

That’s exactly what appears to be happening. The earthing all seems in line and well within limits (TN-C-S too, so pretty low limits). It’s all a shared earth, the Garo PME unit is used to cover PEN faults (and that’s really the only difference between the two houses and why I had some suspicions around that).

The past 3 days it seems to have gotten substantially worse - possibly as a result of moving the TX next to the Pi, possibly as a sign that something is failing. Not only are the dropouts continuing when charging, but each morning an hour or so after charging has completed - the inputs stop again and they don’t recover. This isn’t just limited to the emonTX feed, but also the emonPi feed and even MQTT-only feeds - maybe this changes what the issue may be.

image
image784×130 2.42 KB

image
image779×131 2.96 KB

I’ve connected to the MQTT channel and I can see messages being published from both the TX and the Pi with expected values. That’s right now, whilst it appears emonCMS has hung up on the feed - I’ll check again when the car is on charge to see if the same is true.

MQTT Explorer showing last message no. from the TX - clearly ahead of what emonCMS reports:
image

I’m going to try work out if this is the same issue, or if there are two different issues first…

7

You could be swamping the Pi’s input by having it too close. I’ve never noticed a problem on the occasions I have both quite close (a foot or two) but I don’t think I actually had them closer.

So emonCMS isn’t even receiving the data from inside the same box? :exploding_head:

I don’t understand MQTT nor it’s relevance, so I pass on that. @TrystanLea ?

I think it must be mains-borne, whether it’s screwed up the “emon” front end or the Pi itself, I don’t know from what I know so far. There may well be multiple issues, but I think they all come from the same cause.

Is it possible to move the emonPi to new location, because am I right to think you’re not using its own inputs at the moment, and feed it from a filtered outlet?

8

On that basis it looks like the MQTT feed to emoncms is the issue. Do you have a lot of MQTT topics to be read by Emoncms? I have seen the MQTT input script get swamped if there are too many.

One way around that is to turn on the JSON format in emonhub so it sends a JSON payload on a single node for multiple sensors.

9

Now you mention it @Robert.Wall, there are two new “additions” - OVMS and my home battery (existed before, but a different data source). Both of these output an awful lot of data, and they’re feeding directly into the Pi MQTT instance, as the sole broker.

I’ve disabled the MQTT on the OVMS, and going to try dig the old console-cable driven source for the battery and see what happens tonight. If the problem goes away, I’ll add a new broker and swap things around.

10

It is unlikely to be the feed to the broker that is the issue. It is the script that reads the published topics into emoncms that will be the issue.

The fact you can read the updates from the Broker, demonstrates that.

11

Last night was the first time I’d charged the car after having moved the Pi (The TX remains next to the consumer unit) and also disabling the OVMS and house battery MQTT feeds…

…and for the first time, I’ve had a consistent input to emonCMS :slight_smile:

I’ve moved the Pi back to the consumer unit, and am hoping to put some charge into the car this afternoon to see if the same happens. If it does, I think I can assume it was the MQTT script issue.

12

Can you post your emonhub config, please?

How many topics are you posting to the emon base topic from whatever source (that are therefore converted to inputs in emoncms)?

One way to check the MQTT flow it to have 2 SSH sessions open and tail with a grep the MQTT messages in the logs, one session for emonhub log and the other for emoncms log. You should then see when a message is published to the broker by emonhub that emoncms doesn’t pick up.

You can also enable the logging on the broker and run that in a third window (to prove the broker is receiving the message and republishing it) - although, the fact your MQTT explorer can see it, proves that.

13

I’ve not knowingly made any changes to the emonhub conf:

pi@emonpi:~ $ cat /etc/emonhub/emonhub.conf
#######################################################################
#######################      emonhub.conf     #########################
#######################################################################
### emonHub configuration file, for info see documentation:
### https://github.com/openenergymonitor/emonhub/blob/emon-pi/conf/emonhub.conf
#######################################################################
#######################    emonHub  settings    #######################
#######################################################################

[hub]
### loglevel must be one of DEBUG, DEBUG, DEBUG, DEBUG, 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 en                                                                                        abled) 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 = xxxxxxxxxxxxxxxxxxxxxxxxxxx
        senddata = 1                    # Enable sending data to Emoncms.org
        sendstatus = 1                  # Enable sending WAN IP to Emoncms.org M                                                                                        yIP > https://emoncms.org/myip/list
        sendinterval= 30                # Bulk send interval to Emoncms.org in s                                                                                        econds

#######################################################################
#######################          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, tem                                                                                        p4, 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, tem                                                                                        p4, 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, tem                                                                                        p4, 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, tem                                                                                        p4, 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

[[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

I did go through and approximately count the number of inputs created in emonCMS. I knew there was a lot, but I truly was shocked just how many existed:
For the house battery, it was in the region of 500 parameters;
For OVMS, that was in the region of 300.
Both items configured to post directly to the emon base topic. (I don’t think either let me only post specific topics once enabled - it’s all or nothing).

Since I’ve stopped those two at source, I’ve had no issues of data dropouts - even after relocating the hardware back to where it was.

14

Yes, that will be your issue then. It simply overloads the receiving script.

There are a few scripts around that will republish data from one topic to another, so you can extract selectively. Otherwise, use Node-Red to read off a different topic and republish to the emon topic :slight_smile: