Zähler sendet keine Daten


#228

Naja, funktioniert ja, wie man sieht, es kommen Daten an, falls DGY welche entgegennimmt…:wink:

Ernsthafter: Die hohen Frequenzen kommen da schon ganz gut durch. Die Schränke sind nicht wirklich HF-dicht. Problematischer ist es eher, wenn der Kasten im Keller hinter dicken Betondecken und -wänden ist.
Ich habe auch einen Fritz.Repeater im Zählerschrank, um LAN bereitzustellen. Klappt sehr gut.
Und zur “Haftbarkeit”… Nun der, der den Elektriker beauftragt hat. :wink:


#229

An Discovergy, kann es sein, wenn die Antwortzeit von Ihrem Server 80.86.163.150 (mcp.discovergy.com) über 50ms sind, das der Smartmeter die Verbindung pausiert?
Sobald wie jetzt die Pingzeit bei 10 bis 15ms liegt sendet er wieder einwandfrei?


#230

Es geht wieder nichts!


#231

Das ist ziemlich seltsam. Mein Zweirichtungszähler am HVT sendet ganz normal im Sekundentakt. Der Erzeugungszähler sendet, sendet nicht… Das geht doch über das selbe Gateway.

Hat das noch jemand? Würde ja bedeuten der Erzeugungszähler spinnt oder etwas auf der DCY Seite spinnt. Denn über die API kommen die Daten genauso wenig an. Der Zähler an sich ist aber, zumindest optisch. In Betrieb.

Laufen da mehrere Datenbanken? Für mich ist das nicht nachvollziehbar.

Gibt es Dokumente über die Architektur bei DCY? Also wie werden die Daten vor Ort (von mehreren Zählern) gesammelt, aufbereitet, verschickt, wo landen diese? Oder gehen alle Daten direkt über das GW zu DCY.

Mich würde das Prinzip mal interessieren. Denn diese ständigen Mails mit geht, geht nicht, geht, geht nicht und ständigen Informationen in der App sind echt nervig. Und ja, ich weiß. Ich könnte das ausschalten :slight_smile:


#232

Da ich nun schon wieder seit rund 24h Offline bin.

Verstößt Discovergy gegen die Technische Richtlinie BSI TR-03109

  • Turnusmäßige Auslieferung von tarifierten Messwerten
    Das SMGW MUSS gemäß eines Auswertungsprofils und eines Kommunikationsprofils
    regelmäßig abrechnungsrelevante Messwerte zur Tarifierung an einen externen Marktteilnehmer
    ausliefern können.

  • Das SMGW MUSS mindestens eine Auflösung von 5 Minuten als kleinste Messperiode
    unterstützen.
    Die größte Abweichung bisher gesamt 10h an einem Tag!!!

  • Im Falle einer größeren Abweichung MUSS ein Eintrag in das Eichlog erfolgen und das SMGW
    MUSS den SMGW-Admin informieren. Weitere eingehende Messwerte MÜSSEN danach
    entsprechend gekennzeichnet werden!

Beispiel: Soll ein SMGW Tarifmodelle verarbeiten können, die eine Auflösung von 5 Minuten vorsehen, beträgt die maximal zulässige Abweichung 9 Sekunden. Bei einer Abweichung über 9 Sekunden informiert das SMGW den SMGW-Admin und weitere eingehende Messwerte werden danach entsprechend gekennzeichnet.

Wurden die falschen Messwerte von Seiten Discovergy als Abweichend markiert? Dürfen diese für die stündliche Abrechnung verwendet werden?
Oder werden an den Marktteilnehmer andere Daten übermittelt als in das Kundenportal?

Ich erwarte ein klares Statement von Seiten Discovergy!


#233

Bei mir werden seit mittlerweile 38 Stunden keine Daten mehr übermittelt.
Nicht das es bisher (seit drei Wochen) zuverlässig funktioniert hätte, aber das so lange gar nichts mehr übermittelt wird… Ohne Worte…
Mir wäre kein Unternehmen aus der IT oder einer anderen Branche bekannt, die damit Geld verdienen, das einen Server/Datenbankausfall oder was auch immer dem Kunden gegenüber über einen so langen Zeitraum akzeptieren würde…
By the way, der Gateway wurde schon Resettet und zeigt auch keinen Fehler an…


#234

Evtl sehen wir die Daten nur nicht. Bedeutet ja nicht, dass diese nicht korrekt abgelegt und für DCY und andere verfügbar sind. Nur so eine Idee. Interessante Info @surfercool - Danke dafür!


#235

Mittlerweile wurde diese Daten zum Teil nachgeliefert. Auffällig ist das in den Zeitfenster jedoch bei den nachgelieferten Werten zeitliche Abstände von 30 bis 60 Minuten vorliegen. Das reicht für eine Abrechnung bei aWATTar sicherlich für eine stündliche Abgrenzung aus. Die Frage bleibt, warum der Rest der Meßwerte für immer im Datennivarna ist. Mindestens 15 Minuten Werte würde ich rechtlich erwarten.


#236

Guten Morgen zusammen,

Kurzes Update von unserer Seite: Unsere IT konnte die Ursache des Problems identifizieren und arbeitet daran, den Fehler zu beheben und die Verfügbarkeit des Portals wiederherzustellen.

@martingr, ich versuche im Laufe des Tages herauszufinden, wieso die Messwerte mancher Zeitintervalle nicht nachgeliefert werden.

Viele Grüße,
Pablo Santiago, Discovergy GmbH


#237

Kann es sein, wenn man voreilig Reset drückt?


#238

Hallo Herr Santiago,

Ich habe meine Anfrage an den Support vom 23.3 betreff dem Grunde der nicht Nachlieferung der Daten auch noch nicht beantwortet bekommen


#239

Das habe ich auch schon überlegt und auch mal gefragt, aber keine Antwort bekommen…
Was genau bedeutet denn “Reset”? Zumal nicht alle Meteroit 3.5 überhaupt eine Reset-Taste haben. Die DIN-Hutschiene-Typen kann man nur durch Unterbrechung der Versorgungsspannung resetten.
Allerdings darf eine solche Unterbrechung doch keinesfalls zu Datenverlusten führen.

Ein Szenario “Ausfall der Internet-Verbindung mit nachfolgender Stromunterbrechung” ist ja nicht unrealistisch und muss vom System / Gateway durch Zwischenspeichern und Nachliefern nach Wiederherstellung abgefangen werden.


#240

Bei mir gab es am 05.04. mal wieder zwischen 7:25 - 08.35 Uhr interpolierte Werte

Zur Info: Ich habe noch kein iMSys, sondern noch den alten Zähler mit der grauen Kommunikationseinheit. An dem Tag war auch keiner zu hause, der den Rest-Knopf gedrückt hat.

@Discovergy warum sind eure Zähler/Kommunikationsmodule nicht in der Lage Daten zwischen zu puffern und diese nachzuliefern? Können die Geräte das nicht oder werden die Daten nur nicht korrekt nachgeliefert und im Backend verarbeitet?


#241

Hallo zusammen,

guten Nachmittag. Die Störung ist weitgehend behoben und die Messwerten sollten schrittweise in den nächsten Tagen nachgeliefert werden - hoffentlich ohne große Datenverlusten. Der Ausfall ist auf eine Überlastung des Servers zurückzuführen, die wiederum von einer fehlerhaften Dimensionierung mancher Komponenten ausgelöst wurde.

Und nun zu den konkreten Fragen: Wieso treten Datenverlusten in manchen Zeitintervallen auf? Wenn alles richtig läuft, übertragen die Gateways ihre Messwerte und diese werden auf dem Server in der sogenannten Validation Queue aufgenommen, bevor sie über den Server-Buffer an die entsprechende Datenbank übermittelt werden. Sind einmal die Daten in die Validation Queue angekommen, löscht das Gateway automatisch die bereits übertragenen Messwerten. Problem ist: Bei einem Absturz des Servers können leider in der Regel nicht alle Messwerte aus der Validation Queue wiederhergestellt werden und stehen dadurch Lücken in den Lastprofilen, die durch Ersatzwertbildung interpoliert werden müssen.

Bei dem Meteroit kommt ein Problem dazu: EIn Bug in der Software verhindert aktuell die Speicherung der Messwerte auf dem Gateway, deshalb arbeitet derzeit unsere IT an einem Update der Geräte. Kann das Update erfolgreich durchgeführt werden, sollten die Gateways 2.0 in der Lage sein, die Messwerte von bis zu 80 Tage zu speichern.

Und was das Thema Ersatzwertbildung angeht: Bei Rücksprache mit einigen Kollegen könnte ich heute erfahren, dass eine Ersatzwertbildung nach BSI-Kriterien - ink. entsprechender Kennzeichnung - lediglich den Marktpartner (Netzbetreiber und Energieversorger) zur Verfügung gestellt wird, allerdings wird diese leider weder im Portal noch in der API angewendet bzw. dargestellt. Somit entstehen in dem Portal die bereits bekannten linearen Interpolationen und in der API die dazugehörigen Zeitintervallen ohne Messwerte, auf die @martingr mehrmals hingewiesen hat.

Bei Datenverlusten, der ein Intervall von weniger als zwei Stunden betreffen, können die Daten -auch gegenüber den Marktpartnern - einfach linear interpoliert werden. Ob diese Vorgehensweise auch bei stündlichen Tarifen anwendbar ist, muss ich selber nachforschen.

Ich hoffe, diese Infos könnten einige Fragen klären und ich bedanke mich nochmals für Eure Geduld und Verständnis.

Viele Grüße und einen schönen Nachmittag,
Pablo Santiago, Discovergy GmbH


Störung seit 06.04.2021
#242

Vielen Dank @PabloSantiagoDGY für diese Erläuterungen! :+1:

Die Rechnungen von aWATTar jedenfalls geben für die Unterbrechungszeiten ziemlich genau das wieder, was hier im Portal abgebildet ist. (Flatline)

Zu den Ursachen der Datenverluste:
Das heißt, zumindest bei den 3.5er Gateways, es liegt nicht an den Gateways, sondern an einem fehleranfälligen System auf der Serverseite (Validation Queue).
Auf die Idee, zumindest bis zur Abstellung dieses Fehlers, das Löschen der Gateway-Daten erst zu initiieren, wenn die Daten komplett und sicher in der Datenbank abgelegt wurden, ist sicher schon jemand gekommen bzw geht so einfach nicht, oder…!?

Könnte bitte die Frage nach der Konsequenz des “Reset” noch beantwortet werden? Hat ein Reset Einfluss auf die Daten / deren Wiederherstellung?
Wenn durch ein Reset, die Wiederherstellung gefährdet wird, z.B. weil der Abgleich mit der Validation Queue dann fehlerhaft wird, sollten User damit lieber sparsam umgehen, weil es mehr schaden als nützen könnte…?


#243

Meines Wissens nach wird bei einem Reset nur die Datenverbindung zum Zähler und ins I-Net neu gestartet, d.h. IP Adresse besorgen und nach Hause telefonieren…
Auf die Daten sollte das keinen Einfluß haben.


#244

Danke Herr Santiago für die extensive Antwort ihrer IT schlussendlich.

Dazu 2 Bemerkungen meinerseits:

  • Löschen der Daten auf dem Gateway sobald sie in der Validation-Queue sind ist ein ‘Error by design’! Oder um es mit Murphy zu sagen ‘What might go wrong, will go wrong’. Die Daten im Gateway dürfen erst gelöscht werden nachdem eine Bestätigung über die komplette Verarbeitung an das Gateway gesendet worden ist, besser noch wäre die Daten im Speicher des Gateway zu belassen und sie einfach nach dem ‘LiLo’-Prinzip zu überschreiben, so wären die Daten Verfügbar bis zum Überschreiben wegen Speicherüberlaufs. Wenn ich sie richtig verstanden habe betrifft dies auch nur die Meteroiten 3.5…
  • Dass die Meteroiten 2.0 überhaupt keine Daten speichern wegen eines Softwarefehler ist schon ein starkes Stück! Siehe Murphy!
    Wie lange werden die 2.0 schon verbaut? Wenn dieser Bug seit Einführung der 2.0 ihrer IT noch niemandem aufgefallen ist kann man sich schon Fragen über die Kompetenzen in der IT stellen. Falls der Bug schon länger besteht und noch nicht ausgemerzt wurde kann man sich die gleiche Frage stellen! Bei einem so grossen, dezentralem ‘Deployment’ dürfte so ein gravierender Fehler nicht vorkommen und falls, dann direkt korrigiert werden…

Trotzdem danke für die Erläuterungen und ich hoffe dass die Probleme der letzten Zeit ein Wachruf für ihre Geschäftsleitung waren…

MfG


#245

Laut DGY habe ich einen 2.0
Meine Daten wurden aber immer nachgeliefert


#246

Hängt wohl davon ab was ausgefallen ist, die Verbindung zu deinem Gateway oder die Verarbeitung von den Servern…
Bei ersterem hast du Pech gehabt…

So hab ich es verstanden


#247

Ein Bild sagt mehr als tausend Worte.
Soviel zum Thema die Störung ist weitestgehend behoben…
Aktueller Screenshot am 07.04. 21:15