Emon TXs not updating after Emonpi update

[glyn.hudson]

Quick version:

Replacement emonTx units should not be required. I have identified an issue with the emonPi update (V2.7),

I have pushed a new update (V2.8) which should fix the issue. Run emonPi update to pull in and apply the latest firmware (V2.8).

Very sorry for the hassle. Please let me know how you get on.

---

The long version:

@pb66

The rollback from v2.6 to v2.5 was proven to resolve the “No RF” problems seen by some, but not all users. v2.7 reinstates those v2.5 to v2.6 changes without any confirmed fault or fix, as far as I can tell.

Well remembered. I am aware of the issue with V2.6, therefore V2.7 is based on V2.5, V2.7 has the same ‘RF keep alive’ as V2.5.

https://github.com/openenergymonitor/emonpi/blob/master/firmware/src/src.ino#L250

HOWEVER, V2.7 was compiled with the latest JeeLib while the last known RF stable firmware (V2.5) was compiled with JeeLib from 10th Sep 2015. I had tested V2.7 prior to release with all the emonPi’s and RF nodes that we have here in the lab and it worked fine. The only difference I can think is that the RF nodes here in the lab are mostly transmitting 0’s since they are not conected to anyting or just temperature values. The issue only seems to effect emonTx units which are monitoring multiple circuites i.e they will have large(er) RF packets.

For the latest firmware I have just pushed (V2.8) I reverted back to JeeLib from 10th Sep 2015. This fixed the issue, I was given remote access to an emonPi with a few emonTx’s connected monitoring multiple circuits which had stoped working using V2.7 started working again with V2.8 . Compiling the code using platformIO was super useful in the case since the library commit version can be specified in platformio.ini, this will ensure anyone who compiles the firmware will have exactly the same version.

https://github.com/openenergymonitor/emonpi/blob/master/firmware/platformio.ini#L37

As to why, the latest version of jeelib has got an issue with longer RFM packets, this is still a mystery. I will need to debug further.
emontx/2141?u=glyn.hudson&source_topic_id=2233

@pb66

For example the min RSSI threshold in emonlib has been tightened so if the emonTx signals where at the lower end of the range they may well just be excluded purely by the lib update and replacements may or may not pass that threshold or work for a while or even sporadically.

Interesting, when did this change take place. I can’t see any recent changes to RSSI threshold in emonhub commits.

@pb66

Even if replacing all 4 emonTx’s does overcome this issue by chance it tells us nothing about why this has happened when updating

My plan was to get hold of the emonTx myself for testing back in the lab. I was worried we could have a sub-optimal batch of RF modules. Maybe this will not be needed now.

@pb66

Could we also consider reinstating the “non-quiet” function in the emonPi FW? That way the emonhub.logs in the emoncms webpage could possibly shed significantly more light on this type of issue,

Yes, this is a possibility. What would require adding to the code for this? Do you have a working test?

@pb66

And maybe (on a future revision) the led on the emonPi could be made visible, either with just a well positioned hole in the end plate or replacing the SMT led with one that could over hang the board edge and protrude through a hole in the end plate ? The combo of no led and quiet function make it quite tricky to debug RF on an emonPi.

Mm this would be quite tricky. It would probably be easier just to remove the end-plate(s) of the emonPi to view the LED. Actually new versions of the enclosure in the future will have mounting holes for DIN rail mount therefore we might be able to see the LED through these holes