Angaben in Datei zu Sensorwerten

Micha

Da sind jetzt mehrere Fragen, Antworten und Ideen gepostet, die nicht unbedingt zusammen gehören.

https statt die aktuell verwendete Verschlüsselung: Das würde ich zwar auch begrüßen, macht es doch den Zugriff deutlich einfacher. Aber kommt dann nicht schnell die Frage nach Datensicherheit auf? D.h. Zugriff nur über Name und Passwort oder gar Benutzerverwaltung und das ganze Session-Handling. Auch wenn ich persönlich https begrüßen würde, ich kann mir denken, dass die airQ-Entwicklung da weiter denken muss, und die Anforderung nach Datensicherheit nicht einfach über Bord schmeißen darf. Ob die bestehende Verschlüsselung tatsächlich die Datensicherheit ausreichend gewährleistet, sei dahin gestellt.
SQLite:
Genau genommen sind das zwei Vorschläge:
a. airQ schreibt die Daten in eine SQLite-Datei statt in eine TXT-Datei.
Das sollte theoretisch möglich sein, gibt es doch SQLite-Libraries für den verwendeten ESP32. Aber wo soll der Vorteil sein??
b. airQ bietet über ein API die in SQLite gespeicherten Daten an. Damit verlagert man eine klassische Server-Funktionalität auf den airQ, wo sie definitiv nicht hingehört.
Der airQ startet ein Programm auf der SD-Karte:
Wenn dieses Programm dann tatsächlich auf dem airQ ausgeführt werden soll, denke ich dass dies kaum lösbar ist und vor allem recht kritisch ist.
Wird das Programm aber auf Client-Seite zur Ausführung gebracht, z.B. als Javascript, dann wäre das leicht lösbar und technisch unkritisch. Ich hatte das auch mal vor einiger Zeit vorgeschlagen. Der airQ ist bereits ein Mini-Webserver und könnte Space auf der SD-Karte für Web-Anwendungen reservieren. Man bräuchte lediglich eine kleine Fileserver-Funktionalität um Dateien in diesem Web-Space zu managen. Für den ESP32 gibt es da auch bereits einige Libraries. Meine vielen kleinen Tools würde ich dann dort hinschieben.
airQ versus Cloud:
Auch ich bin nicht unbedingt ein Freund der Cloud, aber Teile dieser Funktionalität auf den airQ zu schieben ist meiner Meinung nach der falsche Weg. Weitere Server-Funktionalitäten gehören technisch nicht dorthin. Der verwendete Micro Controller ESP32 ist als Basis für einen Server schlichtweg ungeeignet. Hier dann noch sicherstellen, dass die Sensor-Daten alle 1-2 Sekunden gescannt werden, wird kaum möglich sein. Performance Problem jeder Art sind dann vorprogrammiert. Wer keine Cloud im Internet benutzen möchte (wie ich z.B.), der muss dann halt seine eigene Cloud sprich einen lokalen Server aufbauen. Und er airQ bietet zum Glück über sein API alles an, was man so braucht. Ich verwende dazu einen kleinen sparsamen Raspberry mit mySQL als Datenbank und Grafana zur grafischen Auswertung. Der kostet nicht einmal 100 €, ist sehr sparsam im Unterhalt und trotzdem für meine Bedürfnisse ausreichend performant. Wie man die Daten stets aktuell vom airQ auf den Raspberry bekommt, habe ich mit diversen kleinen Tools realisiert, die hier alle veröffentlich sind. Wer diesen Weg einschlagen möchte, kann mich gerne kontaktieren, ich helfe gerne dabei. Aber ein gewisses technisches Know How muss man dann schon mitbringen.
Ein Vorteil ist dann auch, dass man so die airQ-Daten auch mit anderen gesammelten Daten korrelieren kann – Wetterberichte, Luftqualitäten von öffentlichen Messstationen, eigene Wetterstationen und vieles andere mehr.

Wenn wir das weiter diskutieren wollen, sollten wir vielleicht für jeden Sachverhalt einen eigenen Thread aufmachen.

mb

ad 1) bisher gibt es auch nur eine Passwort Authentifizierung
ad 2) der Vorteil liegt im Platzbedarf
ad 3) auf dem Server braucht nur ein minimaler Webserver zu laufen, die HTML und Javascript Daten wären deutlich größer – aber würden auf dem Client ausgeführt
ad 4) auch die derzeitige App liest ihre Daten vom Air-Q, da würde sich also nichts ändern – außer dass man Systemunabhängig ist und dass der Kunde bei entsprechendem Wissen die Funktionalität per JS entsprechend eigenen Vorstellungen erweitern kann

Micha

ad 2) der Vorteil liegt im Platzbedarf

Ich habe mal eben meine SD-Karte geprüft. Mein airQ ist seit Juni 2020 in Betrieb und alle Daten sind auf der SD-Karte. In den über 4 Jahren werden dazu 1,6 Mbyte benötigt. Die SD-Karte hat 16 GB. Ich schätze grob, dass bevor es Speicherplatzengpass gibt, die SD-Karte selber stirbt oder der airQ oder ich persönlich.

ad 3) auf dem Server braucht nur ein minimaler Webserver zu laufen, die HTML und Javascript Daten wären deutlich größer – aber würden auf dem Client ausgeführt

Das entspricht meinem Vorschlag.

ad 4) auch die derzeitige App liest ihre Daten vom Air-Q, da würde sich also nichts ändern – außer dass man Systemunabhängig ist und dass der Kunde bei entsprechendem Wissen die Funktionalität per JS entsprechend eigenen Vorstellungen erweitern kann

Nahezu alles kann man schön heute machen, außer dass die HMTL- und Javascript-Dateien nicht auf dem airQ stehen sondern lokal auf einem PC oder Server.
Das API ist dokumentiert und ich vermute stark, dass auch die App ausschließlich dieses API benutzt.

mb

Die Sorge um den Platzbedarf hatte Martin – bei Verwendung der SD statt alles in die Firmware zu packen gibt es keine Platzprobleme
Warum sollte man HTML und JS nicht auf den Air-Q stellen? Platz ist reichlich vorhanden und mit hoher cacheTime werden die auch nur selten vom Client geladen.
Das API ist dokumentiert – wenn man bereit und in der Lage ist 700€ zu zahlen.

Micha

Teile der Funktionen der App in Javascript und HTML zu programmieren ist auch sehr aufwendig und anscheinend braucht man dazu die teurere Science Version. Und ich schätze, dass man Performance Probleme bekommt, sobald man historische Daten auswerten will.

Eine preiswerte Alternative und deutlich einfacher zu entwickeln ist einen kleinen Server z.B. Raspberry aufzusetzen. Dafür muss man einmalig ca. 100 € spendieren. Im Dauerbetrieb braucht der Raspberry vielleicht 5-6 Watt, ist also im Betrieb recht sparsam. Und die Performance ist absolut ausreichend.

Auf dem Raspberry installiert man Apache, php, mySQL, phpMyAdmin und z.B. Grafana, und bei Bedarf noch einen mqtt-Server. Das alles ist in 1-2 h erledigt.

Die Daten vom airQ bekommt man über http-Post oder mqtt auf den Server. Das ist leicht in der Konfiguration des airQ einstellbar. Für die Serverseite muss man dann noch etwas programmieren, um die Daten in die Datenbank zu bekommen. Beispiele dazu habe ich gepostet.
Danach kann man mit Grafana seine individuellen grafischen Auswertungen erstellen. Bei Bedarf bindet man diese noch in entsprechende HTML-Seiten ein.

Nachfolgend ein kleines Beispiel:

mb

Klar ist es ein Performanceproblem, wenn man historische Daten in großem Stil mit dem kleinen Prozessor auswerten will – aber das kann man bereits heute über die App machen. Du rufst die App auf, klickst "Gesundheit" an, klickst irgendeinen der Messwerte an(zB "CO2"), dann unten "Diagramme" und weiter unterhalb der Graphik mit "wähle". Dort annst du den Zeitraum auswählen für den du die Auswertung haben möchtest. Über "Messgrößen" kannst du zudem zwei Größen auswählen die gleichzeitig angezeigt werden sollen.
Deine Argumente, dass das alles mit dem kleinen Prozessor nicht machbar wäre, sind angesichts des Umstands, dass es bereits gemacht wurde, ein wenig merkwürdig. Diese App wird so weit ich das sehe auch für alle Versionen des Air-Q verwendet.

Für große Auswertungen über lange Zeiträume macht es selbverständlich Sinn die Daten auf einen PC zu exportieren. Eine Echtzeitübertragung der Daten per MQTT dagegen halte ich für vollkommen uninteressant, solange sie nicht für eine Hausautomatisierung verwendet werden sollen. Genau für die Echtzeitdaten und die kurze History (Standard der App 24 Stunden) ist die App perfekt – sie sollte nur in HTML und JS erstellt sein.

Eine Ablage der HTML und JS Dateien des Webinterfaces auf der SD Karte wäre sehr gut geeignet interessierte Leute mit entsprechendem Knowhow in die Weiterentwicklung einzubinden. Zum Beispiel wäre es mit geringem Aufwand verbunden die Beschränkung der Messgrößen auf nur zwei Werte in den Graphiken aufzuheben – die Daten liegen eh vor, da immer alle Daten der angefragten Messperiode übertragen werden.

Die ganzen Tools, die du auf dem Raspi installierst, sind eben nur bei wirklich großen Auswertungen einen Blick wert – und da verlasse ich mich lieber auf selbst entwickelte Tools, die ich eh auf meinem Rechner habe. Die Schnittstelle für den Datenzugriff bei größeren Anfragen sollte aber ebenfalls HTML sein, so dass nicht für jeden zweck andere Interfaces angesprochen werden müssen. Auch das ist im Grunde bereits da – nur leider mit Dokumentationen nur für Science Nutzer und ineffektiven Mechanismen.

Micha

Erst einmal möchte ich ein paar Missverständnisse bereinigen:

Eine Echtzeitübertragung der Daten per MQTT dagegen halte ich für vollkommen uninteressant

MQTT ist keine Echtzeitübertragung sondern ein Netzwerkprotokoll zur M2M (machine to machine) Kommunikation. Damit können auch leicht kleine unperformante MQTT-Geräte mit einem MQTT-Broker verbunden werden. Ich hatte vorgeschlagen, dass man http-Post oder MQTT verwenden kann. Wer andere IoT Lösungen hat oder plant ist sicher mit mqtt gut bedient, ansonsten kann man auch http-Post verwenden. MQTT ist etwas sparsamer als http-Post, aber letztendlich in dieser Fragestellung reine Geschmacksfrage.

Deine Argumente, dass das alles mit dem kleinen Prozessor nicht machbar wäre ….

Da hast Du mich wohl falsch verstanden. Wenn man Teile der Aufbereitung der Daten und der Auswertung auf den airQ verlagert und ihn nicht ausschließlich als Datenlieferanten nutzt, dann wird es problematisch. Solange das alles auf einem PC geschieht, wird der airQ ja gar nicht zusätzlich belastet außer dass er die Rohdaten liefern muss.

Und ich schätze, dass man Performance Probleme bekommt, sobald man historische Daten auswerten will.

Unter „Performance Probleme“ verstehe ich dabei nicht, dass der airQ Problem bekommt, sondern die Auswertung selbst nicht performant ist.
Wenn ich die App im lokalen Netz starte, dann dauert es schon eine gute Weile bis die Daten der letzten 12 h (Default) in der App geladen sind. Mach einmal eine Auswertung über eine Woche, dann geht die Wartezeit in den Minutenbereich.
Genau diese Wartezeiten wird man auch bekommen, wenn man mit einem Javascript Code die Daten vom airQ holt. Aus einer Datenbank bekommt man diese im Sekundenbereich.

Die Schnittstelle für den Datenzugriff bei größeren Anfragen sollte aber ebenfalls HTML sein, ….

Also die bestehende Schnittstelle basiert nicht auf HTML und HTML würde in diesem Zusammenhang auch keinen Sinn machen. Die Daten selber sind (nach der Docodierung) als JSON-Strings codiert.
Und wie gesagt, es gibt bereits Code-Beispiele mit der man Daten vom airQ via Javascript holen kann. Also alles ist heute bereits machbar, außer dass der Javascript- und HTML-Code nicht auf dem airQ, sondern auf dem PC liegen muss.
Die Daten dann aufzubereiten, grafisch darzustellen und ein ansprechendes GUI bereit zu stellen ist halt eine sehr große Menge Arbeit.

nur leider mit Dokumentationen nur für Science Nutzer und ineffektiven Mechanismen.

Wieso dies? Der Javascript Code zum Holen der Daten vom airQ steht hier im Forum.
Siehe auch: https://forum.air-q.com/topic/36/airq-api-nutzen/12?page=2
und https://forum.air-q.com/topic/93/eigene-air-q-datenbank-für-z-b-grafana-etc/8
und https://forum.air-q.com/topic/408/php-script-zum-speichern-der-air-q-daten-in-eine-textdatei
und https://forum.air-q.com/topic/74/csv-download/12

Und wo soll da jetzt ein ineffektiver Mechanismus sein?

mb

MQTT ist keine Echtzeitübertragung sondern ein Netzwerkprotokoll

MQTT ist dafür gedacht automatisch Daten von einem Client auf einen Server (MQTT Broker) zu bekommen. Da das automatisch passiert, ohne ständig wiederkehrende Requests, ist das eine Echtzeitübertragung – die Daten werden übertragen sobald sie vorliegen. Das eine schließt übrigens das andere nicht aus.

Wenn man Teile der Aufbereitung der Daten und der Auswertung auf den airQ verlagert

Der AirQ soll auch nur die Rohdaten liefern – aber die App soll HTML basiert sein.

Genau diese Wartezeiten wird man auch bekommen, wenn man mit einem Javascript Code die Daten vom airQ holt. Aus einer Datenbank bekommt man diese im Sekundenbereich.

Deshalb die Speicherung in einer SQLite Datenbank – die ist auch auf einem ESP32 deutlich performanter als das Dateisystem.

Also die bestehende Schnittstelle basiert nicht auf HTML

Sorry für diesen Fauxpas – hier war selbstredend HTTP gemeint. JSON ist für Javascript geschrieben, also leicht handhabbar.

Der Javascript Code zum Holen der Daten vom airQ steht hier im Forum.

Ja – aber der braucht eine manuelle Aktion und ich bevorzuge es doch sehr deutlich, wenn der Rechner solch wiederkehrende Aufgaben ohne weitere Interaktion ausführt.

Du hast noch immer nicht mitbekommen worum es mir geht:

die App soll unbedingt in HTML/JS geschrieben sein. Grund hierfür ist, dass Tooltips in den Graphiken viel zu klein geschrieben werden und nicht vergröert werden können, die App läuft nur horizontal, läßt sich also nicht drehen, eine Erweiterung ist für den Anwender unmöglich ohne alles von Grund auf neu zu schreiben – alles Punkte die sich HTML/JS quasi von selbst erledigen. (wem es dann zu langsam ist, der kann sich ja immer noch einen Server daneben stellen – aber wie häufig macht man solche Abfragen?)
alle Schnittstellen sollen offiziell dokumentiert werden – nicht nur das bestätigt werden, was jemand gerade mal heraus gefunden hat.

Dein Downloadscript habe ich längst nach C und OpenSSL übertragen. Das läuft deutlich schneller und vor allem ohne Interaktion. Auch eine Realtimeabfrage der Daten wäre grundsätzlich über Abfrage von http://air-q/ping möglich, nur muss man dafür alle 1.9 Sekunden abfragen um keine Messung zu verpassen. Aber an einer 2-Sekunden genauen Auflistung der Daten bin ich nicht interessiert, der abgespeicherte 2 Minuten Takt ist meines Erachtens schon mehr als genau genug.

mb

Noch ein nicht zu vergessender Vorteil der HTML-App: Die ist auf allen Plattformen gleichermaßen einsetzbar. Da ich eh den gannzen Tag am Rechner sitze, möchte ich nicht zum Handy greifen müssen, um zu sehen, warum die Luftwerte gerade in den Keller gehen. Und ich kann mir vorstellen, dass es allen Leuten, bei denen so ein Gerät im Büro steht, genauso geht. Der Webserver im Gerät erfordert jedesmal eine Passwortabfrage, was ja auch sinnvoll ist, da er keine HTTPS unterstützt, aber das macht ihn nur benutzbar, wenn man den Tab den ganzen Tag offenläßt, um bei Bedarf nur noch auf "Aktualisieren" drückt. Einfach nur lästig so etwas.

Merlin [air-Q]

Nur ein kleiner Zusatz von mir: Die Grafiken in der App sind zoombar und die App läuft auch bei gedrehtem Bildschirm. Sollte eine der beiden Funktionen bei dir nicht klappen, freuen wir uns über Details wie Modell des Endgerätes etc. damit wir das Problem beheben können.