Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[crycode]

@stefanh-0 Der Adapter schreibt die States mit ack=true (sollte er zumindest).
Eine Besonderheit hier ist, dass der Zeitstempel der Werte auf den echten Zeitstempel des Messwertes, also immer die volle Stunde, gesetzt werden und nicht auf den Zeitpunkt, an dem der State geschrieben wird. Sprich ein um z.B. 16:44 Uhr geschriebener Wert müsste den Zeitstempel von 16:00 Uhr haben.

Ich kann das nächste Woche gerne noch mal bei mir mit dem SQL Adapter zusammen testen.

[mcm1957]

@crycode
Ich habe den Adapter grad mal testweise installiert.
Bei mir werden die Werte mit ACK=TRUE (Bestätigt TRUE) angezeigt.

Ich rege an, dass diejenigen die ein Problem haben, das mal bei sich checken und ggF posten.

Allerdings gibt es im Code eine auf den ersten Blick suspekte Stelle:

https://github.com/crycode-de/ioBroker.odl/blob/43df6b0ca0dea5b2ad6ff9a860e6c4afe403b021/src/main.ts#L368

const currentState = await this.getStateAsync(`${mstKenn}.value`);
      if (!currentState || currentState.val !== (newState as ioBroker.State).val || currentState.ts !== (newState as ioBroker.State).ts) {
        await this.setStateAsync(`${mstKenn}.value`, newState);

        if (objValueCosmic) {
          (newState as ioBroker.State).val = featureLatest.properties.value_cosmic;
          await this.setStateAsync(`${mstKenn}.valueCosmic`, newState);
        }
        if (objValueTerrestrial) {
          (newState as ioBroker.State).val = featureLatest.properties.value_terrestrial;
          await this.setStateAsync(`${mstKenn}.valueTerrestrial`, newState);
        }
      }

Hier wird setState ohne excplizite Angabe von ack= true und damit mit ack=false aufgerufen.
Das kann ein Problem sein, kann aber ebenso völlig in Ordnung sein. Ich erspar mir eine genauere Analyse da @crycode das wahrscheinlich in 1 Minute entscheiden kann (wenn er überhaupt so lange braucht) DANKE crycode für den Adapetr und die Betreuung hier im Forum.

[crycode]

@mcm57 Danke für dein Feedback! :)
Bei deiner genannten Codestelle wird ack=true schon ein paar Zeilen vorher mit definiert:
https://github.com/crycode-de/ioBroker.odl/blob/43df6b0ca0dea5b2ad6ff9a860e6c4afe403b021/src/main.ts#L362C19-L362C19

      const newState: ioBroker.SettableState = {
        val: featureLatest.properties.value,
        ack: true,
        ts: featureLatest.properties.end_measure ? new Date(featureLatest.properties.end_measure).getTime() : Date.now(),
        lc: Date.now(),
        q: featureLatest.properties.value !== null ? 0x00 : 0x81, // 0x00 = good, 0x81 = general problem by sensor
      };

Meines Wissens nach sollte das so passen und gab bislang auch keine Fehler. :thinking_face:

Meine Vermutung wäre eher, wie oben schon geschrieben, dass die States mit einem anderen Zeitstempel (dem des tatsächlichen Messwertes) geschrieben werden und der SQL-Adapter das deshalb vlt. aussortiert. Das checke ich aber nächste Woche genauer.

[mcm1957]

@crycode
DANKE für die Rückmeldung und sorry für die Vermutung. Ich hab definitiv übersehen, dass du ein Objet und nicht einen Wert übergibst.

Wie gesagt ich kann die Aussage dass Werte mit ack=false existieren nicht nachvollziehen.

[StefanH 0]

Das könnte sein, wenn ich mir die Zeitstempel der odl.Objekte (val) anschaue, so liegen diese eigenartigerweise um ca. 10 Minuten vor der Zeit des Raspberry-Pi.

Weiter ist mir über das IOBroker-Info-Menü folgendes aufgefallen:

Die Zeit-Einstellung meines Raspberry-Pi habe ich kontrolliert, diese ist korrekt.
Das sollte dann eigentlich auch die Zeit von IOBroker sein, oder?

[Thomas Braun]

@stefanh-0 sagte in ODL-Adapter:

Das sollte dann eigentlich auch die Zeit von IOBroker sein, oder?

Die Anzeige hat mich auch schon irritiert. Einmal Browser refresh und es passt wieder.

[StefanH 0]

@thomas-braun ja stimmt, hat funktioniert, also ein Bug !

[crycode]

@stefanh-0 Dass die Zeitstempel der val-Objekte in der Zukunft liegen kann eigentlich nicht sein. Die Zeitstempel kommen aus der Datenschnittstelle des BfS. Bis da ein Messwert drin ist, muss die jeweilige Messstelle erst mal die Daten verschickt haben und die Daten müssen dann durch einen internen Prozess (Berechnung der ODL aus den Impulsen der Zählrohre, Berechnung der 1h-Mittelwerte etc.) laufen. Damit ist immer ein Versatz von mind. 10 Minuten drin.

Hast du in der Adapterkonfig die Option "Verlauf nachladen" aktiviert?
Diese sollte ggf. fehlende Datenlücken in der Historie für die letzten 7 Tage auffüllen (und damit auch ggf. nicht direkt gespeicherte aktuelle Werte).
Das ist für die Verlaufs-Adapter history, influx und sql verfügbar.
Wenn es damit klappt, ist es zwar noch nicht die Lösung des eigentlichen Problems, aber wäre zumindest ein Workaround. :)

[StefanH 0]

Kaum zu glauben, nachdem ich die Option

aktiviert habe, bekomme ich nun fortlaufend Daten.
Habe die Option gestern Abend aktiviert und habe alle Veränderungen bis heute Morgen.

Verstehe den Zusammenhang noch nicht ganz!!!!

[crycode]

@stefanh-0 Mit der Option aktiviert, prüft der Adapter zusätzlich deinen gespeicherten Verlauf (in deinem Fall mit dem SQL Adapter) und versucht Datenlücken über eine zusätzliche Anfrage an die Datenschnittstelle des BfS zu füllen.
Wenn die Datenschnittstelle dann Werte liefert, die bei dir noch nicht vorhanden sind, dann gibt der ODL Adapter dem SQL Adapter (alternativ History oder Influxdb) entsprechende Befehle, um die fehlenden Werte bei dir nachzutragen.

Gedacht ist diese Funktion eigentlich dafür, wenn du einen möglichst vollständigen Verlauf haben möchtest, aber die Datenschnitte mal (aus welchem Grund auch immer) für einen Zeitraum von bis 7 Tagen keine Daten geliefert hat, danach aber die Daten aus dem Zeitraum wieder verfügbar sind.

Wie gesagt, das löst das eigentliche Problem nicht, aber füllt durch das Nachladen der fehlenden Werte trotzdem deinen Verlauf.

[crycode]

Kurze Zwischeninfo:
Auch mit InfluxDB und deaktivierter Option "Verlauf nachladen" werden die Werte nicht aufgezeichnet.
Vermutlich filtern die Verlaufsadapter hier nach dem Zeitstempel, damit nicht versehentlich ältere Werte aufgezeichnet werden. Das schaue ich mir noch genauer an.

[crycode]

Ab sofort steht Version 3.0.1 vom ODL-Adapter über NPM und spätestens morgen auch im latest-Repository bereit.
In dieser Version sollte das Problem mit dem Speichern der Verlaufsdaten behoben sein. Zudem wurden alle Abhängigkeiten aktualisiert.
Achtung: Der Adapter benötigt nun mindestens Node.js 16.

@StefanH-0 Kannst du das bitte mal testen und dabei die Option "Verlauf nachladen" wieder (zumindest testweise) deaktivieren?

[StefanH 0]

@crycode Habe gestern Abend noch die Latest Version 3.0.1 installiert und die Optione "Verlauf nachladen" wieder ausgeschaltet. Sieht heute Morgen gut aus, habe über Nacht kontinuierlich und lückenlos Werte erhalten.

Vielen Dank, gute Arbeit!

[crycode]

@stefanh-0 Super! :)
Wenn du im ioBroker einen möglichst vollständigen Verlauf haben möchtest, dann würde ich dir trotzdem empfehlen die Option wieder zu aktivieren.

Über die Datenschnittstelle vom BfS kommen manchmal einzelne Stundenwerte nicht direkt, sondern erst später.
zufälliges Beispiel: Dein Adapter holt die Werte immer um *:40 ab. Um 12:40 erhältst du den 12:00 Uhr Wert, um 13:40 immer noch den 12:00 Wert und um 14:40 dann den 14:00 Wert. Damit würde der 13:00 Wert bei dir im Verlauf fehlen. Mit der Option "Verlauf nachladen" würde der Adapter diese Lücke in deinem Verlauf bemerken und den 13:00 Wert über die Schnittstelle nachladen und bei dir eintragen. :)