Lokale API

Lieber FosCo, lieber API_DGY,

Leider habe ich bislang noch kein einziges Open Source Tool gesehen, welches das SML Protokoll zum lokalen Auslesen von Werten fehlerfrei unterstützt

Ich weiß nicht, ob 47_OBIS in FHEM das fehlerfrei macht, aber wenn da Fehler vorkommen, bin ich dafür zuständig und Ihr / Sie könnt sicher sein, dass ich mein Bestes tun werde, sie zu beheben. Ich habe die ehrenvoller Aufgabe des Maintainers vor 1/2 Jahr geerbt.

Ich möchte um Verständnis für Discovergy werben: Ich halte den Zertifizierungs- und Prüfungsaufwand für die „offiziellen SmartMeterGWs von BSIs Gnaden (samt Sicherer Lieferkette und Co)“ für absurd und ein signifikantes Hindernis der Energiewende. Wenn Discovergy hier durch einen TCP-Socket im LAN sich ein potentielles Angriffsrisiko einfängt, werden die Prüfungen noch umfassender ausfallen. Wir (vom Fach) wissen alle, wie oft gängige Software, die TLS-Ports im Internet bereit stellt, geupdated werden muss, und aus Sicht des BSI lauern die Finsterlinge ja vom Herstellungsprozess über die Lieferkette bis zum heimischen LAN auf die Manipulationsmöglichkeit. Wenn wir also überhaupt eine optische Schnittstelle haben, ist das ein Vorteil ggü. anderen SmGWs.

Im Rahmen von TAF14 sieht die Roadmap für deutsche SmGWs auch vor, dass der Kunde „hochfrequent“ und „als Mehrwertdienst“ seine Daten abfragen darf. Sprich: Da soll ein Standard kommen. Ich wäre unheimlich glücklich, wenn Discovergy hier einmal Einblick geben könnte, wie dieser Standard TAF14 denn einmal zum Endkunden hin aussehen könnte. „Mehrwert“ hört sich aber schon nach „Mehrkosten“ an. Es soll also - wie beim deutschen Trödelzertifizierungsmichel im Allgemeinen - irgendwann mal was kommen - aber wie das aussehen könnte, weiß ich nicht, und ob es kostenfrei wie jetzt bei Discovergy sein wird, auch nicht.

Deswegen denke ich, dass man froh sein sollte, wenn man bei Discovergy sogar beide Wege zur Verfügung hat.

Wie sexy das ist, wenn der Amtsschimmel sich die Zukunft ausdenkt, findet man hier:

„Fahr’ eine zertifizierte CD mit Linux hoch, um Deinen Stromzählerstand abzufragen“.

3 „Gefällt mir“

Der Bericht ist von 2015, ich hoffe, das die Software zwischenzeitlich weiter entwickelt wurde.
Hier in diesem Forum hätte ich gerne Informationen über den Stand der Technik (nennt sich Innovation) und nicht über alte „Kamellen“

Hallo gvzdus,

Vielen lieben Dank für deine ausführliche Antwort!

Das Sicherheitsproblem ist mir aus dem Automotive Bereich bekannt und nicht zu unterschätzen.

Dennoch würde ich mich über eine lokale Möglichkeit der Abfrage freuen :grinning:

Schön, dass der Kontakt hier nun direkt besteht!
Gerne teste ich das auch mit meinem FHEM und meinen beiden discovergy Zählern.

1 „Gefällt mir“

Ja, es könnte so schön sein: Man verbindet die Wallbox mit dem heimischen WLAN, per UPnP erscheint „Stromzähler gefunden, möchtest Du Überschussladen?“ - und fertig. Und genau so wird es mit Sicherheit nicht sein :slight_smile:

Wie geschrieben: Ich wäre hochinteressiert, wie sich der Gesetzgeber und Zertifizierer denn TAF14 („Tarif-Anwendungs-Fall 14“) vorstellen: Entweder, ich war nicht beim Googlen geschickt genug, oder es gibt noch sehr wenig.

Gerne teste ich das auch mit meinem FHEM und meinen beiden discovergy Zählern.

Ich habe daheim eine ganz normale moderne Messeinrichtung und bin hier im Forum lediglich, um die Entwicklung mitzubekommen - oder falls ich als PV- und Wallbox-Betreiber mal in ein SmGW gedrängt werde: Dann würde ich natürlich Discovergy bevorzugen.

Wenn Du die optischen SML-Ausgänge hast (kann man angeblich gut mit der Handykamera überprüfen), kann ich Dir gerne zum Testen einen IR-Kopf leihen. Ich habe daheim sowohl einen IR-USB als auch IR-TTL-Kopf zu Testzwecken liegen, am Zähler hängt der Weidmann-Lesekopf. Wenn’s klappt, kannst Du ihn ja zurückschicken. Mit FHEM auf „verbose 5“ wird ein Logfile geschrieben, dass ich 1:1 zum Entwickeln (bei Problemen) wieder einlesen kann.

Thread im FHEM-Forum ist der hier:

Ich heiße auch im FHEM-Forum gvzdus

1 „Gefällt mir“

Moin, danke für das Angebot, ein IR Kopf kommt bei mir leider nicht in Frage. Abgesehen von der Praktikabilität (FHEM örtlich ganz woanders und Produktionszähler im komplett verplombten Kasten), finde ich das irgendwie Overkill.

Upnp macht ja alles auf.
Würde mir eher einen Zertifikatsabruf vorstellen können mit oauth2 oder ähnlichem, so dass ich mich über die Cloud einmalig (oder automatisiert regelmäßig wie let’s encrypt) authentifizieren, um dann per FHEM und openWB auf die Zähler lokal zugreifen kann.

@API_DGY was haltet ihr von dem Vorschlag?

@gvzdus wäre so etwas umsetzbar? Außer dem Anstoß für die Xiaomi Umsetzungen habe ich bei der Modulentwicklung in FHEM aus Zeitgründen bisher wenig gemacht.

Hi Fosco,

ich möchte Dich noch auf einen ähnlichen Thread vom Mai hinweisen:

Im Prinzip habe ich da ähnliches geschrieben. Die (für mich) interessanten Antworten waren von Pablo Santiago (von Discovergy).

… Wir erwarten aus diesem Grund, dass unser eigenes Gateway direkt bei der Zertifizierung TAF14 (Hochfrequente Messwertbereitstellung für Mehrwertdienste) abbilden kann. …

und auf Nachfrage:

Wenn auch noch nicht zertifiziert, bildet bereits unser Smart-Meter-Gateway Meteroit 3.5, als Vorversion der zertifizierten Hardware, TAF 14 ab, mit Datenübertragung entweder via HAN oder per Mobilfunkanbindung. Ist eine Übertragung via HAN nicht möglich, wie es etwa in der Regel der Fall in einem Mehrfamilienhaus ist, und gibt es keinen auszureichenden Mobilfunkempfang, dann wird der Einsatz intelligenter Zähler problematisch.

Das hört sich für mich für unsere Fälle „EFH, Zähler am LAN“ sehr hoffnungsvoll an. Die offene Frage für mich ist: Wie sieht diese Datenübertragung nach TAF14 aus? Exakt die API von heute, oder etwas Neues?

1 „Gefällt mir“

Leider sind hier noch sehr viele Elemente beweglich. Generell versuchen wir hier aber (mit Hinblick auf TAF14) zweigleisig zu fahren und nach Möglichkeit eine ähnliche Schnittstelle lokal anzubieten, wie diese auch über api.discovergy.com funktioniert. Dies bedeutet zwar auch, dass es kein Websocket lokal geben wird, dafür aber mit fast jeder Bibliothek und „Dritt-Anbieter“ Lösung kompatibel sein sollte. (bis auf die Authentifizierung).

Etwas Low-Tech ausgedrückt, sieht TAF-14 auch vor, dass beliebige Mehrwertdienste verlässlich das Gateway nutzen sollen. D.h. durch ungewollte Implementierungsfehler könnte ein Dienst eine DDoS Flut von Anfragen schicken und parallel einen anderen Dienst den lokalen Verbindungsaufbau unmöglich machen. Man stelle sich die Wirkleistungsbegrenzung eines Wechselrichters auf Basis dieser Schnittstelle vor, die auf den selben „Zugang“ wie das Lastmanagement eines Ladeparks zugreift. Hier redet man bei kurzfristigen Verbindungsproblemen gleich davon, dass die Anschlusssicherung auslöst, weil kurzfristig kein Management bei einer der Geräte stattgefunden hat.

Das Problem ist, dass wir hier von kritischer Infrastruktur sprechen, welche man nach dem Roll-Out nicht wieder verändern kann. Letztendlich wollen alle Komponenten sich auf die Daten verlassen, da diese der Konsens für die eigenen Optimierungen sind.

Doch… so soll es sein, aber leider nicht schnell… Es werden noch Eonen von Jahre vergehen, aber dann wird genau das Möglich sein. Bis dahin wird es allerdings auch noch mehrere Code Generationen von FHEM, openWB und Co. geben, die irgendwie einen „UPnP“ tricksen. IP-Symcon zum Beispiel erkennt heute bereits den Discovergy Zähler im genannten 3.5er Gateway „automatisch“, wenn auch der Mechanismus, der hier verwendet wird, eher etwas „Zufall“ ist.

2 „Gefällt mir“

Danke für die Antwort, das gibt Anlass zur Hoffnung.
Genau die beiden usecases habe ich bei mir.
Auch wenn mein WR wohl keine Wirkleistungsbegrenzung über ein IMsys unterstützen wird.
Das Lastmanagement verlässt sich aber heute bereits auf die Schnittstelle, bei API Ausfall muss ich mir sonst 3 Schmelzsicherungen hinlegen :wink:

Ganz herzlichen Dank für die ausführliche Antwort! Ich nehme für mich einmal mit: Die Dinge in Sachen standardisiertem TAF-14 sind noch sehr im Fluß und weniger schon in Dokumenten niedergelegt, die ich nicht gefunden habe oder nicht öffentlich sind. Auf jeden Fall ist Ihr Ausblick hoffnungsvoll.

Anregung:
Was ich an Ihrer Stelle wohl machen würde, um eine proprietäre LAN-Lösung anzubieten: Optional („ein/aus“) im LAN Multicast-Pakete unquittiert versenden, z.B. die Bytes, die heutzutage auf den optischen OBIS-Schnittstellen anfallen. Diese dürften in ein einzelnes UDP-Paket passen. Das ist zwar proprietär und unquittiert, aber vermeidet jeden Input aus dem Netz, der sonst zu ausnutzbaren Schwachstellen führen könnte. Allterco / Shelly hat so etwas gemacht, nennt es CoIoT als auf CoAP aufsetzendes Protokoll, und „die einschlägigen“ SmartHome-Systeme (OpenHAB, ioBroker, FHEM) unterstützen es.

Broadcast hat den Nachteil, dass die batteriegestützten WiFi-Geräte nicht abbestellen können.

Das von Ihnen beschriebene Thema des Wechselrichters könnte man - falls es um die 70% Einspeisebegrenzung geht - ggf. auf der Seite des Wechselrichters durch den Fallback auf einen harten Threshold lösen („Wenn 40 Sekunden kein MCast-Paket empfangen und ein MCast-Join nichts nützt, dann auf 70% zurückfallen“).

Auf jeden Fall würde das Ihre Server von unseren Anfragen freihalten, und wäre als lokale Lösung wohl auch stabiler. Und so proprietär wäre es auch nicht: Immerhin könnten ja auch andere - bis hin zu Lösungen wie powerfox (optischer Lesekopf für iMSyS) sich ja mit ein paar Zeilen Code zusätzlich Ihrer Lösung anschließen.

3 „Gefällt mir“

Coole Idee, dann würde ich da zwar am Routing fummeln müssen, aber es wäre eine (evtl. bSI taugliche) Lösung :grin:

Meiner Einschätzung nach wäre dieser Ansatz mit am Effektivsten. Wir wissen von anderen Anwendungsfälle (IPTV), dass einige Routerhersteller auch UDP Multicast für lokale WIFI Geräte einschränken können.

Wäre die aktuelle Gateway 3.5 Generation überhaupt updatefähig aus der Ferne um so eine lokale API in Zukunft anbieten zu können?

1 „Gefällt mir“

@API_DGY
Gibt es Neuigkeiten zum Thema lokaler Zugriff?
Im Zuge meiner Recherchen für eine Speicherlösung (Victron Venus gesteuert) werde ich ohne lokale API des DGB Zählers nicht an einem 300€ teuren EM24 vorbeikommen, obwohl der bereits physisch vorhandene Zähler es könnte…
Das erscheint mir komplett widersinnig, da eine Speichersteuerung natürlich nicht von der Cloud abhängig sein darf :frowning:

Hallo zusammen,

ich habe eine weitere einfache Frage zum Thema Schnittstelle. Ist es auch für einen von Discovergy verbauten ImSys Zähler mit Dr.Neuhaus Gateway möglich die Verbrauchsdaten über eine Schnittstelle auszulesen?

Hallo @Camillo,

Ich gehe davon aus, dass sie auch verfügbar sind, aber ich müsste nachfragen. Ich melde mich zurück, sobald mir das bestätigt wurde.

Viele Grüße
Pablo Santiago, Discovergy GmbH

lokal auslesen ist bei den Meteorit-Gateways ja ueberhaupt nicht moeglich, sondern lediglich am Zaehler selbst ueber die vordere IR-Schnittstelle. Wenn die Dr. Neuhaus-Gateways eine lokale Schnittstelle beiten wuerden waere das ja sogar ein Vorteil ggue. den Meteorit.

Hier ist übrigens das Datenblatt zum Meteroit 3.5

Ich habe die Dreipunktvariante:

  • Erweiterungsteckplatz USB (für zukünftige Kommunikationsstandards, z.B. LoRa)
  • Interner BUS zum Steuern und Regeln z.B. Steuerbox
  • Integrierbare Abschaltvorrichtung

Das könnte ich alles super gebrauchen. Weiß jemand mehr?

Hallo @Camillo

sorry, ich habe Ihre Frage schnell gelesen und dachte, Sie beziehen sich ausschließlich auf unsere API, worüber die Daten Ihres Smart Meters mit Dr. Neuhaus Gateway auch verfügbar sein sollten. Darüber hinaus, da Sie über ein zertifiziertes Gerät verfügen, sollten Sie Zugang zu bestimmten Diensten und Daten über das Home Area Network (HAN) haben – siehe bitte „3.4. Vorgaben an die Kommunikationsverbindungen in das HAN“ ab Seite 56. Zertifizierte intelligente Messsysteme bieten zudem über die HAN eine alternative Visualisierung der Messwerte über die Transparenz- und Display-Software (TRuDI), worüber Sie hier weitere Informationen finden.

Viele Grüße
Pablo Santiago, Discovergy GmbH

Wow, das hört sich ja traumhaft an. Mein Meteroit 3.5 ist also kein zertifiziertes Gerät? Ich möchte auch so eine Schnittstelle.

Du hast eine 3.5?
Dann wirst vermutlich keine andere bekommen, weil für iMSys auch der Zähler getauscht werden muss…

Vielen Dank für die schnelle und aufschlussreiche Antwort.