Wie umgehen mit fehlgeschlagenen Aktionen?

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.

Oder ist hier etwas anderes passiert ?

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.

2 „Gefällt mir“

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.

1 „Gefällt mir“

Ich wusste nicht, dass es sowas gibt. Kennst du Parameter gerade zufällig auswendig?

Für den FGS-222

PS: Gibt es eigentlich auch noch welche die sich vor der Inbetriebnahme eines Gerätes die Bedienungsanleitung durchlesen?!

2 „Gefällt mir“

SmartHome ist plug-n-play :thinking:
Bedienungsanleitungen sind was für geistige Dünnbrettbohrer :joy:

1 „Gefällt mir“

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

Die NodOn haben übrigens auch so eine AutoTimerOff Funktion. Falls jemand eine derartige Lösung mit Enocean sucht …

Nein, habe das Manual nicht gelesen. Bin nur über den iobroker datenpunkt gestolpert :wink:

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.

Sind wir Mal gespannt, ob’s helfen wird. :wink:

…und zusätzlich zum Handling auf Protokollebene gibt es ja noch das Tagebuch wo der Schaltvorgang grob wie folgt festgehalten wird:

homee sagt X an
X meldet X aus

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.

2 „Gefällt mir“

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

1 „Gefällt mir“

Mach einen Featurevorschlag, den würde Dir @Thomas (wenn er die Zeit hätte) sicherlich genüsslich um die Ohren schlagen :wink:

Naja, das kann er ja tun, dann muss er halt schauen, dass das Backend alles im Griff hat. :slight_smile: 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.

Da geb ich Dir recht - Ich hoffe da auf den neuen Cube und damit verbunden auch auf mehr Transparenz auf das Mesh