OpenEnergyMonitor Community

Rmf69 setting for emonth2

Tags: #<Tag:0x00007fc9b2bde7b8>

I need to pick up the messages from the emonth2 from a raspberry pi. I purchased the RFM2Pi which picks up the packets fine. However, I need to also communicate with other devices from energenie so I want to use just one RMF69 device. As the RFM2Pi is not really configurable directly from the PI I am using another RFM69 device from energenie as using two crashes the pi. I assume it crashes because of power. There should be no addressing conflict.

I write my own code to talk directly with the RFM69 so all I need are the settings. However, I’ve tried to reverse engineer the code from emonth2 and jeelib on github but I just cant seem to pick up the emonth message which is rather baffling.

Can someone simply supply the register values of the RFM69 I need to pick up the messages. I assume they are once a minute without a request.

I’m not quite sure of the frequency. It says 433 but this has to be converted and placed into 3 registers on the rfm69. The rf69_initialize function seems to take four parameters and I can’t get the value of β€œoff” so I assumed zero.

setFrequency(freq * 10000000L + band * 2500L * off); where freq is 43. band is 1.

This is my attempt at the settings

[[β€˜0x1’, β€˜0x10’], [β€˜0x2’, β€˜0x0’], [β€˜0x3’, β€˜0x1a’], [β€˜0x4’, β€˜0xb’], [β€˜0x5’, β€˜0x5’], [β€˜0x6’, β€˜0xc3’], [β€˜0x7’, β€˜0x6c’], [β€˜0x8’, β€˜0x4f’], [β€˜0x9’, β€˜0x0’], [β€˜0xa’, β€˜0x40’], [β€˜0xb’, β€˜0x40’], [β€˜0xc’, β€˜0x2’], [β€˜0xd’, β€˜0x92’], [β€˜0xe’, β€˜0xf5’], [β€˜0xf’, β€˜0x20’], [β€˜0x10’, β€˜0x24’], [β€˜0x11’, β€˜0x7f’], [β€˜0x12’, β€˜0x9’], [β€˜0x13’, β€˜0xf’], [β€˜0x14’, β€˜0x40’], [β€˜0x15’, β€˜0xb0’], [β€˜0x16’, β€˜0x7b’], [β€˜0x17’, β€˜0x9b’], [β€˜0x18’, β€˜0x8’], [β€˜0x19’, β€˜0x42’], [β€˜0x1a’, β€˜0x8a’], [β€˜0x1b’, β€˜0x40’], [β€˜0x1c’, β€˜0x80’], [β€˜0x1d’, β€˜0x6’], [β€˜0x1e’, β€˜0x10’], [β€˜0x1f’, β€˜0x0’], [β€˜0x20’, β€˜0x0’], [β€˜0x21’, β€˜0x0’], [β€˜0x22’, β€˜0x0’], [β€˜0x23’, β€˜0x0’], [β€˜0x24’, β€˜0xff’], [β€˜0x25’, β€˜0x0’], [β€˜0x26’, β€˜0x5’], [β€˜0x27’, β€˜0x90’], [β€˜0x28’, β€˜0x0’], [β€˜0x29’, β€˜0x78’], [β€˜0x2a’, β€˜0x0’], [β€˜0x2b’, β€˜0x0’], [β€˜0x2c’, β€˜0x0’], [β€˜0x2d’, β€˜0x3’], [β€˜0x2e’, β€˜0x8f’], [β€˜0x2f’, β€˜0x2d’], [β€˜0x30’, β€˜0xd2’], [β€˜0x31’, β€˜0x0’], [β€˜0x32’, β€˜0x0’], [β€˜0x33’, β€˜0x0’], [β€˜0x34’, β€˜0x0’], [β€˜0x35’, β€˜0x0’], [β€˜0x36’, β€˜0x0’], [β€˜0x37’, β€˜0x8’], [β€˜0x38’, β€˜0x42’], [β€˜0x39’, β€˜0x0’], [β€˜0x3a’, β€˜0x0’], [β€˜0x3b’, β€˜0x0’], [β€˜0x3c’, β€˜0x8f’], [β€˜0x3d’, β€˜0x12’], [β€˜0x3e’, β€˜0x0’], [β€˜0x3f’, β€˜0x0’], [β€˜0x40’, β€˜0x0’], [β€˜0x41’, β€˜0x0’], [β€˜0x42’, β€˜0x0’], [β€˜0x43’, β€˜0x0’], [β€˜0x44’, β€˜0x0’], [β€˜0x45’, β€˜0x0’], [β€˜0x46’, β€˜0x0’], [β€˜0x47’, β€˜0x0’], [β€˜0x48’, β€˜0x0’], [β€˜0x49’, β€˜0x0’], [β€˜0x4a’, β€˜0x0’], [β€˜0x4b’, β€˜0x0’], [β€˜0x4c’, β€˜0x0’], [β€˜0x4d’, β€˜0x0’], [β€˜0x4e’, β€˜0x0’], [β€˜0x4f’, β€˜0x93’]]

My project is on hold until this is resolved. I’ve used a second RMF69 device from another supplier and this can also communicate with the energenie devices but not emonth2.

I take it you have the RFM69CW data sheet?
The other sources that might help are the β€˜receive’ RFM code for the emonPi and the emonGLCD, both of which are on Github.
I’ve taken apart the β€˜transmit’ code out of JeeLib, but not the β€˜receive’ side. (That is published with the 3-phase PLL sketch, but it might not help much.)
The emonTH, like everything else, is never polled, all transmit on a timer and don’t expect an acknowledgement.

Yes I have the data sheet.
I’ll check out those references shortly.
That’s what I thought regarding the polling.

What would be nice is if the emonth2 code had a command option to dump the RFM69 registers.

As I would prefer the two systems to talk at the same level to avoid frequency hoping which gets a bit messy (one uses 434 and one 433, one uses Manchester de/encoding the other doesn’t etc) I might look at uploading my own build and reconfigure the message so it is similar to the energenie packet method. Hmm so close and yet so far.

What is odd is that when I use the RFM2Pi I get lots of noise (Every few seconds) when the filter is not active. . Yet when I listen for the packets using my software absolutely nothing. When I use the settings for energgenie their packets come through loud a clear from all over the house. Not one false or mist packet even with all the filters off and the sync opened up to 7 bit errors allowed. I have 4 eTRVs and one energy monitor plug.


Setting the registers for the transmit and receive parameters is all part of JeeLib, and I don’t think there’s a command in the RFM69CW to read everything en bloc. (I haven’t seen anything, but then I’ve never specifically looked for that.)

Changing the emonTH to a different protocol would probably be easier than changing the RFM2Pi to read Energinie packets. I say that only because when I looked at JeeLib, and after I’d picked apart all the functions and made most of it in-line, it wasn’t very difficult to see exactly what was being done and why.

Thanks, I’m now looking at loading software to RFM2Pi just so I can add a command to dump the registers.
Hopefully all this can be done from the pi. After that I plan load new software to the emonth2. Actually the JeeLib packet should be fine. Its just the the initial parameters sent to the RFM69 I need to change. Two minutes worth of coding. Its just the hours of setting it all up.

Manchester encoding
Should be close.

My software now slowly scans frequencies and I still didn’t find the packet.

Its odd that its actually cheaper to buy another eTRV than the buy the emonth2 but as I have one I’m determined to use it. In fact I don’t understand why remote thermostats are generally so expensive. I just need the temperature wirelessly. All the clever stuff is done between the pi and my phone. The thermostat just needs to be a plane box just like the emonth2. Off topic rant. Apologies.

I’ve now upload a new version of the RFM2Pi software with my new registry dump menu option and everything looks the same as my settings unfortunately.
I am using a hacked version of the using an rmf69 directly linked to the pi and I just don’t understand how I can get message from energenie settings but not the open energy setting. The jeelib RFM69 code seems quite small and straight forward.
One difference is I don’t use interrupts as they are not connected on the RFM69 board. The pi doesn’t really support interrupts (I believe) so I simply poll the rmf69 by checking to see if the buffer contains data.

After my success with updating the firmware on the RFM2Pi I now want to update the firmware on the emonth2 so I can match the wireless settings with the engergenie settings and hoping this will allow me to se the messages.

I assume I can link the pi directly to the uart (as and use the avrdude to load firmware similar to the RFM2Pi using the same settings. Does anyone know if there is a guide to this and the pins of the uart on the emonth2.

The circuit diagram for the emonTH is on Github, and the FTDI port is identical to the emonTx V3.

I now have it working. Its taken longer to resolve this single issue than to develop the rest of my project.

I amened the code in small stages on both the rfm2pi and emonth2 until I was using the same spec as required by the openenergie.

It seems the Jeelib for the emonth2 and the RFM2Pi are different. I need to double check this but it seems the emonth2 uses 3 sync characters but somehow the RFM2Pi uses 2. Not sure how this works. I need to go through the process again to confirm so will update later.

I now have C code (or Python code) communicating directly with the RFM69 from a pi receiving both Jeelib temperature packet and the energenie packet.

In the end only a few lines of code needed changing so I now have a room thermostat. Phew

1 Like

Would you be open to sharing your code(s)? And pinout/schematic? Are you using the Pi’s SPI pins?


Yes I’m using the Pi SPI. The big advantage is the the program runs on the Pi so I can use a debugger.

My project uses an ABElectronics Expander to give me Digital IOs at 5V and some ADC converters. However this board also uses the SPI. Whilst the manuals would suggest I can use CS0 or CS1 and share the port I couldn’t get it to work so I cut my loses and moved the RFM69 to the second SPI port so I use the pins lower down (35,36,38,40). I use a general IO pin (22) for the reset simply because the energenie used this pin but I don’t use an interrupt pin for data received as this can be achieved by polling. So all my code is designed around the energenie code as I can’t change this.

The new enonth2 code changes are:.

Frequency is slightly different ( Think it uses the old code used for the RFM21 with default offset). It uses Manchester encoding and a different freq deviation. it now uses two sync bytes which I think was why I couldn’t see the packets. The emonth2 seems not to use the Jeelib on the openenergy git hub but a slightly different version. The new emonth2 code has changed very little but it has a few debugs in the code where it dumps the rfm69 registers to the screen on boot up. The rest is just changes to the settings described above.

I also have the python code from etrombly/RFM69 on git hub (converted from lowpowerlab c code). This is codged but does see both packets from energygenie and my version of emonth but no more.

As well I have hacked code from energenie that runs on the pi. This is C code that picks up the energenie packets but now detects a jeelib packet (simply by the node) and then extracts the required fields. Some of the code is a bit of a codge but works for what I want. If someone would find it useful I can tidy it up.

I’m quite willing to share my code although it is based on code from energenie. Its not too hard to convert it to python.

Hope this helps. Let me know which bits you want.