Danke für die Informationen. Wir gucken uns das an.

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.

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

Thanks for the suggestions. Some of them are already implemented in version 5.0.3 Beta, which can be downloaded from http://sensors.egnite.de/en/network-sensors-and-data-loggers/support-and-service/querx-firmware/

Version 5 stores the configuration differently. You should create a backup of the configuration before updating and restore it later, because the old configuration will be overwritten. The new configuration increases the limits for many settings. The variables for HTTP Push can now be up to 127 bytes long.

TLS for HTTP Push is also implemented in Version 5, but only for Querx WLAN. It will be used if the url starts with https://

A timestamp for the current time can be accessed in templates using {{systimestamp}}.

The device MAC address is available in templates using {{mac}}. On Querx WLAN this will be the MAC address for the currently active interface. {{netiftab_mac.0}} will always be the LAN MAC address and {{netiftab_mac.1}} the WLAN MAC address.

Regards,
Tim

Unfortunately there is an error in the english translation of the tutorial:
The line with "{ # # }" should be replaced with "{# #}". This line marks the start of the http body and is used for calculating the content length. With the additional space characters it is not recognized and the content length is wrong. The following template should work:

add=/tpl/j/cloud.tpl

Authorization: Bearer {{pushtab_var1}}
Content-Type: application/json; charset=utf-8
{# #}
{"{{sensortab_name.0}}": {"value": "{{sensortab_value.0}}", "unit":"{{sensortab_unit.0}}"}, "{{sensortab_name.1}}": {"value": "{{sensortab_value.1}}", "unit":"{{sensortab_unit.1}}"}}