Erratic voltage measurements on 3-phase installation

Hardware
,
1

Hello! I have installed an emontx4 (3ph), emonVs (3ph) and emonBase in an office space location to try measure their energy usage. This is in Austria, with 3-Phase.

However on all 3 phases the voltage appears to be erratically jumping between the expected ~230V and -123V.

The jumps appear to be happen at the same time across all 3 phases, and when I measure the voltage with a handheld meter, the voltage is not changing and becoming negative in reality! Of course this also impacts the power readings we are measuring making it unusable.

We have installed the same setup in 2 other locations, and the voltage readings of the other 2 installations appear stable and accurate.

I have attached a picture of the last week of measurements to show what is happening.

Any ideas what this could be or what else I could try?

Thanks for any help or support!

EmonCMS Voltage error
EmonCMS Voltage error2307×1474 327 KB

2

Welcome, Kyle, to the OEM forum.

The voltage is clearly being corrupted somewhere, because it is very, very difficult to obtain a negative value for a rms average voltage. The question is where is this happening?

Firstly, you write that the problem also affects the power readings, meaning it is happening inside the emonTx. Which sketch are you using in your emonTx4?

At this time, I can think of only one possible cause: The voltage calibration constant is being changed from 100.0 to -53.5 - in the emonTx4 and for all 3 voltage channels. Are you or the emonBase accidentally sending recalibration commands to the emonTx4?

3

Hello @Robert.Wall I think these should be the standard 3 phase 6 CT firmware that I compiled from your library https://github.com/openenergymonitor/emontx4/tree/main/firmware/EmonTxV4_DB_3phase_6CT, correct me if Im wrong @Kyle. Let me know if I can help and feel free to message us at the shop. I think you ordered 2x emonTx4 3-phase units with an emonBase each and 1x emonTx4 unit by itself? Do you have two emonTx4 units transmitting to one emonBase? or via serial as Robert is wondering? It might be worth connecting the emonTx4 up via serial and clearing and the re-setting all of the CT calibrations?

4

Good morning Robert and Trystan, thank you both for your speedy replies :slight_smile:

Shall I continue to message here? or rather the shop? I’m happy to do either.

To answer you questions, yes, these are the units that were purchased from the OEM shop.
As @TrystanLea correctly guessed, this particular office setup has 2 systems (emontx4, emonVS and emonBase) setup. I was hoping to get away with using just the one emonBase, but the two fuseboxes on site weren’t near enough to each other to connect to the same emonBase.
Note: the other emonBase was purchased in another order :slight_smile:

I have connected directly to the emontx4 via serial and changed the CT calibration settings to different Amp values since we had to use different size CTs to the default setting (50/50/50/200 on unit 1, 100/100/100/200/100/100 on unit 2). The first 3 numbers are for the 3 phases. The larger 200A CTs are required mainly due to the physical size of multiple cables measured (at the cost of accuracy I assume).
I left the other values in the serial config alone (e.g. voltage calibration, phase correction) since I wasn’t quite sure what to do with them.

@Robert.Wall my setup could well be accidentally sending recalibration commands, just not intentionally! Is this something I can see by trying to go back through the logs? Or do you have any other recommended way to confirm this?

Also both emonBase’s are connected to the same WIFI network (but have been given different node names in the config). Could this also cause some interference?
As a second problem I need to tackle, they seem to send the same data to emonCMS.org. But I was going to post this later if I couldn’t solve it myself once the Voltage swings were in order.

I will be able to revisit the installation site on Mon 28.8 to try reconnect via serial and reset the CT values.
Please feel free to share any new insights with this extra info.

Cheers!

5

If you want me to see the exchanges, yes, otherwise do as you wish.

It might well appear in the logs - I don’t know because I’ve never needed to look! If it does reach the log, you should see something like this
Cal: k0 -0.53 0

But note - if it is sending recalibration commands, it’s either sending the correct calibration again whereupon the correct voltage is reported, or (possibly more realistically) it’s not saving the “new” calibration to EEPROM and then there’s some mechanism causing it to restart and restore the correct calibration from EEPROM.

If one or more voltage amplitude values are wrong, then a very small calibration adjustment can be made (deliberately :wink:) - but if you change it to -0.53 and then save the settings, you will have permanent wrong negative voltages and powers. If you do not save the settings, they remain in effect only until the next restart.

What I was having difficulty understanding was
a. all three voltages were affected at (or very nearly at) the same instant,
b. all three voltages are affected by the same amount (or very nearly).

even though each channel requires a separate command - but when I look at the sketch, it appears @TrystanLea has not separated out the three voltage calibrations and all three use the same value!

c. all three voltages return to the correct value at (or very nearly at) the same instant, though this can be explained by a reset/restart of the sketch.
d. despite the above, there does not seem to be a pattern for when it happens.

Looking at what needs to be sent
++[cr][lf] or +++[cr][lf]
k 0 -0.53[cr][lf] or k 0 -0.53 01234 [cr][lf]       {the 01234 etc is ignored }

then later

r[cr][lf]

might be enough to cause a restart and restore the correct calibration, or it might need

++[cr][lf] *or* +++[cr][lf]
r[cr][lf]

to cause the restart.

+++ (the ‘password’) can easily appear as a separator or heading of a message intended for humans to read, so in hindsight it’s a particularly bad choice (not as bad as ***) - we had a similar problem with the serial interface and the Huzzah ESP8266 Wi-Fi module sending “chatter” intended for humans which was interpreted by the emonTx V3.

6

Hi Robert! Thank you for the very detailed answer. I must admit a decent amount of it goes over my head and I will have to work through this slowly step-by-step.

Especially the commands at point d., I am at quite a loss when considering what to do with these commands (sorry!), I assuming they need to be passed directly to the unit to trigger a “factory” reset of the unit?

An interesting development is something quite simple that appears to have helped solve the issue. I was on site on Monday 28 Aug and disconnected power to the 2nd setup at 4pm, i.e. to both the emontx4 and emonbase (that was on the same wifi network but measuring a different cabinet on premise), and since then the voltage of the 1st system seems stable (see screenshot).

I am not sure how this was happening, but the temporary solution I am looking at is getting a portable 4G WLAN dongle and leaving this on site to connect the 2nd setup to for sending the data to emonCMS.org. I believe this should work since for ~15 mins the 2nd unit was connected via a smartphone hotspot, and the voltages from the first unit seemed stable. This is not 100% guarantee since as there were several periods for longer than 15 mins previously where the voltage was also stable.

Of course long term, we would ideally leave both units on the same WIFI network and have them working in a stable manner, so still keen to reach the root cause of this issue.
Does this trigger any new thoughts or a different direction I should troubleshoot in?

Cheers!

EmonCMS Voltage error_improvement
EmonCMS Voltage error_improvement1806×1081 203 KB

7

No - you misunderstand. I think these might be the commands that are erroneously being sent to your emonTx4 to first cause - and then remove - the problem. r resets to the defaults in the sketch - so effectively a factory reset, and it all comes good with the calibration as set in the sketch. However, if you changed the calibration and saved it to EEPROM, then if this is still correct, it’s not receiving a r reset but something else is restarting the emonTx4 - maybe a power glitch.

Is “second” the other one that’s not showing the problem?

What is the complete data path from each emonTx to each emonBase? I know you did this

but have you done this for all, and have you disabled the radio in every emonTx?
What I’m trying to get to here is, assuming the problem is the configuration/calibration is being spoiled (and it’s not proven yet, it’s only my best guess), where is it coming from and how?

This is by design. You can turn it off in the emonhub.conf files in your emonbases.

    [[emoncmsorg]]
        Type = EmonHubEmoncmsHTTPInterfacer
        [[[init_settings]]]
        [[[runtimesettings]]]
            pubchannels = ToRFM12,
            subchannels = ToEmonCMS,
            url = https://emoncms.org
            apikey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
            senddata = 0    # Enable sending data to Emoncms.org
            sendnames = 1    # Send full input names (compression will be automatically enabled)
            interval = 30    # Bulk send interval to Emoncms.org in seconds

Take the emoncms.org APIkey out, and set senddata = 0 should kill it.
Or you could put the APIkey of the other emonbase’s emonCMS in there and both/all emonbases would get all the data, assuming they are open to your LAN.

8

Or just comment out the whole interfacer :slight_smile: