Hallo,
in der Produktbeschreibung werden jeweils zwei Werte zur Genauigkeit angegeben.
Für CO2 zum Beispiel ±30ppm, ±3% des Messwerts. Bedeutet das, dass die jeweils kleinere Abweichug zutrifft, oder die jeweils größere?
Danke: mb
Bestbewertete Beiträge von mb
-
Genauigkeit der Sensoren
-
RE: Genauigkeit der Sensoren
Hallo Merlin,
kein Problem – der Urlaub ist gegönnt :)
Das dass Maximumwerte sind, die normalerweise nicht erreicht werden, ist schon klar – aber es muss natürlich klar sein, wo dieses Maximum liegt ...
Danke: mb
Neuster Beitrag von mb
-
RE: Angaben in Datei zu Sensorwerten
Um diese Sicherheitslücke müßte jemand entweder an die Karte kommen – also unerlaubten Zugriff auf die Hardware haben – oder die SD Karte über eine ungesicherte Verbindung beschreiben können. Letzteres möchte ich gar nicht – ersteres ist überall ein Problem, wo ich jemandem unbeobachteten Zugriff auf Hardware erlaube.
-
RE: Angaben in Datei zu Sensorwerten
Ja die Graphiken sind zoombar, aber der Zoom betrifft nur die Graphik. Im Browser kann ich im Gegensatz dazu die Gesamtdarstellung vergrößern, wovon dann auch Schriften (und insbesondere Tooltips) betroffen sind.
Beim Zoom geht es mit ja vor allem darum, den Zeitpunkt zu erkennen, zu dem sich ein Parameter zu ändern beginnt. Graphisch ist der zwar sehr schön zu sehen, aber zum erkennen der Zeit muss ich auch den Tooltip lesen können – und da kommt die Lupe ins Spiel ...
Ich setze Sailfish mit Android App Support ein (Android 11 kompatibel). Ich habe gerade extra noch einmal eine weitere Android App installiert – die führt die Rotation automatisch aus. Die Air-Q App bleibt im horizontalen Modus. Ich befürchte, da könnt ihr nicht viel machen. -
RE: Angaben in Datei zu Sensorwerten
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.
-
RE: Angaben in Datei zu Sensorwerten
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.
-
RE: Angaben in Datei zu Sensorwerten
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.
-
RE: Angaben in Datei zu Sensorwerten
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. -
RE: Angaben in Datei zu Sensorwerten
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 -
RE: Angaben in Datei zu Sensorwerten
Die Firmware selbst müsste dafür lediglich ein auf der SD Karte zu findendes Programm starten. Das dort befindliche Programm wäre natürlich viel Arbeit – aber wenn es Großteils in HTML und Javascript geschrieben und nicht minimiert wird, erlaubt es erfahrenen Nutzern auch es zu erweitern. So etwas ist eie prima Basis für die Einbindung einer Community – erfordert aber auch viel Offenheit ...
-
RE: Angaben in Datei zu Sensorwerten
Naja – die HTML und Javascript Dateien können ja auf der SD Karte liegen.
Auf der kann man auch eine Menge Platz sparen, indem man nicht jeden Tag 12 neue Dateien anlegt, sondern eine Sqlite Datenbank verwendet.
Wohl jeder der die Daten lesen und weiterverwenden will kann mindestens so gut mit einer Sqlite Datei umgehen, wie mit kodierten Dateien.
Platz halte ich da für kein Problem.
Ein kurzer Blick ins Internet zeigt zudem, dass eine 32 GB SD Karte bereits für wenig mehr als 4€ zu bekommen ist – damit stünden dann mindestens 16 GB Platz fürs Programm bereit ... -
RE: Angaben in Datei zu Sensorwerten
Hallo Merlin,
dass das Webinterface nur in Ausnahmefällen genutzt wird liegt meines Erachtens daran, dass es eben nur rudimentär ist – man bekommt halt lediglich die aktuellen Daten zu sehen und kann das Gerät konfigurieren. Jede Form von History oder Statistik ist darin ausgeblendet.
Es wäre schon schön, wenn das Webinterface auch die App ersetzen könnte. Ein Webinterface funktioniert nun mal im Browser, der jede Seite die auf HTML Code basiert skalieren kann. Die App kann das leider nicht. Es ist schon sehr lästig, wenn man für einen Blick auf Zahlwerte die Brille rausholen muss,statt einfach die Anzeige größer zu ziehen. Die App ist zudem nur auf einer Plattform lauffähig, während ein Webinterface sofort auf allen Plattformen zur Verfügung steht.
Auch der Export der Daten landet mit der App auf einem Gerät, auf dem ich die Daten nicht gebrauchen kann – ich muss sie von da also erst mal auf meine Zielplattform (PC) kopieren.
Meine erste Aktion bei Ankunft des Geräts ist daher gewesen das HTML Export Tool von Oliverr in C zu implementieren, um die Daten ohne ständige manualle Aktion in eine Datenbank importieren zu können, die dann auch individuelle Auswertungen erlaubt. Dafür hätte ich mir im Webinterface auch eine kleine Schnittstelle gewünscht. Zudem würde es Leuten wie mir das Leben deutlich erleichtern, wenn statt eines HTTP Interfaces, welches Daten auf recht eigenwillige Weise verschlüsselt, ein HTTPS Interface gibt, welches nach Authentifizierung die Verschlüsselung HTTPS überläßt.
Das Interface, wie es ist, hinterläßt bei mir den Eindruck, dass die Benutzer durch solche Probleme dazu gebracht werden sollen, ihre Daten in die Claud hoch zu laden – was für mich ein absolutes No Go ist.
Sorry für das Gemecker, aber ich denke, dass diejenigen, die so viel Geld für das Gerät ausgeben, die Daten auch gerne mir anderen verfügbaren Daten (zB Aussenwerte vom UBA) abgleichen würden – und da jedesmal zu warten bis einer bei euch die Zeit dafür hat, das zu imlementieren, scheint mir nicht der richtige Weg zu sein. Ich glaube, dass es euch gut tun würde, einiges an Auswertungsoptionen der Community zu überlassen. Bei einer brauchbar dokumentierten API finden sich immer Programmierer, die Spaß daran haben, zusätzliche Features zu implementieren.
Schönen Gruß: mb