Moin, wie in Websocket support? - #20 von FosCo bereits erwähnt, sind die Zugriffe nach extern echt viele, da sowohl die Wallbox, als auch der FHEM Pollen.
Den FHEM werde ich auf die Wallbox umbiegen bei Zeiten, aber auch die OpenWB Entwicklung sagt, dass discovergy hier leider eine unerfreuliche Ausnahme darstellt.
Bitte bitte @API_DGY, schafft hier eine wie auch immer geartete Schnittstelle!
Danke und Grüße
Jonas
Unterstütze ich voll und ganz, laut meinem pi-hole 34.000 Anfragen über die API in 24 Stunden !!!
Wäre schön wenn man mal irgendeinen Entwicklungsfortschritt sehen würde…
Genau das gleiche hier :-\
Und dann das Ganze mal hochrechnen auf mehrere 1000 Kunden 
Also die Anfragen pro Kunde muss Discovergy verkraften, das ist deren Problem, was sie ja auch im Griff zu haben scheinen.
Ich wollte hier ein Thema mit einer freundlichen bitte starten, freue mich auch über Unterstützung, muss mich aber klar von deinen Formulierungen und dem sauren Smiley abgrenzen.
Ich fordere nicht, ich bitte um etwas, und das freundlich!
wenn es euch nur um LIve-Daten des Zählers geht, wie aktueller Verbrauch (ggf. nach Phasen) und Zählerstand: am besten den Zähler selbst „auslesen“. Der sendet sekündlich ein Datenpaket per IR aus das ihr mit einem Lesekopf auslesen könnt, normales binäres SML. Kann FHEM z.B. mit dem OBIS-Modul auswerten. Der Lesekopf muß nur leider mit Klebeband fixiert werden weil kein Metallring am Zähler vorhanden ist.
Bekannter Workaround, bei einem Smartmeter im Netzwerk aber Overkill 
Na, ja , wenn man hier liest was Discovergy so alles nicht im Griff hat, kann einem das schon mal sauer aufstossen…Man merkt schon ab und zu dass die Server an ihre Leistungsgrenze stossen beim übermitteln der Daten, da gibt es schon mal Aussätze von einigen Sekunden bis zu 1-2 Minuten. Ob das der allgemeinen Netzbelastung geschuldet ist oder spezifisch an Discovergy hängt kann ich nicht direkt beurteilen. Mit einer lokalen API könnten diese Probleme wenigstens teilweise umgangen werden. Es muss ja nicht immer alles den Umweg über die Cloud nehmen.
@gnampf Der Kunde zahlt hier ein vielfaches der Messtellengebühr des Grundzuständigen, dementsprechend sind auch die Erwartungen. Ich gehe doch dann nicht hin und baue mir zusätzlich eine eigene IR Infrastruktur auf…
Die Grundsatzdiskussion bzgl. Geld würde ich hier gerne rauslassen, es ist die freie Entscheidung zu wechseln.
Mich würden eher die technischen Optionen interessieren.
Wenn es zu diesen Leistungsgrenzen kommt, dann sind diese nicht von der Skalierung der Systeme abhängig, sondern eher auf zum Beispiel eine fehlende LTE Verbindung, ReConnect bei DSL oder - und das kommt natürlich auch bei uns vor - einem Update auf unseren Servern zurückzuführen.
Der Umweg über die Cloud hat aus Betriebssicht viele Vorteile, da hierdurch auch die Qualität der Daten besser sichergestellt werden kann und ein Konsens über abrechnungsrelevante Sachverhalte hergestellt wird. Eine lokale API ist vonseiten des Supports eine Herausforderung für sich, die ganz andere Schwierigkeiten mit sich bringt. Besonders, wenn hier schnell etwas zusammengezimmert wird und man denkt, damit einen Industriestandard zu erreichen. Leider habe ich bislang noch kein einziges Open Source Tool gesehen, welches das SML Protokoll zum lokalen Auslesen von Werten fehlerfrei unterstützt … lasse mir aber gerne Tipps geben, denn das suche ich bereits einige Zeit und würde auch hier im Forum bestimmt einigen weiterhelfen.
FHEM hat da ein Perl Modul für:
LastValue für Gesamtleistung wurde mit schon genügen. Biete mich mit meinen beiden Zählern und nem FHEM gerne zum Testen an 
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“.
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 
Schön, dass der Kontakt hier nun direkt besteht!
Gerne teste ich das auch mit meinem FHEM und meinen beiden discovergy Zählern.
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
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
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?
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.
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
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.