evcc-io
Epic: Load management enhancements
- [x] Fail-safe mode on errors (https://github.com/evcc-io/evcc/pull/14249)
- [x] Add circuits api to support SteuVE (§14a EnWG) [german law]
- [ ] Handle timers (https://github.com/evcc-io/evcc/discussions/14114#discussioncomment-9803088)
- [ ] Honor priorities (https://github.com/evcc-io/docs/pull/567)
- [x] Support planner (https://github.com/evcc-io/docs/pull/567, https://github.com/evcc-io/evcc/issues/14049, https://github.com/evcc-io/evcc/pull/23554)
- [ ] Visualisation (https://github.com/evcc-io/evcc/discussions/14323) https://github.com/evcc-io/evcc/pull/15110
- [ ] Better limiting in fast mode (https://github.com/evcc-io/evcc/issues/14827)
- [ ] Follow the peak (https://github.com/evcc-io/evcc/issues/21970)
- [ ] Add timers for applying load management limits (https://github.com/evcc-io/evcc/issues/24122)
- [ ] Phase switching under load management (https://github.com/evcc-io/evcc/issues/24932)
Frage: könnte man hier auch noch eine Schieflast-Überwachung mit reinnehmen?
Hier noch nicht, da das eine genaue Zuordnung der Phasen der ersten einzelnen Circuits und Loadpoints erfordert.
Add circuits api to support SteuVE
Noch ein Problem entdeckt, oder ich habe einen Gedankenfehler?
2 Ladepunkte hängen am selben Kabelanschluss. Dieser Anschluss hat kein Meter.
Jeder Ladepunkt (hat sein eigenes Meter) bekommt seinen eigenen circuit. (Annahme von mir, dass darüber später die Regelung bzgl SteuVE läuft).
Beide Ladepunkte sind dem circuit "loadpoints" zugeordnet (wegen der Maximalleistung des Anschlusses).
Der circuit "loadpoints" ist somit nur eine Zusammenfassung der beiden Ladepunkte.
Es kommt der Fehler circuit loadpoints has no meter an no loadpoint assigned.
circuits:
- name: main
title: Hauptsicherung
maxCurrent: 48
- name: loadpoints
title: Ladepunkte
maxCurrent: 16
parent: main
- name: lp1
title: LP1
maxCurrent: 16
parent: loadpoints
- name: lp2
title: LP2
maxCurrent: 16
parent: loadpoints
Kein Denkfehler, aktuelle Restriktion. Die Prüflogik berücksichtigt keine Hierarchie von Circuits über 2 Ebenen hinaus. Würde ich auch erst angeben, wenn das wirklich relevant sein sollte- hier brauchst Du das ja nicht weil Du einfach beide Boxen an den loadpoints Circuit hängen kannst?
hier brauchst Du das ja nicht weil Du einfach beide Boxen an den loadpoints Circuit hängen kannst?
aktuell ja. Aber der Hinweis auf "SteuVE" hat mich auf diesen Gedanken gebracht. Diese Regulierung betrifft ja jede Wallbox einzeln und wenn die Regelung über den circuit laufen soll (was ja Sinn macht), dann braucht jede Wallbox einen eigenen. Aber, stimmt, ist noch nicht relevant.
Die Dimmung erfolgt pauschal für alle SteuVE am Anschluss über die netzrelevante Leistungsaufnahme.
Im Fall eines EMS gibt es dazu eine vglw. komplizierte Formel für die Summe.
Es wird dabei leider nicht nur einfach n * 4200 kW als SteuVE-Limit vorgegeben.
It would be good to allow use of plugins to set the values for circuit. Not sure if that would be a start to help support SteuVE
I have created an english version of the documentation page for loadbalancing. (https://github.com/evcc-io/docs/pull/584)
But I I have noticed a difference in behavior and how the documentation describes how it should work. This statement: "Alle Ladepunkte ohne explizite Stromkreiszuordnung werden diesem Hauptstromkreis zugeordnet. " I conclude from this that if I have only one circuit "main" I do not need to specify "circuit" on the loadpoint configuration. But if I try this loadmanagement does not work on mij loadpoints. I need to specify "circuit: main" on the loadpoints and then it works.
So is this a bug in loadmanagement or just wrong documentation?
In my use-case these warnings are not needed. Overcurrent is expected when we start cooking so it happens almost every day. I am wondering if these warning have any use to other people? Otherwise maybe they could be disabled by default?
Ich habe auch noch ein Problem in Kombination von Lastmanagement und dem Homewizard P1 Meter gefunden. Der Homewizard gibt egal ob Einspeisung oder Bezug eine positive Amperezahl aus. Bedeutet wenn Einspeisung größer als die Limitierung ist, lädt gar nichts mehr. Soll ich dafür ein eigenes Issue erstellen?
[circuit-main] WARN 2024/07/26 11:15:46 over current detected: 21.7A > 10A [site ] DEBUG 2024/07/26 11:15:46 pv power: 16079W [site ] ERROR 2024/07/26 11:15:46 battery 1 soc: outdated [site ] DEBUG 2024/07/26 11:15:46 battery soc: 0% [site ] DEBUG 2024/07/26 11:15:46 battery power: 190W [site ] DEBUG 2024/07/26 11:15:46 grid meter: -14162W [site ] DEBUG 2024/07/26 11:15:46 grid currents: [21.7 21 16.6]A [site ] DEBUG 2024/07/26 11:15:46 site power: -13822W [lp-2 ] DEBUG 2024/07/26 11:15:46 charge voltages: [241 241 242]V [lp-2 ] DEBUG 2024/07/26 11:15:46 detected connected phases: 3p [lp-2 ] DEBUG 2024/07/26 11:15:47 charge total import: 1083.804kWh [lp-2 ] DEBUG 2024/07/26 11:15:47 charger status: B [circuit-main] DEBUG 2024/07/26 11:15:47 validate current: 21.7A + (0A -> 16A) > 10A capped at 0A [lp-2 ] DEBUG 2024/07/26 11:15:47 !! active phases: 3p = min(0p measured 0p vehicle 3p physical 0p charger) [site ] DEBUG 2024/07/26 11:15:55 ---- [lp-1 ] DEBUG 2024/07/26 11:15:55 charge power: 0W [lp-1 ] DEBUG 2024/07/26 11:15:55 charge currents: [0 0 0]A [lp-2 ] DEBUG 2024/07/26 11:15:55 charge power: 5W [lp-2 ] DEBUG 2024/07/26 11:15:56 charge currents: [0 0.0442 0]A [lp-3 ] DEBUG 2024/07/26 11:15:56 charge power: 0W [lp-3 ] DEBUG 2024/07/26 11:15:56 charge currents: [0 0 0]A [circuit-outdoor] DEBUG 2024/07/26 11:15:56 power: 5.3418W [circuit-outdoor] DEBUG 2024/07/26 11:15:56 current: 0.0442A [circuit-main] DEBUG 2024/07/26 11:15:56 power: -13970W
This is a homewizard issue not a load management issue. So maybe better to open a new issue. What you see is strange because I see negative currents in the messages from the homewizard api and the docs also show negative values are possible for current. If you open a separate issue we can discus it further. (if possible use english that would make it easier for me).
But I I have noticed a difference in behavior and how the documentation describes how it should work
@Roeland54 lets move this discussion to https://github.com/evcc-io/docs/issues/587
It would be good to allow use of plugins to set the values for circuit. Not sure if that would be a start to help support SteuVE
Yes, would very much like to have a restful/mqtt api.
2 use cases in the frame of the flemish capacity tariff/peak shaving:
- if the intended max already has been surpassed (by whatever reason) we can lift the limit for the remaining days of the month - it has to be paid for anyway
- if we monitor the current quarter hourly peak, we can decide at minute 10 of 15 to give more power to the circuit for the remaining 5 minutes without hitting the intended limit (not really netzdienlich, but we are very liberalistic here).
see https://github.com/evcc-io/evcc/discussions/16784
This would be https://github.com/evcc-io/evcc/pull/16809. In deviation from the other plugins and given that max power/currents already are config values, this PR works by allowing the plugin to override the current value. If plugin fails, the configured value is acts as fallback.
This would be #16809. In deviation from the other plugins and given that max power/currents already are config values, this PR works by allowing the plugin to override the current value. If plugin fails, the configured value is acts as fallback.
Nice! I am most certainly going to enable this/test this. I had been working on a python script that pulls the latest peak of the month and modifies it accordingly in the evcc.yml but if you have exposed this via an API/HTTP Endpoint that would be even easier/better.
Looking forward to this @andig , super!
@andig Is the EVCC API documentation automatically updated? How can I determine which endpoints and values can be used to modify this?
I was/am under the assumption/understanding the recent pull request https://github.com/evcc-io/evcc/pull/16809 allows us to set the maxPower on the circuit externally via the HTTP API already(?).
I wanted to start experimenting with this but couldn't find the documentation yet, but maybe I have misunderstood the current status of said functionality.
Just add https://github.com/evcc-io/evcc/pull/16809/files#diff-e558b29f57bfef72b6614f8a345c713e6fe64cd1e9032e99a7b7b998a0442271R49-R50. Docs to follow in https://github.com/evcc-io/docs/issues/658. That's not an "api" but simply configuration of the hems device.
Example:
circuits: # Loadmanagement
- name: main
title: Hausanschluss
maxCurrent: 35
GetMaxCurrent:
source: mqtt
topic: Haus/circuit/maxcurrent
maxpower: 24000
GetMaxPower:
source: mqtt
topic: Haus/circuit/maxpower
meter: grid
Am I missing something, or don't we have an API for Loadmanagement yet?
Use case: I would like to limit the power during the day to the limit of my inverter, to avoid that my cars charge more as my PV could (theoretically) do. So my wish would be to limit the power output of all loadpoints in sum to e.g. 8 kW, even if smartcharging is used and 2 cars are plugged in at the same time.
However, during the night: I don't care, so both loadpoints should be able to use all available power (because energy is cheap) and I maybe need my car on the next day.
Simplified: Charge slower (but not too slow when only one car is connected) when by car is during the day at home, but charge fast during the night.
I know that EVCC should not die on feature creep, therefore: an API for Loadmanagement would be enough, so I could do my complex ideas on my own, but without worrying and playing around with 1P/3P charging and currents, as it would be needed right now (AFAIK).
I've been doing this as above now for months no issue.
https://github.com/evcc-io/evcc/issues/14261#issuecomment-2449611775
Have demand tariff so ensuring a max power draw is critical during certain hours. If this fails limits to 2.4kw if the mqtt fails.
This does not need an api you can even use JavaScript in place of mqtt here and code up the times if that suites your use case.
This does not need an api you can even use JavaScript in place of mqtt here and code up the times if that suites your use case.
I didn't think about that in the first place, will use an HTTP source as I have an energy management backend written in Python anyways, still would prefer having an API in mid/long term.
This does not need an api you can even use JavaScript in place of mqtt here and code up the times if that suites your use case.
I didn't think about that in the first place, will use an HTTP source as I have an energy management backend written in Python anyways, still would prefer having an API in mid/long term.
It's sort of an API, being a plugin
GetMaxPower:
source: whatever ( https://docs.evcc.io/en/docs/reference/plugins )
Or you really need a push from outside instead of a pull from inside?
We could not discuss back and forth what an API should be, but that will not be helpful. ;)
But: GetMaxPower with an HTTP source will work for me, so I am fine.
Leider wurde der Punkt Multiple HEMS fail to configure #19216 noch nicht in der Liste des ersten Beitrags als offener Punkt hinzugefügt. Das andere Ticket wurde allerdings bereits geschlossen und auf dieses hier sie Duplikat gesetzt.
https://github.com/evcc-io/evcc/issues/21834#issuecomment-2972902886
You are missing a description? Pls ferl free to put it there. The issue is linked anyway.
@andig As I am not part of the team I am not allowed to edit the first comment of this ticket and add the mentioned failure to the description of this ticket.
