Old emontx v2 low power temp nodes not working any more


I have 3 old emonTx low power temp nodes with ds18b20 sensors which were working well sending data to my emonpi… but now they stopped working properly. I assume it is not a hardware failure because all 3 of them have the very same symptoms. So unless there is a very well planned obsolence :confused: or I am really unlucky :confounded:… I tend to think it is a sotware failure in my emoncms or my emontx code (or compatability between them).

From time to time, I’ll enventually get a temperature from one of them but it is quite sparse and very random.

I just upgraded to the latest emonpi image and reload the lastest emontx fw which I “tuned” a bit. But it won’t work either with original one.

On emontx side, I added some Serial.print. It seems to run ok although it kind of prints corrupted data on some lines :

emonTX Low-power temperature sensor
Based on OpenEnergyMonitor.org software & hardware
Node        : 21
Freq        : 433Mhz
Network     : 210
Resolution  : 12
Conv. delay : 751
Period      : 30000
Start loop...
Requesting temp...
Getting temp...
t|X[é 2143
vcc : 300
Waking up rf12...
sending to rf12...
going to sleep...
Start loop...
Requesting temp...
Getting temp...
tpX[é 2162
vcc : 300
Waking up rf12...
sending to rf12...
going to sleep...

For instance :
tpX[é 2162
should be
temp : 2162

On emonpi side, in emonhub logs, I can’t see the packet coming in, only those from emonpi itself.

Is there a way to debug what’s happening at the arduino level ?
How can I check I get a proper RF connection ?


The corrupted serial is due to the micro going to sleep before serial has finished printing. Try adding a short delay before sleep.

Could you post the rest of your code?

It’s rare for a unit to stop working after working fine for a long period. How is the unit being powered? What are the environmental conditions? Try taking the atmega328 out of its holder and check for any corrosion on pins etc

Ok… adding some dely do solve this ! Thanks for the tip (I’ve been searching for hours :frowning: )

I reloaded the latest firmware I could find with small changes (just for debug print). here it is.

  emonTX LowPower Temperature Example 
  Example for using emonTx with two AA batteries connected to 3.3V rail. 
  Voltage regulator must not be fitted
  Jumper between PWR and Dig7 on JeePort 4

  WHEN SLEEPING                                    0.01mA or maybe less (limit of meter) 

  Temperature sensing takes: 782308 us
  RFM12 Sending takes 2920 us
  TOTAL = 0.785s @ 7mA = 0.017242822 J per pulse
  one every 10s = 0.001724282 W
  baseload = 0.00003137W (worst case)
  = 0.001755652 W
  3000 mah = 2x 10517J ~ 138 Days

  This setup allows the DS18B20 to be switched on/off by turning Dig7 HIGH/LOW
  Part of the openenergymonitor.org project
  Licence: GNU GPL V3
  Authors: Glyn Hudson, Trystan Lea
  Builds upon JeeLabs RF12 library and Arduino


  Libraries in the standard arduino libraries folder:
  - JeeLib    https://github.com/jcw/jeelib
  - OneWire library http://www.pjrc.com/teensy/td_libs_OneWire.html
  - DallasTemperature http://download.milesburton.com/Arduino/MaximTemperature/DallasTemperature_LATEST.zip

  Other files in project directory (should appear in the arduino tabs above)
  - emontx_lib.ino
  - print_to_serial.ino

/*Recommended node ID allocation
-ID-  -Node Type- 
0 - Special allocation in JeeLib RFM12 driver - reserved for OOK use
1-4     - Control nodes 
5-10  - Energy monitoring nodes
11-14 --Un-assigned --
15-16 - Base Station & logging nodes
17-30 - Environmental sensing nodes (temperature humidity etc.)
31  - Special allocation in JeeLib RFM12 driver - Node31 can communicate with nodes on any network group

#define RF69_COMPAT 0 // SET TO 1 IF RFM69
#define RF_freq RF12_433MHZ                                                // Frequency of RF12B module can be RF12_433MHZ, RF12_868MHZ or RF12_915MHZ. You should use the one matching the module you have.
const int nodeID = 24;                                                  // emonTx temperature RFM12B node ID - should be unique on network
const int networkGroup = 210;                                           // emonTx RFM12B wireless network group - needs to be same as emonBase and emonGLCD
                                                                                 //DS18B20 resolution 9,10,11 or 12bit corresponding to (0.5, 0.25, 0.125, 0.0625 degrees C LSB), lower resolution means lower power

const int time_between_readings= 10000;                                  //in ms

#define RF69_COMPAT 0 // set to 1 to use RFM69CW 
#include <JeeLib.h>   // make sure V12 (latest) is used if using RFM69CW
#include <avr/sleep.h>
ISR(WDT_vect) { Sleepy::watchdogEvent(); }                              // Attached JeeLib sleep function to Atmega328 watchdog -enables MCU to be put into sleep mode inbetween readings to reduce power consumption 

#include <OneWire.h>
#include <DallasTemperature.h>

#define ONE_WIRE_BUS 4                                                  // Data wire is plugged into port 2 on the Arduino
OneWire oneWire(ONE_WIRE_BUS);                                          // Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
DallasTemperature sensors(&oneWire);                                    // Pass our oneWire reference to Dallas Temperature.
DeviceAddress sensor;                                                   // arrays to hold device address

typedef struct {
      int temp;                                         
    int battery;                                          
} Payload;
Payload emontx;

void setup() {
  Serial.println("emonTX Low-power temperature example"); 
  Serial.print("Node: "); 
  Serial.print(" Freq: "); 
  if (RF_freq == RF12_433MHZ) Serial.print("433Mhz");
  if (RF_freq == RF12_868MHZ) Serial.print("868Mhz");
  if (RF_freq == RF12_915MHZ) Serial.print("915Mhz"); 
  Serial.print(" Network: "); 
  pinMode(7,OUTPUT);                                                    // DS18B20 power control pin - see jumper setup instructions above
  digitalWrite(7,HIGH);                                                 // turn on DS18B20
  if (!sensors.getAddress(sensor, 0)) Serial.println("Unable to find DS18B20 Temperature Sensor");
  rf12_initialize(nodeID, RF_freq, networkGroup);                          // initialize RFM12B
  rf12_control(0xC040);                                                 // set low-battery level to 2.2V i.s.o. 3.1V


void loop()
  digitalWrite(7,HIGH); delay(2);  // turn on DS18B20 and wait for it to come online
  sensors.requestTemperatures();                                        // Send the command to get temperatures
  float temp=(sensors.getTempCByIndex(0));

  Serial.print(F("temp: ")); Serial.println(emontx.temp);
  Serial.print(F("vcc : ")); Serial.println(emontx.battery);

  // if ready to send + exit loop if it gets stuck as it seems too
  int i = 0; while (!rf12_canSend() && i<10) {rf12_recvDone(); i++;}
  rf12_sendStart(0, &emontx, sizeof emontx);
  // set the sync mode to 2 if the fuses are still the Arduino default
  // mode 3 (full powerdown) can only be used with 258 CK startup fuses

long readVcc() {
  long result;
  ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
  while (bit_is_set(ADCSRA,ADSC));
  result = ADCL;
  result |= ADCH<<8;
  result = 1126400L / result;
  return result;

Yes… I do believe (hope) it is a software issue

Powered using 2 1.5v AA batteries, living at my place… so not really rough condition.
If there ware an issue with the atmega, I wouldn’t get proper serial output, would I ? But I cchecked anyway, seems quite ok.


On the emonpi side, are you seeing a large number of rejected packets? (Debug on, ‘unreliable contents’)

Hello Emjay,

In emonhub.log ? No. Is there any other log I could look at ? Can I have a look at what’s happening on the arduino side ?


Assuming you have set loglevel = DEBUG in emonhub.conf, Have you edited the nodes section for your nodes, your excerpt shows node 21 and the included sketch is node 23, both of these define more variables than the sketch transmits, so the packets would be discarded by emonhub as they are not as expected. However if this was the issue emonhub would log an error so the packets would be visable in the emonhub.log so it is easily spotted.

If there are no traces in the emonhub.log at all then can you try moving one closer to the emonPi to confirm it’s not a range issue.

Unfortunately the emonPi’s quiet mode is permenant so you will not be able to see any packets that have fallen short of the checks in the emonPi receiver FW. If you are comfortable with uploading sketches which it seems you are, you could load the rfm2pi firmware on one of the emonTx v2 temp nodes to view (via the programmer lead & arduino IDE) what it receives from the others, you will have more info to work with.

Hello Paul,

Yes, I changed the nodes definitions to match mine (should have change the number but at the time, I did not want to reload a new sketch on sensors which were working fine!) I tried to change the ID to a non existing node in my conf to see if node configuration could be a problem. As I understand it, it would reveive the data and post it “as-is”. Sorry for the mix of sketch and logs…

Thanks for the tip ! I’ll try that.


If I put one of them side by side with the emonpi, now I get the data :

2016-06-11 23:28:58,112 DEBUG    RFM2Pi     163128 adding frame to buffer => [1465680538, 5, 572, 0, 572, 245.63, 0, 0, 0, 0, 0, 0, 0]
2016-06-11 23:28:58,113 DEBUG    RFM2Pi     163128 Sent to channel' : ToEmonCMS
2016-06-11 23:28:59,217 DEBUG    RFM2Pi     163129 NEW FRAME : OK 21 233 8 42 11 (-78)
2016-06-11 23:28:59,218 DEBUG    RFM2Pi     163129 Timestamp : 1465680539.22
2016-06-11 23:28:59,218 DEBUG    RFM2Pi     163129 From Node : 21
2016-06-11 23:28:59,219 DEBUG    RFM2Pi     163129    Values : [22.81, 2.858]
2016-06-11 23:28:59,219 DEBUG    RFM2Pi     163129      RSSI : -78
2016-06-11 23:28:59,220 INFO     RFM2Pi     Publishing: emon/emonTemp1/temperature 22.81
2016-06-11 23:28:59,220 INFO     RFM2Pi     Publishing: emon/emonTemp1/battery 2.858
2016-06-11 23:28:59,221 INFO     RFM2Pi     Publishing: emon/emonTemp1/rssi -78
2016-06-11 23:28:59,222 INFO     RFM2Pi     Publishing: emonhub/rx/21/values 22.81,2.858
2016-06-11 23:28:59,222 INFO     RFM2Pi     Publishing: emonhub/rx/21/rssi -78
2016-06-11 23:28:59,224 DEBUG    RFM2Pi     163129 adding frame to buffer => [1465680539, 21, 22.81, 2.858, -78]
2016-06-11 23:28:59,224 DEBUG    RFM2Pi     163129 Sent to channel' : ToEmonCMS

So looks like it is only a range problem. I did not imagine it could come from a distance problem as I did not move the sensors when they finally stopped working. And looking at the emonpi, I noticed I never installed the antenna :confounded:

But it worked fine without before !
Sorry for the silly question :confused:

I got 2 more though

  • I only see RSSI data in the input view, not my own data. Here is an extract of my emonhub conf. Am I missing something obvious (as just installing the antenna…) :
    nodename = emonTemp1
       names = temperature, battery
       datacode = h
       scales = 0.01,0.001
       units = C,V
  • What is RSSI exactly ? What are “good values” for RSSI ?

Thanks a lot for your help.


I don’t know why I wasn’t getting my data along with RSSI value but I restarted emonpi and now everything is up & running.

So, in the end

  • corrupted Serial.print output is due to Arduino going to sleep to fast. Adding a delay() for 50 to 100ms solved it (for debug only)
  • not receiving data was due to… RF antenna not installed (sorry)

Thanks a lot for your help.

RSSI is Received Signal Strength Indicator.
Good values are closer to zero - so the closer to zero the better. The best I have seen is -20 to -29.

1 Like

Hello @Jon,

Thanks for the explanation !