Suddenly death of RFM69PI receiver

Hardware RFM69Pi
21

Thanks for the update, Robert. As you say, Gareth only has emonTHs so he shouldn’t have any problems with two LPL receivers.

However my system had emonTX3s and emonTX4s, and with two LPL receivers the LPL acknowledgement / retry mechanism did seem to get confused. When I removed one of the LPL receivers, the lock up problems went away. This information may be useful for other users converting to LPL, and who have emonTXs as well as emonTHs.

1 Like
22

Having two distinct networks of emonTHs would only be a temporary solution whilst I migrate everything to use the LPL protocol. I have too many sensors for me to do it big-bang without risking either losing data (which would result in loss of control of the CH system) or running out of time.

1 Like
23

OK, my plan is:

  1. Examine each emonTH to see if I have any RFM12 senders (I’m pretty sure I haven’t as I recall holding off purchase of the first one because there was a hardware update in progress)
  2. Set up a temporary Pi running the LPL protocol and connected to my MQTT broker.
  3. Migrate sensors one at a time from the old Pi to the new.
  4. Once all are done, move the LPL board to the original Pi (because that boots from an SSD and has a LifePO4wered-UPS).
1 Like
24

Looks good! Hope it all goes well.
(N,B, the emonRFM69PI and RFM69SPI radio modules need different interfacers in the emonHub config)

25

OK, thanks, Robert. I’ve been doing some research into the differences, and I think I’ve got my head around it.

I’ll come back with any tips once I’ve completed the task in case anybody else comes across this thread.

26

Basically, has the I.C. got pins on 2 sides or 4?

27

No, not the hardware, the differences in the protocols. I’ve got it now.

1 Like
28

The last page of this document https://JeeLib Radios RFM69 Native.pdf (859.5 KB) (which Rupert has probably used in his forum posts) gives detail of the radio packet formats. When you study and compare them, all the problems arise from JeeLabs choosing a different position in the packet for the length of the message payload, compared to Hope when they designed the RFM69. If they had been the same, the compatibility problem would have been significantly reduced. I can’t blame JeeLabs, they got there first, with the RFM12B library; and Hope probably neither knew nor cared. But either way, it made it a pain for the users.

29

Thanks for that, Robert
All but one emonTH have now been migrated to use the LPL protocol and are operating normally. The one that isn’t just won’t work after being re-flashed.
It is an emonTH2, but it now does nothing with either protocol. I’ve set it to one side for now. I’ll revisit it tomorrow to try and find out what’s happened.

30

I got to the bottom of the non-working emonTH. All of the other units retained their assigned node number when I re-flashed them. This one adopted node 23 even though it had been configured to be 22.

I realized because the CH kept coming on in the night. When I looked at the sensor for the room demanding heat (each has its own virtual thermostat in Home Assistant), I noticed the temp was fluctuating between two levels every 30s or so. As the TH sensor only send every 60s I reasoned that two sensors were using the same node number. This was confirmed by removing the battery from one of them.

I’ve just re-configured the offending node and now all is well again.

2 Likes
31

For what it is worth, if you hadn’t found the problem, the number of emonTHs and NodeIDs would have been my first suggestion.

32

Good to hear that it’s all working now after the LPL update. Hopefully this should give reliable radio communication, especially assuming that you still have the same very good RSSI numbers that you had before.

I wonder if you will still have lock-ups and need your script?

33

Although your emonBase now has different receiver hardware - new RFM69SPI vs old RFMPI which may affect things …

34

We’ll see.
I’ve disabled the crontab entry for now.