Hello,
I just updated the firmware on my emonth2 and it doesn’t seem to be responding although I had no error messages during the upload with an FTDI. I’m running emoncms on an RPI4.
I then did a full update and a reflash of the emonth2. The emonth2 still did not respond.
In addition, when trying to look at the “inputs,” I got the error:
Some background here. Earlier I started having problems with the emonth2 using batteries faster and faster. First ones lasted over a year, then six months, one month and lastly 12 hours.
They were all good batteries to start. I believe it was Robert who suggested at first that I reflash the firmware which I didn’t do at the time because I could live with the six-month battery replacement. When the last batch lasted 12 hours, I decided to try. Before reflashing, I removed the batteries and used the FTDI to power the empnth2 and it seemed to work correctly.
Much appreciated in advance for help and suggestions here.
Cheers,
Bob
Did you get the correct version (radio library) to match your emonCMS & receiver on your emonBase RPi4? Is it using LowPowerLabs or Classic JeeLib? Is your emonHub setting for your emonTH correct?
Robert,
First, thanks for the reply. I have been doing full updates on the RPI4 for about a year. As a non-software person, I assume the versions. My emonth has always appeared as emonth5 even though it must be a 2. I updated with LowPowerLabs after a full update of everything and a reboot. Looking at the feeds, everything is sending/receiving data except the emonth and I can no longer see the « inputs » screen without the error message. Be happy to send more info it it will help.
Don’t worry about that - it’s assuming you have Nos. 1 - 4 as well somewhere. (That’s the problem with dropping ‘V’ when you mean the version number - should be emonTH V2 and then there’s no ambiguity & confusion.)
It’s no good repeating it doesn’t work, I can’t help until you say which sketch for the emonTH(V)2 you downloaded from Github and put in the emonTH.
Robert,
The emonth board reads emonTH v2.0.2 and it’s set for 433 Mhz. I haven’t changed anything since it was purchased several years ago, until now when I reflashed. I have attached two files here. One showing my updated system and the other with the flash info. sysinfo.txt (3.8 KB) update.txt (5.2 KB)
Thanks for the continued help.
Cheers
update.txt tells me that the emonTH is (now) using the LPL library. It’s possible that it wasn’t, and you now have the emonTH talking one format and the emonBase listening for another.
Do you have anything else sending data to the emonBase RPi by radio?
sysinfo.txt fails to tell me which radio package was loaded in your emonBase, so it’s no help. @TrystanLea - Is there a major problem that prevents the r.f. Library version being included in Admin → System Info? Can it go in the next update? With 3 r.f. libraries available, there’s no obvious way to know which has been installed in the emonPi/emonBase.
If you look at your emonBase RPi and its emonCMS, go to Admin and Update. Did it say “Radio format: RFM69 LowPowerLabs” when you last updated it? Even that might not help, because I can’t see where it’s documented which radio format is the default, and whether that setting or your previous setting is respected when you do the full update.
Also, can you look in emonHub and emonhub.conf (‘Edit config’) and tell me if the entry for your emonTH5 looks like this; and if not, what is it:
I have attached a copy of emonhub.conf emonhub.conf.txt (8.0 KB)
The only other radio sending is emonTX3. I have MQTT setup for some other sensors.
The update I used was RFM69 LowPowerLabs. That was the first update I have done on the emonTH since purchased several years ago so I’m not certain which original firmware I replaced.
The emonTH has been working for years and started eating batteries about a year ago. When I removed the last batteries (lasted about 12 hours) and plugged it in using FTDI power, it was working. I did the update as it was suggested a year or so before as a solution to the battery problem. Thanks
My best guess is you got the wrong file to reflash your emonTH2. That’s because LPL format has only been standard since November 2022, about a year and a half ago.
Before then, the standard radio format was what we now call “Classic” JeeLib. It’s only an educated guess that’s what you have, and as you’ve found out, the two aren’t compatible. The obvious thing to do is connect your emonTH2 via your programmer to a USB port on your RPi4, and use emonCMS – the “Update” page in Admin – to load the “RFM69 JeeLib Classic” software into your emonTH2. I’ve never done this (I always use my laptop because I have the Arduino IDE on it) so I can’t speak from experience. It is supposed to work.
A possibly ‘better’ solution would be to leave the emonTH as it is, and change the emonTx3 and the emonBase to use the newer and more rugged LPL library. You’d do the emonTx3 the same way as I outlined for the emonTH, of course for the emonBase it’s internally connected.
Robert,
I have reflashed the emonTH2 with JeeLib Classic and it seems to have revived, using power from the RPI4. However, I haven’t tried it with batteries so I’m not yet sure if my original problem with its eating batteries has changed. I’ll let you know.
I have a question about the LPL library on my emonTX3, and since my emonPI is an essential part of my entire setup, I’m hesitant to fix something that ain’t broke. By flashing the LPL library, would I have to reconfigure anything? Is there a link for instructions on how to do this? Does my emonPI4 need to be directly connected to the emonTX3 ? Sorry for all the questions but I’m not an engineer or programmer (only a retired, 84 year old librarian). Much appreciated for all your help.
Cheers,
Bob
First, if you change your emonTx3 to LPL, you must also change the emonTH2 and the emonBase. So, as you’re not sure of what you’re doing, I’d think twice now that everything is working.
The advantage of using LPL (and this is only true for the emonTx3) is the emonBase acknowledges each message from the emonTx, and if the emonTx doesn’t get this, it tries again for a few times. The result is missing data is rare. The emonTH2 doesn’t ask for an acknowledgement because it means its receiver has to be turned on while it waits for the base to send the acknowledgement message, and so it costs in terms of battery life.
Quite possibly, because I’m not sure how Trystan has used the EEPROM, or indeed whether the calibration etc settings are saved in EEPROM in your emonTx3; and if they are, are they compatible and can the LPL sketch read them?
Yes, but only to upload the sketch (i.e, you can’t completely reprogram it with a whole new sketch over the air).
Indeed there is. It’s easy enough to find: Go to Docs → emonTx3 →Firmware → Updating firmware …
It’s exactly the same procedure as you did with your emonTH2.
If it does still, then it looks as if it will be a hardware fault, which will be impossible to diagnose remotely. Did you check the battery holder and p.c.b top and bottom for contamination and cleanliness, because at the currents we’re talking about, a bit of dampness could well explain the poor battery life.
Robert,
With the emonth running again, I tried new batteries. They lasted almost 24 hours…. The emonth seems to run well with the FTDI where it gets USB power from another source.
Before throwing it out of the window, can you or anyone suggest a fix for the battery problem? I do have a gizmo that shows the usb current pull which I can attach between the source (another PC) and the FTDI attached to the emonth. What sort of current should the emonth be normally pulling?
Thanks for all your help.
Cheers,
Bob
Robert,
My USB meter reads that the emonth is pulling a constant 0.0469 amps which I guess is 46.9 ma.
On the 59 second update interval I see no change in the current flow but it’s perhaps faster than I am able to register with this equipment.
To an untrained eye, maybe this is locked in transmit mode and not sleeping between transmissions thus causing a current drain. If this is the case then I’m not sure there is anything to do about it other than getting a new one, which is too expensive with international post.
Anyway, unless you have a solution please don’t waste any more time on this. I appreciate your time already spent.
I don’t know how relevant this is … and I don’t have an emonTH2 either …
If you are using an USB to FTDI module to connect to the emonTH2, to power and program the emonTH2, then -
the USB to serial chip on the USB to FTDI module will also be powered by USB. It will be taking current from the USB, as well as the emonTH2.
Typical current consumption for some popular USB to serial chips:
CH340 15mA
CP2102 20mA
FT231X 8mA
You may want to measure the current taken by the USB to FTDI module on its own (disconnected from the emonTH2) and then subtract it from the current taken by the USB to FTDI module plus the emonTH2 to get a more accurate figure.
If the emonTH2 was operating correctly with a very low current consumption, then the current drawn by the USB to FTDI module could mask the emonTH2 current. Judging by the reported 24
hour battery life though, this doesn’t seem likely.
This doesn’t alter your problem though … it just may allow more accurate results
To summarise:
On current = 2.5mA (average)
On time = 226ms
Off current = 0.06mA
Off time = 59774.5 ms
So the average current, working in seconds and uA is
[(2500 x 0.226) + (60 x 59.774)] / 60 = approx 69.2uA, say 70uA
Have I gone wrong somewhere?
Very Rough Estimate of what the battery life should be -
The emonTH2 uses a LTC3525 switching regulator with about 80% efficiency (at 70uA) to transfer power from the batteries (Pbatt) to the emonTH2 circuitry (Pth), so Pth = 0.8 x Pbatt
From above we have Pth = 70uA x 3.3V = ~ 231uW,
so Pbatt = 231uW / 0.8 = 289uW
From the battery specs
we have the capacity of an alkaline AA (discharged to 0.8V) at 5mA current drain (the lowest in the data) of
5mA x 650hours = 3250mAh
The stored energy is 1.2V (average) x 3.25Ah = 3.9Wh, and we have two batteries, so the total is 7.8Wh.
The battery life will be 7.8Wh / 289uW = 26,990h = 1125 days = approx 3,1 years.
This assumes both batteries have been discharged to 0.8V, i.e. 1.6V total. However the LTC3525
will continue working until its input voltage is 0.85V typical (i.e. 0.425V per battery), so it will squeeze a bit more life out of the batteries!
Sorry, I should have thought of the FTDI chip (FT232RL) as an additional load. It seems to require .0084 amps thus leaving a drain of .0385 amps from the emonth2. Is this reasonable or too high ?
I am attaching a graph of the last set of new batteries used which lasted about a day. It shows a strong voltage of 3.2 volts and then suddenly drops off. It looks as if some component is failing after this short period.
The sensor has never been outside and shows nothing I can see on the circuit board that could be causing the problem. As I mentioned in an earlier post, it functioned well for several years on its first set of batteries and then started using them more often over the past year. Now down to about a day before the new batteries are dead.
Not sure where to go from here. It’s probably not worth the time and trouble on this but I’m still curious as to what is going on… Continued thanks.
Cheers,
Bob
It is far too high. The average current without the USB chip should be about 70 µA (0.00007 A) and your USB device might not be able to measure the difference between 8.4 and 8.47 mA.
Therefore
should read, IF the emonTh was working correctly
“thus leaving a drain of 0.00007 A.”
and that’s the average over time. As the Docs article points out: “After [the] sensor sample is complete the ATmega328 goes back to full watchdog sleep … consuming 0.06mA.” (0.00006 A as you put it.)
It’s almost impossible to know exactly what has failed, but I’m fairly certain that something in the hardware has, as you’ve completely uploaded the sketch.
