Power factor on Emoncms from emonPi

I have emonPi installed with CT sensor and AC-AC adapter. Also I have local Emoncms up to date and running.
I would like to develop an application to determine individual or group electric consumptions identified by its nominal consumption and shifting phase. So I need both, real power and power factor to have a more accurate solution.
I know the emonlib library computes power factor, but I do not know how to publish this data into Emoncms. Like power, temperature, VRMS, etc, inputs in the emonPi node.
Is there any simple way to publish this data into Emoncms so I can save it into feed? So I could later export to CSV.
Although I have basic knowledge of programming I am not a programmer, so please consider explain with detail.

1 Like

The problem, which you’ve identified, is the information is available but it is not sent to emonCMS.

The solution is a little complicated:

  1. You must download from GitHub and edit the sketch that runs on the Atmega328P inside your emonPi to send those values.
  2. You must compile the sketch on the emonPi (or transfer the compiled sketch onto the emonPi) and load it into the Atmega328P.
  3. You must edit emonHub to accept the new values and send them to emonCMS.

1). The source file is here: GitHub - openenergymonitor/emonpi: Raspberry Pi Based Energy Monitor. Hardware, Firmware & related software for the PI.
You need to edit src.ino to add the things you want to send. Around line 133, you must name the new variables and add them to the data structure. You can choose your own names, I’ve added my suggestion in bold. You do not need both powerFactor and apparentPower, because powerFactor = realPower / apparentPower.

typedef struct { int power1;
int apparentPower1;
int powerFactor1;
int power2;
int apparentPower2;
int powerFactor2;
int power1_plus_2; int Vrms; int temp[MaxOnewire]; unsigned long pulseCount; } PayloadTX; // create JeeLabs RF packet structure - a neat way of packaging data for RF comms PayloadTX emonPi;

Next, you must assign the calculated values to those names. At around line 280, immediately after the line
you must add:
emonPi.apparentPower1=ct1.apparentPower; emonPi.powerFactor1=ct1.powerFactor*100;

And similarly for input no 2 (ct2), a little lower down the sketch.

2). Using the Arduino IDE, compile the sketch, you’ll need to check the Arduino documentation for your operating system to find out where it puts the compiled (.hex) file.
You load the compiled .hex file using the instruction here: EmonPi - OpenEnergyMonitor Wiki

3). Finally, you need to change emonhub.conf to make it accept the changes. When you have done that, the emonPi will again be recognised (it will disappear if you try it after you make the change above). Look at the comment at the top of the sketch. This gives the emohub.conf setup for the emonPi (Node 5) before you changed it. The four lines, names = …, datacodes = …, scales = … and units = … tell emonHub what is coming. You must add the new variables names etc (I have made them bold) in the correct places (there is a 1:1 relationship along the 4 lines):

    nodename = emonPi
    firmware = emonPi_RFM69CW_RF12Demo_DiscreteSampling.ino
    hardware = emonpi
       names = power1,apparentPower1,powerFactor1,
         power2,apparentPower2,powerFactor2, power1_plus_power2,Vrms, T1,T2,T3,T4,T5,T6,pulseCount
       datacodes = h, h, h, h, h, h, h, h, h, h, h, h, h, h, L
       scales = 1, 1, 0.01, 1, 1, 0.01, 1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
       units = W,VA,n, W,VA,n, W,V,C,C,C,C,C,C,p

We need a scale of 0.01 for power factor because we multiplied by 100 to send the value as an integer, here we convert it back to a decimal.
Make those changes in your emonhub.conf file.

I have not had time to test this, but it should be correct (someone who knows more will no doubt correct me if it is not).


Just to add another point to @Robert.Wall’s comments, once you have the modified sketch up and running on your emonPi you must avoid using the “update emonPi” button in emoncms as this will blindly install the current standard emonPi sketch, over writing your modified version.

A work around is to use the “wrong update button” ie use the “update RFM69Pi” button instead. This will try to use the wrong baud and fail to upload a firmware so your modified sketch remains intact.

Thank you very much for you answer @Robert.Wall. I’ve done what you explain with much detail and it worked! It’s been a while now since the power factor is been saved into feed. I really appreciate the time you spent writing the solution.
Best regards,

1 Like

Hey Robert,

Thanks for this, I’m planning to implement this weekend. Just out of interest, was there a reason for not passing these values to the CMS given the firmware is calculating them? Is there a bandwidth or speed issue or was it more to avoid confusing consumers?



I pass on that one. I didn’t decide what should be sent by default. Certainly, RF channel occupancy comes into the equation when many sensor nodes are operating, but then it doesn’t make sense to me to always send 6 temperatures, even when no temperature sensors are in use. And it doesn’t count inside the emonPi, except the sketch is a dead ringer for the emonTx sketch. I guess a standard was decided, and that’s that. But there’s absolutely no obligation on you, or anyone, to observe it. But do tell us if you ask questions, because we’ve moved from being a constructors’ site to plug-and-play, so we’ll normally assume you have the standard…

1 Like