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.

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.

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.

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.

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.