emonTX using ESP8266 Huzzah WIFI - Strange numbers

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 emonCMS.org 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 emoncms.org 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 emoncms.org. 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.

Ah, that changes things quite a lot!

I’ve revisited the sums I did when deciding whether it was practical that emonLibCM_getWattHour(…) should return a signed value:

The average UK home uses about 3.7 MWh per annum, so at that rate, the signed long integer will overflow after 580 years.

The maximum value for a USA consumer appears to be about 16 MWh but even so, that is good for 134 years.

If an emonTx/emonPi were to remain in service for 50 years, it would need an average consumption of 43 MWh per annum to overflow a signed long integer. (In the UK, that would cost around £8,000 per annum.)

I didn’t think the use of an unsigned value was justified on the grounds of it being necessary to have the capacity to store the value of twice those numbers.

hi Robert, haa that was it… (embarrassed red face). I have been running another older emonTX without the additional power supply without issue for about 6 months now and I unfortunately made the assumption that new ones would work the same, apologies.

I added the additional adaptor to the test and rebooted and I got the readings I was expecting.

Thanks again all for your help and I will try and be less stupid next time!

1 Like

That doesn’t make sense. It’s the emonTx V2 that on its own required both a 5 V d.c. adapter to power it and a 9 V a.c. adapter to measure the voltage.
The emonTx V3 can work with only an a.c. adapter because it was designed that way and the current demand is small, so it doesn’t unduly spoil the waveform that it’s measuring. Adding the ESP8266 increases the current demand by many times and the emonTx should simply not work when the ESP8266 is added, unless you also add the 5 V d.c adapter to supply the extra power that’s needed.

Understand but it dose seem to work on this older one. With the WIFI card attached is happily sending what I assume is correct data with only the one power supply. Just to double check I did connect up the v9 adaptor and power cycle it to see if there was any dramatic change in the ct reading and I could not see one. very strange.

So you were running on only a 5 V d.c adapter?

If you’re running off only a 5 V. d.c. adapter and you’re using the old discrete sample sketch, it will have assumed a nominal 230 V and it’s giving you its best guess at the apparent power on that basis. Give it a 9 V a.c. adapter and it can calculate real power, which is what you pay for. So when you added the 9 V a.c. adapter that feeds the voltage input, it was able to calculate the accurate real power. I would have expected you to have seen some change.

The “latest” sketch pre-loaded by the shop uses the continuous monitoring library, EmonLibCM. That can work with or without the 9 V a.c., and it knows the difference, but it appears that the “latest” default sketch must have the a.c. adapter for it to calculate the real power, it doesn’t use the guessed nominal voltage to show approximate apparent power instead.

Yes that’s correct. All makes sense now, thanks for persevering with me! Do you think its a viable option if I want to deploy these for customers with only the one 5v adaptor that I flash it down to the older version?

I take you mean with the ESP8266 module sending to emoncms.org?

It’s viable, but in my opinion (and I’m biased), the best answer would be to write or customise a sketch that uses emonLibCM to calculate apparent power when the a.c. adapter is unavailable. OK, you won’t receive the full benefit of the better accuracy that emonLibCM offers with the a.c. adapter, but at least you’ll catch all the peaks that the old Discrete Sample sketch misses.

If you never use the ISM band radio, you could also simplify things and leave that out.