[Modul] NRG-Stack ChargerHub / Modbus-Modul für viele Wallboxen: go-eCharger, KEBA, Alfen, Heidelberg, ABL, DaheimLader, Fox ESS, Peblar (+ Netzwerksuche, Symbox-Gateway)

:loudspeaker: Update 19.09.2026: Seit diesem Beitrag ist viel passiert. Vier neue Hersteller (DaheimLader, ABL, Fox ESS, Peblar), ein Symbox-Gateway-Weg, Netzwerksuche für alle neuen Geräte und mehrere Korrekturen aus euren Rückmeldungen. Alle Neuerungen und den aktuellen Stand (0.9.91) findet ihr hier: Nachtrag mit allen Änderungen

Moin zusammen,

nach dem InverterHub (Wechselrichter) und dem MeterHub (Energiezähler) fehlte im Baukasten noch das Stück, das nicht nur misst, sondern eingreift: ChargerHub liest Wallboxen per Modbus TCP aus und steuert sie - Ladefreigabe, Stromlimit, beim go-eCharger auch die Phasenumschaltung. Wieder ein gemeinsames Treibergerüst statt eines eigenen Moduls je Hersteller; wer die beiden anderen kennt, findet sich sofort zurecht.

Ein Hersteller ist an echter Hardware verifiziert, einer gegen eine erprobte Referenzumsetzung abgeglichen, zwei sind aus der Herstellerdoku abgeleitet. Genau dafür suche ich Rückmeldungen.

Die zwei Module

  • ChargerHub - die Auslese- und Steuerinstanz. Hersteller wählen, IP eintragen, Datenpunkt-Gruppen aktivieren. Ein kleiner Kern (Ladestatus, Ladeleistung, Energie) ist immer aktiv, alles Weitere je Gruppe zuschaltbar.
  • ChargerHub Suche - durchsucht einen IP-Bereich und legt gefundene Wallboxen automatisch als Instanz an. Die Erkennung läuft über charakteristische Register mit Plausibilitätsprüfung, nicht über Rateverfahren.

Nur ein Regler je Wallbox - das eigentliche Thema

Bei Zählern und Wechselrichtern ist die Frage „wer schreibt?" meist schnell beantwortet. Bei Wallboxen ist sie das Problem, und sie wird gerade schlimmer:

  • der go-e Controller kann Überschussladen selbst regeln,
  • Tibber Grid Rewards vermarktet Regelenergie inzwischen über die Wallbox,
  • ein Lastmanagement verteilt Ströme über mehrere Ladepunkte,
  • ab EnWG §14a kommt die Dimm-Vorgabe des Netzbetreibers dazu,
  • und dann möchte auch noch ein Energiemanagement optimieren.

Alle greifen auf dieselbe Stellgröße zu. Setzen zwei davon gleichzeitig das Stromlimit, überschreiben sie sich gegenseitig - die Wallbox pendelt, und im Log sieht man nur, dass „irgendwer" den Wert geändert hat. Bei Tibber kann das sogar Geld kosten, weil eine zugesagte Regelenergie- Erbringung gestört wird.

Deshalb hat jede Instanz das Feld „Wer regelt diesen Ladepunkt?" — Niemand, Energiemanagement, go-e Controller, Tibber (Regelenergie), §14a-Steuerung, Direktvermarkter oder Sonstiges. Steht dort etwas anderes als „Niemand"/„Energiemanagement", meldet das Modul über seine Schnittstelle: Finger weg, hier regelt schon jemand — ein Energiemanagement liest den Ladepunkt dann nur noch mit. Bewusst von Hand gesetzt: Ob ein go-e Controller oder Tibber gerade mitregelt, steht in keinem Modbus-Register; das Modul könnte es allenfalls raten, und Raten ist hier die schlechteste Option.

Zwei weitere Bausteine für den Fall, dass dieselbe physische Wallbox über zwei Module gleichzeitig läuft (z. B. beim Umstieg auf OCPPHub, oder wenn eine Übergangszeit lang beide parallel angebunden sind): Ein Feld „Diese Wallbox ist dasselbe Gerät wie …" markiert eine Instanz als technische Dublette — das betrifft nur die Zählung (Summen/Sitzungen/Leistung überspringen sie zugunsten der ausgewählten), nicht die Steuerungshoheit, die weiterhin allein über „Wer regelt?" läuft. Eine Instanz kann also gleichzeitig als Dublette markiert UND der aktive Regler sein. Für den kompletten Stopp (Messen UND Steuern, z. B. eine endgültig abgelöste Alt-Instanz) gibt es zusätzlich CHUB_SetActive($id, bool) als Skript-Funktion. Und weil beim go-eCharger eine Ladefreigabe „Aus" geräteseitig eine harte Zwangs-Sperre setzt, die JEDEN Kanal (App, OCPP, Symcon) blockiert, bis sie wieder aufgehoben wird.

Darunter liegt eine zweite Grenze, die unabhängig von allem gilt: der maximale Anschlussstrom je Instanz. Was ein übergeordneter Regler anfordert, ist ein Wunsch - der Treiber klemmt jeden Schreibvorgang hart auf diesen Wert (und zusätzlich auf das Hardware-Maximum der Wallbox). Ein Rechenfehler im Energiemanagement soll nicht an der Zuleitung ankommen.

Unterstützte Wallboxen

Legende: :white_check_mark: an echter Hardware bestätigt · :wrench: gegen eine an echter Hardware erprobte Referenzumsetzung abgeglichen · :test_tube: aus Herstellerdoku umgesetzt (Feldrückmeldung willkommen)

Wallbox Status Anmerkung
go-eCharger (Gemini, HOME+, V3/V4) :white_check_mark: An zwei Geräten im Betrieb. Mit Abstand der größte Funktionsumfang: neben Status/Leistung/Energie auch Leistung je Phase, aktiv genutzte Phasen, Kabelcodierung, Adapter, RFID-Karte. Steuerbar: Ladefreigabe, Stromlimit, Phasenumschaltung, Zugangskontrolle, Kabelverriegelung, Energielimit je Ladevorgang, LED-Helligkeit. Die Steuerwerte werden vom Gerät zurückgelesen - was jemand in der App umstellt, ist in Symcon sichtbar
KEBA KeContact (P30, P40) :wrench: Registerkarte gegen die evcc-Umsetzung abgeglichen, die an realer Hardware erprobt ist. Ladestatus, Kabelstatus, Leistung, Energie gesamt + Ladevorgang, Strom/Spannung je Phase, Steuerung bis 63 A. P40: dort läuft die Ladefreigabe über das Stromlimit statt über ein eigenes Register - noch nicht gesondert behandelt
Alfen (Eve Single/Double Pro-line, NG9xx) :test_tube: Sockelstatus, Leistung, angewandtes Limit, Spannung/Strom je Phase, Steuerung. Alfen verlangt eine Gültigkeitsdauer für jeden Sollwert - das Modul erneuert sie mit. Derzeit nur Sockel 1
Heidelberg Energy Control :test_tube: Ladestatus, Leistung, Strom/Spannung je Phase, Platinentemperatur, Steuerung bis 16 A (mehr kann das Gerät nicht)

Alle Registeradressen stehen im Beschreibungsfeld jeder Variable (Objekt-Manager, Spalte „Beschreibung") - praktisch für den Abgleich mit dem Handbuch.

Das Wichtigste in Kürze

  • :electric_plug: Ein Modul, mehrere Hersteller - austauschbare Treiber, gemeinsame Konventionen.
  • :magnifying_glass_tilted_left: Netzwerksuche über Port 502 mit Abbrechen-Knopf und Fortschrittsanzeige.
  • :gear: Steuerung aus Symcon heraus - Ladefreigabe und Stromlimit per Skript, Ablaufplan oder Energiemanagement; beim go-eCharger zusätzlich die Phasenumschaltung, der wichtigste Hebel beim Überschussladen (einphasig ab ~1,4 kW, dreiphasig ab ~4,2 kW).
  • :shield: Maximaler Anschlussstrom je Instanz - harte Grenze bei jedem Schreibvorgang.
  • :vertical_traffic_light: Regler-Kennzeichnung für Ladepunkte, die schon jemand anderes regelt (siehe oben), plus Dubletten-Markierung für dieselbe Wallbox über zwei Module.
  • :test_tube: Vorführmodus für öffentliche Demo-Instanzen - Steuerung serverseitig gesperrt, Messwerte bleiben normal sichtbar.
  • :card_index: RFID-Kartenzähler beim go-eCharger (Name + Energie je Karte) - kommt nur über MQTT, kein Modbus-Register dafür vorhanden.
  • :link: CHUB_GetFunctions($id) - dieselbe Schnittstellenidee wie MHUB_GetFunctions: Leistungs- und Energievariablen, Steuer-IDs, Fahrzeugerkennung, Geräteidentität (Seriennummer/Host/ Hersteller, fürs Erkennen derselben Wallbox über mehrere Module) und die Regler-/Dubletten- Kennzeichnung als JSON.

Anschluss-Besonderheiten (kurz)

  • go-eCharger: Modbus muss in der go-e-App erst freigeschaltet werden (Internet → Erweiterte Einstellungen → Modbus). Und dann der Stolperstein, der hier einen Abend gekostet hat: Steht die Einstellung bereits auf „aktiv", heißt das nicht, dass der Server läuft — einmal aus- und wieder einschalten hilft. Prüfen lässt sich das im Browser mit http://<wallbox-ip>/api/status?filter=men. Solange Port 502 zu ist, findet die Suche schlicht nichts. Firmware 60.3 vertauschte außerdem die Byte-Reihenfolge (dafür gibt es einen Schalter, mit 60.4 behoben). Kleine Besonderheit am Rande: go-e unterstützt kein Schreiben einzelner Register - alles läuft über FC 0x16.
  • KEBA: Unit-ID werkseitig 255. Alle Werte sind 32 Bit über zwei Register - auch der Ladestatus. Wer ihn als einzelnes Register liest, bekommt immer 0 und sucht den Fehler lange an der falschen Stelle. (Ja, genau das war hier der erste Versuch.)
  • Alfen / Heidelberg: Unit-ID werkseitig 1, Port 502.
  • Alfen: Eve Double bedient derzeit nur Sockel 1.

Installation

Über den Module Store installierbar - Kanal Beta auswählen (Modulverwaltung → Modul hinzufügen → Store, „NRG-Stack ChargerHub" suchen, Kanal auf Beta stellen).

Status und was ich brauche

Das Ganze ist Beta und frisch. Rückmeldungen sind ausdrücklich erwünscht - bitte mit Hersteller, Modell und betroffenem Register/Wert.

Ganz konkret fehlt mir Hardware für:

  • Alfen Eve - kein Gerät zur Hand, der Treiber ist reine Doku-Arbeit. Wer eine Eve besitzt und einen Blick riskieren mag: sehr gerne. Beim Eve Double interessiert mich besonders der zweite Sockel, den ich dann nachziehen kann.
  • Heidelberg Energy Control - dito.
  • KEBA P40 - die Ladefreigabe funktioniert dort anders als beim P30. Mit einer Rückmeldung baue ich das sauber ein.

Und zwei Wallboxen stehen auf der Liste, mir fehlen die Registertabellen:

  • Vestel EVC04 und Webasto Unite (gleiche Plattform - ein Treiber, zwei Marken)
  • ABB Terra AC

Wer eine Modbus-Adressliste oder eine funktionierende Symcon-Vorlage hat: her damit. Geraten wird nicht - falsche Registeradressen liefern still falsche Werte, und bei einem Gerät, das 11 kW schaltet, ist das keine akademische Frage.

Die Modulfamilie: der NRG-Stack

ChargerHub steht nicht allein. Über die Zeit ist ein ganzer Baukasten entstanden - der NRG-Stack -, dessen Teile zusammenarbeiten, aber jedes Modul läuft auch für sich. Es gibt keine Pflichtabhängigkeiten: Fehlt der Partner, fällt nur dessen Zusatzfunktion weg.

Für ChargerHub heißt das: Ohne Partner ist es eine Wallbox-Anbindung mit Handsteuerung - Ladefreigabe und Stromlimit per Skript oder Ablaufplan, das reicht für „lade nachts" oder „lade nur mit 8 A" völlig. Mit MeterHub und InverterHub daneben kennt das Energiemanagement Erzeugung, Netzbezug und Verbrauch - und kann daraus echtes Überschussladen machen, inklusive Umschalten zwischen ein- und dreiphasig.

Was noch kommt

  • Weitere Hersteller, priorisiert nach Verbreitung und danach, ob sie überhaupt Modbus TCP sprechen. Das ist die unangenehme Wahrheit dieses Marktsegments: Einige der meistverkauften Wallboxen (easee, Wallbox Pulsar Plus) bieten lokal gar kein Modbus an, sondern nur Cloud oder Bluetooth - die sind mit diesem Ansatz grundsätzlich nicht erreichbar. Nächste Kandidaten sind deshalb Vestel/Webasto, ABB Terra AC, SMA EV Charger und Mennekes Amtron.
  • Phasengenaues Stromlimit bei Wallboxen, die das können, statt eines Summenlimits.
  • Alfen Eve Double - zweiter Ladepunkt.
  • §14a-Anbindung: Kommt die Steuerbox, wird die Dimm-Vorgabe nicht in dieses Modul wandern, sondern in ein eigenes. Eine gesetzliche Vorgabe darf nicht davon abhängen, ob gerade ein Energiemanagement läuft; und der Anschlussstrom-Riegel hier unten greift ohnehin unabhängig davon.

Danke fürs Lesen - und fürs Testen! :raising_hands:

Wow, das ist ja mal ein Paket/Übersicht. Frage: ich habe eine ältere ABL eMH1, die habe ich aktuell über Symcon-Modbus (über Ethernet/Rs422 Adapter) und deren json-Template eingebunden. Funktioniert auch, aber kann man die auch steuern und damit bei dir einbinden? Sehr cool ist natürlich auch der Mirgrations-Hub! Danke!

Gruß Michael

Moin Michael,

danke! ABL eMH1 steht noch nicht auf meiner Liste, aber grundsätzlich spricht nichts dagegen - Modbus ist Modbus, ob per TCP oder per RS422-Adapter dahinter. Steuern (Ladefreigabe, Stromlimit) würde technisch genauso laufen wie bei den anderen Herstellern.

Was ich dafür brauche, um das sauber (nicht geraten) einzubauen:

  • Die Modbus-Registertabelle der eMH1 (Adressen, Datentyp, Skalierung) - hast du die vom Hersteller, oder lässt sich das aus deinem JSON-Template extrahieren?
  • Unit-ID und Port, mit denen dein Adapter aktuell angesprochen wird
  • Ob die eMH1 überhaupt schreibend ansprechbar ist (manche RS422-Adapter/Gateways sind nur lesend durchgereicht) - sonst bliebe nur Auslesen möglich, keine Steuerung

Wenn du mir das JSON-Template oder eine Registerliste schicken kannst (hier im Thread oder per PN), schaue ich mir das gerne an und sage dir ehrlich, wie viel Aufwand das wäre.

Und ja, MigrationsHub ist ein eigenes Modul dafür - falls du irgendwann von deinem jetzigen Modbus-Template-Setup zu einer ChargerHub-Instanz wechseln willst, übernimmt das die Historie (Zählerstände/Archiv), damit nichts bei null anfängt.

Gruß

das wäre natürlich super. Allerdings macht das Teil ASCII-ModBus.

Hier der Link auf die API-Schnittstellen Beschreibung seitens ABL. Ich hoffe, du kann was damit anfangen…

Danke und Gruß Michael

Moin Michael,

danke fürs Dokument! Ehrliche Rückmeldung, damit keine falschen Erwartungen entstehen:

Das ist technisch aufwändiger als andere Wallboxen, aus zwei Gründen:

Anderes Protokoll, nicht nur andere Register. Das Dokument beschreibt Modbus ASCII über RS485, kein binäres Modbus TCP. Ob das mit unserem bestehenden Modbus-Client kompatibel ist, hängt davon ab, was dein Ethernet/RS422-Adapter tut: wandelt er wirklich in binäres Modbus TCP um (echtes Protokoll-Gateway), oder reicht er nur die rohen ASCII-Bytes durch (reiner Serial-Tunnel)? Im zweiten Fall bräuchte es einen komplett neuen Softwarebaustein, keinen einfachen Registertabellen-Nachtrag. Kannst du dazu was sagen, oder es an deinem aktuellen Symcon-Modbus-Setup ablesen (spricht es normales FC 0x03/0x10, oder brauchte es ein Spezial-Template für ASCII-Framing)?
Keine Energiezählung in diesem API-Auszug. Das Dokument deckt nur Status, Strom je Phase und Ladestrom-Vorgabe ab, kein Register für den Gesamtenergiezähler. Unser Modul erwartet normalerweise auch eine Energievariable dafür.
Grundsätzlich ist das Protokoll gut dokumentiert und machbar, aber eben kein schneller Nachtrag wie bei den anderen Kandidaten auf meiner Liste, sondern ein eigenes kleines Stück Arbeit. Wenn du mir die Antwort zu Punkt 1 geben kannst, weiß ich genauer, wie groß der Aufwand wirklich ist.

Gruß Dietmar

Hallo Dietmar,
alles kein Problem… die hat in der wohl nur die von dir aufgeführten Stati. Da ich ein Shelly EM3 in der Zuleitung habe, kenn ich auch die jeweiligen Leistungen und Gesamtleistung.
Insofern alles ok.
Gruß Michael

Moin Michael,

danke, dann ist der Energiezähler-Punkt geklärt - Shelly EM3 reicht dafür völlig.

Eine Frage brauche ich aber noch, um den Aufwand realistisch einzuschätzen: Was für ein Ethernet/RS422-Adapter ist das genau (Hersteller/Modell)? Konkret interessiert mich, ob er

  1. das Modbus-ASCII-Protokoll wirklich in normales binäres Modbus TCP umwandelt (ein „echtes“ Protokoll-Gateway), oder
  2. nur die rohen seriellen Bytes 1:1 über Ethernet durchreicht (reiner Transparent-Tunnel, das ASCII-Framing bleibt dabei erhalten).

Falls du in Symcon schon ein generisches Modbus-Modul oder dein JSON-Template gegen dieses Gerät laufen hast: schau mal, ob dort Funktionscode 0x03/0x10 direkt funktioniert, oder ob im Template irgendwo von ASCII-Framing, Doppelpunkt-Start-Byte oder LRC die Rede ist. Das sagt mir, welchen der beiden Fälle wir haben.

Gruß Dietmar

Moin Dietmar,

der Wandler ist ein reiner RS485 to Ethernet. Der kann kann kein Modbus TCP, also wohl nur reines ASCII. In Symcon ist das über „Modbus ASCII über TCP“ eingebunden.

Da ich von dem ganzen nichts verstehe :woozy_face:, anbei das json-template.

Vielleicht kannst damit was anfangen, aber mach den Aufwand nicht so groß, es läuft ja…

Gruß Michael

ablmodbusemh1_v1.json (45,2 KB)

Hallo @Bricoleur,

ich hätte als Wunsch noch die Wallboxen von daheimlader.de. Das Modbus Protokoll habe ich mal angehangen.

Gruß Mike

DaheimLadenModbus0726.pdf (107,1 KB)

Moin Michael,

Update zu ABL eMH1: Ich habe einen eigenen Treiber gebaut (ChargerHub 0.9.75-beta.1, Kanal Beta im Symcon Store bzw. Branch beta auf GitHub).

Was funktioniert:

  • Ladestatus (Zustands-Byte laut deinem Symcon-Template)
  • Strom je Phase (1 A-Auflösung)
  • Ladeleistung - geschätzt aus den drei Phasenströmen × 230 V, da euer API-Subset kein echtes Leistungsregister hat
  • Energie gesamt - neu dazugekommen, ebenfalls eine Schätzung: aus der geschätzten Leistung über die Zeit aufintegriert (Software-Zählung), kein echtes Zählerregister vorhanden. Kann von deinem Shelly EM3 abweichen, gerade bei kurzen Ladevorgängen oder nach einer Pause der Instanz.
  • Ladefreigabe und Stromlimit (6-32 A) über das dokumentierte Icmax-Register (100 % Duty-Cycle = „kein Strom erlaubt“ laut eurer Doku)

Was bewusst NICHT drin ist:
Das Zustandsmaschinen-Register 0x0005 (Sprung zwischen internen Betriebszuständen) wird nicht angefasst. Ein falscher Zustandswechsel ohne Testhardware wäre ein echtes Risiko, nicht nur ein falscher Messwert - deshalb läuft die Ladefreigabe ausschließlich über den sauber dokumentierten Icmax-Weg.

Technischer Hintergrund, falls interessant:
ABL spricht über deinen RS485-zu-Ethernet-Wandler kein binäres Modbus TCP, sondern Modbus ASCII (bestätigt durch deine Angabe, reiner Wandler ohne Protokoll-Gateway). Dafür gibt es jetzt einen eigenen Transport-Client im Modul, das Framing habe ich Byte für Byte gegen die Beispiele aus eurem PDF nachgerechnet.

Was ich von dir brauche:
Alles oben ist ungetestet an echter Hardware. Magst du es ausprobieren? Hersteller auf „ABL“ stellen, IP/Port deines Wandlers eintragen, Unit-ID normalerweise 1 oder wie in deinem Template hinterlegt. Rückmeldung gerne mit: Passt der Ladestatus zu dem, was die Wallbox gerade wirklich macht? Reagiert die Ladefreigabe? Bei Fehlern am besten die genaue Meldung aus dem IP-Symcon-Meldungsprotokoll dazu.

Danke nochmal fürs PDF und die Geduld!

Gruß
Dietmar

Hi Mike,

danke fürs PDF - DaheimLader war ein sehr sauberes, vollständiges Protokoll, direkt umgesetzt (ChargerHub 0.9.75-beta.1, Kanal Beta im Symcon Store bzw. Branch beta auf GitHub).

Was funktioniert:

  • Ladestatus (Standby/Verbunden/Startbereit/Laden/Fehler/etc., alle 10 Werte aus eurer Doku)
  • Kabelstatus, Fehlercode (mit Klartext für alle dokumentierten Fehlerarten)
  • Strom, Leistung und Spannung je Phase
  • Zählerstand (echtes Energiezählerregister, keine Schätzung nötig)
  • Energie und Dauer der aktuellen Ladesitzung
  • Seriennummer
  • Steuerung: Ladefreigabe über den Start/Stopp-Befehl, Stromlimit (aktuell bis 32 A als Software-Obergrenze, in der Instanz änderbar)
  • Bei den PRO-Modellen (Smart PRO, Touch PRO, Business PRO) zusätzlich die Phasenumschaltung (1-/3-phasig)

Was noch nicht drin ist:
RFID-Kartenauslesung (Register 54) und die „Ausfall Strom/Timeout“-Einstellungen (Register 87/89, laut Doku ohnehin nur bei Nicht-PRO-Geräten) - kam mir für den ersten Wurf nicht kritisch genug vor, kann aber bei Bedarf nachgezogen werden.

Was ich von dir brauche:
Ungetestet an echter Hardware. Magst du es ausprobieren? Hersteller auf „DaheimLader“ stellen, IP eintragen (Unit-ID standardmäßig 255, Port 502). Interessant wäre besonders:

  • Welches Modell genau hast du (Smart, Touch, oder eine PRO-Variante)?
  • Passen die Werte (Ladestatus, Ströme, Zählerstand)?
  • Falls PRO: Funktioniert die Phasenumschaltung?

Danke für die Vorlage, das war eine angenehm unkomplizierte Umsetzung!

Gruß
Dietmar

Hallo @Bricoleur,

ich habe den Touch Pro. Grundsätzlich funktioniert es. Aber die Ladeinstellung ist merkwürdig. Bei eingestellten 6A lädt die Wallbox mit 5,8-5,9A und 4000 Watt. Bei 16A lädt sie mir 14,7-14,9 A und 11000 Watt. Das noch korrigieren und ich bin glücklich.

Gruß Mike

Hallo @Bricoleur,

sorry vergessen. Der Phasenwechsel funktioniert nicht.

Gruß Mike

Moin Mike,

zum Phasenwechsel: gefunden und behoben, war tatsächlich ein Bug im Modul, nicht deine Wallbox! Die Phasenumschaltung hatte intern eine falsche Gruppen-Kennung, dadurch wurde in Konsole/WebFront gar kein Bedienelement dafür angelegt - der Ident war zwar theoretisch da, aber ohne Schalter unbedienbar. Ist jetzt in 0.9.76-beta.1 korrigiert. Bitte Modul aktualisieren und die Instanz einmal per „Übernehmen erzwingen“ neu anwenden, dann sollte der Schalter unter „Steuerung“ auftauchen.

Zur Stromabweichung (6A→5,8-5,9A, 16A→14,7-14,9A): danke, dass du das gemeldet hast - das bleibt für mich vorerst offen, da ich ohne die Antworten von vorhin (gleiches Fahrzeug? reproduzierbar? Firmware-Version? zeigt die Wallbox selbst schon den abweichenden Wert?) nichts Sinnvolles ändern kann, ohne zu raten. Magst du dazu noch kurz Rückmeldung geben, wenn du die neue Version testest?

Danke fürs genaue Hinschauen, das hilft sehr!

Gruß Dietmar

FoxEss Charger A,L und C:
Fox.ESS.EV.Charger.Modbus.TCP.Protocol.1.6-5.pdf (621,9 KB)

Siehe auch: EVCC https://github.com/evcc-io/evcc/pull/31412#issue-4794139819

Moin,

danke fürs PDF, das war ein sehr sauber dokumentiertes Protokoll - direkt umgesetzt (ChargerHub 0.9.78-beta.1, Kanal Beta im Symcon Store bzw. Branch beta auf GitHub).

Unterstützt: Ladestatus, Spannung/Strom je Phase, Ladeleistung, Energie (gesamt + aktuelle Sitzung), Geräteinfo (Modellcode, Seriennummer, Firmware-Version), Systemfehler als Bitmaske, Steuerung (Ladefreigabe, Stromlimit bis 32 A als Software-Obergrenze, in der Instanz änderbar). Optional auch Phasenumschaltung, falls eine externe Phasenumschalt-Box angeschlossen ist.

Kleiner Fund beim Umsetzen: Euer PDF widerspricht sich selbst beim Register „Current Phase Sequence“ (Abschnitt 2.17 nennt Type UINT32, die Registerliste in Abschnitt 2 weist ihm aber nur 1 Register zu - bei echtem UINT32 würde das nächste Register kollidieren). Ich bin der Registerliste gefolgt, da die in sich widerspruchsfrei ist, falls du das an ABL Fox ESS mal ansprechen möchtest.

Ungetestet an echter Hardware - magst du es ausprobieren (Hersteller „Fox ESS EV Charger“ wählen, Unit-ID standardmäßig 1, Port 502)? Besonders interessant: welches Modell genau (A, L oder C), passen die Werte, und funktioniert die Ladefreigabe?

Danke für die Vorlage!

Gruß

1 „Gefällt mir“

Hallo @Bricoleur,

vergiss die Stromabweichung. Ist direkt per Modbus genauso. Habe es bisher nicht beachtet. Leider funktioniert der Phasenwechsel aber nicht. Direkt per Modbus angesprochen klappt es aber.

Gruß Mike

Moin Mike,

eingebaut (0.9.79-beta.1): neuer Schalter „:new_button: Automatische Phasenumschaltung (werkseitig an)“ im Steuerungs-Panel. Damit kannst du Register 0x300A direkt über ChargerHub deaktivieren, statt jedes Mal dein externes Modbus-Tool zu bemühen.

Bitte aktualisieren, Instanz per „Übernehmen erzwingen“ neu anwenden, dann den neuen Schalter ausschalten und danach nochmal die manuelle Phasenumschaltung probieren. Das bleibt weiterhin eine Hypothese meinerseits (keine Garantie, dass das wirklich die Ursache war) - wäre aber klasse, wenn du mir sagen kannst, ob es damit jetzt klappt.

Gruß Dietmar

Hallo @Bricoleur,

werde ich morgen neu testen. Das Auto ist leider voll.

Noch zwei Bitten. Ist es möglich die Archivierungen im Standard zu deaktivieren und die Profile bei bereits bestehenden Variablen nicht wieder zur überschreiben?

Gruß Mike

Moin Mike,

beides eingebaut (jetzt in 0.9.81-beta.1):

  1. Neue Checkbox „:new_button: Archivierung deaktivieren“ im Panel „Polling“ - Standardverhalten bleibt wie gehabt, aber du kannst es jetzt gezielt für deine Instanz abschalten. Auch schon aktiv archivierte Variablen werden dabei automatisch wieder deaktiviert (bisherige Historie bleibt erhalten).
  2. Manuell in der Konsole geändertes Variablenprofil wird jetzt nicht mehr bei jedem Übernehmen zurücküberschrieben - ein Merker erkennt, ob du es selbst geändert hast, und lässt es dann in Ruhe. Nur bei einem echten Hersteller-/Typwechsel (der ein anderes Profil technisch braucht) wird trotzdem überschrieben.

Wichtiger Hinweis zu beidem, den ich jetzt auch direkt ins Formular geschrieben habe (steht bei der Checkbox bzw. im Doku-Panel):

  • Manuell geändertes Profil: Falls du bei Variablen, die im Verbund eine Rolle spielen (z. B. energy_total), das Profil änderst, kann das andere Module durcheinanderbringen - MeterHub sucht z. B. automatisch nach Zählern anhand des Profil-Suffixes („kwh“), und Dashboard/EMS verlassen sich teils auf die Standard-Skalierung/Einheit unserer Profile. Wenn du kein EMS/MeterHub/Dashboard im selben System hast, ist das unkritisch - läuft bei dir beides zusammen, würde ich das Profil lieber unangetastet lassen.
  • Archivierung deaktivieren: Betrifft dann auch Werte, die andere Module für Verlaufsauswertungen brauchen könnten (z. B. Dashboard-Charts, oder falls du später mal MigrationsHub für einen Wechsel nutzen willst - das braucht archivierte Historie). Wenn ChargerHub bei dir eigenständig läuft, ohne die anderen NRG-Stack-Module, ist das kein Problem.

Beides sind bewusste Einzelentscheidungen für deine Instanz, kein genereller Rat - nur bitte mit dem Hintergrund im Kopf, damit es später keine Überraschung gibt, falls doch mal ein weiteres Modul dazukommt.

Bitte aktualisieren und testen, wenn du wieder dazu kommst, kein Zeitdruck.

Gruß