RFM2Pi group and node id not stored after power down

I just amending the firmware on the RFM69Pi (V3.1) and have noticed that the Node ID and GROUP ID is not stored after power down whilst the frequency is. The code would suggest the RF12Config structure should be stored in EEPROM. Am I missing something?
Note that group and node id is restored after a reset just not after power off. The 3rd byte format is restored.

Mike

Which version have you amended, and what have you changed?

Looking at what appears to be the latest (V1.4 - Jan 17) version on Github, those configuration values are stored in EEPROM when any one is changed. But looking at the startup code, there appears to be something weird going on - it looks as if it reads from the EEPROM twice. I need to look at the code in detail to understand what’s going on.

If I’m doing this right the verion of src.ino is 1.4 Jan 17. I cloned the source about a week ago.

I’m building a radiator controller so I will be changing quite a lot. The main change I’ve done so far is to change the RF settings to be compatible with energenie devices so I can use one trasmitter on my Pi but still talk to OEM devices. Energenie uses Manchester encoding. I need to set the ID to 25 and the Group to 212. Its all working fine except for this issue.

I’ve added a new menu command to dump the RF registers and some extra prints.

I’ve also added the 1-wrie libraries althought they are not used yet.

Its hard to debug this issue as it is happening at a boot an power up which happens faster than my Pi boots up. Reset and reboot of Pi works as the power remains.

I was thinking of saving it 2 bytes further on in eeprom :slight_smile:

I think I’m going to be fairly busy with other things for the next day or two, so I doubt I’ll be able to look at this in the immediate future.

If you’re never likely to want to change either, there’s absolutely no reason why your sketch can’t have those things - or all the RFM69’s settings - hard-coded, if that’s OK with you.

Am I right in thinking that you want to sit receiving from OEM devices most of the time, but occasionally turn round and transmit to your Energenie radiators?

No rush. As you say I can hard code round it for now. Just checking it wasn’t a feature and/or thought someone might like to know. Was going to add a Manchester encoding config option to make it configurable in case anyone else may find it useful.

The device will be sitting on my Radiator so it will be listening as it does now for an OEM message. The OEM message will be something like:

  1. Request sensor data which will go out every 1 to 5 minutes.
  2. Switch off/on radiator ball valve
  3. Set Fan speed.

The radiator device will send.

  1. Temp in
  2. Temp Out.
  3. Flow rate.
  4. Fan speed

I’m not changing the message (i.e. 12 bytes). All fits nicely. Just high jacking the fields.

The Pi uses the Energenie RF69i and a very hacked C code supplied by the company called hoperf.

The idea is to replace all my radiators similar to the Jagger ones but using my own bit so its much much cheaper with more features.
I should be able to give the BTU output.
Going off topic so I’ll shut up now.

I’m amazed the problem hasn’t shown up before. In the fullness of time, we’ll probably move away completely from the JeeLib r.f. library because the ATMega 328P in the emonPi just cannot do the RFM12B mode of JeeLib while it’s doing continuous monitoring, so we’ll be changing to the Hope format, which we’re calling RFM69 Native format, for the radio packets. This allows the RFM69 to handle all the message processing itself, both transmit and receive, all you do is fill or empty the buffer at your leisure.