FHEM Forum

Hallo zusammen,

ich habe ein Notify, welches mir bei auslösenden Aktor (HM-LC-BL1-FM) beim "motor" event verschiedene Userreadings dieses Aktors beschreibt (u.A. wird die aktuelle Zeit abgespeichert). Nun möchte ich jedoch, dass dieses Notify nur auslöst, wenn es sich um eine manuelle (egal ob per Taster, App, Webseite,..) Auslösung handelt. Also habe ich ein wenig geschaut und mir gedacht, dass vor dem Aufruf meiner Perl-Routine (die die Rollladen automatisiert fährt), einfach das Notify auf "inactive" setze. Dies mache ich in einem anderen Notify mit dieser def:
(Helligkeitssensor:brightness.*) {if ($EVTPART1 > 500) { fhem("set ntfy.Rol_Automatik_Zeit_manuelle_Fahrt inactive; {Auto_Rol_group_Abschattung(\"Rol\")}; set ntfy.Rol_Automatik_Zeit_manuelle_Fahrt active;")} }

Die Routine "Auto_Rol_group_Abschattung" wird auch ausgeführt und tut das, was sie soll, aber anscheinend wird das Notify "ntfy.Rol_Automatik_Zeit_manuelle_Fahrt" trotz setzen auf inactive ausgeführt. D.h. die Userreadings, die ich eigentlich unterdrücken möchte bei dieser automatisierten Fahrt, werden trotzdem geschrieben. Muss ich da evtl. irgendwo Wartenzeiten einbauen, damit das inactive setzen abgeschlossen bzw. damit keine Events mehr auflaufen, bevor ich es wieder aktiviere? Wenn ja, kann mir einer sagen, wo ich das wie einbaue? Und es sollte fhem natürlich nicht durch die Wartezeit stillgelegt werden. Versucht hatte ich schon folgendes:
(Helligkeitssensor:brightness.*) {if ($EVTPART1 > 500) { fhem("sleep 1; set ntfy.Rol_Automatik_Zeit_manuelle_Fahrt inactive; {Auto_Rol_group_Abschattung(\"Rol\")}; set ntfy.Rol_Automatik_Zeit_manuelle_Fahrt active;")} }

Vielen Dank schon für eure Hilfe. Irgendwann sieht man den Wald vor lauter Bäumen nicht mehr...

Grüße, Bernd

userreadings werden doch nicht aufgrund des notify gesetzt, sondern aufgrund  eines events/triggers neu "berechnet". Du müsstest das quasi im userreading abfangen, nicht durch deaktivieren des notify. Wahrscheinlich dazu am besten die "Berechnung" des userreadings in eine sub in 99_myUtils.pm auslagern.

Eventuell zeigst du hier mal noch ein list des device, damit man auch mal noch die Definition der userreadings sieht.

Zitat von: Benni am 29 Mai 2017, 16:48:33
userreadings werden doch nicht aufgrund des notify gesetzt,

Doch, weil ich das Notify (welches ich dann bei Vorgängen in der Routine unterdrücken will) so gebaut habe:
Internals:
   CFGFN
   DEF        (Rol..*:motor.*) {my $jetzt=FmtTime(time()); fhem("setreading $NAME Automatik_Abschattung_Sperrzeitpunkt $jetzt; setreading $NAME Automatik_in_Abschattung 0; setreading $NAME Automatik_Abschatten_vorgemerkt 0; setreading $NAME Automatik_Abschatten_Ende_vorgemerkt 0")}
   NAME       ntfy.Rol_Automatik_Zeit_manuelle_Fahrt
   NOTIFYDEV  Rol..*
   NR         38678
   NTFY_ORDER 50-ntfy.Rol_Automatik_Zeit_manuelle_Fahrt
   REGEXP     (Rol..*:motor.*)
   STATE      active
   TYPE       notify
   Readings:
     2017-05-29 16:51:09   state           active
Attributes:
   room       Rollladen,Notify

Zitat von: Benni am 29 Mai 2017, 16:48:33
sondern aufgrund  eines events/triggers neu "berechnet".

Und weil das Notify von allen meinen Rollläden getriggert wird, möchte ich halt das Notify selber blocken/unterdrücken...

Ich denke, dass das ein Timing-Problem oder ähnliches ist. Könnte es sein, dass das Notify so gar nicht mitbekommt, dass es inactiv gesetzt wurde? Ich habe das Gefühl, dass dies nachher erst getriggert wird, wenn die Routine bereits abgearbeitet und das Notify bereits wieder aktiviert wurde?! Könnte das das Problem sein?

Zitat von: Cluni am 29 Mai 2017, 16:55:47
Doch, weil ich das Notify (welches ich dann bei Vorgängen in der Routine unterdrücken will) so gebaut habe

Ah! Ok! Das sind aber keine userreadings im eigentlichen Sinne (s. https://fhem.de/commandref_DE.html#userReadings) sondern einfach selbst erzeugte Readings.

Du könntest das notify im Ausführungsteil als erstes per set inactive deaktivieren, gefolgt von einem sleep 0.1 quasi um aus der notify-Schleife (ich weiß, der Ausdruck passt nicht ganz  ::)) auszubrechen, das behebt dann evtl. schon dein timing-Problem.

Zitat von: Benni am 29 Mai 2017, 20:59:34
Ah! Ok! Das sind aber keine userreadings im eigentlichen Sinne (s. https://fhem.de/commandref_DE.html#userReadings) sondern einfach selbst erzeugte Readings.

Ah, danke - man(n) lernt ja nie aus...  ;D

Zitat von: Benni am 29 Mai 2017, 20:59:34
Du könntest das notify im Ausführungsteil als erstes per set inactive deaktivieren, gefolgt von einem sleep 0.1 quasi um aus der notify-Schleife (ich weiß, der Ausdruck passt nicht ganz  ::)) auszubrechen, das behebt dann evtl. schon dein timing-Problem.

Gut - das probiere ich mal. Dank dir schon mal!

Internals:
   CFGFN
   DEF        Testbutton:.* {my $jetzt=FmtTime(time()); fhem("set ntfy.Rol_Automatik_Zeit_manuelle_Fahrt inactive;sleep 1"); fhem("setreading $NAME Automatik_Abschattung_Sperrzeitpunkt $jetzt;set Rol.WZ.Seitentuer 1"); fhem("set ntfy.Rol_Automatik_Zeit_manuelle_Fahrt active")}
   NAME       ntfy.Test
   NOTIFYDEV  Testbutton
   NR         41240
   NTFY_ORDER 50-ntfy.Test
   REGEXP     Testbutton:.*
   STATE      2017-05-30 00:10:00
   TYPE       notify
   Readings:
     2017-05-30 00:09:43   state           active
Attributes:
   room       Test

Hmmmm, das Notify wird trotzdem getriggert.  :-\

Guten Morgen zusammen!

Oder habe ich da noch einen Fehler drin?Ich habe schon extra dafür gesonderte fhem("")-Anweisungen genommen...  :(

Hat niemand eine Hilfestellung für mich, wie ich das machen kann?

Noch mal fürs Verständnis - ich möchte über ein Notify, welches durch ein neues Reading eines Helligkeitssensors getriggert wird, eine eigene Perl-Routine aufrufen. In dieser Routine werden Rollladen-Aktoren geschaltet. Durch das Reading "motor" beim Aktor wiederum triggere ich ein anderes Notify, welches mir ein paar Readings dieses Aktors aktualisiert. Da ich das Setzen dieser Readings nur bei manuell ausgelösten Aktionen (egal, ob über Taster, Web-Button, App,...) haben möchte, würde ich das betreffende Notify gerne VOR dem Start der Perl-Routine deaktivieren und nach Abschluss wieder aktivieren. Dabei hakt es bei mir jedoch mit dem obigen Code für das Notify....

Ausgehend von der Beobachtung, dass ein ausgelöstes notify einen aktualisierten STATE bekommt:

Könnte eventuell eine Abfrage des ReadingsAge des STATE vom 1. Notify in dem 2. Notify (dessen Hauptausführungsteil dann nicht durchlaufen werden soll) helfen?

Also: wenn notify 1 vor weniger als 15 Sec. ausgelöst wurde: return undef;? Dann bräuchte man es nicht zu deaktivieren, es würde nur halt nichts machen...

Gruß, Beta-User

Ah das ist ja auch eine tricky Idee. Muss ich mal testen.

Vielen Dank!


Gesendet von iPhone mit Tapatalk

Zitat von: Cluni am 30 Mai 2017, 00:12:59

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        Testbutton:.* {my $jetzt=FmtTime(time()); fhem("set ntfy.Rol_Automatik_Zeit_manuelle_Fahrt inactive;sleep 1"); fhem("setreading $NAME Automatik_Abschattung_Sperrzeitpunkt $jetzt;set Rol.WZ.Seitentuer 1"); fhem("set ntfy.Rol_Automatik_Zeit_manuelle_Fahrt active")}
   NAME       ntfy.Test
   NOTIFYDEV  Testbutton
   NR         41240
   NTFY_ORDER 50-ntfy.Test
   REGEXP     Testbutton:.*
   STATE      2017-05-30 00:10:00
   TYPE       notify
   Readings:
     2017-05-30 00:09:43   state           active
Attributes:
   room       Test

Hmmmm, das Notify wird trotzdem getriggert.  :-\

Ich weiss nicht ob das Teil des problems ist, aber der sleep wird so nicht wirksam.
Ein fhem-sleep sorgt einfach nur dafür dass der Folgebefehl zeitverzögert gestartet wird. Da in diesem fhem-Aufruf aber kein Folgebefehl enthalten ist (sondern nur im notify) wird der sleep 1 keine Auswirkungen haben.

Vielleicht wäre es übersichtlicher einen Dummy zu definieren, den Du setzt und in Deinem notify auf den Status des Dummies prüfen?