emonTX using ESP8266 Huzzah WIFI - Strange numbers

Hi all,

Getting some strange data from my emonTX using WIFI mod/card and I am not sure quite what do to.

Below is a screen shot of the inputs:

There is two CT’s and they are connected into the CT1 and CT2 ports.

I had read this:

Which seemed to suggest that numbers like these can be dealt with to get result by using - 2^3 or - 2^31, but I have been unable to get anything meaningful into the feeds.

Any pointers?


Hello @boydo the energy inputs E1 and E2 are unsigned long variables and so will wrap around to a very large number as you are seeing if the power values are negative. Do your power inputs go negative for extended periods of time?

Thanks again Trystan, not expecting negative values. The CT’s on mains feed for getting import export and the other is on the solar inverter to get solar gen. In case we had the Ct’s around the wrong way I asked that they be turned around.

There is definitely load on the mains feed and even with the overcast day we have here in NI he should be producing something.

Below is what I have now.

If I had got the WIFI modal on the wrong way around would that stop the CT numbers coming through?
The temp reading looks like what I would expect.

emonLibCM produces SIGNED values for energy, and it’s spelled out in the documentation, because negative values are entirely possible if you are someone who is a nett exporter of energy.

Is the firmware going to be CM or DS?

@boydo, How long have you had the emonTX? Have you updated the firmware? Has it just started?

@TrystanLea, could this be related to the emonhub issues this user had?

You right @Robert.Wall on the mains we could expect a negative value at times.

Thanks @borpin I just got it about 2 weeks ago. Unfortunately I don’t have the device as its in a remote location, might have to get it back to the office to get a closer look. it dose not seem related to the emonhab issue as I am viewing the data from emonCMS exported form the emonTX and we are getting data e.g. Temp, mem etc…

That’s fine, just tells us which Firmware for sure.

Can you post a portion of the emonhub log please.

Thanks @borpin will see if I can get remote access, if not we will have to wait until I can get it back to the office. Thanks again.

1 Like

The problem originates in Line 73 of the sketch:

typedef struct {
    unsigned long Msg;
    int Vrms,P1,P2,P3,P4; 
    unsigned long E1,E2,E3,E4; 
    int T1,T2,T3;
    unsigned long pulse;
} PayloadTX;

E1, E2, E3 & E4 should be defined as signed values. What’s happening is further down at line 268, the signed value gets inserted into the unsigned variable:

    emontx.E1 = EmonLibCM_getWattHour(0); 

And then emonhub.conf perpetuates the error.
Your quick fix will be to change your emonhub.conf according to the post you linked to.

That should show an energy of -128 for E1, and -150 for E2.

If editing emonHub doesn’t work, (and it might not, depending on how the data is handled on its way into emonCMS) then try in emonCMS.

I’m not an expert on emonCMS, but there is some conditional processing available.
What I think you need is

If >, skip next [Value: 2147483647]
log to feed [whichever it is]
+ [Value: 4294967294]
log to feed [whichever it is - the same one]

I don’t know what that will do about the display problem - is that coming from the ESP?

The other point I noted - why is your voltage showing only 0.43 V? That probably explains
the very low and negative energy - the voltage is pickup and the phase of the current relative to it is all wrong.

@Robert.Wall - which sketch?

Trystan’s EmonTxV3CM one - which is the one we are reasonably certain is installed on Richard’s emonTx.

I first pointed the problem out about 3 months ago.

1 Like

So is signed long the right construct?

Look at the documentation for the library. That tells you what data type is returned by the “get” API call.

You can download the documentation - it’s included in the .zip file - here:

You don’t need, but can have “signed”. See Kernighan & Ritchie, 2nd Ed, Appendix A8.2, page 211.

It would have been quicker and easier all round if you has just said what it needed to be. And there was me trying to be helpful.

Yes, but now you have the complete information about the library. There’s no point in me spending roughly the same amount of time documenting it as debugging it, if I’ve got to answer questions that are clearly covered there.

1 Like

Fine I won’t bother with the PR then.

Your PR & support is appreciated. Below is a screen shot of another emonTX which I ordered at the same time but would appear to have the same issue. I setup it up this morning beside another emonTX which is working 100% on Version:[v2.3.0] but the newer ones seem to have the same issue as reported above.

You can see the version 3 and also the log of the entries being - values etc…
Not sure if this is what you meant by emonhub log, if not let me know how to get it.


Thanks @Robert.Wall, just seen your post, the odd voltage reading gave me an idea as I had got the power adaptor separately for these two emonTx’s. Tto check I have swapped the power supply with the other working emonTX and the problem continues.

I am using as my CMS and I guess I can’t edit the emonhub.conf on there? Unless there is an emonhub.conf per user?


What sort of “power adapter” is it? Is it the “Ideal” from the shop or another? What does the label on it say? You are aware that when you have the ESP8266, you need both a 5 V d.c. power supply and a 9 V a.c. adapter to measure the mains voltage?

OK, that wasn’t clear. There isn’t an emonHub on there, so no emonhub.conf. You don’t have the conditional jumps there that make it easy either. I think your best solution will be to get (if you don’t have one) a programmer and edit the faulty sketch in your emonTx.

It might just be possible to do something in with adding and subtracting and the “allow” conditions, but you’d need to be quite inventive. The algorithm is simple - implementing it with what’s available looks quite tricky.

I think it’s not possible to restore the correct operation within It’s unhelpfully (in this case :wink:) got a “signed to unsigned” conversion, but not the other way round, and it hasn’t got a “jump” that I think is necessary to implement the algorithm.

So it’s got to be a programmer, I’m afraid.