FORDERUNG: Freigabe des Zugriffs auf die lokalen Schnittstellen (RS485/S0 und LAN/MQTT)

Liebes Discovergy Team,
Die Vorfälle der letzten Monate gezeigt haben, dass eine zuverlässige Steuerung mit einer Cloud Only Lösung NICHT funktioniert.
Daher nun eine FORDERUNG an Discovergy:
Freigabe der lokal vorhandenen Schnittstellen (RS485, S0, LAN, MQTT) damit die Heimautomatisierung auch OHNE Internet und Cloud funktioniert!
Ich kann mit dem aktuellen Zustand NICHT garantieren, dass mein Wechselrichter KEINEN Strom einspeist oder dass die Wärmepumpe nur dann Strom nutzt, wenn die PV-Anlage genug Strom liefert. Aber genau dass sollte mit einem Intelligenten Zähler möglich sein. Die Cloud zur Auswertung und Visualisierung ist super, keine Frage. Aber zur Echtzeitsteuerung taugt sie leider nicht, dafür gibt es einfach zu viele Fehlerquellen auf dem Weg. Sollte Discovergy weiterhin die lokalen Schnittstellen nicht Nutzung freigeben, werden aufgrund der Erfahrungen mit den Ausfällen, sicher immer mehr Kunden abspringen. Auch gewerbliche Anbieter werden wohl langsam nachdenklich, ob der vielen Ausfälle und Störungen.
Danke.

5 „Gefällt mir“

Hallo @ajedv,

Ihre FORDERUNG wurde gestern über den offiziellen, internen Weg an unsere IT weitergeleitet. Angesichts der begrenzten Kapazitäten muss ich Ihnen gegenüber ehrlich sein und Sie warnen, dass die Erfolgsaussichten leider begrenzt sind.

Es wäre auch zu begrüßen, dass Sie Ihre Petition nicht in allen Threads kopieren und dass Ihre Beiträge, da es sich um eine Forderung handelt, höflich mit mindestens einem „Hallo“ beginnen.

Viele Grüße
Pablo Santiago, Discovergy GmbH

1 „Gefällt mir“

Zumindest die Freigabe der RS485 sollte sehr einfach umsetzbar sein.

Sorry, ich hatte den Text kopiert und da fehlte etwas.

Ich unterstütze diese Forderung eines lokalen Lese-Zugriffs! Meine Heizungsanlage sowie auch meine Solaranlage kann ich zb auch lokal auslesen via MQTT oder auch JSON, zusätzlich hängt sie auch in der Cloud um über die APP des Herstellers darauf zuzugreifen! Wieso sollte das hier nicht möglich sein?

Ich sehe nur 2 Punkte woran das scheitern könnte:

  • Mangel an Resourcen durch das Insolvenzverfahren (Der API Entwickler hat ja DGY schon verlassen)
  • Generelle Ablehnung der Freischaltung durch das Management
2 „Gefällt mir“

Dito.

Wer bis dahin nicht warten kann, hat zwei Möglichkeiten:

  • die optische Schnittstelle anzapfen. Bastellösung und heutzutage für alles Andere als zeitgemäß
  • einen eigenen Zähler mit RS485 direkt hinter den von Discovergy setzen. Ressourcenverschwendung.

Ressourcenmangel? es gibt hier ausreichend viele Leute, die programmieren können und bereit sind, ein NDA zu unterschreiben, um derartige Probleme zu lösen. Unter Anderem mich. Ein bisschen Kreativität angesichts der für Alle schwierigen Lage sollte doch eigentlich kein Problem sein.

Abgesehen davon wäre das ein Alleinstellungsmerkmal. Oder gibt es ansonsten einen Zähler, den man über LAN lokal abfragen kann?

2 „Gefällt mir“

Ja, das wäre sogar um zu setzen, ohne irgend eine Schnittstelle frei zu geben. So wie das manche Zähler machen (z.B. SMA HomeManger): Einfach per Broadcast oder Multicast ins lokale Netz schicken, das öffnet dann auch keine unerkannte Sicherheitslücken.

1 „Gefällt mir“

welche seriöse Firma würde denn sowas von „Freiwilligen“ implementieren lassen, wenn selbst keine Resourcen da sind um die Lösung auch nur zu prüfen, testen und ggf. zertifizieren? Am Ende haftet schließlich nicht der Freiwillige, sondern der Meßstellenbetreiber. Und du kannst zwar ggf. den Zähler nicht beeinflussen bei der Zählung, sehr wohl aber die Übetragung an Discovergy, und so z.B. die zeitabhängigen Anbieter betrügen.
Das einzig nicht zeitgemäße an der Info-Schnittstelle ist in meinen Augen der fehlende Metallring. Ansonsten bietet sie alles was man braucht. Und nebenbei: das Gateway selbst ist ebenfalls nur über genau so eine Infrarotschnittstelle angebunden, nur halt über eine bidirektionale, was aber für das Werte auslesen keine Rolle spielt.
Zum Thema Broadcast: Zähler die einem das Netz mit unerwünschten Broadcasts fluten will jetzt auch nicht unbedingt jeder haben… und sobald die Zähler in einem anderen Netz liegen und Routing nötig wäre wärs eh sinnfrei. Und Sicherheitslücken: die beginnen praktisch ab dem Moment, wo die Schnittstelle auch nur eine IP bezieht. Die sind aber meiner Meinung nach nur ein vorgeschobenes Argument gewesen, denn auf der „non-Home-Schnittstelle“ hätte man das so oder so.

Schließe mich da an, der Wunsch besteht schon länger und ohne ist PV geführtes Laden ohne Internet nicht möglich.
An eine „Gegeneinspeisung“ eines Batteriewechselrichters schonmal gar nicht :frowning:

2 „Gefällt mir“

Die Zähler hängen doch bereits im lokalen Netz, zumindest bei mir. die HAN Schnittstelle ist genau für diesen lokalen Netzwerkzugriff vorgesehen, aber erst mit der Zertifizierung (die die Meteor Gateways aber noch nicht haben) verpflichtend. und die RS485 Schnittstelle ist definitiv kein Risiko, denn dort werden nur die Daten ausgegeben.

ich habe doch geschrieben, dass „Sicherheitslücken“ nur ein vorgeschobenes Argument von Discovergy war. Das Problem waren nie potentielle Sicherheitslücken, sondern immer nur der Entwicklungs- und Pflegeaufwand in meinen Augen. Und das ist es jetzt noch um so mehr.
Davon ab: was willst du denn bei der RS485-Schnittstelle noch? Beim Meteorit 3.5 gibts keine, da sowas zu fordern ist also Blödsinn. Beim Meteorit 2.0 ist sie vorhanden und ja wohl auch aktiv, wie man der alten Beschreibung bei Commetering entnehmen kann.

Und noch rein prinzipiell: auch RS485 ist bidirektional. Also auch dort können sich Sicherheitslücken verbergen, je nach Implementierung. Sogar auf dem (unvermeidbaren) Stromanschluß können sich SIcherheitslücken verbergen.

Also nochmal zusammengefasst: ihr wollt lokal? Dann nutzt das was vorhanden ist, wie die Info-Schnittstelle oder bei den alten Meteoriten RS485. Wollt ihr nicht? Dann wechselt den Meßstellenbetreiber. Von Discovergy da in der jetzigen Lage irgendwas zu erwarten, wo die Privatkunden lieber gekündigt werden sobald sie den geringsten Aufwand verursachen, ist einfach nur illusorisch. Kündigungsgründe um schnell aus dem DIscovergy-Vertrag raus zu kommen gibts ja oft genug. Aber nicht wundern wenn ihr dann keine Alternative findet die das leistet was ihr wollt.

Echt jetzt? Hast dazu mehr Info’s?

Google is your friend… https://www.commetering.de/pdf/RS-485-Schnittstelle.pdf
Was man auch gut sieht: zumindest Meteorit 2.0 ist unidirectional zum Zähler, empfängt also nur Daten die der Zähler von sich aus sendet. Also nix anderes als die Info-Schnittstelle, wenn sie vorhanden ist. Beim 3.5 kann das natürlich anders sein, laut Pedro kann 3.5 ja auch eine Tarifumschaltung, dafür wäre senden nötig.

Na dann wollen wir die RS485 mal testen. Evtl. ist sie ja funktionsfähig, auch wenn Discovergy das Gegenteil erklärt hat. Ein Versuch ist es dann ja mal wert.

Doch, auch beim 3.5 ist die Schnittstelle zumindest physikalisch vorhanden:

Aber laut Discovergy nicht funktionsfähig.

der Beschreibung nach dient sie beim 3.5 nicht als Kundenschnittstelle, sondern zur Anbindung eines Zählers. Klar, hardwaretechnisch kein Unterschied, aber eben softwaretechnisch was komplett anderes.

Das hatte ich die letzte Zeit sogar zusätzlich gemacht, um die Daten robust zu bekommen. Schade ist aber, dass dort keine Spannungen abgegriffen werden können und auch keine phasengetrennte Wirkleistung abgreifbar ist. Also deutlich weniger Informationen als über die REST-API. Diese Daten wären aber wichtig, z.B. für die Ansteuerung mehrer Wallboxen mit Lastmanagement und Schieflastüberprüfung.

Meine Lehre für mich: Am besten vom Elektriker einen weiteren privaten Zwischenzähler setzen lassen, dann kann man machen was man will. Kostet zwar Geld und Platz im Zählerschrank, aber dann muss man sich nicht mit dem überteuerten High-End-SMG rumschlagen. Für mich ist dies ein unbrauchbares Milliardengrab. Man hätte so viele schöne Sachen machen können, die nicht nur den EVUs und VNBs helfen, sondern auch den Endanwendern. Aber bislang hat man es nur so gebaut, dass es bei der Abrechnung hilft. Damit wird es für alle nur teurer, ohne einen Mehrwert für die Nutzer zu bieten.

Für den geleisteten Entwicklungsaufwand und die aufgerufenen Kosten und POGs ist das auf jeden Fall eine Enttäuschung bisher.

1 „Gefällt mir“

@Konni Den Zwischenzähler habe ich mir auch gegönnt, gezwungenermaßen.

Ich werde zwar bei Discovergy bleiben, weil ich einen Börsenstromtarif für eine super Sache halte und alle mir bekannten Anbieter von Privatkunden-Börsenstromtarifen auf Discovergy aufbauen, aber für die lokale Steuerung? leider nicht brauchbar.

@gnampf Ich will nicht sagen, dass es unmöglich ist, in einer Modbus-Schnittstelle Sicherheitslücken unterzubringen – der Dummheit sind bekanntlich keine Grenzen gesetzt – aber das Ding ist derart primitiv, dass es echt zu schaffen ist, derartige Fehler nicht zu begehen. Da wäre ich bei Code wie zB der ‚sicheren‘ Verbindung zum Discovergy-Server um Einiges skeptischer. Zertifikats-Prüfroutinen o.Ä. sind in der Vergangenheit mehrfach negativ aufgefallen.

hast du deinen Zähler mit der PIN freigeschaltet? Ich hab da durchaus die Spannungen und WIrkleistungen nach Phase getrennt an der Info-Schnittstelle.
Schieflastüberwachung? Welcher VNB läßt sich denn für sowas auf eine Bastellösung ein, die nicht von einem Hersteller zertifiziert wurde?

@MatthiasU:
wie ja schon mehrfach gesagt: Sicherheitslücken war einfach ein von Discovergy vorgeschobenes Argument um das ganze abzubügeln in meinen Augen, auch damals war der Grund wohl eher Resourcenmangel bzw. fehlender wirtschaftlicher Nutzen, wollte man nur nicht so offen kommunizieren. Und falsch ist es nicht, da sich wie gesagt überall Sicherheitslücken einbauen lassen.
Und Modbus mag simpel sein, trotzdem besteht die Chance dort durch Verletzung des Protokoll z.B. Speicherüberläufe zu erzeugen. Simpler wäre es wenn der Zähler rein von sich aus sendet und der Empfangskanal komplett tot ist. Im Prinzip also die umgeleitete Info-Schnittstelle.
Aber wie gesagt: das ist alles müßig. Discovergy wird keine neuen Schnittstellen implementieren auf absehbare Zeit, sondern wir können froh sein wenn die vorhandenen halbwegs was tun und der Betrieb fortgesetzt wird. Sollte jedem klar sein der die Sache ein wenig im Forum verfolgt.