# OpenEVSE charge regulation – A possible improvement? **URL:** \ **Category:** OpenEVSE\ **Created:** [23 August 2019 11:47 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735 "2019-08-23T11:47:13Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [28 August 2019 15:43 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/21 "2019-08-28T15:43:54Z")
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](http://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](http://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](http://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. ---
**Author:** ![BrianD](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/briand/32/5022_2.png) [@BrianD](https://community.openenergymonitor.org/u/BrianD)\ **Post date:** [28 August 2019 17:36 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/22 "2019-08-28T17:36:45Z")
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. > [@pb66](#): > > Did you find out the info on the diverter payload? group, node id and whether it is in range of the emonpi? I am not sure where you are going with the questions regarding the MartinR diverter but to answer here are some code snips: ```auto 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](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](https://community.openenergymonitor.org/uploads/default/original/2X/2/22c19373d8bd2e23a73b3b88959d5fda321be25d.jpeg) ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [28 August 2019 19:01 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/23 "2019-08-28T19:01:22Z")
> [@BrianD](#): > > I am not sure where you are going with the questions regarding the MartinR diverter 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! > [@BrianD](#): > > The emonPi is inches from the MartinR diverter antenna but it will not decode the UHF TX signal easily. Why do you say that? This is what the [nodes] definition could look like in emonhub.conf ```auto [[?]] 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. > [@BrianD](#): > > 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. Are you looking at the local emoncms? It is there by default on an emonPi/SD image but not available on [emoncms.org](http://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? ---
**Author:** ![BrianD](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/briand/32/5022_2.png) [@BrianD](https://community.openenergymonitor.org/u/BrianD)\ **Post date:** [28 August 2019 19:52 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/24 "2019-08-28T19:52:41Z")
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! ```auto 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: ```auto #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 ``` ---
**Author:** ![BrianD](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/briand/32/5022_2.png) [@BrianD](https://community.openenergymonitor.org/u/BrianD)\ **Post date:** [28 August 2019 20:01 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/25 "2019-08-28T20:01:02Z")
> [@pb66](#): > > Also what is the update frequency of the diverter? 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](https://1drv.ms/u/s!AtcxErupGaCfgjxWmGYncNu0K9MH?e=PagkEP) ---
**Author:** ![BrianD](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/briand/32/5022_2.png) [@BrianD](https://community.openenergymonitor.org/u/BrianD)\ **Post date:** [28 August 2019 20:05 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/26 "2019-08-28T20:05:44Z")
> [@pb66](#): > > And what else is on the same circuit from the House CU as the remote diverter load? The local DHW tank directly controlled by MartinR plus all power and lighting circuits for the house ---
**Author:** ![BrianD](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/briand/32/5022_2.png) [@BrianD](https://community.openenergymonitor.org/u/BrianD)\ **Post date:** [28 August 2019 20:10 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/27 "2019-08-28T20:10:50Z")
> [@pb66](#): > > 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? See Remote diverter code linked above. It is a 3kW immersion heater. ---
**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:** [28 August 2019 21:23 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/28 "2019-08-28T21:23:07Z")
> [@BrianD](#): > > The emonPi is inches from the MartinR diverter antenna but it will not decode the UHF TX signal easily. 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. ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [28 August 2019 21:24 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/29 "2019-08-28T21:24:09Z")
> [@BrianD](#): > > 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! My bad! I missed that. and the group is 210 as defined in this snippet of the remote code > [@BrianD](#): > > #define group 210 // network group, must be same as emonTx and emonBase So your diverter data should be visible in emoncms but perhaps unrecognisable? because the current “node 10” definition in emonhub.conf [nodes] is ```auto [[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 ```auto #[[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. > [@BrianD](#): > > > Also what is the update frequency of the diverter? > > The remote diverter does not have a fixed update frequency. 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? > [@BrianD](#): > > > And what else is on the same circuit from the House CU as the remote diverter load? > > The local DHW tank directly controlled by MartinR plus all power and lighting circuits for the house 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? > [@BrianD](#): > > > 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? > > See Remote diverter code linked above. It is a 3kW immersion heater. 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](https://community.openenergymonitor.org/uploads/short-url/3OpVg8ebcgCNKUIP0xLjZCOtjX7.txt) (8.3 KB) ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [28 August 2019 22:00 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/30 "2019-08-28T22:00:15Z")
> [@BrianD](#): > > 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. 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. ---
**Author:** ![BrianD](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/briand/32/5022_2.png) [@BrianD](https://community.openenergymonitor.org/u/BrianD)\ **Post date:** [29 August 2019 06:39 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/31 "2019-08-29T06:39:19Z")
> [@pb66](#): > > 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? 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 } ``` } ---
**Author:** ![BrianD](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/briand/32/5022_2.png) [@BrianD](https://community.openenergymonitor.org/u/BrianD)\ **Post date:** [29 August 2019 06:45 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/32 "2019-08-29T06:45:54Z")
> [@pb66](#): > > 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? 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. ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [29 August 2019 08:37 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/33 "2019-08-29T08:37:41Z")
> [@BrianD](#): > > The ring main which supplies the remote diverter also carries a freezer and fridge plus a bunch of sockets. 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. > [@BrianD](#): > > There are 5 cunsumer units in my building. Your diagrams just show 3 CU’s and you previously said > [@BrianD](#): > > The diverters are both connected to the House CU so I have to ask, is the main diverter wired directly to the house CU or does that go to another CU? > [@BrianD](#): > > It’s the same thing. 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 ```auto 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 ```auto 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](http://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? ---
**Author:** ![BrianD](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/briand/32/5022_2.png) [@BrianD](https://community.openenergymonitor.org/u/BrianD)\ **Post date:** [29 August 2019 10:52 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/34 "2019-08-29T10:52:17Z")
> [@pb66](#): > > 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. ![inputs_01](https://community.openenergymonitor.org/uploads/default/original/2X/4/46ea45245e56b35c2ac9f942858d626fe2d467ec.jpeg) > [@pb66](#): > > 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 Log file below: [emonhub\_log.txt](https://community.openenergymonitor.org/uploads/short-url/b0t0S7WCYf1kAPwSKHQG3QGOxM4.txt) (1.6 MB) ---
**Author:** ![BrianD](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/briand/32/5022_2.png) [@BrianD](https://community.openenergymonitor.org/u/BrianD)\ **Post date:** [29 August 2019 11:16 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/35 "2019-08-29T11:16:30Z")
> [@pb66](#): > > so I have to ask, is the main diverter wired directly to the house CU or does that go to another CU? 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. ---
**Author:** ![BrianD](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/briand/32/5022_2.png) [@BrianD](https://community.openenergymonitor.org/u/BrianD)\ **Post date:** [29 August 2019 11:19 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/36 "2019-08-29T11:19:34Z")
Emonhub config file: [emonhub\_config\_29082019.txt](https://community.openenergymonitor.org/uploads/short-url/A9ZBMV09W7EXHwBOjLgucLZzHfz.txt) (7.5 KB) ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [29 August 2019 16:46 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/37 "2019-08-29T16:46:30Z")
So in your conf file there is this section ```auto [[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. ```auto [[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. ---
**Author:** ![BrianD](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/briand/32/5022_2.png) [@BrianD](https://community.openenergymonitor.org/u/BrianD)\ **Post date:** [29 August 2019 17:33 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/38 "2019-08-29T17:33:19Z")
> [@pb66](#): > > Is the 3rd input on the MartinR diverter functional if you plug in a CT? 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](https://community.openenergymonitor.org/uploads/default/original/2X/b/bbf991658feda1185d8fd43d896d51a2b7a6bd4d.jpeg) ---
**Author:** ![BrianD](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/briand/32/5022_2.png) [@BrianD](https://community.openenergymonitor.org/u/BrianD)\ **Post date:** [29 August 2019 17:35 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/39 "2019-08-29T17:35:52Z")
> [@pb66](#): > > How is the diverter priority currently configured in the MartinR diverter? Does the remote have a higher priority to the main diverter? 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. ---
**Author:** ![BrianD](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/briand/32/5022_2.png) [@BrianD](https://community.openenergymonitor.org/u/BrianD)\ **Post date:** [29 August 2019 17:36 UTC](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735/40 "2019-08-29T17:36:23Z")
> [@pb66](#): > > 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. That would be perfect! [Previous page](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735.md?page=1) [Next page](https://community.openenergymonitor.org/t/openevse-charge-regulation-a-possible-improvement/11735.md?page=3)