Der Stack beinhaltet auch APIs für die UseCases.
EnWG §14a ist LPC, EEG §9 ist LPP.
Als digitale Schnittstelle etabliert sich für die beiden Anwendungsgebiete wohl EEBUS (nutzt bestehende TCP/IP Infrastruktur und Protokolle).
1 „Gefällt mir“
Fehlt aber noch eine Anbindung in Home Assistant, habe dazu aber nur was unter EVCC gefunden, aber das betrifft ja dann nur die WB, oder irre ich da? Habe kein EVCC bisher. Aber in HA wäre es natürlich am besten, von da aus kann man ja dann alles angebundene Steuern den Anforderungen.
Ein herzliches Servus aus dem Bayerischen Wald,
leider bin ich erst jetzt auf das Thema gestoßen. Vorweg, warum ich hier schreibe: ich betreibe ein selbst geschriebenes EMS und möchte, sobald unser VNB, die Bayernwerk Netz GmbH, so weit ist präpariert sein um §14a Modul 3 mit EEBUS Steuerbox nutzen zu können. Das evtl. ab April '25 kommen.
Auf der Suche nach Source Code zur Umsetzung der nötigen EEBUS Funktionalitäten bin auf verschiedene Quellen gestoßen. So findet sich 2 Jahre alter Code in C# geschrieben (offenbar verwaist), eine Java Implementierung vom Fraunhofer Institut und natürlich die in Go geschriebenen Bibliotheken von @derandereandi - dem ich hier ganz ausdrücklich für seine Arbeit danken möchte. Letzteres scheint mir noch am ehesten geeignet zu sein für meine Zwecke. Jedoch mangelt es allen Quellen an konkreten Beispielen inkl. Installations- und Konfigurations-Vorschlägen eine lauffähige Test- bzw. Entwicklungsumgebung aufzubauen. Zumindest ist es mir bislang nicht gelungen.
Das was mir aktuell am meisten fehlt ist sowas wie ein Steuerbox Simulator. Also eine Software, die die Funktionalität einer Steuerbox nachahmt so dass sich all das, was der VNB bzgl Dimmen und Messen anstellen möchte unabhängig von diesem schonmal ausprobieren lässt. So könnte jeder sein EMS rechtzeitig mit einem EEBUS Interface ausstatten. Irgendwelche Zertifikate scheinen die VNB ja nicht verlangen zu wollen. Erstaunlicherweise scheint man hier mal den Verbrauchern zu vertrauen. 
Zur Einordnung in die Praxis beschreibe ich mal kurz mein System, wie es im Laufe der Zeit (teils auch etwas wild wuchernd) gewachsen ist.
- FNN Basiszähler für iMSys vom Bayernwerk mit 2x RS485 Anschlüssen. An einem hängt ein SMGW, das per Mobilfunknetz die aktuellen Zählerdaten übermittelt. Der andere Anschluss ist für eine zukünftige Steuerbox vorgesehen. Solche Steuerboxen sollen im Laufe das Jahres beim Bayernwerk verfügbar werden.
- PV Anlage mit 10,8 kWp, Sungrow SH10.0RT Wechselrichter
- Akku, BYD HVS 10.2
- Viessmann Vitocal 222-S mit nachgerüsteter Kältefunktion
- KWL (kontrollierte Wohnraumlüftiung), Tecalor TVZ 180
- Wallbox, Compleo (ursprünglich E.ON), eBox smart, 22 kW
- EV, Ioniq 5
- mehrere Smartmeter mit Modbus Interface zum Messen der Leistungen und akkumulierten Energien von Wallbox und Wärmepumpe
- mehrere WLAN-Steckdosenadapter mit Leistungsmessung für Waschmasche, Spülmaschine, Kühlschrank, Gefrierschrank, Mikrowelle, Wasserkocher, etc, etc
- sogar der mechanische Wasserzähler wird mit einem ESP Kamera Modul mit Bilderkennung des Zählerstandes ständig abgelesen
- alle erfassten Werte werden permanent in einer lokalen MariaDB Datenbank gespeichert, so dass auch forensische Auswertungen möglich sind.
Das EMS besteht aus mehreren Funktionsblöcken, die weitestgehend in C# geschrieben sind. Die Benutzeroberfläche ist mit Vue.ts realisiert. Das gesamte System kommuniziert nicht mit dem Internet (nur eine Ausnahme), sondern läuft hausintern auf einer Linux Maschine. All die Daten sind viel zu sensibel um sie nicht abzuschirmen! Ein Gutteil Datenerfassung und Ansteuerungen der verschiedenen Teile geschieht über einen Fhem Server, der auf einem Raspberry PI läuft. So redet dieser bspw mit dem Wechselrichter per Modbus/TCP und kann so auch das Laden des BYD Akkus per Netzstrom steuern. Die Wallbox, die ich seinerzeit bei E.ON gekauft hatte und die anschließend viel Ärger und Frust erzeugt hat, hängt inzwischen an einem selbst geschriebenen OCPP Server und kann so - obwohl dafür nie konzipiert - jetzt mit PV Überschuss automatisiert wahlweise 1- oder 3- phasig betrieben werden. (Randnotiz: der Ioniq 5 schluckt leider nur maximal 11 kW Wechselstrom, also 3-phasig 3x 16A. Aber einphasig gehen auch 32A! Also rund 7,3 kW. Das ist wegen der 1A Stufung perfekt für ein sauberes Nachfahren der PV Kurve auch bei einzelnen Wolken). Die Viessmann WP kann via IR Adapter gelesen und gesteuert werden. Die aktuellen Verbräuche von WB, WP und diversen anderen Verbrauchern werden mit verschiedenen SmartMetern erfasst. Die Leistungen und Stände am Netzanschlusspunkt werden am Tibber Pulse per WLAN in Echtzeit abgegriffen, also ohne Umwege über irgendwelche Clouds. Alleine der Ladestand des Autoakkus kann leider nur via Bluelinky, also per Internet, abgefragt werden. Unser Ionic 5 beherrscht noch keine ISO 15118-20 und die WB würde das eh nicht unterstützen.
Warum schreibe ich das? Weil ich zeigen will, dass für diejenigen die es können - und da draußen wird es einige geben, die es können - nicht sinnvoll ist nur auf fertige Standardlösungen zu setzen. Meine, nur für mich massgeschneiderte Lösung, auch wenn für niemand anderen nutzbar, bietet mir so viel mehr Möglichkeiten auch mal was auszuprobieren und was einzubinden, was dafür nie gedacht war. So kann ich z.B. auch die Kühlfunktion der WP im Sommer nur bei PV Überschuss automatisiert einschalten und das ganze mit fein abgestufter Priorisierung zwischen EV-Laden, Hausakku-Laden und Kühlen, je nach aktuellen persönlichen Erfordernissen.
Außerdem bin ich dabei die Wallbox umzurüsten auf gelegentliches V2H, in der Art, wie es im goingelectric Forum mal beschrieben war. Das war hier verlinkt. Auch das sollte perspektivisch vom EMS automatisiert genutzt werden.
Das ist dann auch der Grund, weshalb für mich dynamische Netzentgelte ala Modul 3 in Kombination mit dem eh schon vorhandenen dynamischen Stromtarif via Tibber so interessant sind. Gerade aktuell (Winter 24/25) erleben wir immer wieder Tage an denen Tags blauer Himmel herrscht und Nachts ist es bitterkalt. D.h. Tags mehr Sonne als der Hausakku schlucken kann und Nachts mehr Heiz-Strombedarf als der Hausakku groß ist. Hier verspreche ich mir von einer quasi „Vergrößerung des Hausakkus“ durch den Autoakku die Möglichkeit zu mehr netzdienlichem Verhalten. Und wenn zu wenig Sonne scheint oder die PV Paneele schneebedeckt sind, dann will ich den Strom nur dann aus dem Netz ziehen, wenn’s möglichst preiswert ist - denn preiswert heißt grün und mehr als genug. Insbesondere angesichts der Wechselverluste bei der angesprochenen V2H Technik (geregeltes 3000W Netzteil am 230V Ausgang des EV und Einspeisung als 400V= in einen MPPT Eingang des WR) macht das nur Sinn, wenn der Spread im Tagesverlauf der Stromkosten groß genug ist. Klar, da muss abgewogen werden zwischen Energieverschwendung und Netzdienlichkeit. Umsonst ist nur der Tod - und nicht mal der.
ABER: dazu braucht es eine Anbindung des EMS an eine zukünftige Steuerbox!
Konkrete Frage an @derandereandi: ist es mit Deinem veröffentlichen GO Code und den Infos von VDE FNN (impuls--digitale-schnittstelle-data.pdf) evtl. zusammen mit dem "Lastenheft Steuerbox" (das ja leider knapp 40€ kostet) möglich einen Steuerbox Simulator zu schreiben? Und könntest Du Dir vorstellen mir dabei zu helfen?
Beste Grüße aus dem kalten aber sonnigen Bayerischen Wald,
Klaus
Das fände ich auch interessant um EVCC und meine (zukünfitge) Betreiber-Dokumentation zu testen. Gibt es da evtl. im EVCC Umfeld schon eine Simu?
Gerade gestern meine Daikin WP mit SG Ready in EVCC eingebunden (hard Relais kommen vermutlich nächste Woche). Mein VNB will noch keine SmartMeter an mich abgeben, aber ich möchte alles vorbereiten.
@vollautomat Ja, das ist mit dem Stack möglich zu bauen. Du bist ja inzwischen auch im Repo Forum dazu aufgeschlagen 
Ich selbst habe keine Zeit das zu entwickeln. Du wirst auch noch die Specs und den Implementation Guide von EEBUS LPC benötigen. Dazu sind auch Testfälle definiert.
Sehr interessanter Thread,
aktuell beschäftige ich mich mit eebus, da ich in kürze ein SMG und wohl Steuerbox bekommen soll. Bisher regle ich alles selbst über iobroker mit VictronESS, RCT Wechselrichter PV Anlage, Heidelberg Wallbox ...
Ich finde leider auch nicht genügend Infos dazu. Meine Idee war das ich am SMG oder einer Steuerbox ein Netzwerkkabel (verbunden mit meinem Router) anschließen kann und über das eebus-Protokoll die Daten abfragen könnte was der NB mir an aktuellen Vorgaben macht. Also WB dimmen oder PV Einspeisung begrenzen ...
Mit diesen Werten könnte ich dann meine 3Phasen Vicrton ESS anlage, RCT Wechselrichter, WB ... selbst intelligent steuern.
Gibt es eine Möglich die Vorgabewerte per lokaelem Netzwerk abzurufen, Dann könnte ich mir den ganzen Relaiskram sparen?
Gibt es ein Beispiel wie ich die GO Implemetierung in meinem system nutzen kann. Was müsste ich wo installieren?
Bin für jeden Hinweis sehr dankbar
noch ein Andi ,-)
Es gibt nichts das du einfach so installieren kannst. Das muss erst mal jemand programmieren und dann noch eine Schnittstelle einbauen damit man das in Systemen wie z.b. ioBroker nutzen kann. Da ist noch ein erheblicher Entwicklungsaufwand zu leisten.
Danke für die schnelle Antwort.
-ist die hardwareseitige Lösung überhaupt möglich?
Also an die Steuerbox ein Netzwerkkabel an meinen Router anzuschließen?
EEBUS ist doch ein IP Protokoll, wenn ich das richtig verstanden habe
- Die Vorgabewerte des NB per Befehl abzurufen und z.B in einem json zu speichern?
-wie kann man deine GO Implemtierung nutzen? geht das nur mit GO? oder gibt es dort Schnittstellen zu mqtt, Rest oder dergleichen? (Sorry , habe mit GO gar kein Erfahrung)
Habe heut den ganzen Tag mit Recherche verbracht, bin aber nicht wirklich weiter gekommen. Mein EMS würde ich im Endeffekt per Relais-Kontakte und mqtt Befehle im Victron-System umsetzen, hätte aber möglichst alle Daten über eebus in mein EMS geschaufelt, statt eventuell mehrere Steuerboxen und Koppelrelais im Schaltschrank, da das mehr als 4 steuVe werden.
Danke
Die Hardwareseitige Lösung könnte gehen, so lange du auf dem Weg auch wirklich das erzielst, was gewünscht ist. Die Steuerbox wird per LAN in das Heimnetz angebunden.
Jemand muss z.B. eine Software bauen welche die Daten von EEBUS zu/von MQTT (oder was auch immer) hin-und-herschaufelt. Was in Go vorhanden ist, ist eine API um mit einer Steuerbox zu reden. Die muss man jetzt noch mit Leben füllen, und zwar so wie es die EEBUS UseCase Spezifikation dazu beschreibt. Dazu kommt dann noch das ganze "Kopplungs-Gedöns" um überhaupt der Steuerbox sagen zu können, mit wem es reden soll.
Mann muss sich also schon etwas tiefer mit EEBUS auseinandersetzen und die zur Verfügung gestellte API verstehen und nutzen zu lernen.
Das ist alles andere als wenig Arbeit. Und mit einem Tag Recherche kommt man da nicht weit.
1 „Gefällt mir“
Es gäbe da noch mehr Victron Kandidaten. Die Multiplus haben von Haus aus nicht mal Relaiseingänge für sowas vorbereitet. Allerdings liefert mein VNB auch weiter Rundsteuerempfänger aus weil er gar keine FNN Boxen hat. Wenn ich das richtig verstehe, braucht man diese ja auch gar nicht weil man die 4 Relaisusgänge nicht braucht. Stattdessen schaltet man sich physikalisch auf die Schnittstelle am Gateway auf mit welchem der ImSys auch kommuniziert? Mein VNB hat aber auch auf der Gegenseite noch überhaupt nichts um die Leistungsreduzierung auf etwas Anderem als auf Langewelle anzusteuern. Wegen dem kriegen alle Kunden noch immer einen alten Empfänger angedreht.
Es ist schade, dass man in de mal wieder einen umständlichen, weltweit nicht anerkannten, Weg einschlägt, der in der Industrie weder in de noch global gepflegt ist und den trotz allem quasi verpflichtenden macht - und das ohne Not. Protokolle wie mqtt und modbus hätten es getan. Man wähle was, was 80 % der arm markt befindlichen Geräte können … aber so..?? Vielleicht geht ja mit den Relais aus der 1960ern mehr
MQTT und Modbus definieren erst mal nur den Transport Layer, bei EEBUS ist das SHIP. Fast alle Endgeräte nutzen aber den Transport Layer unterschiedlich. Fast jedes Gerät hat andere Registersätze, ähnliche Daten in anderen Datentypen, oder anderen Topics. Auch Sunspec wird nicht (schon gar nicht weltweit) konsistent verwendet. Bei Modbus fehlt dazu der Rückkanal, und TLS ist hier auch nicht verbreitet.
Es steht jeder Firma/Initiative frei eine Alternative zu definieren und vom BSI zertifizieren zu lassen. Ist zumindest bisher nicht geschehen.
Ich bin absolut kein Verfechter von EEBUS, es ist ein Monster, Inkonsistent, über-kompliziert, ineffizient, ... und wurde auch für etwas ganz anderes gemacht als es jetzt verwendet wird.
Aber jetzt einfach sagen: Nutzt doch MQTT oder Modbus ist eben auch zu kurz gegriffen.
2 „Gefällt mir“
Danke für deine Einordnung.
Wenn das ‚Problem‘ beim Transport Layer liegt, ist die Steuer Kiste einfach zu dumm. Der könnte man ja durchaus beibringen, welche Infos wie auf welchem Kabel an welche Kiste über diesen Layer gehen - so wie ein bubble fish in Anhalter durch die Galaxis. Sowas zu erstellen schaffen die Hersteller aus Übersee oder selbst eine aktive Community nämlich recht schnell, und eine Identifikation mit zb look up Tabelle und kleinem Speicher (ggf. sogar updatebar….) im Gerät, Thema gegessen. Und: Wen interessiert der Rückkanal, wenn noch ein iMSys vorher misst, dass auch ja nicht mehr (bilanziert) durchgeht?
Datensparsamkeit und so //rant Ende
Und Nein, ich mach nicht dich verantwortlich dafür oder halte dich für eine eebus Fanboy oder gar Sprecher; du hast nur offenbar insights in die vde oder zumindest Eebus Community.. Danke nochmal für die Infos 
Danke für die aufschlussreichen Informationen hier, insbesondere an den anderen Andi, und Kompliment für die GO-Implementierung des Stacks.
Für meine Hybrid-PV möchte ich LPP und LPC selbst in einem EMS implementieren, angebunden über EEBUS. EVCC bietet sich da ja als Basis an, und mit Andis Stack ist es auch ein Kinderspiel, die LPP und LPC-Einstellungen zwischen Client- und Server-Instanzen zu übertragen. Eine Schnittstelle in HomeAssistant für die Einspeisebegrenzung habe ich vorbereitet, das könnte in Zukunft jedoch auch über evcc laufen. Das Durchreichen an den Deye 12k Hybrid funktioniert, HA liefert auch die Dokumentation der Einspeisewerte
Für mich ist allerdings völlig unklar, warum es zwischen SMGW und (DIY-) EMS noch eine Steuerbox braucht. Eigentlich ist doch der CLS-Proxy im SMGW direkt mit steuerbaren Verbrauchern bzw. einem EMS kommunikationsfähig. Die BSI TR-03109-1 habe ich weitgehend durchgeackert und finde nur sehr wenig, was einem Eigenbau auf Basis von Andis Stack entgegen steht, wobei auch Missverständnisse meinerseits nicht auszuschließen sind:
- die Proxy-Kommunikationsprofile sollen ausschließlich vom GWA/VNB ins SMGW eingebracht werden. Da diese die CLS-ID sowie insbesondere das selbstsignierte CLS-Zertifikat enthalten, oder evtl. mehrere davon, müssten wir Bastler das dem VNB mitteilen. Liege ich hier falsch? Das könnte ich mir kompliziert vorstellen.
- im möglicherweise typischen Verbindungsaufbau durch das CLS (HKS3) muss das EMS die ID des aEMT kennen, die man vom VNB mitgeteilt bekommen müsste. Evtl sind das auch mehrere für die beiden Anwendungsfälle.
Aus dem evcc-Blog (Highlights: Lastmanagement, § 14a EnWG | evcc - Sonne tanken ☀️🚘), August 2024, habe ich allerdings folgende überraschende Aussage entnommen: "...Das SMGW selbst bietet allerdings keine sinnvolle Möglichkeit mit dem Heimnetzwerk zu kommunizieren. Dies findet über eine sogenannte Steuerbox statt, die hinter dem SMGW angeschlossen ist. Diese zertifizierte Box leitet das Signal über EEBus an die jeweiligen Geräte weiter. evcc hat die EEBus Schnittstelle zur Steuerbox implementiert."
Das bringe ich irgendwie nicht zusammen, da doch dann die HAN-Schnittstelle weitgehend die gleichen Daten liefern sollte, mit identischem Protokollstack. Und definitiv ist der CLS-Proxy gemäß TR-03109-1 im SMGW lokalisiert.
Das SMGW ist bei mir mittlerweile von der Syna nachgerüstet. Wann eine Steuerbox installiert werden soll bzw. wann sie für LPP und LPC via EEBUS bereit sind, weiß ich leider nicht. Sie fordern momentan die Installation eines FRE für meine in 2024 erstellte und 2025 erweiterte PV mit Speicher (10,2 + 5,1 kWp, 14,4 kWh).
Eine Dimmung LPC wäre eh unwahrscheinlich und würde außerdem ins Leere laufen, da mein Speicher wie die der meisten von uns überhaupt nie aus dem Netz geladen wird. Andere steuerbare Verbraucher habe ich momentan noch nicht, mindestens E-Auto wird aber mittelfristig kommen, vielleicht auch ein zweite Klimaanlage, die dann zusammen über 4,2 kW Anschlusswert liegen.
Ich werde versuchen, dem VNB eine Zwischenlösung ohne FRE schmackhaft zu machen. Ich werde ihm wohl anbieten, bis zur Verfügbarkeit eines EEBUS-Signals am SMGW im Gegenzug auf die Reduzierung des Netzentgelts zu verzichten.
Denn eines ist für mich doch recht deutlich: Auch wenn wir die VNBs mit ihren teils schwer verständlichen Anforderungen gerne als Gegner ansehen, im Falle von § 14a sind sie die tatsächlich gekniffenen. Für das Recht, eine sehr unwahrscheinliche "Dimmung" vorzunehmen (die bei meinem Stromspeicher eh nichts ändert), muss mein VNB das gesamte Netzentgelt, das er für meinen Anschluss mit wenigen hundert kWh Strombezug im Winter erhält, wieder erstatten. Nichts verdient also an der Infrastruktur, die er mir zur Verfügung stellt.
Dass der Speicher auf längere Sicht gar nichts aus dem Netz bezieht und somit die Steuerung dafür ins Leere laufen würde, das erwarte ich, meinem VNB verständlich zu machen, wenn er im Gegenzug das Netzentgelt behalten darf.
Mit Relaissteuerungen möchte ich gar nicht anfangen, auch wenn die vier Kontakte für die aktuelle Konstellation ausreichend wären (2 für 4-stufige Einspeisebegrenzung, ein weiterer, der den Bezug des Speichers von normal null Watt auf gedimmte null Watt umschaltet 
).
Und wenn es denn erlaubt wäre, wäre ich sogar bereit, meinen Speicher netzdienlich einzusetzen. Die mäßigen Effizienzverluste würde ich in Kauf nehmen und morgens im Speicher Platz machen, um von der Mittagsspitze mehr einspeichern zu können. Die zusätzlichen Speicherzyklen machen mir keine Sorge. Auch jetzt schon steuere ich meine Anlage in den sonnenreichen Monaten so, dass das Laden des Speichers von 6 Uhr bis 11:30 verhindert wird.
Ein bisschen Idealismus ist doch bei vielen von uns vorhanden. Gewinnmaximierung durch maximale Einspeisung auch mittags war früher OK, wird aber ein zunehmendes Problem. Eine bessere Lösung dieser Aufgabe als durch Abregeln der Erzeugung ist wünschenswert.
Soweit ich das verstanden habe darf die HAN Schnittstelle nicht mit dem Internet verbunden werden. Sobald ein Internetzugang detektiert wird, soll die Schnittstelle keine Daten mehr liefern. Ob das Netzwerktechnisch irgentwie gelöst werden könnte, weis ich nicht.
Ja, kann auf alle Fälle gelöst werden: Schlimmstenfalls zusätzliche Netzwerkschnittstelle.
Wie detektiert das SMGW einen Internetzugang?
Ich habe noch mal bei einem Herstellern nachgesehen. Von einem "Internetverbot" steht da nichts. Es können aber nur zertifizierte Geräte und Software auf die HAN Schnittstelle zugreifen.
Das BSI erlaubt nicht, dass das SMGW mit irgendeiner Netzinfrastruktur verbunden wird, inkl. dem eigenen LAN für die Komponenten im Haus. Denn da sind ja viele unkontrollierbare Geräte dabei, die ein Einfallstor zum Hacken eines SMGW bieten könnten.
Auch die Gerätehersteller der Steuerboxen/SMGWs wünschen sich, dass das zusätzlich Gerät irgendwann nicht mehr notwendig wird. Es gibt einige SMGWs mit einem "Mehrwertmodul", das ist ein Aufsteckmodul auf das SMGW und somit keine komplett gesonderte Hardware. Aber dieses wird dann auch nur EEBUS können, eine Steuerbox bietet noch die Möglichkeit über Relais Anschlüsse nicht EEBUS kompatible Geräte anzusprechen.
Also kurz nochmal: Der Grund dafür sind Anforderungen des BSI um ein Hacken des SMGW zu verhindern/erschweren.
1 „Gefällt mir“
Was bitte schön soll das verhindern? Wer das will braucht kein Hausnetz dazu, ist aber eine Schwachstelle bekannt, wäre es ein leichtes diese vielfach auszunutzen dann über die Hausnetze.
Müsste dann also eine Box mit Open Source Umsetznung geben, die EEBUS dann wieder verfügbar macht über eine API... aber alles viel zu aufwendig. Dann sollen sie mir 4 Relaisausgänge geben und gut ist es. Blöd und Hinterwäldlerisch, aber ist dann so.
Oder die stellen mal eine API im Internet bereit wo sich die Geräte die Informationen abholen können und es muss nur noch die Funktionalität nachgewiesen werden.
Natürlich finde ich nicht wieder wo ich das gelesen habe. Jetzt finde ich nur noch die BSI Vorgabe wieder.
Dafür gibt es ja die Steuerbox mit einer EEbus Schnittstelle.