21

Apologies for the absence, I’ve not been around much the last few days . I’ve just got in and hoping to eat before hitting the road again in an hour so I’m just posting to say I haven’t abandoned you, I am trying to get to answer your points above. However please don’t invest too much time into it just yet as although that first part is doable, your way is more complex and less accurate than it should be, plus I was going to go on and explain why the diverter (in it’s current configuration) will not play ball with the first part.

Did you find out the info on the diverter payload? group, node id and whether it is in range of the emonpi?

Very quickly regards you last post. emoncms.org is just a hosted version of emoncms that you have on the emonSD. They are different accounts and work independently of each other so if you want to maintain data at home and on the emoncms.org siter you will need to set up the input processing, feeds and dashboarde etc on both accounts. You can send to many different emoncms accounts, both local and remote via emonhub. Your iOS app will be working with which ever host you configured it to point at. You can make changes at any emoncms account via any browser on any machine or via andoid or iOS, the client is immaterial to the host account.

If you want to make things simpler for yourself to begin with, try to use just one host rather than both (or more). Although you can use either to monitor, you would neeed to use the local emoncms if you want to control your EV. AFAIK you cannot do that from emoncms.org (I’m sure someone will correct me if that’s not the case).

I will try and find some time to continue but I’m not sure when that might be exactly, I’ll probably be shattered later and it’s not really a 2min job.

22

Paul please don’t put yourself under pressure on this. I am very happy with the way things are currently working but of course the addition of full power regulation will make things even better.

I am not sure where you are going with the questions regarding the MartinR diverter but to answer here are some code snips:

typedef struct { int power1, power2, power3, Vrms, temp, frequency1, ext_divert; } PayloadTx;

PayloadTx emontx;
// transmit data via the RFM12
void rfm_send(byte *data, byte size)
{
  byte i=0,next,txstate=0;
  word crc=~0;
  
  rfm_write(0x8228); // OPEN PA
  rfm_write(0x8238);

  digitalWrite(RFMSELPIN,LOW);
  SPI.transfer(0xb8); // tx register write command
  
  while(txstate<13)
  {
    while(digitalRead(SDOPIN)==0); // wait for SDO to go high
    switch(txstate)
    {
      case 0:
      case 1:
      case 2: next=0xaa; txstate++; break;
      case 3: next=0x2d; txstate++; break;
      case 4: next=0xd2; txstate++; break;
      case 5: next=10; txstate++; break; // node ID
      case 6: next=size; txstate++; break;
      case 7: next=data[i++]; if(i==size) txstate++; break;
      case 8: next=(byte)crc; txstate++; break;
      case 9: next=(byte)(crc>>8); txstate++; break;
      case 10:
      case 11:
      case 12: next=0xaa; txstate++; break; // dummy bytes (if <3 CRC gets corrupted sometimes)
    }
    if((txstate>4)&&(txstate<9)) crc = _crc16_update(crc, next);
    SPI.transfer(next);
  }
  digitalWrite(RFMSELPIN,HIGH);

  rfm_write( 0x8208 ); // CLOSE PA
  rfm_write( 0x8200 ); // enter sleep
}

The emonPi is inches from the MartinR diverter antenna but it will not decode the UHF TX signal easily.

I am very happy to use only the local emoncms to control the OpenEVSE

This page of the guide has me very puzzled:

https://guide.openenergymonitor.org/integrations/evse-setup/#emoncms-server-setup

This image shows how to add a ‘Publish to MQTT’ process but try as I may there appears to be no such option in my setup.

process_list
process_list856×407 55.7 KB

23

Trying to get more data available for processing. If the emonPi could receive the payload from your diverter it gives us

  1. The option to use the emonPi CT’s for other things rather than duplicating data you already have on tap
  2. A far more accurate tracking of Grid and PV because the diverter is continuous sampling.
  3. An additional “ext_divert” metric that might be useful
  4. Apparently a 3rd CT channel is available too, so you could have 5 CT’s available!

Why do you say that?

This is what the [nodes] definition could look like in emonhub.conf

[[?]]
   nodename = MartinR_diverter
   [[[rx]]]
      names = grid, solar, power3, vrms, temp, freq, ext_divert
      datacodes = h,h,h,h,h,h,h
      scales = 1,1,1,0.01,0.01,0.01,1
      units = W,W,W,V,C,Hz,W

I would need to check the scale for freq, I’m working from memory and IIRC the temp and voltage are to 2 decimals.
The question mark is because you still haven’t told us the diverters node id and group! If the group isn’t 210 then this line in the [[RFM2Pi]][[[runtimesettings]]] section of emonhub.conf will also need editing to whatever group the diverter is using.

If the group is 210, then there is a strong chance that your emonpi is already receiving the MartinR diverter data but discarding it because the payload doesn’t fit one that is already defined with the same node id. I suggest looking at the emonhub logs (from the emoncms config page on the emonPi?) to see if there are any messages to that effect.

Are you looking at the local emoncms? It is there by default on an emonPi/SD image but not available on emoncms.org.

[edit] Also what is the update frequency of the diverter? And what else is on the same circuit from the House CU as the remote diverter load?

Can you also confirm what “ext_divert” is exactly? is it just the remote load? Is it switched by another switch eg a thermostat? or does it accurately reflect the actual use rather than available to use?

24

To avoid clutter I shall respond to your questions with more than one post.

The question mark is because you still haven’t told us the diverters node id and group!

I believe the node id is case 5 of the switch statement in my last post:
case 5: next=10; txstate++; break; // node ID

So 10!

The group definition is probably in here somewhere:
rfm_write(0x0000); // clear SPI
rfm_write(0x80D7); // EL (ena dreg), EF (ena RX FIFO), 12.0pF
rfm_write(0x8208); // Turn on crystal,!PA
rfm_write(0xA640); // 434MHz
rfm_write(0xC606); // approx 49.2 Kbps, as used by emonTx
//rfm_write(0xC657); // approx 3.918 Kbps, better for long range
rfm_write(0xCC77); // PLL
rfm_write(0x94A0); // VDI,FAST,134kHz,0dBm,-103dBm
rfm_write(0xC2AC); // AL,!ml,DIG,DQD4
rfm_write(0xCA83); // FIFO8,2-SYNC,!ff,DR
rfm_write(0xCEd2); // SYNC=2DD2
rfm_write(0xC483); // @PWR,NO RSTRIC,!st,!fi,OE,EN
rfm_write(0x9850); // !mp,90kHz,MAX OUT
rfm_write(0xE000); // wake up timer - not used
rfm_write(0xC800); // low duty cycle - not used
rfm_write(0xC000); // 1.0MHz,2.2V

The remote diverter I wrote monitors the TX from MartinR and uses this:

#define freq RF12_433MHZ // frequency - match to same frequency as RFM12B module (change to 868Mhz or 915Mhz if appropriate)
#define group 210 // network group, must be same as emonTx and emonBase
#define MYNODE 20 // In case we want to transmit
#define ON_time_limit 5000 // Maximum ON time duration difference between two ON commands
25

The remote diverter does not have a fixed update frequency. The best way to explain this is to provide the source code which is quite small.

Remote diverter

26

The local DHW tank directly controlled by MartinR plus all power and lighting circuits for the house

27

See Remote diverter code linked above. It is a 3kW immersion heater.

28

Being too close could be a problem with overloading.
If your emonHub settings (NodeID & payload) are correct, it might be worth turning down the transmitter power to see if that improves reception.

[Edit]
rfm_write(0x9850); // !mp,90kHz,MAX OUT
controls the output power.

The least significant 3 bits define the output power: 0x9850 is maximum, to goes down in steps of 2½dB to 0x9857 which is 17.5 dB below maximum.

29

My bad! I missed that.

and the group is 210 as defined in this snippet of the remote code

So your diverter data should be visible in emoncms but perhaps unrecognisable? because the current “node 10” definition in emonhub.conf [nodes] is

[[10]]
    nodename = emontx1
    [[[rx]]]
       names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacode = h
       scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
       units =W,W,W,W,V,C,C,C,C,C,C,p

do you have a “emontx1” showing up in emoncms? Try commenting out the current node 10 definition and adding the correct definition, so the bit shown imediatly above should be replaced with

#[[10]]
#    nodename = emontx1
#    [[[rx]]]
#       names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
#       datacode = h
#       scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
#       units =W,W,W,W,V,C,C,C,C,C,C,p
[[10]]
   nodename = MartinR_diverter
   [[[rx]]]
      names = grid, solar, power3, vrms, temp, freq, ext_divert
      datacodes = h,h,h,h,h,h,h
      scales = 1,1,1,0.01,0.01,0.01,1
      units = W,W,W,V,C,Hz,W

Or you can post your emonhub.log and emonhub.conf for us to check first. There should be some evidence of your diverter trying to post.

I wasn’t asking about the remote, I was asking at what update interval the main diverter transmits it’s data (for the emonGLCD’s) ie how often is rfm_send() called?

No, that doesn’t sound right at all. from the house CU to the remote diverter load. The lights and sockets and main diverter will be on different circuits from the house CU, what else is on the circuit/wiring from the House CU to the remote diverter?

Again, I wasn’t asking about the remote diverter here, I was asking what the “ext_divert” value is in the main diverter payload.

I have also uploaded your remote sketch here rather than rely on a 3rd party site
remote_energy_diverter.ino.txt (8.3 KB)

30

In fact this would be the better option, by far. You need the consumption value without EV to drive the EV charger and you want the value with EV to report what your total energy use is, whichever way you do it you need/want both.

I previously noted 3 options, move the CT, change the wiring or (as a last resort or actually more just to confirm it is indeed possible to a degree) using a feedback value. Either of the first 2 are equally ok, the latter (your preferred choice) is flawed for a a couple of reasons.

  1. The emonEVSE monitoring data only updates every 30s
  2. The emonEVSE “power” is estimated by multiplying the current by a fixed voltage and PF 1.0
  3. Adding in EV and removing it again isn’t a “clean” way of doing things.

By keeping it simple with CT4 on the House CU (with NO EV) and subtracting that from solar you are subtracting one measured value from another measured value with no reliability on any sums or complex processing, it is just 1 CT minus another CT, both are updated at the same frequency and both are real power measured the same way.

This gives you an accurate “excess pv” value to base your EV control on, then you can simply add the “EV power” reported by the emonEVSE to the House CU CT for your overall power usage data. This way only your EV consumption (and total consumption incl EV) are less accurate due to the lower EV power accuracy. The House consumption and EV control will be much more accurate this way.

You can alter the EV monitoring processing to use the emonpi vrms to give a more accurate apparent EV power, that will improve the EV power accuarcy significantly but still assume a PF of 1.0, I do not know how realistic that is, but if the EV charges at a fairly constant PF that too could be adjusted to give a better representation of realpower perhaps. But non the less, it is far more accurate to use the methos above for the control, then add our best effort at EV power rather than use less than ideal values in complex processing for the EV control when a clean, simple and accurate method is easily available with no downside.

Although I have to point out this is a little academic at this point because the diverter is still the spanner in the works. Or more accurately, the in ability to monitor the diverter load separately is the spanner in the works, the diverter will do it’s job, too well perhaps, causing the EV to wait. But I will move on to explain that in more detail in another post.

31

It’s the same thing. MartinR sends commands aperiodically rather than a fixed frequency.
void loop()
{
if(newCycle)
{
addCycle(); // a new mains cycle has been sampled

/*
 Check if a command to the remote energy diverter is required
 If it is then sendResults must be called early with the required parameter in emontx.ext_divert
*/

if(external_divert_change == 1) // Check for a change of state
{
 sendResults(); // Update the remote controller
 external_divert_change = 0; // Remember not to do this again
}

}

32

Ahh terminology confusion. There are 5 cunsumer units in my building. You are refering to a ring main not what I refer to as a consumer unit circuit.

The ring main which supplies the remote diverter also carries a freezer and fridge plus a bunch of sockets. This ring main is connected to the house CU.

33

Ok, this confirms my suspision, I had guessed that was the reason for the remote diverter but just wanted to check rather than assume we couldn’t get a CT on at the source end of the remote diverter loads wiring.

Your diagrams just show 3 CU’s and you previously said

so I have to ask, is the main diverter wired directly to the house CU or does that go to another CU?

I’m not sure it is. Going by what you replied in your last post alone, that would suggest that the emonGLCD’s are static all night, the vrms, grid, solar and freq do not get updated again until such time as there is sufficient excess PV for the remote load to be activated again. I doubt this is the case, I expected the MartinR diverter to continue transmiting the

typedef struct { int power1, power2, power3, Vrms, temp, frequency1, ext_divert; } PayloadTx;

payload at fairly regular intervals. Looking at the beginning of the remote sketch there are these comments

     An associated master dump controller sends periodic data blocks to wireless display units called emonGLCD
     These data blocks contain a control parameter emontx.ext_divert which is used by this code to control the state of a triac
     which is connectd to an additional dump load.
     
     Data packets are sent every few seconds but this is too slow for an energy diverter so the master sends an extra packet
     immediately when a change of state is required in the remote triac.
     The logic of this code is:

I was asking about the data packets that are sent every few seconds to the emonGLCD not the extra packet that is sent on a change of state. IIRC the original MartinR code sent every 5 secs, but also IIRC this was actually timed from the mains cycles detected, not an absolute “5 secs” but 250 mains cycles.

Do you have a “node 10” at emoncms.org or “emontx1” showing up on your local emonpi emoncms?
Have you edited emonhub.conf as I suggested above?
Have you checked emonhub.log for a node 10?
If there is no sign of it can you check “quiet = False” is set in emonhub.conf [[RFM2Pi]] [[[runtimesettings]]] and check again?

34

inputs_01
inputs_011358×937 103 KB

Log file below:

emonhub_log.txt (1.6 MB)

35

Both the main dump load and the remote dump load are connected to the house CU but they are not on the same ring main or MCB.

36

Emonhub config file:
emonhub_config_29082019.txt (7.5 KB)

37

So in your conf file there is this section

[[10]]
    nodename = emontx1
    [[[rx]]]
       names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacode = h
       scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
       units =W,W,W,W,V,C,C,C,C,C,C,p

and that is trying to decode your diverter and not getting it right because it is defining a emontx payload. A emonTx used to use node 10 by default. So the “[[10]]” must be reused,

The nodename= can be anything you like that is unique and no special chars etc hyphens and underscores, eg “DHW-Diverter”, “SolarDiverter”, MartinR_Diverter etc etc

The names, datacodes, scales and units should all reflect the 7 integers in your diverter payload like so.

[[10]]
  nodename = SolarDiverter
  [[[rx]]]
     names = Grid, Solar, power3, Vrms, Temp, Freq, ext_divert
     datacodes = h,h,h,h,h,h,h
     scales = 1,1,1,0.01,0.01,0.01,1
     units = W,W,W,V,C,Hz,W

The “datacodes=” line is important. In the original form of “datacode=h” would allow any payload of integers to pass, hence your 7 value payload was not rejected and only the first 7 names, scales and units were used of the expected 12 value emontx payload. A stricter check is prefered so by using “datacodes=h,h,h,h,h,h,h” we are defining that a payload must be exactly 7 ints long (14bytes). The reason this is important is because when your diverter starts controlling the remote load it will also use “node 10” but I do not know what that payload looks like, is it the same? If it varies it must be rejected so it doesn’t contaminate the data collected from the standard payload. It’s good practice to do it this way anyway.

Once you make the changes above to your emonhub.conf, you will see a new input created with your new name (SolarDiverter ?) and all the “emontx1” inputs can be deleted.

From this point forward you can use these values as your basic grid and solar values and we have 2 spare inputs on the emonPi for other things.

Is the 3rd input on the MartinR diverter functional if you plug in a CT?

How is the diverter priority currently configured in the MartinR diverter? Does the remote have a higher priority to the main diverter?

Would it suit you if the overall priority was remote diverter then EV then main diverter? I think that will be the best we can achieve without being able to monitor the remote load and it would be easy to achieve by simply putting a CT on the main diverter load.

There is a very slight chance we can possibly change the priority of the remote load using a fixed power value multiplied by ext_divert, but that may not be entirely accurate due to both the obvious variation ion load and also because if there is a thermostat at the tank end, even when the ext_divert is “1” the load maybe 0 watts if demand has been satisfied.

38

This is the schematic I made in 2012. I don’t remeber if I tested the third CT input but it is connected as shown.

emontx_controller_04
emontx_controller_046813×4800 733 KB

39

Yes the remote is the DHW tank and is therefore given highest priority. Tank 2 is full of radiator water and only receives power when the thermostat on tank 1 trips open.

40

That would be perfect!