Archived Forum

Do we need two alternative kWh/d feed processes to correctly track import and export?

It should decrease and eventually go negative if net is exported.

It calculates the kwh increment from from the last measurement by multiplying the power by the time at that power. So if the power is negative the kwh increment will be negative and will subtract from the kwh figure stored up to that point.

Do your kwhd bars decrease at all when the sun is out and your consumption is less than gen?

Yes, I have several days graphed with kWh as negative values (generation was indeed higher than consumption). I don't find this terribly intuitive as it doesn't tell me what my import and export values were.

Can we track grid import and export separately with emoncms?

Do you have an input for solar PV gen and an input for grid import/export?

Yes, Power1 is grid import/export, Power2 is SolarPV gen

Great, ok just written a section here to go through the input processing setup steps: http://openenergymonitor.org/emon/applications/solarpv/emoncms Let me know if I can clarify further.

Yeah, that's pretty much identical to how I have it set up. But, it doesn't log my import and export values for the day.

If I generate 15kWh from solar PV, and use 13kWh over a day, this will report my consumption as -2kWh, This doesn't account for anything I've imported at night, when the solar PV isn't generating. What I want is to track what I've imported and exported, perhaps a kWh/d process that only increments on negative values and another kWh/d that only increments on positive values.

Maybe this is off topic, but is there a way to "reset" the total kWH value?

Meaning, starting over?

Thanks

 vworp: ah ok yes that would need a new input processor. I will see if I can implement it.

rechena: do you mean resetting the daily kwh or the result of the power to kwh processor?

Trystan: Power to kWh a new fresh start :)

 I have been trying to do the same as vworp (show import and export totals separately for a period) and came to the conclusion that it is not currently possible or there was something wrong with my algebra skills, so I was wondering if you had made any progress on the new input processor - I know you are busy.

As an alternative I was going to modify the code that is in the emonglcd that determines the showing of the text importing/exporting, put this on the emontx or emonbase and create two extra inputs for emoncms.

The grid figure would be passed to two inputs for emoncms, named as 'import' and 'export', each having a value assigned for each sending of the data. If the grid figure is negative, then the value, unsigned would be passed to the export input for emoncms and the import input passed would be set at zero. If the grid figure is positive then the value would be passed to the import input for emoncms, and the export input passed would be set at zero. Within emoncms the input processing would then be straight forward.

Any comments on the viability of this approach would be welcome in case I have missed something in my logic.

Trystan,

I've revisited this in the last week or so, and tried to add import and export values to my history page on the GLCD. It doesn't work for some reason, just makes the GLCD hang.

I've manually pasted my alterations to https://github.com/vworp/EmonGLCD (git utterly refuses to work on my machine at the moment).

Rough gist, I've added calculations for wh_import and wh_export to power_calculations() (filling the array is currently commented out) and an extra column to draw_history(). With everything commented out apart from the wh calculations, my GLCD hangs. I'm not sure what's going wrong here, any chance you can have a look see if anything stands out?

Any movement on the new input processor for emoncms?

I've added the code to my emonbase sketch following the descrtiption in my earlier post. Posted to emoncms as powerexport and powerimport. Using 'power' in the name means autoconfigure inputs works on emoncms. If you would like to see the result please go to my dashboard emoncms.org/joseffh. I'll post the code snippet later.

vworp,

I know your (old) code is using nearly all the available memory, is the stack overflowing? I'm not well conversed with the details so you need to research and check.

(Note: by writing the history within a loop and calculating the screen positions rather than hard coding each, you can save a few hundred bytes which should help).

OK, here is the little bit of code I have added to the emonbase sketch to calculate a separate power import and powerexport value to send to emoncms. Code is adapted from that used in the emonGLCD sketch.

first before the 'SETUP section

double consuming, gen, grid;
int powerexport, powerimport;

then the On RF receive section has an addition

  //-----------------------------------------------------------------------------------------------------------------
  // 1) On RF recieve
  //-----------------------------------------------------------------------------------------------------------------
  if (rf12_recvDone()){      
      if (rf12_crc == 0 && (rf12_hdr & RF12_HDR_CTL) == 0)
      {
        int node_id = (rf12_hdr & 0x1F);
        
        if (node_id == 10)                                               // EMONTX
        {
          emontx = *(PayloadTX*) rf12_data;                              // get emontx data
          Serial.println();                                              // print emontx data to serial
          Serial.print("emonTx data rx");
          last_rf = millis();                                            // reset lastRF timer
          
          delay(50);                                                     // make sure serial printing finished
          
          //import or export calculation
          
          gen = emontx.power2;   if (gen<15) gen=0;     // set minimum threshold for generation to be recorded  
          consuming=gen + emontx.power1;             
          grid=emontx.power1;  
         
          if (gen > consuming)                          // if more is being generated than consumed then there must be an export
          {
            grid= grid*-1;                              // changes the export to a positive value
            powerimport=0;                              // as power is being exported power being imported must be zero
            powerexport=grid;                     
          }
          else
          {
            powerexport=0;
            powerimport=grid;
          }

And finally in the JSON creation

str.print(",power2:");        str.print(gen);        // Add power reading
          str.print(",power3:");        str.print(emontx.power3);        // Add power reading
          str.print(",powerexport:");    str.print(powerexport);
          str.print(",powerimport:");    str.print(powerimport);

I was going to give this mod a go, but I'm having problems with the current NanodeRF sketch.

http://openenergymonitor.org/emon/node/1079

Now that the dhcp issues have been resolved and I have a working Nanode again, I've had a go at this patch. It works great with the minor niggle that it seems to break the JSON string when a temperature reading from the GLCD is present. I'm thinking that the extra import and export values are pushing the str.print over length. I'll have a look later and see what can be done.

If anyone else wants to try this fork, it's pretty up to date with the master branch:-

https://github.com/vworp/NanodeRF

I've tweaked my fork so the JSON string isn't truncated when the GLCD temperature is added to it.

Question for Trystan and Glyn:- I like the idea of having import and export calculated on a base unit rather than in emoncms. If the multinode sketch is the way forward, might it be better to add this calculation to emonTX?