Momentan kann man die API nur über einzelne HTTPS Requests abfragen. Das ist extrem teuer sowohl auf dem Server als auch auf dem Client vor allem, wenn der Client die Verbindung nicht offen hält (bzw. offen halten kann), da hier jedesmal ein neuer SSL Handshake, Zertifikatsabfrage etc. stattfindet.
Meine Implementierung für eine ESP8266 MCU braucht für eine Zählerstandabfrage ca. 5s.
Hierfür würden sich Websockets wesentlich besser eignen und auch auf der Serverseite die Last beträglich senken.
Ist so etwas in Planung?
1 „Gefällt mir“
Die Wahl auf eine reine HTTPS Unterstützung ist bei uns gefallen, da der REST Standard hier eindeutig definiert ist und die meisten Laufzeitumgebungen mittlerweile die Verbindung halten können. Websockets hat den Nachteil, dass eine TCP Verbindung zwangsweise gehalten werden muss und somit nicht bei Bedarf getrennt werden kann. Dies schränkt die maximale Anzahl der Clients je Server IP wegen der möglichen Ports sehr stark ein. Websockets wird daher auf absehbare Zeit von der API nicht unterstützt.
Ok, danke für die Information. Ich glaube ehrlich gesagt nicht, dass die begrenzte Anzahl der Ports auf absehbare Zeit eine Limitierung der Nutzung der Schnittstelle darstellen wird. Es kommt natürlich auf die Implementierung an, aber es lassen sich relativ problemlos mehrere hunderttausend, gleichzeitige TCP Verbindungen pro Server/AWS Instanz realisieren. Da fliegt einem normalerweise vorher etwas anderes um die Ohren, gerade, wenn es sich wie bei Discovergy um individuelle Daten handelt auf die zugegriffen wird.
Der Tod für einen Server sind nicht viele Clients, sondern langsame Clients und das Risiko, das man diese hat oder bekommen wird ist bei der derzeitigen Schnittstelle hoch.
Alternativ wäre natürlich auch eine Anbindung per MQTT vielleicht noch besser. Langfristig wird Discovergy allerdings nicht um eine lokale Schnittstelle rumkommen, wenn man die Zählerdaten wirklich zur Gerätesteuerung einsetzen möchte.
Mit der oben genannten Logik gehe ich davon aus, dass auch die Zähler selber per HTTPS REST Schnittstelle angebunden sind. Wobei REST kein Standard ist und auf keinen Fall eindeutig definiert ist 
2 „Gefällt mir“
Ich frage mich seit Anfang an, aus welchem Grund die Abfrage nur über den Discovergy Server/API geht. Wieso wird hier künstlich Traffic und Serverlast produziert. Eine lokale Abfrage im Netzwerk wäre für alle einfacher. Aus welchem Grund habt ihr euch bei Discovergy für diesen Weg entschieden? Wenn es um Support geht, so könnte man die lokale Schnittstelle ja ohne Support anbieten. Eine Schnittstellenbeschreibung vorausgesetzt.
Hier muss man etwas die Historie bedenken. Erst mit dem Smart Meter Gateway kam/kommt eine Definition, wie eine sichere „interne“ Schnittstelle aussehen soll und wird mit der HAN Schnittstelle auch von uns unterstützt.
Bei Heimnetzwerken ist das Problem, dass hier die Absicherung der Messwerte vor unberechtigtem Zugriff deurlich schwieriger ist. Ich denke, es ist bekannt, dass ungesicherte Websockets oder http-server im LAN relativ einfach auch aus dem Internet abgerufen werden können. Dieser Gefahr konnten wir uns nicht aussetzen.
1 „Gefällt mir“
Danke für die Info. Wird der Zugriff auf die HAN Schnittstelle bei bestehenden Installationen nachgereicht? Ab wann werden SmartMeterGateways nach der neuen Zertifizierung und mit Zugriff auf HAN ausgeliefert? Werden die neuen SmartMeterGateways nach wie vor Daten in echtzeit liefern, oder nur in 15 min. Intervallen?
„Jein“ - wenn es sich um ein SMGW mit einer HAN Schnittstelle handelt, dann ja. Da es im Feld allerdings viele Gateways ohne diese Schnittstelle gibt, ist dort ein Hardwareumbau notwendig.
Die Echtzeitdaten sollen bleiben, die 15 Minuten Intervalle sind eigentlich nur für die Abrechnung über die Marktkommunikation von Bedeutung.
1 „Gefällt mir“
Für ein „echtes“ SmartMeterGateway kann ich das nachvollziehen. Aber warum nicht bei den Meteoriten?
Und die Zähler habt Ihr die ja blöderweise auch noch so konfguriert, dass man im Display jedesmal die PIN per Tashenampe eingeben muss, um Daten zu sehen. Und nach 2 Minuten geht auch das wieder nicht. Gemeinerweise steht das nicht im Prospekt. Das merkt man erst, wenn es zu spät ist.
Da könnte man glatt vermuten, das D. sich mittels des Portals unentbehrlich beim Kunden machen möchte, wenn der seine eigenen Daten sehen will. Lokal geht da nichts.
2 „Gefällt mir“
Ich würde ebenfalls gerne die Zähler direkt abfragen, allerdings nicht über das Internet,
sondern per Direktzugriff über das lokale Intranet - also das heimische Netzwerk.
Ein http-Request auf die direkte IP des Zählers ( http://192.168.xxx.xxx/ ) via PHP.
Ich denke, dass es etliche Interessenten für diese Art der Abfrage gibt, und dass
ein Gedanken-Anschubser an Discovergy helfen könnte, dieses Thema nochmals
zu überdenken.
Danke & Gruß,
Volker
2 „Gefällt mir“
Also nur weil ein Gerät im heimischen LAN einen offenen TCP port mit einem http Endpunkt anbietet, ist es definitiv nicht „relativ einfach aus dem Internet“ darauf zuzugreifen. Jedes Heimnetzwerk nutzt einen Router der NAT nutzt, so steht nur der Router selbst im Internet. Geräte hinter dem Router sind, sofern keine Port-Weiterleitung oder UPnP eingerichtet wird, NIEMALS erreichbar.
Wenn natürlich der Router selbst gehacked wird gilt dies nicht mehr, aber dann wären meine Stromverbrauchsdaten meine geringste Sorge…
1 „Gefällt mir“
Naja, es muss ja ein absoluter Querschnitt an Kenntnissen der Netzwerktechnik vorausgesetzt werden. Da liege ich vermutlich drüber und du erst Recht, aber auch der DAU will nicht, dass sowas ne Angriffsfläche bietet, obwohl er keine Ahnung hat was da ein Problem sein könnte…
Und als Firma muss discovergy sich leider absichern.
Aus meiner Usersicht hätte ich gerne einen Direktzugriff auf die Zähler, mit immer gültigen Zertifikat und allem Pipapo, aber das ist leider nur für einen kleinen Kreis an Nutzern relevant und daher vermutlich weit hinten auf der Liste 
ist leider so nicht richtig, da man bei Websocket an den IP Range des Heimnetzes kommt und besonders die des Routers. Dank des UDP Protokolls kann man dann Pakete an den Router senden, als ob diese von „intern“ kommen würden und werden an alle Geräte im LAN unter interner IP weitergeleitet.
Hi API_DGY, erstmal danke für deine Antwort am Sonntag Abend, da merkt man schon jemandem macht sein Job Spaß 
Hast du für dieses Websocket/UDP Risiko eine Quelle? Hab dazu auf die schnelle nichts eindeutiges gefunden, wo nicht das Gerät im LAN explizit selbst mitmachen muss um den Router zu „überwinden“.
Was ich aber in meinem Kommentar beschrieb war ja ein ganz klassischer HTTP Endpunkt auf TCP Basis, wie ihn z.b. auch viele Wechselrichter im LAN anbieten. Wo seht ihr da das Risiko?
Eine Quelle findet sich in unter anderem in Kombination mit einer Suche nach WebRTC. Die Herausforderung besteht darin, dass man sich einen anderen Client als Relay bedient.
Beispiel: Im LAN existiert ein TP-Link 860RE als Repeater, dieser hat eine schicke Admin Oberfläche, welche auf Port 80 via TCP erreichbar ist aus dem LAN. Auf einer Webseite (irgendwo im Internet) nutzt man nun WebRTC, um die interne IP Adresse eines Besuchers in dessen LAN herauszubekommen. Nun iteriert man lediglich die 255 wahrscheinlichen IP Adressen im LAN und schaut, ob man via XMLHttpRequest eine positive Antwort auf http://192.168.178.x/proxy.js erhält. Wenn ja, dann hat man die interne IP Adresse des Repeaters und kann nun sich als internes System dessen API bedienen.
Den TP-Link Repeater habe ich hier nur als Beispiel genutzt. Bei einem Varta Engion Storage konnte man diesen früher komplett fernsteuern über diesen weg (ist gefixt), bei der Wallbox, die hier bei mir hängt kann ich auf diese Art die Ladung sperren und steuern - ohne, dass ich jemals physikalisch an meinem LAN gewesen bin. Anders ausgedrückt: LAN ist sicherer, hat aber auch Angriffspunkte, die man bei einem SmartMeter (inkl. Gateway) nicht haben will, vor die der DLS Router mit NAT einen nicht schützen kann.
2 „Gefällt mir“
So ganz kann ich die Argumente nicht nachvollziehen. So wie ich das verstanden habe, sagst Du, weil Gerät xyz ein potentielles Sicherheitsproblem haben kann, können wir das nicht machen. Das ist natürlich ein Totschlagargument. Auf dieser Grundlage kann man gar nichts machen.
Auf der anderen Seite hat der Zähler schon jetzt offene Ports und auch ein Portforwarding im Router wurde in der Installationsanleitung empfohlen.
Zumindestens war das vor gut einem Jahr so. Ich weiß nicht, ob das immer noch so ist. Aber da ist das Sicherheitsproblem noch viel größer, weil es nun einen offenen Port ins Internet gibt.
Dann gibt es dann noch das Problem, dass der Zähler in meinem Netzwerk regelmäßig abgeraucht ist und nur in einem getrennten Gastnetzwerk stabil läuft. Das halte ich persönlich für ein viel größeres Sicherheitsproblem, da es geradezu zu einer Denial of Service Attacke einlädt.
Alles in allem halte ich einen Websocket, der z.B. mit einem Zertifikat abgesichert ist für ein überschaubares Sicherheitsproblem.
Ich benutze die API zur Steuerung von Verbrauchern und monitore auch die Latenz. Ich kann aus meiner Erfahrung sagen, das die Latenz im Großen und Ganzen bei ca. 1,5 Sekunden ist. Leider aber schon relativ häufig Ausreißer hat. Das ist für die Gerätesteuerung natürlich ein Problem. Außerdem erzeugt ein HTTPS Request alle 5s meiner Meinung nach nicht ganz unerhebliche Last auf Euren Servern. Vor allem bei Clients, die die Verbindung nicht halten, sondern jedesmal neu durch den SSL Handshake gehen.
3 „Gefällt mir“
Ich hänge mich einmal dran. Kurz zur Vorstellung (1. Post hier im Forum): Ich finde die Idee von Discovergy und Awattar genial, im Prinzip auch SmGWs an sich. Situation: 10 kWp auf dem Dach seit 07/20, BEV vor der Tür, moderne Messeinrichtung. Ich habe außerdem die Rolle des Maintainers für das OBIS-Modul beim SmartHome-System FHEM übernommen.
Stand jetzt würde für mich ein SmGW einen Rückschritt bedeuten: Z.Zt. verarbeite ich meine Daten quasi im Sekundentakt lokal auf dem Raspi über den optischen Lesekopf an der D0-Schnittstelle der modernen Meßeinrichtung.
Wie ich in diesem und anderen Threads hier lese, nimmt Discovergy das Bedürfnis einiger (weniger?) Benutzer ernst, ihre Daten lokal und hochfrequent zu erhalten. Wenn ich Euch / Ihnen eine Empfehlung für eine möglichst simple „proprietäre“ Implementierung machen dürfte: Ich würde im heimischen LAN Multicast-Pakete nach CoAP-Standard versenden. Damit müsste kein Port am SmGW geöffnet werden, keine Settings am SmGW (außer vielleicht an/aus). Ähnlich machen es die Shelly-Devices, und die SmartHome-Systeme wie FHEM, OpenHAB, ioBroker setzen auf die Multicasts auf.
Der Standard soll ja wohl TAF-14 werden, aber hier ist mir nach schnellem Lesen nicht klar, wie hier die Lösung aussehen soll, um das zu erreichen, was heute mit einem IR-Lesekopf an der D0-Schnittstelle für den Nutzer schon möglich ist.
Viele Grüße, Georg Zezschwitz
2 „Gefällt mir“
Hallo Georg,
danke für deinen konstruktiven Beitrag. Ich würde mir eine implementierte HAN Schnittstelle nach BSI Spezifikation wünschen. Broadcast bzw. Multicast sind in flachen Netzstrukturen okay, aber nicht in größeren Umgebungen. In meinem Beispiel gibt es zwei Hände voller VLANs mit getrennten IP-Netzen, einer routenden Firewall dazwischen. Da wäre Multicast eher sehr nervig, aber eine klare, dokumentierte HAN Schnittstelle direkt auf dem SmGW wäre toll. Ich bin da sehr, sehr skeptisch, dass Discovergy hier etwas machen wird. Mir würde erstmal reichen, dass nicht regelmäßig Daten verloren gehen.
Als Teil meiner PV Anlage habe ich mir einen Sunny Home Manager von SMA einbauen lassen. Der liefert mir zum Glück über Modbus/TCP sekundrnschnell alles was ich brauche inkl. Eigenverbrauch. Ich habe den in ein OpenEMS Energiemanagementsystem eingebunden.
HAN hochfrequent wäre ja okay, und natürlich ist ein Standard immer die bessere Lösung. Ich weiß nur nicht, wann TAF14 fertig sein wird, und ich kann die Bedenken von Discovergy verstehen „irgendwelche TCP-Ports“ zu öffnen - natürlich entstehen damit Risiken. Deswegen der UDP/MCast-Vorschlag als Provisorium.
Wenn ich TAF14 lese, z.B. so beschrieben: „Mit der Bereitstellung des neuen TAF 14 (“Hochfrequente Messwertbereitstellung für Mehrwertdienste”) wird auch die Attraktivität des SMGWs für den Letztverbraucher vergrößert. Mit diesem Anwendungsfall können Messstellenbetreiber ihren Kunden die Visualisierung von hochaufgelösten Daten und darauf aufbauenden Dienstleistungen anbieten. Dabei können die Daten hochfrequent an den Externen Marktteilnehmer übertragen werden.“ dann „riecht“ das durch Worte wie „Mehrwertdienste“ danach, als ob ich mir meine eigenen Daten beim Meßstellenbetreiber wieder zurückkaufen dürfte - ein Unding m.E. Wo ich Beschreibungen von TAF14 lese, geht der Weg nicht lokal, sondern über den MSB und „die Cloud“.
Deine Lösung mit dem HomeManager von sma ist ja sauber. Allerdings habe ich die gleiche Situation wie ein Freund, der einen sma HM 2.0 hat: WR ist von SolarEdge, und „sie sprechen nicht miteinander“. Auch ist es einfach ökonomisch unsinnig / redundant, wenn 2 digitale Geräte hintereinander den Stromverbrauch messen (offizieller Zähler und sma HM) - es sei denn, ein Stromspeicher fordert ein so schnelles Feedback auf der Netzseite, dass ein Netzzähler mit seinem Sekundentakt zu langsam wäre.
Ob UDP/Multicast die sichere Lösung sind, als ein offener TCP-Port. Ich weiss ja nicht. Sauber wäre ein offener TCP-Port, API mit TLS und Zertifikatauthentifizierung und Connection Limit als „Mini-DDoS“ Schutz. Die API kann dann gerne auch die Bedingungen für die BSI HAN erfüllen.
Da kann ich nicht ganz folgenden. Du brauchst doch sowieso bei einem Zwei-Richtungszähler von Discovergy noch einen Erzeugungszähler, sonst kannst du sowas wie Eigenverbrauch, aktive Überschussladung usw. ja gar nicht nutzen. Und das ist der Home Manager 2.0 (in Verbindung mit einem SMA Wechselrichter) für mich persönlich optimal. Ich finde aber auch beim SHM seltsam, dass der seine Daten nur mit dem Wechselrichter teilt und keine autonome Modbus/TCP Schnittstelle hat.
Um hier vielleicht auch nochmal für @API_DGY ein paar Anhaltspunkte zu geben:
Es läuft hier ein raspi, der eine Displayoberfläche bedient und den aktuellen Stromverbrauch anzeigen soll. Hier habe ich schon auf 10sec begrenzt, was optisch hässlich wird (Produktion und 2R-Zähler sind dadurch nicht immer im Sync).
Nun ist noch eine openWB dazugekommen, da habe ich keinen Einfluss auf die Frequenz.
Über 24h ist der api.discovergy.com Aufruf Spitzenreiter nach außen im Netzwerk, das ist absolut unnötig:
