EmonTX E1 value is 4294967231.00 kWh

Hi, have had Emoncms setup for about a week now. All working fine until we had a power cut this morning. I capture the incoming house supply using an EmonTX rather than a EmonPi because the solar inverters is at the other end of the garden.

Once everything was back online the EmonTX was sending 4294967231.00 for its input E1. Now I’m assuming that’s because we are currently exporting from the solar, however I would have expected a negative which I could have filtered.

I thought it was better to use E1 for kWh rather than convert P1 to kWh as it took care of missing data due to dropped RF, but I cant see how its suppose to work.

Any suggestions what I should do?

I don’t have the answer, but couldn’t help noticing that 42949672371 looked mighty familiar.
Turns out that 2^32 is 4294967296. Signed / unsigned / two’s complement issue?


Im guessing E1 doesn’t allow a negative number, so it defaults to the maximum and counts down?

I’m afraid it’s a fault in the sketch. The library correctly returns a signed value, but for some inexplicable reason, it’s assigned to an unsigned.

You need to edit the sketch so that the relevant variables in the data structure being passed through to the radio are signed, and change the entry in emonhub.conf likewise.

I’ve answered this with full details not long ago, I’ll try to find it.

Here, I’ve corrected it for you: (12.5 KB)
It’s an unofficial V1.8 Note the changed definition for the Node 15 in emonhub.conf in the comment at the top.

@TrystanLea This is a long-standing problem that needs correcting - emonhub.conf too.

@Bill.Thomson I guess this needs to be in the FAQ - at least until it’s corrected.

1 Like


I’ve applied your change here @Robert.Wall

For emonhub, I can make a change to the default config but it wont automatically correct existing systems. Im working on a new image and that will make it available. I guess we need a way of updating emonhub.conf if the user has made no changes, In theory that should not be too complicated but Im also weary of adding further complication.

Instead of a new image, why not work out how to do that with an rsync update.
Sure would save a lot of time and bandwidth. Food for thought.

1 Like

The new image is for the long overdue upgrade of the underlying OS and to reduce the time that users need to spend downloading the first update if they download the Oct19 image.

This change is just a small addition.

I’ve uploaded a tagged release EmonTx3CM v1.8.0 including pre-compiled binary:

Testing here the emonPi/base upload method uploads this latest version fine.

Hi All,

Thanks for shedding light on the problem.

Would I needs to purchase a USB to UART adapter to do the update, or is the a way to do this over the air?

Hello @mancavePVun yes Im afraid this does need a USB to UART adapter.

@Robert.Wall I’ve updated the default emonhub.conf in the emonhub repository
Note that this won’t apply to existing systems.

Just gave it a shot. Worked OK here too. thumbsup

1 Like

A caveat with the new upload method…

Ensure the user makes the correct comm port selection selection.
I almost made that mistake until I realized I was about to overwrite the 328 chip data in my emonPi.
They need to choose ttyUSB0 not ttyAMA0 from the dropdown list.

1 Like

Unless you have a spare RPi, in which case you can do it via the GPIO Pins.

The version I posted here was only intended for Ben’s use, so I didn’t record the alteration. So unfortunately, the change history needs to be updated in the source file.