Topics created by Marco T

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.

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)

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.

Hallo Marco

Vielen Dank für deinen Code für das Python DB-Backup. Ich habe es auch implementiert. Bei mit hat das mit den Values als Fragezeichen nicht funktioniert. Ich musste die Fragezeichen mit einem %s ersetzen. Weiss nicht genau warum. Ich arbeite mit dem "mysql.connector", also ich mache

import mysql.connector as mysql

@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

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.

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!

Hallo Daniel

@Daniel said in Bugreport: Palamoa Website zeigt unter "Aktive Sitzungen" Geräte nicht an:

dieses Feature wurde vor ca. eine Woche implementiert und funktioniert nur in Kombination mit der aktuellen Version (1.2) der Palamoa Android App. Außerdem ist nach diesem Update ein einmaliges Aus- und wieder Einloggen erforderlich, damit die Session gespeichert wird.

Korrekt. Nach dem Aus- und wieder Einloggen wird die Session angezeigt.

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.

Achja, nachdem ich auf der Website in den Edit-Modus gewechselt und die Sensor-Konfiguration geöffnet hatte, werden die "0"-Werte korrekt angezeigt... Bin etwas verwirrt, aber vielleicht hilft euch die Information weiter.

Gerade gesehen, dass 4.4.27.1 veröffentlicht wurde. Probiere ich mal aus, auch wenn ich seit der Nachricht hier keine Sensor-Fehler mehr hatte (damals halt gerade 2 mal kurz hintereinander).

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.

@Daniel said in Wunschliste Palamoa:

Eine Möglichkeit zum Daten-Export ist meiner Meinung nach auch sehr sinnvoll und übrigens schon lange geplant.

Cool. Habe vor einer Weile gesehen, dass dies umgesetzt wurde und es funktioniert wunderbar. Danke!
Habe die Liste entsprechend angepasst.

lg, Marco

@Daniel Cool! Sehr schön und verständlich gemacht.
Ich hoffe, ihr habt "meine" Taupunkt-Formel überprüft und vielleicht auch an eure intern genutzte Formel angepasst. Das habe ich selber nämlich nicht gemacht und einfach angenommen, dass sie stimmt als ich sinnvoll erscheinende Ergebnisse erhielt.

Auf alle Fälle: danke für die ganze Arbeit, die ihr mit den Tutorials leistet. Ein dickes "thumbs up"