Wrong values if cloud access not working

[Finke3]

If connection to Smartset portal is not working (also with Smartset App) the adapter is providing wrong values (e.g.if wifi connection to ISM7 is broken). Not sure, but it seems to be some old values from the history?! Instead e.g. last valid values should be used.

Errors from the log, if Smartset portal is not reachable:

[Apollon77]

What you mean with "wrong values"?

[Finke3]

Hi @Apollon77,

What you mean with "wrong values"?

If the cloud portal is not accessible, the data objects of the adapter are filled with some old values. I guess only objects are affected, which will be written into history. I‘m not 100% sure, but I guess that in above error case, the first stored history entry will be used as object value in the Adapter. Is that possible? My expected behaviour would be, that the objects will keep the last entry from the history and not the first or another old one.

I‘m not sure why, but I have every day some minutes, where I‘m facing these kind of connection problems. During these minutes also the original app is not working. During these connection problems e.g the value of my water temperature in the adapter is always jumping to the value of 62,5 degrees, which is an old logged value from the history. Due to that my diagrams are showing crazy peaks.

Hopefully my explanation was good enough and you are able to reproduce and fix the issue.

[Apollon77]

I would not expect the adapter to write historical data into the datapoints, but we would need to check that. So it would be great if you can check if it is history which is just configured to "re log values every x time" or if really old values are in the states. ALso mabe having a debug log of the adapter could make sense

[Finke3]

Hi, thanks for the response. The values seems definetely come from the states of the Adapter. See attached Screenshot from History with the source. Here you also can see that the temperature value is jumping from 28,2 degrees to 58 degrees (old value) during the cloud portal / wifi outage. After cloud portal /wifi was available again the values were also looking fine again. I also navigated manually to the states of the adapter, which were also showing these wrong values during the outage.

I would be really thankful if you could try to reproduce and fix this irritating behavior.

[Apollon77]

Pleas eprovide a debug log ... honestly ... I do not have such a device so I will not be able to reproduce it ... so hopefully a debug log provide some insights

[Finke3]

Hi @Apollon77 ,

I enabled debug log, but there are some confidential information in it, so that I only paste the important information from my point of view. During outage a log entry "create states" will be logged. Maybe you can check in that direction what this mean in detail? This log entry will only be written in case of such outages.

Hopefully it helps.

[MeisterTR]

Hi Finke, hier ist es ein bisschen leichter als per email... Das schreiben der Werte geschieht nur wenn neue Daten aus der Cloud kommen, der Adapter kann selbst dann nicht verifizieren ob diese Daten korrekt sind oder nicht.

Du kannst gerne den info.connection state mitloggen und die beiden gegenüberstellen (wird aber nur jeden vierten Abruf abgefragt) und schauen ob die Fehlwerte zeitlich exakt zur offline Zeit passen, dann würde ich unterbinden, dass die Werte geschrieben werden, wenn das Gerät offline ist, dafür muss es aber zeitlich passen, wenn da ne Latenz von ein paar Minuten drin ist, bringt das auch nix...

[Finke3]

Hi @MeisterTR, ich habe nun mal den info.connection state mitgeloggt und mit den Zeitstempeln der geloggten States während zwei Ausfällen verglichen. Bei den beiden Ausfällen war es wirklich so, dass die Fehlwerte innerhalb der Zeitspanne geschrieben wurden, wo der info.connection state bereits "false" war. Demnach könnte eine Prüfung auf diesen state durchaus eine Lösung darstellen. Entsprechende Screenshots eines Ausfalls und dem Status der States siehst du unten.

History von info.connection state:

History des fehlerhaften Wertes:

Vielleicht kannst du das Problem ja bei dir reproduzieren, in dem du einfach die W-LAN Verbindung zum Modul unterbrichst?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions. Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.

[Finke3]

Hi @MeisterTR, @Apollon77 ist damit zu rechnen, dass die gemeldeten Fehler in naher Zukunft behoben werden? Viele der gemeldeten Issues werden nach einer Zeit automatisch geschlossen ohne behoben zu werden. ☹️

[Apollon77]

Ich sehe hier immer noch kein Debug log mit dem man suchen könnte.

Zur Klarheit: Admin - Expertenmodus aktiviere - Instanzen - instanz aufklappen, Loglevel auf debug ändern.Dann Logile von der Platte aus /opt/iobroker/logs nehmen

[Finke3]

Hi @Apollon77,

wie bereits im Verlauf geschrieben, enthält das Debug Log einige vertrauensvolle Daten. Daher habe ich damals den relevanten Teil hier eingefügt. Aus dem Debug Log ist lediglich der Eintrag „create states“ geloggt. Mehr geht aus dem Log leider nicht hervor. Wie hier bereits von @MeisterTR erwähnt, müsste das Schreiben der Werte unterbunden werden, sobald der Wert „info.connection = false“ ist. Als Workaround nutze ich gerade ein simples Script, welches die wichtigsten Werte in einen eigenen Datenpunkt dupliziert. Sollte der Wert „info.connection=false“ sein, so werden die falschen Daten nicht in den eigenen Datenpunkt geschrieben. Das funktioniert bei mir zuverlässig, sollte aber langfristig im Adapter gefixt werden.

[Apollon77]

Naja die Frage ist ja das folgende ... Wie willst Du ohne Log mitbekommen das was nicht tut ... Wenn würde ich ggf das logging bei "wenn nicht connected" auf warn/info runterschrauben und nicht connected ... aber am Ende ist das immer so eine Sache.

Es ist ein Fehler ... Also um was geht es dir? Wenn es nur um ein "Das log soll leer sein" geht... ja ok ... viele andere aber wollen wissen wenn was nicht geht.

[Finke3]

Hallo @Apollon77 , ich glaube du verwechselt was. Es geht hier nicht ums Log. Es geht darum, dass die Werte in den Datenpunkten falsch sind bzw. historische Daten enthalten, sobald keine Cloud Verbindung besteht. So wird z.B. beim Ausfall am Nachmittag einfach ein Wert von morgens in den Datenpunkt geschrieben. Das kann man lösen, in dem der Adapter nur die Datenpunkte bzw. states mit Daten befüllt, wenn der state „info.connection=true“ ist. Wenn der state „info.connection=false“ ist, dürfen alle anderen Datenpunkte des Adapters z.B. Kollektortemperatur, Vorlauftemperatur etc. nicht weiter (mit alten Werten) befüllt werden. Schau mal in den Lösungsvorschlag von @MeisterTR .

[MeisterTR]

Ich habe das Problem noch nicht weiter verfolgen können oder verifizieren können. bin mir noch nicht sicher ob es sinnvoll ist die werte nciht zu schreiben wenn die Heizung keine Verbindung zur Cloud hat, das muss ich noch einmal ausgiebige testen. Der erste Post ist irreführen. weil es dort um die Verbindung von Adapter zum Portal geht. wenn die nicht steht, werden auch keine werte geschrieben. Das Problem bezieht sich ja auf die Verbindung von Heizung zur Cloud, dann werden von der Cloud "falsche" Werte gesendet.

[Finke3]

Ja genau. @MeisterTR: Basierend auf deinem Hinweis mit der Prüfung auf „info.connection=true“ komme ich derzeit gut klar. Ich habe mir einen Workaround geschaffen, und kopiere die Werte in eigene Datenpunkte. Mit einem einfachen if/else prüfe ich vorher den „info.connection“ state. Dieser Workaround löst nahezu 100% mein Problem. Es wäre halt langfristig nur schön, wenn dieses Problem im Adapter gefixt bzw. das Fehlverhalten der Cloud abgefangen wird, so dass man die Datenpunkte des Adapters zuverlässig nutzen kann.

[Apollon77]

please check 1.1.1