Keine nachgelieferten Daten über die API bei Ausfall am 23.3.2022

Guten Morgen,
Bei dem Ausfall sind die Daten über die API nicht nachgeliefert worden, beim Start ist nur der letzte Zählerstand geliefert worden, wobei im Portal wie auch bei zaehlerfreunde.de die Daten nachgeliefert worden sind. Wie ist das zu verstehen?

Mittlerweile sollten alle Daten wieder verfügbar sein - also nicht nur die letzten Zählerstand, die ohnehin nach dem Ausfall der IKT als erstes übertragen werden. Die Zwischenstände (/readings) folgen mit etwas Zeitversatz.

Von daher die direkte Frage, ob die Daten der Zählerfreunde nun wieder lückenlos sind?

Hallo, Es geht ja nicht um die Daten der Zählerfreunde sondern um den Discovergy Adapter von Iobroker der alle 10 Sekunden einen ‚Poll‘ der API macht, dabei hat er nur den Timestamp und den Wert des jüngsten Zählerstandes bekommen, die vorherigen Zählerstände nicht. Dies hat aber bei einem früheren Ausfall korrekt funktionniert. Ist natürlich bei einem zeitbasierten Tarif von Awattar schlecht.

Also über Endpunkt /last_reading der API wird immer der jüngste Zählerstand geliefert. Von daher kann ich mir gerade nicht erklären, wie man einen Algorithmus aufbauen würde, der eine Lücke füllt, denn last_reading soll nun mal der jeweils Jüngste sein.

Wenn der Anwendungsfall es benötigt, so sollte dieser die fehlenden Werte auch berücksichtigen und entsprechend nachfordern (über den /readings Endpunkt).Vermutlich ist der genutzte Adapter für einen anderen Anwendungsfall entwickelt worden, welcher hier für Awattar zweckentfremdet genutzt wird.

Was mir aufgefallen war, das Discovergy Portal war schon fertig aktualisiert mit den fehlenden Werten, der Adapter der über die API fährt hat aber zu der Zeit immer noch ein Timeout 504 gemeldet.

Erst um 19:18 lief der Adapter wieder, mit dieser Fehlermeldung:

2022-03-23 19:18:03.663 - info: host.ubuntu instance system.adapter.discovergy.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
2022-03-23 19:18:06.179 - info: host.ubuntu instance system.adapter.discovergy.0 started with pid 2292696
2022-03-23 19:18:09.245 - info: discovergy.0 (2292696) starting. Version 0.5.9-0 (non-npm: DrozmotiX/ioBroker.discovergy#d8f81e91db78c2e01425526caa370a47df7c5745) in /opt/iobroker/node_modules/iobroker.discovergy, node: v14.19.0, js-controller: 4.0.15
2022-03-23 19:18:09.326 - info: discovergy.0 (2292696) Discovergy Adapter startet, trying to discover meters associated with your account
2022-03-23 19:18:09.814 - error: discovergy.0 (2292696) State type : printedFullSerialNumber unknown, send this information to the developer ==> printedFullSerialNumber : „1ESY1160669411“
2022-03-23 19:18:10.489 - info: discovergy.0 (2292696) All meters associated to your account discovered, initialise meters
2022-03-23 19:18:10.540 - warn: discovergy.0 (2292696) State attribute definition missing for + Timestamp of last value update
2022-03-23 19:18:10.541 - info: discovergy.0 (2292696) [Error caught and sent to Sentry, thank you for collaborating!] error: State attribute definition missing for + Timestamp of last value update
2022-03-23 19:18:10.589 - info: discovergy.0 (2292696) All meters initialized, polling data every 10 seconds

Mir scheint es doch so dass die API nur den letzten Wert geliefert hat, ist doch schon so mehrmals passiert, dass Werte nicht nachgeliefert wurden.

Negativ - s.h. Implementierung: ioBroker.discovergy/main.js at main · DrozmotiX/ioBroker.discovergy · GitHub

Wer nur nach last_reading fragt - bekommt auch nur last_reading … nachgeliefert wird hier nichts.

Habe einen Enhancement Request gestellt beim Entwickler des Adapters.

Danke, bin mir aber sicher dass bei vorherigen Ausfällen die Werte nacheinander kamen, kann das sein ? Deswegen wurde ja auf mein Vorschlag vor einiger Zeit schon dieser timestamp des Zählerwertes mitgeliefert. Wir werden sehen was der Entwickler mit dem Request macht…

Das ist möglich und deckt sich mit dem wohl am häufigsten auftretenden Problem einer Kommunktationsunterbrechung, denn da ist es zum Beispiel die DSL Verbindung, die für einige Stunden „mal da“, „mal weg“, „mal da“, „mal weg“ ist. In diesem Fall sind die last_readings, wenn sie zwischen den Unterbrechungen stattinden „in Sequenz“.

Hat der Entwickler sich irgendwie gemeldet?

leider bislang noch nicht. Aber der Backlog bei ioBroker scheint auch recht lange zu sein.

Bei ioBroker gibt es doch eine Schnittstelle zu NodeRED. Dort habe ich das Modul zur Anbindung entwickelt und betreue es auch. Könnte der Umweg über NodeRED eine Möglichkeit sein?

Ich hab mich bis jetzt noch nicht mit node-Red beschäftigt. Ich habe mal die Instanz node-Red installiert, wie bekomme ich jetzt das Discovergy modul hineingeladen?

Ich schieb das nochmal hoch, ist vielleicht übersehen worden: Wo finde ich dein Discovergy modul in Node-Red? Ich hab da nämlich mehrere gefunden…

Hallo @kleinjn ,

laut den Kollegen soll in Node-red nach Discovergy gesucht werden (unter Palette).

Viele Grüße
Pablo Santiago, Discovergy GmbH

Hat sich erledigt, hatte den Palette-manager nicht aktiviert…

Welcher Node ist es denn?

Ich würde sagen, der zweite. Der dritte und vierte gehören zum Energieversorger Corrently, mit dem wir vor Kurzem ein interessantes Webinar durchgeführt haben.