[Gelöst] Wie ist in FHEM bei Z-Wave 'resending message' realisiert?

[db0b23b]

Hallo zusammen,

ich habe folgende Frage: Kann es sein, dass FHEM kein echtes 'resending message' macht, sondern den STATE des Z-Wave-Empfängers neu ausliest und diesen (ggf. inzwischen geänderten) dann sendet?

Hintergrund:
Eine Lampe wird gelegentlich nicht beim ersten Funkversuch erreicht.

Im Logfile FHEM äußert sich das dann so:

Code Auswählen Erweitern

2018.03.23 10:47:43 3: ZWave set FL.Deckenleuchte dim 99
2018.03.23 10:47:43 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013030326016325c047

Ist normal.
Im Logfile der Lampe FL.Deckenleuchte finde ich dann aber folgendes:

Code Auswählen Erweitern

2018-03-23_10:47:43 FL.Deckenleuchte dim 99
2018-03-23_10:47:43 FL.Deckenleuchte on

Was mir auffiel ist, dass die beiden Zeilen nicht identisch sind. Für ein 'resending message' hätte ich das erwartet.

Bei der Ursachensuche bin ich dann auf ein notify gestoßen:

DEF(inition) von notify FL.DimWert
FL.Deckenleuchte:dim.* IF ($EVTPART1>0) (IF ($EVTPART1<100) ((setreading FL.DeckenDim state $EVTPART1),(setreading FL.Deckenleuchte state on))) ELSE (setreading FL.Deckenleuchte state off)

Relevant ist das (setreading FL.Deckenleuchte state on)

Zweck ist es u.a., bei der Lampe eine leuchtende Glühlampe in der FHEM-Oberfläche als Schaltzustand anzuzeigen ('setstate FL.Deckenleuchte on' habe ich auch versucht, aber das ging nur mit einem sleep x, sonst wurde im Rahmen der ganzen Aktivitäten der STATE von FL.Deckenleuchte gleich wieder überschrieben).

Der Status STATE der Lampe ändert sich also mit jedem 'dim xx'-Befehl, welcher an sie gesendet wird. Das soll so bleiben.

Damit zurück zur Frage: Kann es sein, dass FHEM kein echtes 'resending message' macht, sondern den STATE des Z-Wave-Empfängers neu ausliest und diesen (ggf. inzwischen geänderten) dann sendet?

Vielen Dank.

[db0b23b]

Ich glaube, ich habe einen Denkfehler. der Eintrag im Logfile der Lampe kommt ja vom notify.

Ich schaue noch mal selbst genauer.

[rudolfkoenig]

ich habe folgende Frage: Kann es sein, dass FHEM kein echtes 'resending message' macht, sondern den STATE des Z-Wave-Empfängers neu ausliest und diesen (ggf. inzwischen geänderten) dann sendet?

Nein. Das berechnete Telegramm wird in die Warteschlage des Controllers gesteckt. Wenn der Controller den USB Empfang nicht quittiert, wird der gleiche Wert nochmal gesendet, den siehst du auch im Log nach resending. Der Controller ist verantwortlich das Telegramm per Funk oefters zu schicken, wenn der Empfaenger kein ACK sendet. Und der Controller meldet das Geraete-Ack an FHEM weiter, wie auch den Fall, wenn er nach mehreren Versuchen aufgegeben hat. In diesen Faellen wird der naechste Befehl aus der Warteschlage verarbeitet, d.h. an dem Controller geschickt.