After many more hours, I can confirm that TX and RX of RF69 format packets through your library works well from RF12 devices.
There is a bug in RFDemo ( I think somewhere in the rf12 init from EEPROM, but it’s a really weird one, and the offset is that it increments the Group by 1 vs what you told it via RF12_init). Anyway that is a digression.
However, I’ve uncovered an issue in emonPICM. Every 5 seconds or so it appears to ‘tickle’ the shutdown GPIO, this leads to the display showing ‘Shutdown ? Hold 5 seconds’, and it does this every 5 seconds, despite navigating away from that page of the LCD.
Investigation shows the shutdown GPIO is being invoked and detected by the emonPiLCD.py control through this code :
logger.info("Attaching shutdown button interrupt...")
try:
shut_btn = Button(17, pull_up=False, hold_time=5)
shut_btn.when_pressed = preShutdown
shut_btn.when_held = shutdown
The GPIO is being ‘tickled’ but not held for the 5 seconds that are needed to invoke shutdown, but this happens every 5 seconds without fail when running the CM firmware.
My investigation thus far shows it is somewhere in this block of code in the loop in emonPiCM:
if (EmonLibCM_Ready())
{
single_LED_flash(); // single flash of LED on local CT sample
emonPi.power1 = EmonLibCM_getRealPower(0); // Copy the desired variables ready for transmission
emonPi.power2 = EmonLibCM_getRealPower(1);
emonPi.power1_plus_2 = emonPi.power1 + emonPi.power2;
emonPi.E1 = EmonLibCM_getWattHour(0);
emonPi.E2 = EmonLibCM_getWattHour(1);
emonPi.Vrms = EmonLibCM_getVrms() * 100; // Always send the ACTUAL measured voltage.
if (EmonLibCM_getTemperatureSensorCount())
{
for (byte i=0; i< MaxOnewire; i++)
emonPi.temp[i] = allTemps[i];
}
emonPi.pulseCount = EmonLibCM_getPulseCount(0);
emonPi.pulse2Count = EmonLibCM_getPulseCount(1);
send_emonpi_serial(); // Send emonPi data to Pi serial using packet structure
if (EEProm.showCurrents)
{
// to show voltage, current & power factor for calibration:
Serial.print(F("|Vrms:")); Serial.print(EmonLibCM_getVrms());
Serial.print(F(", I1:")); Serial.print(EmonLibCM_getIrms(0));
Serial.print(F(", pf1:")); Serial.print(EmonLibCM_getPF(0),4);
Serial.print(F(", I2:")); Serial.print(EmonLibCM_getIrms(1));
Serial.print(F(", pf2:")); Serial.print(EmonLibCM_getPF(1),4);
Serial.print(F(", f:")); Serial.print(EmonLibCM_getLineFrequency());
Serial.println();
}
delay(50);
// Save energy & pulse count values to EEPROM
storeEValues(emonPi.E1, emonPi.E2, emonPi.pulseCount, emonPi.pulse2Count);
}
Commenting that out and all is well. Now, that block of code is the guts of the CM, so I really don’t want to go down that rabbit hole when the man who built if may know why this is happening.
Any ideas ?
Thanks
Alan
Those changes may (and likely) will necessitate changes in EmonHubOEMInterfacer.py, or even provision of another interfacer to talk to it. And that’s all fine.