Zugriff auf Webinterface mit PC nur nach Neustart - Raspberry geht immer

Hallo Community, die Fehler der letzten Tage wurden hoffentlich behoben. Entschuldigt den Umstand! Viel Spaß weiterhin. Lg
  • Hallo zusammen,

    heute mein erster Beitrag, obwohl ich schon seit Monaten passiv mitlese.

    Ich bin mir sicher, dass es zu meinem Problem schon irgendwo einen Thread geben muss, weil ich nicht glauben kann, dass ich der einzige mit diesem Problem bin. Bitte habt Nachsehen aber ich suche schon seit Tagen.

    Ich habe einige Sonoffs und NodeMCUs mit Tasmota in unterschiedlichen Versionen (von irgendeiner 6er bis zur neuesten) im Einsatz. Das Problem ist bei allen dasselbe. Meine Netzwerkinfrastruktur besteht aus UniFi-Geräten.

    Auf das Webinterface der Geräte hatte ich mit meinem Android Smartphone noch nie Zugriff. Das ist nicht so schlimm, ich hätte aber auch nichts dagegen, wenn wir das gleich mit lösen. Dass es an einer Firewalleinstellung liegt glaube ich eher nicht, weil ich ohne Weiteres mit dem Smartphone auf meinen Raspberry, also z.B. den ioBroker zugreifen kann.

    Von dem Raspberry habe ich auf das Webinterface aller Tasmotas jerderzeit uneingeschränkt Zugriff.

    Vom PC aus komme ich auf das Webinterface (gefühlt) für 30 Minuten nach dem Start, danach bekomme ich "ERR_CONNECTION_TIMED_OUT". Ich habe es mit verschiedenen Browsern probiert. Was mir dann hilft, ist mich von dem Raspberry aus einzuloggen und den jeweiligen Tasmota neu zu starten, oder im UniFi-Controller den reconnect-button zu drücken. Sofort habe ich wieder Zugriff, aber eben nur für ca. 30 Minuten.

    Vor zwei Wochen ging es mit dem PC noch wunderbar, mit dem Smartphone wie gesagt noch nie.

    Ich weiß nicht, ob es mit dem UniFi-Controller zusammenhängen kann, ich habe diesen vor ein paar Tagen von einem Raspberry 3 auf einen 4er umgezogen. Auf dem 4er läuft gleichzeitig der ioBroker. Auf dem Weg ist auf diesen Raspberry auch mein pi hole mit umgezogen. Daran kann es eigentlich auch nicht liegen, wenn ich den DHCP Name Server im UniFi wieder auf Auto schalte und meinen PC neu verbinde, bleibt das Problem bestehen.

    Mehr fällt mir nicht ein, was ich noch schildern könnte. Wenn ich noch Informationen liefern kann, mache ich das natürlich gerne.

    Ich danke Euch schon einmal, dass Ihr mein Problem gelesen habt!

  • mit Tasmota in unterschiedlichen Versionen (von irgendeiner 6er bis zur neuesten) im Einsatz.

    Da kannst du mit den vermutlich besten Erfolgsaussichten anfangen: Bringe alle Geräte auf einen - am besten gleichen - Firmware-Stand. Es gab in der Tat in den höheren 6.x- und ersten 7.x-Versionen vermehrt Wifi-Probleme. Bringe alles auf aktuellen Master-Stand bzw.Develop-Version, falls nicht gerade Wifi-Probleme gemeldet werden.

    Ich weiß nicht, ob es mit dem UniFi-Controller zusammenhängen kann,

    Das kann man aus der Entfernung auch schlecht beurteilen. Im allgemeinen haben die Geräte einen guten Ruf. Wie ist denn deine logische Wifi-Infrastruktur? Sind die Geräte als Repeater oder als Access-Points konfiguriert? Arbeitest du mit DHCP oder haben deine Geräte "echte" feste IPs (also keine IP-Reservierung im Router, sondern eine dem Gerät fest eingegebene IP.) Welchen WiFiConfig-Modus hast du eingerichtet? Geben die Konsolenprotokolle der Geräte etwas her? Hast du eine Hausautomationssoftware (IOB, Domoticz) im Einsatz. Was melden dann deren Log-Files?

    Möglicher Weg, um an eine Lösung zu kommen: Gibt es bei bestimmten Routern oder Endgeräten auffällig wenig Störungen? Wie sind die konfiguriert? Unterscheiden die sich von den anderen und worin?

    Arbeites du mit Teilnetezen? Passt dann alles mit den Gateways?

    Wie rigide ist PiHole konfiguriert? Ein bisschen "Internet" brauchen die Tasmotas schon, z. B. wg. NTP oder arbeitest du mit einem lokalen NTP-Server?

    Du siehst: Eine Menge Fragen (was alles versteckte Hinweise sind :)) und eine vielschichtige WiFi-Infrastruktur, die du betreibst, die leider dann auch viele Möglichkeiten für Störungen bietet.

    Keine Lösung aber ein für fast alles funktionierender Workaround: Mach dich mit MQTT gut vertraut (und eigenständigen Konsolen- oder grafischen Clients). HTTP-Probleme bzw. Web-Interfaceprobleme mit Sonoff/Tasmota hatte ich ich auch immer mal wieder, aber das MQTT-Protokoll ging "immer" und sei es, dass es nur für das Absetzen des Kommandos restart 1 an das "unerreichbare" Gerät diente, um es wieder wachzurütteln.

  • Ich weiß nicht, ob es mit dem UniFi-Controller zusammenhängen kann, ich habe diesen vor ein paar Tagen von einem Raspberry 3 auf einen 4er umgezogen.

    ich habe ebenfalls ein UniFi System und den Controller als SW auf dem Raspberry installiert. (Kein HW Controller). Keine Probleme.

    Evtl ist beim Umzug etwas mit der DHCP Vergabe passiert, bei mir macht das nicht der Controller sondern immer noch die FritzBox.

    Hast du beim umziehen da beide aktiv als DHCP server ?

    grüsse aus Heidelberg

    ca. 100 Tasmota Geräte teilweise mit SML Script.

    Home Assistant, Alexa, Sonos, (Pilot APP zur Steuerung, Domoticz (auslaufend))

  • Ich danke euch beiden für die Ausführungen!

    Scheinbar habe ich den Fehler gefunden! im "Wireless Network" war die Option "Block LAN to WLAN Multicast and Broadcast Data" aktiviert.

    Seitdem ich den Haken entfernt habe läuft alles, auch von dem Smartphone...

    Ich habe noch nicht ganz kapiert, was die Option macht. Seltsam ist jedenfalls, dass die Option auch schon vor dem Umzug aktiviert war und es da ja zumindest vom PC immer funktioniert hat. Seltsam ist auch, dass sich jetzt, wenn ich die Option wieder aktiviere weitere Optionen aufklappen, die vorher nicht da waren. <-- Ist zu verstehen, was ich meine? Scheint mir ein Bug zu sein.

    Wie auch immer, ich lasse die Option deaktiviert und melde mich, falls es doch wieder zu Problemen kommt.

  • Block LAN to WLAN Multicast and Broadcast Data

    Das bedeutet wohl, das bestimmten Anfragen in solche Netze blockiert werden. Broadcast Data sind normalerweise unspezifische, nicht an ein einzelnes Gerät adressierte Pakete in ein Netz, deren Ziel es ist, dass ein Gerät, dass sich angesprochen "fühlt", darauf antwortet. So interpretiere ich das...