10_CUL_MH Version 24158

[Otto123]

na dann frag von mir aus den state ab aber triggere auf was anderes (kenne die Events vom Regensensor nicht)
state selbst liefert normal kein spezifisches Event

oder mach es in dem Fall so und frag alle anderen Bedingungen nur ab!
(["^DEVICE$:^state: rain$"])

Code Auswählen Erweitern

attr DeinDoif addStateEvent

Aber sag jetzt nicht das gilt immer! 

[the ratman]

ich blicks grade nicht, was mit "gilt immer" (und dem meisten rest) gemeint ist.

und vor allem blick ich schon gar nicht, warum - was auch immer - jetzt nach jahren auf einmal ein problem ist. der ganze schrott ist doch problemlos gelaufen, warum jetzt nicht mehr?

könntet ihr bitte allgemein den level auf "dummy" senken für mich?

[frank]

nö, is bei mir nicht ein, ich hab nur 3 mal auf update gedrückt. dann hatte ich einen load von 17%, vorher warens 2%. nick knatterton hat dann vermutet: passt super zu meinen aktionen.

mach mal ein neuen ratman-actiondetector-chaos-thread auf und poste dort ein list vom actiondetector.

[the ratman]

erledigt.

und was heißt bitte chaos?
ich hab ein problem, man antwortet mir freundlicher weise mit div. fragen, ich versuche die fragen so umfangreich wie es mir möglich ist zu beantworten - gern auch mehrfach - um möglichst viele folgefragen raus zu nehmen.
mach ich was falsch?

[Otto123]

könntet ihr bitte allgemein den level auf "dummy" senken für mich?

Ich dachte da bin ich schon die ganze Zeit 
"gilt immer" meint: es gibt mit Sicherheit kein universal Lösung sondern das ist die ev. Lösung für deinen Regensensor. Ich weiß doch nicht was Deine 25 DOIFs machen. 

Das es bisher funktionierte lag daran, dass unvorsichtigerweise die bisherige Lösung unter der Annahme stand: Es gibt einen Event und damit ist es ganz einfach. Es war schon immer ein böses Erwachen wenn dann plötzlich mehrfache Übertragungen (Events) auftauchten oder so was. Das wird häufig mit dem Allheilmittel attr ... eocr .* behoben. Ja kann sein es hilft - aber besser ist schon immer nur darauf zu reagieren was relevant ist. Ich kann mich da nur wiederholen: Am besten so umbauen, dass genau eine Reaktion auf ein Ereignis erfolgt. 

[the ratman]

wie bei nem vortrag: interessierte ingenieure und darüber auf niveau 14 jährige und alles andere für unter 12 jährige erzählen. geh bei mir in sachen fhem bitte auf 5 bis 6 oder mal mir bilder mit lustigen tierchen ... das könnte dann vielleicht funktionieren *g*

ich weiß auch ned, was die doifs machen.
mittlerweile warscheinlich viel weniger als noch vor 2 tagen. hab ordentlich ausgemistet, und dann versucht, alles, was mit hm zu tun hat und ein "ne" in der abfrage hat ebenfalls zu ersetzen. was mir aber nicht vollständig gelingen mag.
ich kann dir die dinger aber gern mal alle auf einmal um die ohren hauen.
warscheinlich lachst du dann die ersten 5 minuten bist du gar bitterlich zu weinen beginnst ...

Am besten so umbauen, dass genau eine Reaktion auf ein Ereignis erfolgt.

und dazu würdest du im doif folgendes eintragen:

ich kann das addstateevent aber nur auf 0 oder 1 setzen - wo kommt dann (["^DEVICE$:^state: rain$"]) hin?

[Otto123]

was doif angeht:
eine abfrage wie z.b. ([terrasse_regensensor_regenanzeige:state] eq "rain") kann für mein empfinden auch nur triggern, wenn im state "rain" steht. ob dort sonst "dry" oder "was anderes" steht, müßte doch egal sein. ob es das intern auch so tut, muß wer anderer sagen.

Anstatt ([terrasse_regensensor_regenanzeige:state] eq "rain") schreibst Du (["^terrasse_regensensor_regenanzeige$:^state: rain$"])

ich kann das addstateevent aber nur auf 0 oder 1 setzen

Ja, das ist das lustige wenn Du nichts hinschreibst wird 1 gesetzt 

[the ratman]

danke dir, wird probiert, sobald ich mal wieder 5 min. zeit hab.

[sigma415]

Ich hänge mich hier mal dran...

Ich habe zwei 6-fach-Taster, die mit DOIFs abgefragt werden. Seid dem Update auf o.g. Version werden bei Betätigen eines beliebeigen Tasters die Funktionen aller Taster ausgeführt.
...

Hallo zusammen,

hat jemand mal probiert, ob dieses und die weiteren Probleme aus dem Thread in den nachfolgenden 10_CUL_HM-Versionen behoben sind ? (aktuell 24449 vom 16.05.2021)

Würde irgendwann mal gerne das "exclude_from_update" wieder rausmachen ....

[LuckyDay]

werden bei Betätigen eines beliebeigen Tasters die Funktionen aller Taster ausgeführt

da wird sich wenig ändern--> die notify-doif besser einschränken

nimmt man einen ganz spezifischen Event und triggert damit das DOIF
    wertet man ein spezifisches Reading und nicht state aus.

[noansi]

Hallo sigma415,

ob dieses

Dieses Problem hier ist kein grundsätzliches CUL_HM Problem, sondern zunächst nur eine Verhaltensänderung. Das Problem hier sind zu unspezifische Eventauswertungen und das ist ein Anwenderthema.

Und die Verhaltensänderung ist auch nicht in aktueller Version auf weniger Events zurück geändert, wenn ich es nicht übersehen habe. Die betreffende Zeile enthält nur seit dem letzten (?) einen Kommentar dazu. Für irgendwas scheint Martin die Events zu benötigen.

Gruß, Ansgar.

[Sany]

@ the ratman

Moin,
vielleicht kann ich Deine "Verwirrung" etwas "entwirren". Bin auch gerade dabei, meine DOIF's "triggerfest" umzustellen.
Es stimmt tatsächlich, dass der Regensensor außer state kein anderes nutzbares Reading hat. Die anderen von Dir genannten HM-Komponenten allerdings schon.
Gib mal in fhem folgendes ein:

list TYPE=CUL_HM model deviceMsg contact motion

Du bekommst eine (lange) Liste mit allen Deinen HM-Komponeneten. Wenn vorne in der Liste ein Zeilenabstand ist hat das Device eines der gesuchten Readings. Ist kein Zeilenabstand dann ist ausser model nichts angegeben. Das wird beim Regensensor so sein. Bei den anderen hast Du contact (z.B. HM-SEC-SCO, HM-SEC-RHS), deviceMsg (z.B. HM-LC-SW1-BA-PCB, HM-LC-SW1-PL-DN-R1) oder motion (HM-SEN-MDIR-SM). Diese Readings liefern (offensichtlich) den eindeutigen Zustand.
Beispiel Fensterkontakt (ohne eocr.. Einschränkung)

2021-05-19 10:15:46.186 CUL_HM hm_TestSensor battery: ok
2021-05-19 10:15:46.186 CUL_HM hm_TestSensor commState: CMDs_done
2021-05-19 10:15:46.186 CUL_HM hm_TestSensor contact: open (to myVCCU)
2021-05-19 10:15:46.186 CUL_HM hm_TestSensor open
2021-05-19 10:15:46.186 CUL_HM hm_TestSensor trigger_cnt: 57
2021-05-19 10:15:46.186 CUL_HM hm_TestSensor daysSinceLastBatt: 448

2021-05-19 10:15:47.994 CUL_HM hm_TestSensor battery: ok
2021-05-19 10:15:47.994 CUL_HM hm_TestSensor commState: CMDs_done
2021-05-19 10:15:47.994 CUL_HM hm_TestSensor contact: closed (to myVCCU)
2021-05-19 10:15:47.994 CUL_HM hm_TestSensor closed
2021-05-19 10:15:47.994 CUL_HM hm_TestSensor trigger_cnt: 58
2021-05-19 10:15:47.994 CUL_HM hm_TestSensor daysSinceLastBatt: 448

Beispiel Funksteckdose:

2021-05-19 10:26:05.262 CUL_HM Steckdose_StehlampeTV commState: CMDs_pending
2021-05-19 10:26:05.984 CUL_HM Steckdose_StehlampeTV set_on noArg
2021-05-19 10:26:06.124 CUL_HM Steckdose_StehlampeTV commState: CMDs_processing...
2021-05-19 10:26:06.262 CUL_HM Steckdose_StehlampeTV trigLast: fhem:02

2021-05-19 10:26:12.040 CUL_HM Steckdose_StehlampeTV commState: CMDs_done
2021-05-19 10:26:12.040 CUL_HM Steckdose_StehlampeTV deviceMsg: on (to myVCCU)
2021-05-19 10:26:12.040 CUL_HM Steckdose_StehlampeTV level: 100
2021-05-19 10:26:12.040 CUL_HM Steckdose_StehlampeTV pct: 100
2021-05-19 10:26:12.040 CUL_HM Steckdose_StehlampeTV on
2021-05-19 10:26:12.040 CUL_HM Steckdose_StehlampeTV timedOn: off
2021-05-19 10:26:20.762 CUL_HM Steckdose_StehlampeTV commState: CMDs_pending
2021-05-19 10:26:21.533 CUL_HM Steckdose_StehlampeTV set_off noArg
2021-05-19 10:26:21.685 CUL_HM Steckdose_StehlampeTV commState: CMDs_processing...
2021-05-19 10:26:21.840 CUL_HM Steckdose_StehlampeTV trigLast: fhem:02

2021-05-19 10:26:23.993 CUL_HM Steckdose_StehlampeTV commState: CMDs_done
2021-05-19 10:26:23.993 CUL_HM Steckdose_StehlampeTV deviceMsg: off (to myVCCU)
2021-05-19 10:26:23.993 CUL_HM Steckdose_StehlampeTV level: 0
2021-05-19 10:26:23.993 CUL_HM Steckdose_StehlampeTV pct: 0
2021-05-19 10:26:23.993 CUL_HM Steckdose_StehlampeTV off
2021-05-19 10:26:23.993 CUL_HM Steckdose_StehlampeTV timedOn: off

Es kommen also jede Menge Events, die man vermutlich nie alle braucht. Also auf das nötigste Beschränken mittels event-on-change-reading xxx. Damit werden alle Events von nicht gewählten Readings unterdrückt, die gewählten Readings erzeugen nur bei Änderung einen Event. Bei den Fensterkontakten lasse ich z.B. nur noch contact, battery,sabotageError und Activity durch, mittels event-min-interval battery:3600 darf die Batterie stündlich ihren Zustand melden, auch wenn er sich nicht ändert.

Jetzt gehts nochmal um DOIF, wie das so tickt (hat Otto eigentlich schon erklärt):
Man sollte sich klar machen, ob man eine Zustand eines Readings "abfragen" möchte oder ob ein Event eines Readings etwas auslösen soll. Beispiel: Türkontakt und Regensensor:
Ich möchte eine Ansage "es regnet" wenn es regnet und ich die Tür öffne. Also ist der Trigger die Tür, der Zustand des Regensensors wird abgefragt:

Code Auswählen Erweitern

DOIF (["^Tuer$:^contact:.open"] and [?Regensensor] eq "rain")(...Ansage)
["^Tuer$:^contact:.open"] bedeutet: Es wird der Event genommen (Hochkomma), das Device beginnt ^ mit Tuer und endet $ mit Tuer, es heisst also GENAU Tuer, das Reading und der Wert contact:.open beginnt nur genau mit contact, weil hinter open/closed hier noch (to VCCU) oder so stehen kann. Das ist bei mir unterschiedlich und nicht wichtig. Der Trigger ist so eindeutig definiert. Du kannst Dir das so vorstellen, dass der Türkontakt diesen Event sendet und DOIF hat eine "Schablone", wo genau dieser Event reinpasst. Schickt ihn der Schalter, wird in und für diesen Moment diese Bedinung wahr. Dann kommt die Abfrage  [?Regensensor:state] eq "rain", die durch das Fragezeichen nicht triggert. Kommt also der Tür-Event und es regnet wird die Bedingung wahr und der Ausführungsteil wird abgearbeitet (Ansage...)
Bei eine Definition wie [Regensensor:state] eq "rain" ist es so, dass das DOIF bei jedem Event von "Regensensor" angetriggert wird und dann die Bedinung überprüft wird. Die Bedingung wird also wahr, wenn sich der state von dry auf rain ändert, aber auch, wenn der Regensensor irgend etwas anders liefert und state auf rain steht. Bei FS20 Sendern ist das ziemlich egal, bei Homematic gibts aber mittlerweile so viele Events, dass man darauf genau achten muss.
Zurück zum Regensensor:
Mit ["^terrasse_regensensor_regenanzeige$:^rain$"] und ["^terrasse_regensensor_regenanzeige$:^dry$"] filterst Du exact nach den beiden relevanten Events. Das funktioniert bei mir jetzt zu 100% (gibt ja gerade reichlich Schauer....)

Ob das DOIF richtig funtioniert kannst Du auch mit

trigger terrasse_regensensor_regenanzeige rain

und

trigger terrasse_regensensor_regenanzeige dry

ausprobieren, wenn es gerade nicht schauert 

Ansonsten, auch wenn es schon etwas abgedroschen klingt: die Kapitel "Ereignissteuerung" und "Ereignissteuerung über Auswertung von Events" in der Commandref zu DOIF kann man gar nicht oft genug lesen....
Vor dem DOIF-schreiben würde ich immer das Device (Tükontakt/Regensensor etc) per EventMonitor beobachten und alle möglichen Zustände auslösen. Aus dem EventMonitor kannst Du dann die DOIF Definition fast immer 1:1 übernehmen.


Viel Erfolg!

Edit: das ist auch noch interessant zum Thema:
https://forum.fhem.de/index.php/topic,115785.msg1100628.html#msg1100628

[frank]

hallo Sany,

du solltest deine beispiele noch mehr eingrenzen, da es bei gepeerten devices sonst trotzdem mehrfache events gibt.

jeder peer erzeugt ein weiteres "...(to <peer>)" event.
und wenn die kommunikation gestört ist, kommen eventuell noch weitere events hinzu.

gruss frank

[Sany]

Hallo frank,

danke für den Hinweis. Mein hm_TestSensor ist natürlich der einzige im Haus, der nicht gepeert ist. Alle anderen sind mit einem Thermostaten gepeert und entsprechend kommen 2 Meldungen. Ein Kurzer Versuch hat gezeigt, dass zuerst der Thermostat und dann die VCCU dran ist, mit ca 1,5 sec Unterschied! Kannst Du sagen, dass die Reihenfolge immer gleich ist oder kann das auch beliebig sein?
Dann kann man natürlich im DOIF auf diese Events gezielt triggern, und wenn das bei der Reihenfolge tatsächlich so ist dann z.B. bei "open" auf den ersten contact Event und bei "closed" auf den 2ten. Wenn die Reihenfolge nicht immer gleich ist dann eben doch nur auf das open oder closed triggern und eine weitere Ausführung innerhalb weniger Sekunden im DOIF unterdrücken. Ich muss da mal meine HM-Komponenten eine Weile beobachten.

Aber allgemein gesagt scheint es keinen eindeutigen Event zu geben, um z.B. bei einem Türkontakt auf open/closed zu triggern. Also mit Reading. Finde ich schon etwas seltsam. Das state alles Mögliche erzählen kann, daran habe ich ich schon fast gewöhnt. Das contact auch verschiedene "open's" und "closed's" erzählen kann machts in der Anwendung nicht wirklich einfach. Mal sehen, was da sonst noch so raus kommt. Vielleicht sogar die Quelle für CPU-Last-Anstiege wenn Türen oder Fenster geöffnet werden....
OK, ist alles etwas OT, bezog sich hauptsächlich auf den Post von the ratman.

Sany

[frank]

hallo sany,

der fk sendet nun mal an jeden peer und die centrale. warum sollte man die unterschiedlichen infos unter den tisch fallen lassen. es ist doch ein leichtes, auf nur ein event zu reagieren.

das einfachste ist doch immer, den ganzen string zu nehmen.
wenn ich deine erklärung für doif verstehe, dann wohl zb so:
["^Tuer$:^contact:.open.(to.vccu)$"]

ob die reihenfolge immer gleich ist, würde ich nicht drauf wetten. vielleicht fw abhängig?

oder mit einem userreading open/close aus contact holen, welches zusammen mit eocr nur noch 1x open/close im userreading zulässt.
ist aber eigentlich unnötige, zusätzliche belastung.

das userreading hätte bei gepeerten devices den vorteil, dass auch mal eine message "verloren" gehen kann.