Best posts made by tim

Hallo Marco,

ich hätte noch ein paar Verbesserungsvorschläge:

Aktuell wird der Timestamp in Python in einen String in Lokalzeit umgewandelt. Danach wird er von der Datenbank in DATETIME umgewandelt. Das könnte zu Problemen führen, wenn es eine Zeitumstellung gibt oder Datenbank und Python mit unterschiedlichen Zeitzonen arbeiten. Bei einer Zeitumstellung könnten dann z.B. Daten für eine Stunde verloren gehen. Eine mögliche Lösung wäre es, wenn man den Timestamp direkt als Zahl speichert. Man könnte auch die Zeitzone von Datenbank und Python auf UTC einstellen.

Aus Sicherheitsgründen wäre es besser, wenn man die SQL-Anfrage nicht komplett als String baut. Wenn sich ein Angreifer als Querx ausgeben kann, dann könnte er z.B. in einem Sensorwert einen SQL-Befehl zum Löschen der Tabelle einschleusen. Stattdessen gibt es normalerweise Funktionen, um in der SQL-Anfrage Platzhalter zu verwenden und die Daten getrennt zu übergeben.

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

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.

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

Aktuell ist es leider nicht möglich den Luftdruck gleichzeitig absolut und relativ abzufragen. In manchen Fällen könnte es reichen, den Luftdruck immer absolut abzufragen (indem die Höhe auf 0 gesetzt wird) und später selbst umzurechnen. Dann wäre die Anzeige im Webinterface aber auch absolut.
Ein neues Register für den absoluten Luftdruck einzuführen, wäre möglich. Wir werden das vermutlich für eine zukünftige Firmware-Version implementieren.

1. Ein kleiner Nachteil ist, dass beim Ausschalten des Querx oder einem Stromausfall der letzte gespeicherte Wert weiter zurück liegen kann. Im Diagramm könnte die Lücke bei einem Stromausfall also größer aussehen, als sie eigentlich war. Es könnte auch noch andere Darstellungsfehler im Diagramm geben.

2. Die Werte inklusive Min und Max müssen für alle Sensoren gleich sein, damit nichts gespeichert wird. Sobald sich ein Wert verändert, wird wieder alles gespeichert.

3. Beim Export und im Diagramm werden die vorherigen Werte wieder rekonstruiert. Eine Lücke erscheint nur bei Neustart des Gerätes. (Dazu werden die ersten Sensordaten nach einem Neustart speziell markiert.)

In der neuen Firmware 5.0.12 gibt es das Modbus-Register mit Offset 18. Darin ist der absolute Luftdruck enthalten. Der relative Luftdruck ist weiterhin im Register mit Offset 19. Im Handbuch ist eine Tabelle mit den Registern.

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.

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.

Intern wird die Konfiguration jetzt anders gespeichert, wodurch sie bei dem Update verloren geht. Das Backup der Konfiguration ist aber kompatibel. Das Backup enthält allerdings keine Passwörter. Diese müssen später manuell wieder eingegeben werden. (Ab Version 5.0 kann man optional auch ein Backup mit Passwörtern erstellen.)

Das Update sollte nur gemacht werden, wenn der Querx über Ethernet und nicht Wlan im Netz ist, da die Wlan-Zugangsdaten verloren gehen. Auch andere Einstellungen, wie HTTPS, gehen verloren und können dazu führen, dass nach dem Update erst anders auf den Querx zugegriffen werden muss.

Nach dem Update erscheint auf den Konfigurationsseiten des Querx eine Meldung, dass die alte (interne) Konfiguration nicht lesbar ist. Diese Meldung muss mit "Reset configuration" bestätigt werden, um die Konfiguration zu überschreiben. Wenn man sie nicht bestätigt, dann könnte man auch noch eine ältere Firmware wieder aktivieren, um erneut auf die alte Konfiguration zuzugreifen.

Es gibt auch die Möglichkeit, ein Update mit Querx Hub durchzuführen. Dabei wird die Konfiguration automatisch gesichert und wiederhergestellt. Allerdings kann das auch hier nicht über Wlan gemacht werden und Passwörter gehen verloren.

Templates für Palamoa sollten weiterhin funktionieren.

Hallo Marco,

wir werden das in der nächsten Version korrigieren.
In der Zwischenzeit könnte man ein eigenes Template in den Einstellungen unter Firmware bei "Content installieren" hochladen. Folgendes Template könnte benutzt werden:

add=/tpl/j/currentxml.tpl

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE querx PUBLIC "-//egnite//DTD Querx 1.0//EN"
  "http://www.egnite.de/dtds/querx.dtd">
<querx version="1.0">
        <hostname>{{hostname}}</hostname>
        <ip>{{ip_addr}}</ip>
        <port>{{http_port}}</port>
        <date_gmt>{{ DATE_GMT }}</date_gmt>
        <date_local>{{ date_local }}</date_local>
        <contact>{{syscontact}}</contact>
        <location>{{syslocation}}</location>
        <sensors>
                {%for sensortab%}
                <sensor id="sensor_{{loop.index}}"
                        name="{{sensortab_name}}"
                        unit="{%if sensortab_unit=="&deg;C"%}°C{%elif sensortab_unit=="&deg;F"%}°F{%else%}{{sensortab_unit}}{%endif%}"
                        status="{{sensortab_status}}"
                        uplim="{{sensortab_lim_hi}}"
                        lolim="{{sensortab_lim_lo}}"/>
                {%endfor%}</sensors>

        <data>
                <record>{%for sensortab%}
                        <entry sensorid="sensor_{{loop.index}}" name="value" value="{{sensortab_value}}" trend="{{sensortab_trend}}"/>{%endfor%}
                </record>
        </data>
</querx>

Danach kann man das Template mit einer Anfrage an http://192.168.1.100/tpl/document.cgi?tpl/j/currentxml.tpl auswerten.

@Marco-T Ja, der Timestamp ist in UTC. Die anderen Attribute date und time sind in Lokalzeit des Querx.

Danke, das ist interessant. Eine genaue Ursache konnte ich noch nicht finden. Vielleicht hängt es damit zusammen, dass der Querx ohne WLAN die Anfragen nicht parallel bearbeiten kann. Der Browser muss dann etwas länger warten.

Hallo Marco,

das Ersetzen von "$1" wird nicht mehr unterstützt, weil die Templates jetzt flexibler sind und die Aufgabe übernehmen können. Das integrierte Template palamoa.tpl enthält z.B. folgende Zeile:

{%option url%}http://palamoa.de/json/{{actiontab_var1}}{%endoption-%}

Damit wird eine Standard-URL gesetzt, die von der ersten Variable abhängt. Wenn man in den Einstellungen der Aktion keine andere URL angibt, dann wird die URL von diesem Template automatisch generiert.

Bei den Logeinträgen nach Drücken von Test sollten immer nur die letzten Einträge stehen. Die haben dann auch die selbe oder eine ähnliche Zeit. In dem Screenshot ist merkwürdig, dass die Nachricht mit Push zweimal auftaucht. Sieht das auch so aus, wenn man die Logeinträge in den Einstellungen unter Syslog anzeigt? Hier werden die letzten 8 Nachrichten angezeigt.

Hallo Marco,
wenn das Template noch auf dem Querx ist, dann kann man es sich auch anzeigen lassen. Auf der Firmware-Seite gibt es unten die Liste der Dateien und man kann sie editieren. Auf der Konfigurationsseite der Aktion gibt es neben der Auswahl des Templates auch einen Editier-Button, mit dem man auch integrierte Templates sehen kann.

Bei dem Test-Knopf werden immer die Log-Einträge seit Start des Tests angezeigt. Dabei können auch Einträge sein, die eigentlich unabhängig vom Test sind.

Eigene Header können einfach am Anfang des Templates nach den Optionen stehen. Die Zeile "{# #}" ist ein Kommentar, der nicht übertragen wird. Stattdessen ist hier eine leere Zeile, die bei HTTP die Header von dem Inhalt trennt. In dem Template gibt es bereits den Header "Content-Type". Hier ist ein Beispiel-Template, das den API-Key für Palamoa als Header überträgt:

{%escape json-%}
{%option method%}POST{%endoption-%}
{%option url%}http://palamoa.de/json/{%endoption-%}
{%option num_variables%}1{%endoption-%}
{%option title1%}API-Key{%endoption-%}
Content-Type: application/json; charset=utf-8
Apikey: {{actiontab_var1}}
{# #}
{
"device_name": "{{hostname}}",
"temperature": {"label": "{{sensortab_name.0}}","value": "{{sensortab_value.0}}", "unit":"{{sensortab_unit.0}}", "color": "{{sensortab_chart_color_html.0}}"}
}

Danke für den Hinweis zu den Anführungszeichen.