Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[liv-in-sky]

@crycode

danke dir - bei mir sind daten gekommen :-)

[Latzi]

@crycode sagte in ODL-Adapter:

Könnt ihr das bestätigen?

ja, kann ich bestätigen - herzlichen Dank! :+1:

[StefanH 0]

Geht bei mir auch wieder, vielen Dank!

[Ralf 2]

@crycode
Es kamen auch bei mir wieder ein paar Werte, hat aber nicht lange angehalten und die Werte blieben wieder aus.
Jedoch gibt es keine Warnmeldungen mehr.

[crycode]

@ralf-2 Hast du mal geschaut, ob die Messstelle noch "in Betrieb" ist?
Es gibt auch immer mal wieder Störungen in der Datenkommunikation oder Wartungsarbeiten an einer Messstelle. Dann kommen auch für (meist) kurze Zeit keine Daten. Dafür ändert sich dann Status und das sollte auch im *.status State stehen.
Sonst schreib mir mal kurz um welche Messstelle (9-stellige Kennung) es geht und dann kann ich genauer nachsehen.

[StefanH 0]

Ich habe festgestellt, dass die vom Adapter gemeldeten Werte nicht über den SQL-Adapter geschrieben werden.
Der Grund hierfür ist offensichtlich, dass der Adapter die Werte mit ACK=false liefert.
Wenn ich die Daten aus dem Objekt-Knoten des Adapters auslesen und mit ACK=true wieder schreibe, werden diese auch von dem SQL-Adapter geschrieben.

var valkoblenz = getState('odl.0.071110001.value').val; 
setState("odl.0.071110001.value",valkoblenz,true); 

Hat jemand von Euch ebenfalls dieses Problem?

[Ro75]

@stefanh-0 setState mit 'true' nur bei Datenpunkten in '0_userdata.0.xxx' verwenden, nicht bei Adaptern. Wenn der SQL-Adapter da nichts speichert, stimmt was anderes nicht bei deinem System.

Ro75.

[StefanH 0]

@ro75 Interessanterweise werden nur die Objekte des Odl-Adapters nicht geschrieben, bei allen anderen Adaptern habe ich da keine Probleme. Habe die Odl-Instanz auch schon gelöscht und wieder neu eingerichtet. Nach der Neueinrichtung schreibt er genau 1 x weg und dann ist wieder Schluss.

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