Keen to try out this new emonTx V4. I already have a server on site running 24x7.
The options in the shop are “None” and “emonBase 433Mhz”. I think I don’t need yet another computer running here, so I’d like to try to interface with what I already have. I am already using Zigbee and rtl_433 to collect data from existing sensors and it looks like emonTx might have worked with rtl_433 once, but may now be moribund.
Has anyone interfaced an RFM69 module with a PC? Adafruit Feather M0 looks like it might work?
Welcome.
Doesn’t rtl_433 have a builtin decoder for emoncms (edit - yes 45)? The packet format may have changed and/or you will need to adjust the firmware for the right format (as out of the box the TX4 uses a different library/format) - @Robert.Wall will be able to help with that.
Me, I have interfaced an ESP device to the UART and developed an ESPHome component to read the data and send it on (search out the threads).
I’m afraid not. Trystan has modified the emonTx V3 sketches and emonLibCM for what I’m calling the 1V6I version, I’ve barely looked at what he’s done as I’m battling (and so far losing) to make good his promises for speed, capabilities etc on the 3-phase and 12-input versions (3V6I & 3V12I).
OK, ESP* sounds like the way to go for now. They’re pretty cheap, there’s wifi where the emonTx would be going and I’ve used one before.
If I can get rtl_433 working at some point, then great, but the reason I said it’s moribund is this:
Just to be clear, will the RFM69 module in the emonTx broadcast the data unilaterally, without another RFM69 module to talk to?
1 Like
The RFM69CW can use any one of 3 protocols: “classic” Jeelib, “RFM69 Native” JeeLib or LowPowerLabs. To receive the transmissions you need a compatible receiver (in terms of frequency, receiver bandwidth and demodulator) and appropriate software to decode the data. Published here are full details of the first two, and I believe details on the 3rd will be available shortly if they have not appeared already. I can’t help much more than that.
I know nothing about 3rd party opinions published elsewhere.
For now, but I think the PiPicoW is the future, but support for it is still a bit limited.
Ah it’s the Whitening that is the issue.
Firstly, @wattaload the Whitening can be turned off - that used to be a runtime option, but it looks like you will have to do it in the code and recompile. @TrystanLea, Robert, can you confirm?
@Robert.Wall, you can probably answer some of the questions posed in the GitHub Issue. I know you don’t ‘do’ Git, but this is just a conversation in a forum effectively.
Is there any documentation on the implementation of the whitening for them?
As far as I know, the on-line switch to turn the radio off/on/whitened is still present. I haven’t removed it. If it’s not implemented in the emonTx V4 sketch that @TrystanLea has published, then you must turn off whitening in emonHub.
If you don’t know what whitening is, look at the emonTx V3 sketch.
The help on the TX4 shows
w<x> - turn RFM Wireless data off: x = 0 or on: x = 1
That I don’t know.
That issue on GitHub was asking about how it is implemented in the packets sent - i.e is there a flag saying it is on in the packet. Is that documented anywhere?
As you well know, I have NO knowledge of what goes on in Github.
Yes but I hadn’t realised you were so closed as to not even look and read the issue - commenting or helping is just like responding here. GitHib /= git.
Yes that’s correct.
Sounds like Pi Pico or ESP is your best bet for now, or if it’s within short distance USB is simpler still.
Whereas previously whitening was a feature implemented at the Atmega328 level, it’s actually possible to let the RFM69Cw radio itself handle this, which is where that’s moved now. It’s an option you can turn on/off with a register setting so in principle you could always modify the firmware to suit your requirements.
WiFi does seem like it will be the least trouble in your case.
1 Like
Is there any definition of the packet structure that would help the rtl_433 guys?
Which library should be selected?
I can confirm it is not implemented in the emonTx4 sketch as this is now dealt with on the RFM69cw chip itself. That said the LowPowerLabs format has whitening turned off, which is a shame and I missed that (I’ve just found this discussion about that setting over at LowPowerLabs https://github.com/LowPowerLab/RFM69/issues/70), I might consider switching that on. We have however turned encryption on as standard which should in effect achieve the same aim. With the important note that encryption is currently turned on with a key that is public and therefore not secure by anything more than obscurity - a user needs to set a self generated key on all nodes to secure properly. This will all be in the documentation.
1 Like
It did occur to me today, that an EmonBase without RF connected by USB to the TX4 would be one of the cheapest options. I still think the RFM comms method’s days are numbered 
The best bet is to look for a LowPowerLabs based receiver that can plug into the @wattaload server via usb. That will then be able to pick up the emonTx4 packets with only the need to match the encryption key, networkID and frequency.
Is the JeeLib Classic closer to the old TX3 format that the rtl_433 could decode?
JeeLib Classic is the old TX3 format (I’ve copied the terminology from JCW who coined them here » Classic vs native packets » JeeLabs).
I dont think any of the formats would be more or less hard to decode than the other. Whitening should not be an issue, Encryption is probably more complicated but that could be turned off. Perhaps the Feather M0 running a LowPowerLabs receiver code is the easiest solution: Adafruit Feather M0 RFM69 Packet Radio - Pimoroni their recommendation for use with this board is the LowPowerLabs library Using the RFM69 Radio | Adafruit Feather M0 Radio with RFM69 Packet Radio | Adafruit Learning System
1 Like
Looks like this is now an option: