I suggest you read the comments I’ve made previously in other Topics about Github. I’ve no intention of wasting any more time on it.
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
On the face of it, it’s peculiar to your emonPi. Whether it’s a timing issue (mine is a 2B, slow) is open to question.
The bit that keeps emonLibCM data coming is the call to EmonLibCM_Ready(), after that it’s up to you to use the API to fetch what you like and leave out what you don’t.
I haven’t touched the RPi’s code, that’s Trystan’s domain. The only time the front end controls the display is at startup; or for commissioning when the display is showing the currents & power factors, which is turned on and off by the same configuration option that sends them to the Arduino IDE serial window via emonHub.
Further info - this happens each EmonLibCM_datalog_period, without fail.
Changing this changes the frequency of the pin tickle to match exactly.
So something weird is happening when this timer expires, tickling this PIN.
It’s a raspberry3b attached to it iff I recall, but I have no CTs attached (this is my test emonPi), so not sure if that makes any difference.
Down the rabbit hole we go…
It appears to be a problem in EmonLibCM_get_readings , specifically in the temp handling bit :
// Retrieve the temperatures, which should be stored inside each sensor
if (temperatureEnabled)
{
retrieveTemperatures();
}
With the above commented out, the Pi shutdown GPIO is not ticked every datalog_period, and the display is stable.
I guess I need to dust off my one-wire skills and see what’s going on there.
FOUND IT !
It seems that on the emonPi the OneWire bus is on Pin 4, not Pin 5 as on the EMONTX.
Pin 5 happens to be the shutdown pin on the emonPi. So everytime its doing a 1Wire read, it’s tickling the shutdown pin instead of the 1Wire bus pin.
The setup code appears to tell emonLIBCM to use Pin4, but it looks like it’s hard coded in emonLibCM.cpp line 255
// Temperature measurement
//
// Hardware Configuration
byte W1Pin = 5; // 1-Wire pin for temperature = 5 for emonTx V3, 4 for emonTx V2 & emonTx Shield
char DS18B20_PWR = -1; // Power pin for DS18B20 temperature sensors. Default -1 - power off
I’ll work up a fix.
That’s the default.
And it might help if you explained what you mean by “tickling”.
Tickling - changing the state, interfering with, upsetting, touching, electrically modifying.
Anyway, the problem is that in the code its running a 1W bus on the PI’s shutdown pin.
I’ve changed it to 4 and it works, but as emonLIB is shared across devices, I think you’re going to need to #define the value based on the device type. I can’t see how a variable will work as the 1W bus is created as part of the global variable initialisation here ::
// Global variables used only inside the library
OneWire oneWire(W1Pin);
After that is done, doesn’t seem it can be changed.
I’ll look when the present rush dies down. If what you say is correct, then it looks as if the fundamental problem is with the OneWire library, because surely it should be possible to write to a different pin on the fly? Maybe just a lazy “nobody should ever need to do that” thought when it was conceived?
My problem is that temperature measurement needs to be so closely bound to the timing of emonLibCM that it’s going to be very problematical possible to drive temperature measurement from the sketch.
Thanks Robert.
IMHO, you don’t want to ever start anything on the pi shutdown GPIO, even if you change it later on.
I don’t see any issue with your current temp readings in the sketch, it seems to work well. I didn’t look closely but I assume you are using 9bit resolution for quickest conversions. I may submit a small patch to emonLibCM to also cater for the DS2438 for temp readings. I have a bunch of them here and they are sold in RJ45 modular form as temp sensors:
This patch is in the normal emonLIB so makes sense to give CM the same capability for zero cost (all the differs is the Onewire Device ID and the call to get temp - trivial change).
Thanks for all your help with this, at last I’ve got RFM69 packets in my RF network and it all plays together happily with RF12, using the superior capabilities of the RFM69 node when possible. And CM to boot. Did you know the RFM69 has even got a built in temperature sensor ? Could make for a more power efficient emonTH but I suspect the days of those are numbered due to other solutions (BTLE etc.).
Off to wrap up my small changes to the Interfacers and emonGLCD code and post some merge requests.
Of course, I’m an engineer and I read data sheets. The problem with the OneWire stuff is I couldn’t find any useful data about the library. If that’s the only bug, I’m not too upset.
If you want changes made to any software released at the top of this thread, then this is the place to make the request, in plain English: What you recommend changing, what to and why. For the 3rd time, I don’t understand and don’t use Github.
Here is an updated emonLibCM with a very minor change.
I added #DEFINE that must be set if used on a EMONTX.
This was thought safer defaulting to pin4 as using on emonTX with the wrong pin will simply
mean a non-working 1-Wire bus, but on an EMONPI will cause spurious shutdowns.
emonLibCM.zip (135.9 KB)
I’ll look later, but my immediate thought is, can the OneWire library be modified to suit our usage, and is that a more sensible way to go about it? I’m thinking ahead to the new emonPi2 and emonTx V4.
As promised, here is EmonLibCM with support for the DS2438 sensor.
This brings EmonLibCM to feature parity with EmonLib in terms of one-wire. The conversion time for a DS2438 should be super quick as the config registers you write for the DS18B20 have the nice side affect of disabling all of the DS2438 other functions for current and voltage measurements (which aren’t used in the MS-T variant).
The changes to the code were minor, centered around the retrieveTemperatures() function which does a different temp calculation when a DS2438 is found. EmonLibCM_TemperatureEnable was also modified to permit DS2438 devices (id 0x26) into the temperatureSensors array.
Tested and working on my setup, appreciated very much if you would merge (if anything, to avoid me having to re-write the firmware every time emonPI is upgraded with my own binary).
I have a bunch of these that I use to measure temperature and possible other folks may have them as well.
EmonLibCM.zip (125.7 KB)