ODL-Adapter

[Ralf 2]

@ro75

Danke für das Skript. Es ist die selbe Vorgehensweise wie im Adapter.
Was fehlt ist der Parameter "rejectUnauthorized: false" in der Webadresse

...kenn:051220003#&sortBy=end_measure+A&maxFeatures=168',%20method:%20'GET',%20"rejectUnauthorized":%20false,...

das müßte man nur im Adapter einpflegen. Scheinbar wurde das bis zum 13.09. nicht benötigt.

[Ro75]

@ralf-2 NEIN. Damit wird nur das Problem mit dem Zertifikat übersprungen. Der Parameter sorgt nur dafür, das der "Fehler" ignoriert wird.

Sauber ist diese Lösung nicht. Diesen Parameter habe ich vor 3 Tagen bei mir im Skript eingefügt und fliegt sofort wieder raus wenn die das Problem mit dem Zertifikat geklärt haben.

Ro75.

[crycode]

Hallo zusammen,
wie von @Ro75 bereits geschrieben liegt das Problem beim dem vom BfS verwendeten Zertifikat. Da scheint ein Teil der Zertifikatskette nicht mit ausgeliefert zu werden, wodurch das Zertifikat nicht geprüft werden kann.

Ich werde morgen eine Lösung des Problems in die Wege leiten.
Bis dahin bitte etwas Geduld.

[crycode]

Jetzt sollte es wohl wieder gehen.
Bei mir sind zumindest die Warnungen weg und die Daten kommen wieder.
Könnt ihr das bestätigen?

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

[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