Do not latch full on transient zero current; require explicit completion. Validate go-e errors and Pico status/timestamps, keep historical events diagnostic, and preserve faults until a fresh successful poll. Budget the 6 A phase probe through the manager and correct stale phase counts conservatively. Add adapter, regulator, isolated runtime and Symcon regression cases plus migration documentation. Verified: composer check (402 tests, 1875 assertions), 92 pure-function assertions in Symcon 8.0, git diff --check. No plant deployment or hardware commands.
This commit is contained in:
@@ -4,14 +4,14 @@
|
||||
|
||||
Das Modul bindet eine einzelne Ladestation direkt an Enelix EMS an. Es liest
|
||||
den Fahrzeug- und Ladezustand ueber die Geraete-API, ermittelt die Phasenzahl
|
||||
wie Enelix 1 und setzt den vom Manager gewaehlten Ladestrom. Es benoetigt keine
|
||||
aus aktuellen Messwerten und setzt den vom Manager gewaehlten Ladestrom. Es benoetigt keine
|
||||
Gateway-Instanz und hat keine technische Beziehung zum separaten Modul
|
||||
**Ladestation Gateway**.
|
||||
|
||||
## Funktionsumfang
|
||||
|
||||
- direkte Statusabfrage und Steuerung der unterstuetzten Ladestationen,
|
||||
- Fahrzeug-, Lade- und Phasenerkennung nach der Enelix-1-Logik,
|
||||
- Fahrzeug-, Lade- und Phasenerkennung mit geprueften Geraetedaten,
|
||||
- Leistungsangebote fuer PV- und Peakbetrieb,
|
||||
- lokale Freigabe und Umschaltung zwischen Solar- und Normalbetrieb,
|
||||
- Kommunikation mit dem Enelix Manager ueber den Nachrichtenvertrag `4.0`,
|
||||
@@ -34,26 +34,36 @@ Variable noch im Debug-Protokoll oder im Diagnosefeld
|
||||
|
||||
## Fahrzeug- und Phasenerkennung
|
||||
|
||||
Die Auswertung folgt bewusst dem Verhalten der bisherigen Enelix-1-Ladestation:
|
||||
Die Leistungsskalen bleiben kompatibel zu Enelix 1; die Fehler- und
|
||||
Ladeendeauswertung ist seit der Korrektur vom 07.10.2026 strenger:
|
||||
|
||||
1. Bei go-e gilt das Fahrzeug als verbunden, wenn `car != 1` ist. Bei Pico
|
||||
wird entsprechend `State != 1` ausgewertet.
|
||||
1. Nach erfolgreicher Statusvalidierung gilt das Fahrzeug bei go-e mit
|
||||
`car != 1` und bei Pico mit `State != 1` als verbunden. Fehler- und
|
||||
Offlinezustaende werden vorher abgewiesen.
|
||||
2. Die gemessene Leistung wird bei der alten go-e-API mit Faktor 10, bei
|
||||
Gemini direkt in Watt und bei Pico von kW in Watt umgerechnet.
|
||||
3. go-e meldet die drei Phasenstroeme einzeln. Sobald mindestens zwei Phasen
|
||||
Strom fuehren, wird dreiphasiges Laden direkt erkannt.
|
||||
3. go-e und Pico koennen die drei Phasenstroeme einzeln melden. Ab 1 A gilt
|
||||
eine Phase als belastet; mindestens zwei belastete Phasen werden konservativ
|
||||
als drei gerechnet. Frische Dreiphasenmessungen korrigieren gespeicherte
|
||||
Einphasigkeit. Bestaetigte Dreiphasigkeit bleibt konservativ bis zum Ausstecken
|
||||
erhalten, auch wenn zeitweise nur eine Phase belastet wird.
|
||||
4. Sind beim Anstecken noch keine belastbaren Phasenwerte vorhanden, gibt das
|
||||
Modul zunaechst nur den Mindeststrom von 6 A als Erkennungsstrom vor. Bis zur
|
||||
abgeschlossenen Erkennung bleibt `Phasenzahl=0` und das EMS-Angebot `[0]`.
|
||||
Modul `[0,4104] W` an: 6 A mit dem bestehenden Dreiphasenbudget. Eine
|
||||
zugeordnete Station startet erst nach passender Manager-Vorgabe. Bei
|
||||
Solarladen im Peakbetrieb bleibt das Angebot `[0]`; es gibt keinen direkten
|
||||
Probebefehl am Manager vorbei. `Phasenzahl=0` bleibt bis zur Erkennung erhalten.
|
||||
5. Nach `Phasenerkennungszeit` wird die gemessene Leistung relativ zum
|
||||
angeforderten Erkennungsstrom ausgewertet. Dadurch lassen sich eine und drei
|
||||
Phasen bereits bei 6 A unterscheiden. Die erkannte Phasenzahl bleibt bis
|
||||
zum Ausstecken erhalten und kippt waehrend einer Ladepause nicht zurueck.
|
||||
Phasen bereits bei 6 A unterscheiden. Unter 1265 W bleibt die Anzahl
|
||||
unbekannt, insbesondere bei 0 W. In einer Ladepause bleibt die zuletzt
|
||||
erkannte Anzahl erhalten; neue belastete Phasenmessungen koennen sie korrigieren.
|
||||
6. Der Ladestrom wird aus der Leistung mit `230 W/A` einphasig beziehungsweise
|
||||
`684 W/A` dreiphasig berechnet.
|
||||
7. Ein Ladeende wird nur nach zuvor tatsaechlich gemessener Ladeleistung
|
||||
erkannt. Eine vom EMS angeordnete Solarpause gilt deshalb nicht als
|
||||
`FahrzeugGeladen`.
|
||||
7. Nur ein explizites aktuelles Ladeende (go-e `car=4`) ohne relevante Last
|
||||
(< 1 A und < 100 W) setzt `FahrzeugGeladen`. Ein einzelner Nullwert und
|
||||
Ladepausen genuegen nicht. Neues Laden oder ein anderer aktueller Status
|
||||
hebt den Wert wieder auf. Die Pico-API hat keinen eindeutigen Voll-Status;
|
||||
dort wird deshalb kein Ladeende aus niedrigem Strom abgeleitet.
|
||||
|
||||
Der normalisierte `Fahrzeugstatus` verwendet folgende Werte:
|
||||
|
||||
@@ -82,7 +92,9 @@ stoppt die Ladestation.
|
||||
Die Leistungsstufen entsprechen Enelix 1: `230 W` pro Ampere einphasig und
|
||||
`684 W` pro Ampere dreiphasig. Ohne gueltige Manager-Vorgabe faehrt das Modul
|
||||
bei aktivem Solarladen mit `0 A`; bei ausgeschaltetem Solarladen verwendet es
|
||||
die maximale angebotene Leistung.
|
||||
die maximale angebotene Leistung. Ausnahme: Bei unbekannten Phasen und
|
||||
zugeordnetem Manager gibt es auch ohne Solarladen keinen Start ohne Budget.
|
||||
Ohne Manager kann die eigenstaendige Station im Normalbetrieb mit 6 A pruefen.
|
||||
|
||||
Beim Aktivieren oder Umschalten von Solarladen bleibt ein bereits gesetzter
|
||||
Geraetestrom zunaechst unveraendert. Das neue Angebot wird zuerst an den
|
||||
@@ -157,8 +169,8 @@ Immer sichtbar:
|
||||
| --- | --- | --- |
|
||||
| `Aktiv` | Boolean / bedienbar | Lokale EMS-Freigabe; der Initialwert ist `false`. |
|
||||
| `FahrzeugVerbunden` | Boolean / Anzeige | Zeigt, ob die API ein verbundenes Fahrzeug meldet. |
|
||||
| `FahrzeugGeladen` | Boolean / Anzeige | Ergebnis der kompatiblen Enelix-1-Voll-Erkennung. |
|
||||
| `Ladestrom` | Float / Anzeige | Aus der gemessenen Leistung ermittelter Ladestrom in A. |
|
||||
| `FahrzeugGeladen` | Boolean / Anzeige | Aktuell bestaetigtes Ladeende; bei Pico ohne eindeutiges API-Signal immer `false`. |
|
||||
| `Ladestrom` | Float / Anzeige | Groesster gemessener Phasenstrom, ersatzweise aus Leistung und bekannter Phasenzahl berechnet. |
|
||||
| `Phasenzahl` | Integer / Anzeige | `0` unbekannt, `1` einphasig oder `3` dreiphasig. |
|
||||
|
||||
Nur mit `EinstellungenInVisu=true` sichtbar; Ladefreigabe und Solarladen sind bedienbar:
|
||||
@@ -179,6 +191,7 @@ Nur mit `DiagnosevariablenAnzeigen=true` sichtbar:
|
||||
| `AenderungMoeglich` | Zeigt, ob das aktuelle Angebot mehr als eine Leistungsstufe enthaelt. |
|
||||
| `Stoerung` | Sammelstatus fuer Konfigurations- und Kommunikationsfehler. |
|
||||
| `Stoertext` | Letzte verstaendliche Fehlerbeschreibung. |
|
||||
| `Geraetehinweis` | Pico-Autorisierung und historisches letztes Ereignis, getrennt vom aktuellen Fehler. |
|
||||
| `LetzterGeraetebefehl` | Letzter Steuerbefehl mit HTTP-Methode und URL ohne Zugangsdaten; Statusabfragen ueberschreiben ihn nicht. |
|
||||
| `LeistungsangebotDiagnose` | Aktuelles Leistungsangebot als JSON-Liste in W. |
|
||||
|
||||
@@ -206,6 +219,7 @@ An den Manager werden neben den gemeinsamen Feldern diese Zustaende gemeldet:
|
||||
- `Ladefreigabe`
|
||||
- `Solarladen`
|
||||
- `Ladefehler` mit Stoertext
|
||||
- `Geraetehinweis`
|
||||
|
||||
Eine Sollleistung wird nur angenommen, wenn sie im zuletzt berechneten
|
||||
Leistungsangebot enthalten ist. Nach `VorgabeTimeout` ohne Erneuerung wird sie
|
||||
@@ -226,6 +240,51 @@ verwenden 5 Sekunden Verbindungs- und 10 Sekunden Gesamt-Timeout. Antworten ab
|
||||
HTTP-Status 400 sowie unvollstaendige oder ungueltige JSON-Antworten gelten als
|
||||
Kommunikationsfehler.
|
||||
|
||||
go-e muss `err=0` und einen bekannten `car`-Wert 1 bis 4 melden. Pico muss
|
||||
einen verwendbaren Zustand 1, 2, 3, 4 oder 6 sowie einen frischen `LastSeen`
|
||||
(ersatzweise `ValueDate`) liefern. Bei Ladezustand 4 oder positiver Leistung
|
||||
muss auch `ValueDate` frisch sein. Die Grenze liegt bei 120 Sekunden; mehr als
|
||||
15 Sekunden in der Zukunft oder ein Zeitstempel ohne Zeitzone sind ungueltig.
|
||||
Im Leerlauf wird das beobachtete `ValueDate=0001-01-01` toleriert, sofern
|
||||
`LastSeen` aktuell ist und keine Leistung gemeldet wird. CamelCase und PascalCase
|
||||
der Pico-Feldnamen werden unterstuetzt. Nicht-endliche/negative Messwerte
|
||||
werden abgewiesen.
|
||||
|
||||
Pico-Zustand 6 wartet auf Autorisierung und bietet `[0]`, ohne allein deshalb
|
||||
einen Kommunikationsfehler zu erzeugen. `LastWarningOrError` ist ein
|
||||
historisches Ereignis und wird nur als `Geraetehinweis` ausgegeben, nicht als
|
||||
dauerhaft aktiver Fehler interpretiert. `MaxStationCurrent` begrenzt die
|
||||
Stationsleistung; dynamische Grenzen von 0 A sind kein Hardwaremaximum.
|
||||
|
||||
Der lokale Statuscache gilt fuer drei Abfrageintervalle, mindestens 15 und
|
||||
hoechstens 120 Sekunden, bei Pico hoechstens bis zum Ablauf der API-Zeitstempel.
|
||||
Managerdaten erneuern diesen Cache nicht. Bei Fehler oder Ablauf werden Angebot
|
||||
und Vorgabe auf 0 gesetzt und die Station als nicht verfuegbar gemeldet. Der
|
||||
steuernde Pfad versucht bei zuvor gesetztem Strom eine Nullvorgabe; deren
|
||||
Scheitern wird zusaetzlich gemeldet. Eine API-Annahme ist keine Bestaetigung
|
||||
eines physischen Ladestopps. Erst eine frische gueltige Statusabfrage hebt den
|
||||
Fehler auf. Reine periodische Rueckmeldungen lesen nicht erneut per HTTP.
|
||||
|
||||
Herstellerquellen: [go-e API-Schluessel](https://github.com/goecharger/go-eCharger-API-v2/blob/main/API_KEYS_FIRMWARE/apikeys-en.md)
|
||||
und [smart-me OpenAPI](https://api.smart-me.com/swagger/v1/swagger.json),
|
||||
abgeglichen am 07.10.2026.
|
||||
|
||||
## Migration der Korrektur vom 07.10.2026
|
||||
|
||||
Vor Installation laufende Moduldateien und Konfiguration sichern und fremde
|
||||
Anpassungen vergleichen. Beim ersten `ApplyChanges` mit Erkennungsversion 2
|
||||
werden alte, moeglicherweise aus 0 W abgeleitete Phasen verworfen. Ein alter
|
||||
Voll-Status wird beim erneuten Lesen nur mit aktuellem explizitem Signal
|
||||
bestaetigt. Freigaben, Solarwahl, Prioritaeten, Objektkennungen und Zugangsdaten
|
||||
bleiben erhalten. Es wird kein Benutzerobjekt geloescht. Neue Phasenerkennung
|
||||
kann auf ausreichendes Managerbudget warten; das ist beabsichtigt.
|
||||
|
||||
Veroeffentlichung auf `develop`/`beta` aktualisiert die Anlage nicht. Nach einem
|
||||
separat freigegebenen Update frische Statusdaten, Phasen, PV/Peak-Angebote,
|
||||
Ladepause/Wiederanlauf und Abschaltung an echten Geraeten kontrollieren.
|
||||
Fuer einen Rollback die gesicherten Moduldateien und passenden Instanzzustand
|
||||
verwenden; keine fremden Laufzeitaenderungen ueberschreiben.
|
||||
|
||||
## Installation und Inbetriebnahme
|
||||
|
||||
1. Im IP-Symcon Module Control den Testing-Branch `develop` der Bibliothek
|
||||
@@ -259,11 +318,14 @@ niemals in Repository-Dateien, Skripte oder Screenshots.
|
||||
- Ohne Fahrzeug sind `FahrzeugVerbunden=false`, `Phasenzahl=0` und das
|
||||
Leistungsangebot `[0]`.
|
||||
- Nach dem Anstecken wird das Fahrzeug erkannt und bei unbekannten Phasen
|
||||
zunaechst der Mindeststrom von 6 A zur Erkennung angefordert.
|
||||
zunaechst `[0,4104]` angeboten. Nur mit Freigabe und Managerbudget beginnt
|
||||
die 6-A-Probe; Solar/Peak verhindert sie.
|
||||
- Nach der Erkennungszeit werden eine oder drei Phasen relativ zum Pruefstrom
|
||||
gespeichert. Bei go-e koennen die einzelnen Phasenstroeme die Erkennung
|
||||
bereits vorher abschliessen.
|
||||
gespeichert, sofern eine belastbare Leistung gemessen wird. Bei 0 W bleibt
|
||||
die Anzahl unbekannt; einzelne Phasenstroeme koennen die Erkennung vorziehen.
|
||||
- Die erkannte Phasenzahl bleibt bei einer anschliessenden Ladepause stabil.
|
||||
- Ein kurzzeitiger Nullwert setzt nicht `FahrzeugGeladen`; neues Laden bleibt moeglich.
|
||||
- go-e-Fehler und alte Pico-Zeitstempel sperren positive Angebote bis zur frischen gueltigen Abfrage.
|
||||
- Die gemessene Leistung wird plausibel in `Istleistung` und `Ladestrom`
|
||||
abgebildet.
|
||||
- `Aktiv=false` oder `Ladefreigabe=false` stoppt die Ladestation.
|
||||
@@ -286,23 +348,34 @@ niemals in Repository-Dateien, Skripte oder Screenshots.
|
||||
- Status `202`: Erreichbarkeit, DNS, lokale Firewall und API-Antwort pruefen.
|
||||
`Stoertext` enthaelt den konkreten Kommunikations- oder JSON-Fehler.
|
||||
- Fahrzeug wird nicht erkannt: Rohstatus der Geraete-API kontrollieren. Der
|
||||
Adapter erwartet bei go-e `car` und `nrg[11]`, bei Pico `State` und
|
||||
`ActiveChargingPower`.
|
||||
Adapter erwartet bei go-e `err`, `car` und `nrg[11]`, bei Pico `State`,
|
||||
`ActiveChargingPower` und die oben beschriebenen Zeitstempel.
|
||||
- Phasenzahl bleibt laenger auf `0`: Waehrend der Erkennungsphase muessen
|
||||
Ladestation und Fahrzeug den angeforderten Maximalstrom tatsaechlich
|
||||
freigeben. Bei Pico muss fuer eine sichere Dreiphasenerkennung waehrend der
|
||||
Erkennung mehr als 7500 W anliegen; go-e kann zusaetzlich anhand der
|
||||
einzelnen Phasenstroeme erkennen.
|
||||
Managerbudget, Freigabe und tatsaechliche Stromaufnahme vorliegen. Nullleistung
|
||||
bleibt unbekannt. Beide Adapter koennen einzelne Phasenstroeme nutzen; ohne
|
||||
diese Werte wird die Leistung nach einer budgetierten 6-A-Probe ausgewertet.
|
||||
- Manager-Vorgabe wird abgewiesen: aktive Zuordnung im Manager sowie
|
||||
`LeistungsangebotDiagnose` und die Betriebsart kontrollieren.
|
||||
|
||||
## Tests
|
||||
|
||||
Stand der Korrektur vom 07.10.2026: `composer check` erfolgreich mit 402 Tests
|
||||
und 1875 Assertions, einschliesslich isolierter Modullaufzeit. Zusaetzlich 92
|
||||
Assertions der reinen Adapter-/Reglerklassen im Symcon-8.0-Entwicklungskernel
|
||||
mit eigenem Test-Namespace erfolgreich. Der vollstaendige native Modultest
|
||||
unten wurde fuer diese Korrektur angepasst, aber nicht ausgefuehrt. Keine
|
||||
Stellbefehle an reale Hardware, kein Anlagenupdate und keine Feldabnahme.
|
||||
|
||||
Die Unit- und Adaptertests verwenden einen injizierten Fake-HTTP-Transport.
|
||||
Damit werden fuer go-e alt, go-e Gemini und smart-me Pico Statusantworten,
|
||||
URL, HTTP-Methode, Authentisierung und Steueraufrufe ohne reale Hardware
|
||||
geprueft.
|
||||
|
||||
Isolierte Laufzeittests fuehren zusaetzlich das echte Stand-alone-Modul mit
|
||||
simulierten Symcon-Aufrufen aus: Ladepause, Ladeende/Wiederanlauf, Budgetprobe,
|
||||
Peak-Sperre, Phasenkorrektur, Cacheablauf, Fehlerbeibehaltung und Migration.
|
||||
Diese Fake-IPS-Laufzeit darf niemals im echten Symcon-Kernel geladen werden.
|
||||
|
||||
Der Symcon-Funktionstest verwendet den internen `Testmodus` mit simulierten
|
||||
API-Antworten. Er prueft alle drei Geraetevarianten, die Mindeststrom-Probe
|
||||
beim Anstecken, stabile Phasen waehrend einer Ladepause, die Schaltsperren,
|
||||
|
||||
Reference in New Issue
Block a user