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...

[Per]

Bei einem dummy wird list nicht viel bringen. Interessant wären die Einträge unter "Probably associated with".

[marvin78]

Natürlich kann das list was bringen. Warum sollte es nicht? Ohne list müsste man hier gar nicht weiter machen, denn im dummy selbst ist die Wahrscheinlichkeit am größten, die Ursache zu finden. Erst wenn man sie dort nicht findet, sind andere Dinge dran.

[automatisierer]

jo, wenn das DOIF durch den dummy nicht getriggert wird oder nicht immer, könnte z.B. ein 'event-on-change-reading' oder ähnliches dran schuld sein und das sieht man dann bei einem list.

[Pete37]

Hier noch mal ein List besagten Dummies:

Code Auswählen Erweitern

Internals:
   NAME       STA_BLI_Zustand
   NR         622
   STATE      unten
   TYPE       dummy
   Readings:
     2016-06-24 08:48:37   state           unten
Attributes:
   devStateIcon unten:ICO_BLI_Unten sonne:ICO_BLI_Sonne oben:ICO_BLI_Oben
   fp_MainSystems 452,412,0
   group      State
   room       BLI Rollaeden
   setList    state:null,unten,sonne,oben
   webCmd     state

Zur Struktur: Ich habe vier DOIF, die dieses Dummy setzen können (1x Automatik und 3x Knöpfe im Display) und drei, die den Zustand auswerten und daraus Befehle für die Rolläden ableiten. Letzere kann ich natürlich noch zu einem einzelnen zusammenführen. Aber an sich tun die ja auch.

Das Problem ist offensichtlich nur der Dummy: Er ändert sich manchmal (nicht immer), ohne irgendwem Bescheid zu geben - auch die Anzeigen im Floorplan bekommen die Änderung nicht mit...

[Ellert]

Hier noch mal ein List besagten Dummies:

Code Auswählen Erweitern

Internals:
   NAME       STA_BLI_Zustand
   NR         622
   STATE      unten
   TYPE       dummy
   Readings:
     2016-06-24 08:48:37   state           unten
Attributes:
   devStateIcon unten:ICO_BLI_Unten sonne:ICO_BLI_Sonne oben:ICO_BLI_Oben
   fp_MainSystems 452,412,0
   group      State
   room       BLI Rollaeden
   setList    state:null,unten,sonne,oben
   webCmd     state

Zur Struktur: Ich habe vier DOIF, die dieses Dummy setzen können (1x Automatik und 3x Knöpfe im Display) und drei, die den Zustand auswerten und daraus Befehle für die Rolläden ableiten. Letzere kann ich natürlich noch zu einem einzelnen zusammenführen. Aber an sich tun die ja auch.

Das Problem ist offensichtlich nur der Dummy: Er ändert sich manchmal (nicht immer), ohne irgendwem Bescheid zu geben - auch die Anzeigen im Floorplan bekommen die Änderung nicht mit...

Dann poste doch auch mal Listings der 4 DOIF, sonst kennen wir nur 1/5 des Problems.
Wo kommt das Attribut "fp_MainSystems 452,412,0" her und was hat es für eine Bedeutung?

[Pete37]

das ist der Flooplan auf dem der Dummy zu sehen ist.

hier die Automatik, bei der sehe ich schon viel "notexist" - das klingt nicht gut?:

Code Auswählen Erweitern

Internals:
   DEF        ## Regen erkannt
([STA_BLI_Betriebsart] eq "automatik" and [DEV_WEA_Sensor:isRaining] > 0) 
(set STA_BLI_Zustand oben)

## Sonne außerhalb des Bereichs erkannt
DOELSEIF ([STA_BLI_Betriebsart] eq "automatik" and ([DEV_WEA_Sensor:sunDirection] < 90 or [DEV_WEA_Sensor:sunDirection] > 270)) 
(set STA_BLI_Zustand oben)

## Hitze erkannt
DOELSEIF ([STA_BLI_Betriebsart] eq "automatik" and [DEV_WEA_Sensor:temperature] >= 28) 
(set STA_BLI_Zustand unten)

## Hitze verkannt
DOELSEIF ([STA_BLI_Betriebsart] eq "automatik" and [DEV_WEA_Sensor:temperature] < 26) 
(set STA_BLI_Zustand sonne)

## Dunkelheit erkannt
DOELSEIF ([STA_BLI_Betriebsart] eq "automatik" and [STA_BLI_Zustand] eq "sonne" and [DEV_WEA_Sensor:brightness] < 20000)
(set STA_BLI_Zustand oben)

## Schatten erkannt
DOELSEIF ([STA_BLI_Betriebsart] eq "automatik" and [STA_BLI_Zustand] eq "sonne" and [DEV_WEA_Sensor:brightness] < 45000)
(set STA_BLI_Zustand oben)

## Sonne erkannt
DOELSEIF ([STA_BLI_Betriebsart] eq "automatik" and [STA_BLI_Zustand] eq "oben" and [DEV_WEA_Sensor:brightness] > 55000)
(set STA_BLI_Zustand sonne)

## nichts erkannt
DOELSE ()
   NAME       CMD_BLI_Automatik
   NR         575
   NTFY_ORDER 50-CMD_BLI_Automatik
   STATE      umsEck
   TYPE       DOIF
   Readings:
     2016-06-25 01:24:41   Device          DEV_WEA_Sensor
     2016-06-24 17:59:38   cmd             2
     2016-06-24 17:59:38   cmd_event       DEV_WEA_Sensor
     2016-06-24 17:59:38   cmd_nr          2
     2016-06-25 01:24:41   e_DEV_WEA_Sensor_brightness 0
     2016-06-25 01:24:41   e_DEV_WEA_Sensor_isRaining 0
     2016-06-25 01:24:41   e_DEV_WEA_Sensor_sunDirection 0
     2016-06-25 01:24:41   e_DEV_WEA_Sensor_temperature 23.7
     2016-06-24 17:40:52   e_STA_BLI_Betriebsart_STATE automatik
     2016-06-23 19:40:59   e_STA_BLI_Zustand_STATE oben
     2016-06-24 17:59:38   state           umsEck
     2016-06-24 08:48:37   wait_timer      no timer
   Condition:
     0          InternalDoIf($hash,'STA_BLI_Betriebsart','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "automatik" and ReadingValDoIf($hash,'DEV_WEA_Sensor','isRaining','','',AttrVal($hash->{NAME},'notexist',undef)) > 0
     1          InternalDoIf($hash,'STA_BLI_Betriebsart','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "automatik" and (ReadingValDoIf($hash,'DEV_WEA_Sensor','sunDirection','','',AttrVal($hash->{NAME},'notexist',undef)) < 90 or ReadingValDoIf($hash,'DEV_WEA_Sensor','sunDirection','','',AttrVal($hash->{NAME},'notexist',undef)) > 270)
     2          InternalDoIf($hash,'STA_BLI_Betriebsart','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "automatik" and ReadingValDoIf($hash,'DEV_WEA_Sensor','temperature','','',AttrVal($hash->{NAME},'notexist',undef)) >= 28
     3          InternalDoIf($hash,'STA_BLI_Betriebsart','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "automatik" and ReadingValDoIf($hash,'DEV_WEA_Sensor','temperature','','',AttrVal($hash->{NAME},'notexist',undef)) < 26
     4          InternalDoIf($hash,'STA_BLI_Betriebsart','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "automatik" and InternalDoIf($hash,'STA_BLI_Zustand','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "sonne" and ReadingValDoIf($hash,'DEV_WEA_Sensor','brightness','','',AttrVal($hash->{NAME},'notexist',undef)) < 20000
     5          InternalDoIf($hash,'STA_BLI_Betriebsart','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "automatik" and InternalDoIf($hash,'STA_BLI_Zustand','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "sonne" and ReadingValDoIf($hash,'DEV_WEA_Sensor','brightness','','',AttrVal($hash->{NAME},'notexist',undef)) < 45000
     6          InternalDoIf($hash,'STA_BLI_Betriebsart','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "automatik" and InternalDoIf($hash,'STA_BLI_Zustand','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "oben" and ReadingValDoIf($hash,'DEV_WEA_Sensor','brightness','','',AttrVal($hash->{NAME},'notexist',undef)) > 55000
   Devices:
     0           STA_BLI_Betriebsart DEV_WEA_Sensor
     1           STA_BLI_Betriebsart DEV_WEA_Sensor
     2           STA_BLI_Betriebsart DEV_WEA_Sensor
     3           STA_BLI_Betriebsart DEV_WEA_Sensor
     4           STA_BLI_Betriebsart STA_BLI_Zustand DEV_WEA_Sensor
     5           STA_BLI_Betriebsart STA_BLI_Zustand DEV_WEA_Sensor
     6           STA_BLI_Betriebsart STA_BLI_Zustand DEV_WEA_Sensor
     all         STA_BLI_Betriebsart DEV_WEA_Sensor STA_BLI_Zustand
   Do:
     0:
       0          set STA_BLI_Zustand oben
     1:
       0          set STA_BLI_Zustand oben
     2:
       0          set STA_BLI_Zustand unten
     3:
       0          set STA_BLI_Zustand sonne
     4:
       0          set STA_BLI_Zustand oben
     5:
       0          set STA_BLI_Zustand oben
     6:
       0          set STA_BLI_Zustand sonne
     7:
       0
   Helper:
     event      brightness: 0,sunDirection: 0,sunHeight: -17,temperature: 23.7,isRaining: 0,T: 23.7 W: 0 IR: 0 B: 0,wind: 0
     globalinit 1
     last_timer 0
     sleepdevice DEV_WEA_Sensor
     sleepsubtimer -1
     sleeptimer -1
     timerdev   DEV_WEA_Sensor
     timerevent brightness: 0,sunDirection: 0,sunHeight: -17,temperature: 23.7,isRaining: 0,T: 23.7 W: 0 IR: 0 B: 0,wind: 0
     triggerDev DEV_WEA_Sensor
     timerevents:
       brightness: 0
       sunDirection: 0
       sunHeight: -17
       temperature: 23.7
       isRaining: 0
       T: 23.7 W: 0 IR: 0 B: 0
       wind: 0
     timereventsState:
       brightness: 0
       sunDirection: 0
       sunHeight: -17
       temperature: 23.7
       isRaining: 0
       state: T: 23.7 W: 0 IR: 0 B: 0
       wind: 0
     triggerEvents:
       brightness: 0
       sunDirection: 0
       sunHeight: -17
       temperature: 23.7
       isRaining: 0
       T: 23.7 W: 0 IR: 0 B: 0
       wind: 0
     triggerEventsState:
       brightness: 0
       sunDirection: 0
       sunHeight: -17
       temperature: 23.7
       isRaining: 0
       state: T: 23.7 W: 0 IR: 0 B: 0
       wind: 0
   Internals:
     0           STA_BLI_Betriebsart:STATE
     1           STA_BLI_Betriebsart:STATE
     2           STA_BLI_Betriebsart:STATE
     3           STA_BLI_Betriebsart:STATE
     4           STA_BLI_Betriebsart:STATE STA_BLI_Zustand:STATE
     5           STA_BLI_Betriebsart:STATE STA_BLI_Zustand:STATE
     6           STA_BLI_Betriebsart:STATE STA_BLI_Zustand:STATE
     all         STA_BLI_Betriebsart:STATE STA_BLI_Zustand:STATE
   Itimer:
   Readings:
     0           DEV_WEA_Sensor:isRaining
     1           DEV_WEA_Sensor:sunDirection
     2           DEV_WEA_Sensor:temperature
     3           DEV_WEA_Sensor:temperature
     4           DEV_WEA_Sensor:brightness
     5           DEV_WEA_Sensor:brightness
     6           DEV_WEA_Sensor:brightness
     all         DEV_WEA_Sensor:isRaining DEV_WEA_Sensor:sunDirection DEV_WEA_Sensor:temperature DEV_WEA_Sensor:brightness
   Regexp:
     0:
     1:
     2:
     3:
     4:
     5:
     6:
     All:
   State:
   Trigger:
Attributes:
   cmdState   regen|umsEck|hitze|kuehle|dunkel|schatten|sonne|nichts
   group      Command
   room       BLI Rollaeden
   wait       0:0:120:1200:120:1200:300

Die Befehlsausführung zum Rauffahren:

Code Auswählen Erweitern

Internals:
   DEF        ([STA_BLI_Zustand] eq "oben")   
(set DEV_BLI_Wz up)

DOELSE ()
   NAME       CMD_BLI_Oben
   NR         625
   NTFY_ORDER 50-CMD_BLI_Oben
   STATE      cmd_2
   TYPE       DOIF
   Readings:
     2016-06-24 08:48:37   Device          STA_BLI_Zustand
     2016-06-24 08:48:37   cmd             2
     2016-06-24 08:48:37   cmd_event       STA_BLI_Zustand
     2016-06-24 08:48:37   cmd_nr          2
     2016-06-24 08:48:37   e_STA_BLI_Zustand_STATE unten
     2016-06-24 08:48:37   state           cmd_2
   Condition:
     0          InternalDoIf($hash,'STA_BLI_Zustand','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "oben"
   Devices:
     0           STA_BLI_Zustand
     all         STA_BLI_Zustand
   Do:
     0:
       0          set DEV_BLI_Wz up
     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:
   do         always
   group      Command
   room       BLI Rollaeden

Der Befehl zum Runterfahren:

Code Auswählen Erweitern

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

DOELSE ()
   NAME       CMD_BLI_Unten
   NR         626
   NTFY_ORDER 50-CMD_BLI_Unten
   STATE      cmd_1
   TYPE       DOIF
   Readings:
     2016-06-24 08:48:37   Device          STA_BLI_Zustand
     2016-06-24 08:48:37   cmd             1
     2016-06-24 08:48:37   cmd_event       STA_BLI_Zustand
     2016-06-24 08:48:37   cmd_nr          1
     2016-06-24 08:48:37   e_STA_BLI_Zustand_STATE unten
     2016-06-24 08:48:37   state           cmd_1
   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:
   do         always
   group      Command
   room       BLI Rollaeden

und für die Sonnenposition:

Code Auswählen Erweitern

Internals:
   DEF        ([STA_BLI_Zustand] eq "sonne")   
(set DEV_BLI_Wz position 42)

DOELSE ()
   NAME       CMD_BLI_Sonne
   NR         574
   NTFY_ORDER 50-CMD_BLI_Sonne
   STATE      cmd_2
   TYPE       DOIF
   Readings:
     2016-06-24 08:48:37   Device          STA_BLI_Zustand
     2016-06-24 08:48:37   cmd             2
     2016-06-24 08:48:37   cmd_event       STA_BLI_Zustand
     2016-06-24 08:48:37   cmd_nr          2
     2016-06-24 08:48:37   e_STA_BLI_Zustand_STATE unten
     2016-06-24 08:48:37   state           cmd_2
   Condition:
     0          InternalDoIf($hash,'STA_BLI_Zustand','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "sonne"
   Devices:
     0           STA_BLI_Zustand
     all         STA_BLI_Zustand
   Do:
     0:
       0          set DEV_BLI_Wz position 42
     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:
   do         always
   group      Command
   room       BLI Rollaeden

was hat es mit dem

Code Auswählen Erweitern

AttrVal($hash->{NAME},'notexist',undef) auf sich?

[Ellert]

Die Frage ist noch offen:

Wo kommt das Attribut "fp_MainSystems 452,412,0" her und was hat es für eine Bedeutung?

Mir ist nichts Fehlerhaftes aufgefallen. Meine Vermutung war, dass Du irgendwo setstate benutzt oder direkt in den Hash der Geräteinstanz schreibst.

1. DOIF: Du benutzt [STA_BLI_Zustand] als Abfrage und mit set in einem DOIF, das ist kein Problem, da Schleifen im DOIF unterbunden sind. Trotzdem würde ich in der Bedingung [STA_BLI_Zustand] mit Fragezeichen als nicht  triggernd Kennzeichnen, [?STA_BLI_Zustand].

Die anderen 3 DOIF bieten sich zum zusammenfassen an, das hattest Du ja schon erwähnt.

AttrVal($hash->{NAME},'notexist',undef)

bezieht sich auf ein eventuell existierendes Attribut notexist und ist keine Fehlermeldung.

Im erste Post sehe ich noch einen Hinweis auf eine "structure", könnte es dadurch zu unerwünschten Wechselwirkungen kommen?

[Pete37]

hier noch das Structure der zwei Rolläden:

Code Auswählen Erweitern

Internals:
   ATTR       device
   DEF        device DEV_BLI_Wz_L DEV_BLI_Wz_R
   NAME       DEV_BLI_Wz
   NR         74
   NTFY_ORDER 50-DEV_BLI_Wz
   STATE      opened
   TYPE       structure
   Content:
     DEV_BLI_Wz_L opened
     DEV_BLI_Wz_R opened
   Readings:
     2016-06-25 09:27:10   LastDevice      DEV_BLI_Wz_L
     2016-06-25 09:27:10   LastDevice_Abs  DEV_BLI_Wz_L
     2016-06-25 09:27:10   state           opened
     2016-05-10 09:41:33   sunAutomatic    0
Attributes:
   group      Device Structure
   room       BLI Rollaeden
   webCmd     sunAutomatic:up:down:stop

Unterdessen haben sich die Biester wieder bewegt: der Befehl "sonne" scheint weiter zu funktionieren, auch wenn "oben" nicht wollte.

Habe zunächst mal die drei Kommando-DOIFs zusammengefasst, die Fragezeichen eingebaut und einen Bug noch aus der Automatik geholt. Ich werde weiter beobachten und berichten.

[Ellert]

Die Antwort auf die Frage

Wo kommt das Attribut "fp_MainSystems 452,412,0" her und was hat es für eine Bedeutung?

verweigerst Du hartnäckig. Kann das eine Referenz zu etwas sein, dass den Dummy bedient?

[Pete37]

Sorry, ich hatte schon geantwortet, es nur nicht dazugeschrieben: Das ist der Floorplan auf dem der Dummy zu sehen ist.

[Pete37]

dieses neue Fhem Web-Interface macht mich wahnsinnig! ist ja schön und übersichtlicher - aber die Readings werden nicht mehr g'scheit aktualisiert!! ich kann kaum mehr debuggen und muss immer händisch einen Refresh machen!?

(in welchem Thread wäre dieser Post passender?)

[Ellert]

Sorry, ich hatte schon geantwortet, es nur nicht dazugeschrieben: Das ist der Floorplan auf dem der Dummy zu sehen ist.

Bis hier sehe ich nichts, was den Dummy unerwartet setzt.

Dann müsstest Du die 99_myUtils.pm, fhem.cfg oder fhem.save mal durchsehen, ob irgend etwas den Dummy ohne Event setzt.

dieses neue Fhem Web-Interface macht mich wahnsinnig! ist ja schön und übersichtlicher - aber die Readings werden nicht mehr g'scheit aktualisiert!! ich kann kaum mehr debuggen und muss immer händisch einen Refresh machen!?

(in welchem Thread wäre dieser Post passender?)

Versuchs mal hier: https://forum.fhem.de/index.php/board,19.0.html

[Pete37]

und wieder nix - der Zustand hat sich korrekt geändert - aber keiner hat es mitbekommen!!!

[Pete37]

ich komme hier mit dem Debugging einfach nicht weiter: der Dummy verändert ständig seinen Status (was er auch soll), OHNE IRGENDJEMANDEM BESCHEID ZU SAGEN (was er nicht soll)! Ich kann es also im Logfile und Eventmonitor nicht nachvollziehen!

Wie kann das sein? Wie kann ein Dummy sich von einem in den anderen Zustand tunneln?

Ich finde ja gerne meine eigenen Fehler, aber dieses Verhalten sieht mir nicht danach aus, als dass ich es verursacht habe??

[Ellert]

Wie kann ein Dummy sich von einem in den anderen Zustand tunneln?

Es gibt Möglichkeiten den STATE eines Gerätes mit setstate ohne Event zu setzen.

Auf Perl-Ebene gibt es auch andere Möglichkeiten Readings eines Moduls ohne Event zu setzen z.B. mit

Code Auswählen Erweitern

$defs{<Gerätename>}{STATE} = "XYZ";
$defs{<Gerätename>}{READINGS}{state}{VAL} = "XYZ";

weitere Möglichkeiten sind hier http://www.fhemwiki.de/wiki/DevelopmentModuleIntro#Readings erwähnt.

Das könnte durch Module, Perl-Funktionen geschehen, die eine Referenz zu dem Dummy haben.