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.
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.
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…
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.
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.
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.
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:
Ist bei mir genauso, 34158 Aufrufe der API ins WEB, absolut unnötiger Traffic, sowohl local als auch bei Discovergy selbst. Vielleicht ist dies eine der Ursachen der Serverüberlastung von Zeit zu Zeit ? Wir sind ja wohl nicht die einizigen die die API dementsprechend nutzen…
Ich weiß ja nicht, wie oft das Dashboard versucht, die Daten zu bekommen, jedenfalls hat es am Anfang - ich bin seit 12.Mai dabei - jede Sekunde einen neuen Wert angezeigt. Das war mir zu hektisch, ich habe eine eigene Anwendung geschrieben, die die Daten nur alle fünf Sekunden holt. Irgendwann kamen die Daten dann nur noch jede Minute und ich habe habe hier im Forum gefragt, warum. Antwort: irgendwo sei eine Mobilfunk-Verbindung beteiligt. Dann ging es auf einmal - ohne mein Zutun - wieder im sekündlichen Abstand, dann wieder nicht, und jetzt schon seit vielen Tagen nicht mehr. Wenn es an einer Überlastung des discovergy-servers liegt, kann ich den Wunsch gut verstehen, die Daten im Heimnetz abgreifen zu wollen.
Wohl eher ja, denn auch vorher waren immer genügend Ressourcen verfügbar. Wir hatten einmal ein extern einsehbaren Status-Monitoring, bei dem man dies auch im langfristigen Verlauf hätte sehen können, finde allerdings die URL gerade nicht - werde mich aber erkundigen.
Ich habe mir gerade mal angesehen, was das Widget „Verbrauchsanzeige“ so tut. Um im Sekundentakt nur eine einzige Zahl anzuzeigen, überträgt es jedes Mal ca. 1,6 kb Json-Daten mit allem möglichen Kram wie Zählernummern, Bezeichnungen, massenweise leere Felder… Das ist doch Wahnsinn?
