[gelöst (mit Workaround)] Reading als Flag

Begonnen von GaiusMarius, 04 Oktober 2022, 18:27:53

Vorheriges Thema - Nächstes Thema

GaiusMarius

Hallo allerseits,

ich hätte gerne1) ein Reading in einem Device, das anzeigt, ob ein anderes Reading desselben Devices einen bestimmten Wert hat oder irgendwann einmal hatte. Sozusagen ein Flag...

Hier ein wenig Code, der meiner Intention schon recht nahe kommt:uR_CurrSabotage {
  my $CurrSabotage = ReadingsVal($NAME, 'sabotageError', 'unknown');
  if    ($CurrSabotage eq 'on' ) {'+'}
  elsif ($CurrSabotage eq 'off') {'-'}
  else                           {'?'}
},

uR_Sabotage {
  my $Sabotage     = ReadingsVal($NAME, 'uR_Sabotage',     'unknown');
  my $CurrSabotage = ReadingsVal($NAME, 'uR_CurrSabotage', 'unknown');
  if (($CurrSabotage eq '+') && ($Sabotage ne '+')) {'+'}
  else                                              {$Sabotage}
},
Beides sind userReadings an dem Device.

uR_CurrSabotage wandelt dabei das "echte" Reading sabotageError in für mich besser handhabbare Zeichen +, - und ? um und uR_Sabotage ist das Flag, dass mir zeigt, dass (irgendwann einmal) uR_CurrSabotage auf + stand.

Nachteil an dieser Lösung: uR_Sabotage - genauer: der Zeitstempel von uR_Sabotage - wird bei jeder Änderung im Device aktualisiert. Auch wenn sich an uR_Sabotage nichts geändert hat.

---------

Die zweite Lösung wäre ein notify, welches auf uR_CurrSabotage triggert.

Nachteil an dieser Lösung: Na ja, es wäre eine device-externe Programmierung notwendig. Wäre aber machbar...

---------

Gibt es eine Möglichkeit, die erste Lösung zum Laufen zu bekommen? 

------------------

Wen der Anwendungsfall interessiert:
Die Homematic (CULHM) Fenster- und Türsensoren erkennen, wenn ihr Batteriefach geöffnet wird. Das führt zu einem Wechsel des Readings sabotageError von off zu on. Sobald der Deckel wieder geschlossen wird, wechselt das Reading zurück auf off. Somit geht die Information, dass der Sensor geöffnet wurde, verloren. Ich möchte aber, dass der Administrator (also ich  ;D) darüber informiert wird und letztendlich diese Gehäuseöffnung absegnen kann / muss.


1) = So begannen die größten Katastrophen der Weltgeschichte!  :)

Otto123

#1
Zitat von: th0masrad am 04 Oktober 2022, 18:27:53
Nachteil an dieser Lösung: uR_Sabotage - genauer: der Zeitstempel von uR_Sabotage - wird bei jeder Änderung im Device aktualisiert. Auch wenn sich an uR_Sabotage nichts geändert hat.
Hi,

schau mal in der commandref nach timestamp-on-change-reading und event-on-change-reading
Beides zusammen wird Dir helfen ;)

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Nun ja, man könnte auch einfach einen passenden "trigger" für die userReadings setzen, oder? Und mir erschließt sich auch nicht so ganz, warum dann 2 userReadings erforderlich sein sollen.

Und es stellt sich dir Frage, warum man nicht gleich die Benachrichtigung "abschießt", sondern erst umständlich irgendwas umpackt...? (Das man dann hinterher wieder graderücken muss, damit der (doppelte...) Status wieder stimmt).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

GaiusMarius

Ich gebe ja zu, dass meine Frage eher theoretischer als praktischer Natur ist. 8)

@Beta-User:
Na ja , auch eine sofortige Aktion wäre ein Flag. Beispiel: Gehäuse geöffnet, Batterien entnommen, Tür geöffnet, Inhalt geklaut1), Tür geschlossen, Batterien eingelegt, Gehäuse geschlossen.
Ich könnte nun z. B. eine E-Mail an mich schicken. Diese ist dann das Flag, weil ich sie erst abarbeiten kann, wenn ich aus dem Urlaub wieder da bin. Selbst eine Sirene wäre ein Flag, da diese sinnvollerweise nicht verstummen sollte, wenn das Gehäuse wieder geschlossen wird.

@Otto123:
Hinsichtlich der generierten Events ja, innerhalb der userReadings leider nicht. Die müssen ja immer durchlaufen werden, wenn es eine Geräteänderung gibt.

@all:
Ich glaube, meine Frage ist eigentlich, ob man die Bearbeitung eines userReadings verlassen kann ohne dessen Wert und dessen Zeitstempel zu ändern.
Je mehr ich darüber nachdenke, desto bekloppter kommt mir meine Frage vor, denn mittels eines notify ist mein Anliegen für alle Geräte zu lösen...
Der einzige Nachteil an einem notify wäre, dass die Geräte, welche noch nie eine Sabotage erlitten, das userReading nicht haben...





1) = Ich weiß, FHEM/Homematic ist keine Alarmanlage...

betateilchen

*** POPCORN ***


Zitat von: th0masrad am 05 Oktober 2022, 18:54:24
Je mehr ich darüber nachdenke, desto bekloppter kommt mir meine Frage vor,

Selbsterkenntnis... usw.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Otto123

Zitat von: th0masrad am 05 Oktober 2022, 18:54:24
@Otto123:
Hinsichtlich der generierten Events ja, innerhalb der userReadings leider nicht. Die müssen ja immer durchlaufen werden, wenn es eine Geräteänderung gibt.
Einer von uns beiden hat entweder nicht richtig gelesen, nicht probiert oder falsch verstanden. :)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

GaiusMarius

Zitat von: betateilchen am 05 Oktober 2022, 19:02:12
*** POPCORN ***


Selbsterkenntnis... usw.

Ist es nicht die Selbstreflektion, die uns als Menschen auszeichnet? Und die Kommunikation, um die beste Lösung zu erreichen?  8)

(Habe den ersten Post auf "[gelöst (mit Workaround)]" gesetzt...)