EmonTX v3 not showing in latest build of EmonCMS

Hi All,

Many years ago I purchased a Pi + EmonTX solution from here and used it successfully for may years.

I know have re-found the parts and have setup the EmonTXv3 which all looks to be working fine and have put a new copy of the EMONCMS software onto an SD card and fired up a Raspberry Pi 3 model B with the RFM12B expansion.

The CMS boots fine and I have created an account BUT in the Setup > Inputs screen nothing shows despite my patience… I seem to remember something about there being baud rates to set somewhere but no idea how to achieve this or where to look!

Any help gratefully received!!!

To use the older RFM12Pi you need to set the baud rate to 9600 in emonhub.conf this can be done via the emonhub tab in emoncms:

The Tx and the RFM12Pi are the same frequency?

I changed the EmonHub Config settings to 9600 and also noticed I could turn on error logging and got the following:

-- Logs begin at Thu 2016-11-03 17:16:42 UTC, end at Wed 2019-04-24 08:09:02 UTC. --
Apr 24 07:59:14 emonpi emonhub.py[327]: 2019-04-24 07:59:14,234 INFO     MainThread Setting emoncmsorg sendstatus: 1
Apr 24 07:59:24 emonpi systemd[1]: Stopping emonHub service description...
Apr 24 07:59:24 emonpi systemd[1]: Stopped emonHub service description.
Apr 24 07:59:24 emonpi systemd[1]: Started emonHub service description.
Apr 24 07:59:26 emonpi emonhub.py[998]: 2019-04-24 07:59:26,259 INFO     MainThread EmonHub emonHub emon-pi variant v2.1.2
Apr 24 07:59:26 emonpi emonhub.py[998]: 2019-04-24 07:59:26,259 INFO     MainThread Opening hub...
Apr 24 07:59:26 emonpi emonhub.py[998]: 2019-04-24 07:59:26,260 INFO     MainThread Logging level set to DEBUG
Apr 24 07:59:26 emonpi emonhub.py[998]: 2019-04-24 07:59:26,260 INFO     MainThread Creating EmonHubJeeInterfacer 'RFM2Pi'
Apr 24 07:59:26 emonpi emonhub.py[998]: 2019-04-24 07:59:26,263 DEBUG    MainThread Opening serial port: /dev/ttyAMA0 @ 9600 bits/s
Apr 24 07:59:28 emonpi emonhub.py[998]: 2019-04-24 07:59:28,266 WARNING  MainThread Device communication error - check settings
Apr 24 07:59:28 emonpi emonhub.py[998]: 2019-04-24 07:59:28,267 INFO     MainThread Setting RFM2Pi frequency: 433 (4b)
Apr 24 07:59:29 emonpi emonhub.py[998]: 2019-04-24 07:59:29,268 INFO     MainThread Setting RFM2Pi group: 210 (210g)
Apr 24 07:59:30 emonpi emonhub.py[998]: 2019-04-24 07:59:30,270 INFO     MainThread Setting RFM2Pi quiet: 0 (0q)
Apr 24 07:59:31 emonpi emonhub.py[998]: 2019-04-24 07:59:31,272 INFO     MainThread Setting RFM2Pi baseid: 5 (5i)
Apr 24 07:59:32 emonpi emonhub.py[998]: 2019-04-24 07:59:32,273 INFO     MainThread Setting RFM2Pi calibration: 230V (1p)
Apr 24 07:59:33 emonpi emonhub.py[998]: 2019-04-24 07:59:33,275 DEBUG    MainThread Setting RFM2Pi subchannels: ['ToRFM12']
Apr 24 07:59:33 emonpi emonhub.py[998]: 2019-04-24 07:59:33,276 DEBUG    MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS']

I have a feeling that another baud rate was used for a short time - but I can’t remember what it was. I’d suggest trying different values from 9600 up. 57600 has been mentioned.

Thought this might be useful too.

Server Information
emonhub Active Running
emoncms_mqtt Active Running
feedwriter Active Running - sleep 60s
service-runner Active Running
emonPiLCD Active Exited
redis-server Active Running
mosquitto Active Running
Emoncms Version low-write 9.9.8
Modules Administration : App v1.2.1 : Backup v1.1.6 : EmonHub Config v1.1.0 : Dashboard v1.3.3 : Device v1.2.1 : EventProcesses : Feed : Graph v1.2.3 : Input : Postprocess v1.0.0 : CoreProcess : Schedule : Network Setup v1.0.0 : sync : Time : User : Visualisation : WiFi v1.3.1
Git URL: GitHub - emoncms/emoncms: Web-app for processing, logging and visualising energy, temperature and other environmental data : Branch: * stable : Describe: v9.5.1-1775-gd0db7a57
Server OS Linux 4.14.71-v7+
Host emonpi : emonpi : (
Date 2019-04-24 11:54:21 UTC
Uptime 11:54:21 up 3:33, 1 user, load average: 0.16, 0.16, 0.11
HTTP Server Apache/2.4.25 (Raspbian) HTTP/1.1 CGI/1.1 80
MySQL Version 5.5.5-10.1.23-MariaDB-9+deb9u1
Host (
Date 2019-04-24 11:54:20 (UTC 00:00‌​)
Stats Uptime: 12770 Threads: 3 Questions: 19831 Slow queries: 0 Opens: 24 Flush tables: 1 Open tables: 18 Queries per second avg: 1.552
Redis Version 3.2.6
Host localhost:6379 (
Uptime 0 days
MQTT Server Version Mosquitto 1.4.10
Host localhost:1883 (
Pi Model Raspberry Pi 3 Model B Rev 1.2 - 1 GB (Embest)
SoC Broadcom BCM2835
Serial num. 6071C3AD
Temperature CPU: 50.46°C - GPU: 51.5’C
Release emonSD-30Oct18
Memory RAM Used: 15.16% Total: 976.74 MB Used: 148.06 MB Free: 828.68 MB
Swap Used: 0.00% Total: 100 MB Used: 0 B Free: 100 MB
Disk Mount Stats
/ Used: 39.89% Total: 3.81 GB Used: 1.52 GB Free: 2.11 GB
/boot Used: 51.71% Total: 42.52 MB Used: 21.99 MB Free: 20.53 MB
/home/pi/data Used: 3.43% Total: 3.21 GB Used: 112.8 MB Free: 2.93 GB
PHP Version 7.0.30-0+deb9u1 (Zend Version 3.0.0)
Modules apache2handler : calendar v7.0.30-0+deb9u1 : Core v7.0.30-0+deb9u1 : ctype v7.0.30-0+deb9u1 : curl v7.0.30-0+deb9u1 : date v7.0.30-0+deb9u1 : dom v20031129 : exif v7.0.30-0+deb9u1 : fileinfo v1.0.5 : filter v7.0.30-0+deb9u1 : ftp v7.0.30-0+deb9u1 : gd v7.0.30-0+deb9u1 : gettext v7.0.30-0+deb9u1 : hash v1.0 : iconv v7.0.30-0+deb9u1 : igbinary v2.0.1 : json v1.4.0 : libxml v7.0.30-0+deb9u1 : mbstring v7.0.30-0+deb9u1 : mcrypt v7.0.30-0+deb9u1 : mosquitto v0.4.0 : mysqli v7.0.30-0+deb9u1 : mysqlnd vmysqlnd 5.0.12-dev - 20150407 - $Id: b5c5906d452ec590732a93b051f3827e02749b83 $ : openssl v7.0.30-0+deb9u1 : pcre v7.0.30-0+deb9u1 : PDO v7.0.30-0+deb9u1 : pdo_mysql v7.0.30-0+deb9u1 : Phar v2.0.2 : posix v7.0.30-0+deb9u1 : readline v7.0.30-0+deb9u1 : redis v4.1.1 : Reflection v7.0.30-0+deb9u1 : session v7.0.30-0+deb9u1 : shmop v7.0.30-0+deb9u1 : SimpleXML v7.0.30-0+deb9u1 : sockets v7.0.30-0+deb9u1 : SPL v7.0.30-0+deb9u1 : standard v7.0.30-0+deb9u1 : sysvmsg v7.0.30-0+deb9u1 : sysvsem v7.0.30-0+deb9u1 : sysvshm v7.0.30-0+deb9u1 : tokenizer v7.0.30-0+deb9u1 : wddx v7.0.30-0+deb9u1 : xml v7.0.30-0+deb9u1 : xmlreader v7.0.30-0+deb9u1 : xmlwriter v7.0.30-0+deb9u1 : xsl v7.0.30-0+deb9u1 : Zend OPcache v7.0.30-0+deb9u1 : zlib v7.0.30-0+deb9u1
Client Information
HTTP Browser Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36
Screen Resolution 3008 x 1692
Window Size 2039 x 1253

Did you buy the RFM card and the EmonTX at the same time? Are the frequencies of the 2 items the same (I accidentally was sent 2 different ones when I bought mine many moons ago). Worth checking.

Yep, I bought a kit many moons ago and it was all working on the old Raspberry Pi before I tried to get clever and move it to newer hardware etc…

Ah OK. Did you run an update from the Administration screen?

@Robert.Wall - could the wrong firmware have been flashed as part of an update? Not something I know how to fix.

This is where it gets confusing. The emonPi and the emonBase are more or less the same. If an “emonBase” update is done on an emonPi, the update to the RFM12B/69CW should fail because it’s the wrong baud rate. The converse is also true. So yes, I suspect that might have happened. But I don’t know what symptoms that might produce to give an indication that it has happened.

I’m not a RPi or emonCMS expert, so I’m not the right person to ask.

I think from the picture that RFM12B is a 433 MHz version, so the frequency of the RFM12Pi is correct.

Ok, thanks. @pb66 @glyn.hudson could you advise?

IIRC, that was 38400 bps.

AFAIR all rfm12b’s were originally 9600, only when we moved to rfm69cw did the baud get changed to 57600 and then to 38400. And since then the later rfm12b firmware has now been changed to 38400 too since it is the same fw as the rfm69cw but with “compat” set.

I’m less sure of the current status as there are a lot of changes to the update procedure in the last month or so and there is no build guide for the current image, but prior to Oct 2018, I believe the firstboot script that auto runs when an image is first installed will assume it’s an emonpi and try to update the emonpi FW, failing to do so on a emonBase regardless of rfm 12or69.

So it is only IF the “update emonbase” button has been used that it will have updated the FW and over written the rfm12 FW with rfm69 FW (same FW but compiled with the compat setting). I strongly suspect that is the case. IIRC when the wrong FW is installed, the LED might stay on since the rfm cannot be initialised. It looks like the led is on in the picture, that could just be a fluke capture, but that combined with the error and no data, plus the updates, it’s a very strong possibility.

If that is the case you will need to ssh in and run a manual command to reflash the rfm12 FW. unless you might be able to switch branches in emoncms (to master) and maybe @TrystanLea’s new multi-button setup might allow reflashing an rfm12pi via the GUI? I’m not sure how far that’s progressed, or if it’s any easier to switch branches over manually flashing (assuming avrdude etc is still there on the oct 2018 image?)

@alunr - can you confirm if you updated via the “update emonbase” button and/or if the rfm12pi’s LED is permanently lit?

[edit] Seems there might not be a emoncms option to update just yet (emonpi/update at master · openenergymonitor/emonpi · GitHub) so it would have to be via the command line using


(I think! Ref RFM2Pi/update-RFM12.sh at master · openenergymonitor/RFM2Pi · GitHub)

1 Like

And before any corrections start, YES an RFM12Pi can be either rfm12 or rfm69! The RFM69Pi’s (PCB with additional IO broken out) are all rfm69cw, but the RFM12Pi’s (no additional IO) are either rfm12b (9600 or 38400) or rfm69cw (57600 or 38400). The add-on board model does not directly map to rfm device or baud other than all RFM69Pi’s are rfm69cw and 38400 baud, but that doesn’t help us here RFM12Pi’s can be almost anything!!!


Hi All, sorry for disappearing, work/life balance got a bit messy…

I definitely updated the EMONCMS to make sure I was up to date. I don’t “think” I updated the EMONBASE but in fairness the UI is a bit messy here…

I’ll try the reflash option and come back to you all!

1 Like

Yes, there is work afoot to improve it with the next release.

1 Like

I “think” this was the culprit but even after running this flash it was all still not working so I gave it one last chance and rebuilt the server from scratch again and BOOM! it all works!!