emonPi Problem after emonPi_CM/LPL firmware upgrade

[rupert]

An update. Summarizing:

My emonPi receives RF data from an emonTx3 and some emonTxShields (all using the Jeelink format ) via USB from an unmodified Jeelink USB module.

The emonPi also receives receives measurement data from the atmega328 add-on board - e.g. Vrms and temperature measurements, and LPL format RF data from an emonTx4 via the on-board RFM69.

The firmware of the atmega328 in the emonPi has been updated (1.1.4) to allow reception of the LPL format. Although this allows LPL reception. it has corrupted the data shown on the emonPi LCD - see:

Updating an emonPi to emonPi_CM

Looking more deeply in the forums, it seems that the need for a new emonHub node configuration for the emonPi_CM software has been found before by others, who have gone down the same path as I have - and has been solved with the help of @Robert.Wall . It seems that the node configuration that I used is not correct, and should be - [[5]] nodename = emonpi [[[rx]]] names = Msg, power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulse1count,pulse2count,E1,E2 datacodes =…

My problem:
Apart from the emonPi LCD problem mentioned above, the emonPi now regularly stops recording emonTx4 data, although the measurement data from the atmega328 sometimes continues, so the atmega328 is still working. The failure to reliably log data means the emonPi is unusable.

I also have an emonBase unit which receives the same data as the emonPi (LPL via the RFM69Pi, Jeelink via a USB Jeelink). It shows that the transmitted emonTx4 data is not dropping out. The emonBase is next to the emonPi so I don’t think it’s a signal strength issue. And the emonPi data dropouts didn’t start until I upgraded the emonPi to LPL and added the USB Jeelink.

When the emonTx4 data is lost, it disappears from the emonHub log.

Also when the emonTx4 data is lost, a lot of new spurious input nodes are often created. see

@Robert.Wall

I think you’ve stumbled across a newish “feature” which appears to automatically create a new input if it sees a problem with the incoming data, rather than junking the corrupted data.

Definitely one for @TrystanLea to solve.

At first I thought the the RFM69 on the emonPi was failing, but the problem can be fixed by halting the emonPi, and turning the power off and back on, or restarting the emonHub.

i.e. by going to
Setup / Emonhub /
and clicking the orange ‘Restart’ button at the top right of the page. This seems a reliable (!) way of getting all my logging going again after a stoppage. No full power cycle is necessary.

I am assuming that this means I have an EmonHub problem … perhaps …

Or is it possible that there are occasional collisions between USB and AMA0 data that are upsetting things?

Any thoughts? @TrystanLea