diff --git "a/docs/Grunds\303\244tzliches zu Z\303\244hlern.md" "b/docs/Grunds\303\244tzliches zu Z\303\244hlern.md" index add8c822a8..b5df17333e 100644 --- "a/docs/Grunds\303\244tzliches zu Z\303\244hlern.md" +++ "b/docs/Grunds\303\244tzliches zu Z\303\244hlern.md" @@ -1,6 +1,6 @@ openWB benötigt zum erfolgreichen PV-Überschussladen die entsprechenden Zählerwerte am EVU-Punkt (EVU=Elektrizitätsversorgungsunternehmen), sprich dem Übergang ins öffentliche Netz. An dieser Stelle muss die Gesamtleistung saldierend erfasst werden. Für eine phasenbasierte Leistungsüberwachung sind auch die einzelnen Ströme und/oder Leistungen der drei Phasen notwendig. Bei einem Zähler im Hausverbrauchs-Zweig muss die Konfiguration wie [hier](https://github.com/openWB/core/wiki/Hausverbrauchs-Zähler) beschrieben erfolgen. -Im einfachsten Fall geschieht dies durch Kauf und Einbau eines [EVU-Kits](##EVU-Kit). Sollten schon digital auslesbare Zähler vorhanden sein, so besteht die Möglichkeit diese Werte an openWB weiterzuleiten, auch mit Hilfe von Hausautomationsservern. +Im einfachsten Fall geschieht dies durch Kauf und Einbau eines [EVU-Kits](#evu-kit). Sollten schon digital auslesbare Zähler vorhanden sein, so besteht die Möglichkeit diese Werte an openWB weiterzuleiten, auch mit Hilfe von Hausautomationsservern. Es gibt viele verschiedene Möglichkeiten, Zähler als auch Wechselrichter in das openWB-System einzufügen. Die Struktur der Zähler muss dann im [Lastmanagement](https://github.com/openWB/core/wiki/Lastmanagement-und-kaskadierte-Zähler) dem System bekanntgegeben werden. Hier können auch [virtuelle Zähler](##Virtuelle Zähler) hinzugefügt werden, welche openWB-intern die untergeordneten Zähler verrechnen. @@ -13,7 +13,7 @@ Der Zähler kommuniziert mit der openWB über Ethernet. Die Kits sind so vorkonf ## MQTT -openWB hat einen MQTT-Broker integriert, welcher unter Port 1883 (ohne Verschlüsselung) und Port 8883 (mit Verschlüsselung) erreichbar ist. Benutzerauthentifizierung ist deaktiviert und auch nicht aktivierbar. Ein Zähler, welcher die benötigten Daten liefert muss sich mit diesem Broker verbinden und dort die Werte unter den entsprechenden Topics publishen. +openWB hat einen MQTT-Broker integriert, welcher unter Port 1883 (ohne Verschlüsselung) und Port 8883 (mit Verschlüsselung) erreichbar ist. Benutzerauthentifizierung ist deaktiviert und auch nicht aktivierbar. Ein Zähler, welcher die benötigten Daten liefert muss sich mit diesem Broker verbinden und dort die Werte unter den entsprechenden Topics veröffentlichen. Folgende Werte können dem MQTT-Zähler übergeben werden. Die ID ist individuell und wird beim Anlegen der MQTT-Komponente angezeigt. Die folgenden Topics sind für einen reibungslosen Betrieb unbedingt erforderlich: @@ -57,10 +57,10 @@ Die Netzfrequenz, Spannungen, Leistungen und Leistungsfaktoren jeder Phase werde ## Huawei Wechselrichter mit DTSU666-H 250A und SDongle Huawei Wechselrichter werden, in der Betriebsart mit Aufzeichnung des Hausverbraucht mit dem _DTSU666-H 250A_ Stromzähler direkt am EVU-Punkt betrieben. Die Kommunikation zwischen Zähler und Wechselrichter findet über RS485 statt. Sofern der Wechselrichter mit dem optionalen SmartDongle FE ausgestattet ist, können über diesen Daten des Wechselrichter ausgelesen werden. -Die Schnittstelle am Dongle ist Modbus-TCP. Dies muss mit Installer-Account am Wechselrichter auf "Unrestrictet" gestellt werden, damit die Daten extern abgerufen werden können. +Die Schnittstelle am Dongle ist Modbus-TCP. Dies muss mit Installer-Account am Wechselrichter auf "Unrestricted" gestellt werden, damit die Daten extern abgerufen werden können. Der Huawei-Wechselrichter kann direkt über die openWB ausgelesen werden. -Eine weitere Möglichkeit des Datenabrufs wird im [openWB-Forum](https://openwb.de/forum/viewtopic.php?t=7029) entwickelt und ist auf [Github](https://github.com/AlexanderMetzger/huawei_openwb_bridge) sowie der [Homepage des Entwicklers](https://lebensraum-wohnraum.de/openwb-kommunikation-mit-dem-huawei-wechselrichter-sun-2000/) zu finden. Hierbei wird das Image auf die SD-karte eines Raspberry-Zero gespiegelt und der Raspberry mit dem Config-WLAN des Wechselrichters verbunden. Die Skripte ziehen sich die entsprechenden Werte in Echtzeit vom Wechselrichter und publishen diese auf die [MQTT](#MQTT) Schnittstelle der openWB. Der Zähler in der openWB muss dementsprechend als MQTT-Zähler eingerichtet sein. +Eine weitere Möglichkeit des Datenabrufs wird im [openWB-Forum](https://openwb.de/forum/viewtopic.php?t=7029) entwickelt und ist auf [Github](https://github.com/AlexanderMetzger/huawei_openwb_bridge) sowie der [Homepage des Entwicklers](https://lebensraum-wohnraum.de/openwb-kommunikation-mit-dem-huawei-wechselrichter-sun-2000/) zu finden. Hierbei wird das Image auf die SD-karte eines Raspberry-Zero gespiegelt und der Raspberry mit dem Config-WLAN des Wechselrichters verbunden. Die Skripte ziehen sich die entsprechenden Werte in Echtzeit vom Wechselrichter und veröffentlichen diese auf die [MQTT](#mqtt) Schnittstelle der openWB. Der Zähler in der openWB muss dementsprechend als MQTT-Zähler eingerichtet sein. ### Solaranzeige @@ -69,7 +69,7 @@ Dieses Projekt unterstützt aktuell (Stand 2024-02) mehr Wechselrichter als open Die Software ist originär dafür vorgesehen auf einen Raspberry per Image installiert zu werden und nach wenigen Konfigurationsschritten lauffähig zu sein. Es gibt auch schon Portierungen für [Docker](https://github.com/DeBaschdi/docker.solaranzeige). Solaranzeige kann mit vielen Wechselrichtern kommunizieren und auch teilweise die angeschlossenen Zähler auslesen. Eine zeitbasierte Datenbank (InfluxDb), Datenweitergabe über einen MQTT-Client sowie eine Visualisierung mit Grafana sind direkt integriert. Es kann aber auch bereits existierende Infrastruktur verwendet werden. In dem Projekt wird (mit Stand von 2021) auch die Möglichkeit dokumentiert die Daten direkt an openWB weiterzuleiten. Dann kann jedoch kein weiterer MQTT-Broker bedient werden. -Alternativ können die Zählerwerte an eine Hausautomationsserver weitergegeben, dort ggf. vorzeichenkorrigiert und dann über einen zweiten MQTT-Client zur openWB geschickt werden. +Alternativ können die Zählerwerte an eine Hausautomationsserver weitergegeben, dort ggf. mit korrigiertem Vorzeichen und dann über einen zweiten MQTT-Client zur openWB geschickt werden. ## Virtuelle Zähler diff --git a/docs/Hausverbrauch.md b/docs/Hausverbrauch.md index 0135f48e5b..a9b0c9cc78 100644 --- a/docs/Hausverbrauch.md +++ b/docs/Hausverbrauch.md @@ -1,5 +1,5 @@ -Der Hausverbrauch kann in der openWB auf zwei verschiedenen Wegen ermittelt werden: die openWB berechnet den Hausverbrauch oder du gibst in den Einstellungen einen Zähler an, der den Hausverbrauch misst. -Eine Mischung der beiden Möglichkeiten, also nicht gemessener, berechneter Hausverbrauch und gemessener Hausverbrauch kann in der openWB nicht abgebildet werden. +Der Hausverbrauch kann in der openWB auf zwei verschiedenen Wegen ermittelt werden: die openWB berechnet den Hausverbrauch oder du gibst in den Einstellungen einen Zähler an, der den Hausverbrauch misst. +Eine Mischung der beiden Möglichkeiten, also nicht gemessener, berechneter Hausverbrauch und gemessener Hausverbrauch kann in der openWB nicht abgebildet werden. Es muss in der Anlage einen Zähler geben, der alle Verbräuche erfasst. Dies kann entweder der EVU-Zähler sein (dieser erfasst auch Wechselrichter und Speicher) oder der Hausverbrauchszähler (Wechselrichter und Zähler werden separat erfasst). ### Möglichkeit 1: Berechnung des Hausverbrauchs durch die openWB @@ -8,14 +8,15 @@ Der Hausverbrauch entspricht der Summer aller nicht gemessenen Verbraucher. Übl ### Möglichkeit 2: Hausverbrauchszähler -Unter `Einstellungen→Konfiguration→Lastmanagement` kann bei Hausverbrauch ein Zähler ausgewählt werden. Diese Einstellung ist nur dann richtig, wenn in der Anlage ein Zähler verbaut ist, der den Hausverbrauch misst. Dies ist bei manchen Systemherstellern wie Kostal(?) üblich. Der Hausverbrauchszähler kann die Ladepunkte messen oder nicht. Dann müssen diese in der Hierachie entsprechend hinter oder neben dem Zähler angeordnet werden. +Unter `Einstellungen→Konfiguration→Lastmanagement` kann bei Hausverbrauch ein Zähler ausgewählt werden. Diese Einstellung ist nur dann richtig, wenn in der Anlage ein Zähler verbaut ist, der den Hausverbrauch misst. Dies ist bei manchen Systemherstellern wie Kostal(?) üblich. Der Hausverbrauchszähler kann die Ladepunkte messen oder nicht. Dann müssen diese in der Hierarchie entsprechend hinter oder neben dem Zähler angeordnet werden. Bezug und Einspeisung ins öffentliche Netz werden dann mit einem virtuellen Zähler aus den Werten des Hausverauchszählers, Wechselrichter und Speicher berechnet. Der virtuelle Zähler addiert die Werte aller in der Struktur dahinter angeordneten Komponenten. Zunächst ein Virtuelles Gerät mit einem virtuellen Zähler anlegen. Die Komponenten müssen in der Hierarchie wie in den Abbildungen unten angeordnet werden. In den Einstellungen für das Lastmanagement beim Punkt Hausverbrauch den Hausverbrauchs-Zähler auswählen. ### Hausverbrauch bei mehreren Zählern -Wenn es einen Zähler am EVU-Punkt und einen Zähler im Hausverbrauchszweig gibt, dann wie unter `Möglichkeit 2` beschrieben, den Zähler, der den Hausverbrauch misst unter `Einstellungen→Konfiguration→Lastmanagement→Hausverbauch` auswählen. -Wenn der Hausverbrauch die Summer mehrerer Zähler in der Anlage ist, müssen diese in einem virtuellen Zähler zusammengefasst werden und dieser wie unter `Möglichkeit 2` als Hausverbrauchs-Zähler ausgewählt werden. Dieser kann nicht der Zähler an der Spitze (EVU-Zähler) sein, da in diesem Zähler immer auch Speicher und PV miteingerechnet werden müssen, um den Überschuss für PV-Laden am EVU-Punkt zu kennen. + +Wenn es einen Zähler am EVU-Punkt und einen Zähler im Hausverbrauchszweig gibt, dann wie unter `Möglichkeit 2` beschrieben, den Zähler, der den Hausverbrauch misst unter `Einstellungen→Konfiguration→Lastmanagement→Hausverbauch` auswählen. +Wenn der Hausverbrauch die Summer mehrerer Zähler in der Anlage ist, müssen diese in einem virtuellen Zähler zusammengefasst werden und dieser wie unter `Möglichkeit 2` als Hausverbrauchs-Zähler ausgewählt werden. Dieser kann nicht der Zähler an der Spitze (EVU-Zähler) sein, da in diesem Zähler immer auch Speicher und PV mit eingerechnet werden müssen, um den Überschuss für PV-Laden am EVU-Punkt zu kennen. Misst der Zähler den Hausverbrauch, ergibt sich folgende Anordnung: diff --git "a/docs/IO-Ger\303\244te & -Aktionen.md" "b/docs/IO-Ger\303\244te & -Aktionen.md" index 57186c772f..f8b610676e 100644 --- "a/docs/IO-Ger\303\244te & -Aktionen.md" +++ "b/docs/IO-Ger\303\244te & -Aktionen.md" @@ -1,11 +1,15 @@ ### IO-Geräte + IO/GPIO sind analoge und digitale Ein- und Ausgänge, die man meist als Pin- oder Buchsenleiste auf der Platine findet. openWB software2 kann analoge und digitale Eingänge auslesen und analoge sowie digitale Ausgänge schalten. Die Ein- und Ausgänge befinden sich auf dem konfigurierten IO-Gerät, wie zB dem Dimm- & Control-Kit. Um festzulegen, was mit den Informationen aus den Eingängen gemacht werden soll oder welche Ausgänge geschaltet werden sollen, konfigurierst Du IO-Aktionen. Bei der IO-Aktion gibst Du an, welcher Ein- oder Ausgang dafür verwendet werden soll und ggf weitere Aktions-spezifische Einstellungen. #### Dimm-& Control-Kit + Das Dimm-& Control-Kit besitzt acht analoge Eingänge (AI1-AI8), acht digitale Eingänge (DI1-DI8) und achte digitale Ausgänge (DO1-DO8). Bei den Ausgängen handelt es sich um potentialfreie Relais-Ausgänge mit 5A@28VDC/250VAC. #### openWB series2-Modell mit AddOn-Platine + Die AddOn-Platine stellt 7 Eingänge und 3 Ausgänge zur Verfügung. WICHTIG: In openWB software 1.9 waren den IOs feste Aktionen zugeordnet, die auch auf der Platine beschriftet sind. Diese Zuordnung ist in software2 NICHT vorgegeben. Zur einfachen Zuordnung der Pins hier eine Übersicht: + | Pin | Beschriftung | |---------|---------| | Eingang 21 | RSE 2 | @@ -19,8 +23,8 @@ Die AddOn-Platine stellt 7 Eingänge und 3 Ausgänge zur Verfügung. WICHTIG: In | Ausgang 16 | LED 2 | | Ausgang 18 | LED 1 | +## IO-Aktionen -### IO-Aktionen +### Steuerbare Verbrauchseinrichtungen: Dimmen per HEMS, Dimmung per Direkt-Steuerung, RSE -#### Steuerbare Verbrauchseinrichtungen: Dimmen per HEMS, Dimmung per Direkt-Steuerung, RSE Ausführliche Informationen findest Du im gesonderten Wiki-Beitrag [Steuerbare Verbrauchseinrichtungen](https://github.com/openWB/core/wiki/Steuerbare-Verbrauchseinrichtungen) diff --git a/docs/Identifikation.md b/docs/Identifikation.md index 2fcb688871..f74b0b9b12 100644 --- a/docs/Identifikation.md +++ b/docs/Identifikation.md @@ -2,9 +2,9 @@ Mit den verschiedenen Identifikations-Möglichkeiten kannst du die openWB grunds Die Identifikation erfolgt über - * RFID-Tags: Setzt einen eingebauten RFID-Reader voraus. Dieser ist als optionales Zubehör für openWB Pro und openWB series2 erhältlich. Der Tag kann nach oder max. 5 Minuten vor dem Anstecken gescannt werden. - * Eingabe einer ID am Display: Setzt ein eingebautes Display voraus. - * Fahrzeugerkennung: Setzt eine openWB Pro und ein Fahrzeug, das diese Funktion unterstützt, voraus. (Permalink zur Übersicht im Forum) Zur Identifikation wird die MAC-Adresse des Fahrzeugs verwendet. Hat die Pro auch einen RFID-Reader, hat bei der Fahrzeug-Zuordnung die MAC-Adresse die höhere Priorität. Beim Entsperren wird beides geprüft. +* RFID-Tags: Setzt einen eingebauten RFID-Reader voraus. Dieser ist als optionales Zubehör für openWB Pro und openWB series2 erhältlich. Der Tag kann nach oder max. 5 Minuten vor dem Anstecken gescannt werden. +* Eingabe einer ID am Display: Setzt ein eingebautes Display voraus. +* Fahrzeugerkennung: Setzt eine openWB Pro und ein Fahrzeug, das diese Funktion unterstützt, voraus. (Permalink zur Übersicht im Forum) Zur Identifikation wird die MAC-Adresse des Fahrzeugs verwendet. Hat die Pro auch einen RFID-Reader, hat bei der Fahrzeug-Zuordnung die MAC-Adresse die höhere Priorität. Beim Entsperren wird beides geprüft. Die beschriebenen Identifikationsverfahren werden in der Software gleich ausgewertet. Es sind unterschiedliche Wege je nach Hardwareausstattung, die Information an die Software zu übergeben. Wenn ID-Tags genutzt werden sollen, dann ist in der Navigationsbar unter Einstellungen - Optionale Hardware unter dem Punkt Identifikation von Fahrzeugen die Option Identifikation aktivieren auf An zu stellen. @@ -18,15 +18,16 @@ Unter Einstellungen → Konfiguration → Ladepunkte → Ladepunkt-Profil kann f Im Menü Einstellungen → Konfiguration → Fahrzeuge können ID-Tags für das Fahrzeug hinterlegt werden. Wird einer dieser Tags erkannt, wird das Fahrzeug dem Ladepunkt zugeordnet. -Im Ladeprofil kann eingestellt werden, ob nach dem Abstecken das Standard-Fahrzeug zugeordnet werden soll. Andernfalls wird nach Abstecken das letzte vorher ausgewählte Fahrzeug zugeordnet. -Die Option Standard nach Abstecken macht nur Sinn, wenn neben dem Standard-Fahrzeug mindestens ein weiteres Fahrzeug und neben dem Standard-Lade-Profil mindestens ein weiteres Lade-Profil angelegt wurde. Dabei ist dem Standard-Fahrzeug das Standard-Lade-Profil und dem weiteren Fahrzeug das weitere Lade-Profil zuzuweisen. Wenn nur mit Identifikation geladen werden soll, muss im Standard-Lade-Profil der aktive Lademodus auf Stop gestellt werden. In den Lade-Profilen der anderen Fahrzeuge muss Standard nach Abstecken aktiviert werden. +Im Ladeprofil kann eingestellt werden, ob nach dem Abstecken das Standard-Fahrzeug zugeordnet werden soll. Andernfalls wird nach Abstecken das letzte vorher ausgewählte Fahrzeug zugeordnet. +Die Option Standard nach Abstecken macht nur Sinn, wenn neben dem Standard-Fahrzeug mindestens ein weiteres Fahrzeug und neben dem Standard-Lade-Profil mindestens ein weiteres Lade-Profil angelegt wurde. Dabei ist dem Standard-Fahrzeug das Standard-Lade-Profil und dem weiteren Fahrzeug das weitere Lade-Profil zuzuweisen. Wenn nur mit Identifikation geladen werden soll, muss im Standard-Lade-Profil der aktive Lademodus auf Stop gestellt werden. In den Lade-Profilen der anderen Fahrzeuge muss Standard nach Abstecken aktiviert werden. Über den ID-Tag wird ein Fahrzeug zugeordnet. Nach Abstecken wechselt die Auswahl dann auf Standardfahrzeug in den Lademodus Stop und der Ladepunkt startet keinen weiteren Ladevorgang, bis die Auswahl entweder händisch über das User Interface oder automatisch per ID-Tag auf ein Fahrzeug geändert wird, das sich z.B. im Lademodus Sofortladen befindet und laden darf. ### Use Cases #### Sperre nach Abstecken - + Sperre nach Abstecken kann an einem Ladepunkt verwendet werden, welcher das Laden gegenüber fremdem Zugriff sichert. Wird der ID-Tag nur zum Sperren/Entsperren des Ladepunktes verwendet, dann startet immer das ausgewählte Fahrzeug den Ladevorgang. Dies kann im privaten Bereich mit nur einem Fahrzeug sinnvoll sein, damit nur dieses Fahrzeug auch laden darf. Die Option ist aber auch für Ladeparks sinnvoll, bei denen die Ladepunkte nur für eine Gruppe von ID-Tags freischaltbar sind und dem ID-Tag zum Entsperren auch gleichzeitig zugeordnet sind. #### Standard nach Abstecken + Standard nach Abstecken kann an einem Ladepunkt verwendet werden, welcher das Laden mehrerer verschiedener Fahrzeuge ermöglichen soll. Werden mehrere Fahrzeuge mit verschiedenen Lade-Profilen und verschiedenen ID-Kennungen neben dem Standard-Fahrzeug angelegt, kann über die ID-Kennung zwischen den einzelnen Fahrzeugen gewechselt werden. Hier bietet sich beispielsweise ein privater Ladepunkt mit zwei Fahrzeugen an oder ein Ladepunkt in einer Firma mit verschiedenen Mitarbeitern. Standard nach Abstecken kann auch dazu verwendet werden, um beispielsweise zwischen zwei Fahrzeugen (und damit Fahrzeug-Profilen und Lade-Profilen) ohne ID-Tag zu wechseln, vor allem wenn nur eines der Fahrzeuge über die ID-Kennung zuverlässig erkannt wird. diff --git a/docs/Lademodi.md b/docs/Lademodi.md index 1d9f20cc3e..9ffb373f52 100644 --- a/docs/Lademodi.md +++ b/docs/Lademodi.md @@ -1,18 +1,19 @@ ### PV-Laden -Beim PV-Laden wird die Ladeleistung anhand des Überschusses am EVU-Punkt geregelt. Um ständiges Starten und Stoppen der Ladung zu verhindern, startet die Ladung, wenn für die Dauer der Einschaltverzögerung die Einschaltschwelle überschritten wurde. Die Ladung wird gestoppt, wenn für die Dauer der Abschaltverzögerung die Abschaltschwelle unterschritten wurde. + +Beim PV-Laden wird die Ladeleistung anhand des Überschusses am EVU-Punkt geregelt. Um ständiges Starten und Stoppen der Ladung zu verhindern, startet die Ladung, wenn für die Dauer der Einschaltverzögerung die Einschaltschwelle überschritten wurde. Die Ladung wird gestoppt, wenn für die Dauer der Abschaltverzögerung die Abschaltschwelle unterschritten wurde. Wenn ein Wechselrichter verbaut ist, bei dem die Einspeiseleistung reduziert wird - auch als 70%-Regelung bekannt -, kann dies mit dem Regelpunkt Einspeisegrenze eingestellt werden. ### Regelmodus -Die Ladeleistung kann nicht mit absoluter Genauigkeit eingestellt werden, sodass am EVU-Punkt nicht auf exakt 0W geregelt werden kann. Einige Fahrzeuge und ältere openWBs können zudem nur in Schritten von 1A regeln (entspricht 230W bei einphasiger Ladung). Der Regelmodus bestimmt, in welchem Bereich (ca. 200-300W) sich der EVU-Überschuss bewegen soll. Beim Regelmodus „Bezug“ darf ein geringer Netzbezug vorhanden sein, bevor nachgeregelt wird. Das Auto lädt dann etwas schneller, aber es wird mehr Netzstrom verbraucht. Im Regelmodus „Einspeisung“ kann etwas Strom ins Netz eingespeist werden, bevor nachgeregelt wird. Dann lädt das Auto etwas langsamer und es wird weniger Netzstrom verbraucht. -Der Regelbereich wird auf den gesamten Überschuss angewendet, bevor die PV-Regelung durchgeführt wird. D.h. der Regelbereich wird auf alle Einstellungen für das PV-Laden angewendet und nur einmal unabhängig von der Anzahl der angesteckten Fahrzeuge. Liegt der Überschuss am EVU-Punkt im vorgegebenen Regelbereich, wird nicht nachgeregelt. Liegt er außerhalb des Bereichs, wird die Lade-Leistung auf die Mitte des Bereichs angepasst. +Die Ladeleistung kann nicht mit absoluter Genauigkeit eingestellt werden, sodass am EVU-Punkt nicht auf exakt 0W geregelt werden kann. Einige Fahrzeuge und ältere openWBs können zudem nur in Schritten von 1A regeln (entspricht 230W bei einphasiger Ladung). Der Regelmodus bestimmt, in welchem Bereich (ca. 200-300W) sich der EVU-Überschuss bewegen soll. Beim Regelmodus „Bezug“ darf ein geringer Netzbezug vorhanden sein, bevor nachgeregelt wird. Das Auto lädt dann etwas schneller, aber es wird mehr Netzstrom verbraucht. Im Regelmodus „Einspeisung“ kann etwas Strom ins Netz eingespeist werden, bevor nachgeregelt wird. Dann lädt das Auto etwas langsamer und es wird weniger Netzstrom verbraucht. +Der Regelbereich wird auf den gesamten Überschuss angewendet, bevor die PV-Regelung durchgeführt wird. D.h. der Regelbereich wird auf alle Einstellungen für das PV-Laden angewendet und nur einmal unabhängig von der Anzahl der angesteckten Fahrzeuge. Liegt der Überschuss am EVU-Punkt im vorgegebenen Regelbereich, wird nicht nachgeregelt. Liegt er außerhalb des Bereichs, wird die Lade-Leistung auf die Mitte des Bereichs angepasst. Bei Speichervorrang erzeugt die Regelung bei Bedarf unabhängig vom eingestellten Regelmodus Einspeisung, damit der Speicher seine Ladeleistung erhöht. Achtung: bei unlogischen Einstellungen kann die Regelung gestört werden! Im Zweifel bitte unsere vordefinierten Modi verwenden. #### Speicherbeachtung -Sofern ein Hausstromspeicher (im Folgenden „Speicher“ genannt) im Energiesystem verbaut ist, kann dieser beim Fahrzeugladen mit berücksichtigt werden. Dies erfolgt passiv über die Berücksichtigung der Speicherleistungswerte und des Speicher-SoC. Eine aktive Speichersteuerung durch openWB ist aktuell mangels Speicherschnittstelle nicht möglich. -Bei Auswahl „Fahrzeuge“ wird der gesamte Überschuss in das EV geladen. Ist die maximale Ladeleistung der Fahrzeuge erreicht und es wird eingespeist, wird dieser Überschuss in den Speicher geladen. -Bei Auswahl „Speicher“ wird der gesamte Überschuss in den Speicher geladen. Ist die maximale Ladeleistung des Speichers erreicht und es wird eingespeist, wird dieser Überschuss unter Beachtung der Einschaltschwelle in die Fahrzeuge geladen. -Bei Auswahl „Mindest-SoC des Speichers“ wird der Überschuss bis zum Mindest-SoC in den Speicher geladen. Ist die maximale Ladeleistung des Speichers erreicht und es wird eingespeist, wird dieser Überschuss in die Fahrzeuge geladen. Wird der Mindest-SoC überschritten, wird der Überschuss ins Fahrzeug geladen. \ No newline at end of file +Sofern ein Hausstromspeicher (im Folgenden „Speicher“ genannt) im Energiesystem verbaut ist, kann dieser beim Fahrzeugladen mit berücksichtigt werden. Dies erfolgt passiv über die Berücksichtigung der Speicherleistungswerte und des Speicher-SoC. Eine aktive Speichersteuerung durch openWB ist aktuell mangels Speicherschnittstelle nicht möglich. +Bei Auswahl „Fahrzeuge“ wird der gesamte Überschuss in das EV geladen. Ist die maximale Ladeleistung der Fahrzeuge erreicht und es wird eingespeist, wird dieser Überschuss in den Speicher geladen. +Bei Auswahl „Speicher“ wird der gesamte Überschuss in den Speicher geladen. Ist die maximale Ladeleistung des Speichers erreicht und es wird eingespeist, wird dieser Überschuss unter Beachtung der Einschaltschwelle in die Fahrzeuge geladen. +Bei Auswahl „Mindest-SoC des Speichers“ wird der Überschuss bis zum Mindest-SoC in den Speicher geladen. Ist die maximale Ladeleistung des Speichers erreicht und es wird eingespeist, wird dieser Überschuss in die Fahrzeuge geladen. Wird der Mindest-SoC überschritten, wird der Überschuss ins Fahrzeug geladen. diff --git a/docs/Neues Modul programmieren.md b/docs/Neues Modul programmieren.md index ef3e9fbd44..e76061d3a8 100644 --- a/docs/Neues Modul programmieren.md +++ b/docs/Neues Modul programmieren.md @@ -34,6 +34,7 @@ Wenn von der Komponente die Zählerstände für Import und Export gelesen werden Bei Hybrid-Systemen erfolgt die Verrechnung von Speicher-und PV-Leistung automatisiert, wenn Speicher und Wechselrichter in der Hierarchie wie [hier](https://github.com/openWB/core/wiki/Hybrid-System-aus-Wechselrichter-und-Speicher) beschrieben angeordnet sind. Wenn noch weitere spezifische Berechnungen erforderlich sind, müsst Ihr die Komponenten wie unter sample_request_per_device abfragen. Die update-Methode der Komponenten wird dann in eine get- und set-Methode aufgeteilt. Die get-Methode liefert den Component-State zurück, dieser wird in der update_components-Methode des Geräts verrechnet und dann die set-Methode der Komponente aufgerufen, die die store-Methode der Komponente aufruft. #### Schnittstelle für die Speicher-Steuerung + Bei Speichern, die eine aktive Steuerung unterstützen, kann mit der Methode `set_power_limit` die Speicherleistung gesetzt werden. Die Speicher erben von der Klasse `AbstractBat`, die die abstrakte Methode `set_power_limit` beinhaltet. Bei der Implementierung des Speichers kannst Du diese Methode überschreiben. Die Regelung prüft am Ende, ob die Methode für den jeweiligen Speicher implementiert ist und ruft diese auf. Als Variable wird die Speicherleistung in Watt oder `None` übergeben, dann wird der Speicher nicht mehr aktiv von der openWB gesteuert und soll selbst anhand des EVU-Punktes regeln. ### Neues Fahrzeug programmieren diff --git a/docs/NextCloud als Sicherungs-Cloud einrichten.md b/docs/NextCloud als Sicherungs-Cloud einrichten.md index 9077e27424..d5fed7c2fd 100644 --- a/docs/NextCloud als Sicherungs-Cloud einrichten.md +++ b/docs/NextCloud als Sicherungs-Cloud einrichten.md @@ -10,13 +10,13 @@ Diesen Link in das Feld Cloud-URL in der openWB unter System -> Datenverwaltung Alternativ: Falls es Probleme gibt kann der Link auch folgendermaßen eingetragen werden: -Freigabelink z.B.: https://kim.nl.tab.digital/s/tUbHHrEdGltSRgx +Freigabelink z.B.: Wahl: BackupCloud: NextCloud Unterpunkt: Einstellungen für Backup-Cloud Modul "NextCloud" Cloud-URL: z.B.: OHNE /s/ oder / Benutzername: dein shared token, also z.B.: tUbHHrEdGltSRgx -Passwort: kann leergelassen oder irgendetwas eingetragen werden, spielt keine Rolle +Passwort: kann leer gelassen oder irgendetwas eingetragen werden, spielt keine Rolle Beide Varianten wurden getestet und funktionieren. diff --git a/docs/SoC-BMW-Mini.md b/docs/SoC-BMW-Mini.md index fa5e144e2b..ebc6b47d5e 100644 --- a/docs/SoC-BMW-Mini.md +++ b/docs/SoC-BMW-Mini.md @@ -9,6 +9,7 @@ Die Konfiguration des SoC-Moduls erfolgt in der Konfiguration des Fahrzeuges: Die Hilfe zu den Feldern kann durch Click auf das (?) angezeigt werden. In der Konfiguration des SoC-Moduls BMW&Mini ist Folgendes einzugeben: + - SoC-Modul: BMW & Mini - Intervalle zur Aktualisierung der Fahrzeugdaten - Auswahl: Nur Aktualisieren wenn angesteckt @@ -20,8 +21,10 @@ In der Konfiguration des SoC-Moduls BMW&Mini ist Folgendes einzugeben: Das Captcha-Token muss durch Lösen eines Captcha ermittelt werden. -Nach Eingabe des Captcha-Token und Sichern der Einstellung muss der SoC für das Fahrzeug sofort abgerufen werden. Dies geschieht mittels des Kreispfeils ineben der SoC-Anzeige auf der Hauptseite.
-Falls das nicht auf Anhieb klappt, muss es wiederholt werden.
+Nach Eingabe des Captcha-Token und Sichern der Einstellung muss der SoC für das Fahrzeug sofort abgerufen werden. Dies geschieht mittels des Kreispfeils neben der SoC-Anzeige auf der Hauptseite. + +Falls das nicht auf Anhieb klappt, muss es wiederholt werden. + Im SoC-Log (Einstellungen - System - Fehlersuche) können evtl. Fehlermeldungen eingesehen werden. Bei Fragen, Problemen, Kommentaren: [Support-Seite im openWB Forum](https://forum.openwb.de/viewtopic.php?t=4870) diff --git a/docs/SoC-OVMS.md b/docs/SoC-OVMS.md index b1c3764ef3..4cbdcab75e 100644 --- a/docs/SoC-OVMS.md +++ b/docs/SoC-OVMS.md @@ -1,4 +1,5 @@ # SoC-Modul OVMS + Das OVMS-Modul im Fahrzeug sendet je nach Ausführung die Daten über Mobilnetz und/oder WLAN an den OVMS-Server (z.B. ovms.dexters-web.de).
Die OVMS Smartphone-Apps (Android/ios) verbinden sich mit dem gewählten OVMS-Server.
Das SoC-Modul holt die Daten auch vom OVMS Server.
@@ -10,6 +11,7 @@ Die Hilfe zu jedem Feld kann durch Click auf das (?) angezeigt werden! ![SoC-OVMS-Einstellungen](SoC-OVMS-Settings.png) Nach den allgemeinen Einstellungen ist in den speziellen Einstellungen des SoC-Moduls OVMS Folgendes einzutragen: + - Server URL(incl. Port, z.B. `https://ovms.dexters-web.de:6869`) - User Id des Accounts im OVMS-Server - Passwort des Accounts diff --git a/docs/SoC-VWId.md b/docs/SoC-VWId.md index 92aacd1348..5e89033515 100644 --- a/docs/SoC-VWId.md +++ b/docs/SoC-VWId.md @@ -7,57 +7,64 @@ Für nicht-VW Fahrzeuge (Audi, Skoda, etc.) funktioniert das Modul nicht. **Wichtig für alle Fahrzeuge:** Es muss ein aktives Konto in myVolkswagen vorhanden sein und die "Volkswagen App" muss eingerichtet sein. - **WICHTIG:** -VW ändert gelegentlich die Bedingungen für die Nutzung der Online-Services.
-Diese müssen bestätigt werden.
-Wenn der SOC-Abruf plötzlich nicht mehr funktioniert, VOR dem Posten bitte Schritt 1 ausführen. +VW ändert gelegentlich die Bedingungen für die Nutzung der Online-Services. +Diese müssen bestätigt werden. Wenn der SOC-Abruf plötzlich nicht mehr funktioniert, VOR dem Posten bitte Schritt 1 ausführen. Bei Problemen zunächst bitte diese Schritte durchführen: -1. sicherstellen, dass auf diesen VW-Seiten alle Einverständnisse gegeben wurden.
- https://www.volkswagen.de/de/besitzer-und-nutzer.html
- https://vwid.vwgroup.io/landing-page
- In einigen Fällen wurden die Einverständnisse gegeben und trotzdem funktionierte die Abfrage nicht.
- Hier hat folgendes Vorgehen heholfen:
- Im Volkswagen Konto das Land temporär umstellen, d.h. +1. sicherstellen, dass auf diesen VW-Seiten alle Einverständnisse gegeben wurden. + + + + + + In einigen Fällen wurden die Einverständnisse gegeben und trotzdem funktionierte die Abfrage nicht. + Hier hat folgendes Vorgehen geholfen: Im Volkswagen Konto das Land temporär umstellen, d.h. - auf ein anderes Land als das eigene ändern - sichern - zurück auf das eigene Land ändern - sichern. -2. Nach einem manuellen SOC-Abruf (Kreispfeil hinter dem SOC clicken) auf der Status - Seite EV-SOC Log und Debug log auf Fehler kontrollieren -3. Falls im Ev-SOC Log ein fehlendes Modul gemeldet wird, z.B.
- `ImportError: No module named 'lxml' (LV0)`
-- in openWB 1.9 sicherstellen, dass 1.9.304 (Nightly) installiert ist. -- einen Reboot durchführen (Einstellungen - System - Reboot, Fahrzeug dazu abstecken!)
-Bei dem Neustart sollten fehlende Module installiert werden.
-Falls das nicht hilft gibt es den Support im Forum; dazu den Log der Startphase (1.9: Debug Log, 2.x Main Log) als code block () posten. +2. Nach einem manuellen SOC-Abruf (Kreispfeil hinter dem SOC klicken) auf der Status - Seite EV-SOC Log und Debug log auf Fehler kontrollieren +3. Falls im Ev-SOC Log ein fehlendes Modul gemeldet wird, z.B. + `ImportError: No module named 'lxml' (LV0)` + - in openWB 1.9 sicherstellen, dass 1.9.304 (Nightly) installiert ist. + - einen Reboot durchführen (Einstellungen - System - Reboot, Fahrzeug dazu abstecken!) + Bei dem Neustart sollten fehlende Module installiert werden. + Falls das nicht hilft gibt es den Support im Forum; dazu den Log der Startphase (1.9: Debug Log, 2.x Main Log) als code block () posten. 4. Falls im log evcc erwähnt wird: von VW ID (alt) auf VW ID umstellen. -5. Falls im Ev-Soc Log Fehler 303 (unknown redirect) gemeldet wird:
+5. Falls im Ev-Soc Log Fehler 303 (unknown redirect) gemeldet wird: - Ursache 1: Bestimmte Sonderzeichen im Passwort funktionieren nicht mit dem Modul. Bitte das Passwort auf eines ohne Sonderzeichen ändern und testen. - Ursache 2: Falsche Email, Passwort oder VIN eingegeben. Alle 3 löschen, speichern, neu eingeben, speichern und testen. 6. Falls eine Firewall im Spiel ist: Es gab einzelne Probleme beim Internet-Zugriff der openWB auf Python Archive und Fahrzeug-Server wenn IPV6 aktiv ist. -7. Nach Neustart bzw. Änderung der LP-Konfiguration werden im EV-Soc-Log Fehler ausgegeben (permission oder fehlende Datei).
-Diese Fehler sind normal und können ignoriert werden.
-Leider wird im Debug Mode 0 keine Positiv-Meldung ausgegeben.
-Empfehlung: In Einstellungen - System - Debugging dies einstellen: Debug Mode 1/Regelwerte
-Dann einen manuellen SOC-Abruf durchführen (im Dashboard auf Kreispfeil clicken).
-danach sollte im EV-SOC-Log eine Zeile ähnlich dieser kommen:
- - `2023-02-12 11:57:14 INFO:soc_vwid:Lp1 SOC: 61%@2023-02-12T11:53:20`
- - Diese Zeile zeigt folgende Information:
- `2023-02-12 11:57:14 - Timestamp des SOC-Abrufs`
- `INFO - Debug Level INFO`
- `soc_vwid - SOC-Modul`
- `Lp1 - Ladepunkt`
- `SOC: 61% - SOC Stand`
- `@2023-02-12T11:53:20 - Timestamp des Updates vom EV zum VW Cloud-Server`
- -8. Falls diese Schritte nicht zum Erfolg führen, das Problem im [Support Thema](https://forum.openwb.de/viewtopic.php?t=4803) posten mit Angabe relevanter Daten
+7. Nach Neustart bzw. Änderung der LP-Konfiguration werden im EV-Soc-Log Fehler ausgegeben (permission oder fehlende Datei). + + Diese Fehler sind normal und können ignoriert werden. Leider wird im Debug Mode 0 keine Positiv-Meldung ausgegeben. + Empfehlung: + - In Einstellungen - System - Debugging dies einstellen: Debug Mode 1/Regelwerte + - dann einen manuellen SOC-Abruf durchführen (im Dashboard auf Kreispfeil klicken). + - danach sollte im EV-SOC-Log eine Zeile ähnlich dieser kommen: + + `2023-02-12 11:57:14 INFO:soc_vwid:Lp1 SOC: 61%@2023-02-12T11:53:20` + + Diese Zeile zeigt folgende Information: + + `2023-02-12 11:57:14 - Timestamp des SOC-Abrufs` + + `INFO - Debug Level INFO` + + `soc_vwid - SOC-Modul` + + `Lp1 - Ladepunkt` + + `SOC: 61% - SOC Stand` + + `@2023-02-12T11:53:20 - Timestamp des Updates vom EV zum VW Cloud-Server` + +8. Falls diese Schritte nicht zum Erfolg führen, das Problem im [Support Thema](https://forum.openwb.de/viewtopic.php?t=4803) posten mit Angabe relevanter Daten - oWB SW Version - oWB gekauft oder selbst installiert - wenn selbst installiert: welches OS(Stretch/Buster) diff --git "a/docs/Steuerbare Verbrauchseinrichtungen nach \302\247 14a.md" "b/docs/Steuerbare Verbrauchseinrichtungen nach \302\247 14a.md" index e19f35df9b..549dea8aaf 100644 --- "a/docs/Steuerbare Verbrauchseinrichtungen nach \302\247 14a.md" +++ "b/docs/Steuerbare Verbrauchseinrichtungen nach \302\247 14a.md" @@ -1,12 +1,15 @@ Der Gesetzgeber sieht verschiedene Möglichkeiten für steuerbare Verbrauchseinrichtungen vor. Für jede steuerbare Verbrauchseinrichtung kann eine andere Option angemeldet werden. Bei der Konfiguration muss deshalb auch immer der/die Ladepunkte angegeben werden, für die die IO-Aktion angewendet werden soll. ### Dimmen per HEMS + Beim Dimmen wird eine maximale Bezugsleistung für alle steuerbaren Verbrauchseinrichtungen nach einer vorgegebene Formel ermittelt. Das Ergebnis dieser Formel muss bei der IO-Aktion `Dimmen` in der Einstellung `maximale Bezugsleistung` eingetragen werden. ACHTUNG: Die openWB kann aktuell nur die Ladepunkte berücksichtigen. Sind noch weitere steuerbare Verbraucher angemeldet, können diese über einen digitalen Ausgang angebunden werden. Da openWB die Leistung dieser Geräte nicht kennt, werden 4,2kW angenommen. Muss der Verbraucher seine Leistung begrenzen, wird der Ausgang auf 0V gesetzt. Für die korrekte Ermittlung der maximalen Bezugsleistung ist der Betreiber, nicht openWB oder die software2 verantwortlich. Vorhandener Überschuss kann zusätzlich zur maximalen Bezugsleistung verwendet werden. ### Dimmung per Direkt-Steuerung + Bei der Dimmung per Direkt-Steuerung wird jede steuerbare Verbrauchseinrichtung separat angesteuert und ihr Leistungsbezug auf 4,2kW gedimmt. Pro steuerbarer Verbrauchseinrichtung muss eine IO-Aktion konfiguriert werden und dort der Ladepunkt und der zugehörige Eingang angegeben werden. ### Rundsteuer-Empfänger-Kontakt (RSE) -Für den RSE-Kontakt kann ein Muster aus verschiedenen Eingängen und ein Prozentwert, auf den die Anschlussleistung begrenzt wird, angegeben werden. \ No newline at end of file + +Für den RSE-Kontakt kann ein Muster aus verschiedenen Eingängen und ein Prozentwert, auf den die Anschlussleistung begrenzt wird, angegeben werden. diff --git a/docs/Strompreisbasiertes Laden.md b/docs/Strompreisbasiertes Laden.md index 61457f74cb..3de589cb1a 100644 --- a/docs/Strompreisbasiertes Laden.md +++ b/docs/Strompreisbasiertes Laden.md @@ -1,11 +1,11 @@ -Einige Stromanbierter berechnen die Strompreise stundenweise anhand des Strompreises an der Börse. openWB bietet die Möglichkeit, die günstigen Zeiten optimal zu nutzen. Eine Übersicht über die unterstützten Anbieter findest Du hier: +Einige Stromanbierter berechnen die Strompreise stundenweise anhand des Strompreises an der Börse. openWB bietet die Möglichkeit, die günstigen Zeiten optimal zu nutzen. Eine Übersicht über die unterstützten Anbieter findest Du hier: Unter `Einstellungen → Ladeeinstellungen → Übergreifendes` muss der Stromanbieter konfiguriert werden. Die dort abgefragten Preise werden dann auch zur Berechnung der Ladekosten für den Netzanteil im Ladeprotokoll verwendet. Im Ladeprofil des Fahrzeugs muss das strompreisbasierte Laden aktiviert werden. Die Berücksichtigung des Strompreises in den verschiedenen Lademodi erfolgt folgendermaßen: - * Sofort- und Zeitladen: Es wird nur geladen, wenn der Strompreis unter dem maximalen angegeben Strompreis liegt. - * Zielladen: Die openWB berechnet anhand der eingestellten Stromstärke und Phasenanzahl für diesen Lademodus, wie lange geladen werden, muss um den konfigurierten SoC oder die konfigurierte Energiemenge zu erreichen. Dieses Ladefenster wird automatisch auf die günstigsten Stunden des Stromtarifs gelegt. Ist PV-Überschuss vorhanden, wird dieser immer zuerst genutzt und verkürzt das besagte Ladefenster. - * PV-Laden: keine Berücksichtigung des Strompreises +* Sofort- und Zeitladen: Es wird nur geladen, wenn der Strompreis unter dem maximalen angegeben Strompreis liegt. +* Zielladen: Die openWB berechnet anhand der eingestellten Stromstärke und Phasenanzahl für diesen Lademodus, wie lange geladen werden, muss um den konfigurierten SoC oder die konfigurierte Energiemenge zu erreichen. Dieses Ladefenster wird automatisch auf die günstigsten Stunden des Stromtarifs gelegt. Ist PV-Überschuss vorhanden, wird dieser immer zuerst genutzt und verkürzt das besagte Ladefenster. +* PV-Laden: keine Berücksichtigung des Strompreises -Wenn keine Preise abgefragt werden können, wird bei Sofort- und Zeitladen immer geladen und bei Zielladen zunächst mit PV-Überschuss und zum Erreichen des Zieltermins mit Netzstrom. \ No newline at end of file +Wenn keine Preise abgefragt werden können, wird bei Sofort- und Zeitladen immer geladen und bei Zielladen zunächst mit PV-Überschuss und zum Erreichen des Zieltermins mit Netzstrom. diff --git "a/docs/Typische-Anwendungsf\303\244lle.md" "b/docs/Typische-Anwendungsf\303\244lle.md" index 6d2bcf7ed2..ea2f18874c 100644 --- "a/docs/Typische-Anwendungsf\303\244lle.md" +++ "b/docs/Typische-Anwendungsf\303\244lle.md" @@ -1,7 +1,20 @@ +## Übersicht + +| Szenario | Konfiguration | +|---------------|---------------| +|Ich muss schnell weg und brauche ein voll geladenes Fahrzeug. | Sofortladen | +|Ich stecke mittags an, möchte PV nutzen und brauch am nächsten Morgen um 8:00 mindestens 75% SoC. | Zielladen | +|Ich habe einen dynamischen Stromtarif und stecke mittags an, möchte PV nutzen und brauch am nächsten Morgen um 8:00 mindestens 75% SoC. | Zielladen: Anhand der berechneten Ladedauer werden die günstigsten Stunden ermittelt und dann geladen.| +|Ich habe einen dynamischen Stromtarif und möchte nur laden, wenn Überschuss vorhanden ist oder der Strompreis unter einer von mir festgelegten Grenze liegt. | Eco | +|Ich möchte nur Überschuss laden. | PV | +|Ich möchte Überschuss laden. Falls ich spontan fahren möchte, brauche ich immer mind 40% SoC. | PV mit Mindest-SoC | +|Ich möchte Überschuss laden. Ich habe kein SoC-Modul und möchte das mein Auto immer etwas geladen wird, falls ich spontan fahren möchte. | PV mit Begrenzung Energiemenge | +|Für meinen Arbeitstag brauche ich mind 60% SoC. Falls Überschuss da ist, soll der auch in mein Auto geladen werden. Mein Auto soll immer mindestens 25% haben, falls ich spontan fahren möchte. | Zielladen und Zeitladen mit Begrenzung SoC | + ## Privater Haushalt, ein E-Auto und PV-Anlage In diesem Szenario sind die Ziele meistens, das Auto morgens für den Weg zur Arbeit fahrbereit zu haben, aber bis dahin möglichst viel Energie aus der PV-Anlage zum Laden zu nutzen. -Hierfür ist die Funktion *Zielladen* zu nutzen. Auch, wenn es vom Namen her scheint, dass nur zu einem festen Zeitpunkt eine definierte Energiemenge in das EV geladen sein soll, wird dennoch bis zum Beginn dieses erzwingenen Ladevorgangs PV-Energie, sofern vorhanden, genutzt. +Hierfür ist die Funktion *Zielladen* zu nutzen. Auch, wenn es vom Namen her scheint, dass nur zu einem festen Zeitpunkt eine definierte Energiemenge in das EV geladen sein soll, wird dennoch bis zum Beginn dieses erzwungenen Ladevorgangs PV-Energie, sofern vorhanden, genutzt. ![Zielladen](pictures/Anwendungsfaelle_zielladen.jpg) @@ -9,7 +22,7 @@ Einstellbar ist der Ziel SoC, der in vielen Fällen auf 80% eingestellt wird, da In dem oben gezeigten Beispiel ist der Ladestrom mit 13A eingestellt. Somit bleibt bei einem 3-phasigen 11kW-Lader noch Reserve, um die Stromstärke kurz vor Ende ggf. noch zu erhöhen. Als Zielzeit ist die Abfahrtzeit Abfahrt einzustellen. Die Regelung berechnet aus dem aktuellen SoC des Fahrzeugs, sowie aus den zwingend korrekt anzugebenden Maximalwerten der Ladeströme im Ladeprofil, den Zeitpunkt, an dem die Ladung starten muss. -Es empfielt sich den Ladestrom im Ladeprofil unter Zielladen etwas niedriger als die Möglichkeiten der Wallbox und des Fahrzeugs anzugeben, damit etwas Puffer vorhanden ist, falls das Auto zu spät angesteckt worden ist. +Es empfiehlt sich den Ladestrom im Ladeprofil unter Zielladen etwas niedriger als die Möglichkeiten der Wallbox und des Fahrzeugs anzugeben, damit etwas Puffer vorhanden ist, falls das Auto zu spät angesteckt worden ist. Falls das EV durch eine Standheizung vor Fahrtbeginn vorgeheizt werden soll, kann hierfür ein Zeitslot mit _Laden nach Zeitplan_ konfiguriert werden. Zeitladen kann zusätzlich zum gewählten Lademodus, hier Zielladen, aktiviert werden. So wird der Akku durch die Standheizung nicht belastet, sondern der Strom kommt aus dem EVU-Netz. Hier kann dann ein minimaler Strom von z.B. 6A gewählt werden, da die Leistungsaufnahme für die Heizung meist nicht mehr als 1kW benötigt. @@ -17,7 +30,7 @@ Falls das EV durch eine Standheizung vor Fahrtbeginn vorgeheizt werden soll, kan Wird das Fahrzeug außer der Reihe benötigt und es soll kurzfristig viel Energie in den Akku geladen werden, ist die openWB auf der Startseite auf *Sofortladen* zu stellen. Hier ist es möglich, mit der maximal verfügbaren Leistung den Akku so schnell wie möglich aufzuladen. -### Ausnutzen der PV-Anlage bei wechseldem Wetter +### Ausnutzen der PV-Anlage bei wechselndem Wetter Insbesondere im Frühling und Herbst kann die PV-Leistung bei bewölktem Himmel stark schwanken. Um ein häufiges Beenden und Starten des Ladevorgangs zu vermeiden, kann bei dem Modus PV ein *Minimaler Dauerstrom* eingestellt werden. Ist die Einstellung auf 0A, so wird ausschließlich mit solarem Überschuss geladen. Steigt die Netzeinspeisung über den in _Konfiguration->Ladeeinstellungen ->PV-Laden_ eingestellten Grenzwert, wird nach Ablauf der Einschaltverzögerung die Ladung gestartet. Mit der nächstgrößeren Einstellmöglichkeit 6A, wird (z.B. bei einphasigem Laden) kontinuierlich mit ~1,3kW geladen. Wird ins Netz eingespeist, wird die Ladeleistung hochgeregelt, sodass möglichst weder Strom eingespeist noch bezogen wird und, je nach Möglichkeiten des Fahrzeugs, auf 3-phasiges Laden umgeschaltet. @@ -26,9 +39,9 @@ Ist die Einstellung auf 0A, so wird ausschließlich mit solarem Überschuss gela ## Integration in Hausautomation -openWB eignet sich hervorragend zur Integration in eine bestehende Hausautomatins-Infrastruktur, da über den integrierten MQTT-Broker Befehle sowie Statusmeldungen ausgetauscht werden können. +openWB eignet sich hervorragend zur Integration in eine bestehende Hausautomation, da über den integrierten MQTT-Broker Befehle sowie Statusmeldungen ausgetauscht werden können. ### MQTT Zum Debugging empfiehlt sich das Programm [MQTT-Explorer?](http://mqtt-explorer.com/). -Eine detailierte Erklärung ist auf der [MQTT-Seite](https://github.com/openWB/core/wiki/MQTT) zu finden. +Eine detaillierte Erklärung ist auf der [MQTT-Seite](https://github.com/openWB/core/wiki/MQTT) zu finden. diff --git a/docs/WiCAN.md b/docs/WiCAN.md index f605d70bee..e4a29e3d62 100644 --- a/docs/WiCAN.md +++ b/docs/WiCAN.md @@ -1,105 +1,110 @@ # WiCAN-OBD2 mit manuellem SoC Modul der openWB -Mit Hilfe des WiCAN OBD2 Dongles von meatPi Electronics können die Werte des Fahrzeugs über die OBD2-Schnittstelle ausgelesen und im WLAN per MQTT an die openWB Wallbox gesendet werden. -In Verbindung mit dem manuellem SoC Modul der openWB ist hiermit die Nutzung ohne Cloud-Dienste der Fahrzeughersteller möglich. -https://github.com/meatpiHQ/wican-fw +Mit Hilfe des WiCAN OBD2 Dongles von meatPi Electronics können die Werte des Fahrzeugs über die OBD2-Schnittstelle ausgelesen und im WLAN per MQTT an die openWB Wallbox gesendet werden. +In Verbindung mit dem manuellem SoC Modul der openWB ist hiermit die Nutzung ohne Cloud-Dienste der Fahrzeughersteller möglich. + -Die erste Umsetzung erfolgte von zut im openWB Forum, der hierfür auch eine Unterstützung von Spritmonitor umgesetzt hat. Hierfür ist ein weiteres Gerät im Netzwerk nötig, auf dem ein kleines Programm (soc_helper) laufen kann: -https://forum.openwb.de/viewtopic.php?t=7451 +Die erste Umsetzung erfolgte von zut im openWB Forum, der hierfür auch eine Unterstützung von Spritmonitor umgesetzt hat. Hierfür ist ein weiteres Gerät im Netzwerk nötig, auf dem ein kleines Programm (soc_helper) laufen kann: + Im Laufe der weiteren Entwicklung wurde die Möglichkeit des automatischen Auslesen (AutoPID) in die Firmware des Gerätes integriert. Hierfür ist nun keine zusätzliche Hardware mehr nötig, da der Dongle die Daten direkt per MQTT an die openWB sendet. Die Unterstützung von Spritmonitor ist hiermit jedoch nicht möglich. Die Einrichtung dieser Funktion soll hier näher beschrieben werden. -### 1. Voraussetzungen +## 1. Voraussetzungen + * WiCAN Dongle mit Firmware 3.48, 4.03 oder neuer (4.00 ist fehlerhaft). * Konfiguration des Manuellen SoC Moduls im Fahrzeug der openWB. * WLAN Empfang im Bereich der openWB bzw. des Fahrzeugs. * Ggf. Beachtung einer Alarmanlage, die den OBD2 Port überwacht. -### 2. WiCAN Dongle +## 2. WiCAN Dongle + Die Beschaffung der Hardware ist zunächst die größte Hürde, da die Firma meatPi Electronics Ihren Sitz in Australien hat. -Es sind aktuell 2 Bezugsquellen bekannt: -https://github.com/meatpiHQ/wican-fw?tab=readme-ov-file#order-on-mouser-or-crowd-supply -Es ist hierbei darauf zu achten, dass nur der WiCAN-OBD2 oder der WiCAN PRO (Coming soon) verwendet werden kann. Bei Bestellung über Mouser erfolgt der Versand ab 50€ Versandkostenfrei, so dass sich idealerweise 2 oder mehr Besteller zu einer Sammelbestellung zusammentun können. +Es sind aktuell 2 Bezugsquellen bekannt: + +Es ist hierbei darauf zu achten, dass nur der WiCAN-OBD2 oder der WiCAN PRO (Coming soon) verwendet werden kann. Bei Bestellung über Mouser erfolgt der Versand ab 50€ Versandkostenfrei, so dass sich idealerweise 2 oder mehr Besteller zu einer Sammelbestellung zusammentun können. Achtung: Die angegeben Preise sind Nettopreise. -### 3. Konfiguration manueller SoC in openWB -* In der Fahrzeugkonfiguration der openWB muss das manuelle SoC Modul eingerichtet werden. Für die spätere Konfiguration der MQTT-Topics wird die Fahrzeug-ID benötigt. Diese kann man am besten auf der Status Seite der openWB auslesen: +## 3. Konfiguration manueller SoC in openWB + +* In der Fahrzeugkonfiguration der openWB muss das manuelle SoC Modul eingerichtet werden. Für die spätere Konfiguration der MQTT-Topics wird die Fahrzeug-ID benötigt. Diese kann man am besten auf der Status Seite der openWB auslesen: ![Status](pictures/WiCAN_openWB-Status.png "openWB Status") -### 4. Konfiguration WiCAN Settings +## 4. Konfiguration WiCAN Settings * Zunächst muss der WiCAN ins Heim-WLAN geholt werden: -https://meatpihq.github.io/wican-fw/config/wifi + -* Nun werden die weiteren Parameter konfiguriert: +* Nun werden die weiteren Parameter konfiguriert: ![WiCAN Settings](pictures/WiCAN_Settings.png "WiCAN Settings") * Protocol AutoPID wird zur automatischen Abfrage der PIDs benötigt (Bereich Automate) * MQTT zur openWB erfolgt mit leerem User und Passwort * RX und Status Topic müssen mit others/ beginnen, damit sie von openWB beachtet werden. Sie dienen nur der Fehleranalyse und Überwachung mit MQTT-Explorer. Für die eigentliche Funktion werden sie nicht benötigt. + --- + * Sleep Mode (Bereich Power Saving): Bei Unterschreiten der Sleep Voltage schaltet sich der WiCAN ab. Hierdurch wird ein Entladen der 12V Batterie verhindert. ![WiCAN Power Saving](pictures/WiCAN_PowerSaving.png "WiCAN Settings") -### 5. Ermittlung der PID Parameter aus dem Vehicle Profile bei meatPi +## 5. Ermittlung der PID Parameter aus dem Vehicle Profile bei meatPi Es werden bei meatPi die benötigten Parameter verschiedener Fahrzeuge in Vehicle-Profilen gesammelt. Die Informationen aus diesen Profilen können wir verwenden, um die Parameter, die wir für die openWB benötigen, zu ermitteln. -Die Profile sind hier einzeln verfügbar: -https://github.com/meatpiHQ/wican-fw/tree/main/vehicle_profiles +Die Profile sind hier einzeln verfügbar: + -Anhand des Beispiels eines VW:ID, die wichtigen Informationen (fettgedruckt). +Anhand des Beispiels eines VW:ID, die wichtigen Informationen (fettgedruckt). Wir benötigen zwingend den SoC, optional können wir auch die Reichweite (Range) gebrauchen: --- -{ - "car_model":"VW: ID", - **"init":"ATST96;ATFCSD300000;ATFCSM1;",** - "pids":[ - { - **"pid":"22028C1",** - **"pid_init":"ATSP7;ATCP17;ATSHFC007B;ATFCSH17FC007B;ATCRA17FE007B;",** +{ + "car_model":"VW: ID", + **"init":"ATST96;ATFCSD300000;ATFCSM1;",** + "pids":[ + { + **"pid":"22028C1",** + **"pid_init":"ATSP7;ATCP17;ATSHFC007B;ATFCSH17FC007B;ATCRA17FE007B;",** "parameters":[ { - "class":"battery", - **"expression":"B4\*0.4425-6.1947",** - **"name":"soc",** + "class":"battery", + **"expression":"B4\*0.4425-6.1947",** + **"name":"soc",** "unit":"%" } - ] - }, - { - **"pid":"222AB62",** - **"pid_init":"ATSP6;ATCP18;ATSH710;ATFCSH710;ATCRA77A;",** + ] + }, + { + **"pid":"222AB62",** + **"pid_init":"ATSP6;ATCP18;ATSH710;ATFCSH710;ATCRA77A;",** "parameters":[ { - "class":"none", - **"expression":"[B5:B6]",** - **"name":"range",** + "class":"none", + **"expression":"[B5:B6]",** + **"name":"range",** "unit":"km" } - ] + ] } -### 6. Übernahme der Werte für die Custom PIDs (Automate-Tab) +## 6. Übernahme der Werte für die Custom PIDs (Automate-Tab) die gefundenen Werte werden nun im Bereich Automate bei den Custom PIDs eingetragen: ![WiCAN Automate Tab](pictures/WiCAN_Automate.png "WiCAN Automate") -- Das Feld "Custom Initialisation" wird aus "**init**" vom Vehicle-Profile übernommen. -- Das Feld Name muss für den SoC "manual_soc" lauten, für die Reichweite "range". -- Falls vorhanden wird das Feld "Init" aus "**pid_init**" vom Vehicle-Profile übernommen. Dieses Feld kann auch leer sein, wenn für die einzelnen PIDs keine besondere Initialisierung benötigt wird. -- Das Feld PID wird aus "**pid**" übernommen. -- Das Feld Expression wird aus "**expression**" übernommen. -- Period(ms) ist das Intervall, in denen die Werte abgefragt werden. -- Im Feld "Destination Type" muss für den SoC "MQTT_Topic", für die Reichweite jedoch "MQTT_Wallbox" eingestellt werden. -- Im Feld Send_to muss die Fahrzeug ID aus der openWB, die wir in [Punkt 3](#3-konfiguration-manueller-soc-in-openwb) ermittelt haben, eingesetzt werden (...vehicle/**x**/...): - -Die Werte lauten für den SoC: -openWB/set/vehicle/**x**/soc_module/calculated_soc_state -Für die Reichweite: +* Das Feld "Custom Initialization" wird aus "**init**" vom Vehicle-Profile übernommen. +* Das Feld Name muss für den SoC "manual_soc" lauten, für die Reichweite "range". +* Falls vorhanden wird das Feld "Init" aus "**pid_init**" vom Vehicle-Profile übernommen. Dieses Feld kann auch leer sein, wenn für die einzelnen PIDs keine besondere Initialisierung benötigt wird. +* Das Feld PID wird aus "**pid**" übernommen. +* Das Feld Expression wird aus "**expression**" übernommen. +* Period(ms) ist das Intervall, in denen die Werte abgefragt werden. +* Im Feld "Destination Type" muss für den SoC "MQTT_Topic", für die Reichweite jedoch "MQTT_Wallbox" eingestellt werden. +* Im Feld Send_to muss die Fahrzeug ID aus der openWB, die wir in [Punkt 3](#3-konfiguration-manueller-soc-in-openwb) ermittelt haben, eingesetzt werden (...vehicle/**x**/...): + +Die Werte lauten für den SoC: +openWB/set/vehicle/**x**/soc_module/calculated_soc_state +Für die Reichweite: openWB/set/vehicle/**x**/get/range Das Ergebnis sieht dann z.B. so aus: @@ -108,41 +113,43 @@ Name|Init|PID|Expression|Period(ms)|Type|Send_to -|-|-|-|-|-|- manual_soc|ATSP7;ATSHFC007B;ATCP17;ATCRA17FE007B;ATFCSH17FC007B;|22028C1|B4*0.4425‑6.1947|10000|MQTT_Topic|openWB/set/vehicle/**3**/soc_module/calculated_soc_state range|ATSP6;ATSH710;ATCP18; ATCRA77A;ATFCSH710;|222AB62|[B5:B6]|10000|MQTT_Topic|openWB/set/vehicle/**3**/get/range -| -### Ergänzug zur openWB 1.9 -Bei openWB 1.9 wird das SOC Modul Manuell+Berechnung am Ladepunkt konfiguriert, das Topic benötigt hier den Typ MQTT_Wallbox. + +### Ergänzung zur openWB 1.9 + +Bei openWB 1.9 wird das SOC Modul Manuell+Berechnung am Ladepunkt konfiguriert, das Topic benötigt hier den Typ MQTT_Wallbox. Am Beispiel Ladepunkt 1 würde dies dann so aussehen: + Name|Init|PID|Expression|Period(ms)|Type|Send_to -|-|-|-|-|-|- manualSoC|ATSP7;ATSHFC007B;ATCP17;ATCRA17FE007B;ATFCSH17FC007B;|22028C1|B4*0.4425‑6.1947|60000|MQTT_Wallbox|openWB/set/lp/**1** -Nachtrag: openWB 1.9 aktzeptiert nur Ganzzahlige SOC-Werte und kann daher aktuell nicht verwendet werden. +Nachtrag: openWB 1.9 akzeptiert nur Ganzzahlige SOC-Werte und kann daher aktuell nicht verwendet werden. -### 7. Alarmanlage des Fahrzeugs +## 7. Alarmanlage des Fahrzeugs -Bei Fahrzeugen mit einer Alaramanlage wird häufig auch der OBD2-Port überwacht, so dass bei einer Abfrage die Alarmanlage auslöst. +Bei Fahrzeugen mit einer Alarmanlage wird häufig auch der OBD2-Port überwacht, so dass bei einer Abfrage die Alarmanlage auslöst. Um dieses Problem zu umgehen sind momentan folgende Lösungen bekannt: -- Bei einigen Fahrzeugen liegt an PIN1 des OBD2-Ports nur bei eingeschalteter Zündung eine Spannung von 12V an. Diese kann dann zur Versorung des WiCAN Dongles verwendet werden, so dass dieser bei abgeschalteter Zündung gar keine Spannungsversorgung hat. Normalerweise liegt an PIN16 die Versorgungsspannung für den WiCAN an. -Es kann also in doiesem Fall mit einem entsprechend "manipuliertem" Adapterkabel z.B. PIN1 und PIN16 getauscht werden: -https://forum.openwb.de/viewtopic.php?p=115467#p115467 -- Ggf. ist eine Anpassung der OBD2-Überwachung der Alarmanlage möglich: -https://www.born-forum.de/forum/thread/193-m%C3%B6gliche-codierungen-am-cupra-born-ohne-gew%C3%A4hr-auf-eigene-gefahr/?postID=77395#post77395 +* Bei einigen Fahrzeugen liegt an PIN1 des OBD2-Ports nur bei eingeschalteter Zündung eine Spannung von 12V an. Diese kann dann zur Versorgung des WiCAN Dongles verwendet werden, so dass dieser bei abgeschalteter Zündung gar keine Spannungsversorgung hat. Normalerweise liegt an PIN16 die Versorgungsspannung für den WiCAN an. +Es kann also in diesem Fall mit einem entsprechend "manipuliertem" Adapterkabel z.B. PIN1 und PIN16 getauscht werden: + +* Ggf. ist eine Anpassung der OBD2-Überwachung der Alarmanlage möglich: + Beide Lösungen dienen nur zur Info und erfolgen stets auf eigene Gefahr -### 8. Übersicht erfolgreich getesteter Fahrzeuge +## 8. Übersicht erfolgreich getesteter Fahrzeuge Abschliessend noch eine kurze Auflistung von bereits erfolgreich getesteten Fahrzeugen. Gerne kann und sollte diese Liste erweitert werden. Zur besseren Übersicht werden hier nur die tatsächlich verwendeten Fahrzeuge (am besten mit Modelljahr) sowie nur der SoC aufgeführt: -|Fahrzeug|Custom Initialisation|Name|Init|PID|Expression| -|-|-|-|-|-|-| -|CUPRA Born 2022|ATST96;ATFCSD300000;ATFCSM1;|manual_soc|ATSP7;ATCP17;ATSHFC007B;ATFCSH17FC007B;ATCRA17FE007B;|22028C1|B4*0.4425‑6.1947| -|Hyundai Ioniq (28 kWh) 2017|ATSP6;ATSH7E4;ATST96;|manual_soc||2105|B39/2| -|Peugeot iOn|ATSP6;ATFCSH761;ATFCSD300000;ATFCSM1;ATSH761;ATCRA762;|manual_soc||2101|(B4/2)‑5| -| +Fahrzeug|Custom Initialization|Name|Init|PID|Expression +-|-|-|-|-|- +CUPRA Born 2022|ATST96;ATFCSD300000;ATFCSM1;|manual_soc|ATSP7;ATCP17;ATSHFC007B;ATFCSH17FC007B;ATCRA17FE007B;|22028C1|B4*0.4425‑6.1947 +Hyundai Ioniq (28 kWh) 2017|ATSP6;ATSH7E4;ATST96;|manual_soc||2105|B39/2 +Peugeot iOn|ATSP6;ATFCSH761;ATFCSD300000;ATFCSM1;ATSH761;ATCRA762;|manual_soc||2101|(B4/2)‑5 + +Anmerkungen zur Tabelle: -Anmerkungen zur Tabelle: -Um einen Zeilenumbruch zu verhindern, müssen Leerzeichen durch einen "no-break space character" (\ ) und ein Minuszeichen durch "no-brak hyphen" (\‑) im Markdown Quelltext ersetzt werden. \ No newline at end of file +Um einen Zeilenumbruch zu verhindern, müssen Leerzeichen durch einen "no-break space character" (\ ) und ein Minuszeichen durch "no-break hyphen" (\‑) im Markdown Quelltext ersetzt werden. diff --git a/docs/samples/sample_electricity_tariff/tariff.py b/docs/samples/sample_electricity_tariff/tariff.py index ea23689b6d..fab002574f 100644 --- a/docs/samples/sample_electricity_tariff/tariff.py +++ b/docs/samples/sample_electricity_tariff/tariff.py @@ -5,7 +5,6 @@ from modules.common import req from modules.common.abstract_device import DeviceDescriptor from modules.common.component_state import TariffState -from modules.common.configurable_tariff import ConfigurableTariff log = logging.getLogger(__name__) diff --git a/packages/control/bat_all_test.py b/packages/control/bat_all_test.py index 35379d64ae..25122d5db5 100644 --- a/packages/control/bat_all_test.py +++ b/packages/control/bat_all_test.py @@ -157,7 +157,7 @@ class Params: ] -@ pytest.mark.parametrize("params", cases, ids=[c.name for c in cases]) +@pytest.mark.parametrize("params", cases, ids=[c.name for c in cases]) def test_get_charging_power_left(params: Params, caplog, data_fixture, monkeypatch): # setup b_all = BatAll() diff --git a/packages/modules/common/store/_inverter_test.py b/packages/modules/common/store/_inverter_test.py index 02687ee280..46b2c58092 100644 --- a/packages/modules/common/store/_inverter_test.py +++ b/packages/modules/common/store/_inverter_test.py @@ -37,7 +37,7 @@ def mock_data() -> None: ] -@ pytest.mark.parametrize("params", cases, ids=[c.name for c in cases]) +@pytest.mark.parametrize("params", cases, ids=[c.name for c in cases]) def test_fix_hybrid_values(params): # setup data.data.counter_all_data.data.get.hierarchy = params.hierarchy diff --git a/packages/modules/devices/byd/byd/bat.py b/packages/modules/devices/byd/byd/bat.py index 0770b272ef..6c42baf0c2 100644 --- a/packages/modules/devices/byd/byd/bat.py +++ b/packages/modules/devices/byd/byd/bat.py @@ -53,7 +53,7 @@ class BydParser(HTMLParser): values = {"SOC:": 0, "Power:": 0} armed = None - @ staticmethod + @staticmethod def parse(html: str): parser = BydParser() parser.feed(html) diff --git a/packages/modules/devices/growatt/__init__.py b/packages/modules/devices/growatt/__init__.py new file mode 100644 index 0000000000..e69de29bb2 diff --git a/packages/modules/devices/growatt/growatt/__init__.py b/packages/modules/devices/growatt/growatt/__init__.py new file mode 100644 index 0000000000..e69de29bb2 diff --git a/packages/modules/devices/rct/rct/rct_lib.py b/packages/modules/devices/rct/rct/rct_lib.py index 9023698e52..2b92c065b5 100644 --- a/packages/modules/devices/rct/rct/rct_lib.py +++ b/packages/modules/devices/rct/rct/rct_lib.py @@ -181,7 +181,7 @@ def __init__(self, command=0, address=0, frame_type=FRAME_TYPE_STANDARD): # add a rct_id item to a frame def add(self, item): - if type(item) == rct_id: + if isinstance(item, rct_id): if len(item.name) > self.name_len: self.name_len = len(item.name) if len(item.desc) > self.desc_len: @@ -534,9 +534,9 @@ def read(self, idList): # add all ids to a new frame def read_setup_frame(self, id): frame = Frame(cmd_read) - if type(id) == list: + if isinstance(id, list): for item in id: - if type(item) == rct_id: + if isinstance(item, rct_id): frame.add(item) else: obj = self.find_by_id(item) diff --git a/packages/modules/devices/sungrow/sungrow/modbus.md b/packages/modules/devices/sungrow/sungrow/modbus.md index d8bf7b210a..04a50389d2 100644 --- a/packages/modules/devices/sungrow/sungrow/modbus.md +++ b/packages/modules/devices/sungrow/sungrow/modbus.md @@ -1,13 +1,15 @@ -# Modbus Adressen für Sungrow SH* und SG* Wechselrichter +# Modbus Adressen für Sungrow SH\* und SG\* Wechselrichter -## Datengrundlage: -* TI_20230918_Communication Protocol of Residential and Commerical PV Grid-connected Inverter_V1.1.58_EN.pdf +## Datengrundlage + +* TI_20230918_Communication Protocol of Residential and Commercial PV Grid-connected Inverter_V1.1.58_EN.pdf * TI_20231019_Communication Protocol of Residential Hybrid Inverter_V1.1.2_EN.pdf * modbus_finder.py an SH10RT-V112 (LAN) Firmware SAPPHIRE-H_B001.V000.P005-20231027 * modbus_finder.py an SH10RT-V112 (WiNet-S) Firmware WINET-SV200.001.00.P023 * modbus_finder.py an SG10RT (WiNet-S) Firmware BERYL-S_B000.V000.P039-20230626 / WINET-SV200.001.00.P023 ## Werte + | Wert | SH_LAN | SH_WiNet | SG_WiNet | Einheit | Typ | Bemerkung | |-------------------------------------|--------|----------|---------------|---------|----------------|------------------------------------------------------------------| | WR: Zähler inkl. Batterieentladung | 5003 | 5003 | -- | 0.1 kWh | UINT_32 mixed | Delta zu 'WR: Zähler Gesamtertrag' ist entladene **Netz**energie | @@ -39,4 +41,4 @@ | Meter: AC Spannung Phase C | 5742 | -- | -- | 0.1 V | UINT_16 little | | | Meter: AC Strom Phase A | 5743 | -- | -- | 0.01 A | UINT_16 little | Immer positiv, auch bei Einspeisung | | Meter: AC Strom Phase B | 5744 | -- | -- | 0.01 A | UINT_16 little | Immer positiv, auch bei Einspeisung | -| Meter: AC Strom Phase C | 5745 | -- | -- | 0.01 A | UINT_16 little | Immer positiv, auch bei Einspeisung | \ No newline at end of file +| Meter: AC Strom Phase C | 5745 | -- | -- | 0.01 A | UINT_16 little | Immer positiv, auch bei Einspeisung | diff --git a/packages/modules/electricity_tariffs/fixed_hours/tariff.py b/packages/modules/electricity_tariffs/fixed_hours/tariff.py index 0a73ccb125..1353a5e61a 100644 --- a/packages/modules/electricity_tariffs/fixed_hours/tariff.py +++ b/packages/modules/electricity_tariffs/fixed_hours/tariff.py @@ -7,7 +7,6 @@ from modules.electricity_tariffs.fixed_hours.config import FixedHoursTariff, FixedHoursTariffConfiguration from modules.common.abstract_device import DeviceDescriptor from modules.common.component_state import TariffState -# from modules.common.configurable_tariff import ConfigurableTariff log = logging.getLogger(__name__) diff --git a/packages/modules/vehicles/polestar/api.py b/packages/modules/vehicles/polestar/api.py index 63847faae1..ec33c72cbc 100755 --- a/packages/modules/vehicles/polestar/api.py +++ b/packages/modules/vehicles/polestar/api.py @@ -2,6 +2,7 @@ from modules.common import req import time from modules.vehicles.polestar.auth import PolestarAuth +from typing import Optional, Dict from modules.common.component_state import CarState @@ -15,7 +16,7 @@ def __init__(self, username: str, password: str, vin: str) -> None: self.vin = vin self.client_session = req.get_http_session() - def query_params(self, params: dict, url='https://pc-api.polestar.com/eu-north-1/mystar-v2/') -> dict or None: + def query_params(self, params: dict, url='https://pc-api.polestar.com/eu-north-1/mystar-v2/') -> Optional[Dict]: access_token = self.auth.get_auth_token() if access_token is None: raise Exception("query_params error:could not get auth token") @@ -43,7 +44,7 @@ def query_params(self, params: dict, url='https://pc-api.polestar.com/eu-north-1 return result_data - def get_battery_data(self) -> dict or None: + def get_battery_data(self) -> Optional[Dict]: params = { "query": "query carTelematics($vin: String!) { carTelematics(vin: $vin) { " + "battery { batteryChargeLevelPercentage estimatedDistanceToEmptyKm } } }", diff --git a/packages/modules/vehicles/polestar/auth.py b/packages/modules/vehicles/polestar/auth.py index 464ae4587f..e0605f0308 100755 --- a/packages/modules/vehicles/polestar/auth.py +++ b/packages/modules/vehicles/polestar/auth.py @@ -4,6 +4,7 @@ import os import re from datetime import datetime, timedelta +from typing import Optional import base64 import hashlib from modules.common.store import RAMDISK_PATH @@ -90,7 +91,7 @@ def _save_token_to_ramdisk(self) -> None: log.error("_save_token_to_ramdisk:error saving token store %s:%s", self.token_file, e) # auth step 3: get token - def get_auth_token(self) -> str or None: + def get_auth_token(self) -> Optional[str]: # first try to load token from ramdisk self._load_token_from_ramdisk() @@ -159,7 +160,7 @@ def get_auth_token(self) -> str or None: return self.access_token # auth step 2: get code - def _get_auth_code(self) -> str or None: + def _get_auth_code(self) -> Optional[str]: self.resume_path = self._get_auth_resumePath() if self.resume_path is None: return None @@ -216,7 +217,7 @@ def _get_auth_code(self) -> str or None: return code # auth step 1: get resumePath - def _get_auth_resumePath(self) -> str or None: + def _get_auth_resumePath(self) -> Optional[str]: # Get Resume Path params = { "response_type": "code", diff --git a/packages/modules/vehicles/vwid/prepare_libvwid.sh b/packages/modules/vehicles/vwid/prepare_libvwid.sh index 25b1c03b41..5bde746a25 100755 --- a/packages/modules/vehicles/vwid/prepare_libvwid.sh +++ b/packages/modules/vehicles/vwid/prepare_libvwid.sh @@ -1,3 +1,4 @@ +#!/bin/bash echo "downloading libvwid.py from github to libvwid.org" curl -sS -o libvwid.org https://raw.githubusercontent.com/skagmo/ha_vwid/main/custom_components/vwid/libvwid.py @@ -19,7 +20,7 @@ s/ $// echo "checking libvwid.mod for flake8 issues" flake8 libvwid.mod > libvwid.flake8 -l=`wc -l libvwid.flake8 | awk '{print $1}'` +l=$(wc -l libvwid.flake8 | awk '{print $1}') if [ $l -eq 0 ] then echo "libvwid is flake8 clean"