Can you post the file here please - see the FAQ for the reason why…
sorry, edited the post
It looks to me as if something is being swamped by the data. I see at least one message has arrived out of sequence: 83, 84, 85, 89, 86, 87, 88, 90, 92…
Can you explain what you mean by that? Where and how?
That sets the reporting interval to 1.0 s. Why do you need the data every second? I suspect that is part of the problem, though using the Arduino IDE as the receiver on a direct serial connection, it will go somewhat faster than that. I didn’t have an ESP module when I tested V2.0 of emonLibCM, so I don’t know/have not proven the maximum rate at which the ESP can handle the data.
Have you tried adding a delay as I suggested earlier in the thread? (Post no.5) In conjunction with lengthening the reporting interval, I would expect that to at least alleviate the problem.
Just a thought, have you turned off the RFM output in the settings? It does look like the serial output is getting distrupted.
Yes, I did a change to the emonhub code to stop that happening but it looks like the ESP needs the same logic (easy enough - look for “MSG” in the string to be sent).
Is this a standard EmonTX Firmware (sorry if I missed a mention of that above). Have you modified the rate of messages?
[Edit]
I’d suggest this could well be the problem. Try reducing the rate and see what happens. I’d also suggest that as emoncms can do a max (min?) rate of 5s (IIRC), sending data once a second is pointless.
That’s only emoncms.org, and I think the limit is 10 s. Having said that, both emonCMS’s offer a minimum of 10 s for PHPFINA feeds.
But we don’t know where the data is ending up, so it’s all guesswork. On thing is certain - message numbers being out of sequence cannot be a problem inside the emonTx, so we could well be, and most probably are, looking at multiple faults.
If the serial data is being read directly (on to a specific device not the esp), how can it not be a problem with the transmission of the serial data by the TX? I’m not a serial data expert as you know 
.
From my EmonPi
I overlooked the data log value because I’ve never intentionally changed it, all my sampling rates in emoncms are 10s
To capture that serial data in my last message i connected a raspberry pi to the free uart pins and consumed the same serial data that i assume the emonesp would be receiving and processing. I just dumped that out into the code snippet i attached above and you can see how everything is connected up in one of my above photos.
Yes its all standard emontx and emonesp firmware.
I’ve not intentionally disabled the RFM output i’ll look into doing that.
Just to clarify i had flashed the emontx a few times over the course of the last few weeks with the standard continuous monitoring firmware which should have wiped out any config like the data log interval (god knows what changed it in the first place).
I’m almost certain the 1 second log intervals are what i’d been observing when this started happening naturally at random points usually during the night. A restart the following morning seemed to resolve this and was exactly what i was doing.
Just to add i have 4 emontx’s in total set up the same way and this particular board is the only one that’s ever misbehaved.
That said i’m pretty sure i damaged the emontx in question last night probing as all clamps are now reading 0’s. new board on the way hopefully arriving soon.
Did you unplug everything and plug back in (not just switch off). I had an oddity like that once. I think I plugged in just the P1 and then the others (while powered down), and it all came back.
Well that is odd!
Unfortunately, that’s not true. The EEPROM isn’t normally wiped when you reload the sketch. If the configuration and calibration data had at some point been stored in EEPROM, then the “new” sketch will read it and use it in preference to its own defaults.
The default “datalogging” interval in the sketch is 9.96 s. You should revert to that if your logging interval is 10 s. (This is so that a delayed message has a chance of not missing its slot, resulting in a NULL value being stored. Occasionally, a value that arrived just after the beginning of the slot will get overwritten by the next arriving just before the end.)
So I think at some point either you inadvertently sent a configuration command (“d1 … s” - or similar) that set the reporting interval to 1 s and saved it, or maybe if the ESP Tx output is connected, that could have sent it - possibly as part of a string of unwanted characters.
It’s worth connecting the Arduino IDE directly to the emonTx, enter the configuration & calibration mode, and do a “r” - restore sketch defaults. If the calibration constant (either voltage or current) has become set to zero, then you’ll get zero power reported.
Because there’s no storage happening inside the emonTx, and nothing in the software to allow the message count to jump about. So if the data arrived out of sequence, the only rational explanation I can come up with is some intervening data packets got delayed. I can’t see how the requisite characters could have been corrupted in transmission to come up with what’s in the log we’ve seen. That said, I don’t have any explanation if the log was a direct connection from the emonTx.
The rate for PHPFINA is not the same as the throttling rate of emoncms.org. OK, I was writing from memory, but it still doesn’t go down to 1 s, so your point about sending the data more frequently is still valid - 5 (or 10) values are written into the database and 4 (or 9) of those are immediately overwritten, only the last in any time slot is saved.
Maybe not so odd if this one’s EEPROM has different and non-standard values in it.
so spent more time than i care to admit trying to get into config mode over serial, turns our the firmware is looking for CRLF for the [Enter] portion of the key combo which i wasn’t sending from linux.
loading the sketch defaults has resurrected that emontx and i’ve disabled RF now.
will leave everything as is and check in tomorrow to see if that has solved the problem
1 Like
that seems to have done the trick, thanks for the help both
1 Like