Gibt es eine Art AutoRetry, wenn Device bei set_on stehenbleibt?

Begonnen von FunkOdyssey, 21 Dezember 2020, 16:30:50

Vorheriges Thema - Nächstes Thema

FunkOdyssey

Ich habe bei einem Fibaro FGS222 immer wieder das Problem, dass Schaltbefehle nicht richtig beantwortet werden.
Das Gerät ist im Gartenbereich eingebaut und hat daher nicht die beste Verbindung.
Gibt es bei den Z-Wave-Geräte in FHEM eine Möglichkeit, dass Schaltbefehle wiederholt werden, wenn die Geräte bei set_on oder set_off stehenbleiben?

rudolfkoenig

Sowas kann bzw. muss man selbst basteln, z.Bsp. mit watchdog oder mit sequence.

Meines Wissens sendet der Controller jedes Befehl bis zu dreimal, wenn er vorher kein ACK vom Zielgeraet empfaengt.
Er versucht die Meldung auch ueber potentielle "Nachbarknoten" zu routen, evtl. hilft in diesem Fall ein "neighborupdate".
Oder man platziert eine neue Zwischensteckdose strategisch guenstig, als Router.

FunkOdyssey

Danke. Ich wollte vor dem Selberbasteln fragen, ob ich ein Feature dieser Art vielleicht übersehen haben.
Eigentlich sind es nur zwei Meter zwischen den Knoten. Ich habe die Probleme bei diesem einen Gerät schon seit Jahren. Da haben auch keine weiteren Knoten geholfen. Irgendwie will der Fibaro nicht. Vielleicht sind das sogar klebende Relais. Darauf muss ich mal achten.

Beta-User

Glaube nicht, dass es ein klebendes Relay ist; dann würde der Befehl an sich doch quittiert, oder?
Und wenn das Ding einfach funktechnisch "kaputt" ist und ein neighbourupdate nichts bringt, weiß ich nicht so recht, ob (bzw. wie lange/häufig) es Sinn macht, die Sendung zu wiederholen. Aber an sich müßte das ausbleibende ACK doch auch eine triggernde Aktualisierung des ACK-Readings zur Folge haben, auf die man dann ggf. mit einem schlichten notify reagieren könnte?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

FunkOdyssey

Wegen den klebenden Relais hast du bestimmt Recht.

Ich habe in den beiden Kanälen des Aktors leider nur state und reportedState.
Und im Hauptdevice verändert sich kein Reading. Keine ACK und NO_ACK vorhanden.
In den Kanälen könnte ich mir mit get xyz swbStatus den Status holen.

Derzeit beobachte ich mit monitoring die Geräte, ob diese mit set_on oder set_off stehengeblieben sind.


Beta-User

Im Hauptdevice gibt es bei mir ein Reading "transmit", und afaik sollte es das eigentlich bei allen (Haupt-) Geräten geben. Es wird nur eben nicht immer triggernd aktualisiert, und auf den Verursacher runterbrechen (welcher der beiden Kanäle?) müßte man dann auch noch...

Aber wenn du eine andere Lösung im Einsatz hast, paßt das ja... (wenn man von der "Kleinigkeit" absieht, dass der Effekt gar nicht erst sein dürfte).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors