# No data from RFM2PI reaching emoncms **URL:** \ **Category:** RFM69Pi\ **Created:** [12 February 2017 12:26 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144 "2017-02-12T12:26:22Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![SianiAnni](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/s/3ec8ea/32.png) [@SianiAnni](https://community.openenergymonitor.org/u/SianiAnni)\ **Post date:** [12 February 2017 12:26 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/1 "2017-02-12T12:26:22Z")
[Moved from [Newly created inputs not appearing in emonCMS via MQTT](https://community.openenergymonitor.org/t/newly-created-inputs-not-appearing-in-emoncms-via-mqtt/2515)] > [@Newly created inputs not appearing in emonCMS via MQTT](https://community.openenergymonitor.org/t/newly-created-inputs-not-appearing-in-emoncms-via-mqtt/2515/15): > > mandatory. So far so good! Yesterday morning I had one emonTH on node 18 logging tempertaure, humidity, battery level to my emonbase and [emoncms.org](http://emoncms.org) Having given up on getting an old emonTH running using 433, I bought another in the openenergymonitor shop sale. The new emonTH\_V1 arrived yesterday morning, configured for RF nodeid 23 according to the paperwork. I put in some batteries, and the leds lit up steadily for a few seconds and then went out. Since then I have had the first and second emonTH units side by side. The first thing I noticed was that although the leds on the first one flash regularly (although more like every minute rather than every 10 seconds), the second one doesn’t flash at all after the initial power up. At this point the emonTH entries in my local configuration file look like this: ```auto #[[18]] # nodename = emonth0 # [[[rx]]] # names = temperature, humidity, spare1, spare2, battery # datacode = L,L,L,L,L # scales = 0.01,0.01,1,1,0.1 # units = C,%,C,C,V [[19]] nodename = emonth1 [[[rx]]] names = temperature, external temperature, humidity, battery datacode = 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 ``` At this time the first emonTH had been logging for over a month with the node 18 entry for emonhub.conf commented out. Initially the second emonTH was transmitting virtually nothing recognisable. I stopped emonhub and checked the data being received > #minicom -D /dev/ttyAMA0 -b9600 This showed regular, 11 bytes of data from node 18 interleaved with 13 bytes of data on node 23, corresponding to that shown in the NEW FRAME data in the log below. I quit (rather than exited) from the minicom session. I then restarted the emonhub service. (#sudo systemctl start emonhub) When I checked later, things had settled down, and the emonhub.log had entries like this: ```auto 2017-02-11 14:29:16,091 DEBUG RFM2Pi 2507 NEW FRAME : 18 18 7 126 14 0 0 0 0 26 0 2017-02-11 14:29:16,095 DEBUG RFM2Pi 2507 Timestamp : 1486823356.09 2017-02-11 14:29:16,097 DEBUG RFM2Pi 2507 From Node : 18 2017-02-11 14:29:16,100 DEBUG RFM2Pi 2507 Values : [1810, 3710, 0, 0, 26] 2017-02-11 14:29:16,103 DEBUG RFM2Pi 2507 Sent to channel(start)' : ToEmonCMS 2017-02-11 14:29:16,106 INFO RFM2Pi Publishing: emon/18/1 1810 2017-02-11 14:29:16,112 INFO RFM2Pi Publishing: emon/18/2 3710 2017-02-11 14:29:16,118 INFO RFM2Pi Publishing: emon/18/3 0 2017-02-11 14:29:16,123 INFO RFM2Pi Publishing: emon/18/4 0 2017-02-11 14:29:16,128 INFO RFM2Pi Publishing: emon/18/5 26 2017-02-11 14:29:16,143 INFO RFM2Pi Publishing: emon/18/rssi 0 2017-02-11 14:29:16,159 INFO RFM2Pi Publishing: emonhub/rx/18/values 1810,3710,0,0,26 2017-02-11 14:29:16,170 INFO RFM2Pi Publishing: emonhub/rx/18/rssi 0 2017-02-11 14:29:16,198 DEBUG RFM2Pi 2507 adding frame to buffer => [1486823356.090841, 18, 1810, 3710, 0, 0, 26] 2017-02-11 14:29:16,201 DEBUG RFM2Pi 2507 Sent to channel(end)' : ToEmonCMS 2017-02-11 14:29:28,551 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-11 14:29:28,554 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-11 14:29:31,638 DEBUG RFM2Pi 2508 NEW FRAME : 23 184 0 0 0 10 0 31 0 1 0 0 0 2017-02-11 14:29:31,645 DEBUG RFM2Pi 2508 Timestamp : 1486823371.64 2017-02-11 14:29:31,648 DEBUG RFM2Pi 2508 From Node : 23 2017-02-11 14:29:31,651 DEBUG RFM2Pi 2508 Values : [18.400000000000002, 0, 1, 3.1, 1] 2017-02-11 14:29:31,653 DEBUG RFM2Pi 2508 Sent to channel(start)' : ToEmonCMS 2017-02-11 14:29:31,656 INFO RFM2Pi Publishing: emon/emonth5/temperature 18.4 2017-02-11 14:29:31,665 INFO RFM2Pi Publishing: emon/emonth5/external temperature 0 2017-02-11 14:29:31,670 INFO RFM2Pi Publishing: emon/emonth5/humidity 1 2017-02-11 14:29:31,675 INFO RFM2Pi Publishing: emon/emonth5/battery 3.1 2017-02-11 14:29:31,681 INFO RFM2Pi Publishing: emon/emonth5/pulsecount 1 2017-02-11 14:29:31,686 INFO RFM2Pi Publishing: emon/emonth5/rssi 0 2017-02-11 14:29:31,691 INFO RFM2Pi Publishing: emonhub/rx/23/values 18.4,0,1,3.1,1 2017-02-11 14:29:31,697 INFO RFM2Pi Publishing: emonhub/rx/23/rssi 0 2017-02-11 14:29:31,703 DEBUG RFM2Pi 2508 adding frame to buffer => [1486823371.637282, 23, 18.400000000000002, 0, 1, 3.1, 1] 2017-02-11 14:29:31,706 DEBUG RFM2Pi 2508 Sent to channel(end)' : ToEmonCMS 2017-02-11 14:29:35,060 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1486823371.637282,23,18.400000000000002,0,1,3.1,1]]&sentat=1486823375 2017-02-11 14:29:35,294 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-11 14:29:35,298 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-11 14:30:05,073 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1486823405 2017-02-11 14:30:12,545 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-11 14:30:12,548 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y ``` So although the leds weren’t flashing regularly, I was still receiving data. I am supposedly logging to both my local emoncms and [emoncms.org](http://emoncms.org), but all I was seeing at this point was inputs on node 19 and rssi on node 23 locally. I can’t remember what I saw on [emoncms.org](http://emoncms.org). At some point I swapped the batteries between the emonTHs. Things started going wrong after that. On [emoncms.org](http://emoncms.org), inputs from first emonTH moved from node 18 to node 19. Locally, there was nothing. I managed to get some kind of data showing on a graphat [emoncms.org](http://emoncms.org) yesterday evening, but by this morning there was nothing logged locally, and only very limited data showing on [emoncms.org](http://emoncms.org). This morning I uncommented the node 18 entries in emonhub.conf, and restarted the emonhub service. That didn’t seem to help, so I rebooted the pi this morning, and now I seem to have lost all my inputs! from the period of the most recent emonhub service restart, emonhub.log contains: ```auto 2017-02-12 11:48:54,235 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-12 11:48:54,238 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-12 11:49:00,755 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1486900140 2017-02-12 11:49:00,990 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-12 11:49:00,994 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-12 11:49:30,819 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1486900170 2017-02-12 11:49:48,394 DEBUG MainThread SIGINT received. 2017-02-12 11:49:48,396 INFO MainThread Exiting hub... 2017-02-12 11:49:54,459 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-12 11:49:54,463 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-12 11:49:54,818 INFO MainThread Exit completed 2017-02-12 12:03:17,391 INFO MainThread EmonHub emonHub 'emon-pi' variant v1.2 2017-02-12 12:03:17,394 INFO MainThread Opening hub... 2017-02-12 12:03:17,397 INFO MainThread Logging level set to DEBUG 2017-02-12 12:03:17,400 INFO MainThread Creating EmonHubJeeInterfacer 'RFM2Pi' 2017-02-12 12:03:17,408 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 9600 bits/s 2017-02-12 12:03:19,412 WARNING MainThread Device communication error - check settings 2017-02-12 12:03:19,415 INFO MainThread Setting RFM2Pi frequency: 433 (4b) 2017-02-12 12:03:20,419 INFO MainThread Setting RFM2Pi group: 210 (210g) 2017-02-12 12:03:21,424 INFO MainThread Setting RFM2Pi quiet: 0 (0q) 2017-02-12 12:03:22,428 INFO MainThread Setting RFM2Pi baseid: 5 (5i) 2017-02-12 12:03:23,432 INFO MainThread Setting RFM2Pi calibration: 230V (1p) 2017-02-12 12:03:24,436 DEBUG MainThread Setting RFM2Pi subchannels: ['ToRFM12'] 2017-02-12 12:03:24,440 DEBUG MainThread Interfacer: Subscribed to channel' : ToRFM12 2017-02-12 12:03:24,442 DEBUG MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS'] 2017-02-12 12:03:24,445 DEBUG MainThread Interfacer: Subscribed to channel' : ToRFM12 2017-02-12 12:03:24,451 INFO MainThread Creating EmonHubMqttInterfacer 'MQTT' 2017-02-12 12:03:24,455 INFO MainThread MQTT Init mqtt_host=127.0.0.1 mqtt_port=1883 mqtt_user=emonpi 2017-02-12 12:03:24,465 DEBUG MainThread MQTT Subscribed to channel' : ToEmonCMS 2017-02-12 12:03:24,469 INFO MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg' 2017-02-12 12:03:24,475 DEBUG MainThread emoncmsorg Subscribed to channel' : ToEmonCMS 2017-02-12 12:03:24,593 INFO MQTT Connecting to MQTT Server 2017-02-12 12:03:24,621 INFO MQTT connection status: Connection successful 2017-02-12 12:03:24,630 DEBUG MQTT CONACK => Return code: 0 2017-02-12 12:03:24,744 INFO MQTT on_subscribe 2017-02-12 12:03:54,599 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1486901034 2017-02-12 12:04:00,402 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-12 12:04:00,405 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-12 12:04:24,579 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1486901064 2017-02-12 12:04:30,396 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-12 12:04:30,399 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-12 12:04:54,581 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1486901094 2017-02-12 12:04:59,852 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-12 12:04:59,857 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y ``` So it looks as if I’ve messed up /dev/ttyAMA0! Help! ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [12 February 2017 21:04 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/2 "2017-02-12T21:04:02Z")
Adding any new nodes to emonhub.conf will be correctly picked up by emonhub immediately, but as described above the phpmqtt input doesn’t seem to pick up those new MQTT inputs without fully rebooting the Pi. The node 18 config is not right, you say it’s 11bytes and yet the config is ```auto # names = temperature, humidity, spare1, spare2, battery # datacode = L,L,L,L,L ``` 5x Unsigned Longs (L) is 20 bytes +1 node id = 21 not 11, I think your device is sending 2 byte values ie int(h) or unsigned int(H) as 5x 2byte values +1 node id = 11. Plus the syntax is incorrect as you cannot have `datacode = L,L,L,L,L`, you can have `datacode = L` or `datacodes = L,L,L,L,L`. As for the serial error in that last log ```auto 2017-02-12 12:03:17,400 INFO MainThread Creating EmonHubJeeInterfacer 'RFM2Pi' 2017-02-12 12:03:17,408 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 9600 bits/s 2017-02-12 12:03:19,412 WARNING MainThread Device communication error - check settings ``` there are 12mins between stopping emonhub and restarting emonhub, I suspect this is when you stopped emonhub to check the serial output in a terminal and not exiting the terminal correctly may have caused a temp fault on the serial port as only one device should be connected at any one time. Can you recheck the log following a full reboot. ---
**Author:** ![SianiAnni](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/s/3ec8ea/32.png) [@SianiAnni](https://community.openenergymonitor.org/u/SianiAnni)\ **Post date:** [13 February 2017 20:36 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/3 "2017-02-13T20:36:12Z")
So, I seem to have several problems. I’ve just rebooted and got the log: ```auto 2017-02-13 20:03:29,083 INFO MainThread EmonHub emonHub 'emon-pi' variant v1.2 2017-02-13 20:03:29,086 INFO MainThread Opening hub... 2017-02-13 20:03:29,088 INFO MainThread Logging level set to DEBUG 2017-02-13 20:03:29,122 INFO MainThread Creating EmonHubJeeInterfacer 'RFM2Pi' 2017-02-13 20:03:29,130 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 9600 bits/s 2017-02-13 20:03:31,156 WARNING MainThread Device communication error - check settings 2017-02-13 20:03:31,159 INFO MainThread Setting RFM2Pi frequency: 433 (4b) 2017-02-13 20:03:32,169 INFO MainThread Setting RFM2Pi group: 210 (210g) 2017-02-13 20:03:33,173 INFO MainThread Setting RFM2Pi quiet: 0 (0q) 2017-02-13 20:03:34,177 INFO MainThread Setting RFM2Pi baseid: 5 (5i) 2017-02-13 20:03:35,181 INFO MainThread Setting RFM2Pi calibration: 230V (1p) 2017-02-13 20:03:36,185 DEBUG MainThread Setting RFM2Pi subchannels: ['ToRFM12'] 2017-02-13 20:03:36,188 DEBUG MainThread Interfacer: Subscribed to channel' : ToRFM12 2017-02-13 20:03:36,217 DEBUG MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS'] 2017-02-13 20:03:36,220 DEBUG MainThread Interfacer: Subscribed to channel' : ToRFM12 2017-02-13 20:03:36,318 INFO MainThread Creating EmonHubMqttInterfacer 'MQTT' 2017-02-13 20:03:36,378 INFO MainThread MQTT Init mqtt_host=127.0.0.1 mqtt_port=1883 mqtt_user=emonpi 2017-02-13 20:03:36,481 DEBUG MainThread MQTT Subscribed to channel' : ToEmonCMS 2017-02-13 20:03:36,517 INFO MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg' 2017-02-13 20:03:36,564 DEBUG MainThread emoncmsorg Subscribed to channel' : ToEmonCMS 2017-02-13 20:03:36,620 INFO MQTT Connecting to MQTT Server 2017-02-13 20:03:36,783 INFO MQTT Could not connect... 2017-02-13 20:03:37,902 INFO MQTT Connecting to MQTT Server 2017-02-13 20:03:38,004 INFO MQTT Could not connect... 2017-02-13 20:03:39,153 INFO MQTT Connecting to MQTT Server 2017-02-13 20:03:39,262 INFO MQTT Could not connect... 2017-02-13 20:03:40,401 INFO MQTT Connecting to MQTT Server 2017-02-13 20:03:40,490 INFO MQTT Could not connect... 2017-02-13 20:03:41,667 INFO MQTT Connecting to MQTT Server 2017-02-13 20:03:41,741 INFO MQTT Could not connect... 2017-02-13 20:03:49,744 INFO MQTT Connecting to MQTT Server 2017-02-13 20:03:49,847 INFO MQTT Could not connect... 2017-02-13 20:03:50,984 INFO MQTT Connecting to MQTT Server 2017-02-13 20:03:51,036 INFO MQTT Could not connect... 2017-02-13 20:03:52,156 INFO MQTT Connecting to MQTT Server 2017-02-13 20:03:52,165 INFO MQTT Could not connect... 2017-02-13 20:03:53,309 INFO MQTT Connecting to MQTT Server 2017-02-13 20:03:53,368 INFO MQTT Could not connect... 2017-02-13 20:03:54,485 INFO MQTT Connecting to MQTT Server 2017-02-13 20:03:54,554 INFO MQTT Could not connect... 2017-02-13 20:03:55,704 INFO MQTT Connecting to MQTT Server 2017-02-13 20:03:55,721 INFO MQTT Could not connect... 2017-02-13 20:03:56,887 INFO MQTT Connecting to MQTT Server 2017-02-13 20:03:56,954 INFO MQTT Could not connect... 2017-02-13 20:03:58,101 INFO MQTT Connecting to MQTT Server 2017-02-13 20:03:58,184 INFO MQTT Could not connect... 2017-02-13 20:03:59,289 INFO MQTT Connecting to MQTT Server 2017-02-13 20:03:59,347 INFO MQTT Could not connect... 2017-02-13 20:04:00,500 INFO MQTT Connecting to MQTT Server 2017-02-13 20:04:00,564 INFO MQTT Could not connect... 2017-02-13 20:04:01,803 INFO MQTT Connecting to MQTT Server 2017-02-13 20:04:01,864 INFO MQTT Could not connect... 2017-02-13 20:04:02,987 INFO MQTT Connecting to MQTT Server 2017-02-13 20:04:03,006 INFO MQTT Could not connect... 2017-02-13 20:04:04,134 INFO MQTT Connecting to MQTT Server 2017-02-13 20:04:04,234 INFO MQTT Could not connect... 2017-02-13 20:04:05,338 INFO MQTT Connecting to MQTT Server 2017-02-13 20:04:05,349 INFO MQTT Could not connect... 2017-02-13 20:04:06,474 INFO MQTT Connecting to MQTT Server 2017-02-13 20:04:06,585 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1487016246 2017-02-13 20:04:06,674 INFO MQTT connection status: Connection successful 2017-02-13 20:04:06,678 DEBUG MQTT CONACK => Return code: 0 2017-02-13 20:04:06,871 INFO MQTT on_subscribe 2017-02-13 20:04:54,794 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-13 20:04:54,796 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-13 20:04:55,385 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1487016295 2017-02-13 20:04:56,005 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-13 20:04:56,007 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-13 20:05:25,411 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1487016325 2017-02-13 20:05:49,272 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-13 20:05:49,284 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-13 20:05:55,474 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1487016355 2017-02-13 20:05:56,063 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-13 20:05:56,066 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-13 20:06:25,549 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1487016385 2017-02-13 20:06:49,216 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-13 20:06:49,219 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-13 20:06:55,625 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1487016415 2017-02-13 20:06:56,044 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-13 20:06:56,047 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-13 20:07:25,658 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1487016445 2017-02-13 20:07:49,460 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-13 20:07:49,473 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-13 20:07:55,714 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1487016475 2017-02-13 20:07:56,089 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-13 20:07:56,091 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-13 20:08:25,732 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1487016505 2017-02-13 20:08:49,362 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-13 20:08:49,366 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-13 20:08:55,806 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1487016535 2017-02-13 20:08:56,015 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org 2017-02-13 20:08:56,019 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y 2017-02-13 20:09:25,878 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1487016565 ``` When I used minitel on Saturday, the v option which showed versin info and then dynamically showed data appearing from both emonTH units, now doesn’t even give the version info. And there’s no v option shown. ![](https://community.openenergymonitor.org/uploads/default/original/2X/1/1ae466a12588449f472b5a4388a2988b5c060b7e.png) . I got a bit confused as to whether I should be using service or systemctl to stop/start emonhub, so there’s a possibility that I may have run minitel while emonhub was stll running… When I do _ls_ on the device I get: ```auto pi@emonpi(ro):emonhub$ ls -l /dev/ttyA* crw-rw---- 1 root dialout 204, 64 Feb 13 20:03 /dev/ttyAMA0. ``` Any suggestions as to what else I can try? ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [13 February 2017 21:08 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/4 "2017-02-13T21:08:14Z")
It certainly looks like you have multiple issues, aside from the errors in the conf pointed out in my last post, there is also a problem communicating with the RFM2Pi via serial. ```auto 2017-02-13 20:03:29,130 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 9600 bits/s 2017-02-13 20:03:31,156 WARNING MainThread Device communication error - check settings ``` and connecting to MQTT ```auto 2017-02-13 20:03:36,620 INFO MQTT Connecting to MQTT Server 2017-02-13 20:03:36,783 INFO MQTT Could not connect... ``` For the serial comms:- Have you disturbed the RFM2Pi board? Is it located neatly on the top ten pins of the Pi’s GPIO? is the underside of the antenna clear of the unused GPIO pins? Is the LED on the RFM2Pi flashing roughly in sync with the emonTH transmissions (around 60s each) Have you used the “update emonbase” or “update RFM69Pi” buttons in emoncms? This will NOT work with the older RFM2Pi’s as they are rfm12b based, not rfm69cw like the current devices. If you have, the firmware on the RFM2Pi will need changing back and in future only use the “update emonPi” button for updating, As it is the _wrong one_ it will fail to install new firmware (because it is set up for an emonPi board) thus not overwriting the RFM2Pi’s rfm12 firmware with rfm69 firmware. For the MQTT issue:- What do you get if you run the following from the command line? ```auto sudo systemctl status mqtt_input ``` If you have updated the emonPi recently can you download the update.log and attach that too. ---
**Author:** ![SianiAnni](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/s/3ec8ea/32.png) [@SianiAnni](https://community.openenergymonitor.org/u/SianiAnni)\ **Post date:** [13 February 2017 23:40 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/5 "2017-02-13T23:40:40Z")
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. ![](https://community.openenergymonitor.org/uploads/default/original/2X/1/15bfec7580753b727af52c0dab5b80b3c210a88b.jpg) Is that a problem? I haven’t used update emonbase or update RFM69Pi in emoncms. For MQTT. ```auto 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. ``` ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [15 February 2017 15:58 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/6 "2017-02-15T15:58:26Z")
> [@Newly created inputs not appearing in emonCMS via MQTT](https://community.openenergymonitor.org/t/newly-created-inputs-not-appearing-in-emoncms-via-mqtt/2515/29): > > 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?](https://community.openenergymonitor.org/t/emonbase-same-setup-as-emonpi/3009/8) 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? ```auto sudo service mosquitto status ``` ---
**Author:** ![glyn.hudson](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/glyn.hudson/32/35003_2.png) [@glyn.hudson](https://community.openenergymonitor.org/u/glyn.hudson)\ **Post date:** [15 February 2017 23:39 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/7 "2017-02-15T23:39:48Z")
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! ---
**Author:** ![SianiAnni](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/s/3ec8ea/32.png) [@SianiAnni](https://community.openenergymonitor.org/u/SianiAnni)\ **Post date:** [16 February 2017 08:10 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/8 "2017-02-16T08:10:13Z")
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! ---
**Author:** ![SianiAnni](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/s/3ec8ea/32.png) [@SianiAnni](https://community.openenergymonitor.org/u/SianiAnni)\ **Post date:** [13 March 2017 15:48 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/9 "2017-03-13T15:48:45Z")
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? ---
**Author:** ![stuart](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/stuart/32/16661_2.png) [@stuart](https://community.openenergymonitor.org/u/stuart)\ **Post date:** [14 March 2017 11:28 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/10 "2017-03-14T11:28:25Z")
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? ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [14 March 2017 12:15 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/11 "2017-03-14T12:15:38Z")
> [@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. ---
**Author:** ![SianiAnni](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/s/3ec8ea/32.png) [@SianiAnni](https://community.openenergymonitor.org/u/SianiAnni)\ **Post date:** [14 March 2017 22:41 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/12 "2017-03-14T22:41:20Z")
> [@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. ---
**Author:** ![ridhaE](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/r/57b2e6/32.png) [@ridhaE](https://community.openenergymonitor.org/u/ridhaE)\ **Post date:** [22 April 2017 22:28 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/13 "2017-04-22T22:28:53Z")
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. ![](https://community.openenergymonitor.org/uploads/default/original/2X/4/47e6075153fa25a9433ce6501fe32bb41fcdfdbf.jpg) Any idea or suggestions about the issue. Thanks. ---
**Author:** ![ridhaE](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/r/57b2e6/32.png) [@ridhaE](https://community.openenergymonitor.org/u/ridhaE)\ **Post date:** [24 April 2017 10:05 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/14 "2017-04-24T10:05:43Z")
I resolve my problem thanks 🙂 . ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [24 April 2017 10:16 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/15 "2017-04-24T10:16:01Z")
How? You might be able to help somebody else if tell us what you did. ---
**Author:** ![ridhaE](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/r/57b2e6/32.png) [@ridhaE](https://community.openenergymonitor.org/u/ridhaE)\ **Post date:** [24 April 2017 12:02 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/16 "2017-04-24T12:02:39Z")
the problem seems to be caused by RFM2Pi , by updating the firmware , it works fine. ---
**Author:** ![SianiAnni](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/s/3ec8ea/32.png) [@SianiAnni](https://community.openenergymonitor.org/u/SianiAnni)\ **Post date:** [18 May 2017 22:40 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/17 "2017-05-18T22:40:43Z")
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: ```auto [[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: ```auto 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? ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [18 May 2017 23:22 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/18 "2017-05-18T23:22:07Z")
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. ---
**Author:** ![SianiAnni](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/s/3ec8ea/32.png) [@SianiAnni](https://community.openenergymonitor.org/u/SianiAnni)\ **Post date:** [19 May 2017 17:03 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/19 "2017-05-19T17:03:33Z")
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. ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [19 May 2017 17:17 UTC](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144/20 "2017-05-19T17:17:44Z")
They are very common and very easy to get hold of, the [OEM shop stocks them too](https://shop.openenergymonitor.com/dht22-temperature-humidity-sensor-am2302/), How long ago did you buy them? If it wasn’t that long ago email [support@openenergymonitor.org](mailto: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](https://community.openenergymonitor.org/t/newly-created-inputs-not-appearing-in-emoncms-via-mqtt/2515). [Next page](https://community.openenergymonitor.org/t/no-data-from-rfm2pi-reaching-emoncms/3144.md?page=2)