3. Fehlerzustände per Modbus/TCP erkennen

Fehlerzustände per Modbus/TCP erkennen


  • Guten Tag

    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?

    0
  • T
    Administrators

    Leider ist es aktuell nicht möglich, einen Sensorfehler über Modbus zu erkennen. Es wird weiterhin der zuletzt gelesene Wert übertragen. Nach einiger Zeit mit Fehler startet der Querx automatisch neu.

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

    0

  • Dass das Gerät unbeirrt alte Werte ausgibt ist etwas unglücklich... 0x0000 oder 0xFFFF als Wert oder ein Status-Register, das man abfragen kann wäre echt nützlich. Zum Glück ändert sich der Luftdruck nicht so schnell, aber es bedeutet, dass ich mindestens einmal täglich den Sensor anderweitig kontrollieren muss.

    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
    0
  • T
    Administrators

    Danke für die Versionsnummern.

    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.

    1
  • T
    Administrators

    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.

    1 1 Reply

  • @tim said in Fehlerzustände per Modbus/TCP erkennen:

    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?

    0
  • T
    Administrators

    Angefangen bei dem niederwertigsten Bit:
    Ist das erste Bit gesetzt (Wert 1), dann hat der erste Sensor (Temperatur) einen Fehler.
    Ist das zweite Bit gesetzt (Wert 2), dann hat der zweite Sensor (Luftfeuchtigkeit) einen Fehler.
    Ist das dritte Bit gesetzt (Wert 4), dann hat der dritte Sensor (Taupunkt) einen Fehler.
    Ist das vierte Bit gesetzt (Wert 8), dann hat der vierte Sensor (Luftdruck) einen Fehler.
    Ist das sechzehnte Bit gesetzt (Wert 32768), dann gibt es einen Fehler mit Batterie der RTC.
    Je nach Variante des Querx ist nur ein Teil der Sensoren vorhanden.

    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.

    1
Log in to reply