10_CUL_MH Version 24158

Begonnen von sepultura30, 07 April 2021, 16:51:41

Vorheriges Thema - Nächstes Thema

MegaData

#30
Also generell steht bei motion immer nur "off" oder "on (to VCCU)".

Du hast Recht, ich triggere erstmal wenn eine Bewegung kommt und schaue dann ob der State vom Bewegungsmelder "motion" sendet. Falls das Licht aus ist, es dunkel genug ist, und wir beide daheim sind, schalte ich für 4 Minuten ein. Dadurch muss ich es durch FHEM nicht erneut ausschalten lassen.

Ich meine viele Wege führen nach Rom, was soll daran denn jetzt seid 3-4 Tagen falsch sein ? Klar - ich könnte auch auf motion:.on reagieren lassen... Da müsste ich aber alle meine Notifies für Bewegungsmelder umbauen... :-O


Ach ja, was mir noch eingefallen ist: wenn ich ein set Treppenbeleuchtung on abschicke, egal über die Kommandozeile oder über ein State-Icon... dann ging das Licht auch nur ne halbe Sekunde an und dann wieder aus - ganz unabhängig vom Bewegungsmelder. Ergo bekommt man das Licht überhaupt nicht mehr dauerhaft an...

frank

ZitatAch ja, was mir noch eingefallen ist: wenn ich ein set Treppenbeleuchtung on abschicke, egal über die Kommandozeile oder über ein State-Icon... dann ging das Licht auch nur ne halbe Sekunde an und dann wieder aus - ganz unabhängig vom Bewegungsmelder. Ergo bekommt man das Licht überhaupt nicht mehr dauerhaft an...

dann ist dein aktor defekt, oder ein weiteres doif mischt sich ein.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

MegaData

Nein ist er nicht. Ich habe die HMConfig.pm und die 10_CUL... zurück gespielt und alles funktioniert wieder normal.

Und DOIF verwende ich generell nicht.

Otto123

moin,

dann mischt sich ein anderes notify ein. Welches notify sendet den set Treppenbeleuchtung off Befehl?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

MegaData

Keins... ich setze einen on-for-timer - 4 Minuten... da brauchts doch keinen Off-Befehl ?

Gernott

Zitat von: MegaData am 11 April 2021, 11:36:00
Keins... ich setze einen on-for-timer - 4 Minuten... da brauchts doch keinen Off-Befehl ?
Kannst Du  mal alle notifys deaktivieren, das Log-File des Aktors aktivieren, falls nicht vorhanden, und mal ein on-for-timer abschicken? Das klingt ja bald so, als würde CUL-HM komplett falsche on-Zeiten an den Aktor abschicken. Bei mir sieht ein 5 s on so aus:
2021-04-11_12:02:35 hm.switch_KL.FlurLicht set_on-for-timer 5
2021-04-11_12:02:35 hm.switch_KL.FlurLicht commState: CMDs_processing...
2021-04-11_12:02:35 hm.switch_KL.FlurLicht trigLast: fhem:02
2021-04-11_12:02:35 hm.switch_KL.FlurLicht trigLast: fhem:02
2021-04-11_12:02:35 hm.switch_KL.FlurLicht commState: CMDs_done
2021-04-11_12:02:35 hm.switch_KL.FlurLicht deviceMsg: on (to vccu)
2021-04-11_12:02:35 hm.switch_KL.FlurLicht level: 100
2021-04-11_12:02:35 hm.switch_KL.FlurLicht pct: 100
2021-04-11_12:02:35 hm.switch_KL.FlurLicht on
2021-04-11_12:02:35 hm.switch_KL.FlurLicht timedOn: running
2021-04-11_12:02:42 hm.switch_KL.FlurLicht commState: CMDs_done
2021-04-11_12:02:42 hm.switch_KL.FlurLicht deviceMsg: off (to vccu)
2021-04-11_12:02:42 hm.switch_KL.FlurLicht level: 0
2021-04-11_12:02:42 hm.switch_KL.FlurLicht pct: 0
2021-04-11_12:02:42 hm.switch_KL.FlurLicht off
2021-04-11_12:02:42 hm.switch_KL.FlurLicht timedOn: off


Warum trigLast 2x kommt, weiß ich auch nicht...CUL-HM ist 24031.

frank

Zitat von: MegaData am 11 April 2021, 11:36:00
Keins... ich setze einen on-for-timer - 4 Minuten... da brauchts doch keinen Off-Befehl ?
es geht nicht darum, ob es einen off befehl braucht, sondern darum, dass scheinbar einer gesendet wird.

mach am besten einen eigenen thread auf und poste dort:

ein list vom aktor,
und die raw messages aus fhem.log vom on-for-timer befehl.
siehe wiki homematic sniffen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

the ratman

#37
also bei mir kommt langsam ein bissi handfesteres zusammen.

vielleicht kann man hier ja was mit anfangen:
https://forum.fhem.de/index.php/topic,120202.msg1148230.html#msg1148230

ich stell fest, ich krieg per state (dem ich wie im anderen fred beschrieben definitiv nicht überall ausweichen kann) nen haufen sinnloser meldungen mit - bis ich da mal von off zu on komme, hat der state schon x andere meldungen auch raus geworfen. das scheint den doif's dann übel aufzustoßen.

betrifft wohl: HM-SEN-RD-O, HM-SEC-SCO, HM-SEC-SC-2. teilweise HM-LC-SW1-BA-PCB und HM-LC-SW4-WM

was nun?
→do↑p!dnʇs↓shit←

frank

Zitatbis ich da mal von off zu on komme, hat der state schon x andere meldungen auch raus geworfen.
die sonne geht auf!  8)

Zitatdas scheint den doif's dann übel aufzustoßen.
nee, die machen dann einfach nur das, was in der DEF des doif für diese events definiert ist.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

the ratman

#39
Zitatnee, die machen dann einfach nur das, was in der DEF des doif für diese events definiert ist.
in den doifs ist bei mir definiert: mache dieses oder jenes, wenn der state auf on wechselt und mache was anders, wenn der state auf off geht. ich hab in keinem doif mittlerweile was stehen, dass auf irgend einen undeffinierten status reagieren soll, nicht mal mehr sowas wie [xxx:state] ne "off"

was muß ich nun noch tun, damit ich das problem los werde?
ich sags gern nochmal: ich habe hier eindeutig geräte, die nur am state ihren status geben, ich kann auf kein anderes reading ausweichen.


btw - ists eigentlich üblich, dass ein händisches update des watchdogs bei 29 geräten gleich mal 5% load beim hmlan macht?
hab das ja nie wirklich beobachtet, aber irgendwie scheint mir das schon ein haufen zu sein.
und da hat kein doif was mit zu tun *g*
→do↑p!dnʇs↓shit←

frank

bei doif halte ich mich raus. das ist zu schwer für mich.
man muss grundsätzlich in jedem zweig nur die events zulassen, die man dort benötigt.

Zitatdass ein händisches update des watchdogs
was für ein update bei was für einem watchdog. ich verstehe nur bahnhof.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

the ratman

#41
tschuldige, so nenn ich den - ist der "actiondetector".
das gute tool also, daß mir das leben meiner hm batteriegeräte anzeigt.


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.
meines erachtens kann das nur probleme geben, wenn ich anstelle "eq" ein "ne" verwende, um div. andere zustände abzudecken. das hab ich jetzt so weit wie möglich raus, aber nicht überall.

als beispiel will ich eine rollo ganz zu fahren, wenn es regnet - soweit so gut.
da die aber ja nicht nur on und off können, sondern auch die pct-werte zw. 1 und 99 am state liefert, hab ich ein zusätzliche IF in div. doifs eingebaut. z.b.: ( IF ([schlafzimmer_rollo:state] ne "on" ) (set schlafzimmer_rollo on)   )
mein wissen reicht da nicht aus, um z.b. zu sagen, wenn "off" oder "0-99", dann "on".
gut, bei vielen aktoren kann ich dann rein auf pct gehen, aber das geht eben nicht überall.
das es zu problemen führen kann, wenn der aktor die ganze zeit was rein schreit, kann ich mir vorstellen. nur, was tun?
→do↑p!dnʇs↓shit←

Otto123

Zitat([terrasse_regensensor_regenanzeige:state] eq "rain") kann für mein empfinden auch nur triggern, wenn im state "rain" steht
nein so ist DOIF nicht.
Es wird durch irgendein Event für das Gerät terrasse_regensensor_regenanzeige getriggert und anschließend wird das Reading state abgefragt.
Wenn also 27 einzelne Events für die Aktualisierung von 23 Readings und 4 Statusmeldungen erfolgen, wird das DOIF 27 mal triggern und jedes mal wird das Reading abgefragt, ausgewertet und wenn (sich das reading state auch gar nicht ändert) die Abfrage wahr ergibt - im blödesten Fall auch 27 mal der Ausführungsteil ausgeführt!

In state kann zwischenzeitlich alles mögliche stehen, wenn man also sichergehen will:

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

Allgemein also in etwa so:
(["^DEVICE$:^Event$"] and [?DEVICE:reading])
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frank

Zitattschuldige, so nenn ich den - ist der "actiondetector".
das gute tool also, daß mir das leben meiner hm batteriegeräte anzeigt.
der actiondetector von cul_hm erzeugt normaler weise NULL load.

der sammelt nur "lebenszeichen" ein und merkt sie sich.
beim update berechnet er nur, ob nun devices dead sind.

nur wenn das attr autoActTry=1 gesetzt ist, wird bei einem möglicher weise als dead zu kennzeichnenden device einmalig noch ein statusrequest versucht.

bei 5% load hast du entweder einen anderen actiondetector, oder du hast hier auch irgendwelche doifs, die komische sachen machen.


ich kenne keinen aktor der nicht die readings level oder pct hat.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

the ratman

#44
wir drehen uns im kreis ...

zuerst mal thx für die infos. nutzt halt nix, wenn es eben nur state gibt und kein anders reading. die entsprechenden sensoren hab ich aufgeführt.
als bspl. regensensor kanal für die anzeige des regens:

    READINGS:
     2021-04-11 21:30:52   R-sign          off
     2021-04-11 21:41:57   RegL_01.        00:00 08:00 22:64 23:00 30:06 87:0B 88:54 8B:0B 8C:22 8F:3C 91:82
     2021-04-11 21:41:57   cfgState        ok
     2021-04-12 08:32:12   commState       CMDs_done_Errors:1
     2021-04-12 08:32:12   lastRain        2021-04-11 20:48:45
     2021-04-12 08:32:12   recentStateType info
     2021-04-12 08:32:12   state           dry
     2021-04-12 08:32:12   timedOn         off
auf was, außer state, soll ich da triggern, wenn ich wissen will, obs regnet oder nicht?
die errors kommen jetzt, weil der sensor selber auf dummy 1 steht.

@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.
in dem fall könnte ich nur eine readingsgroup anbieten für batterieanzeige:<homematic>
TYPE=CUL_HM:battery


Zitatich kenne keinen aktor der nicht die readings level oder pct hat.
ich schon, aber nehmen wir nur mal den regensensor! ich mag mich ja nicht wirklich mit euren modulen, perl oder irgendwelchen programmiertechniken auskennen, aber lesen kann ich schon noch.
→do↑p!dnʇs↓shit←