Der Timer ist auch gelaufen, hat aber jedesmal in einem Fehler geendet. Zugriff testen brachte zwar einen Zugriff aber er hat keine Daten vom Automower geholt.
Irgendwie schräg, aber wie gesagt der Neustart hat alles gelöst!
lg
hagi
Habe gestern auch geupdatet……bisher keine Probleme!
1 „Gefällt mir“
Hallo Demel,
hab da probiert! Leider tut sich garnichts bzgl dem Mäher, wenn ich auf den Knopf drücke (im Debug allerdings sehe ich dass was geschickt wird).
Kann ich sonst nochwas probieren
Gruss
Tobias
ne, war nur ein Versuch. Dann weis ich (noch) nicht, wie die das in der App auslösen.
Ich werden dem API-Support mal eine Mail schreiben…
Seit kurzer Zeit bekomme ich bei meinem 435X immer wieder den Fehler „manueller Eingriff erforderlich“ meistens zwischen dem nach Hause fahren und dem Laden und nur für ein paar Sekunden und dann ist plötzlich wieder alles gut. Kann aber auch schon mal 1-2 Stunden dauern bis er sich wieder einkriegt. Hat das irgendjemand anders auch beobachtet?
Ist bei mir, beim 550 Epos auch so. Tritt seid dem Update auf. Kann natürlich Zufall sein.
Tom
meint ihr, das der Fehler im Modul auftritt?
Dann brauchen ich ausreichend lande Debugs von der Device-Instanz und dem (genauen) Zeitpunkt, wann das aufgetreten ist, damit ich das im Log wiederfinde.
Was sagt die Husqvarna-App zu diesem Zeitpunkt?
Hallo zusammen
Ich habe ein Problem dem Modul und Symcon 7.0, weiss aber nicht ob das Problem vom Modul herkommt oder von der 7.0.
Ich habe am Wochenende auf Symcon 7.0 upgegraded und danach ging plötzlich das Licht nicht mehr an.
Ich habe dann festgestellt, dass im WS Client vom Deconz Modul die wss adresse von husqvarna drin stand, und Fehler tauchten auf dass 2 instanzen auf den WS client zugreifen.
Ich habe darauf das Automower Modul deinstalliert und neu installiert, worauf alles gut aussah. Danach habe ich auf den Beta kanal gewechselt und und die AutomowerConnectConfig kapert sich erneut den WS Client von Deconz.
Ich bin wieder zurück auf der Stable, habe reinstalliert, aber die Verbindung zum WS Client bleibt.
Jetzt bleibt mir nur, das Modul zu entfernen, sonst kann ich das Licht nicht schalten (den Mäher brauch ich ja mal die nächsten paar Monate nicht 
)
Gruss
pelota
Nun ja, der Einsatz des WS-Client ist ja Bestandteil der neuen Version des Moduls, das aber zZt nur im Beta-Kanal ist. Steht ja auch so in der Beschreibung.
Was meint „WS Client von Deconz“. Ist das eine spezielle Anwendung?
Eigentlich macht der ein eigene WS-Client.Instanz auf. Ggfs. musst Du eine eigene WS-Instanz anlegen und in der Splitter-Instanz (AutomowerConnectSplitter → die frühere AutomowerIO-Instanz) diese als Gateway eintragen.
Was die Module selbst angeht, so wäre es natürlich ganz wichtig zu wissen, warum die Module „rot“ sind, sprich was der Fehler ist,. Kannst du die Instanzseite denn nicht öffnen - das steht dann der Fehler im Klartext?
Bei allen meinem Moduls ist bei Updates mit Änderung an Einstellungen/Daten etc auf der Instanzseite das Update dieser Daten zu initiieren.
Was mich schon wundert ist, das eine IO-Instanz unterhalb einer anderen IO-Instanz steht und darunter dann ein Konfigurator. Das sind doch unterschiedlichen Typen und daher in unterschiedlichen Kategorieren zu finden?
Ich rede hier vom Deconz Modul von Silberstreifen. Der erstellt ja auch einen WS-Client.
Wenn ich die Beta vom Automower Modul installiere, erstellt dieser nicht wie erwartet ein WS Client, sondern hängt sich an das bestehende vom Deconz Modul (siehe oben den screenshot der pysikalischen Baumansicht).
Ich hätte doch erwartet, einen neuen WS Client zu sehen, aber dem ist nicht so. Kann es einem GUID clash liegen (beine Module nutzen selbe IDs)? Oder ist da ein Bock in Symcon selbst?
Hmm, ein Bock im Symcon vermute ich ja nicht.
Ich hatte noch nicht das Problem, das ich eine System hatte, das schon ein WS-Client hatte. Ich muss mal schauen, ob man da zukünftig was verbessern kann, aber einstweilen ist die beste Möglichkeit, von hand ein Ws-client anzulegen und im Splitter das anzugeben.
Der Parametriert dann bei nächste Gelegenheit den WS-Client.
Der „feindlich übernommene“ Devons-WS-Client muss dann vermutlich neu parametriert werden.
Vielleicht kann ich dir da helfen, ich denk ich hab was gefunden:
In deinem Code verwendest du $this->ConnectParent
Gemäss Doku:
Die Funktion verbindet die Instanz mit einer vorhandenen übergeordneten kompatiblen (Parent) Instanz. Sollte diese nicht vorhanden sein, wird diese erstellt und anschließend verbunden.
Hingegen gibts noch die RequireParent:
Sofern keine Verbindung existiert, wird eine übergeordnete Instanz mit der GUID ÜbergordneteGUID erstellt. Selbst dann, wenn eine kompatible übergeordneten Instanz vorhanden wäre.
Ja, das ist korrekt. Mir ist nur irgendwie, als wäre ich damit seinerzeit bei der Umstellung auf ein Problem gestossen. Ist schon etwas her, daher werde ich das vermutlich aus meine Hirn nicht mehr extrahieren können.
Ich muss versuchen, ob ich den damaligen Zustand nochmal herstellen kann … mhh denk grübel …
aber vielleicht habe ich mich damals auch nur vertan.
Hast du das bei dir schon umgestellt? Sonst würde ich eine Version mit RequireParent machen und mit der könntest du die Umstellung nochmal probieren.
Ja, ich habe den WS Client von hand erstellt und den splitter umgebogen…
Funktioniert - wahrscheinlich (weiss nicht genau, mein Gartengehilfe ist im Winterschlaf). Zumindest clashts z.Z nicht mit dem anderen Modul.
Ich habe einen neuen Fehler (glaube ich). Ich habe zwei Automower an meinem Account und die GPS Daten etc werden auch fein säuberlich auseinander gehalten, so dass in der jeweiligen Instanz die korrekten Koordinaten ankommen. Die Daten von „letzter Fehler“ werden allerdings irgendwie zwischen den Instanzen durcheinander gebracht. @demel42 : Könntest Du mal gucken was da los ist? Wenn Du keine zwei Mäher hast, könntest Du Dich auch gerne per Teamviewer oder so in meine Installation reinklinken.
Herzlichen Dank
gros_ibou
kann ich gerne machen, die nächsten Wochen sind aber eher schlecht.
und dann ist vielleicht winterpause?
egal, wenn ich mich nicht melde, dann erinnere mich gelegentlich nochmal
Ok. Ist ein bisschen kompliziert, da die eine Installation in Italien (bei meinem Bruder) ist und die andere in Deutschland. Bin gerade in Italien und kann hier testen. Aber keine Eile ist jetzt auch nicht wirklich entscheidend, denn ich kann von Hand rausfinden wo der Fehler aufgetaucht ist anhand von GPS Koordinaten.
Gruß
gros_ibou
du könntest natürlich mal ein ausreichenden Debug von allen Instanzen (incl. Websocket) machen mit zweckdienlichen Informationen.
Vielleicht sehe ich ja was schon daran.
So wie ich das im Kopf habe, ist immer das Device in den Nachrichten mit drin, aber vielleicht (wahrscheinlich) übersehe ich da noch was.
Ok, mache ich. Allerdings ist der deutsche Automower im Winterschlaf. Schicke aber trotzdem den Debug von beiden
Apropos Winterschlaf, könnte man da auch ne Funktion/Schalter einbauen. Ich habe meinen nun auch eingemottet und die jeweiligen Apps auf inaktiv geschaltet. Könnte man das nicht „geschickter“ machen? Nur ne Idee…
schönen Sonntag und Gruß Michael