FHEM Forum

Ich setze ein Reading eines MQTT-Devices mittles:
setReading PIR2 occupancy_filtered true

Daraufhin soll folgendes DOIF aktiv werden:
defmod PIR_MOTION DOIF ([PIR2:occupancy_filtered] eq 'true') (...)

Problem ist, dass das DOIF nie getriggert wird.
Kann mir da bitte wer weiterhelfen?

nie oder nur einmal? do always beim DOIF?
Ansonsten zeig mal je ein list vom Device damit man mehr sieht...

Zitat von: Otto123 am 24 Februar 2023, 09:28:19
nie oder nur einmal? do always beim DOIF?
Ansonsten zeig mal je ein list vom Device damit man mehr sieht...

Das DOIF wird nie getriggert.
Hab "do=always" und vorsichtshalber "checkReadingEvent=1".

Das verrückte ist jedoch, dass ein alter/weiter oben in der fhem.cfg stehender code mit der exakt gleichen Definition aber schon auslöst!  ???

List vom Device:

Internals:
   CID        zigbee_0x1111111111111111
   DEF        zigbee_0x1111111111111111
   FUUID      1111111-1111-1111-1111-1111111111111111
   IODev      myMQTT2_SERVER
   LASTInputDev myMQTT2_SERVER
   MSGCNT     102
   NAME       PIR2
   NR         559
   STATE      false
   TYPE       MQTT2_DEVICE
   eventCount 108
   myMQTT2_SERVER_CONN myMQTT2_SERVER_127.0.0.1_41844
   myMQTT2_SERVER_MSGCNT 102
   myMQTT2_SERVER_TIME 2023-02-24 09:33:24
   READINGS:
     2023-02-23 21:55:03   IODev           myMQTT2_SERVER
     2023-02-24 09:33:24   battery         100
     2023-02-24 09:33:24   linkquality     42
     2023-02-24 09:33:24   occupancy       false
     2023-02-24 09:33:24   occupancy_filtered false
     2023-02-24 09:33:24   power_outage_count 236
     2023-02-24 09:33:24   voltage         3015
Attributes:
   IODev      myMQTT2_SERVER
   devStateIcon true:people_sensor@red .*:people_sensor@lightgray
   icon       people_sensor
   readingList zigbee2mqtt/0x11111111111111:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   stateFormat occupancy_filtered

Das Reading "occupancy_filtered" wird von einem anderen DOIF mittels "setReading" gesetzt.
Und genau auf das Reading reagiert ein weiteres DOIF eben nicht.

Mir fallen spontan 2 Schreibfehler(?) auf:
Hast du das eq 'true' statt mit Hochkomma auch mal mit Gansefüßchen getestet (eq "true")?
Das "setReading" wird doch normal mit klenem "r" geschrieben (setreading).

Sorry, falls ich Unsinn schreibe, aber ich kenne nur die obigen Schreibweisen.

Zitat von: rih am 24 Februar 2023, 10:20:26
Mir fallen spontan 2 Schreibfehler(?) auf:
Hast du das eq 'true' statt mit Hochkomma auch mal mit Gansefüßchen getestet (eq "true")?
Das "setReading" wird doch normal mit klenem "r" geschrieben (setreading).

Sorry, falls ich Unsinn schreibe, aber ich kenne nur die obigen Schreibweisen.

Hat beides leider keinen Unterschied gemacht.



Hier das DOIF das richtig funktioniert:

defmod TEST_LICHT1 DOIF ([PIR2:occupancy_filtered] eq "true") \
(\
set STECKDOSE_5 longpulse 14 1 1\
)
attr TEST_LICHT1 checkReadingEvent 1
attr TEST_LICHT1 do always

setstate TEST_LICHT1 2023-02-24 10:20:23 Device PIR2
setstate TEST_LICHT1 2023-02-24 10:20:15 cmd 1
setstate TEST_LICHT1 2023-02-24 10:20:15 cmd_event PIR2
setstate TEST_LICHT1 2023-02-24 10:20:15 cmd_nr 1
setstate TEST_LICHT1 2023-02-24 10:20:23 e_PIR2_occupancy_filtered false
setstate TEST_LICHT1 2023-02-24 10:21:17 last_cmd cmd_1


Hier ist das DOIF welches NIE auslöst:

defmod TEST_LICHT2 DOIF ([PIR2:occupancy_filtered] eq "true")\
(\
set STECKDOSE_5 longpulse 14 1 1\
)
attr TEST_LICHT2 checkReadingEvent 1
attr TEST_LICHT2 do always

setstate TEST_LICHT2 initialize
setstate TEST_LICHT2 2023-02-24 10:24:45 mode enabled
setstate TEST_LICHT2 2023-02-24 10:24:45 state initialize

Wird denn durch ein "setreading" überhaupt ein Event beim betreffenden Device ausgelöst?
Muss ich parallel zum "setreading" noch einen "trigger" setzen?

ZitatBemerkung: In früheren Versionen des Moduls war checkReadingEvent 0 die Voreinstellung des Moduls. Da die aktuelle Voreinstellung des Moduls checkReadingEvent 1 ist, hat das Setzen von checkReadingEvent 1 keine weitere Funktion mehr.

Habe rein "vom auf den Code gucken" keine Idee warum die praktisch gleiche DEF einmal auslöst und einmal nicht. Der Satz macht mich stutzig:

Zitat von: chunter1 am 24 Februar 2023, 09:40:19
Das verrückte ist jedoch, dass ein alter/weiter oben in der fhem.cfg stehender code mit der exakt gleichen Definition aber schon auslöst!  ???

Aber wenn es da zwischendurch einen Fehler geben sollte, würde das Device wohl gar nicht in der Raw Definition sichtbar sein.

Hier siehst Du doch quasi den Event:

Zitatsetstate TEST_LICHT1 2023-02-24 10:20:23 e_PIR2_occupancy_filtered false

Ansonsten schau im Eventmonitor :)