Wie in folgendem Ausschnitt zu sehen, löst ein Homeegramm die Aktion aus und sendet an Gerät wc den Befehl Schalter 2 aus, bekommt vom Gerät aber leider den Zustand Schalter 2 an zurückgemeldet.
Der Gerät ist ein FIBARO System FGS223 Double Relay.
Was soll ich in solchen Fällen tun ? Für mich sieht es so aus, als habe das Gerät den Befehl nicht „verstanden“. Doch eine Fehlerbehandlung in Homeegramme einzubauen als Benutzer scheint mit komplett aussichtslos.
Das heißt, dass homee vom Gerät keine Bestätigung für den Schaltvorgang bekommen hat. Meist hat der Aktor den Befehl auf Grund von Empfangsproblemen nicht bekommen und daher keine Quittung geschickt.
Ich habe mir angewöhnt, bei wichtigen Schaltvorgängen (Gartenbewässerung usw.) das homeegramm wie folgt aufzubauen:
(Beispiel Licht am Taster einschalten)
HG
Auslöser: WENN Taster wird eingeschaltet
ODER WENN das HG abgespielt wird
Bedingung: UND WENN Lampe ist ausgeschaltet beim Auslösen
Aktion: DANN Licht einschalten
UND DANN spiele HG ab mit einer Verzögerung von x Sekunden
Damit wird das HG so oft abgespielt, bis das Licht angeschaltet meldet.
Wäre mir immer noch zu unsicher, vor allem wenn es um Wasser geht, das dann unkontrolliert fließt.
Bei der Bewässerung nutze ich das automatische ausschalten der Fibaro UP-Module.
Also, im Grunde, eine selbstgestrickte Fehleraufrollung. Nicht gerade die Lösung, auf die ich gehofft hatte; aber danke sehr für den Beispiel-Code, der inspiriert schon einmal !
Eine robustere Kommunikation/besseres Fehlerhandling soll ja Teil des neuen Z-Wave-Stacks sein.
Aber wenn das Gerät nicht/nie erreicht werden kann, hilft das natürlich alles nix und man muss bei kritischen Aktionen irgendwie eine Fallback-Lösung einrichten
Ich denke, das Händling mit so einer Situation sollte eine Standardfunktion eines Schaltvorgangs sein . z.B. ein Schalter im Gerät und wenn der gesetzt ist macht Homee entsprechende Wiederholungen mit vorgegebener Anzahl wenn keine positive Meldung kommt.
So werden sonst Homeegramme unnötig kompliziert. Dabei sollen sie doch so einfach wie möglich bleiben.
Das entsprechende Fehlerhandling ist ja bereits Teil des Protokolls (Z-Wave).
Aber man hat eben festgestellt, dass dies oft nicht ausreicht. Das ist, soweit ich mich erinnere, genau der Punkt, an dem der neue Z-Wave-Stack Verbesserungen bringen soll → zusätzliches erweitertes Fehlerhandling & Kommunikationsoptimierung auf homee-Ebene.
Genau, an der Stelle wo das Protokoll offensichtlich versagt, muss Homee eingreifen. Und erst wenn Homee da selbst nichts machen kann, kann man selbst noch Absicherungen vornehmen. Aber vorher sollte da Homee auf so eine Situation reagieren.
Noch mal (wir haben uns wohl missverstanden): Das tut er doch - er schickt die Signale MEHRFACH (auf Protokollebene) und hält im Tagebuch (Applikationsebene) fest, dass das Gerät (nach diesen mehrfachen erfolglosen Schaltversuchen) als Status einen anderen zurückmeldet.
Was ist denn Deine konkrete Erwartung? Eine Pushmeldung mit der der homee petzt, dass der böse Aktor nicht das gemacht hat was er ihm gesagt hat? (etwas zynisch gesprochen)
So läuft es…
Protokollebene:
homee sendet X (notfalls mehrfach in einer bestimmten Zeit unter Beachtung des Duty Cycles, wenn er keine Rückmeldung bekommt)
Applikationsebene:
homee protokolliert im Tagebuch den Schaltversuch (mit dem ersten Versuch)
Weiter auf der Protokollebene:
homee fragt nach einiger Zeit (in der er keine Rückmeldung vom bösen Aktor bekommen hat) den Status ab, es kann ja auch die Rückmeldung auf dem Transportmedium Luft durch eine Kollision oder ähnliches nicht gehört worden sein.
Wenn es gut läuft (evtl. ist das Gerät wieder erreichbar, das shared Medium Luft war wieder frei, etc.) dann antwortet der Aktor mit einem Status der auf Applikationsebene im Tagebuch vermerkt wird. Wenn er nicht antwortet, dann halt nicht. Wenn sich der Aktor eine längere Zeit überhaupt nicht zurückmeldet wird er auf der Applikationsebene ausgegraut und ein gröberes Problem liegt vor.
Wo steht, dass er es wie oft probiert hat? … Die Situation dass ein Gerät irgendwie nicht reagiert oder Homee nicht auf das Gerät reagiert weil irgendwas in der Funkverbindung nicht klappt haben wir doch Medium-bedingt immer wieder und nicht selten.
Dadurch kommt der Eindruck, das was mit Homee nicht stimmt. Aber Homee kann mit Sicherheit selten etwas dafür. Er ist aber der Controller und kann mir detailliert dazu Infos geben und wenn es sein muss auch andere oder gar nochmal wiederholte Aktivitäten auf Applikationsebene durchführen, die mit dem Protokoll auf unterer Ebene erstmal nichts zu tun haben.
Also mal weit weg vom Homeegramm sondern vereinfacht dargestellt:
Ich schalte in der App ein Licht an,… es passiert nichts
Homee weiß natürlich dass man auf Protokollebene sicher nochmal probieren muss und tut das automatisch bis zum „Timeout“
Homee gibt auf und macht nichts mehr
Homee fragt dann regulär den Status ab
das Licht meldet dann weil es wieder erreichbar ist es sei aus
Währenddessen oder auch hinterher schalte ich mehrfach das Licht an und aus bis ich den gewünschten Zustand habe.
Im Homeegram müsste ich solche Fälle vorsehen, damit es automatisch passiert und verkompliziere das Homeegram, welches vielleicht schon ohnehin kompliziert ist, um diese Fälle.
Wenn mir aber Homee als Werkzeug an die Hand gibt, dass ich an einem Gerät welches nicht reagiert dennoch den Schaltvorgang auf Applikationsebene wiederhole, dann brauch ich mir in Homeegrammne und natürlich manuell keine Sorgen mehr darüber machen.
Meine Vorstellung wäre eine Anzahl an Wiederholung, welche ich selbst konfigurieren kann unabhängig vom Protokoll. Wenn er im Protokoll schon 10 Wiederholungen vorsieht, dann ist das schön vom Protokoll. Wenn ich dazu in der Einstellung sage, er soll 3 Wiederholung tun, dann würde er 3x Applikationswiederholung x 10 Protokollwiederholung durchführen.
Also einfach eine weitere Absicherung auf Applikationsebene
Naja, das kann er ja tun, dann muss er halt schauen, dass das Backend alles im Griff hat. Wenn im Backend einfach aufgehört wird ohne was zu tun, dann ist es nach Aussen unbefriedigend. Und für uns User umso mehr, wenn wir eigene Workarrounds basteln müssen.
Stichwort Workarround, das ist eigentlich was man vermeiden sollte.
Wenn im Backend einfach aufgehört wird ohne was zu tun, dann ist es nach Aussen unbefriedigend. Und für uns User umso mehr, wenn wir eigene Workarrounds basteln müssen.