Support

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.

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.

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.

I was able to set this up via NodeRed and MQTT. It wasn't wildly difficult and it's been simplified in the most recent EVSE firmware. Basically each EVSE sends out current consumption, and my NodeRed flow subtracts that from available power and shares it to all EVSEs. The only problem I've found is that the EVSEs occasionally lose their connection to the MQTT server (it seems to coincide with a UniFi firmware update) and that "kills" all EVSEs until you restart the WiFi.

NodeRed also helps me here in that it will check for lack of heartbeat over MQTT, and hit the API to restart the wifi server if it doesn't get a heartbeat. This works about 90% of the time.

If you know Python you can probably figure out NodeRed and MQTT. I run everything off an unraid box using docker containers which lets you do a whole bunch of other fun stuff and in this case, could probably run off a Pi or similar.

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.

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.

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.