@glyn.hudson - 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.
Since the fault occurred at the time of updating and was perfectly ok prior to that for some months, would it not prove useful to try a rollback on the firmware? Even if replacing all 4 emonTx’s does overcome this issue by chance it tells us nothing about why this has happened when updating. 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.
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,
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.
@jingy - Would you be willing and able to get ssh access to the command line to install a different firmware hex, with some guidance if needed?