DOIF reagiert auf Änderung eines Dummies nicht zuverlässig!?

[Pete37]

Hallo Forum,

ich habe zig DOIFs sehr erfolgreich im Einsatz und plötzlich machen mir einige hartnäckige Kopfschmerzen:

Ich verwende ein Dummy, das den (Soll)Zustand der Rolläden trägt:

Code Auswählen Erweitern

Internals:
   NAME       STA_BLI_Zustand
   NR         247
   STATE      oben
   TYPE       dummy
   CHANGED:
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
     oben
   CHANGEDWITHSTATE:
   Readings:
     2016-06-22 22:28:33   state           oben
Attributes:
   devStateIcon unten:ICO_BLI_Geschlossen oben:ICO_BLI_Offen sonne:ICO_BLI_Sonne
   fp_MainSystems 452,412,0
   group      State
   room       BLI Rollaeden
   setList    state:null,oben,sonne,unten
   webCmd     state

Dieses steht vermutlich schon seit Stunden auf "oben", weil mein Steuerungs-DOIF richtig erkannt hat, dass die Sonne um's Eck rum ist, also die Rolläden rauf sollen. Mein Visualisierungs-Icon zeigt auch brav "oben" an.

Allerdings hat das DOIF, was die Rolläden hätte rauffahren lassen sollen offenbar nicht reagiert. Es glaubt immer noch, der Zustand wäre "unten"! Wie kann das sein??

Code Auswählen Erweitern

Internals:
   DEF        ([STA_BLI_Zustand] eq "unten")   
(set DEV_BLI_Wz down)

DOELSE ()
   NAME       CMD_BLI_Unten
   NR         576
   NTFY_ORDER 50-CMD_BLI_Unten
   STATE      aktiv
   TYPE       DOIF
   Readings:
     2016-06-22 17:22:34   Device          STA_BLI_Zustand
     2016-06-22 17:22:34   cmd             1
     2016-06-22 17:22:34   cmd_event       STA_BLI_Zustand
     2016-06-22 17:22:34   cmd_nr          1
     2016-06-22 17:22:34   e_STA_BLI_Zustand_STATE unten
     2016-06-22 17:22:34   state           aktiv
   Condition:
     0          InternalDoIf($hash,'STA_BLI_Zustand','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "unten"
   Devices:
     0           STA_BLI_Zustand
     all         STA_BLI_Zustand
   Do:
     0:
       0          set DEV_BLI_Wz down
     1:
       0
   Helper:
     event      unten
     globalinit 1
     last_timer 0
     sleeptimer -1
     timerdev   STA_BLI_Zustand
     timerevent unten
     triggerDev STA_BLI_Zustand
     timerevents:
       unten
     timereventsState:
       state: unten
     triggerEvents:
       unten
     triggerEventsState:
       state: unten
   Internals:
     0           STA_BLI_Zustand:STATE
     all         STA_BLI_Zustand:STATE
   Itimer:
   Readings:
   Regexp:
     0:
     All:
   State:
   Trigger:
Attributes:
   cmdState   aktiv|passiv
   do         always
   group      Command
   room       BLI Rollaeden

Ich übersehe offenbar irgendein Detail - ich seh's nur halt nicht...

Vielen Dank für Eure Analysen,
Pete

[kumue]

du hast ja auch nur definiert, was es bei "unten" machen soll - oder ?

[Pete37]

ehm, ja. Für dieses DOIF schon. habe natürlich noch ein weiteres, das entsprechend auf "oben" reagieren soll. Aber der Punkt an diesem Bild ist: das DOIF ist noch um Zustand "aktiv", obwohl es das nicht sein dürfte. Entsprechend ist das andere noch "passiv" gewesen, obwohl es hätte reagieren sollen...

Den selben Spaß habe ich mit drei DOIFs, die den Zustand anzeigen sollen: sie reagieren nicht - zumindest nicht bei der ersten Einladung!

[Damian]

ehm, ja. Für dieses DOIF schon. habe natürlich noch ein weiteres, das entsprechend auf "oben" reagieren soll. Aber der Punkt an diesem Bild ist: das DOIF ist noch um Zustand "aktiv", obwohl es das nicht sein dürfte. Entsprechend ist das andere noch "passiv" gewesen, obwohl es hätte reagieren sollen...

Den selben Spaß habe ich mit drei DOIFs, die den Zustand anzeigen sollen: sie reagieren nicht - zumindest nicht bei der ersten Einladung!

Aus irgendwelchem Grund wird das Modul nicht getriggert.

[Pete37]

ja, vielleicht ist es der Dummy, der die Probleme macht - er schaltet zwar um, aber nicht mal das Logfile bekommt das mit!?

[Damian]

ja, vielleicht ist es der Dummy, der die Probleme macht - er schaltet zwar um, aber nicht mal das Logfile bekommt das mit!?

Dann erzeugt die Änderung offenbar kein Event.

[Pete37]

zumindest nicht immer - ich ändere den Zustand gerade per Knopfdruck. Geht an sich - nur immer mal wieder verschluckt er wohl ein Event. Habe ich mein Fhem schon an die Überlast getrieben? wo könnte ich das sehen?

[Damian]

zumindest nicht immer - ich ändere den Zustand gerade per Knopfdruck. Geht an sich - nur immer mal wieder verschluckt er wohl ein Event. Habe ich mein Fhem schon an die Überlast getrieben? wo könnte ich das sehen?

Normalerweise geht logisch gesehen in FHEM nichts verloren. Hast du fhem2fhem im Einsatz?

[Pete37]

ne, nur einen fhem auf einem raspi

und er macht es schon wieder: vor meinen eigenen Augen!! Der Dummy schaltet um, aber die Rolläden tun nix und nicht mal das Log weiß Bescheid...

[Damian]

ne, nur einen fhem auf einem raspi

und er macht es schon wieder: vor meinen eigenen Augen!! Der Dummy schaltet um, aber die Rolläden tun nix und nicht mal das Log weiß Bescheid...

Dann wird wohl auch nichts im Event-Monitor erscheinen!?

[Pete37]

korrekt: der Event-Monitor schweigt über diesen Dummy - WARUM!? wie kommt denn sowas?

ich hatte ihn gestern noch mal entfernt und komplett neu angelegt. gleiches heute mit den ausführenden DOIFs. Im Log-File (wo jetzt wieder Einträge erschienen) passieren auch merkwürdige Dinge!
Beim händischen Wechsel von "oben" (wo er sich still und leise hinbegeben hatte) zu "null" schreibt das Log zeitgleich den alten und den neuen Zustand. Das habe ich so noch nicht gesehen. Dann reagiert die Automatik (Sonne ist längst rum, die Rolläden sollen hoch) und wieder kommen zeitgleich zwei Einträge, nur diesmal die gleichen.

Wenn natürlich Event-Dopplungen auftreten - insbesondere, wenn zeitlich unterschiedliche Status gemeldet werden, kann ich verstehen, dass die ausführenden DOIFs verwirrt sind und das im Zweifel ignorieren. Bleibt die Frage: warum liefert dieses Dummy so ein seltsames Verhalten??

Code Auswählen Erweitern

2016-06-23_09:23:35 STA_BLI_Zustand unten
2016-06-23_19:38:49 STA_BLI_Zustand oben
2016-06-23_19:38:49 STA_BLI_Zustand null
2016-06-23_19:38:56 STA_BLI_Zustand unten
2016-06-23_19:40:07 STA_BLI_Zustand oben
2016-06-23_19:40:07 STA_BLI_Zustand oben

[cbl]

Das gleiche Problem scheine ich auch zu haben.

Ich habe einen Dummy "Tageslicht", der als state "dunkel" oder "hell" haben kann. Bislang setze ich den state per AT zum Sonnenaufgang und -untergang.
Das funktioniert auch soweit.

Dann habe ich ein DOIF, das entweder zu einer definierten Zeit oder wenn Tageslicht:state dunkel ist, die Rolladen runterfahren soll. Für morgens gibt es das gleiche mit einer frühesten Uhrzeit und "hell".
In diesem DOIF sehe ich ein Reading "device = dummy.Tageslicht" und ein Reading "e_dummy.Tageslicht_state = dunkel". Die Readings wurden exakt zu der Zeit verändert (21:55:14), als der AT-Befehl den Zustand verändert hat.

Nur wird das DOIF nur dann ausgeführt, wenn ich manuell den Status von Tageslicht auf "dunkel" setze.
Wie kommt der state von Tageslicht in das DOIF, wenn dann trotzdem nur bei manuellem "set" das DOIF ausgeführt wird?

Das AT sieht so aus:
at *{sunset("CIVIL",-1800)} set dummy.Tageslicht dunkel

Das DOIF sieht (in Anlehnung an http://www.fhemwiki.de/wiki/Rolladensteuerung_mit_Eingabem%C3%B6glichkeiten) so aus:
([dummy.Rollo_Art] eq "Normal" and ([dummy.Tageslicht:state] eq "dunkel" or [[dummy.Rollo_Zeit_runter]] )) (set eg.wohnzimmer.Rollo.Esszimmerfenster Ab, set eg.wohnzimmer.Rollo.Terrassenfenster Ab ) DOELSEIF ([dummy.Rollo_Art] eq "Weihnachten" and [[dummy.Rollo_Zeit_runter]] ) (set eg.wohnzimmer.Rollo.Esszimmerfenster Ab, set eg.wohnzimmer.Rollo.Terrassenfenster Ab ) DOELSEIF ([dummy.Rollo_Art] eq "Urlaub" and ([dummy.Tageslicht:state] eq "dunkel" or [[dummy.Rollo_Zeit_runter]]) ) (set eg.wohnzimmer.Rollo.Esszimmerfenster Ab, set eg.wohnzimmer.Rollo.Terrassenfenster Ab, set eg.wohnzimmer.Rollo.Terrassentuer Ab )


Also auch hier: Das DOIF wird korrekt ausgeführt, wenn ich manuell den Dummy Tageslicht auf "dunkel" setze. Wenn er per AT auf dunkel gesetzt wird, passiert nichts.

Gruß
Christian

[Pete37]

ich vermute einen Bug im System - ich habe kurz vorher noch ein Update gemacht.

Oder gibt es ein Limit an DOIFs, die Fhem verträgt? ich benutze die sehr viel...

[Per]

korrekt: der Event-Monitor schweigt über diesen Dummy - WARUM!? wie kommt denn sowas?

Wenn im Event-Monitor nichts zu sehen ist, kann DOIF das auch nicht sehen und nicht reagieren. Insofern würde ich dieses DOIF schonmal nicht als Ursache sehen.

Bleibt die Frage: warum liefert dieses Dummy so ein seltsames Verhalten??

Vllt. gibt es noch ein anderes DOIF/notify, welches hier "reingrätscht"? Wenn ich deine Aussagen richtig interpretiere, nutzt du verschiedene DOIF für hoch und runter (warum?! doppelte Last!).

[automatisierer]

mach doch mal ein list von dem dummy, vielleicht ist da ein Fehler erkennbar...