Getting up to speed on the rfm69cw module capabilities, I noticed that the chip supports AES128 encryption but the Jeelib library doesn’t yet implement this. Has anyone worked with alternate libraries with any success (or interesting failures)?
Here is one with encryption. I’ve only experimented with the non-encryption code examples. I don’t believe this is compatible with the JeeLib library.
I’m fairly certain it isn’t.
Aye. I was thinking along the lines of replacing the JeeLib library with this one. It may be fairly major surgery.
And endangered if you allow the ‘receiving’ end (emonPi/emonBase) to get automatically updated.
setting the emon update and backwards compatibility aside for one moment (ouch)… Is there any reason why the emon systems couldn’t move forward to the LowPowerLabs libraries?
One area of concern might be the temptation to use the higher-powered radios - RFM69HW / RFM69HCW - supported by the LowPowerLabs library I believe, which would almost certainly not be usable on the emonTx V3 without an external 5 V USB power supply.
Hi
Coincidentally I was dealing with same problem.
I replaced original RFM2Pi firmware that uses JeeLib with RMF69 library.
Details can by found in GitHub - vvvlc/RFM2Pi at RFM69
I plan to add support to EmonCMS hub in future.
Regards
Vitek
Be aware that you might run into problems if you update your emonPi.
As @pb66 wrote about the sketch in the Atmel328P (the ‘emon’ part):
If you use the “update RFM69Pi” button rather than the “update emonPi” button it will update in exactly more or less the same way but when it tries to upload the firmware at the wrong upload baud it will fail and the existing firmware will remain intact. This works as the 16MHz emonPi has a different bootloader to all the 8MHz RFM2Pi type devices.
- If you have an emonPi with a totally stock sketch you are best using “update emonpi” to keep up to date.
- If you have an emonPi with a modified sketch you are best using “update emonbase” to avoid overwriting.
- If you have an emonBase and you know your RFM2Pi or RFM69Pi is rfm69 based and has a totally stock sketch you are best using “update emonBase” to keep it updated
- If you have an emonBase with a rfm69 based RFM2Pi or RFM69Pi running a modified sketch OR if you have a rfm12 based RFM2Pi OR you are unsure what RFM2Pi you have you should use “update emonpi” to avoid over-writing the firmware.
Aside from the firmware differences, there is no difference, both buttons fully update the emonSD used in both the emonPi and emonBases. There is no emonHub update button, emonhub is updated along with emoncms and other softwares in that same emonSD update.
See Update EmonPi Button or Update EmonBase Button? for more info.
Oh, If only things were that straight-forward, sometime after that I discovered there is a load of other unrelated stuff that’s been tagged on the end of the “emonpi” firmware update that doesn’t get done on the “rfm69pi” update. So it would seem users with either a stock emonpi sketch, an edited rfm69pi sketch or an rfm12pi (ie use the emonpi update) get “bonus updates” and those users that have an edited emonpi sketch or stock rfm69pi sketch (ie use the rfm69pi update) do not. (see Update EmonPi Button or Update EmonBase Button? - #15 by pb66 for more info).
I do not think there is anything crucial to miss out on, but none the less it does mean it’s not “exactly the same” and not all update routines are equal (even aside from the FW)
Why did this spring to mind? “That’s the beauty of standards. There are so many to choose from.”
At least, Vitek and anyone following his lead will be aware of the dangers lurking.
[I’ve edited my warning to incorporate the main message of yours. Thanks PB.]
1 Like
Thx folks for comments, I have neither emonPi nor emonBase. But I understand this could be confusing and dangerous for for owners of emonPi, emonBase, because as you wrote RFM69 is not compatible JeeLib.
I have Raspbery Pi and RFM69Pi_V3 made by Martin Harizanov
and I have several http://harizanov.com/wiki/wiki-home/funky-v3/ so I wanted to leverage encryption.
Funky sends data to gateway RFM69Pi_V3 running on RPI where emonhub is running that forwards data to emoncms.org.
I would like to enhance emonhub to support:
- encryption
- FOTA to update firmware in Funky using emonhub. I have a proof on concept for FOTA that works without external SPIFlash (GitHub - vvvlc/Funky-FOTA: FOTA for Funky)
Regards
Vitek
can you provide a link, pic or more details on that HW? I’d just like to know we are talking about the same HW, does it say “openenergymonitor” and “made in Wales” on it?
Interesting stuff, keep us posted as to how it goes or if you need any help with the emonhub implementation let us know and I’ll help if I can.
One day I’d like to get around to making a Low Power Labs interfacer so we have an alternative option to JeeLib, but I have to say it’s not high on the priorities right now. A LoRaWAN transceiver would be good to.
It is this http://harizanov.com/2013/02/new-rfm2pi-board-in-the-works/ but with http://harizanov.com/2015/03/using-rfm69cw-instead-of-rfm12b/
Vitek
Ah, ok, Here at OEM an RFM69Pi is one of these
which is the “v3” of the RFM2Pi boards.
v1 was initially ATtiny and then ATMega in a DIL package (see Raspberry Pi - OpenEnergyMonitor Wiki)
v2 was a SMT ATmega328p, originally with a rfm12b and then later on a rfm69cw, (see RFM12Pi V2 - OpenEnergyMonitor Wiki)
The “v3” is essentially the same as a late rfm69cw “v2” but with additional IO broken out to the edge of the board to take headers. (see RFM69Pi V3 - OpenEnergyMonitor Wiki)
What I suspect you have is a “RFM2Pi v2 with RFM69CW” as shown at the bottom left of the second link in your last post (http://harizanov.com/2015/03/using-rfm69cw-instead-of-rfm12b/), If so it works exactly the same way as a “v3” it just doesn’t have the 2 rows of additional IO holes.
So anything you dev for your board will work for any rfm69cw based RFM2Pi or RFM69Pi OEM boards too.
You had me thinking Martin had released a new model I missed :-).