I have a new EmonTH2 node that I wish to use in garage, for pulse counting mainly.
I am reading packets from it using an RFM69 based Jeelink. It runs happily for as long as I care to observe it, while in the house. However when placed in the garage, I find it will stop working once the temperature falls to around 16C.
I have re-flashed the sketch to blink the led and use a 20s interval for debugging purposes. I observe that when it stops it really does stop - no more led blinks (even if warmed up again).
It doesn’t seem to stop abruptly. There are a couple of garbled packets first, eg
I’m sorry your emonTH is failing you - this is certainly not something that I can recollect having come across before. I’d suggest getting a powerful magnifying glass and have a good look for a badly soldered joint - particularly around the radio module but also around the Si7021 sensor, or maybe a broken track. If there’s nothing obvious, email the shop ([email protected]) and mention this topic. They should be back on Tuesday.
I have an emonTH2 in my garage, reading 12.6°C now, and it’s been lower at 3.7°C on 28th November, so it’s not a generic problem.
You could try disabling the radio - comment out just the one line that transmits, line 444 or thereabouts rf12_sendNow(0, &emonth, sizeof emonth);
and if it is the radio, it should continue flashing the LED (though of course you won’t know the temperature unless you enable debugging and use your programmer to watch the output, with a long USB extension to stay in the warm yourself).
Equally, you could comment out where the sensor is read (the ‘if’ clause just above that ‘if (SI7021_status==1)’ and substitute bogus data in emonth.temp = ' and emonth.humidity = ` (123 should read 12.3°C, etc)
I think that’s about all you can do to narrow it down.
Thanks for the reply and suggestions Robert. I tried 2 experiments:
Comment out sensor reading code, include power enable/disable.
Comment out radio transmission code, including power enable/disable.
In both cases I see similar behaviour, in that the LED will stop blinking after 15-20 mins or so of taking the EmonTH outside.
I tested Vcc in various places while in the garage and see the expected 3.3V (DHT22 pads, screw terminals, RFM69 board). Battery voltage was 2.6V.
I noticed (fairly sure this was not happening previously) that my current sketch with radio disabled the LED starts blinking again not long after bringing the EmonTH back into the warm. This is after setting it down without touching it further. I have only observed the transition (not-flashing - flashing) once and am pretty sure unless I blinked that there was no long LED pulse indicating a reset. Also I think the first few blinks had some flashes missed out.
As for visual inspection I only have a x10 loupe and can’t see anything obviously wrong.
I think I will need to get in touch with the shop.
I think so too. From what you’ve written, there’s an intermittent contact that’s breaking and (possibly) making again as the temperature changes and parts expand and contract at different rates. It’s more likely to be soldering on the board rather than a weld inside one of the i.c’s, but I wouldn’t rule that out.
I received a replacement EmonTH on Saturday (thanks Glyn) and of course it has been running without incident for several days now in the same location where the failing unit was not happy.
My initial debugging assuming a radio issue was useful in that it prompted me to replaced my RFM12 JeeLink receiver with an RFM69 one to be able to log RSSI, and to add an extra wire to it to make the antenna into a dipole. As a result my existing collection of JeeLib-based sensors now seem to have far fewer missed packets.
Now on to work out how best to count reed switch closures on my gas meter with the EmonTH (looks like something is in the forum archive).
I’ve recently (and finally) got round to that. Basically, it’s the reed between the pulse input and GND, using the internal pull-up of the ATMega '328P. I found I had intermittent contact both as the reed closed and as it opened, @glyn.hudson’s software hold-off doesn’t solve both problems, but a 0.1 µF across the reed did what’s necessary. I’ve logged over 5 k pulses so far, the last time I checked 3 days ago, the meter had recorded 5283.5 (pulses) and the count was 5284, it’s consistently been ±1 pulse over all time, depending on where the most significant digit is when I read the meter.
I couldn’t implement the solution I’ve put into emonLibCM due to battery life and power considerations.