Group Details Private

administrators

  • egnite Querx not affected by Log4j

    A critical vulnerability in the Java library Log4j (Log4Shell) leads to a serious threat situation, according to the German Federal Office for Information Security (BSI) [german].

    Herewith we would like to inform you that the products egnite Querx and the tools we provide for it are not affected.

    posted in Announcements
  • egnite Querx nicht von Log4j betroffen

    Eine kritische Sicherheitslücke in der Java-Bibliothek Log4j (Log4Shell) führt nach Angaben des Bundesamtes für Sicherheit in der Informationstechnik (BSI) zu einer ernsten Bedrohungslage.

    Hiermit möchten wir Sie darüber informieren, dass die Produkte egnite Querx und die von uns dafür zur Verfügung gestellten Tools nicht betroffen sind.

    posted in Ankündigungen
  • RE: Python / Datenbank / Querx Beispiel

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

    posted in Generelle Diskussion
  • RE: Python / Datenbank / Querx Beispiel

    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.

    posted in Generelle Diskussion
  • RE: Bug: datalogger.tpl xml export mit nur 1 record

    Hallo Marco,
    wir werden das in einer zukünftigen Version korrigieren. In der Zwischenzeit könnte man im Python-Script überprüfen, ob das timestamp-Attribut leer ist.

    posted in Generelle Diskussion
  • RE: Gelöst: Ungültiges xml in xml export

    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.

    posted in Generelle Diskussion
  • RE: Update 4.4.29 auf 5.0.12

    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.

    posted in Generelle Diskussion
  • RE: Fehlerzustände per Modbus/TCP erkennen

    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.

    posted in Generelle Diskussion
  • RE: 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.

    posted in Generelle Diskussion
  • RE: Luftdruck mit und ohne Höhenkorrektur

    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.

    posted in Generelle Diskussion