Power sharing

[kallisti5]

Fun idea. As more and more people begin to have more than one EV, OpenEVSE should look into powersharing.

Example workflow:

• Set a "main" OpenEVSE unit
• Other OpenEVSE units can "join" it creating a "pool" of OpenEVSE units
• A maximum service level can be defined for the pool (32A for example)
• OpenEVSE units take turns charging, or divide up the service (2 units charging, offer 15A each, etc)

For maximum flexibility, units should communicate to each other. While in pooled mode, loss of network connectivity means members refuse to charge.

There are safety concerns, so it would be best to set big overheads (for example, when sharing a circuit only use 80% of it, etc)

[KipK]

I don't think that it's evse job to handle a fleet, but more the task of an external service Wouldn't it be more appropriate to build a simple external load balancer script or using Hass/Jeedom/whatever ? There's an api for that on evse to use with.

[KipK]

Even just tricking max power used by Shaper would work nice I think Edit: I mean if you have 2 evse charging at the same time, just divide the max power by 2. If only one is charging then set it back to the real value.

But as in all case you'll have to script something out, I'd rather use either mqtt claim topic or api claim endpoint to set charge_current to what you want on each device instead of hitting the shaper max_power value that is written in flash

@kallisti5 you can also trick the mqtt live power topic by letting only half the power available: Live_pwr =Max_pwr - ((Max_pwr - RealLive_pwr)/numberOfEvse)

[fhteagle]

Doesn't OpenEVSE's OCPP implementation already handle this elegantly? Not sure as I have never used it myself, but...

https://www.chargelab.co/industry-advocacy/ocpp

[kallisti5]

Overall, OCPP does some of this as of OCPP 1.6+. However, all OCPP implementations seem to require a central server, database backend, account management, etc.

This all seems like overkill for just wanting two chargers to share a single source and balance.

I think requiring a central MQTT server or something might be an elegant (and less complex) method to get this... but with just MQTT it starts to get a little complex when you think through the interactions between OpenEVSE units. One would need to play leader to the rest.

[fhteagle]

This can definitely be done in HomeAssistant, as well. Let me know if you want to to go that route and I can probably get you through a recipe to do so.

[KipK]

Node-red could also fit well if you don't want to script something in Python or node.js

[chris1howell]

OpenEVSE has been capable of power-sharing for a very long time, it just takes a fair amount of technical knowledge to pull off.

Many of the big guys are offering simple power-sharing. Tesla offers up to 4 HPWCs connected vis RS485. Clipper Creak Share2 (unspecified 2 wire digital serial). Enel X offers Load Share Group functionality via Juice Net etc.

I think a some point, OpenEVSE needs to offer similar functionality without a complex external service/script.

IP Multicast would be a good way to exchange information, such as group name/ID, current pool size, number of stations, priority, heartbeat, station status, power consumed, loss comm safe rate, etc.

[KipK]

ArduinoMongoose has no udp server nor multicast ready yet I think.

But multicast won't be a solution here, there's cases where all OpenEvse won't receive the same commands, and it will be tricky to manage connection states over multicast.

-> we only have 12A available ( defined by Shaper or Divert ) for 3 openevse. We need then to only activate 2 of them at 6A and disable the third one instead of disabling everybody. ( thinking of that, how do we define priority rules ? ) -> perhaps some wants to charge full speed one EV first and then switch to the other one when done.

It needs coordinating each of them separately, http api could be use for that but a real sock connection should be better to handle connection states.

There's some setup to add:

• clients ip / pass on server side, or server ip / pass on client side, not sure wich one is best yet.
• priorities depending of current available
• max vehicles we can charge at the same time

some question to solve:

• what happend when network is down or some clients are unreachable ?
• How do we know they are really powered off or just unreachable but can still draw amps on their own ?

a default rule of disabling the evse if not connected to the server or to the network would solve booth question. Shaper already handle this if not receiveing data for xx seconds but it's not instantaneous

I still continue to think it's a better task for an external daemon btw.