OpenEnergyMonitor Community

Sending to emonhub/tx/nodeid/values: emonHub doesn't trigger RFM69Pi outbound packet

Hi all,
I recently had to replace my node-RED server because the Pi it was running on died. I moved my flows over and I have one particular one that publishes to emonhub/tx/16/values, which in turn causes my Emonhub to tell the RFM69Pi to send radio packets outbound.

I doesn’t appear to me that the radio packets are going out. They certainly don’t seem to be arriving at the destination, but I don’t see anything in the emonHub log that would indicate they are being sent. I’m using the same emonHub configuration file, the same RFM69Pi, the same receiving nodes as I was when it was working last week. The only thing that has changed is that the version of everything in the emonHub and node-RED stack is newer, and I went from a Pi 3 to a Pi 4.

Any suggestions for me?

Here is the history of how I got this working in the before times.

Update. I think the problem might be that no serial output is going from the Pi to the RFM69Pi.

I tried using minimum to test this.
sudo minicom -b 38400 -D /dev/ttyAMA0

I tried typing ‘v’ and ‘t’ to see if I could get a response from the RFM69Pi and I didn’t get anything. Even though it is receiving signals from emonTx and outputting over serial to emonHub, it doesn’t seem to be getting serial inbound from the Pi. At least not from minicom.

However, I can update the firmware from the Admin screen in emonCMS, so it must get something?

Then I tried plugging in a homemade RFM69Pi I put together with a Motieno USB and the RFM69Pi firmware. It works to receive inbound emonTx on TTYUSB0, and I could see this in minicom. But again, typing ‘t’ and ‘v’ did nothing. So then I plugged this Moteino USB into the Arduino IDE on my PC and sent ‘t’ and ‘v’ through the serial monitor. This did work, and I could tell in emonHub that the packets were sent and received. So it really is something where the Pi is not sending serial out to the RFM69Pi.

I’ve tried this on a Pi 2 Model B and a Pi 4. Same thing.

I tried making sure I had serial enabled in raspy-config. No dice.

Any ideas would be much appreciated.

Hi Brandon. I rarely use minicom so I can’t recall what it does about line endings, your Arduino IDE will be set to send both if that is working ok.

Try sending v\r\n or t\r\n if minicom doesn’t add them. [Edited to include the \rs as both return and newline required]

Getting the expected responses using the serial terminal would then confirm an issue in emonhub, currently the clues are possibly contradicting as minicom not working suggests a port or connection issue, but yes as you suspect, uploading new FW does confirm the RPi tx to RFM2Pi rd line is ok.

There have been a lot of changes in emonhub including a move to Python3, several changes in the MQTT side and IIRC correctly the RFM side has been changed to better suit a flawed emonGLCD FW (rather than the other way round), and I suspect very few if any checks would have been done to the RFM send code as very few users use it AFAIA.

Do you recall exactly what version of emonhub you were previously running? Looking at the commits on git between versions might help, but there may be a lot to wade through.

The version of emonCMS running on that Pi was low-write 9.8.31 | 2018.06.21. I am not sure how to find which version of emonHub. But in any case, older.

I tried using minicom to connect to the RFM69Pi running on my emonCMS server and was able to confirm that it responds to ‘t’ and ‘v’, which is consistent with the idea that communication from the Pi to the RFM69Pi is not the issue. (Testing with another Pi and another RFM69Pi is a habit because minicom hijacks all the data going to emonCMS while I am testing. But in this case the test setup isn’t sending data from the Pi to the RFM69Pi. I am going to assume that is some problem with the serial setup on these test Pis I had sitting around and not worry about it for now.)

In other news, I just found this post that would suggest I might have to update the version of jeelib I use on my receiving node. I have been using the OEM specific fork, but it appears @alandpearson used the latest jeelib on the emonGLCD receiving side? At least, that it how I read the thread so far.


I can confirm that messages from node-RED to the topic emonhub/tx/16/values are being published. I can see them using mosquitto_sub -v -u ‘emonpi’ -P ‘emonpimqtt2016’ -t ‘emonhub/#’ on my emonCMS Pi.

I can confirm that packets go out from my RFM69Pi and are received by my device. I plugged my receiving device into Arduino IDE so I can see what it is receiving using the serial monitor. I can send a test packet by from the RFM69Pi by connecting to it with minicom and using ‘t’. This test packet is received by my device.

However, when I send “1,1,1” to emonhub/tx/16/values using node-RED, no packet is received by my device.

So it seems to me that the breakdown is in emonHub listening to the tx topic and triggering an outbound message.

Here is my setup in emonHub config.


    Type = EmonHubMqttInterfacer
        mqtt_host =
        mqtt_port = 1883
        mqtt_user = emonpi
        mqtt_passwd = emonpimqtt2016

        pubchannels = ToRFM12,
        subchannels = ToEmonCMS,

        # emonhub/rx/10/values format
        # Use with emoncms Nodes module
        node_format_enable = 1
        node_format_basetopic = emonhub/

        # emon/emontx/power1 format - use with Emoncms MQTT input
        nodevar_format_enable = 1
        nodevar_format_basetopic = emon/

    nodename = emonIOT
       names = switchId, btnIndex, mode, switchMessage
       datacode = h
       scales = 1,1,1,1
       units = "","","",""
       names = switchId, btnIndex, mode
       datacodes = b, b, b
       units = "","",""

By my device do you mean emonhub?

Set log level to DEBUG - you should get a message on receipt.

One of my pet hates, an if with no else.

If it receives something but doesn’t parse it correctly, then you will never know :angry:

Assuming you are not getting a log message indicating the message has been received and parsed, I suggest adding in an else to that statement and just try and debug it here.