Ausgangslage:
Wir haben den Querx THP in unser Testsystem eingebunden um dne Einfluss des Umgebungsdrucks auf eine Luftstrommessung kompensieren zu können (dazu haben wir den Wert für "Altitude" auf 0 belassen und bekommen so den Luftdruck auf Stationshöhe).

Während des Testbetriebes erhielt ich einmal die Ausgabe "Sensor Error" auf dem Web-Frontend des Querx (ähnlich wie im Blog-Eintrag zu Glitches beschrieben) welche sich nur durch einen Powrcycle des Querx beheben liess.

Frage:
Kann ich aus den Werten, die ich per Modbus/TCP auslesen kann feststellen, wenn ein Sensorfehler aufgetreten ist?

Es wäre noch interessant, mehr über den Fehler selbst herauszufinden. Mit welcher Firmware-Version und welcher Hardware-Version ist der Fehler aufgetreten? Die Hardware-Version steht auf dem Etikett, z.B. "Querx THP 1.2".

Es ist Hardware Revision 1.2 und Firmware 4.4.23.1 (PS: Das Etikett ist leider nach dem Festschrauben des Gerätes nicht mehr sichtbar).

Im Syslog zeigte sich der Fehler so:

Sep  9 08:25:00 172.16.111.19 AEQsnsmtgthp Push palamoa.de/json/ABCDEFGH: HTTP/1.1 200 OK
Sep  9 08:25:00 172.16.111.19 AEQsnsmtgthp Sensor[1]:25.3;25.3;25.3
Sep  9 08:25:00 172.16.111.19 AEQsnsmtgthp Sensor[2]:49;49;49
Sep  9 08:25:00 172.16.111.19 AEQsnsmtgthp Sensor[3]:977.6;977.6;977.7
Sep  9 08:29:30 172.16.111.19 AEQsnsmtgthp Failed to read temperature
Sep  9 08:29:30 172.16.111.19 AEQsnsmtgthp Failed to read humidity
Sep  9 08:29:39 172.16.111.19 AEQsnsmtgthp Temperatur sensor error
Sep  9 08:29:39 172.16.111.19 AEQsnsmtgthp Configuration(3604.151) saved
Sep  9 08:29:39 172.16.111.19 AEQsnsmtgthp rel. Luftfeuchte sensor error
Sep  9 08:29:39 172.16.111.19 AEQsnsmtgthp Configuration(3604.152) saved
Sep  9 08:30:00 172.16.111.19 AEQsnsmtgthp Push palamoa.de/json/ABCDEFGH: HTTP/1.1 200 OK
Sep  9 08:31:14 172.16.111.19 AEQsnsmtgthp History request from 08.09.2020 09:00:00 to 09.09.2020 09:00:00 in 600s steps
Sep  9 08:31:23 172.16.111.19 AEQsnsmtgthp History request from 08.09.2020 09:00:00 to 09.09.2020 09:00:00 in 600s steps
Sep  9 08:32:23 172.16.111.19 AEQsnsmtgthp History request from 08.09.2020 08:55:00 to 09.09.2020 09:00:00 in 300s steps
Sep  9 08:32:53 172.16.111.19 AEQsnsmtgthp History request from 08.09.2020 09:00:00 to 09.09.2020 09:00:00 in 600s steps
Sep  9 08:33:06 172.16.111.19 AEQsnsmtgthp System reset
Sep  9 08:33:09 172.16.111.19 AEQsnsmtgthp System reset

Ich denke auch, dass es bei modbus möglich sein sollte, einen Fehler zu erkennen. Ich habe notiert, dass wir uns das für eine spätere Version ansehen.
Alternativ kann man schon jetzt einen Sensorfehler über eine HTTP-Anfrage erkennen. Eine Anfrage an http://ip/tpl/document.cgi?tpl/j/current.tpl&format=json liefert Informationen über das Gerät und alle Sensoren. Für jeden Sensor gibt es das Feld "status", in dem steht, ob ein Alarm oder ein Sensorfehler vorliegt. Ein Wert von 0 bedeutet, dass alles in Ordnung ist. Ansonsten kann man über die Bits in der Zahl herausfinden, welches Problem vorliegt. Folgende Werte sind aktuell definiert:
1: Unterer Grenzwert verletzt
2: Oberer Grenzwert verletzt
4: Wert fällt zu schnell
8: Wert steigt zu schnell
128: Sensorfehler
Es können auch mehrere dieser Bits gleichzeitig gesetzt sein.

Man kann diesen Sensor-Status auch in einem eigenem Template über die Webvariable sensortab_status abfragen, falls man den Wert zum Beispiel über HTTP-Push übertragen will.

In der neuen Firmware 5.0.12 gibt es das Modbus-Register mit Offset 9. Für jeden Sensor gibt es ein Bit, das bei einem Fehler auf 1 gesetzt wird. Wenn das Register 0 ist, dann gibt es keinen Sensorfehler. Bei einem Sensorfehler wird jetzt auch nicht mehr der alte Wert übertragen, sondern ein ungültiger Wert. Im Handbuch ist eine Tabelle mit den Registern.

Vielen Dank für das Implementieren der Funktion.
Wo finde ich die Zuweisung der Fehlerbits zu den Sensoren?

Für manche Anwendungen würde es vermutlich reichen, wenn man nur überprüft, ob es einen Fehler gibt, indem man das Register mit 0 vergleicht.