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.

Hallo Noah,

die Write-Community war vorgesehen, damit später auch Veränderungen implementiert werden können. Da das aktuell nicht möglich ist, wurde die Write-Community in der neu veröffentlichten Firmware-Version 6.0.7 jetzt komplett deaktiviert. Sie kann hier heruntergeladen werden: https://www.egnite.de/support/firmware/

Viele Grüße,
Tim

Ein unter WSL 2 laufender Firefox auf demselben Computer ist nicht betroffen. Dies ergibt insofern Sinn, als dass mit WSL 2 ein komplettes, virtualisiertes Linux unter Windows läuft.

Links Firefox nativ Windows 11, Rechts Firefox unter Debian in Windows Subsystem for Linux 2

Unter WSL 1, das den Netzwerkstack von Windows zu nutzen scheint, kann ich es nicht so leicht testen, da dort das Laufelassen von GUI Applikationen nicht ohne weiteres möglich ist (Ja, es gibt Workarounds)

Und wer den Taupunkt wissen will, kann den SQL-Server rechnen lassen. Der macht das sehr effizient :). Bei der Abfrage von 19'000 Zeilen aus der DB lag der Zeitunterschied für die Verarbeitung der Abfrage unterhalb der mehr oder weniger zufälligen Varianz zwischen mehreren Anfragen.

SELECT *, ROUND(-4283.58 / ((LN( HumidityAvg / 100 ) + ((17.625*TemperatureAvg) / (243.04+TemperatureAvg))) - 17.625) - 243.04, 1) AS DewPoint FROM ClimateData WHERE TIME BETWEEN '2022-01-1 00:00' AND '2022-03-11 09:00'

Die Resultate der Rechnung stimmen mit jenen überein, die vom Querx-Sensor selber ausgegeben werden.
Die ursprünglich Formel war:

ROUND( (243.04 * (LN( HumidityAvg / 100) + ((17.625 * TemperatureAvg) / (243.04 + TemperatureAvg)))) / (17.625 - (LN( HumidityAvg / 100 ) + ((17.625*TemperatureAvg) / (243.04+TemperatureAvg)))), 1) AS DewPoint

Da ist aber (LN( HumidityAvg / 100) + ((17.625 * TemperatureAvg) / (243.04 + TemperatureAvg)) 2 mal drin, deshalb habe ich mit WolframAlpha rumgespielt, bis etwas kürzeres heraus kam Die Ergebnisse sind identisch, die umgestellte Rechung ist aber deutlich kürzer und sollte auch effizienter sein.

Ach, das hatte ich glatt übersehen. In der Tat ist hier das Template fehlerhaft. Dort wird für beide Zeiten die Lokalzeit histotab_time verwendet. Für UTC sollte es aber histotab_gmtime sein.

@tim Danke für das Aufnehmen der Meldung.
Mein Script werde ich eventuell anpassen (das ist wie du schreibst wirklich kein grosser Aufwand). Allerdings ist dies sowieso eher ein Grenzfall, in welchem sowieso keine Daten in die Datenbank zu schreiben sind und daher die Fehlermeldung höchstens ein kosmetisches Problem ist.

Mie Erwähnung des Python-Programmes war eher als Hinweis gedacht, wie ich diesen Bug überhaupt entdeckt habe.

@Daniel said in Design Querx Webinterface:

Ich weiss nicht, ob es zum Anwendungsfall passt, aber es gäbe die Möglichkeit über so etwas wie Tampermonkey ein Userscript im Browser zu installieren, was das Favicon ändert.
Siehe https://stackoverflow.com/questions/16745773/embed-favicon-using-a-userscript
Per Userscript ließe sich prinzipiell auch das CSS überschreiben. Geht es um ein bestimmtes Interface-Element?

Danke @Daniel
Die Frage wegen des Favicon war vor allem, um in den Schnellstart-Icons im Firefox nicht nur das hässliche default-icon aus dem Anfangsbuchstaben des Seitennamens zu sehen oder aber dieses auf jedem Rechner von Hand setzen zu müssen.

Ich kann aber die Begründung des Entwicklungsaufwandes absolut nachvollziehen (auch in Anbetracht der wohl recht beschränkten Resourcen auf dem Sensor selbst).

Ich kann gut damit leben. Es wäre aber schade, wenn die Möglichkeit bestünde, aber ich sie nicht nutze weil ich nichts davon weiss

vielen Dank für die schnelle Antwort

Hat perfekt funktioniert! Vielen Dank!

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.

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.

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.

@Megachip said in Querx THP 3.4.10.1:

Ich muss mal drauf achten, ob es bei anderen Firmwares auch auftritt.

Der "Fehler" tritt bei 5.0.11.1 nicht auf. Scheint also irgendwie an der Kombi 3.4.10.1 und Safari zu liegen.

Kann man dann wohl zu den Akten legen, so alt wie diese FW ist

Besten Dank und viele Grüße
Meg

Nochmal vielen Dank @Marco-T!

Viele Grüße
Daniel

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.

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.

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

Wow, ihr seid ja fix! Danke!