"Token und Key pruefen" ist bei einem Connect-Timeout die falsche Spur #4
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Was passiert
Ist die Anlage nicht erreichbar (hier: stromlos), meldet der Dienst
in jedem Zyklus:
Der Grund steht zwar mit drin (
Connect timeout), die Handlungsanweisungverweist aber auf Token und Key. Bei einem Verbindungstimeout sind die noch
gar nicht im Spiel — die richtige Spur waere Strom, WLAN, IP-Aenderung,
Firewall oder VLAN.
check-configsagt in derselben Lage "Token/Key: gesetzt", was denWiderspruch noch verstaerkt.
Vorschlag
Nach Fehlerart unterscheiden:
Strom, WLAN, IP oder Firewall pruefen"
setup-midea)"Gefunden beim Durchspielen des Docker-Wegs mit v0.11.1.
Behoben in
57c395f(Hauptdienst 0.12.0). Die Meldung unterscheidet jetzt nach Fehlerart: Timeout/verweigerte Verbindung -> "Anlage unter : nicht erreichbar: ... Strom, WLAN, IP-Adresse oder Firewall/VLAN pruefen."; erst bei stehender Verbindung geht es um Token und Key. Weil msmart-ng Netzwerkfehler teils in eigene Exceptions ohne brauchbaren Typ verpackt (beobachtet: "Connect timeout."), entscheidet neben dem Typ auch eine Textpruefung - im Zweifel bleibt es beim Token/Key-Hinweis.