[Gelöst] - HM-LC-Bl1PBU-FM schalten, obwohl es nicht gewollt ist

[maxritti]

Guten Abend zusammen,

gestern Abend hat mich mal etwas verwundert, als ich abends so auf dem Sofa gesessen habe.
Und zwar habe ich 4 x HM-LC-Bl1PBU-FM im Einsatz. Damit schliesse ich abends meine Rollos per at und sunset.

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        *{sunset("HORIZON=-4")} {Rollos_Down()}
   NAME       at_Rollos_Down
   NR         100
   NTM        21:10:59
   REP        -1
   STATE      Next: 21:10:59
   TRIGGERTIME 1398798659
   TRIGGERTIME_FMT 2014-04-29 21:10:59
   TYPE       at
Attributes:

Code Auswählen Erweitern

sub myRollosUtils_Rollos_Down {
  my $EG_ku_TK_Strasse = ReadingsVal("EG_ku_TK_Strasse", "state", "closed");
  my $EG_wz_TK_Terrasse = ReadingsVal("EG_wz_TK_Terrasse", "state", "closed");

  Log (3, "Strasse  : $EG_ku_TK_Strasse");
  Log (3, "Terrasse: $EG_wz_TK_Terrasse");
 
  if ($EG_ku_TK_Strasse eq "closed") {
    fhem("set EG_ku_RO_StrasseRechts off");
  }
  if ($EG_wz_TK_Terrasse eq "closed") {
    fhem("set EG_wz_RO_TerrasseLinks off");
  }
  fhem("set EG_ku_RO_StrasseLinks off");
  fhem("set EG_wz_RO_TerrasseRechts off");
}

Soweit so gut. Die Rollos gehen brav runter. Gestern steht im Log dies:

2014.04.28 21:09:17 3: CUL_HM set EG_ku_RO_StrasseRechts off
2014.04.28 21:09:17 3: CUL_HM set EG_wz_RO_TerrasseLinks off
2014.04.28 21:09:17 3: CUL_HM set EG_ku_RO_StrasseLinks off
2014.04.28 21:09:17 3: CUL_HM set EG_wz_RO_TerrasseRechts off

Was dann komisch ist, ist die Tatsache, dass um 21:22:00 noch mal dies im Log steht und die Aktoren noch mal "klackern".

2014.04.28 21:22:00 3: CUL_HM set EG_wz_RO_TerrasseLinks off
2014.04.28 21:22:01 3: CUL_HM set EG_ku_RO_StrasseRechts off

Im DBLog sehe ich auch einfach nur ein EG_wz_RO_TerrasseLinks set_off und EG_ku_RO_StrasseRechts set_off.

Jetzt bin ich mir allerdings nicht bewusst, noch von irgendwo per anderem at o.ä. die Aktoren noch mal zu schalten.
Dabei finde ich komisch, dass ausgerechnet die beiden Rollos, bei denen ich in meiner Funktion prüfe, ob der Türkontakt closed ist, noch mal den set_off bekommen.
Die beiden anderen nicht.


Mal schauen, ob das gleich nach 21 Uhr wieder passiert oder das nur ein Einzelfall war.

Wobei ich sehe gerade, dass das vorgestern auch bereits war:
Diesmal aber nicht etwa 13 Minuten nach dem regulären runterfahren, sondern etwa 44 Minuten später.

Code Auswählen Erweitern

2014.04.27 21:07:34 3: CUL_HM set EG_ku_RO_StrasseRechts off
2014.04.27 21:07:34 3: CUL_HM set EG_wz_RO_TerrasseLinks off
2014.04.27 21:07:34 3: CUL_HM set EG_ku_RO_StrasseLinks off
2014.04.27 21:07:34 3: CUL_HM set EG_wz_RO_TerrasseRechts off
2014.04.27 21:51:26 3: CUL_HM set EG_wz_RO_TerrasseLinks off
2014.04.27 21:51:27 3: CUL_HM set EG_ku_RO_StrasseRechts off

Hat dazu jemand eine Idee?

[betateilchen]

Du arbeitest in Deiner Fehlerbeschreibung mit zwei unterschiedlichen Funktionen

*{sunset("HORIZON=-4")} {Rollos_Down()}

sub myRollosUtils_Rollos_Down {

Was ist denn nun richtig? Ruft das at eine Funktion auf, die Du uns nicht zeigst, oder was ist da los?

[maxritti]

Ups, das ist ja in der Tat interessant.

Die Tage (genauer am 26.04.) habe ich angefangen meine 99_myUtils.pm in thematisch aufgeteilte 99_my...Utils.pm aufzuteilen.
Dabei habe ich dann eine 99_myRollosUtils.pm erstellt, wo auch die gepostete sub myRollosUtils_Rollos_Down { drin ist. Also den Code für die Steuerung der Rollos.

Die ehemals benannte Funktion Rollos_Down() gibt es nicht mehr. Auch nicht mehr in der 99_myUtils.pm. Gerade noch mal geprüft.
Um so erstaunlicher, dass die Rollos überhaupt noch runter gehen. 

Da muss ich wohl noch mal suchen....

[betateilchen]

mach mal in der fhem Befehlszeile ein {Rollos_Down}

[maxritti]

Ist ja ein Dingen. Da gehen die alle runter.
Verdammt, wo hat die sich denn versteckt?
Kann eigentlich nicht so schwer sein, die Funktion in zwei pm Dateien zu finden...

[maxritti]

Ah ja.

Ich hatte vom 31.03.2014 noch eine 99_Test.pm in dem Verzeichnis /opt/fhem/FHEM/ und da gibt es noch die Funktion Rollos_Down().
Das erklärt zumindest, dass das at noch funktioniert.

Die lösche ich mal besser und passe das at an. 

Dann noch schnell die Rollos wieder hoch fahren und abwarten, was gleich passiert...

Danke Dir auf jeden Fall schon mal für das Auffinden der Unstimmigkeit.

[betateilchen]

Ist ja ein Dingen. Da gehen die alle runter.

typischer "Error 40"

[maxritti]

Nun gut.
Das erklärt aber noch nicht das eigentliche Problem was eingangs beschrieben wurde.

Code Auswählen Erweitern

2014.04.29 21:45:08 3: CUL_HM set EG_wz_RO_TerrasseLinks off
2014.04.29 21:45:08 3: CUL_HM set EG_ku_RO_StrasseRechts off

Inkl. hörbarem schalten der Aktoren.

[maxritti]

Vielleicht hat Martin eine Idee, warum heute Nacht und heute morgen noch weiter Einträge dazu gekommen sind?

Code Auswählen Erweitern

2014.04.29 23:45:08 3: CUL_HM set EG_wz_RO_TerrasseLinks off
2014.04.30 06:31:45 3: CUL_HM set EG_wz_RO_TerrasseLinks off

[betateilchen]

entweder Du hast aus Deinen Experimenten noch irgendwo "alte" at im fhem Speicher oder Du hast noch notify definiert, die etwas auslösen. Von alleine entstehen keine set Befehle.

[maxritti]

Dann werde ich mal weiter experimentieren suchen und hoffen, dass sich Deine Behauptung bewahrheitet dass das Problem vor dem Rechner sitzt.

Dies Vermutung von Dir hat sich in einem anderen Post ja auch mal als falsch rausgestellt.
Niemand ist nunmal unfehlbar.

Sollte dennoch jemand eine Idee haben, warum ein solcher Befehl abgesetzt wird ist diese herzlich willkommen. 

[maxritti]

Hallo zusammen,

meiner Ansicht nach habe ich das Rätsel jetzt erkannt.
Bin mir jetzt aber nicht sicher, ob dies selbst verschuldet ist.

Zum gewissen Teil hat betateilchen Recht gehabt. Allerdings habe ich nicht "alte" at im Speicher oder noch notify definiert, sondern die logische UND Verknüpfung der beiden verursacht ein erneutes "set_off" an meine Aktoren.

Um Plotabrisse meiner Tür-/Fensterkontakte zu vermeiden, schreibe ich mittels addLog wie im Wiki beschrieben die Werte stündlich ins Log.

Code Auswählen Erweitern

define at_EG_wz_TK_Terrasse at +*01:00 {addLog("EG_wz_TK_Terrasse","state")}

Nun habe ich ein Notify, welches prüfen soll, ob eine Tür geschlossen wird und die Zeit überschritten wurde wo die Rollos eigentlich zu sein sollten, aber nicht automatisch zugegangen sind, weil eben die Tür noch offen war.
Wenn dem so ist, soll der Rollo runter gehen.

Code Auswählen Erweitern

define no_TK_Terrasse_closed notify EG_wz_TK_Terrasse:.*closed.* IF ($hms gt [RollosRunter:state]) (set EG_wz_RO_TerrasseLinks off)

RollosRunter ist dabei ein Dummy, welcher mal nach einem Vorschlag von betateilchen mit einer Uhrzeit gefüllt wird um diese an unterschiedlichen Stellen zu auswerten zu können.
(http://forum.fhem.de/index.php/topic,16093.msg105591.html#msg105591)

Code Auswählen Erweitern

define at_RollosRaufRunter_Timer at *02:00:00 {my $ss = sunset("HORIZON=-4");; fhem("set RollosRunter $ss");; my $sr = sunrise("REAL");; fhem("set RollosHoch $sr")}

Jetzt bin ich doch etwas verwirrt, dass wenn das o.a. at für den Logabriss um beispielsweise 22:04:02 startet auch gleichzeit das notify feuern lässt.

Zumindest entnehme ich das so dem Log, welches ich mal mit verbose = 4 mitgeschnitten habe:

Code Auswählen Erweitern

2014.04.30 22:04:02 5: exec at command at_EG_wz_TK_Terrasse
2014.04.30 22:04:02 5: Cmd: >{addLog("EG_wz_TK_Terrasse","state")}<
2014.04.30 22:04:02 5: Cmd: >trigger EG_wz_TK_Terrasse closed<
2014.04.30 22:04:02 5: Triggering EG_wz_TK_Terrasse (1 changes)
2014.04.30 22:04:02 5: Notify loop for EG_wz_TK_Terrasse closed
2014.04.30 22:04:02 4: eventTypes: CUL_HM EG_wz_TK_Terrasse closed -> closed
2014.04.30 22:04:02 5: DbLog: logging of Device: EG_wz_TK_Terrasse , Type: CUL_HM , Event: closed , Reading: state , Value: closed , Unit:
2014.04.30 22:04:02 5: Triggering no_TK_Terrasse_closed
2014.04.30 22:04:02 4: no_TK_Terrasse_closed exec IF ($hms gt [RollosRunter:state]) (set EG_wz_RO_TerrasseLinks off)
2014.04.30 22:04:02 5: Cmd: >IF ($hms gt [RollosRunter:state]) (set EG_wz_RO_TerrasseLinks off)<
2014.04.30 22:04:02 5: Cmd: >{if($hms gt ReadingValIf('RollosRunter','state','')){fhem('set EG_wz_RO_TerrasseLinks off')}}<
2014.04.30 22:04:02 5: Cmd: >set EG_wz_RO_TerrasseLinks off<
2014.04.30 22:04:02 5: CUL_HM EG_wz_RO_TerrasseLinks protEvent:CMDs_pending pending:1
2014.04.30 22:04:02 5: Triggering EG_wz_RO_TerrasseLinks (1 changes)
2014.04.30 22:04:02 5: Notify loop for EG_wz_RO_TerrasseLinks set_off

Kann mir das vielleicht einer erklären, ob das so gewollt ist?

BTW:

Passt vielleicht nicht mehr so ganz in den Homematic Bereich.
Könnte das bitte jemand vielleicht nach FHEM / Sonstiges schieben?

[maxritti]

Okay, gerade noch mal in der command ref gelesen 

trigger was in der addLog Funktion genutzt wird kann ein notify auslösen.
Nur was heisst hier können? Offensichtlich tut es das ja. Dann sollte dort doch "löst ein notify" aus stehen oder?

In der englischen command ref steht davon nicht, dass ein notify ausgelöst werden kann. 

[frank]

addlog löst auf alle fälle events der entsprechenden readings aus, sonst könnte das logfile auch nichts mitbekommen. ist ja auch eine art notify.

bau in dein notify folgendes if ein

Code Auswählen Erweitern

if($EVENT !~ m/addLog/) {"make me happy"}

gruss frank

[maxritti]

Danke Dir für den Tip.
Ich habe es mal so geändert, dass ich einfach bei dem notify prüfe, ob die Rollos schon unten sind.
Nur wenn nicht, noch mal triggern.

Damit hat sich das ja dann gelöst.