Rolladen-Funk-Aktor mit Gedächtnis?

[MarkoP]

Hallo,

ich habe gestern meinen Homematic-Rollladen-Funk-Aktor HM-LC-BL1-HM per Notify an ein Structure gekoppelt, dass aus den Ladeströmen von zwei QI-Handyladeschalen gesteuert wird.
Heute Morgen spielte der Aktor plötzlich verrückt. Er fuhr stetig rauf und runter mit immer wechselnden Positionen. erst auf 20%, dann 80%, dann wieder auf 0%, danach 90%, dann 50% und so weiter. Alle Werte sind Schätzwerte.

Bei der Fehlersuche kommen bei mir folgende Fragen auf:

• Hat der Aktor eine Art Initialisierung bei der er sich "ausrichtet"?
• Oder hat der Aktor ein Gedächtnis in der sich aufgesammelte Befehle sammeln und dann nacheinander abgearbeitet werden?

[Beta-User]

1. Kein list.
2. Kein Log-Auszug (alle von FHEM automatisch ausgelösten Schaltvorgänge sind per default darin zu finden).
3. Bei CUL_HM wird irgendwann (recht schnell) abgebrochen, wenn eine Schaltanweisung nicht zustellbar ist.
4. Meine Vermutung:

Bin mal gespannt, ob das mit der Verbrauchsmessung als Indikator für eine Nachtschaltung klappt...

Mein Tipp: Schau dir mal an, wie sich der Messwert der Dose über der Zeit verhält. 4,5W sind für einen laufenden Ladevorgang irgendwie sehr wenig, und dass die dauerhaft gebraucht werden, wenn das Laden beendet ist, bezweifle ich...

(Wenn es letzteres ist: Verschiebe den Thread bitte in den Anfängerbereich, das hat mMn. NICHTS mit Homematic zu tun ).

[MarkoP]

Also da USB3.x Schnittstellen alle nur 5V bei 4,5W können und bei QI sicherlich ja noch mal etwas verloren geht, sind die 4,5W schon realistisch.
Aber nicht immer beständig, die Leistungsaufnahme schwankt natürlich etwas und was ich nicht bedacht habe, wenn das Handy 100% erreicht hat wird die Leistungsaufnahme wohl abgeschaltet. Ich bin von einem Erhaltungsstrom ausgegangen.
List und Log muss ich nachreichen, das ging heute Morgen nicht zwischen Tür und Angel.

Bei CUL_HM wird irgendwann (recht schnell) abgebrochen, wenn eine Schaltanweisung nicht zustellbar ist.

Dann kann es wohl kaum sein, dass sich Befehle "aufgestaut" haben die dann nacheinander abgearbeitet worden sind.
Also muss er ja innerhalb von Sekunden zig Befehle bekommen haben. Das müsste ich ja im Log nachvollziehen können.

Grundsätzlich schon mal vorab:
Die beiden Ladeschalen hängen jeweils an einem Shelly2.5. Mit den beiden Leistungsdaten werden per Notify jeweils ein Dummy für den Homestatus (1=anwesend, 2=schlafen, 3=abwesend und 4=urlaub) gesetzt. Bei Leistungsaufnahme größer 2W wird ein Notify ausgelöst, dass den Status auf 2 setzt und bei Leistungsaufnahme kleiner 1W wird ein weiteres Notify ausgelöst, dass den Status auf 1 setzt. Die beiden Dummys sind in einem structure-Device mit "absolute"-Einstellung vereint. Also nur wenn beide Homestatus-Dummys per Notify auf 2 gesetzt werden, wechselt das structure-Device ebenfalls auf 2. Dadurch wird wiederum per Notify der Rollladen geöffnet bzw. geschlossen. Beim Öffnet geht der Rollladen allerdings nicht direkt ganz auf, sondern bewusst erst auf 20% (also ca. Schlitzbildung) und dann verzögert nach ca. 5 Min. komplett auf.

P.S.:
Hab schon mal ins Log reingeschaut (Kopiere es heute Abend vom PC hier rein). In der betreffenden Zeit +/- 20 Minuten als der Fehler auftrat konnte ich keinen einzigen Eintrag zum Rollladenaktor im Log finden.
Dafür allerdings immer wieder Schaltbefehle für Fritzbox-Zwischenstecker die ich irgendwie mal abfangen sollte und einen Befehl zur Schaltung einer Lampe, die aber falsch definiert ist und daher nicht funktionieren kann.

[Beta-User]

Danke für die Bestätigung, dass es wohl kein Homematic-Problem ist (wie gesagt, das Modul versucht mehrfach, die Schaltanweisung an den Aktor zu senden, wenn da aber nicht binnen irgendwas von unter einer Minute Rückmeldung kommt, geht das Device auf "NACK" und das war es dann; kein weiteres Queueing, causa finita...)

Was USB angeht: mein Handy bekommt über einen USB-C-Stecker beim Laden sicher mehr wie 1A@5V . Vielleicht schaust du mal in die Spec von dem Ladegerät, aber der Shelly müßte doch schlicht und ergreifend (bis zu mehreren Ampere bei) 230V "schalten".

Wie dem auch sei: die zwei notify würde ich durch einen THRESHOLD ersetzen, und beim Thema Bewohnerstatus RESIDENTS einsetzen, aber letzteres hatten wir ja schon mal...

Ansonsten klingt langsames Laden und dann "20% und später dann hoch" genau nach dem Szenarium, das du als "Fehler" genannt hattest, nur weil es eben wiederholt ausgeführt wurde und die Zeiten unvorhersehbar waren, wann die nächste Schaltanweisung dann von deiner Logik rausgehauen wurde.

[MarkoP]

Auch hier werde ich mal schauen was ich rausfinden kann, trotzdem wie versprochen hier das List des Gruppen-Device:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        group 12  IODev=Hue_Bridge
   FUUID      5f51483c-f33f-b8b5-6246-f595145d182b9ae4
   FVERSION   31_HUEDevice.pm:0.218370/2020-05-02
   ID         G12
   INTERVAL   
   IODev      Hue_Bridge
   NAME       HUEGroup12
   NR         70865
   STATE      unknown
   TYPE       HUEDevice
   class      Bedroom
   desired    0
   lights     3,4
   name       Nachtische
   type       Zone
   READINGS:
     2020-09-04 13:10:24   all_on          0
     2020-09-04 19:44:58   any_on          1
   helper:
     devtype    G
     fromAutocreate 1
     update_timeout 1
     json:
       class      Bedroom
       name       Nachtische
       type       Zone
       action:
         alert      select
         bri        254
         colormode  xy
         ct         153
         effect     none
         hue        0
         sat        254
         xy:
           0.3019
           0.1244
       lights:
         3
         4
       sensors:
       state:
     lights:
       3          1
       4          1
Attributes:
   IODev      Hue_Bridge
   alias      Nachtische
   color-icons 2
   delayedUpdate 1
   devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
   group      Licht
   room       20_Schlafzimmer
   userattr   createActionReadings:1,0 createGroupReadings:1,0

Was mir im Log aufgefallen ist (werde morgen eins nachliefern, wenn ich ein bereinigtes habe) ist, dass die gemessene Leistungsaufnahme des Aktors zwischen ca. 4,5W, 2,1W und 0W wechselt. Die letzteren beiden wenn das Handy zu 100% geladen ist. Also scheint die Erhaltungsladung schon da zu sein, aber nicht wie vermutet kontinuierlich, sondern rythmisch zu verlaufen.

Vielleicht kannst du mir für meine Versuche da mal eine Frage beantworten:
Gibt es eine Möglichkeit in einem Notify den Trigger über eine bestimmte Dauer zu prüfen? Also im konkreten Fall so, dass der Trigger erst ausgelöst wird  wenn das reading länger als ca. 5 Minuten auf 0W bleibt.

[Beta-User]

Kannst du das bitte verschieben und den Titel ändern?

Kurz zu der Frage: Das ganze ist nicht ganz trivial und man kann solche Probleme auf mehrere Arten lösen. Dazu muß man aber wissen, wozu man die betreffenden Daten ggf. sonst noch braucht und wie die Zusammenhänge sind.

Hier würde ich als erstes mal die Lektüre zu event-on-change-reading (und weiterer verwandter Attribute, beginnend in der commandref und es gibt auch einen "Wechselwirkungen"-Artikel dazu im Wiki) empfehlen. Ansonsten suchst du evtl. sowas wie "watchdog" (das Modul, SAME, triggerzeit auf die 0 entsprechend lange im eocr-Attribut einstellen).

Meine persönliche Tendenz wäre, das mit zwei userReadings zu lösen, aber das ist zum einen relativ komplex, da es Perl erfordern würde und zum anderen deswegen nicht optimal, weil man mit userReadings sehr sparsam sein sollte; das wird teils inflationär und zu den falschen Zwecken genutzt und ist in der Beziehung ein enger Verwandter von "dummy". Daher sollte es nicht eine der ersten Lösungen sein, mit denen man sich als Anfänger beschäftigt .

[MarkoP]

Wenn du mir sagst wie ich den Threat verschieben kann, mache ich das gerne - in der Regel können sowas doch nur die Admins, oder ist das hier anders?

mit den readings event-on-change-reading, event-on-update-reading und timestamp-on-event-reading habe ich mich schon beschäftigt und die Commandref durchgelsen, trotzdem eventuell nicht alles voll umfängich verstanden. Grob gesagt lese ich daraus, dass die aufgeführten reading entsprechend dem attribut eben nur bei einem update oder einer Änderung geloggt werden bzw. ob jeweils der letzte oder der Timestamp der letzten Änderung geloggt wird. Bei mir sind alle alle betreffenden Devices auf "event-on-change-reading .*" und "timestamp-on-change-reading .*" gestellt. Dadurch werden schon wiederholungen mit gleichen Werten nicht mehr geloggt soweit ich das verstanden haben, richtig?

Watchdog habe ich schon mehrfach gelesen, kenne ich aber nicht, die anderen Sachen sagen mir rein gar nichts - muss ih mir ansehen.
Mein erster Gedanke war einen Dummy von "Falsch" auf "Wahr" zu schalten und den zusammen mit dem Leistungswert abzufragen. Aber du bist ja eher ein Gegner von Dummys, daher will ich erst mal deine Einschätzung wissen.

[martinp876]

Wenn es sich um einen Autor handelt und der fehler reproduzierbar ist sollte man erst einmal logs einschalten.
In fhem hm werden komnandos gequeued. Wenn eines bedtätigt ist wird das nächste gesendet. Der Aktor könnte beim Start mit dem ack den level 20%melden ziel 80% wird gemeldet wenn erreicht. Interessant ist die Richtung up down stop.
Bei gegenläufigem kommando wird das aktuelle sofort ersetzt.

[Beta-User]

@Martin: Es scheint sich nunmehr auch nach Auffassung von MarkoP nicht um ein Homematic-Problem zu handeln.

@MarkoP: zum Verschieben gibt es einen Knopf unter dem Thread, das kann man hier als User selbst (warum schlage ich das sonst vor...?).


Ich bin auch kein "Gegner" von dummy, ich finde nur deren Verwendung _in der Regel_ überflüssig. Wenn man (wirklich) einen braucht, ist das sehr hilfreich. Grundsätzlich versuche ich, Informationen beim selben Device zu verwalten, die zusammengehören. Dafür ist setreading und (partiell) userReadings mMn. besser, da übersichtlicher.

An sich wäre das mit deiner eocr-Konfiguration perfekt für watchdog: Starte, wenn ein "0"-Wert gemeldet wird und nicht innerhalb einer bestimmten Frist der Haltestrom (oder ein neuer Ladestrom) gemeldet wird. Die Schwierigkeit hier besteht halt darin, dass wir vermutlich nicht davon ausgehen können, dass es nicht geringfügige Schwankungen gibt... Aber da das immer einstellig ist (?), sollte als 2. Event sowas wie "[1-5].[0-9]" gehen.

Bitte ggf. die Events (nur dieses Devices) mal im Event-Monitor mitschneiden, dann ist das ggf. einfacher und zur Übung würde ich empfehlen, die beiden Teile des Watchdog mal als separate notify zu schreiben, damit sichergestellt ist, dass die jeder für sich funktionieren. Kannst ja mal setreading austesten und einfach ein passendes Reading (myLoading) zu dem Shelly-Device schreiben...


Was "alle Devices mit eocr .*" angeht finde ich persönlich das nicht gut, martinp876 wird dir mit guten Gründen erläutern können, warum er das speziell bei CUL_HM für fast immer richtig hält...

Meine Meinung: jedenfalls für Messwerte ist es in den meisten Fällen nicht gut, und man sollte wenigstens eine Zeitgrenze setzen. (Achtung: HIER wäre das falsch bzw. kontraproduktiv für den watchdog!)

Das mit dem timestamp ist mMn. in fast jedem Fall für Meßwerte falsch und nur für Schaltzustände fast zwingend.

Summary: Immer mit Bedacht einsetzen, es kommt fast immer darauf an, was man eigentlich am Ende bezweckt...

[MarkoP]

Leider habe ich am Wochenende nichts geschafft. Ist halt immer so, dass plötzlich alles wichtiger ist.
Trotzdem kannst du mir vielleicht behilflich sein bei meinen Versuchen eine Lösung zu finden, denn immerhin ist mir eine Idee gekommen.

Und zwar würde ich gerne ein Diagramm für die Messwerte erstellen um besser sehen zu können wann, wie und auf welchen Wert geschaltet wird.
Leider bekomme ich das nicht hin. Ich finde nirgendwo die Schaltfläche zum Erstellen des Diagramms. Mir fehlt auch der "Raum" "Plot's" auf den in mehreren Beispielen verwiesen wird. Ich meine mich zu erinnern, dass ich den ganz am Anfang mal irgendwie ausgeblendet habe, finde aber nichts um dies wieder Rückgängig zu machen. Ich hoffe, dass ein SVG-Diagramm genauere Infos liefert und eine bessere Übersicht als im Log aufweist.

Was ich auch nicht verstehe ist der Punkt, dass mein Notify für aktiven Ladestrom triggert, wenn der Ladestrom ungleich 0 Watt ist, obwohl eingestellt ist bei größer 4 Watt.

Thema Watchdog: Ich verstehe die Bedeutung des zweiten Regex-Ausdrucks noch nicht ganz. Kann man für Regexp2 auch generische Ausdrücke nutzen, oder muss man dann mehrere Watchdogs schreiben?
In der commandref steht lediglich, dass Watchdog insgesamt nicht generisch möglich ist. Was meinst du mit "beide Teile"? Meinst du den Trigger zur Reaktivierung mit zweitem Teil?

Das eocr.* habe ich erstmal gesetzt um nicht ständig doppelte Werte im Log zu haben, die sich nicht unterscheiden. Sollte hauptsächlich die Datenmenge begrenzen und mehr Übersichtlichkeit  schaffen. Wie kann man denn eine Zeitgrenze setzen? Wenn ich das attribut für den timestamp weglasse, sehe ich ja nicht wann der Wert geändert wurde, nur wann er zum letzten Mal registriert wurde. Das wäre doch kontraproduktiv um etwas mitzuloggen oder verstehe ich da was falsch.

Bitte ggf. die Events (nur dieses Devices) mal im Event-Monitor mitschneiden

Welches Device genau meinst du, sind ja mehrere beteiligt. Ich gehe mal vom Shelly aus, der den Ladestrom registriert, oder?

[Beta-User]

Welches Device genau meinst du, sind ja mehrere beteiligt. Ich gehe mal vom Shelly aus, der den Ladestrom registriert, oder?

Ja, die "Quelle des Übels" ist immer am interessantesten .

Ich hatte verstanden, dass du die Werte von dem Shelly in ein FileLog schreibst. Aus der Detailansicht des FileLog heraus sollte sich eigentlich auch irgendwo ein Link finden zur Erstellung von einem Plot-Diagramm (SVG) mit dem Plot-Editor (sobald du das einmal gemacht hast und verstanden, wie das funktioniert bzw. welche Daten eigentlich wie in der .gplot landen, vergißt du bitte direkt wieder, dass es den gibt! Verwendung ist hier zu finden: https://wiki.fhem.de/wiki/Plots_erzeugen, Generalisierung und "bessere" .gplot im Artikel SVG).

Leider habe ich am Wochenende nichts geschafft. Ist halt immer so, dass plötzlich alles wichtiger ist.

Nevermind: Du darfst (und sollst erst) antworten, wenn du das jeweilige "Pflichtprogramm" durch hast.

Ich hoffe, dass ein SVG-Diagramm genauere Infos liefert und eine bessere Übersicht als im Log aufweist.

Nicht unbedingt, im Prinzip sollte reichen, was im Logfile steht. Gleiche Werte siehst du im Plot nämlich nicht.

Was ich auch nicht verstehe ist der Punkt, dass mein Notify für aktiven Ladestrom triggert, wenn der Ladestrom ungleich 0 Watt ist, obwohl eingestellt ist bei größer 4 Watt.

Du erwartest nicht, dass ich ohne "list" was dazu sagen kann?

Thema Watchdog: Ich verstehe die Bedeutung des zweiten Regex-Ausdrucks noch nicht ganz. Kann man für Regexp2 auch generische Ausdrücke nutzen, oder muss man dann mehrere Watchdogs schreiben?

Verstehst du nun die Bedeutung nicht, oder ist einfach unklar, wie die 2. Regex geschrieben werden müßte? Wenn letzteres: Ich hatte bereits ein Fragment dazu geliefert... Da hätte ich  gerne Rückmeldung dazu. Falls dir nicht klar ist, was das im Detail soll, empfehle ich einen Blick auf regexr.com, da sind die erforderlichen Infos zu finden.

In der commandref steht lediglich, dass Watchdog insgesamt nicht generisch möglich ist. Was meinst du mit "beide Teile"? Meinst du den Trigger zur Reaktivierung mit zweitem Teil?

"Generisch" verstehe ich so: es ist nicht möglich, einen Watchdog so auf eine Vielzahl von Ausgangsdevices anzusetzen, dass der in der Reaktion irgendwie das (nicht) triggernde Gerät berücksichtigen könnte. Ansonsten gehe ich davon aus (ohne im Code nachgesehen zu haben), dass eine regex bei watchdog den allgemeinen Regeln folgt und es daher auch möglich wäre, an beiden Stellen, in denen eine regex vorgesehen ist auch eine solche hinzuschreiben, die auf mehrere Devices hören würde. In unserem Fall ist das alles aber blanke Theorie... (Falls du was generischeres suchst, wäre readingsWatcher ggf. ein Stichwort (aber mMn. mit einem anderen Schwerpunkt, aber bleib erst mal bei einer Sache...!)

Das eocr.* habe ich erstmal gesetzt um nicht ständig doppelte Werte im Log zu haben, die sich nicht unterscheiden. Sollte hauptsächlich die Datenmenge begrenzen und mehr Übersichtlichkeit  schaffen. Wie kann man denn eine Zeitgrenze setzen?

"event-min-interval" in https://wiki.fhem.de/wiki/Event-on-change-reading#Wechselwirkungen hast du überlesen?

[MarkoP]

Also ich muss jetzt mal Querschießen, denn das sind aktuell viel zu viele Informationen. Ich sehe den Wald vor lauter Bäumen nicht mehr.

Bitte lass uns erstmal event-on-change-reading mit seinen Verbindungen klären. denn ich verstehe nicht welchen Sinn das min-interval haben soll.
Ich setze doch event-on-change-reading um eben nur dann einen Trigger bzw. Logeintrag auszulösen wenn sich der Wert wirklich geändert hat, warum soll ich das wider künstlich mit einem Interval einschränken. Mir erklärt sich die Logik dahinter einfach nicht.
Gleiches gilt bei timestamp-on-change-reading. Wenn ich event-on-change-reading setze, dann will ich doch auch den Zeitpunkt haben, an dem das reading sich geändert hat und nicht den letzten Abfragezeitpunkt. Also ergibt ein event-on-change-reading ohne ein timestamp-on-change-reading doch eigentlich keinen Sinn.

Vielleicht denke ich auch einfach falsch, aber mir erschließt sich der Anwendungssinn hinter den genannten Fällen nicht.
Vielleicht wird es für mich etwas klarer wenn du mir erst mal das erklärst. Eventuell fällt mir dann auch selbst eine Lösung ein. Denn irgendwie komme ich mit der Logik in Fhem allgemein offenbar nicht zurecht.

[Beta-User]

Also nochmal der Reihe nach:

_HIER_ ist das mit event-on-change-reading mMn. ok, wie du das gesetzt hattest. Damit kann man insbesondere eine sinnvollen watchdog bauen, sonst müßte man es anders lösen.

timestamp-on-change-reading würde ich hier _nicht_ setzen, das macht mMn. eigentlich nur dann Sinn, wenn es sich um wichtige Schalt-Status-Infos handelt. Da will ich wirklich wissen können, wann der letzte Schaltvorgang war, sonst ist es in der Regel besser wissen zu können, wann die letzte Info über den jeweiligen Zustand reingekommen ist.

Das mit dem min-interval macht dann Sinn, wenn du irgendeinen laufenden Meßwert hast (z.B. von einem Temperaturfühler), der sehr häufig aktualisiert wird. Ein Beispiel: Manche 433MHz-Temperatursensoren senden alle 15 Sekunden (oder so) den aktuellen Meßwert. In der Regel braucht man das aber gar nicht so oft, also dünnt man aus, indem man zum einen einen kleinen Threshold festlegt (wg. Messungenauigkeiten bzw. sehr kleinen Änderungen soll nicht jedes Mal ein Event generiert werden), und zum anderen dann aber schon alle paar Minuten dann ein Event durchläßt, damit man daran anknüpfende Berechnungen durchführen lassen kann (zur Heizungssteuerung, z.B.) oder Datenpunkte für plots hat, oder ...
Bei echten Meßwerten macht es auch Sinn zu sehen, wann sie das letzte Mal aktualisiert wurden, selbst, wenn sie nicht getriggert hatten.

Das mit diesen drei Argumenten ist übrigens einer der Themen, die v.a. neue User oft überhaupt nicht verstehen (es gibt duzende Threads dazu), und dass es "timestamp" gibt, ist mir auch lange entgangen, bis mir irgendwann mal auch einer dieser Shelly in die Hände gefallen ist und das "mein" Problem gelöst hat. Mein Zwischenergebnis zu diesen Attributen für einen einkanaligen@MQTT ist (indirekt) hier zu finden: https://forum.fhem.de/index.php/topic,94060.msg1075460.html#msg1075460

Hoffe, so wird es - auch in der Zusammenschau - wenigstens etwas klarer...?

Vielleicht noch eine Anmerkung zum Stichwort "Abfragezeitpunkt": FHEM merkt sich weniger sowas wie einen "Abfragezeitpunkt", sondern in der Regel den letzten Zeitpunkt der Aktualisierung (aus FHEM-Sicht). Das ist in der Regel der Zeitpunkt, zu dem eine Nachricht bei FHEM eingegangen war, also (in der Regel) das "Event" stattgefunden hat. Du solltest also weniger in "Abfragen" (klingt für mich nach Schleifen und aktivem Abholen) denn in "Events" denken (das kann auch mal die Folge von Abholen sein, aber sehr viele Devices schicken Infos "ungefragt" und du bzw. FHEM muß dann entscheiden, ob bzw. was mit diesen Infos geschehen soll). Das macht für mich einen prinzipiellen Unterschied .

(Zu pollende Devices haben dann uU. noch den Nachteil, dass man zwar auf Nachfrage eine Antwort erhält, aber die Frage völlig ungeklärt ist, wann denn eigentlich die Messung stattgefunden hat, bei der dieser Wert erhoben worden war).

[MarkoP]

Ok, deine Erläuterungen machen die Wirkung klar, aber den Sinn kann ich dahinter nicht sehen.
Liegt vielleicht einfach daran dass ich noch zu wenig Erfahrung mit Fhem habe, du sagst ja selbst, dass gerade Anfänger damit häufig Probleme haben.
Für mich ist aus programmiertechnischer Sicht nicht die letzte Aktualisierung interessant, sondern eben die letzte Änderung bzw. der Zeitpunkt dieser. Ist einfach ein anderer Denkansatz. Aber ich habe verstanden was, warum und wie. Vielleicht ändert zunehmende Erfahrung meine Meinung dazu, aber derzeit ist für mich die letzte Abfrage eher sinnfrei, da dadurch ein getriggertes Notify nur immer und immer wieder ausgeführt  würde. Und das war mein größtes Problem am Anfang. Ich hatte ständig Aktionen ohne zu Wissen wer oder warum sie ausgelöst wurden. Bis ich irgendwann kapiert habe, das ein Notify eben bei JEDER Abfrage/Event ausgelöst wird, egal ob sich der Wert geändert hat oder nicht. Mag auch sein, dass situationsbezogen andere Einstellungen sinnvoll sind und ich hier einfach zu sehr von dem Problem ausgehe.

Dennoch habe ich zwei Fragen deren Beantwortung mir das Thema Notify weiter verständlich machen würde, ich aber bisher keine Antworten im Wiki oder der Commandref gefunden habe.
Erstens eine theoretische Ausgangssituation:
Ein Gerät, dass bei Benutzung in der Dunkelheit beleuchtet werden soll. Bedingung ist also, dass a) das Gerät eingeschaltet ist und b) ein Helligkeitssensor, Twillight-Modul oder vergleichbares die Dunkelheit feststellt. Nun gibt es mMn zwei Auslöser: 1) Das Gerät wird eingeschaltet - im Set-Befehl muss die Bedingung "b" geprüft werden, 2) Es wird Dunkel - im Set-Befehl muss die Bedingung "a" geprüft werden.
Gibt es eine Möglichkeit mit einem Notify oder anderem Modul beide Trigger und beide Bedingungen in einem Befehl unterzubringen?
Also nach dem Motto "Wenn Ereignis 1 oder Ereignis 2 eintritt, dann schalte, wenn Bedingung "a" und Bedingung "b" erfüllt sind, das zugehörige Licht ein. Eventuell auch mit einem DOIF.

Und zweitens einige Fragen zu Watchdog:
Verstehe ich es richtig, dass wenn Regexp 1 eintritt, der Befehl erst ausgeführt wird, wenn innerhalb der angegebenen Zeit nicht der Regexp2 eintritt?
Was ist wenn Regexp1 innerhalb der Zeit noch einmal eintritt?
Kann man den Trigger des Watchdog auch mit einem "externen" Notify zurücksetzen?

[Otto123]

Also nach dem Motto "Wenn Ereignis 1 oder Ereignis 2 eintritt, dann schalte, wenn Bedingung "a" und Bedingung "b" erfüllt sind, das zugehörige Licht ein.

Schon oft zitiert: https://wiki.fhem.de/wiki/Notify da stehen wirklich fast wortwörtlich diese Fragen und die Antworten dazu!
https://wiki.fhem.de/wiki/Notify#Einfache_ODER_Funktion
https://wiki.fhem.de/wiki/Notify#Einfache_UND_Funktion
oder einfach die Umsetzung Deines Textes:

Code Auswählen Erweitern

define n_bla notify (Ereignis.1|Ereignis.2) {if ("a" and "b") {fhem("set Licht an")}}
Merke:
- die Ereignisse/Trigger sind quasi ein ODER - es ist aber ein regExp! ODER ist hier simpel, alles andere ist aufwendiger.
- die Abfrage im Ausführungsteil ist Perl Code und damit völlig offen, im Beispiel ein UND.