@BrianD
Missing from your diagram is where MartinR’s diverter’s dump load is fed from. That information is crucial.
Previously Brian had said it they were both from the house CU.
1 Like
Maybe this might help clarify the type 1 vs type 2 (and an un-mentioned possible 3rd type)
| Grid CT | Solar CT | Use CT | and | |
|---|---|---|---|---|
| "Type 1" | no | yes | yes | Grid = Use - Solar |
| "Type 2" | yes | yes | no | Use = Grid + Solar |
| 3rd Type | yes | no | yes | Solar = Use - Grid |
(I hope that’s all accurate I just knocked it up quickly to demonstrate the “2 of 3” rule)
Until the consumption of the dump load is known by some means so that it can be subtracted from the power available to the EV, then it’s going to be difficult if not impossible to have a stable system where the priorities can be controlled.
“by some means” can be by a direct measurement or, if Martin’s diverter is working as per his original design (not the published sketch) and the diversion is being overridden by temperature measurement so that the diverted power can be calculated (not possible if the immersion heater thermostat is the temperature control mechanism), then Martin’s diverter can send that data by radio to the Pi.
I have read all the above several times and it seems to me that a simple fact is being overlooked.
The MartinR diverter only applies its dump load when 2250 Joules of energy has fed to the grid.
If PV power is available but is all used by anything connected to Henley block 2 then no power is fed to the grid and MartinR remains OFF. This is what is intended by design and is what I observe during normal operation.
The discussion above appears to focus upon the interaction of the MartinR diverter and the load controlled by the emonPi. I would like to simplify the problem by starting with MartinR removed. During any testing I shall simply switch him OFF.
I hope to achieve the goal of regulating the power flow to the EV based on the simple rule of:
EV = PV – H2
Where EV is power diverted to the car via OpenEVSE
PV is power from solar
H2 is power to Henley block 2 as measured by CT4
The emonPi has access to both PV & H2 is capable of this simple arithmetic my problem is that I don’t know how to do it.
This part would have worked fine with the original Henley block arrangement as it was so that H2 doesn’t include EV because to expand your equation above it would become
EV = PV – (House CU + EV)
when in actual fact it should be
EV = PV – House CU
As the HB’s were (EV on HB1), then yes CT4 can be used directly to ascertain the available power for EV charging which is what I’ve been saying,
Originally 8 days ago on the other thread
. . . and in this thread 3 days ago
Alternatively you could move CT4 to between HB2 and the house CU or maybe some form of feedback value could be used, for example available for EV = PV – (HB2 - used by EV). Whether the EV is removed from the “normal use” by changing the wiring, moving the CT or in the maths, EV must be removed from the basic PV - USE equation.
Otherwise when there is 2KW of spare PV the EV will be told to use 2kW at which point there is no spare PV so the EV will be switched off and then the 2kW spare reappears so the EV is told to use the 2kW etc etc etc
Do you agree with this part before we reintroduce the diverter?
[edit] Looking closer at the diagrams, moving the CT not the wiring seems the easy choice, the change of diagram style confuses comparison between what you had originally and what you have now.
Yes indeed I have always agreed with what you are saying. My first post in this thread was seeking to achieve the same thing but by a different method.
If I move CT4 between Henley 2 and the house CU the emonPi will have the information required to calculate surplus PV (EV = PV – CT2) However, the power consumed as displayed and recorded on emoncms will not include the EV.
If we leave things as shown on version 6 of my drawing let’s consider what will happen if as the system operates.
Where EVm = EV measured
EVc = EV control level
House = House CU load
Assuming that the command sent to EV will be EVc = PV – (House + EVm)
Initially EVm = 0 therefore the calculation will result in EVc = (PV – House)
Some short while later as the OpenEVSE ramps up the value of EVm will increase and consequently will effectively apply negative feedback by reducing EVc which should prevent overshoot. The inherent delays in this should result in a damped control system which will not oscillate up and down.
I am very happy to try this but I don’t yet know how to do it. If you could please give me an example I would be delighted to try and report back the result.
I thought you may like to see the following graph. It shows the system for today 26/08/2019 with the wiring as detailed in the Version 6 drawing.
Just before 10:00 you can see MartinR diverting power as expected until I enabled the car to charge which happened to coincide with my wife switching on a 3kW load. After that the consumption curve is correctly showing the power diverted to the car plus the house base load. You can see the car taking more power as the sun comes up and in the late afternoon reduces to 2kW as it is designed to do. The spikes are the inevitable cups of tea.
The drop to zero at around 11:00 was me interfering.
The reason to post this is simply to show how well the OpenEVSE is working. Sorry if this is all old news to you.
1 Like
It may help if I backtrack a little and explain why I am having such difficulty making progress.
I am using a Win 10 desktop machine to access my emoncms configuration via https://emoncms.org This allows me to view graphs and configure the system using Inputs and Feeds.
In addition, I can access the emonPi directly from the desktop machine using the local IPA of 192.168.1.85 where I can also configure Inputs and Feeds as required.
Thirdly, I can access emoncms via an app on IOS where once again I can configure Inputs and Feeds.
I don’t understand which of these has priority, if I try to add some simple arithmetic function in the control loop which should I be tinkering with?
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.
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.
Trying to get more data available for processing. If the emonPi could receive the payload from your diverter it gives us
- The option to use the emonPi CT’s for other things rather than duplicating data you already have on tap
- A far more accurate tracking of Grid and PV because the diverter is continuous sampling.
- An additional “ext_divert” metric that might be useful
- 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?
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
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.
The local DHW tank directly controlled by MartinR plus all power and lighting circuits for the house
See Remote diverter code linked above. It is a 3kW immersion heater.
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.
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)
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.
- The emonEVSE monitoring data only updates every 30s
- The emonEVSE “power” is estimated by multiplying the current by a fixed voltage and PF 1.0
- 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.
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
}
}