Unterstützung von Smart Meter Gateways (SMGW)

[nichtich]

Derzeit werden von den Netzbetreibern so genannte intelligente Stromzähler installiert. Soweit ich es verstanden habe sind das Smart Meter Gateways (SMGW), die neben der externen Abfragemöglichkeit auch lokal per Ethernet abgefragt werden können ("HAN-Schnittstelle", siehe auch TRuDI als offener Client). Auf der Homepage steht

Damit evcc die Ladung bestmöglich regeln kann, ist ein Messgerät (=auslesbarer Energiezähler) am Netzanschluss der Hausinstallation notwendig.

Fallen darunter alle Smart Meter Gateways als meter oder kommt es auf den Hersteller an, ob sie unterstützt werden? Welches Gerät installiert wird, entscheidet ja meist der Netzbetreiber. Wenn sowieso ein SMGW vorhanden ist, müsste doch nicht noch extra ein weiteres Gerät wie der SMA Home Manager 2.0 zum Messen des aktuellen Verbrauchs und der aktuellen Einspeisung angeschafft werden, oder? Vielleicht könnte in der Dokumentation noch deutlicher gemacht werden dass auslesbare Energiezähler von den Netzbetreibern vermehrt sowieso installiert werden.

[premultiply]

Prinzipiell kann man häufig auch die vorhandenen Zähler des Messstellenbetreibers auslesen. Das ist sogar unabhängig von s. g. „Smart Metern“.
Klappt prinzipiell sogar mit Ferraris-Zählern.
Dazu benötigt man eine Zwischenschicht wie z. B. vzlogger die die konkrete Übersetzung des Zählersabgriffs übernimmt. Hierbei unterscheidet sich aber die Aktualisierungsrate der Leistungswerte und auch die Aufgliederung z. B. in einzelne Phasenmesswerte usw. sehr stark von der jeweiligen Lösung.

Der SMA SHM hat zwar auch einen vollständigen (und schnellen) internen Zähler, leistet aber auch noch andere zentrale Dienste für die zugehörige Anlage so dass ausgerechnet dieser in diesem Sinne am wenigsten verzichtbar ist.

[nichtich]

Ok, es kommt also auf den Hersteller und das konkrete Zählermodell an.

Der SMA SHM hat zwar auch einen vollständigen (und schnellen) internen Zähler, leistet aber auch noch andere zentrale Dienste für die zugehörige Anlage so dass ausgerechnet dieser in diesem Sinne am wenigsten verzichtbar ist.

Gilt das für evcc allgemein oder welche anderen zentralen Dienste meinst du? Ich hatte bisher angenommen dass nur irgend ein Messgerät den Verbrauch messen können muss evcc den Rest der Automatisierung übernimmt. Messgeräte sind je eher für 100€ statt für 500€ wie der SMA SHM zu haben. Ich frage weil wir grade einen SMA Wechselrichter bekommen haben und nächste Woche vom Netzbetreiber ein neuer Stromzähler eingebaut wird, wozu dann noch ein weiteres Gerät?

[nichtich]

Ok ich hab's gefunden: evcc kann so eingerichtet werden dass es durch den SMA Home Manager gesteuert wird und so beispielsweise vor allem läd wenn sonst ab 70% Wirkleistung die PV-Anlage abgeregelt werden würde (ohne SMA SHM muss der Wechselrichter fest auf 70% Leistung gedrosselt werden). Je nach Ausrichtung der PV-Anlage sind das aber eher maximal 5% der Energie die ungenutzt abgeregelt wird. Ob es sich nur dafür lohnt einen SMA Home Manager anzuschaffen wenn der aktuelle Verbrauch sowieso per Stromzähler gemessen werden kann (das ist die ursprüngliche Frage), muss sich jede*r selber ausrechnen.

[andig]

Die „Transparenzsoftware“ Trudi kommt ohne Open Source Herstellerplugins und ist damit leider sinnlos: https://bitbucket.org/dzgtrudi/trudi-public/issues/6/open-source-hersteller-plugins. Meine Anfrage dazu ist fast 2 Jahre alt...

[nichtich]

Ach so, es sah auf den ersten Blick so aus als sei Trudi Open Source und HAN ein Standard, ist aber nicht so bzw. kleinster gemeinsamer Nenner ist "irgendwas nicht offenes über Ethernet". Warum einfach, wenn's auch kompliziert geht? Danke für die Klärung!

P.S: Zur Not könnte Trudi ja auch als Black Box zur Kommunikation mit dem Smart Meter Gateway laufen und von dort der aktuelle Verbrauch per Screenscraping abgegriffen werden. Ist aber vermutlich zu frickelig und instabil.

[naltatis]

Gibts im Bezug auf Smart Meter auslesen irgendwas neues? Bei mir hat die Westnetz angekündigt, dass sie mir jetzt ein "intelligentes Messsystem" einbauen möchten. Gibts Geräte bei denen wir in Echtzeit an die aktuellen Leistungsdaten kommen können?

[VolkerK62]

Das ist der einzige Wert, der uns wirklich interessiert,

Nicht die Leistungsreduzierung vergessen 😄

[masgo]

Zur Info: ich habe das "PPC LTE Smart Meter Gateway". Ich habe noch etwas rumprobiert und folgendes rausgefunden:

Über Trudi kriege ich nur den Zählerstand in 15min Schritten und historische Werte ausgelesen. Ich hab z.B. um 13:09 Uhr drauf geschaut, dann zeigt er mir den Zählerstand von 13:00 Uhr an. Um 13:15 Uhr gibt es dann den neuen Zählerstand. Sowas wie die aktuelle Leistung oder andere Infos mit höherer Auflösung konnte ich nicht finden.

Das Ding hat auch ein Web-Interface.
Wenn ich auf https://192.168.2.1/cgi-bin/hanservice.cgi gehe, werde ich nach Benutzer+PW gefragt und er akzeptiert die gleichen Daten wie Trudi. Das Webinterface bietet allerdings auch nicht mehr Infos als Trudi.
Das Skript hier hat mich inspiriert das zu versuchen: https://gist.github.com/atarp/11dfe096a554db81d94615e3bfc65424
Das Skript selbst konnte ich mangels Linux auf dem Notebook noch nicht testen. Habe mir die Kommunikation aber in der Firefox Konsole angeschaut und mir scheint das zu passen. Allerdings würde das auch nur den Zählerstand auslesen der nur alle 15min aktualisiert wird.

Ob das Ding noch mehr Funktionen oder offene Ports hat muss ich mal testen wenn ichs im VLAN hab und Linux mal drauf loslassen kann.

[masgo]

skipt funktioniert übrigens prima.

[andig]

Ich hatte per Mail Kontakt mit PPC. Sie weigern sich irgendeine Schnittstelle heraus zu rücken, man könne ja TRUDI nehmen. Das das z.B. auf MacOS nicht läuft ist PPC egal. M.E. verstoßen sie damit gegen den Sinn den HAN-Schnittstelle, aber das interessiert anscheinend auch Niemanden...

[tolot27]

Sowas wie die aktuelle Leistung oder andere Infos mit höherer Auflösung konnte ich nicht finden.

Genau das liefert TAF 14 („Hochfrequente Messwertbereitstellung für Mehrwertdienste"), welches vom Messtellenbetreiber freigeschaltet werden muss und dann minütlich die Werte liefert, statt alle 15 Minuten.

Über TAF 11 ("Steuerung von unterbrechbaren Verbrauchseinrichtungen und Erzeugungsanlagen") könnte sogar die Steuerung gemäß § 14a EnWG erfolgen.

[stefan123t]

Es gibt die Seite des BSI die die zertifizierten Smart Meter Gateways auflistet:

• EMH metering GmbH & Co.KG, CASA 1.0 and CASA 1.1
• Theben Smart Energy GmbH, CONEXA 3.0, Version 1.7
• Sagemcom Dr. Neuhaus GmbH, SMARTY IQ-LTE, Version 1.5, 349€ gebraucht Bucht
• EFR GmbH, Secure Smart Grid Hub (SGH-S), V1.02
• Power Plus Communications AG, SMGW Smart Meter Gateway Version 2.2

Leider ist keines der derzeit vom BSI zertifizierten Systeme für Endverbraucher am Markt erhältlich.

Hier die Informationen bzw. Antragsformulare zur Smart Metering PKI

• BSI Smart Metering PKI
• Telekom Trust Center Smart Metering PKI
  • Registrierung als Smart Meter PKI Sub-CA für den Betrieb einer Test Instanz
  • Smart Meter Gateways als GWH (Gateway Hersteller), GWA (Gateway Administrator), EMT (Externer Marktteilnehmer) oder EMT-MAK (Externer Marktteilnehmer für Marktkommunikation)

Wenn also jemand eine solche SubCA in der SmartMetering PKI Test Umgebung beantragt, dann könnte man damit den Code zur Signierung mit validen Zertifikaten verwenden und ein quelloffenes Smart Meter Gateway (SMGW) realisieren.

Sowie die beiden Tools:

• Universität Tübingen jOSEF: A Java-Based Open-Source Smart Meter Gateway Experimentation Framework
• PTB Braunschweig Transparenz- und Displaysoftware TRuDI

Vielleicht ist auch noch das GuruX DLMS Project hilfreich um Smart Meter auszulesen ?

[andig]

Falls jemand ein Theben hat: wäre nett das als Netzzähler verwenden zu können: #26157

[tobima]

Bei meinem Bruder wurde heute ein Theben SMGW eingebaut. Wenn ich die Zugangsdaten bekomme schaue ich mir da mal an.

[iseeberg79]

du könntest dann mal probieren, ob die Implementierung ins Blaue (abgeleitet von anderen) klappt, und Werte (welche?) liefern würde.

[tobima]

Ich habe jetzt die Zugangsdaten. Die Implementierung passt noch nicht ganz. Ich werde die Tage einen PR zusammen basteln.
Aber ich kann jetzt schon sagen, dass zumindest in dem Setup auch nur die Zählerstände abrufbar sind. Firmware ist aktuell.
Ist der gleiche Zähler und der gleiche Messstellenbetreiber wie bei mir zu Hause.

[iseeberg79]

gleiche Frage an andere mit EMH CASA SMGW, werden Echtzeitwerte bereitgestellt? Wovon hängt es ab?

Gerne zum Test&Feedback, wenn HAN und Zugangsdaten eingerichtet:

#26427

[tobima]

Ich habe von Inexogy eine EMH eBZD Zähler (eBZD-W23E8-0LHLG-D401-H5Q2) und ein EMH CASA 1.1 SMGW.

Leider bekomme ich nur die Zählerstände für Bezug und Lieferung vom SMGW.

TAF 1 und TAF 7 für Bezug und Lieferung sind in der meterlist.
Das extended metering JSON sieht so aus:
{ "capture_time": "2026-01-20T14:34:07+01:00", "status": "a0000000209d3800", "timestamp": "2026-01-20T14:34:07+01:00", "values": [ { "logical_name": "0100010800ff.1emh00XXXXXXX.sm", "scaler": -1, "signature": "-", "unit": 30, "value": "5624491" }, { "logical_name": "0100020800ff.1emh00XXXXXXX.sm", "scaler": -1, "signature": "-", "unit": 30, "value": "986529" } ] }

[iseeberg79]

Aus Interesse: die MeterId ist welche? Vmtl. Zähler... Werte sind hier leider klar nur Bezug/Einspeisung
In einer Anleitung - vielleicht passt Sie zu deinem Zähler? - wird von "Grid Funktion (optional)" gesprochen - sollte die (HW-)Funktion bei dir fehlen? Alles nur Spekulation... EMH

Egal mit welchen Zugangsdaten (habe zwei erhalten), identische Sensorwerte - die Kombination von SMGW und Zähler ist ggf. relevant, was es nicht einfacher macht.

curl -k --digest -u "user:password" https://192.168.33.2:443/json/metering/origin/1efr0123456789/extended

{
    "capture_time": "2026-01-20T19:53:40+01:00",
    "status": "a000000020863800",
    "timestamp": "2026-01-20T19:53:40+01:00",
    "values": [
        {
            "logical_name": "0100010800ff.1efr0123456789.sm",
            "scaler": -1,
            "signature": "-",
            "unit": 30,
            "value": "15688560"
        },
        {
            "logical_name": "0100020800ff.1efr0123456789.sm",
            "scaler": -1,
            "signature": "-",
            "unit": 30,
            "value": "4695714"
        },
        {
            "logical_name": "01000e0700ff.1efr0123456789.sm",
            "scaler": -1,
            "signature": "-",
            "unit": 44,
            "value": "499"
        },
        {
            "logical_name": "0100100700ff.1efr0123456789.sm",
            "scaler": 0,
            "signature": "-",
            "unit": 27,
            "value": "359"
        },
        {
            "logical_name": "01001f0700ff.1efr0123456789.sm",
            "scaler": -2,
            "signature": "-",
            "unit": 33,
            "value": "435"
        },
        {
            "logical_name": "0100200700ff.1efr0123456789.sm",
            "scaler": -1,
            "signature": "-",
            "unit": 35,
            "value": "2276"
        },
        {
            "logical_name": "0100240700ff.1efr0123456789.sm",
            "scaler": 0,
            "signature": "-",
            "unit": 27,
            "value": "923"
        },
        {
            "logical_name": "0100330700ff.1efr0123456789.sm",
            "scaler": -2,
            "signature": "-",
            "unit": 33,
            "value": "175"
        },
        {
            "logical_name": "0100340700ff.1efr0123456789.sm",
            "scaler": -1,
            "signature": "-",
            "unit": 35,
            "value": "2313"
        },
        {
            "logical_name": "0100380700ff.1efr0123456789.sm",
            "scaler": 0,
            "signature": "-",
            "unit": 27,
            "value": "-168"
        },
        {
            "logical_name": "0100470700ff.1efr0123456789.sm",
            "scaler": -2,
            "signature": "-",
            "unit": 33,
            "value": "183"
        },
        {
            "logical_name": "0100480700ff.1efr0123456789.sm",
            "scaler": -1,
            "signature": "-",
            "unit": 35,
            "value": "2294"
        },
        {
            "logical_name": "01004c0700ff.1efr0123456789.sm",
            "scaler": 0,
            "signature": "-",
            "unit": 27,
            "value": "-395"
        },
        {
            "logical_name": "0100510701ff.1efr0123456789.sm",
            "scaler": 0,
            "signature": "-",
            "unit": 8,
            "value": "120"
        },
        {
            "logical_name": "0100510702ff.1efr0123456789.sm",
            "scaler": 0,
            "signature": "-",
            "unit": 8,
            "value": "240"
        },
        {
            "logical_name": "0100510704ff.1efr0123456789.sm",
            "scaler": 0,
            "signature": "-",
            "unit": 8,
            "value": "344"
        },
        {
            "logical_name": "010051070fff.1efr0123456789.sm",
            "scaler": 0,
            "signature": "-",
            "unit": 8,
            "value": "222"
        },
        {
            "logical_name": "010051071aff.1efr0123456789.sm",
            "scaler": 0,
            "signature": "-",
            "unit": 8,
            "value": "188"
        }
    ]
}

[tobima]

Die MeterId ist die Zählernummer.

Die Messwerte der Grid Funktion sind auf Seite 33 aufgelistet. Da geht es um Netzzustandsdaten, die dürfen nach §56 MsbG nur im Auftrag des Netzbetreibers vom Messstellenbetreiber erfasst werden. Eventuell ruft mein Inexogy diese Daten vom Zähler nicht ab oder deren Zähler können diesen Datensatz nicht bereitstellen. Über den TAF10 würden diese Werte dem Netzbetreiber zur Verfügung gestellt.

Ist bei dir zufällig der TAF10 konfiguriert curl -k --digest -u "user:password" https://192.168.33.2:443//json/metering/derived

[iseeberg79]

hier nur TAF1 und TAF7; ich hab anders (aber ähnlich) gedacht: Zähler sendet die Daten nicht aus SMGW, oder dieser ignoriert diese. Hypothese wäre TAF10 würde diese weitergeben (können), vorausgesetzt die werden eben überhaupt erfasst? Es heisst ja in anderen Foren auch bei anderen SMGW, das Messwerte nicht in bestimmter Konstellation von Zähler/SMGW bereitgestellt werden.

Es wird also eine Matrix geben aus Konfiguration und Kombination Zähler/SMGW geben und man kann nicht davon ausgehen, dass das SMGW Modell alleine entscheidet.
Das würde bedeuten (aktuell) eigenen sich nur bestimmte Konstellationen als GridMeter zur Messwerterfassung.

Wenn sich das bestätigt, wäre eine Implementierung zwar noch interessant und nicht zu aufwändig, aber der Einsatz nur für wenige möglich/sinnvoll. Die Erklärung, ob sich der vor Ort verfügbare SMGW als Meter eignet aufwändig?

Grundsätzlich scheint das aber von Herstellern bereitgestellt zu werden: Pressemitteilung

[tobima]

Die Pressemitteilung hört sich danach an, dass die HAN-APi nach der V2 der TR implementiert umgesetzt wird. Mal abwarten.

[iseeberg79]

naja, der Auszug:
CASA 1.1 ist dabei in der Lage, Messdaten im Sekundentakt bereitzustellen. Solche hochauflösenden Energiedaten erhöhen die Transparenz für Letztverbraucher erheblich. Das Portal ist daher auch ein wichtiges Instrument zur Kundenbindung. In Kombination mit einem Energiemanagementsystem (EMS) legen hochauflösende Messdaten die Basis für eine intelligente Steuerung von Verbrauchsgeräten und ermöglichen eine optimale Nutzung dynamischer Tarife. Neu ist: Über das Webportal stehen diese Daten erstmals Letztverbrauchern zur Verfügung, die kein eigenes EMS nutzen.
Da würde ich jetzt fast davon ausgehen, man braucht 310...., ab Firmware "x.y" - aber wie herausbekommen, ohne das es Rückmeldungen von anderen Nutzern gibt - scheinbar ist die Auflösung und die Nutzung des HAN wirklich selten unter den aktuellen Nutzern... vielleicht einfach noch zu früh. Zu anderen Metern gibt's ja auch nicht wirklich Rückmeldung und z.B. die Integration von Theben / PPC in HA mit dem Add-On bezog sich primär auf die Zählerstände, aber nicht auf Messwerte.

Und ob es dann noch eine Abhängigkeit der Bereitstellung von Messwerten zwischen Zähler und SMGW gibt ist auch nicht klar.

[theArcher73]

TAF 10 ist ein nicht abrechnungsrelevanter TAF für den Verteilnetzbetreiber. Er enthält max. 15 Werte im Kontext Netzzustandsdaten. Da sind keine Verbrauchswerte drin. Der TAF10 kann minütlich oder 1/4h Daten liefern, je nachdem was der VNB bestellt hat.

Und, wenn das CASA 1.1 in der Lage ist, Sekundenwerte bereitzustellen bedeutet das leider noch nicht, das jeder Zähler am LMN in der Lage ist, diese dem SMGW bereit zu stellen.

Bei der Definition der Anforderungen stand leider auch immer die kleinste Bilanzierungsphase im Energiemarkt im Scope und das sind 15min.

[tobima]

Welche Firmware Version hat dein SMGW? Bei mir ist es 31000000__X026e. Diese wurde im Oktober 2023 vom BSI zertifiziert. Seit dem gab es einige Updates. Wohl auch mit Änderungen der Messwert Verarbeitung und Darstellung über das HAN.
Auf der Startseite /start steht die Firmware Version.

[iseeberg79]

...X026f

Auf der Startseite sind nach Anmeldung schon alle Messwerte dargestellt.

[iseeberg79]

...X026f

Auf der Startseite sind nach Anmeldung schon alle Messwerte dargestellt.

Das Produkt CASA 1.0 wurde zur Verbesserung der Implementierung bezüglich Systemstabilität und Netzwerkverbindungen geändert. Daher änderte sich die SW-Versionsnummer von 30100000__X026e nach 30100000__X026f. Die Änderungen hatten keinen Einfluss auf die zertifizierte Sicherheitsfunktionalität.

Danach kommt noch (die bei mir aber nicht installiert ist):

Das Produkt CASA 1.0 wurde zur Verbesserung der Systemstabilitt hinsichtlich Kommunikation über die nicht zum EVG gehörigen Kommunikationsadapter geändert.
Daher änderte sich die EVG-SW-Versionsnummer von 30100000__X026f nach 30100000__X026g.
Die Änderungen hatten keinen Einfluss auf die zertifizierte Sicherheitsfunktionalität.

[tobima]

Die Versionsnummer sind etwas verwirrend. Wenn auf deinem SMGW die 30100000_X026f ist wäre, dass sogar eine ältere wie auf meinem.

[iseeberg79]

ja, verwirrend - hab 31000000__X026f

CASA 1.1
SW: 31000000__X026f, HW: 11301 / 11302

BSI-DSZ-CC-0919-V3-2023-MA-02
(Ausstellungsdatum / Certification Date 17.06.2024)

Die Produkte CASA 1.0 und CASA 1.1 wurden geändert, um die Verbindung zu externen Zählern und den Kommunikationsinterfaces für drahtlose Kommunikation zu verbessern. sowie um kleinere Fehler zu beheben.
Konfigurationsmanagement-Prozeduren erforderten eine Änderung der Produktidentifikation. Daher änderte sich die SW-Versionsnummer für CASA 1.0 und CASA 1.1 von 31000000__X026e zu 31000000__X026f.
Die Änderungen hatten keinen Einfluss auf die zertifizierte Sicherheitsfunktionalität.

[iseeberg79]

das Update kommt vom GWA? Wäre spannend, was sich ändert, wenn du auch 31...f hättest.

[iseeberg79]

Moin, nein - das wäre wohl der falsche Schluss. Aber Tatsache ist aktuell, dass man selbst eher weniger mit dem Meter anfangen kann und oft zusätzlich weiter ein Pulse oder anderer Netzzähler (Solarinstallation o.ä.) relevant bleiben

[tobima]

Der Nutzen eines iMSys liegt woanders. Ich bin gespannt wie lange Tibber den dynamischen Tarif ohne iMSys noch anbieten will. Alle anderen Marktbegleiter machen, dies nicht.
Variable Netzentgelte (14a Modul 3), Energy Sharing usw. sind nur mit SMGW möglich.

[iseeberg79]

Das hängt ja vom verbauten Zähler ab, ob der Pulse (oder "Volkszähler") kompatibel ist. Aber grundsätzlich ja, so steht das auch bei Tibber (parallele Übermittlung). Vorteil liegt in der Verfügbarkeit der Echtzeitwerte. Die Lastgänge und echten Zahlen stehen, zumindest bei mir, erst verzögert bereit (n. Tag). Aus meinem Meter kann ich die, glücklicherweise aber sogar direkt per HAN auslesen, aber das ist genau der seltene Fall aktuell.

[tobima]

Aus der eigenen Erfahrung und der Meldungen im Forum von Inexogy lassen lässt sich der Pulse weiter nutzen mit einem iMSys von Inexogy. Entweder bekommt man direkt vom Monteur die PIN für den Zähler um die Schnittstelle freizuschalten oder man frägt im Forum von Inexogy nach und bekommt relativ schnell eine Antwort.

[andig]

Bleibt bitte beim Thema. Hier gehts nicht um Tibber.

[flmuel]

Vielleicht für den ein oder anderen interessant -> Die TRuDI App für macOS könnt ihr hier in den Releases finden :)

[andig]

Trudi ist mangels Schnittstellen leider eine absolute Totgeburt der Regulierungsbürokraten.

[flmuel]

Dem kann ich leider nichts entgegnen. Die Benutzerfreundlichkeit, um sich mit den Gateways zu verbinden, ist ja schon ein Graus… keine Ahnung wer sich diese Sicherheitslogik ausgedacht hat. Sich „smart“ mit dem eigenen Smart Meter zu verbinden ist leider nicht…

[TRON4R]

Ich habe diese Home Assistant Integration geschrieben, mit der man zumindest ohne großen Aufwand automatisiert die Tagessummen aus seinem SMGW herausholen kann.

Ein Tarif wie der Intelligent Octopus Go mit verschiedenen Arbeitspreisen zu unterschiedlichen Uhrzeiten wird auch unterstützt. Auf die Weise kann man zumindest seine täglichen Verbräuche in HA erfassen und dann mit der Abrechnung von seinem Stromanbieter vergleichen. (Im Falle von Octopus durchaus sinnvoll, weil die leider auch mal die Stromwerte interpolieren, wenn sie die Daten von einem Tag - warum auch immer - nicht erhalten haben.)

Und mit TRuDI muss man sich dann auch nicht mehr herumschlagen.

Und ja, die Weboberfläche von dem SMGW ist auch eine Katastrophe. Härter zugenagelt als jede Online-Bank. Die kleinste Unstimmigkeit und man wird zwangs-ausgeloggt. Und dabei geht es da nur um simple Stromdaten und nicht um den Zugriff auf Geld oder persönliche medizinische Daten.

[theArcher73]

Nabend,

ja Trudi ist ein Produkt welches versuchte, die Anforderungen der physikalisch Technischen Bundesanstalt (PTB) zu erfüllen. Da stand nicht die Usability bzw. die Integrationsmöglichkeit im Vordergrund, sondern ein Fort Knox mittels dessen der Anwender signierte Messwerte abrufen kann und anhand der Signatur prüfen können sollte, das die Messwerte auch tatsächlich vom eigenen Zähler kommen. Wie schon treffend bemerkt, eine Totgeburt. Und die Security des SMGW - schaut man nur auf das Messwerthandling ist es der absolute Overkill. In dem Augenblick, in dem das Steuern lokaler Anlagen zu den Aufgaben des SMGW hinzukommt kommen wir in den Bereich des sicheren Netzbetriebes des Stromnetzes. Es ist leider relativ egal ob ein Angreifer zentral ein Umspannwerk oder dezentral eine Vielzahl der steuerbaren Verbraucher manipuliert - das Ergebnis sind signifikante Probleme im Netzbetrieb.

Für die Integration der HAN-Schnittstelle in ein Smart Home / HEMS gabe es bisher einfach kein final definiertes Schnittstellenformat. Daher zogen sich einige Hersteller der SMGW auf Trudi zurück, wer ein SMGW von EMH hat, ist da glücklicher dran. Dort läuft auf der HAN-Schnittstelle ein Webserver welcher die Messwerte als JSON bereitstellen kann. Kann, nicht muss - um da drauf zu kommen muss der Messstellenbetreiber mitspielen und die Credentials zur Anmeldung am Webserver bereit stellen. Die HAN-Schnittstelle wird aktuell oft mit einer fixen IP in einer Range bereitgestellt, die definitiv in kein Heimnetzwerk passt. DHCP würde auch gehen, macht aber keiner (aus Gründen). Die ersten Hersteller haben jetzt die Zertifizierung nach der neuen TR V2.0 - da wird hoffentlich einiges besser.

Was aber auch spannend ist, das BSI hat im Rahmen eines Impulspapiers die Möglichkeit eröffnet, das zukünftig direkt aus den SMGW's über die HAN-Schnittstelle eeBus gesprochen werden kann. Das hat bisher ein Hersteller umgesetzt - ich werde da mal mit evcc testen. Spannend sind in diesem Kontext die Usecases LPP und LPC, Mit den Usecase MPC könnte eeBus so auch das Messwertthema lösen, ich werde es mal versuchen.

[theArcher73]

Warum wundert mich das jetzt nicht? Der FNN vertritt statutengemäß die Interessen der Netzbetreiber, die haben das Thema Optimierung innerhalb der Kundenanlage nicht wirklich auf dem Zettel.

[WeAllScreamForIceCream]

Ich bekomme hoffentlich noch ein SMGW mit EEBus. Beantragt ist es beim Bayernwerk und soll mit der OpenWb §14a realisieren. Leider hat meine Wärmepumpe von Lambda keine vergleichbare Schnittstelle und wird über Kontakte mit Relais arbeiten müssen. Melde mich ggfs. nochmal wenn ich EVCC zum laufen bekomme.
Ich hatte avm.de vor einiger Zeit angeschrieben. Die könnten eine EEBus Schnittstelle mit MGCP anbieten. Schliesslich laufen deren "Kisten" sowieso rund um die Uhr. Sie haben es an das Produktmanagement weitergereicht und seither hab ich nichts mehr gehört.
Wird OpenWB MGCP von EVCC übernehmen?
Ein einfacher Ersatz für die IR-Köpfe wäre ein echter Vorteil.

[andig]

Wird OpenWB MGCP von EVCC übernehmen?

Ich glaube du fragst an der falschen Stelle. Aber warum nicht einfach evcc nehmen ;)

[WeAllScreamForIceCream]

Vermutlich wird es wohl so kommen. Stimmt natürlich. Schlanker wäre die Lösung bei mir allerdings integriert in die WB

[andig]

Auch da kannst du evcc installieren