Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Ro75]

@stefanh-0 wie sehen denn die Einstellungen dazu aus?

[StefanH 0]

@ro75 welche Einstellungen meinst du, die vom Odl-Adapter oder die SQL-Einstellungen der Datenpunkte ?

[Ro75]

@stefanh-0 um die Daten zu speichern, also SQL.

[StefanH 0]

@ro75 Hier die Einstellungen:

[Ro75]

@stefanh-0 sehe jetzt nicht unbedingt ein Problem. Wann war denn die letzte Änderung vom Datenpunkt mit welchem Wert?

[StefanH 0]

@ro75 Wie gesagt, wenn ich selbst den Datenpunkt nochmals, aber mit ACK=True schreibe, funktioniert es.
Wenn ich das nicht mache, werden die Daten nicht automatisch geschrieben.

[Ro75]

@ro75 sagte in ODL-Adapter:

Wann war denn die letzte Änderung vom Datenpunkt mit welchem Wert?

@StefanH-0 was ist denn damit?

[StefanH 0]

@ro75 Der Adapter ist im Moment so eingestellt, das er 1 x stündlich die Werte abruft. Die Werte der einzelne Stationen bewegen sich zwischen 0.09 - 0.107

[Ro75]

@stefanh-0 die Frage war eigentlich: "Wann war denn die letzte Änderung vom Datenpunkt".

[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.