[GELÖST] Dimmer mit Bewegungsmelder und Helligkeitssensor peeren und schalten

Begonnen von darkness, 19 Oktober 2017, 11:15:15

Vorheriges Thema - Nächstes Thema

darkness

Hallo,

ich habe mal eine Verständnisfrage.

Bisher schalte ich einen Dimmer HM-LC-Dim1TPBU-FM per notify.

Dieses triggert auf die Bewegung eines  HM-Sen-MDIR-WM55 wenn die Außenhelligkeit  (HM-Sen-LI-O) unter einen Wert X fällt.
Anstatt des HM-Sen-MDIR-WM55 nutze ich den HM-Sen-LI-O, da dieser kontinuierlich sendet.

Nach meinem Verständnis kann ich sowas nicht mit direktem peering lösen oder?



Pfriemler

Jein. Das Stichwort heißt "virtueller Kanal". Nagle mich bitte nicht auf Details fest, für mich ist das selbst ein Buch mit ca. 6,5 Siegeln bzw. ich habe es aus FHEM noch nicht sauber hinbekommen.

Prinzipiell kannst Du den physikalischen Kanal (den 1.) des PBU-FM mit einem virtuellen (2. bzw. 3.) koppeln, also bspw. maskieren, hier etwa in dem Stil "schalte physikalisch nur, wenn der virtuelle auch eingeschaltet ist". Den virtuellen kannst Du dann mit dem HM-Sen-Li-O koppeln (geht dann quasi auf Dauer an, wenn Helligkeit unterschritten), den physikalischen mit dem Bewegungsmelder. Es gibt dann aber einen wesentlichen Haken: Der Dimmer geht auch von Hand nur, wenn es dunkel genug ist.

Diese Verknüpfung ist btw eine der Aktionen, wegen derer ich früher einen Konfigurationsstick und die passende Software aus der Schublade geholt habe...
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

darkness


martinp876

Direkt geht es nicht, korrekt.
Über einen virtuellen Aktor könnte man das leisten, ist aber nicht implementiert.
Aber wenn man es über einen virtuellen Aktor macht geht es über die Zentrale..... Und dann kann man gleich ein notify nehmen.

Zur direkten Kopplung von mdir und Lichtschaltern habe ich ein template veröffentlicht welches das onfortimer durch den mdir erlaubt und durch einen anderen Taster überschrieben werden kann, also Dauer on. Geht alles ohne Zentrale.

frank

Zitat von: Pfriemler am 19 Oktober 2017, 15:46:27
Jein. Das Stichwort heißt "virtueller Kanal". Nagle mich bitte nicht auf Details fest, für mich ist das selbst ein Buch mit ca. 6,5 Siegeln bzw. ich habe es aus FHEM noch nicht sauber hinbekommen.

Prinzipiell kannst Du den physikalischen Kanal (den 1.) des PBU-FM mit einem virtuellen (2. bzw. 3.) koppeln, also bspw. maskieren, hier etwa in dem Stil "schalte physikalisch nur, wenn der virtuelle auch eingeschaltet ist". Den virtuellen kannst Du dann mit dem HM-Sen-Li-O koppeln (geht dann quasi auf Dauer an, wenn Helligkeit unterschritten), den physikalischen mit dem Bewegungsmelder. Es gibt dann aber einen wesentlichen Haken: Der Dimmer geht auch von Hand nur, wenn es dunkel genug ist.

ich könnte mir vorstellen, wenn man die self-peers mit einem weiteren virtuellen channel peert, dass man dann auch manuell "übersteuern" könnte. habe ich aber noch nie probiert.

hier mal etwas lektüre: https://www.elv.de/elektronikwissen/virtuelle-homematic-aktorkanaele-und-ihre-verknuepfungslogik.html
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

darkness

Wow danke.
ZitatÜber einen virtuellen Aktor könnte man das leisten, ist aber nicht implementiert

Mit FHEM kann ich das ganze dann aber nicht umsetzen, oder?

ZitatAber wenn man es über einen virtuellen Aktor macht geht es über die Zentrale..... Und dann kann man gleich ein notify nehmen.

Laut dem Artikel wäre es aber ohne Zentrale möglich, oder?

Da unter dem Dimmer ein Bewegungsmelder ist, könnte ich das Licht auch darüber schalten. Wäre also nicht so schlimm, wenn der Dimmer selbst nicht mehr geht.

martinp876

Die virtuellen Kanäle Dienstag dimers sind voll umgänglich in fhem vorhanden.
Unklar ist mir, dass ein Aktor (auch der virtuelle) auf einen Sensorwert reagieren kann. Das ist kein Trigger. Allerdings ist das schon möglich, muss man testen.
Wenn das geht, dann ist es kein. Problem

Beta-User

Kann ich da was helfen bzw. mit testen?

Persönliches Ziel wäre es, den Helligkeitwert eines Bewegungsmelders (HM-Sen-MDIR-O) auszuwerten, und dann bei Unterschreitung eines Mindestwerts einen Switch eines HM-LC-SW2-FM einzuschalten (für eine bestimmte Dauer, versteht sich), wenn eine Tür mit einem HM-SEC-SC-2 geöffnet wird. Das setup habe ich 2 Mal bzw. für je einen Türkontakt pro Switch...

Der Bewegungsmelder ist bereits mit dem LC-SW2 gepairt, allerdings triggert der MDIR ja nur, wenn eine auf diesem Gerät eingestellte Mindesthelligkeitsschwelle unterschritten ist, das scheint also auf dem MDIR gespeichert zu sein...

Wenn das nicht hierher gehört, können wir das gerne auch separat diskutieren, ich will den Thread nicht kapern ;) .

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Pfriemler

Zitat von: Beta-User am 20 Oktober 2017, 21:13:41
Der Bewegungsmelder ist bereits mit dem LC-SW2 gepairt, allerdings triggert der MDIR ja nur, wenn eine auf diesem Gerät eingestellte Mindesthelligkeitsschwelle unterschritten ist, das scheint also auf dem MDIR gespeichert zu sein...
Woher hast Du das? Meine Bewegungsmelder senden jede Bewegung, unabhängig von der Tageszeit oder Helligkeit. Vielmehr habe ich aus dem Vergleich von Verknüpfungen mithilfe des HomeMatic-Konfigurators und dem nachfolgenden Einlesen der Register in FHEM die Erkenntnis, dass beim Direktverknüpfen die Einschaltbedingungen im Aktor für den Peerpartner Bewegungsmelder auf "ltLo" geändert werden (d.h. Aktor schaltet bei Werten unter der Schwelle ein) und die Lo-Schwelle wird der gewünschten Maximalhelligkeit entsprechend reduziert (bei mir von 50 auf 20 für fast völlige Dunkelheit mit einem MDIR-O). Meines Wissens machen auch die Templates nichts anderes. Wenn man die Pakete snifft, sieht man sogar, dass bei größerer Helligkeit der angesprochene Aktor das Paket vom Bewegungsmelder quittiert, anschließend aber angibt, dass er ausgeschaltet bleibt.

Das gewünschte Ziel (allein mit Peering) halte ich hier aber für nicht erreichbar, weil dem HM-LC-Sw2-FM die dafür erforderlichen Verknüpfungskanäle für die Verbindung von Daten mehrerer Sensoren für eine Schaltentscheidung fehlt.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Beta-User

Zitat von: Pfriemler am 20 Oktober 2017, 21:25:28
Woher hast Du das? Meine Bewegungsmelder senden jede Bewegung, unabhängig von der Tageszeit oder Helligkeit.
Stimmt, kann eigentlich nicht so sein, dass der MDIR das aussortiert, Bewegung (bzw. auchregelmäßig Helligkeit) wird immer gesendet.

In den Registern des Aktors kann ich allerdings nicht erkennen, wie die Logik intern abgebildet wird:
CFGFN DEF        2A192901 NAME       Aussenlicht_vorne_Sw_01 NOTIFYDEV  global NR         192 NTFY_ORDER 50-Aussenlicht_vorne_Sw_01 STATE      off TYPE       CUL_HM chanNo     01 device     Aussenlichter peerList   self01,Bewegungsmelder_1, READINGS: 2017-10-20 21:27:13   CommandAccepted yes 2017-10-20 21:01:09   R-Bewegungsmelder_1_chn-01-lgActionType jmpToTarget 2017-10-20 21:01:09   R-Bewegungsmelder_1_chn-01-shActionType jmpToTarget 2017-10-20 21:01:08   R-self01-lgActionType jmpToTarget 2017-10-20 21:01:08   R-self01-shActionType jmpToTarget 2017-04-23 08:48:03   R-sign          off 2017-10-20 21:01:06   RegL_01.         08:00 00:00 2017-10-20 21:01:09   RegL_03.Bewegungsmelder_1_chn-01  02:22 03:22 04:78 05:64 06:00 07:7E 08:00 09:FF 0A:01 0B:13 0C:13 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63 00:00 2017-10-20 21:01:08   RegL_03.self01   02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63 00:00 2017-10-20 21:32:33   deviceMsg       off (to broadcast) 2017-10-20 21:32:33   level           0 2017-10-20 21:32:33   pct             0 2017-10-20 21:01:06   peerList        self01,Bewegungsmelder_1, 2017-10-20 21:32:33   recentStateType info 2017-10-20 21:32:33   state           off 2017-10-20 21:32:33   timedOn         off helper: peerIDsRaw ,2A192901,2D84F801,00000000 expert: def        1 det        0 raw        1 tpl        0 role: chn        1 shadowReg: tmpl: Attributes: group      Licht icon       FS20.off model      HM-LC-SW2-FM peerIDs    00000000,2A192901,2D84F801, room       Garten,Treppenhaus webCmd     statusRequest:toggle:on:off Aber wenn ich den Artikel richtig verstanden habe, müßte man derartige internen Auswertungen schon hinbekommen können. Hmmm, aber mit FHEM-Bordmitteln die Register/jumptable etc. anpassen...?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Pfriemler

#10
Ups... kopiert aus "list ..."? Sehe keine Zeilenumbrüche.

Diese Direktverknüpfung schaltet bei einer sehr geringen Raumhelligkeit den Dimmer für das Deckenlicht auf 20%:

Internals:
...
   NAME       HM_RGB1_Dim
...
   peerList   FB12_Btn_01,FB12_Btn_02,Wz6TasterRightDown,Wz6TasterRightUp,BewMelder2,DispFB_Btn_01,
   READINGS:
...
     2017-01-04 18:12:02   .R-BewMelder2_chn-01-shCtDlyOff ltLo  # alle Trigger auf geringere Helligkeit als ...
     2017-01-04 18:12:02   .R-BewMelder2_chn-01-shCtDlyOn ltLo
     2017-01-04 18:12:02   .R-BewMelder2_chn-01-shCtOff ltLo
     2017-01-04 18:12:02   .R-BewMelder2_chn-01-shCtOn ltLo
     2017-01-04 18:12:02   .R-BewMelder2_chn-01-shCtRampOff ltLo
     2017-01-04 18:12:02   .R-BewMelder2_chn-01-shCtRampOn ltLo
     2017-01-04 15:04:56   .R-BewMelder2_chn-01-shCtValHi 100
     2017-01-04 18:12:02   .R-BewMelder2_chn-01-shCtValLo 20     # Schaltschwelle
...
     2017-01-04 18:12:02   .R-BewMelder2_chn-01-shOnTime 300 s      # 5 min
     2017-01-04 18:12:02   .R-BewMelder2_chn-01-shOnTimeMode minimal  # mindestens, wenn nicht andere peers längere Zeit vorgeben
     2017-05-08 11:43:29   .R-BewMelder2_chn-01-shRampOffTime 10 s  # langsam ausdimmen
     2017-05-08 11:43:29   .R-BewMelder2_chn-01-shRampOnTime 2 s  # langsam hochdimmen
     2017-01-04 15:04:56   .R-BewMelder2_chn-01-shRampSstep 5 %
...
     2017-06-25 23:01:18   R-BewMelder2_chn-01-shActionTypeDim jmpToTarget
     2017-06-25 23:01:18   R-BewMelder2_chn-01-shOnLevel 20 %   # 20% Helligkeit (Orientierungslicht)
...
     2017-10-20 22:00:34   deviceMsg       70 (to BewMelder2) # er redet mit dem Bewegungsmelder direkt


Vergleich mal Deine Register damit. Hab die relevanten kopiert und kommentiert.

edit: Entweder Template verwenden oder alles mit regSet von Hand programmierbar.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

darkness

#11
Mir ist noch nicht ganz klar, wie ich die Bedingungen setzen kann. Oder Spiegelt das die internen Register wieder?

Siehe die Doku von Pfriemler:

Zitat
    Kanal inaktiv: Der Kanal wird bei der Verknüpfung ignoriert.
    OR: Das Verknüpfungsergebnis ist der höhere von beiden Pegeln.
    AND: Das Verknüpfungsergebnis ist der niedrigere von beiden Pegeln.
    XOR: Ist nur einer der Pegel größer als 0 %, ist dieser Pegel auch das Verknüpfungsergebnis. In den anderen Fällen ist das Verknüpfungsergebnis 0 %.
    NOR: Es wird die Verknüpfung OR ausgeführt und das Ergebnis anschließend invertiert (100 % - Pegel).
    NAND: Es wird die Verknüpfung AND ausgeführt und das Ergebnis anschließend invertiert (100 % - Pegel).
    OR_INVERS: Der zu verknüpfende Kanal (rechts vom ,,o") wird zuerst invertiert (100 % - Pegel) und anschließend die Verknüpfung OR ausgeführt.
    AND_INVERS: Der zu verknüpfende Kanal (rechts vom ,,o") wird zuerst invertiert (100 % - Pegel) und anschließend die Verknüpfung AND ausgeführt.
    PLUS: Die beiden Pegel werden addiert (max. 100 %).
    MINUS: Die beiden Pegel werden subtrahiert (min. 0 %).
    MULTI: Die beiden Pegel werden multipliziert.
    PLUS_INVERS: Der zu verknüpfende Kanal (rechts vom ,,o") wird zuerst invertiert (100 % - Pegel) und anschließend die Verknüpfung PLUS ausgeführt.
    MINUS_INVERS: Der zu verknüpfende Kanal (rechts vom ,,o") wird zuerst invertiert (100 % - Pegel) und anschließend die Verknüpfung MINUS ausgeführt.
    MULTI_INVERS: Der zu verknüpfende Kanal (rechts vom ,,o") wird zuerst invertiert (100 % - Pegel) und anschließend die Verknüpfung MULTI ausgeführt.
    INVERS_PLUS: Die beiden Pegel werden addiert (max. 100 %) und das Ergebnis anschließend invertiert (100 % - Pegel).
    INVERS_MINUS: Die beiden Pegel werden subtrahiert (min. 0 %) und das Ergebnis anschließend invertiert (100 % - Pegel).
    INVERS_MULTI: Die beiden Pegel werden multipliziert und das Ergebnis anschließend invertiert (100 % - Pegel).



Werde morgen mal Testen.

ZitatDie virtuellen Kanäle Dienstag dimers sind voll umgänglich in fhem vorhanden.
Ah, da ist dann Channel 02 und 03 bei den Dimmern?

Pfriemler

ZitatSiehe die Doku von Pfriemler:...
Äh ... der Link ist von frank, aber gut.

ZitatAh, da ist dann Channel 02 und 03 bei den Dimmern?
You got it.
Im Prinzip lassen sich alle Kanäle einzeln peeren, bedienen und manipulieren. Das sichtbare Endergebnis ist dann die beschriebene logische Kombination aus den drei Kanälen, wobei die Gewichtung jedes Kanals im Register "logicCombination" festgelegt.
Der verlinkte Beitrag beschreibt übrigens mMn den gewünschten Anwendungsfall: Kanal 1 mit Bewegungsmelder (OR), Kanal 2 als Helligkeitsmaske (AND) und Kanal 3 manuelle Bedienung mit 100% (OR)...
Dazu muss der Taster aber mit dem dritten und nicht mit dem ersten Kanal gepeert werden. Und wieder was gelernt.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

darkness

Zitat von: Pfriemler am 20 Oktober 2017, 23:48:32
Äh ... der Link ist von frank, aber gut.

Ups, natürlich. Sorry

Danke. Werde gleich mal ein wenig ausprobieren und berichten.

darkness

#14
Schade auch.

Leider scheitert das ganze an meinem HM-Sen-LI-O  >:(

ZitatDas  Gerät  unterstützt  keine  direkten  Verknüpfungen, es ist nur an eine HomeMatic Zentrale
anmeldbar .  Alle  Geräteverknüpfungen  sind  allein über Zentralenprogramme möglich .

Dann muss ich halt doch mal die Helligkeit vom HM-Sen-MDIR-WM55 testen