evcc-io / evcc Goto Github PK

Currently SMA meter only supports api.Meter. It would be great if it would also support api.MeterEnergy

I am manually simulating same situations.
My testsetup: Only gridmeter and charger (without meter). PV Only

[main] INFO 2020/04/29 11:37:24 evcc dev (HEAD)
[main] INFO 2020/04/29 11:37:24 using config file evcc_configurable.yaml
[main] INFO 2020/04/29 11:37:24 listening at 0.0.0.0:7070
[mqtt] INFO 2020/04/29 11:37:24 connecting evcc-530756363 at localhost:1883
[wifi] WARN 2020/04/29 11:37:24 -- experimental --
[load] INFO 2020/04/29 11:37:24 main config: vehicle ✓ grid ✓ pv — charge —
[load] INFO 2020/04/29 11:37:24 main charger: power — energy — timer —
...
<truncated>

Charging is startet, I reduce grid export power to 100W (value = -100) (because charger consumes 1600W), in the next cycle main target power is calculated wrong and charger gets disabled. main target power should include already set power for the second cycle.
Also if not reducing grid power the charger get disabled.

Attached is my configuration.
evcc_configurable_short.txt

Maybe it is only a simulation issue.

Hallo! Ich wollte EVCC ab nächster Woche mal testen.

Setting:
-- go-e Charger
-- Renault ZOE (Modell 2020)
-- PV-Eigenversorgungsanlage mit Smartmetern von Discovergy
-- Synology-NAS vorhanden

Fragen:
-- Kann EVCC schon mit der Discovergy API umgehen (für die Abfrage von Einspeisung / Bezug). Hier gibt bei bei OpenWB bereits ein Modul
-- Empfielst du ein Docker auf der Synology-NAS oder besser eine andere Umsetzung?

Support should cover:

• caching (any value, timeout or cache), currently supported for any provider
• jq-like selection of json content (any value, jq), currently supported for http
• scaling (only numeric values, scale), currently supported for http, modbus, mqtt

This should be applicable across any transport (MQTT, HTTP, script).

Fixes #62 (using scale).

Settings:

charger: go-e
phases: 3

Da unser Zoe erste nächste Woche da ist, hat heute ein Freund die Wallbox mit einem Hyundai Ioniq eingeweiht. Der lädt einphasig, maximal 32A, also ca 7,3 kW.

Beobachtung:

• Die Steuerung des Ladestroms durch EVCC geht davon aus, dass dreiphasig geladen wird und berechnet daraufhin den Strom, der maximal fließen soll. Da jedoch nur einphasig geladen wird, fließt viel PV Strom ins Netz, siehe
  
  --> grün die Bereich, wo mit "Sofort laden" der maximale Strom und damit die 7,2 kW Ladeleistung erreicht wurden.
  --> nach den "Sofort laden" Zeiten fällt die Ladung im PV-Modus langsam ab. Ist das agiler einstellbar mit dem Setting
  sensitivity: 1 # current raise/lower step size (default 10A)
  --> Ist hier die Einheit Ampere/min gemeint?

Hauptfrage:
Wie bekommt man es hin, dass auch einphasige Autos an einem dreihpasigem loadpoint im PV-Modus bei genügend Überschuss mit entsprechend mehr Leistung geladen werden?

Ich habe einen Phoenix Contact charge controller der EV-CC-AC1-M3 Serie in meiner Wallbox. Die Kommunikation geht über RS-485 Modbus. Hätte auch ein paar Python Beispiele bei Interesse:
https://www.phoenixcontact.com/online/portal/de/?uri=pxc-oc-itemdetail:pid=1622459

EVCC könnten auch ein paar Basisnetz(schutz)funktionen ganz gut stehen.

• Frequenzabhängiger Lastabwurf (d.h. Unterbrechnung) des Ladevorgangs bei Netzüberlastung (< 49,200 Hz)

• Schieflastbegrenzung auf <= 20A (max. Phasenstromdifferenz) am Netzübergabepunkt

• Bezugsleistungsbegrenzung am Netzübergabepunkt (wg. techn. Auslegung oder Vertragsgestaltung der Netzanbindung)

• Phasenstrombegrenzung am Netzübergabepunkt (wg. techn. Auslegung oder Vertragsgestaltung der Netzanbindung)

• Phasenstrombegrenzung für Ladepunktgruppen (wg. techn. Auslegung der Zuleitung / Unterverteilung)

Nach §14a EnWG:

• Abregelung durch VNB-Steuergerät (temporäre Limitierung auf x A)

• Freigabe/Sperrung durch VNB-Steuergerät ("Wärmepumpenstrom", abschaltbare Last)

• Limitierung des PV Mode auf 70% Abregelung (Nutzung von "abgeregelter Energie" für Eigenverbrauch)

• OCPP-Anbindung zum VNB

Vlg. z. B. https://assets.ctfassets.net/xytfb1vrn7of/6TIfm0d9BAtSlWvTSY3zis/4dd36bd0311ac927d19c00b5c5490bda/2020_03_NetzeBW_TMA_Netzdienliche_Steuerung.pdf

vzlogger has a few interfaces that could be used:

• Push Server (updates very fast)

• HTTP (it depends on the set agg time, but this is rather high because it also used to writes the data to the database)

• MQTT (I do not know the update rate, probably the same as API)

MQTT should be supported already by evcc, it could be uses as a workaround. But not everybody is using mqtt.

volkszaehler:

• HTTP

Right now the docker image only contains one architecture amd64 instead of all supported/wanted

These architectures might be useful to support:

• armv6
• armv7
• arm64
• 386
• amd64

We need to find out what the issue is and fix it

[main] INFO 2020/04/14 13:51:52 using config file /etc/evcc.yaml
[main] INFO 2020/04/14 13:51:52 listening at 0.0.0.0:7070
[go-e] WARN 2020/04/14 13:51:52 -- experimental --
[load] INFO 2020/04/14 13:51:52 main config: vehicle ✓ grid ✓ pv — charge —
[load] INFO 2020/04/14 13:51:52 main charge mode: off
[load] ERROR 2020/04/14 13:51:53 main charger error: invalid character '<' looking for beginning of value
[load] ERROR 2020/04/14 13:51:53 main charge controller error: invalid character '<' looking for beginning of value
[load] ERROR 2020/04/14 13:51:53 main charger error: invalid character '<' looking for beginning of value
panic: runtime error: index out of range [11] with length 0

Any ideas?

We might want the UI to be available in additional languages besides German 😁

This ticket is to track the feature and discuss anything related to it.

Ich würde vorschlagen die Push-Benachrichtigungen (Telegram, Pushover, SMS, E-Mail, ...) mit weiteren Metadaten zu füttern oder zumindest um weitere mögliche Datenfelder zu erweitern.

Hier mal eine lose Ideensammlung unabhängig vom aktuellen Implementierungsstand und der Umsetzungsschwierigkeit:

• Start-SOC (bei Verbindung)
• Aktueller SOC -> socCharge
• Aktuelle Ladeleistung -> chargePower
• Durchschnittliche Ladeleistung (seit Verbindung)
• Maximale gemessene Ladeleistung (Fahrzeug)
• Maximale freigegebene Ladeleistung (EVCC)
• Gesamtladedauer (Nettoladezeit, Summe aller Ladephasen) -> chargeDuration (#238)
• Verbindungszeit (Bruttoladezeit) -> connectedDuration (#237)
• Geladene Energie (seit Verbunden) -> chargedEnergy (#238)
• Prognostizierte (Rest)Ladedauer -> chargeEstimate
• Prognostiziertes Ladeende (Uhrzeit)
• Aktuelles Datum+Uhrzeit
• Ladekurve als Grafik
• Netzbezugsanteil
• Energiekosten (des Netzbezugs)

Darüber hinaus sollten zu folgenden Events entsprechde Mitteilungen verschickt werden können:

• Fahrzeug wurde verbunden (Status A->B) -> connect (#237)
• Fahrzeug hat Ladung begonnen (Status ->C) -> start
• Fahrzeug hat Ladung beendet (Status C->B) -> stop
• Fahrzeug wurde getrennt (Status ->A) -> disconnect (#237)
• Ladung wurde freigegeben (durch EVCC während Fahrzeug verbunden)
• Ladung wurde gesperrt/pausiert (durch EVCC während Fahrzeug verbunden)
• EVCC-Fehlermeldung
• SOC-Wert geändert

We could support the same flexibility for integrating ModBus meters as MBMD: https://github.com/volkszaehler/mbmd/blob/master/docs/mbmd_read.md

This would allow to support meters that are sofar not covered by MBMD.

Die Renault ZE API benötigt eine korrekte Behandlung von abgelaufenen Token (refresh) und ggf. weiteren Fehlerzuständen.

I.e. Wallbe seems to return connected time instead of charge time. In this case we should rather not use the charger value.

Follow-up to #84

...in addition to meter.

Everything logged on the ERROR or FATAL logger should also be set to UI for error popup.

Documentation is at https://www.nrgkick.com/home/wp-content/uploads/2019/08/20190814_API-Dokumentation_04.pdf

Currently evcc is reacting on every single measurement which may lead to a charge disable if grid power is read during the short spike (maybe only if charge current is at minimum, I don't know). A few things that I image that would be useful:

1. hold on time: grid power must be less than XX for YY sec/min to disable charger
2. holf off time: grid power must be greater than min charge power for xx sec/min to enable charger
3. Maybe also start / stop power limits could be configurable. Installations with small pv systems could configure to charge with e.g. 70% pv. Maybe setting the percentage value from ui would be useful. This is not comparable to "Minimum + PV" as this would starts immediately and not wait for sufficient pv power. The pv percentage setting should be a minimum pv value, charge power should only be increased if pv percentage is 100%. evcc should not regulate to the 70% value.

SMA has two devices that are often installed in houses with SMA PV and/or battery inverters. Especially with battery inverters to optimize the charging and discharging process.

The devices are:

• SMA Home Manager 2.0
• SMA Energy Meter 30

The main goal for this issue is to discuss the proper implementation architecture to add support for these devices. Once the architecture is clear, I would implement it and start a pull request when the first working implementation is available.

Both devices provide 2 way balanced power measurements. The SMA Home Manager 2.0 is installed directly after the net provider grid meter. So it can be used as a grid meter. The SMA Energy Meter is either also used as a grid meter, or also as a dedicated PV meter in a SMA installation, if non SMA inverters are to be used with the Home Manager device.

Both devices use UDP multicast on the same port to provide current measurements. Each device automatically broadcasts a data package about every 10 seconds. Each data package contains the serial number of the device and this way the data can be associated if multiple devices are installed. The Energy Meter also provides other ways to get data, but this is the only way to get data from the Home Manager. That‘s why we ignore the other options to provide support for both devices.

Architecture suggestion:

• Add a new „SMAMeter“ provider
• Setup a single shared instance of a multicast listener that is used for all SMAMeter devices
• The listener parses the data packages and sends each new dataset into a channel
• The provider instance subscribes to the channel provided by the listener
• The provider filters out the data package for its defined serial number and assigns the needed data values
• The listener could be implemented in its own file or as part of the SMAMeter file. Not sure what the preferred approach here is

What do you think?

My smart meter (AMIS Zähler) returns import and export power at the same time. Both values are positive. The smartmeter is read with vzlogger and optical interface EN 13757 (M-Bus).
To calculate the real export power, the import power has to be substracted from the export power.

Currently not planned as it requires specialised hardware and is typically not implemented in commercial wallboxes. If you need 1p3p support for using smaller PV generators, especially during winter time, I'd recommend using OpenWB hardware.

If anybody has such a setup please let me know.

Examples of devices that are supported out of the box but not obviously so:

• SMA Home Manager and SMA Energy Meter (type „sma“)
• KOSTAL SEM and EMxx (modbus TCP)
• E3DC (modbus TCP)
• vzlogger (type „http“)
• any modbus RTU meter (SDM630 and any other) (modbus RTU oder TCP)

The control connection to the specified charger (primarly) should be permanently monitored.
While this is more important for mobile chargers like NRGkick and go-eCharger also connections to fixed infrastructure could be disturbed or even interrupted.
These situations should be handled properly (automatic reconnection), clearly logged (but not flooded) and displayed on the UI.

from #98:

Another thing I'm wondering about: when evcc is set to pv only (and there is not enough PV generation) and I connect my car, then charging will start immediately (and stop after guardtime).

Major settings like charge current and charge enabled should be kept in sync between internal EVCC and EVSE.

Due to any connection problem (shutdown or reboot of EVSE, bad wireless connection, EMP, manual settings on EVSE, internal EVSE logic etc.) settings can be desynced between EVCCs will and what the charger really does.
So EVCC should read the major settings from EVSE, compare and update them if they differ on a regular base where possible. Not all types of EVSE allow for reading the internal settings.

Appart from that it should make sure that the connection to EVSE is alive by implementing something like "heartbeat" or "ping" to monitor the connection #122

Wahrscheinlich gar nicht.

OpenWB ist eine ausgereifte und erprobte Gesamtlösung aus Hard- und Software. Mit OpenWB gibt es breite Anwendungserfahrung. Insbesondere unterstützt OpenWB eine Vielzahl von unterschiedlichen Wallboxen und Ladern.

EVCC besteht ausschließlich aus Software und unterstützt vorkonfiguriert nur Wallbe Eco Wallboxen. Ein Vorteil von EVCC besteht in der Unabhängigkeit der zugrunde liegenden Plattform.

Während OpenWB einen RaspberryPi benötigt und vollständig mit dem Betriebssystem verbunden ist, besteht EVCC aus einem einzigen Binary und kann auch als Docker Container betrieben werden.

Currently logging is only executed on influxDB. Should also log to MQTT. Requires a design how to represent/access multiple loadpoints, e.g. per index or per name. Per index would be most reproducible setup. Should we include units similar to openWB?

If a house setup is also having a battery inverter (and battery connected), then it can/will block dynamic adjustments of the power to charge the car with as long as the inverters charging capacity is within the unused solar generated power.

The system basically works like this:

• The energy manager checks the power usage in the house, which is including the power the ev charger takes
• tells the battery inverter to draw the difference between the generated solar power and the used power
• if the difference is bigger than the capacity of the battery inverter, it will send the rest to the grid
• now this rest is only what the EVCC can detect right now to use for power adjustments for the ev charger

There are multiple options to handle this:

• Do nothing special as the end user still can use "Sofortladen" to overwrite all these limitations to tell the ev charger to use full available/possible power
• Do nothing special and the system simply has to wait until the house battery is charged sufficiently (this is for the energy manager to determine) until more power to charge the car with is getting available
• Consider the battery inverters current charging power as "available" power to add to the ev charging process
• Consider the battery inverters current charging power as "available" and add an option for the user to "allow" the battery inverter to always have a minimum power available

Are there any other options I didn't think of here?

We need a place for end users to find anything they need to use EVCC, if possible in English and German languages.

I would suggest to use Github pages and create a website for this use, e.g. using Hugo static site generator. The Github readme imho should stay development centric. What do you think?

Grid power = 1000W import, Mode is default Off. Charger is in enabled state during evcc start.

[main] INFO 2020/05/10 08:56:40 evcc dev (HEAD)
[main] INFO 2020/05/10 08:56:40 using config file /xxx/evcc/evcc.yaml
[main] INFO 2020/05/10 08:56:40 listening at 0.0.0.0:7070
[load] INFO 2020/05/10 08:56:40 main loadpoint config: vehicle — grid ✓ pv — battery — charge —
[load] INFO 2020/05/10 08:56:40 main charger config: power — energy — timer —
[load] INFO 2020/05/10 08:56:40 main charge mode: off
-> correct
[load] INFO 2020/05/10 08:56:40 main charger enabled
-> this is my init state.
[load] DEBUG 2020/05/10 08:56:40 main set charge current: 6A
-> charging will beginn / continue
[load] DEBUG 2020/05/10 08:56:40 > main
[load] DEBUG 2020/05/10 08:56:40 main charger status: B
[load] DEBUG 2020/05/10 08:56:40 main grid power: 1000.0W
[load] DEBUG 2020/05/10 08:56:40 main charge power: 0.0W
[load] DEBUG 2020/05/10 08:56:40 main charger disable - contactor delay 19s
[load] DEBUG 2020/05/10 08:56:40 < main
[load] DEBUG 2020/05/10 08:56:40 > main
[load] DEBUG 2020/05/10 08:56:40 main charger status: B
[load] DEBUG 2020/05/10 08:56:40 main grid power: 1000.0W
[load] DEBUG 2020/05/10 08:56:40 main charge power: 0.0W
[load] DEBUG 2020/05/10 08:56:40 main charger disable - contactor delay 19s
[load] DEBUG 2020/05/10 08:56:40 < main
[load] DEBUG 2020/05/10 08:56:50 > main
[load] DEBUG 2020/05/10 08:56:50 main charger status: B
[load] DEBUG 2020/05/10 08:56:50 main grid power: 1000.0W
[load] DEBUG 2020/05/10 08:56:50 main charge power: 0.0W
[load] DEBUG 2020/05/10 08:56:50 main charger disable - contactor delay 19s
[load] DEBUG 2020/05/10 08:56:50 < main
[load] DEBUG 2020/05/10 08:57:00 > main
[load] DEBUG 2020/05/10 08:57:00 main charger status: C
[load] INFO 2020/05/10 08:57:00 main start charging ->
[load] DEBUG 2020/05/10 08:57:00 main grid power: 1000.0W
[load] DEBUG 2020/05/10 08:57:00 main charge power: 1380.0W
[load] DEBUG 2020/05/10 08:57:00 main charger disable - contactor delay 19s
[load] DEBUG 2020/05/10 08:57:00 < main
[load] DEBUG 2020/05/10 08:57:10 > main
[load] DEBUG 2020/05/10 08:57:10 main charger status: C
[load] DEBUG 2020/05/10 08:57:10 main grid power: 1000.0W
[load] DEBUG 2020/05/10 08:57:10 main charge power: 1380.0W
[load] DEBUG 2020/05/10 08:57:10 main charger disable - contactor delay 19s
[load] DEBUG 2020/05/10 08:57:10 < main
[load] DEBUG 2020/05/10 08:57:20 > main
[load] DEBUG 2020/05/10 08:57:20 main charger status: C
[load] DEBUG 2020/05/10 08:57:20 main grid power: 1000.0W
[load] DEBUG 2020/05/10 08:57:20 main charge power: 1380.0W
[load] DEBUG 2020/05/10 08:57:20 main charger disable - contactor delay 19s
[load] DEBUG 2020/05/10 08:57:20 < main

I think enabled state of charger can occur in real world (e.g. restart of evcc during charging) and evcc should be able to handle this situation. Contactor delay in not decreased so it will never stop charger.

If I have misunderstood the charger state please close this issue.

This should initially allow HTTP request plus jq-like value extraction. Could support #66.

My grid meter is currently providing positive values as long as power gets delivered to the grid and negative values if power is getting purchased from the grid.

Please implement a config parameter to invert the reading. Currently i'm just dry-running evcc just with my meters. Charger and vehicle is configured as dummy script.

See https://www.tq-group.com/filedownloads/files/products/automation/software_tools/energy-management/TQ_EM_JSON-API.0104.pdf

Not sure if this is needed or if the SMM can be read via the KOSTAL SunSpec model.

It would be great to get remote access for testing.

See https://www.tq-group.com/filedownloads/files/products/automation/software_tools/energy-management/TQ_EM_Modbus_Slave.0013.pdf.

Not sure if this is needed or if the SMM can be read via the KOSTAL SunSpec model.

It would be great to get remote access for testing.

I would need credentials for testing. If you want to help please pm me at [email protected].
Refs https://github.com/Hacksore/bluelinky/blob/master/lib/index.ts

I have evcc 0.5 running on docker and a Wallbe eco 2.0 connected to 1 phase at the moment.
evcc seems to control the wallbox (connection ok).
But evcc seems to set the MaxCurrent value 10 times too high (e.g. 60 amps instead of 6).

evcc set to "pv":

result in wallbe interface:

As a result the wallbox runs at full power even though PV energy is too low.

Current state:
The guardduration ticks down since the last change to the WallBox.
If you click "Sofortladen" or "Stop" you have to wait for the change until the guardduration has expired.

Expected behavior:
If "Sofortladen" or "Stop" are clicked the command should be send to the WallBox immediately.

See https://www.goingelectric.de/forum/viewtopic.php?p=1241738#p1241738

It would be cool if you could integrate the ABL Charger.
Communication reference:
https://manualsbrain.com/de/manuals/703790/?page=7
I could sent out an ABL emh1 (1-phase), to test.

Alle unterstützen Geräte sind in der README dokumentiert. Neben direkt unterstützen Geräten stehen Plugins zur Integration weiterer Geräte zur Verfügung.

Für eine Vielzahl von bereits unterstützen Zählern, Wallboxen und Fahrzeug APIs finden sich in https://github.com/andig/evcc-config fertige Beispielkonfigurationen.

Falls es noch keine fertige Implementierung gibt bitte im Diskussionsforum oder im GoingElectric Forum anfragen.

For time being, key switch will enabled charging at currently set charge current. EVCC will not be aware of external charge release by key. To be decided if key switch should be:

• immediate charging at maximum power
• charging at selected mode

Trying to setup evcc in a docker container on a synology 918+ for Tesla Model3, Wallbe eco2s and Solaredge PV (installation due), data going through mqtt/Home Assistant.

Pasted the client key and id from pastebin link in wiki but still getting
"https://owner-api.teslamotors.com/oauth/token": x509: certificate signed by unknown authority"

Didi anyone get a connection to the tesla mothership?

In #52 we're discussing support how home batteries. It would be great to get access to one for understanding the possibilities. E3DC would be most helpful as it supports Modbus TCP and could be integrated right away.

When Wallbe is turned off or power limited in PV mode, overcurrent detection is used to disable wallbe. Using overcurrent detection, Wallbe will go into error mode (state E). When EV is disconnected in this mode, Wallbox will remain in state E, thus not detecting car being disconnected (A).
Furthermore, since Connected() API will return true even in error state, polling of SoC will continue, potentially exhausting communication limit.