# The emonPiCM

**URL:** <https://community.openenergymonitor.org/t/the-emonpicm/18173>\
**Category:** emonPi\
**Tags:** emoncms\
**Created:** [17 July 2021 21:51 UTC](https://community.openenergymonitor.org/t/the-emonpicm/18173 "2021-07-17T21:51:51Z")\
**Posts on this page:** 15\
**Page:** 3

<div class="post-metadata">

**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\
**Post date:** [12 August 2022 19:19 UTC](https://community.openenergymonitor.org/t/the-emonpicm/18173/41 "2022-08-12T19:19:49Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![alandpearson](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@alandpearson](https://community.openenergymonitor.org/u/alandpearson)\
**Post date:** [14 August 2022 20:02 UTC](https://community.openenergymonitor.org/t/the-emonpicm/18173/42 "2022-08-14T20:02:59Z")

</div>

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 :

```auto
   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:

```auto
  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

---

<div class="post-metadata">

**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\
**Post date:** [14 August 2022 21:08 UTC](https://community.openenergymonitor.org/t/the-emonpicm/18173/43 "2022-08-14T21:08:00Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![alandpearson](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@alandpearson](https://community.openenergymonitor.org/u/alandpearson)\
**Post date:** [14 August 2022 22:30 UTC](https://community.openenergymonitor.org/t/the-emonpicm/18173/44 "2022-08-14T22:30:26Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![alandpearson](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@alandpearson](https://community.openenergymonitor.org/u/alandpearson)\
**Post date:** [14 August 2022 22:49 UTC](https://community.openenergymonitor.org/t/the-emonpicm/18173/45 "2022-08-14T22:49:47Z")

</div>

Down the rabbit hole we go…  
It appears to be a problem in EmonLibCM\_get\_readings , specifically in the temp handling bit :

```auto
    // 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.

---

<div class="post-metadata">

**Author:** ![alandpearson](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@alandpearson](https://community.openenergymonitor.org/u/alandpearson)\
**Post date:** [14 August 2022 23:03 UTC](https://community.openenergymonitor.org/t/the-emonpicm/18173/46 "2022-08-14T23:03:56Z")

</div>

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

```auto
// 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.

---

<div class="post-metadata">

**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\
**Post date:** [14 August 2022 23:12 UTC](https://community.openenergymonitor.org/t/the-emonpicm/18173/47 "2022-08-14T23:12:55Z")

</div>

> [@alandpearson](#):
>
> it looks like it’s hard coded in emonLibCM.cpp line 255

That’s the default.

And it might help if you explained what you mean by “tickling”.

---

<div class="post-metadata">

**Author:** ![alandpearson](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@alandpearson](https://community.openenergymonitor.org/u/alandpearson)\
**Post date:** [14 August 2022 23:21 UTC](https://community.openenergymonitor.org/t/the-emonpicm/18173/48 "2022-08-14T23:21:37Z")

</div>

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 ::

```auto
// Global variables used only inside the library
OneWire oneWire(W1Pin);

```

After that is done, doesn’t seem it can be changed.

---

<div class="post-metadata">

**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\
**Post date:** [15 August 2022 08:32 UTC](https://community.openenergymonitor.org/t/the-emonpicm/18173/49 "2022-08-15T08:32:11Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![alandpearson](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@alandpearson](https://community.openenergymonitor.org/u/alandpearson)\
**Post date:** [15 August 2022 10:49 UTC](https://community.openenergymonitor.org/t/the-emonpicm/18173/50 "2022-08-15T10:49:43Z")

</div>

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:

> **[MS - T Temperature sensor](https://homechip.com/collections/1-wire-sensors/products/ms-t-temperature-sensor)**
>
> Description The temperature measurement is made with a DS-2438Z. The device is not calibrated, but empirical data shows it to be accurate within a few degrees of actual, with an operating range of -40C to +85C. Because the sensing device is partially...

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.

---

<div class="post-metadata">

**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\
**Post date:** [15 August 2022 11:02 UTC](https://community.openenergymonitor.org/t/the-emonpicm/18173/51 "2022-08-15T11:02:50Z")

</div>

> [@alandpearson](#):
>
> Did you know the RFM69 has even got a built in temperature sensor ?

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.

> [@alandpearson](#):
>
> post some merge requests.

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.

---

<div class="post-metadata">

**Author:** ![alandpearson](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@alandpearson](https://community.openenergymonitor.org/u/alandpearson)\
**Post date:** [15 August 2022 12:25 UTC](https://community.openenergymonitor.org/t/the-emonpicm/18173/52 "2022-08-15T12:25:18Z")

</div>

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](https://community.openenergymonitor.org/uploads/short-url/bEQkg1ARje5g1ejiaSQUS1rwHna.zip) (135.9 KB)

---

<div class="post-metadata">

**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\
**Post date:** [15 August 2022 19:08 UTC](https://community.openenergymonitor.org/t/the-emonpicm/18173/53 "2022-08-15T19:08:22Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![alandpearson](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@alandpearson](https://community.openenergymonitor.org/u/alandpearson)\
**Post date:** [16 August 2022 16:23 UTC](https://community.openenergymonitor.org/t/the-emonpicm/18173/54 "2022-08-16T16:23:19Z")

</div>

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](https://community.openenergymonitor.org/uploads/short-url/yXU7u7TQvSVizC5dMtxPYz8rZKG.zip) (125.7 KB)

---

<div class="post-metadata">

**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\
**Post date:** [20 January 2023 23:23 UTC](https://community.openenergymonitor.org/t/the-emonpicm/18173/55 "2023-01-20T23:23:40Z")

</div>



[Previous page](https://community.openenergymonitor.org/t/the-emonpicm/18173.md?page=2)