No data from RFM2PI reaching emoncms

SianiAnni · 2017-02-13T23:40:40.443Z

Thanks for taking the time to help me out with this Paul.

I haven’t opened up the pi casing since around last November myself, so unless someone else opened it up last Thursday evening at EcoHomeLab, the board would not have been disturbed. And everything was fine until Saturday when the second emonTH was powered up.

I’ve been watching for several minutes and haven’t seen a led on the RFM2Pi flashing. But, there is a white splodge on the square chip.

IMG_20170213_232704509.jpg3328×2496 2.14 MB

Is that a problem?

I haven’t used update emonbase or update RFM69Pi in emoncms.

For MQTT.

pi@emonpi(ro):~$ sudo systemctl status mqtt_input
â mqtt_input.service - LSB: Starts phpmqtt_input agent daemon at boot time
   Loaded: loaded (/etc/init.d/mqtt_input)
   Active: active (running) since Mon 2017-02-13 20:04:19 UTC; 2h 46min ago
  Process: 1816 ExecStart=/etc/init.d/mqtt_input start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/mqtt_input.service
           ââ1820 /usr/bin/php /var/www/emoncms/scripts/phpmqtt_input.php

Feb 13 20:04:19 emonpi mqtt_input[1816]: Starting Daemon for the emoncms MQTT script: mqtt_input.
Feb 13 20:04:19 emonpi systemd[1]: Started LSB: Starts phpmqtt_input agent daemon at boot time.

pb66 · 2017-02-15T15:58:26.720Z

Newly created inputs not appearing in emonCMS via MQTT

But, there is a white splodge on the square chip.

I can’t say I can’t ever recall seeing an ATmega328p with a “white splodge” on it and now I’ve seen 2 in one day!
(See Emonbase - same setup as EmonPi? thread).

Is the “splodge” dry? does it smell? Is it definitely “on” the chip or is the chip surface “holed”? Having never “popped” one of these myself, I do not know what to expect to see after the smoke and the smell dissipated if one did “pop”. Are you able to confirm it definitely wasn’t there previously or have you just not noticed it before? It looks like a smear of heat sink compound from here.

As for the MQTT that service looks fine, what about the mosquitto service?

sudo service mosquitto status

glyn.hudson · 2017-02-15T23:39:48.409Z

The spot just means it’s been tested and was working when it left the factory, one of the manufacturers we worked with for a while used this method of identification. Our current manufacturer uses a sticker which is much more unambiguous!

SianiAnni · 2017-02-16T08:10:13.623Z

Thanks Paul and Glyn, pleased to hear it’s just paint

Getting beaylott to sort out the RFM12Pi for me. Will get there one day!

SianiAnni · 2017-03-13T15:48:45.000Z

I now have a replacement RFM2Pi board on my pi.
I have the ‘newer’ emonTHV1 at home, and running at 38400.
Initially it appeared to be constantly logging bad data (starting with ?) despite having quiet = true in the config file.
When I commented out quiet = true, those reports went away, which was the opposite of what I would expect, but anyway, I could the see the data being received regularly in the log:

2017-03-13 15:12:13,128 DEBUG RFM2Pi 64 NEW FRAME : OK 23 191 0 0 0 10 0 26 0 1 0 0 0 (-67)
2017-03-13 15:12:13,137 DEBUG RFM2Pi 64 Timestamp : 1489417933.13
2017-03-13 15:12:13,139 DEBUG RFM2Pi 64 From Node : 23
2017-03-13 15:12:13,141 DEBUG RFM2Pi 64 Values : [19.1, 0, 1, 2.6, 1]
2017-03-13 15:12:13,144 DEBUG RFM2Pi 64 RSSI : -67
2017-03-13 15:12:13,147 DEBUG RFM2Pi 64 Sent to channel(start)’ : ToEmonCMS
2017-03-13 15:12:13,150 INFO RFM2Pi Publishing: emon/emonth5/temperature 19.1
2017-03-13 15:12:13,158 INFO RFM2Pi Publishing: emon/emonth5/external temperature 0
2017-03-13 15:12:13,163 INFO RFM2Pi Publishing: emon/emonth5/humidity 1
2017-03-13 15:12:13,169 INFO RFM2Pi Publishing: emon/emonth5/battery 2.6
2017-03-13 15:12:13,175 INFO RFM2Pi Publishing: emon/emonth5/pulsecount 1
2017-03-13 15:12:13,180 INFO RFM2Pi Publishing: emon/emonth5/rssi -67

and there is an input called emonth5 in the local emoncms showing temperature and battery values much as I could expect.
But what’s happened to the humidity data?
The invoice for the emonTH says it is a emonTH V1 Temperature & Humidity Node DHT22 [emonTH_V1].
The other slightly odd thing is that the emonTH LED doesn’t flash as it transmits data.
What version of software should I be running on emonTH V1/DHT22?

stuart · 2017-03-14T11:28:25.541Z

It may just be the picture quality above, but the solder connections of the header connector look very dull and grey - is this bad soldering?

Robert.Wall · 2017-03-14T12:15:38.781Z

SianiAnni:

The other slightly odd thing is that the emonTH LED doesn’t flash as it transmits data.

Correct, it doesn’t. That is intentional - to save battery power.
I think the latest will be emonTH_DHT22_DS18B20_RFM69CW_Pulse.ino, V2.7, but you’ll need to change that from the RFM69CW (#define RF69_COMPAT 1 ) to #define RF69_COMPAT 0 for your RFM12B radio module.

SianiAnni · 2017-03-14T22:41:20.404Z

Robert.Wall:

emonTH_DHT22_DS18B20_RFM69CW_Pulse.ino, V2.7

Thanks Robert. Good to know about the LED
Next job is to get that sketch uploaded.

ridhaE · 2017-04-22T22:28:53.177Z

Hi , I’m new in using emoncms . My Emonpi work normally for severals days. But Yesterday , I lost getting data from RFM2PI and no data pulished or recieved in MQTT server. I don’t know what’s happen. The log file show me somethings like this.

log.jpg1341×466 180 KB

Any idea or suggestions about the issue. Thanks.

ridhaE · 2017-04-24T10:05:43.249Z

I resolve my problem thanks .

Robert.Wall · 2017-04-24T10:16:01.223Z

How? You might be able to help somebody else if tell us what you did.

ridhaE · 2017-04-24T12:02:39.432Z

the problem seems to be caused by RFM2Pi , by updating the firmware , it works fine.

SianiAnni · 2017-05-18T22:40:43.194Z

Two months later, and I have eventually got the firmware recommended by @Robert.Wall onto my second emonTH_V1.
It’s still giving me temperature readings in the correct range, and battery levels look ok. But it is still giving me humidity readings which are not in the correct range. Given that this is what I was seeing back in March, I suspect it’s the humidity sensor itself.
Relevant config is as follows:

[[19]]
   nodename = emonth1
   [[[rx]]]
       names = temperature, external temperature, humidity, battery
       datacodes = h,h,h,h
       scales = 0.1,0.1,0.1,0.1
       units = C,C,%,V

[[23]]
    nodename = emonth5
    [[[rx]]]
       names = temperature, external temperature, humidity, battery, pulsecount
       datacodes = h,h,h,h,L
       scales = 0.1,0.1,0.1,0.1,1
       units = C,C,%,V,p

Frame data extracted from log:

2017-05-18 18:06:10,029 DEBUG    RFM2Pi     62945 NEW FRAME : OK 23 216 0 0 0 102 0 27 0 1 0 0 0 (-69)
2017-05-18 18:07:09,900 DEBUG    RFM2Pi     62952 NEW FRAME : OK 23 216 0 0 0 102 0 27 0 1 0 0 0 (-69)
2017-05-18 18:08:09,783 DEBUG    RFM2Pi     62958 NEW FRAME : OK 23 216 0 0 0 102 0 27 0 1 0 0 0 (-68)
2017-05-18 18:09:09,592 DEBUG    RFM2Pi     62965 NEW FRAME : OK 23 216 0 0 0 102 0 27 0 1 0 0 0 (-68)
2017-05-18 18:09:49,591 DEBUG    RFM2Pi     62970 NEW FRAME : OK 19 187 0 0 0 14 2 24 0 (-63)
2017-05-18 18:10:09,487 DEBUG    RFM2Pi     62973 NEW FRAME : OK 23 216 0 0 0 102 0 27 0 1 0 0 0 (-69)
2017-05-18 18:11:09,354 DEBUG    RFM2Pi     62980 NEW FRAME : OK 23 216 0 0 0 102 0 27 0 1 0 0 0 (-68)
2017-05-18 18:12:09,148 DEBUG    RFM2Pi     62987 NEW FRAME : OK 23 216 0 0 0 102 0 26 0 1 0 0 0 (-69)
2017-05-18 18:13:09,029 DEBUG    RFM2Pi     62994 NEW FRAME : OK 23 216 0 0 0 102 0 26 0 1 0 0 0 (-69)
2017-05-18 18:14:08,912 DEBUG    RFM2Pi     63001 NEW FRAME : OK 23 216 0 0 0 102 0 27 0 1 0 0 0 (-69)
2017-05-18 18:14:28,312 DEBUG    RFM2Pi     63004 NEW FRAME : OK 19 187 0 0 0 15 2 25 0 (-63)
2017-05-18 18:15:08,769 DEBUG    RFM2Pi     63009 NEW FRAME : OK 23 215 0 0 0 94 0 27 0 1 0 0 0 (-69)
2017-05-18 18:16:08,712 DEBUG    RFM2Pi     63016 NEW FRAME : OK 23 215 0 0 0 94 0 27 0 1 0 0 0 (-69)
2017-05-18 18:17:08,529 DEBUG    RFM2Pi     63023 NEW FRAME : OK 23 215 0 0 0 94 0 27 0 1 0 0 0 (-69)

So whereas the first emonTH on node 19 is giving me humidity readings around the 50% mark, the second emonTH on node 23 is reading around the 10% mark. It’s almost as if the most significant byte of data has lost its value/been reset by something.

Could it be anything else other than a dodgy humidity sensor?

pb66 · 2017-05-18T23:22:07.880Z

You could well be right about the humidity sensor, a very quick and easy way to prove it one way or the other would be to swap the 2 sensors if you have 2 emonTH v1’s. The large white 4 pin sensor just pulls out and pushes back in, if the low reading transfers with the sensor to the other emonTH, it is without doubt, the sensor.

SianiAnni · 2017-05-19T17:03:33.988Z

Have swapped the sensors and yes, the fault has moved with the sensor!
Thanks @pb66. Now I have a way forward, as long as I can get hold of a spare sensor.

pb66 · 2017-05-19T17:17:44.990Z

They are very common and very easy to get hold of, the OEM shop stocks them too, How long ago did you buy them? If it wasn’t that long ago email support@openenergymonitor.org @glyn.hudson or @Gwil might just pop one in the post to you as the’re generally nice like that when you’ve had a bit of a bumpy road trying to get this working.

Robert.Wall · 2017-05-19T17:59:56.058Z

… and mention this thread.

glyn.hudson · 2017-05-19T22:28:30.505Z

No problem, we can send you a couple of DHT22 sensors free of charge. In fact if anyone else wants DHT22 sensors we’re also happy to send them out free of charge if you’re happy to cover shipping. We actually have some excess stock when we moved from the emonTH V1 to emonTH V2 with Si7021.

Best email support@openenergymonitor.zendesk.com and quote your original order number.

Sorry to hear you have had trouble.

SianiAnni · 2017-05-20T07:23:21.728Z

Thanks everyone I did email sales last night cheekily asking for a replacement, and have just forwarded to support as you suggest Glyn.

SianiAnni · 2017-05-25T22:09:39.608Z

Thanks @glyn.hudson for the sensors. They have arrived and I have tried them.

You might be interested to hear that the first one I tried behaved exactly the same as the one I was having problems with. I’m guessing you sent two because you’ve seen a high failure rate?

The second worked. Sort of. It’s readings are 20% less than the good one from 1+ years ago, even when they’re side by side:)

emoncms-25-5-diff-hum.jpg1903×927 208 KB

Is this something you have seen before? I’ve just ‘calibrated’ it by adding 20 to the raw input, so will keep an eye on that. That should be good enough.