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.
I've been thinking about doing a similar thing as a long term project. My current setup has the OpenEVSE limited to 16 amps (230 volts). My next car will be able to use 32 amps. Our house has a single phase connection limited to 63 amps.
My plan is to place a current sensor on the house feed and based on the reading from this reduce the current available to the car that results in the house load staying at or below 60 amps.
I would have the OpenEVSE setup so that when first powered on the car would not charge (or would charge at a very low rate if I couldn't stop the charging).
To do this I'd use a microcontroller and control the OpenEVSE via RAPI commands.
You could do a similar thing using a microcontroller and two OpenEVSE with built in current sensors.
With the WiFi board you could use MQTT to publish energy stats for both boxes. The logic could be created in NodeRED and fed back into OpenEVSE using the Solar Divert feature. The Solar Divert is really just an "Available power" input.
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.
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,
Heartbeat supervision is implemented in the latest development firmware
with a RAPI command SY:
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
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.
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.
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.
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.