Start a new topic

Circuit sharing

I have two EVs, and just finished assembling my second 40A OpenEVSE w/Wifi, but only one 50A circuit. I could run another circuit, but it's difficult and I'd rather not. Also, it's really not necessary, since even with two cars the circuit is idle the majority of the time.


I have an algorithm in mind for how to make two OpenEVSEs cooperate to avoid pulling more than 40A combined, while still allowing either to pull up to the limit when the other is idle, using only the RESTful RAPI interface, with no explicit coordination.


However, before I put too much time into testing the algorithm, I want to check to see if someone else has done this, and whether there is a better approach.


1 person likes this idea

My plan (and what I started to implement) was purely in-device, with the EVSEs connected directly to each other. I'll probably pick it up again in a couple of years if no one else builds it.

Yes, the easy "hack" would be to split the current limits so you never go over the 40A (on a 50A circuit) 80% limit. But if we wanted easy we wouldn't be using an OpenEVSE :-)


My plan is to have a "priority switch" in my HomeAssistant, and potentially maybe even a hardware switch of some sort that allows the user to set the priority charger.


I'll use MQTT and NodeRed to set the "priority" charge to the full 40A and then monitor load. If there's >6A of spare capacity, it will allocate that to the other charger (including a scenario where the "priority charger" is not being used, so the secondary charger would get the full 40A).


What I like about the heartbeat function is it provides a "failsafe" if you lose MQTT or wifi connectivity, as after the timeout period you reduce the risk of two EVSE trying to pull a full 40A and relying on the breaker to save the day. I lose MQTT about once every 2-25 weeks, and haven't determined if it's OpenEVSE, Mosquitto (my mqtt broker), unRAID, or something else that's triggering the loss.


The ideal scenario would be if multiple OpenEVSE could connect to each other and manage all this without a "middleman" like NodeRED in the middle, but I'll take the 80% solution at this point. I also use NodeRED to take the MQTT from OpenEVSE, massage the data a bit, and put it into an influx database so I can draw pretty graphs and calculate energy costs and other amusing but ultimately useless exercises.

So, I kind of dropped this. Not because it isn't a good idea or useful, but because I decided I didn't need it.  What I ended up doing was to configure one EVSE with a 35A limit and one with a 10A limit.  I plug the Tesla into the higher-amperage unit and the Leaf in the other.  This is enough that both of them always get charged as needed. I should use the past tense because my son who owned the Leaf moved out, so I currently only have one vehicle to charge.


When I get my Cybertruck (probably late next year), then I'll actually want both EVSEs to be able to share the available current without leaving any unnecessarily unutilized.

Heartbeat supervision has been added to the latest 4.0 Alpha firmware.


https://github.com/OpenEVSE/ESP32_WiFi_V3.x/issues/138


SY heartbeatinterval hearbeatcurrentlimit

 Response includes heartbeatinterval hearbeatcurrentlimit hearbeattrigger

 hearbeattrigger: 0 - There has never been a missed pulse, 

 2 - there is a missed pulse, and HS is still in current limit

 1 - There was a missed pulse once, but it has since been acknowledged. Ampacity has been successfully restored to max permitted 

 $SY 100 6  //If no pulse for 100 seconds, set EVE ampacity limit to 6A until missed pulse is acknowledged

 $SY        //This is a heartbeat supervision pulse.  Need one every heartbeatinterval seconds.

 $SY 165    //This is an acknowledgement of a missed pulse.  Magic Cookie = 165 (=0XA5)

 When you send a pulse, an NK response indicates that a previous pulse was missed and has not yet been acked
I'm interested in this as well. I recently ordered a second plug in vehicle and was hoping for a single EVSE with one 40/50A input and 2 outputs. I'm hesitant to allow the chargers to require a home server to determine charge control. This should all be able to be handled in the controller.

Any updates? Have my second charger in and lost mqtt again (seems to happen every couple months) so a “fail safe” is very much welcomed!

Any idea when we'll see the SY command implemented? It doesn't seem to be in 3.3.2 based on the docs (I'm on 3.3.1 so haven't verified but will update later).


That seems like it would be the perfect solution to building a fairly robust circuit sharing controller via MQTT while minimizing overload risk.

Such a cable between EVSE would not be problematic, I have two chargers, now there is a third one, they are all in one garage and I can connect them with a cable - but what next?
Anyone can help. I would like to share the connection between 3 chargers dynamically.


This could already be done just with MQTT, the problem is that there's a "failure scenario" where the MQTT server could set multiple EVSEs to more amperage than the circuit could handle if it lost connection before ramping one of them down. This could result in a best case of a flipped breaker, or a worst case of spark/fire.


The heartbeat seems like a smart way to avoid this since each EVSE will ramp down if it doesn't get a heartbeat. The ideal scenario would be having this functionality embedded into the EVSE firmware rather than relying on a "roll your own" on an external server, although the latter does give more options.


If it did go into firmware, having the ability to set the total available circuit capacity, and some sort of sharing percentage (e.g. should each EVSE get 50% of the available capacity, 60/40, or one gets max and the other gets like 6A) would be cool. It would be a differentiator if OpenEVSE leveraged its WiFi for this rather than needing a dedicated wire like the Tesla chargers.

So in terms of implementing load/circuit sharing I think this could already be done with MQTT control. Some kind of external "supervisor" would monitor each of the OpenEVSE's and set the max charging rate for each based on either a fixed total current (or perhaps solar export amount). Any current not being used by one EVSE could be allocated to another one (i.e. a vehicle that can only charge at a lower rate is plugged in). It could also send the heartbeat ampacity limit to begin with, so that current would drop back to 12A (for two EVSE's) or 18A (for three EVSE's) etc. 


I'm just thinking (out loud) about how this might be implemented without needing a seperate MQTT server, and if that is a good idea. It seems like a load sharing protocol might be required so the OpenEVSE's can talk between themselves. I suppose the other option is to run an MQTT server on the master OpenEVSE, but this seems a bit of an imposition. Given there is already some kind of integration into the emon ecosystem, perhaps this "supervisor" functionality really belongs there.

Heartbeat supervision is implemented in the latest development firmware 


https://github.com/lincomatic/open_evse


 with a RAPI command SY:


https://github.com/lincomatic/open_evse/blob/development/firmware/open_evse/rapi_proc.h


SY heartbeatinterval hearbeatcurrentlimit

 Response includes heartbeatinterval hearbeatcurrentlimit hearbeattrigger

 hearbeattrigger: 0 - There has never been a missed pulse, 

 2 - there is a missed pulse, and HS is still in current limit

 1 - There was a missed pulse once, but it has since been acknowledged. Ampacity has been successfully restored to max permitted 

 $SY 100 6  //If no pulse for 100 seconds, set EVE ampacity limit to 6A until missed pulse is acknowledged

 $SY        //This is a heartbeat supervision pulse.  Need one every heartbeatinterval seconds.

 $SY 165    //This is an acknowledgement of a missed pulse.  Magic Cookie = 165 (=0XA5)

 When you send a pulse, an NK response indicates that a previous pulse was missed and has not yet been acked


2 people like this
It seems like it's entirely possible with the hardware, but would require a bit of work on the software. I'd like a similar function. I'll happy with an external device working with the rapi. But I think it would be safest if communication is lost that it drops back to 6A with some built in capability.
I’m in a similar situation. Anyone have any good ideas? It would be nice if this ran on the OpenEVSE itself and allowed for a master/secondary configuration so you’d eliminate another component (mqtt server/micro controller) but I’m getting outside my depth here.

I figure this thread is already 1 year ago, but I'm facing the same requirements here... 2 EV and 1 40amps circuits. I already have an OpenEVSE for which I LOVE, handful of possibilities. As such, for 2 EVs (and 2 chargers), have you shared/documented your solution somewhere (ie GitHub)?

I initially thought about using a single charger but activated with RFID, but in the long run, it does not solve the situation.

Thanks in advance,

Yh.

Thanks Christopher.  I'll go read the MQTT code and see where I could hook in. That seems like a nice solution.


My basic idea was to have both devices query the other via RAPI to discover their current state and then "be polite", taking only what the other side isn't using (as evidenced by current limit) and voluntarily reducing their own current limit whenever the draw falls below, say, 80% of current current limit and the other EVSE is drawing > 80% of its current current limit. The 80% threshold seems to work pretty well in my experiments.


1 person likes this
Login or Signup to post a comment