PRESENCE cover version - anderer Ansatz basierend auf aktuellem Code

Begonnen von martinp876, 23 Dezember 2020, 14:38:45

Vorheriges Thema - Nächstes Thema

JoWiemann

Hallo,

ich habe das ganze überarbeitet und auch das Toggeln funktioniert jetzt. commandRef ist gepflegt. Bitte einmal testen und vielen Dank.

@Robert, ich habe Deine Anregungen aufgenommen und wurde für einen neuen Lösungsansatz motiviert.

Bitte nach dem Einspielen Fhem neu starten. Ein reload reicht nicht aus.

Grüße Jörg
Jörg Wiemann

RPi 4 B mit 4 GByte bookworm, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM; zigbee2mqtt

ioBroker als Datenlieferant für z.B. Anker, Samsung

bertl

Hallo Jörg,

hier meine Erkenntnisse:
Wenn das Gerät auf "absent" geht und der Threshold auch abläuft funktioniert alles wie erwartet (in die Gegenrichtung funktionert es auch).

Wenn das Gerät auf "absent" geht und der Threshold noch nicht abgelaufen ist, sondern das Gerät vorher wieder auf "present" geht passiert folgendes:
"presence" geht von "maybe absent" auf "maybe present" und "state" geht von "present" auf "undefined" (in die Gegenrichtung passiert das Gleiche).

Gruß, Robert

bertl

Weiteres Problem:
Wenn das erste Mal (nach einem Neustart) ein Gerät auf "absent" geht, wird der Threshold nicht berücksichtigt und "state" inklusive "presence" gehen sofort auf "absent" (ohne "maybe ...").
Das Reading "thresHldCnt" gibt es in diesem Fall auch nicht.

Und dann steht alles, egal ob das Gerät "absent" oder "present" ist - keine Reaktion mehr - und dann auf einmal einige Zeit später ...

... ich glaube da passt noch mehr nicht - bitte überarbeiten!

JoWiemann

Zitat von: bertl am 25 September 2026, 12:24:14Wenn das Gerät auf "absent" geht und der Threshold noch nicht abgelaufen ist, sondern das Gerät vorher wieder auf "present" geht passiert folgendes:
"presence" geht von "maybe absent" auf "maybe present" und "state" geht von "present" auf "undefined" (in die Gegenrichtung passiert das Gleiche).
arbeitet, wie programmiert. Siehe auch commandRef. In Fall des Toggelns ist ja unklar welcher Zustand herrscht.

Zitat von: bertl am 25 September 2026, 12:24:14Wenn das erste Mal (nach einem Neustart) ein Gerät auf "absent" geht, wird der Threshold nicht berücksichtigt und "state" inklusive "presence" gehen sofort auf "absent" (ohne "maybe ...").
Das Reading "thresHldCnt" gibt es in diesem Fall auch nicht.
arbeitet, wie programmiert. Siehe auch commandRef. Hier handelt es sich um die Initialisierung. Da habe ich keine threshold vorgesehen.

Zitat von: bertl am 25 September 2026, 12:24:14Und dann steht alles, egal ob das Gerät "absent" oder "present" ist - keine Reaktion mehr - und dann auf einmal einige Zeit später ...

verstehe ich nicht.

Grüße Jörg
Jörg Wiemann

RPi 4 B mit 4 GByte bookworm, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM; zigbee2mqtt

ioBroker als Datenlieferant für z.B. Anker, Samsung

bertl

Zitat von: JoWiemann am 25 September 2026, 13:24:32In Fall des Toggelns ist ja unklar welcher Zustand herrscht.

Wenn es 1x einen Ausreißer gibt wird das aktuell bereits als Toggeln gewertet!

Zitat von: JoWiemann am 25 September 2026, 13:24:32Da habe ich keine threshold vorgesehen.

Warum nicht?

JoWiemann

Zitat von: bertl am 25 September 2026, 13:35:10Wenn es 1x einen Ausreißer gibt wird das aktuell bereits als Toggeln gewertet!
sehe ich so.

Zitat von: JoWiemann am 25 September 2026, 13:24:32Da habe ich keine threshold vorgesehen.
Warum nicht?
[/quote]
Nach einem Neustart ist die vorhandene Information veraltet und keiner kann sagen, welche Zustände in der Zeit vorhanden waren. Ich möchte also schnell den aktuellen Zusatand wissen.
Ähnliches gilt für ein Define. Auch da möchte ich schnell den aktuellen Zustand wissen.

Sollte sich beim nächsten Zustand ein neuer ggf. wahrer Zustand ergeben, dann würde hier der Threshold wieder greifen.

Grüße Jörg
Jörg Wiemann

RPi 4 B mit 4 GByte bookworm, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM; zigbee2mqtt

ioBroker als Datenlieferant für z.B. Anker, Samsung