Ein kleiner Verbesserungsvorschlag: Bisher meldet sich ein Gerät bei dem lokalen DHCP server mit dem generischen Namen "espressif" an. Vielleicht können Sie es einreichten, dass zukünftig der in der Konfiguration definierte Devicename verwendet wird. Das würde eine Identifikation, insbesondere bei mehreren Geräten in einem Netz sehr hilfreich machen.

@Daniel-air-Q danke! Mit rc6 klappt das Einbuchen ins WLAN wieder.

Als Workaround nutze ich jetzt die EditThisCookie Extension auf Chrome, um das Posthog Cookie zu unterdrücken. Mal sehen, ob das irgendeine Auswirkung auf meine Software, insbes. Graylog hat.

Meine weiteren Forschungen ergaben, dass das Graylog-UI beim Login ein Posthog-Cookie setzt, und dieses Cookie killt dann meinen Zugriff auf das Web-GUI von air-Q, bis ich alle Cookies löschen.

@Merlin-air-Q Da anzunehmen ist, das Graylog nicht die einzige Software ist, die sowas macht, wäre ich natürlich an einem Fix gem. der Idee von @Micha sehr interessiert.

@Merlin-air-Q danke. Ich hab schon befürchtet, dass sich das nicht so einfach reproduzieren läßt, es scheint mit dem Setup meiner beiden Macs zu tun zu haben.

Ich habe alle Cookies im Chrome vom air-Q gelöscht, aber die Reaktion bleibt die gleiche.

Allerdings habe ich jetzt mit etwas Aufwand rausgefunden, dass das Problem von einem Posthog-Cookie kommt. Es fängt mit "ph_phc_" an und ist elendig lang. Ich vermute, dass sich daran der HTTP Server auf dem air-Q verschluckt und den Fehler generiert. Ich denke, dass sich das mit einer Config-Änderung auf der air-Q Seite, wie von @Micha beschrieben, beheben liesse (es gibt einige Hinweise im Netz dazu).

Ich hab jetzt alle Browser-Cookies gelöscht und plötzlich verschwindet mein Problem. Bisher weiss ich nicht, wer dieses Posthog-Cookie setzt und warum es beim Löschen der air-Q Cookies nicht mit verschwindet. Ich hab jetzt mal Third Party Cookies komplett abgeschaltet. Vielleicht taucht das Problem nicht mehr auf.

Ich nutze macOS und will auf meine AirQ per Browser zugreifen.

Bei Safari und Chrome kommt im Standard-Modus die Fehlermeldung "Header fields are too long for server to interpret".

Wenn ich den anonymen Browsing-Modus verwende (will ich dafür aber eigentlich nicht), geht es bei beiden Browsern.

Ich denke, dass muss im Code gefixt werden? Cookies löschen ist für mich keine Option.

@Daniel-air-Q danke! Mit rc6 klappt das Einbuchen ins WLAN wieder.

Mit Version 1.80.0-rc4 kann sich mein airQ nicht mehr sauber zum WLAN verbinden, nach Rückstieg auf 1.79 geht es wieder...

2022-11-08T13:42:40+00:00 Error 1.80.0-rc4 WLANconnect Connecting to network failed - Type: OSError; Reason: the requested operation failed

Es findet ein initialer Kontakt mit meinem DHCP-Server statt, und es geht u.U. auch ein ping durch, aber dann ist Stille, und die untersten LED links und rechts werden lila (?).

@micha Genau das gleiche hab ich auch und mir reicht das. Mit war nur wichtig, dass ich unterschiedliche Namen pro Gerät habe, ob es der Hostname ist, ist für mich sekundär, so bekomme ich die Identifikation hin.

Mit Version 1.75 ist das Thema Hostname bei DHCP erfolgreich gelöst. Ich bin begeistert. Danke!

Ein kleiner Verbesserungsvorschlag: Bisher meldet sich ein Gerät bei dem lokalen DHCP server mit dem generischen Namen "espressif" an. Vielleicht können Sie es einreichten, dass zukünftig der in der Konfiguration definierte Devicename verwendet wird. Das würde eine Identifikation, insbesondere bei mehreren Geräten in einem Netz sehr hilfreich machen.

Ich habe zwei Geräte mit der Science-Option (zumindest laut Bestellung, Rechnung, und Preis). Beide mit Version 1.69.

Eines zeigt bei type: in der Device Info "airQ Science", das andere "airQ Pro" -- ist das ein Problem?

Danke,
Peter