Ich tippe darauf, das Du es weg bekommst, wenn du in der Automower-Splitter-Instanz Zugriff testen auslöst.
Hintergrund (vermutlich):
die IO-Instanz ist ja ein WebSocket-Client. Der hat als Parametrierung den Access-token, also den temporären Zugriffschlüssel.
Der wird in der Splitter-Instanz (bei der Anmeldung) geholt und zyklisch aktualisiert. Nur wenn das mal nicht klappt, ist die IO-Instanz dann „fehlerhaft“, was ja in den Child-Instanzen ausgewiesen wird.
Durch das Zugriff testen wird implizit auch der Access-Token geprüft und ggfs. erneuter und in die IO-Instanz eingetragen.
Es kann aber sein, das Du dich neu anmelden musst.
Ich bin mir nicht sicher, du hast geschrieben, das du den Verbindungstyp geändert hast … und doch auch neu andügemeldet, oder?
Hatte ich auch schon versucht. Leider ohne Erfolg.
Nach der Umstellung auf Symcon-Connect habe ich mich angemeldet und die Verbindung bestätigt. Wurde auch ordentlich quittiert. Den Fehler mit der Schnittstelle hat es nicht behoben.
das Problem habe ich schon eine ganze Weile. Bin jetzt mal in den Beta gewechselt.
Wie ich mir immer helfe: Bei Typ zwischen Text und Binar umschalten. Dann öffnet sich die Schnittstelle wieder… Den Modulcode habe ich mir noch nie angesehen, wäre vllt. mal eine Option. Was halt stört: die Schalter sind ausgegraut…
PS: schön zu sehen, dass ich nach so vielen Jahren Symcon noch ein Junior bin ;-). Mit 2000 Variablen und 350 Skripten liege ich doch sicher schon im Mittelstand, oder
das ist immer so, wenn eine Schnittstelle vin einen Modul aus parametriert wird.
ein Reaktivieren der Websocket-Schnittstelle führt ja nicht wirklich zum Erfolg.
Bei dem kurzen Log von @timloe (debug3.log) ist zu sehen, das nach kurzer Zeit wieder ein Permission denied kommt. Das ist, nach dem was zu erkennen ist, keine Reaktion der Husqvarna-API.
Also eher was, was in dem IPS-System liegt
Und da das offensichtlich nicht bei jedem so ist, denke ich eher an das spezifische System.
Einen Modulcode der Websocket-Schnittstelle gibt es nicht, die ist zentraler Bestandteil des IPS
Na doch, wenn ich auf Typ Text oder Binary (Richtung ist egal) umstelle, dann will er ja die Änderungen übernehmen. Danach verbindet er sich wieder.
Habe jetzt ein Skript gemacht, welches 1x pro Minute den WS prüft und gegebenenfalls schließt und wieder öffnet. Na mal sehen, ob das was bringt.
Weiterhin habe ich in meiner Fritzbox noch die tägliche Trennung deaktiviert (war so eingestellt, gibt wohl provider die das regelmäßig tun / brauchen).
Ich werde berichten, wenn es nichts gebracht hat. Ansonsten hat es sich damit gelöst.
// Prüfen, ob die Verbindung aktiv ist
$isActive = IPS_GetProperty($wsckID, „Active“);
if (!$isActive or $Status <> 102)
{
echo „Die WebSocket-Verbindung ist nicht aktiv!\n“;
// Versuch, die Verbindung neu zu starten
IPS_SetProperty($wsckID, "Active", false);
IPS_ApplyChanges($wsckID);
IPS_Sleep(500); // Sicherheitswartezeit
IPS_SetProperty($wsckID, "Active", true);
IPS_ApplyChanges($wsckID);
echo "Die Verbindung wurde neu gestartet.\n";
} else {
echo „Die WebSocket-Verbindung ist aktiv.\n“;
}
das ist ja eben die Frage. das die io temporär wieder geöffnet wird, ist ja klar.
bei dem debug von @tinloe kamen ja keine nutzdaten sondern nur regelmäßig das „permission denied“
und ohne nutzdaten auf der websocket gibt es nur daten beim zyklischen abruf.
und häufige, aktive, abrufe werden von miele nicht gewünscht
Miele? Du meinst Husqvarna. Oder hat sich Gardena jetzt auch Miele unter den Nagel gerissen?
Bis jetzt geht es. Permission denied hatte ich ja nicht. Die Verbindung war halt unterbrochen und durch den Workaround des Typ-Wechsels in Verbindung mit dem Änderung übernehmen hat er sich wieder verbunden.
Was ich festgestellt habe. Trotz des 10 Minuten Abfrage-Intervalls aktualisiert sich der Längen und der Breitengrad alle 30 Sekunden. Woran liegt das? Ich habe Angst, dass sich damit die 10.000 Abrufe im Monat sehr schnell aufbrauchen. Hatte im letzten Sommer das Gefühl, dass sich wegen der Nutzung der API die eigentliche Husqvarna-App auch nicht mehr aktualisiert. Wird das auch auf die 10.000 angerechnet?
ah sorry, natürlich Husqvarna.
Miele hatten fast Zeitgleich auch auf Ereignis-getriebenen Kommunikation umgestellt, die benutzen aber SSE (Server-Sent-Events).
ok, ich hatte das angenommen, weil du ja eingangs geschrieben hast
das Problem habe ich schon eine ganze Weile
und da dachte, es wäre das gleiche
Was ist denn dein Problem, warum er deaktiviert? Vielleicht kann man da ja systematisch was dran machen?
Nun, ich nehme an, du bekommst die Änderungen über die WebSocket. Ein Blick in den Debug der IO-Instanz zeigt es, die Meldungen sind gut identifizierbar; natürlich nur, wenn sich beim Mäher was tut, also i.d.R. wenn er mäht.
In den Ruhezeiten meldet er nur wenig, weil sich ja nix ändert.
Und diese WebSocket-Meldungen werden nicht angerechnet, das bezieht sich auf aktive Anfragen und Befehle.
Vielen Dank für die Erläuterung. D.h. die Position (z.B.) wird als quasi „push Nachricht“ vom Mäher / Server an das WS gesendet. Ok. Verstanden. Habe es im Debug des WS angesehen.
Was ist dieses PING - PONG? Genau 1x pro Minute. Eine Art Keep Alive? Oder Lebenszeichen? Geht das auch vom Server aus?
Achso: Ich bekomme als Warnung im Status-Log:
06.04.2025, 06:41:15 | AutomowerConnectDevice | decode_restrictedReason: unknown value „ALL_WORK_AREAS_COMPLETED“
Das sollte sicherlich im Modulcode noch nachgebessert werden.
Verbindung besteht noch. Ich zeichne jetzt mal mit, ob und wann ein Reconnect durch das Skript erfolgt ist. Dann können wir der eigentlichen Ursache vllt. noch besser auf den Grund gehen.
Ja, ist ein keep alive. Muss vom IPS gemacht werden, sonst würde die Verbindung (IPS → Husqvarna) nach einiger Zeit wieder zu sein und es kämen keine Nachrichten.
ja, die Inhalte dieses Feldes ist leider in der API-Dokumentation nicht wirklich beschrieben und müssen daher beim Auftreten nachgepflegt werden.
Bei mir bringt das Script leider nichts. Die Instanz lässt sich so nicht wieder aktivieren. Die Änderung von Text auf Binär und zurück mit entsprechenden Speichern bring hier auch kein Erfolg.
Bei mir hat das Skript in der Nacht bis jetzt ca. 5…6x die Verbindung wieder hergestellt.
Warum es bei mir abbricht, weiß ich allerdings noch immer nicht. Im normalen Log der Meldungen unter var/log/symcon ist nichts zu finden
@demel42: vielen Dank fürs Update! Ich lasse den Mäher gerade laufen, wenn er fertig ist, werde ich sehen, ob es hinhaut.
Jetzt muss ich mir nur noch ansehen, wie man den Mäher mit Symcon steuern kann. Aber heute nicht mehr, jetzt ist erstmal Garten Wetter!
Einmal auf „Zugriff Testen“ im Splitter hat das Problem gelöst.
Also so richtig weiß ich „nicht was ich tue“. Fühlt sich alles etwas nach „ringsherumbasteln“ an.
Ich werde in mein reconnect-Script noch das „Zugriff Testen“ einbauen.
Allerdings sollte das Modul doch diese Probleme selbst erkennen und lösen.
Naja, bin ja froh, dass es das Modul überhaupt gibt. Ist ja das einzige überhaupt.
So schön wie ich Symcon finde, die Verbreitung ist halt recht übersichtlich im DACH-Raum, damit die Community sowie die Entwickler auch. Scripte habe ich reichlich, stellenweise auch komplexer Natur. Module daraus zu machen übersteigt meine Fähigkeiten (ok, kann man lernen) und vor allem meine Zeit. Ich spende daher auch immer, wenn ich ein Modul von jemandem installiere, der die Amazon oder Paypal-Spendenknöpfe anbietet.
Es ist zu befürchten, dass HomeAssitent oder ähnliches an uns vorbei gehen werden…
Bereich leer? Da steht doch die Authorization drin
Ok, die Meldung sagt, das der DNS-Zugriff nicht funktioniert hat - der Geht ja von dem Modul/IPS-System über dein System zum Internet. Irgendwo auf dieser Kette wurde der Hostname api.amc.husqvarna.dev nicht ausgelöst. Kommt mal vor, liegt a bei i.d.R. an dem lokalen System/Router (der die DNS-Abfragen ja weiterleitet)
Tut es in der Regel auch, aber solchen lokalen Netzprobleme können nicht immer abgefangen werden.
Naja, das tut es auch ziemlich häufig. Das nicht mehrere Leute das gleiche Thema bearbeiten finden ich aber auch nicht verwunderlich, eigentlich auch sinnvoll
Nuja, da kann man unterschiedlicher Meinung sein. in HA finde ich sicherlich viele Module, ich hole mir da auch häufiger Anregungen. Aber wenn es ein Problem gibt, gibt es das auch häufig genauso da.
Und da das ganze ja ziemlich international aufgestellt ist (oder besonders halt US), gibt es mal Reaktionen und mal nicht.
Aber da hat sischerlich jeder selber eine Meinung zu
Die Authorization stand halt nicht mehr drin. Tabelle war leer. Kam erst beim „Zugriff testen“ wieder.
Die ggf. lokale Störung war ja schon fast eine Stunde vorbei. Und bei „Zugriff testen“ ging es sofort wieder und der Eintrag kam zurück.
Single Source ist selten gut. Wenn Du z.B. keine Zeit oder Lust mehr hast, ist das Thema tot.
TASMOTA ist so ein Beispiel. Da hat die Community das Thema übernommen. zum Glück.
Und die Entwicklungen der KI machen es auch nicht besser. Fragen, die oft durch den Informationsaustausch in Communities wie dieser erörtert, idR. gelöst und vor allem dokumentiert werden, fallen durch den Dialog mit Chat GPT weg. Nur die KI behält das Wissen (für sich).
So, dann schaue ich mal, wie ich das „Zugriff testen“ noch implementiere…
PS: gefunden: IPS_RequestAction($SplitterID, „TestAccount“, „“);
Der Splitter reagiert sofort, wenn die IO-Instanz einen Fehler hat und versucht wieder eine gültige Authorization zu erzeugen/zu setzen.
Wenn „Authorization“ leer war, kann es eigentlich nur bedeutet, das der Splitter zu diesem Zeitpunkt auch keinen Token erzeugen konnte und daher die „Authorization“ gelöscht hat. Und das dürfte bedeuten, das das DNS-Problem noch bestand.
Das ist schin ein spezifischen Problem; vermutlich kann man ausschliessen, das der öffentliche DNS-Server ein Problem hat (da habe ich jedenfalls noch nie von gehört) und sicherlich nicht immer wieder.
Dann würde ich vermutlich eher mal in dem internen Netzwerk überprüfen, ob es dafür einen Grund geben kann.
Da ist sicherlich so. Allerdings … wenn du dir in HA mal die hinter den Adaptern steckenden Quellen anschaust wirst du sehen, das es häufig (natürlich nicht immer) auch nur eine Person ist, die das betreut. Ich bin häufiger bei den diversen Smarthome-Systemen unterwegs und natürlich auch bei HA um zu sehen, wie bestimmte Problem da gelöst werden. Und da sehe ich manchmal auch, das Fehler lange unbearbeitet bleiben oder jemand dann doch das GitHub-Projekt clont und sich damit beschäftigt.
Und genauso ist das diesbezüglich bei Symcon: alle Module liegen im GitHub vor und es ist ja jedem überlassen, das zu clonen und weiter zu entwickeln. Das ist dann damit zwar nicht im Modulstore, aber man kann die Module ja genauso auch direkt aus dem GitHub einbinden.
Natürlich; KI ist dafür völlig unbrauchbar. Wie soll KI ein neues, i.d.R. unbekanntes Protokoll (die in der Regel auch nicht öffentlich sind) herausfinden, verstehen, was ein Anwender so will und das Ergebnis dann auch noch mit einer physischer Hardware testen?
