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.
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?
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: EmonTxV3CM.zip (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.
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.
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.
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.
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.
