GW2000 Problem seit letzten Update...

[UrsulaB]

War falsch, du meintest so, oder?

[Gyvate]

richtig, muss natürlich beim WLAN Interface erfolgen, denn Dein Ehternet/LAN Interface ist ja nicht verbunden ...
Jetzt mal sehen, ob das Gateway weiter zickt ....
208.67.220.220 ist übrigens ein freier, providerunabhängiger DNS Server von OpenDNS.

[UrsulaB]

Ich halte dich am laufenden....

[Gyvate]

Es kann ja durchaus sein, dass der von Deinem Internetprovider standardmässig benutzte DNS Server überlastet ist und sich die Anfrage "festfrisst" - und dann klappt auch die Verbindung ins Internet nicht.
Oder dass der Ecowitt CDN Server überlastet ist ...

Zwischen Internetzugangspunkt und Zielpunkt kann viel passieren und auch schiefgehen, auf das der Benutzer keinen Einfluß hat und das nicht immer abgefangen werden kann.

[UrsulaB]

Hat ŵhl scheinbar schon mal so ein Problem gegeben:

https://www.wxforum.net/index.php?topic=46089.0

Aber leider gab es keinerlei Lösung...

Da hattest du ja seinerzeit auch mit debattiert

[Gyvate]

leider sind derartige Geschichten oft viel komplexer als vom Benutzer aus Symptomsicht angenommen. Und oft auch nur im Ergebnis ähnlich, aber nicht notwendigerweise in der Ursache. Auch Störquellen in der Umgebung können eine Rolle spielen und sind ggf. wenn das Fehlverhalten bemerkt wird, schon wieder inaktiv.
Andererseitis, wenn sich der Webserver des GW2000 aufhängt, kann das Posting und auch die Abfrage via API (--> CMX) durchaus weiterlaufen.
Mal sehen, was Ecowitt zu sagen hat - je nachdem werde sie noch ich auf ein mögliches Sich-Aufhängen des Webservers hinweisen - aber wenn es sich nicht nachstellen lässt ....
Szenarien, die sich nachstellen lassen, werden i.d.R. auch schnell von Ecowitt beseitigt.
- vielleicht kriegst Du ja ein Ersatzgerät und damit ist dann (hoffentlich) alles gut.

Und natürlich kann am Ende des Tages auch einfach das Gerät "einen Schuss" haben. Es genügt, dass ein verwendetes Bauteil vorzeitigt "verendet" oder nicht mehr richtig funktioniert. Etwas, was man bei der besten Qualitätssicherung nicht feststellen kann.
An der Sensoranzahl kann es ja bei Dir eigentlich nicht liegen, da Du da ja keine Heerscharen einsetzt.

[UrsulaB]

Also soll ich jetzt Ecowitt nochmal anschreiben, oder machst du das?
Oder was meinst du, soll ich jetzt machen.... einfach abwarten?

[Werner]

@UrsulaB

versuche es mal ohne CumulusMX oder prüfe die eingestellt MAC-Adresse dort.
Ich hatte ein ähnliches Problem, als ich Cumulus Mx (mit Ecowitt HTTP API) startete, konnte die WsViewPlus App nicht mehr auf das Gateway zugreifen, die Custom-Server Funktion lieferte keine Daten mehr, das lokale Web-UI hatte auch keinen Zugriff mehr.
Cumulus MX lieferte/zeigte aber alle Daten. Nach Beenden von Cumulus MX und notwendigen Neustarten des Gateways war wieder alles ok.
Die Ursache bei mir war eine falsche MAC-Adresse mit richtiger IP-Adresse eingestellt bei Cumulus MX.

[Gyvate]

Also soll ich jetzt Ecowitt nochmal anschreiben, oder machst du das?
Oder was meinst du, soll ich jetzt machen.... einfach abwarten?

probier mal Werners Hinweis aus - der Hund könnte tatsächlich dort begraben liegen.

Ansonsten habe ich das Problem bei Ecowitt eingestellt.
Das Zusammentreffen von Firmware-Upgrade und "Arbeitsverweigerung" könnte ggf. andere und sogar bei Ecowitt bekannte Ursachen haben.

Hast Du mal versucht, den Zugangspunkt (AP, HotSpot), das gateway-eigene WLAN (SSID: GW2000A-WIFIxxxx) zu aktivieren (Reset-Knopf ca. 5 Sekunden lang drücken). Ggf. ist der auch bereits aktiviert. Normalerweise bedeutet das dauernde Blinken, dass der Hotspot aktiv ist. Mit dem PC oder Smartphone sich mit diesem Netzwerk verbinden, den Hinweis auf "kein Internetzugang" ignorieren. Und im Webbrowser 192.168.4.1 eingeben. Wenn Du dann ins WebUI kommst, den Fritz!Box-Zugang nochmals aktivieren.
Wenn das Smartphone mit dem Gateway über sein WLAN GW2000A-WIFIxxxx verbunden ist, sollte WS View Plus auch funktionieren. Das Netzwerk 192.168.4.x ist natürlich aus Deinem lokalen Netzwerk normalerweise nicht erreichbar.

Dass sich das Ganze allerdings von Zeit zu Zeit wiederholt, ist komisch - aber vielleicht auf einen von Werner beschriebenen MAC/IP-Mismatch zurückzuführen.

[UrsulaB]

@UrsulaB

versuche es mal ohne CumulusMX oder prüfe die eingestellt MAC-Adresse dort.
Ich hatte ein ähnliches Problem, als ich Cumulus Mx (mit Ecowitt HTTP API) startete, konnte die WsViewPlus App nicht mehr auf das Gateway zugreifen, die Custom-Server Funktion lieferte keine Daten mehr, das lokale Web-UI hatte auch keinen Zugriff mehr.
Cumulus MX lieferte/zeigte aber alle Daten. Nach Beenden von Cumulus MX und notwendigen Neustarten des Gateways war wieder alles ok.
Die Ursache bei mir war eine falsche MAC-Adresse mit richtiger IP-Adresse eingestellt bei Cumulus MX.

Aber kann sich so etwas von alleine verstellen, Cumulus lief jetzt fast ein Jahr ohne Probleme....und meines Wissens ist die Custom Server Funktion bei Ecowitt ausgeschaltet.... Sorry aber so fit bin ich nicht in der Netzwerkwelt