I have an emonth5 that had been running at least a year or more on its battery supply. I have replaced the batteries twice this year and now they have run down again. I’m sure the replacement batteries were fresh. I notice that the unit sends data every 2 minutes to the RPI running emoncms.
Since the emonth5 has been functioning several years, I haven’t paid much attention to it. Is there a way to slow down the transmissions? Any idea why it has suddenly started using up batteries so quickly? I’m not sure how to trouble shoot this problem.
Thanks in advance.
Can anyone comment on this? Thanks
emonTH5? Don’t you mean emonTH2 hardware?
Sorry, I have no idea why it should be using batteries - unless there’s contamination inside that’s leaking current. Is it indoors or out? Are there or has there been squatters of the multi-legged variety inside? What is it measuring - internal sensors only, or external temperature, or pulses? Which radio format are you using?
The reporting interval can be changed - it means editing the sketch and uploading the changed version - but as far as I know, the default interval is around 55 s, so it sounds as if you have a special sketch in any case.
Thanks, Robert. I guess it’s an emonth2 but it shows emonth5 as node. Nothing external connected, only the internal sensor. It’s indoors and never has never been outside or in a harsh environment. Data is sent to an emonTX. Everything is standard as for the US. I haven’t modified the firmware or software. Been working fine for several years with batteries lasting 1-2 years. It is 1 minute data.
Not sure there is a solution…
That’s all the obvious physical might-be’s ruled out. This leaves the battery maker or the shop conned you, or a wayward neutrino has done naughty things to the software. Two or is it three sets of iffy batteries unless all came from the same packet sounds unlikely. If you have a programmer, you could try reloading the software is about the only sensible suggestion I’ve got, maybe @TrystanLea can think of something.
Hello @bgrattan I’ve seen this happen when the battery is drained at the same time as data stops, caused by some kind of software lock up. Have you been recording battery voltage by any chance?
What does the LED on the unit do? does it flash once every minute or 2 minutes? or a different rate?
When I replace the batteries, the led comes on for several seconds. I don’t see any blinking after that.
Ah ok, LED stays on but data comes through on a regular basis?
Have you got a USB to serial programming cable?
It would be worth trying to reset the configuration on it or/and upload the firmware again.
Sounds like something has corrupted somehow.
I thought @bgrattan meant the LED comes on for a few seconds, then goes off, and no further flashes. This is the default action - the LED is turned off when the start-up phase is completed successfully, no flashing LED extends battery life.
v2.3.1 - (12/10/14) don’t flash LED on RF transmission to save power
bool flash_led = false;
and if this is set to
true then lines 494 - 498 flash the LED just after each radio transmission.
That was all I could think of.
Ah yes sorry, I misread that. Sounds like the correct operation then. Best thing would be to try clearing the EEPROM and uploading new firmware I think. We are happy to do that here in the office if you’d like to sent it back to us @bgrattan ?
Am I right in thinking you don’t use ACKs for the emonTH & LPL? Just a thought - what would battery life be if the RFM69CW got into and stayed in ‘receive’ waiting for an ACK from the base? I’m guessing not very long at all - days or weeks?
Thanks @TrystanLea and @Robert.Wall the postage cost to ship back would keep me in batteries for some time. If you could point me to instructions on how to upgrade then I can give it a try—of course, if I mess up then I’ll have to ship it back…
Do you have a programmer available (either that one or its predecessor)?
Do you have an up-to-date emonCMS with the ability to program the emonTH2? Look in Setup →Admin → Update and in the Hardware drop-down “emonTH2” is listed?
These are the pre-requisites. If you don’t have a programmer, you might get the same one locally - but you’re likely to need to solder a header. It’s a Future Technology Devices LC231X (Digikey lists it, no doubt others too) and all the details you need are in Docs → Learn → Electricity Monitoring → Programmers → FTDI. You’ll need a USB lead (A to micro-B), which you probably have anyway.
Don’t be tempted by a cheap programmer without the CTS & RTS lines, you’ll struggle. (See the photo in ‘Learn’)
If you don’t have the upload facility in your emonCMS, you can update it or you’ll need a computer and set up the Arduino IDE. Again, the instructions are in ‘Learn’ and you won’t need the plug-in for Spence-Konde and the DX core. You can use the Arduino IDE Version 2 if you wish, get it direct from Arduino. The ‘Learn’ instructions are for V1.8.x but V2.x is similar enough. You will need the libraries too and of course the emonTH2 sketch from Github. I can’t support you if you try platfomio, when I tried it, it screwed my system up and it took hours to recover, so it’s banned from my laptop.
Once you’ve got the IDE set up and the sketch from Github copied into your “Sketchbook” directory, it’s a matter of plug everything up and one click to compile the sketch, keep a lookout for errors (most likely a missing library - usually in the wrong place) and if all is well it will upload to the emonTH.
Much appreciated, I’ll give it a try.
Checking, I had an error compiling the emonTH2 sketch.
error: ‘SPIClass’ has not been declared
It couldn’t find a declaration for
SPIClass, cured by un-commenting line 29 in RFM.h - part of the LPL library.
If you’re using the proper Arduino IDE as I recommend, you’ll also need to specify the RF Library you want to use in line 86 of the emonTH2 sketch. Uncomment the
#define RadioFormat RFM69_LOW_POWER_LABS