Kurzes Update nach 5 Tagen:
Leider immer noch häufige Neustarts:
Ich habe gerade die Zeit zwischen den Abfragen meines Scripts auf 30 Sekunden erhöht.
Ich schaue mir weiter an wie es läuft und melde mich regelmäßig wieder.
Ein weiteres Update: Seit dem letzten Update des AirQs sind die Neustarts deutlich weniger geworden. Schätzungsweise alle 2-3 Wochen.
Hallo @Mario-air-Q,
Da nun schon ein halbes Jahr vergangen ist seit der letzten Antwort, wollte ich mich mal nach dem Status erkundigen.
Gibt es ein Update zu dem Thema? :)
Hallo zusammen,
Ich bin schon länger Nutzer des Air Q. Als ich ihn erworben habe, wurde auf der Produktseite https://www.air-q.com/smart-home-standards/google-assistant der Status bereits mit "Folgt in Kürze (2-3 Monate)" angeben.
Das ist nunmehr 1,5 Jahre her.
Passiert in der Richtung noch irgendwas?
Viele Grüße
Steffen
Ein weiteres Update: Seit dem letzten Update des AirQs sind die Neustarts deutlich weniger geworden. Schätzungsweise alle 2-3 Wochen.
Kurzes Update nach 5 Tagen:
Leider immer noch häufige Neustarts:
Ich habe gerade die Zeit zwischen den Abfragen meines Scripts auf 30 Sekunden erhöht.
Ich schaue mir weiter an wie es läuft und melde mich regelmäßig wieder.
Hallo @Daniel,
Danke für deine ausführliche Antwort!
@Daniel-air-Q sagte in Air-Q started regelmäßig neu:
@sscheib, wäre es möglich zu schauen, wie es sich auswirkt, wenn das Abfrageintervall reduziert wird? Zumdindest für ein paar Tage? Dann könnte man schon einen statistischen Zusammenhang erahnen.
Ich habe testweise mal den ICMP Ping weggelassen, welcher jede Minuten gelaufen ist und der Air Q hat volle drei Tage durchgehalten. Das ist immer noch nicht optimal, aber deutlich besser als davor; Da hat er teilweise mehrfach am Tag neu gestartet. Ich werde das jetzt mal weiter beobachten und melde mich regelmäßig mit neuen Erkenntnissen.
@Daniel-air-Q sagte in Air-Q started regelmäßig neu:
Die Abfrage alle 1,5 Sekunden sollte regulär funktionieren. Auch parallele Abfragen sollten zu keinem Problem führen.
Da bin ich wirklich beruhigt - ich hätte mich sehr geärgert, wenn das nicht möglich gewesen wäre.
@Daniel-air-Q sagte in Air-Q started regelmäßig neu:
Da wurde in Firmware 1.80.0 etwas Finetuning am Timing durchgeführt. Trat das in 1.79 auch schon auf?
Das kann ich leider nicht sagen, da ich den Air Q wirklich erst seit sehr kurzer Zeit habe (~14 Tage) und dann auch direkt auf die 1.80 Beta Version gegangen bin.
@Daniel-air-Q sagte in Air-Q started regelmäßig neu:
Die Gute Nachricht zum Schluss: Die Reboots haben keinen Einfluss, außer dass ein paar Messpunkte fehlen.
Das ist wirklich eine gute Nachricht, ich hatte befürchtet, dass die Sensoren sich erst wieder warm laufen müssen.
@Daniel-air-Q sagte in Air-Q started regelmäßig neu:
Kurz: FAT32, keine Herstellerpräferenz, einfach leere Karte rein oder Karte auf die die alten Daten drauf kopiert worden sind
Danke, das hilft! :)
@Daniel-air-Q sagte in Air-Q started regelmäßig neu:
Diese Fehler stehen dann nicht im Error-Log - weil die Firmware hier nicht mehr greift - können aber durch Setzen des Konfigurationsschlüssels {"logging": "Warning"} indirekt aufgezeichnet werden, denn dann werden auch Neustarts ins Log eingetragen.
Danke für den Hinweis. Wäre es ggf. generell möglich den Log nicht bei jedem Neustart zu leeren? Oder den Log nach einem Neustart zu rotieren (sprich in eine neue Datei zu packen)?
Ich denke das würde bei der Fehleranalyse helfen, da ich jetzt nicht mehr die Möglichkeit habe die Logs vor dem Neustart zu sehen.
Ich weiß jetzt leider nicht, ob die Logs bereits rotiert werden (was eventuell schon geschieht, wenn man sich den Namen des Logfiles ansieht: log.0.html); Sollte das der Fall sein, wäre es eventuell sinnvoll den API Endpoint log insofern zu erweitern, dass ich eine Zeitspanne angeben kann, von dem ich den Log sehen möchte. Das würde auch immens beim ständigen Auslesen der Daten helfen, um diese bspw. in Zabbix zu packen.
Ich hatte mir initial überlegt, die Logs in Zabbix zu packen, allerdings habe ich hier neben der oben genannten Schwierigkeit, die "Schwierigkeit", dass die Logs mit HTML-Tags formatiert sind; Es wäre schön, wenn die Daten wie bei allen anderen API Endpoints im JSON Format zurück geliefert werden könnten.
Zum Schluss noch etwas Lob: Ich bin wirklich glücklich mit dem Air Q! Ich kann soviele detailierte Daten über die Luftqualität messen und auch sinnvoll auslesen über die API - da habt ihr anderen Herstellern wirklich einiges voraus!
Deshalb an dieser Stelle: Super arbeit, vielen lieben Dank!
Viele Grüße
Steffen
@Micha sagte in Air-Q started regelmäßig neu:
Bei zumindest wenig größeren Intervallen könnte auch die Errorrate, die es für jeden Sensor gibt, eventuell weiterhelfen?
Stehe gerade auf dem Schlauch, inwiefern könnte das helfen?
@Micha sagte in Air-Q started regelmäßig neu:
Sollte tatsächlich, wie ich vermute, der Air-Q auf einem ESP-Mikrocontroller basieren, dann fällt mir noch ein Problem auf, mit dem ich in anderen ESP-Projekten manchmal zu kämpfen hatte. Der ESP kann auch "in die Knie gehen", wenn parallel mehrere Clients die Daten abfragen.
Gibt es bei Dir diese Situation?
Ich habe lediglich zusätzlich hin- und wieder die Air-Q Android App genutzt im Bezug auf einen Client der Daten abfrägt.
Allerdings habe ich bei Zabbix auch ein Ping-Template hinterlegt, welches alle 60 Sekunden einige Pings an den Air-Q sendet, zwecks Verfügbarkeitsprüfung, ICMP Loss, ICMP High Ping Prüfung. Diesen habe ich nun testweise mal deaktiviert.
Ich werde das weiterhin beobachten.
@Micha sagte in Air-Q started regelmäßig neu:
Man kann bereits die aktuellen Logs abfragen.
Das ist perfekt, Danke. Wusste gar nicht, dass es den API Endpoint /log gibt - aber das kann ich nun natürlich auch in den Zabbix packen :)
Danke für deine Antwort, Micha!
Um auf deine Fragen und Bemerkungen einzugehen:
@Micha sagte in Air-Q started regelmäßig neu:
Alle 1,5 Sek. die Daten abzufragen, halte ich für sportlich. Im Air-Q sitzt meines Wissens nach ein Mikrocontroller der ESP-Familie. Ich kann mir schon vorstellen, dass er da an ein Limit kommt
Das wäre meiner Meinung nach nicht akzeptabel, wenn das Gerät keine Abfragen alle mindestens 1,8 Sekunden ab könnte, da ja effektiv damit geworben wird, dass der Air Q alle ~ 1,8 Sekunden misst; Hat man nun die Science Version, möchte man sicherlich diese Vielfalt an Daten auch abfragen und bewerten. Sonst nützt mir eine Messung alle 1,8 Sekunden recht wenig, wenn ich die Daten beispielsweise nur alle Minute abfrage.
Das ist meine persönliche Meinung und ich möchte hier auch niemanden angreifen, aber ich denke für knappe 700 Euro sollte das schon drin sein.
@Micha sagte in Air-Q started regelmäßig neu:
Was machst Du mit soviel Daten?
Mir geht es vorallem um die Lärm-Sensor Daten um eventuell auftretende kurze Lärm-Peaks zu isolieren. Bei allen anderen Werten stimme ich dir zu, die ändern sich nicht so häufig, dass sich ein Abfragen tatsächlich rentiert. Leider gibt es (meines Wissens nach) keinen API Endpoint, der mich speziell einen Sensor abfragen lässt, daher muss ich zwangsgedrungen alle Sensoren abfragen (über den API Endpoint) /data - wenn ich die Daten schonmal abgefragt habe, kann ich sie natürlich auch gleich vorhalten. 1,5 Sekunden deshalb, weil der Air Q alle 1,8 Sekunden eine Messung vornimmt (bzw. vornehmen sollte) und ich somit keinen Messpunkt verpasse (Verbindung zum Air Q muss ja aufgebaut werden und Daten abgefragt werden, sprich ich rechne eine Toleranz von 300ms ein).
In der Praxis schnellt der Wert measure_time manchmal (seltener) bis auf ~3 Sekunden hoch.
Natürlich könnte man über /file gehen und alle N Minuten die gesammelten Datenpunkte abfragen, aber dann hätte ich ja keine Live-Daten, sondern historische Werte. Die Frage bleibt natürlich offen, ob das tatsächlich die Last verringern würde, da schließlich die ganze Datei übertragen werden muss (die vermutlich schon verschlüsselt vorliegt).
@Micha sagte in Air-Q started regelmäßig neu:
WLANconnect Fehler
Luftlinie sind das bei mir von Access Point (AP) zu Air Q weniger als drei Meter. Was ich mir vorstellen könnte ist, dass der Air Q meinen anderen AP (der als Repeater dient) kontaktiert, was aber keinen Sinn machen würde, da das Signal deutlich schwächer ist. Da ich auch meine APs monitore und die Logs etwas durchforstet habe, kann ich das auch mit 99% Sicherheit ausschließen.
@Micha sagte in Air-Q started regelmäßig neu:
main overwatch loop detected that the main loop timed out
Gut, dann muss ich mir hier wohl keine Sorgen machen :)
@Micha sagte in Air-Q started regelmäßig neu:
SD-Kartenfehler: Halte ich für kritisch. Prüfe doch mal die SD-Karte oder setze gleich eine Neue ein.
Ich habe noch SD-Karten, die ich nutzen kann, allerdings habe ich keine Info gefunden
Natürlich ist klar, dass die Daten auf der SD-Karte verloren gehen, wenn ich eine neue SD-Karte einsetze, da ich aber meine Daten sowieso extern (Zabbix) vorhalte, stört mich das überhaupt nicht.
Vielen Dank!
Viele Grüße
Steffen
Hallo zusammen,
Ich frage mittels Python Messwerte vom Air Q alle 1,5 Sekunden ab, um diese Daten dann zu einer Zabbix Instanz zu senden.
Ferner, monitore ich auch den Uptime-Status des Air Q und dieser startet sich in in unregelmäßigen Abständen neu; Ich schließe das aus dem Wert uptime
vom API-Endpoint /data.
Mein Air Q hat sich an folgenden Tagen neugestartet:
Es läst sich aufgrund der aufgetretenen Ereignisse kein Muster erkennen.
Im Log konnte ich einige Informationen finden:
2022-11-10T20:21:13+00:00 Error 1.80.0-rc4 WLANconnect Connecting to network failed - Type: OSError; Reason: the requested operation failed
2022-11-10T20:21:18+00:00 Error 1.80.0-rc4 WLANconnect Connecting to network failed - Type: OSError; Reason: the requested operation failed
2022-11-10T20:36:43+00:00 Error 1.79 writeSD Last run timestamp could not be read from SD card - Type: ; Reason: invalid syntax for integer with base 10
2022-11-10T20:36:54+00:00 Error 1.79 writeSD Last run timestamp could not be read from SD card - Type: ; Reason: invalid syntax for integer with base 10
2022-11-10T20:47:57+00:00 Error 1.79 writeSD Last run timestamp could not be read from SD card - Type: ; Reason: invalid syntax for integer with base 10
2022-11-10T20:48:10+00:00 Error 1.79 writeSD Last run timestamp could not be read from SD card - Type: ; Reason: invalid syntax for integer with base 10
2022-11-13T00:44:08+00:00 Error 1.79 sensors Sensors could not be read - Type: ; Reason: Status
2022-11-13T00:44:08+00:00 Error 1.79 sensors Sensor values could not be averaged - Type: ; Reason: timestamp; Traceback: None
2022-11-13T12:51:24+00:00 Error 1.79 main overwatch loop detected that the main loop timed out (POS:MQTT Cloud Upload, AWS MQTT POS: Find unsent data points): machine restarted
2022-11-17T17:42:54+00:00 Error 1.80.0 main main() loop detected that the overwatch loop timed out (POS: 6): machine restarted
2022-11-17T17:43:32+00:00 Error 1.80.0 WLANconnect Connecting to network failed - Type: OSError; Reason: the requested operation failed
2022-11-20T03:13:46+00:00 Error 1.80.0 main overwatch loop detected that the main loop timed out (POS:Cloud update device shadow): machine restarted
2022-11-20T20:50:17+00:00 Error 1.80.0 WLANconnect Connecting to network failed - Type: OSError; Reason: the requested operation failed
2022-11-21T06:46:00+00:00 Error 1.80.0 pressure Cannot read from pressure sensor - Type: TypeError; Reason: unsupported types for __add__: 'float', 'slice'
2022-11-22T04:38:08+00:00 Error 1.80.0 WLANconnect Connecting to network failed - Type: OSError; Reason: the requested operation failed
2022-11-22T22:43:33+00:00 Error 1.80.0 pressure Cannot read from pressure sensor - Type: TypeError; Reason: object of type 'slice' has no len()
2022-11-23T16:13:25+00:00 Error 1.80.0 pressure Cannot read from pressure sensor - Type: TypeError; Reason: object of type 'slice' has no len()
2022-11-24T06:42:40+00:00 Error 1.80.0 LTC2499 Reading ADC failed (POS:390) - Type: AttributeError; Reason: 'str' object has no attribute 'append'
Diese Daten korrelieren allerdings nicht mit den Neustarts des Gerätes. Mich macht schlicht stutzig, dass das Gerät so häufig neustartet - aus mir unersichtlichen Gründen.
Beispielsweise:
main overwatch loop detected that the main loop timed out (POS:MQTT Cloud Upload, AWS MQTT POS: Find unsent data points): machine restarted
Obige Fehlermeldung klingt für mich danach, dass das Gerät neugestartet wurde, weil ein Upload in the Cloud nicht möglich war. Warum sollte das Gerät dafür neustarten?
Mir stellen sich nun folgende Fragen:
Und eine Bitte: Wäre es möglich einen API Endpoint einzuführen, bei dem man die aktuellen Log-Daten auslesen kann oder ein Log-Forwarding (zB. an zentrale syslog-Server) zu implementieren?
Vielen Dank!
Viele Grüße
Steffen
Danke! Das macht nun tatsächlich viel mehr Sinn.
Im Changelog kann ich sehen, dass die Wertungen einzelner Sensoren im Gesundheits und Leisungsindex deaktiviert werden kann ("Die Wertung einzelner Sensoren bzgl. Gesundheits- und Leistungsindex kann deaktiviert werden.").
Leider finde ich keine Einstellungsmöglichkeit in der (Beta) App - wo finde ich das?
// Edit: Benutze ein Android Gerät