RFM69Pi Packets Appear to Be Coming from Node 37

emonHub
1

Hi all,

I’m working on a project where I’ll need my RFM69Pi to send packets outbound from my emonHub, based on messages from node-RED via MQTT. I’m using the emonGLCD instructions as an example of what to do. My Pi is running low-write 9.8.31 2018.06.21, created from an emonSD image back when the image included node-RED and openHAB.

I wasn’t having luck getting my packets on the receiving end, so I decided to test that the radio was sending using minicom connected to the RFM69Pi. I used ‘t’ to send a test packet and I listened on another RFM69Pi. I was able to see the test packet being broadcast, but it appeared to be coming from node 37.

The sending RFM69Pi connected to my node-RED server gives this information when I press ‘v’. I looks like it is sending from Node 5, as expected for an emonPi.
[RF12demo.14] E i5 g210 @ 433 MHz

Then I press ‘t’ to send a test packet. This is what I see on the other RFM69Pi:

OK 37 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 2
 -> ack

To me it looks like the packet is being sent from Node 37. Any idea why?

2

Because you’ve enabled acks, the ‘32 bit’ of the byte containing the node id (0-31) is used to set acks. It looks as if there is an error in the firmware with regards to masking the 3 msb’s to leave just the node id (5 lsb’s).

I’m pretty sure this has been fixed previously, how old is the rfm69pi?

Edit - found it!

What version fw is the “other” receiving rfm69pi running? If it’s pre RFdemo.13 that would make sense.

3

Thanks!
This makes sense. So the RFM69Pi connected to the emonPi is transmitting, and my node is receiving. What must be failing is the node-RED/MQTT flow to transmit the message.

I pasted the flow here, but essentially it publishes “1,1,0” to emonhub/tx/16/values. Any thoughts on how to track this down? I haven’t looked inside the emonHub python script much, especially for outbound messages.

[{"id":"e26336dd.efa688","type":"inject","z":"66944c61.60cc04","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":160,"y":140,"wires":[["f3c9e8f9.ebfa58"]]},{"id":"f3c9e8f9.ebfa58","type":"function","z":"66944c61.60cc04","name":"Test message","func":"var thingId = 1;\nvar argument1 = 1;\nvar argument2 = 0;\n\nmsg.payload = thingId + ',' + argument1 + ',' + argument2;\nreturn msg;","outputs":1,"noerr":0,"x":380,"y":140,"wires":[["d5277251.3e4ac"]]},{"id":"d5277251.3e4ac","type":"mqtt out","z":"66944c61.60cc04","name":"","topic":"emonhub/tx/16/values","qos":"2","retain":"","broker":"bb796140.4b562","x":680,"y":140,"wires":[]},{"id":"bb796140.4b562","type":"mqtt-broker","z":"","broker":"localhost","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","willTopic":"","willQos":"0","willPayload":""}]

And here are the relevant (I think) portions of the emonhub.conf

[[MQTT]]

    Type = EmonHubMqttInterfacer
    [[[init_settings]]]
        mqtt_host = 127.0.0.1
        mqtt_port = 1883
        mqtt_user = emonpi
        mqtt_passwd = emonpimqtt2016

    [[[runtimesettings]]]
        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
        # http://github.com/emoncms/emoncms/blob/master/docs/RaspberryPi/MQTT.md
        nodevar_format_enable = 1
        nodevar_format_basetopic = emon/

…

    [[16]]
        nodename = emonIOT
        [[[rx]]]
           names = switchId, btnIndex, mode
           datacodes = h
           scales = 1,1,1
           units = "","",""
         [[[tx]]]
           names = nodeid, switchId, btnIndex, mode
           datacodes = h
           units = "","",""

.

4

Update: I can tell that my node-RED-to-MQTT flow is getting messages to the EmonHubMqttInterfacer (I changed the debug line from .uri to .realdata, but here it is):

2019-11-23 16:00:56,597 DEBUG MQTT ['1', '1', '0'] Sent to channel : ToRFM12

From there I get lost, so far.

5

Update: And I can tell that my RFM2Pi interfacer is getting the cargo appended to it with an info logger line I put into emonhub.py:
2019-11-23 23:09:06,705 INFO MainThread Append cargo to :ToRFM12 : ['1', '1', '0']

I don’t really see where the EmonHubJeeInterfacer looks to see if it has any such cargo to pick up and send.

6

@brandock, you missed this question from @pb66 I think. It may be the firmware on the RFM module needs updating…

7

I just updated my firmware to the one found in the link below. It didn’t help. I wasn’t thinking it would because (a) I could send and receive messages with the RFM69Pi using minicom with the Jeelib test commands and (b) I later tried enabling the emonGLCD time-sending feature in the Emonhub.conf and those messages were sending and being received without issue.

So I am currently trying to work my way through the emonhub.py code, tracing a packet through and seeing if I can understand where it is getting stopped. Currently I think it is after the MainThread appends the message cargo to the ToRFM12 channel. So far I don’t see how it would be picked up by anything.

1 Like
8

Making progress. I now understand where the JeeInterfacer picks up the message. It is in the emonhub_interfacer method “run”, where it calls self.add(frame). The JeeInterfacer has an “add” method that reads the frame and calls its “send” method that writes to the RFM2Pi.

Tracing through to the sending, I discovered that I am getting an error in the data code matching and then a “RFM2Pi thread is dead.”

2019-11-24 **14:00:32** ,018 WARNING RFM2Pi 68 TX datacodes: h are not valid for values ['1', '1', '0']

2019-11-24 **14:00:32** ,024 WARNING RFM2Pi Exception caught in RFM2Pi thread. Traceback (most recent call last):

2019-11-24 **14:00:32** ,216 WARNING MainThread RFM2Pi thread is dead.

2019-11-24 **14:00:32** ,217 WARNING MainThread Attempting to restart thread RFM2Pi (thread has been restarted 1 times...

2019-11-24 **14:00:32** ,219 INFO MainThread Creating EmonHubJeeInterfacer 'RFM2Pi'

2019-11-24 **14:00:32** ,221 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
1 Like
9

Working now. I used this format in my emonhub.conf:

[[16]]
    nodename = emonIOT
    [[[rx]]]
       names = switchId, btnIndex, mode
       datacodes = h
       scales = 1,1,1
       units = "","",""
     [[[tx]]]
       names = switchId, btnIndex, mode
       datacodes = h, h, h
       units = "","",""
1 Like
10

A note for others who might try this. I based my Emonhub.conf settings on an article in the emonGLCD GitHub rep. Based on that, I included “nodeId” in my list of names for the node.

[[[tx]]]
           names = nodeid, switchId, btnIndex, mode

But what I found was that I needed to leave it out of my Emonhub.conf settings, but expect to receive it on the other end as if it was in that position.

This worked:

[[[tx]]]
           names = switchId, btnIndex, mode

with

typedef struct {
  byte nodeId;       // this isn't shown in the emonhub.conf but is added by the interfacer, so you have to recieve it or things are out of aligment 
  byte switchId;
  byte btnIndex;
  byte mode;
} PayloadTX;
1 Like
11

Another note. Make sure your data codes in your Emonhub.conf match your payload structure variable types in your sketch. I changed my data codes to ‘b’ in the Emonhub.conf in my previous post to match the 'byte" variables I was using in PayloadTX.

[[[tx]]]
          names = switchId, btnIndex, mode
          datacodes = b, b, b
          units = "","",""

with

typedef struct {
  byte nodeId;       // this isn't shown in the emonhub.conf but is added by the interfacer, so you have to recieve it or things are out of aligment 
  byte switchId;
  byte btnIndex;
  byte mode;
} PayloadTX;
1 Like