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.

Aber auch mal was Positives... in meinem Unifi-WLAN mit 3 AP scheinen die WLAN-Instabilitäten von früher wirklich vorbei zu sein.

@Daniel-air-Q Ich kann den Fehler seit rc3 nicht mehr reproduzieren.

@Daniel-air-Q Ich kann den Fehler seit rc3 nicht mehr reproduzieren.

Science, der Rest per Email.

Aber auch mal was Positives... in meinem Unifi-WLAN mit 3 AP scheinen die WLAN-Instabilitäten von früher wirklich vorbei zu sein.

Es scheinen noch mehr Konfigurationsoptionen in userconfig.json nicht mehr zu funktionieren:

• RoomHeight
• RoomArea
• Rejection
• mqtt
• NightMode
• geopos
• country_code
• Altitude

Ich habe gerade Firmware 2.0 beta auf einem meiner Geräte eingespielt.

Da gibt es eine kleine aber hinterhältige Änderung, wie die Konfiguration des WLAN in der userconfig.json aussehen muss:

Vor Version 2.0 ging bei mir seit Jahren Folgendes:
"WLANssid": {
"meine_ssid": {
"WiFipass": "mein_password"
}
}

Das geht nicht mehr, es muss jetzt (in Übereinstimmung mit der Doku) so aussehen, sonst verbindet sich das WLAN nicht mehr:
"WLANssid": {
"meine_ssid": "mein_password"
}

In meiner Informatiker-Seele macht die alte Variante mehr Sinn, denn ein Beispiel aus der Doku ist:
"WLANssid": {
"Ihre WLAN-SSID": {
"WiFipass": "Ihr WLAN-Key",
"WiFibssid": "a0c86d65ee71"
}
}
und da verstehe ich meine alte Konfiguration halt nur als einen Sonderfall dieser Logik: nur Passwort, aber keine BSSID.

Peter

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.