EmonTx3CM Datalogging period changes and floods EmonESP

I am running EmonTX V3.4.2 board running EmonTx3CM V2.3 (EmonLibCM V2.2.1) connected to a Wemos D1 Mini running EmonESP V3.1.4. I have compiled both codebases with both Arduino and VSCode/PlatformIO IDEs. I find that between 5sec and 3mins the message frequency changes from 9.96s to about 0.5s flooding the EmonESP and the Home Assistant MQTT monitoring and display entity. The behaviour is the same if it’s plugged into all 4 CTs in my system or only plugged into 9V AC adapter and the FDDI serial interface on 6 pin header UART connection to a PC running Putty on my desk. Pulse and Temperature enables are “false” and “rf_whitening = 0;”. On investigation I found that the Datalogging period value changes from 9.96 to 2.00 however the LED blink rate is faster than 2s. I have fixed this for the time being by re-writing Datalogging period in the main loop "float period = 9.96; EmonLibCM_datalog_period(period); before the serial transmission block. Have you see this before and is there a solution? Will my fix unduly wear EEPROM and can you suggest a better solution? Many Thanks

I have only ever compiled with the Arduino IDE (on Ubuntu Linux), if you have used platformio, all I can say is I have less than zero confidence in it.

I had emonLibCM running and logging continuously via the radio, not using the emonESP, for several months before release and never detected a timing problem such as that, nor has it been reported on the forum here.

Also, on the rare occasions that I have connected an ESP8266, I’ve never seen a problem. I’ve no idea how many active installations there are of the CM sketch and library, it’s been the default software since May 2020 and ther changes since then have been minor, so I suspect it could be well on the way to 4 figures. If it was a systemic problem, I would have expected it to have been seen long ago.

Do you have an inbound data connection on the emonTx’s serial port (labelled “Tx” )? If you have, I strongly recommend disconnecting it. A well-known fault (with the ESP8266) is it sends random unwanted characters to the emonTx which are interpreted as calibration instructions.

My understanding is the variable is held in RAM, so your EEPROM is unaffected.

Thanks for the prompt reply, The EmonESP TX link is present as I liked the idea of viewing and updating values remotely, the “+++” command works well through EmonESP web interface. I read about the random characters so I will scope the line and either remove or filter the line as you suggest.
With respect to development environments, what’s your preferred set-up?

The “correct” solution would be to rewrite the ESP software so that it only sends data that you instruct it to send. Once the emonTx has seen “+++” or “++s”, calibration is turned on. Then, “d[a number]” will set the datalogging to that value, but d[nothing] will set it to zero. What happens then is data will be sent as soon as the serial interface has sent the last lot (plus 1 mains cycle), subject to the library minimum. If the sketch and the ESP can handle it, the library works down to 0.1 s.

I don’t know what the ESP sends - I’ve never got round to finding out. It may well be there’s a better choice than “+++”, which would allow you access but not the ESP of its own volition.

Notepad++ and the Arduino IDE.

I need to rename all the source files (because for an unknown reason, almost every one is “src.ino” - and when I have a dozen or more open tabs, each called “src.ino”, it gets confusing).

I’ll spend a few days on the “correct” solution, as mentioned it also happens when emonTX is connected via FDDI cable to a PC and no EmonESP connected.

VSCode with PIO extension enforces a "/src/… and /lib/… structure and Arduino enforces // structure which is why I thought you were a PIO user.

Thanks for the insights.

If platformio or anything else sends to the appropriate (USB in this case) port characters that make sense to the emonTx, it will get interpreted and acted upon.

Having said that, I normally work via the FTDI programmer and, unless I’ve typed ‘p’ on its own (equivalent to “p0”), I’ve never seen anything like the behaviour you see. I can’t help thinking it might be something some other installed application is sending to the port, either via the programmer or via WiFi and the ESP - though that does seem unlikely. I can’t think of hardware failure that might do what you’re seeing.

Just confirm please, in “flood” mode, if you query the emonTx settings, the datalogging interval is reported as what?

If you search for my posts that mention platformio, sooner or later you’ll read what happened when I installed it, and as a consequence my opinion of it. There’s absolutely no possibility of me ever installing it again after that.

I’ll scope it out and log all serial data. When it happens the value of datalog = 2.00 but the led flashes at a rate faster than 2s and the serial messages are faster than 2s. Cheers

I set an emonTx with a “Shop” (i.e. as supplied by Megni) ESP8266 running 12 hours ago - it sent 4452 messages (according to the emonTx’s counter) in 44340 seconds. That’s an average of one every 9.9596 seconds, which is pretty close. Recorded as PHPTIMESERIES data, it shows a missing message every 220 roughly, which is exactly as it’s designed to do, thus avoiding a null data point should delivery or processing delay the data’s receipt in emonCMS.

At this point, I’m about as sure as I can be that it’s not a fault in the emonTx sketch or the library.

Having again checked the behaviour of the library, I can’t explain how the datalogging period is reported as “2.00” while the LED flashes are faster. Using the FTDI programmer, if I issue the command “p”, or “p0.05” (a value less than 0.1) it reports the number I set but runs at 0.1 s interval. For values greater than 0.1, it runs at and reports the true value.

12:59:30.124 -> logging period: 0.05 s
12:59:30.157 -> MSG:487,Vrms:233.79,T1:0.00,T2:0.00,T3:0.00,pulse:0
12:59:30.257 -> MSG:488,Vrms:234.02,T1:0.00,T2:0.00,T3:0.00,pulse:0
12:59:30.356 -> MSG:489,Vrms:233.93,T1:0.00,T2:0.00,T3:0.00,pulse:0
12:59:30.423 -> MSG:490,Vrms:233.69,T1:0.00,T2:0.00,T3:0.00,pulse:0
12:59:30.522 -> MSG:491,Vrms:233.56,T1:0.00,T2:0.00,T3:0.00,pulse:0
12:59:30.622 -> MSG:492,Vrms:234.74,T1:0.00,T2:0.00,T3:0.00,pulse:0
12:59:30.721 -> MSG:493,Vrms:233.51,T1:0.00,T2:0.00,T3:0.00,pulse:0
12:59:30.821 -> MSG:494,Vrms:234.87,T1:0.00,T2:0.00,T3:0.00,pulse:0
12:59:30.920 -> MSG:495,Vrms:233.50,T1:0.00,T2:0.00,T3:0.00,pulse:0


12:59:35.367 -> Settings:
12:59:35.367 -> Group 210, Node 15, Band 433 MHz
12:59:35.367 -> 
12:59:35.367 -> Calibration:
12:59:35.367 -> vCal = 268.97
12:59:35.367 -> assumedV = 0.00
12:59:35.367 -> i1Cal = 90.90
12:59:35.367 -> i1Lead = 4.20
12:59:35.367 -> i2Cal = 90.90
12:59:35.367 -> i2Lead = 4.20
12:59:35.367 -> i3Cal = 90.90
12:59:35.367 -> i3Lead = 4.20
12:59:35.367 -> i4Cal = 16.67
12:59:35.367 -> i4Lead = 6.00
12:59:35.367 -> datalog = 0.05
12:59:35.367 -> pulses = 1
12:59:35.367 -> pulse period = 0
12:59:35.367 -> temp_enable = 0
12:59:35.367 -> RF off
12:59:35.367 -> Temperature Sensors found = 0 of 3
12:59:35.367 -> Temperature measurement is NOT enabled.
12:59:35.367 ->