[gelöst] Fensterkontakt und Schalter

Begonnen von cjung, 02 November 2014, 12:10:46

Vorheriges Thema - Nächstes Thema

cjung

Hallo Zusammen,

ich möchte einen Fensterkontakt HM-Sec-SC-2 mit einem UP Aktor HM-LC-SW1-FM peeren.
Das ist die Steuerung der Dunstabzugshaube weil im gleichen Raum ein Kamin steht.

Die Regel soll lauten:
Fenster offen: Dunstabzug hat Strom
Fenster geschlossen: Dunstabzug hat keinen Strom.

Der HM-LC-SW1-FM und der HM-Sec-SC-2 sind fertig eingebaut und mit der vccu gepaired
Mit dem HM-LC-SW1-FM kann ich erfolgreich die Dunstabzugshaube steuern.
Beide waren neu und das HM-Info hat keine Fehler gezeigt.
Ein Update meiner FHEM Installation habe ich auch heute durchgeführt.

Nun habe ich die beiden Geräte gepeered:
set CUL_HM_HM_SEC_SC_2_2770C8 peerChan 0 CUL_HM_HM_LC_SW1_FM_2A5C76 single set
(GetConfig und Button im SC-2 gedrückt, HMInfo gibt keine Fehler)

Jetzt schaltet das öffnen des SC-2 den SW1-FM erfolgreich aus.
Wenn ich den SC-2 schließe geschieht allerdings nichts.

Wenn ich den SC-2 jetzt wieder öffne wird der SW1-FM jetzt eingeschalten.
Das Schließen des SC-2 ändert wieder nichts am SW1-FM

Also: nur das öffnen schaltet den SW1-FM

In den Readings der beiden Geräte sehe ich jedoch die Zustandsänderung.
Im SW1-FM:
trigLast  CUL_HM_HM_SEC_SC_2_2770C8 :closed
trig_CUL_HM_HM_SEC_SC_2_2770C8 closed

Zusätzlich gibt der SC-2 jetzt alle 5 sec einen Status ab. Zuvor waren es die üblichen ca 180 sec.

Ich habe alle Geräte nochmal zurück gesetzt und die ganze Konfiguration noch einmal gemacht, mit dem gleichen Ergebnis.

Meine beiden Fragen sind nun:
- Wie bekomme ich beim Schlissen des SC-2 auch den SW1-FM geschaltet-
- Wie kann ich die Zeit für die Statusübertragung im SC-2 wieder auf das normaler Maß bringen.

Gruß
Christoph
Raspberry Pi 2 B
Funk: HM_CFG_USB2, HM-CFG-LAN 8*HM_CC_RT_DN, 3*HM-SEC-SD, 3*HM_TC_IT_WM_W_EU, 1*HM-LC-Dim1TPBU-FM,5*HM-SEC-SC-2, 1*HM-SEC-SCo
Wired: HMW: CFG-LAN, 8*LC_Bl1_DR, LC_Dim1L_DR

frank

ZitatZusätzlich gibt der SC-2 jetzt alle 5 sec einen Status ab. Zuvor waren es die üblichen ca 180 sec.
ich habe zwar nur einen sc ohne die 2, aber der gibt keine regelmässigen stati aus. nur bei statusänderung. poste mal ein list vom sc.
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

cjung

Hallo Frank,

hier der get reg all vom SC-2:
CUL_HM_HM_SEC_SC_2_2770C8 type:threeStateSensor -
list:peer   register         :value
   0:         cyclicInfoMsg    :off
   0:         pairCentral      :0x263522
   0:         sabotageMsg      :on
   0:         transmDevTryMax  :6
   1:         eventDlyTime     :0 s
   1:         ledOnTime        :0.5 s
   1:         msgScPosA        :closed
   1:         msgScPosB        :open
   1:         sign             :off
   1:         transmitTryMax   :6
   4:CUL_HM_HM_LC_SW1_FM_2A5C76_chn:01   expectAES        :off
   4:CUL_HM_HM_LC_SW1_FM_2A5C76_chn:01   peerNeedsBurst   :off

Und der entsprechende vom SW1-FM:
CUL_HM_HM_LC_SW1_FM_2A5C76 type:switch -
list:peer   register         :value
   0:         intKeyVisib      :invisib
   0:         pairCentral      :0x263522
   1:         sign             :off
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgActionType     :jmpToTarget
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgCtDlyOff       :geLo
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgCtDlyOn        :geLo
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgCtOff          :geLo
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgCtOn           :geLo
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgCtValHi        :100
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgCtValLo        :50
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgMultiExec      :on
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgOffDly         :0 s
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgOffTime        :unused
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgOffTimeMode    :absolut
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgOnDly          :0 s
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgOnTime         :unused
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgOnTimeMode     :absolut
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgSwJtDlyOff     :off
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgSwJtDlyOn      :on
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgSwJtOff        :dlyOn
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   lgSwJtOn         :dlyOff
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shActionType     :jmpToTarget
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shCtDlyOff       :geLo
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shCtDlyOn        :geLo
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shCtOff          :geLo
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shCtOn           :geLo
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shCtValHi        :100
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shCtValLo        :50
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shOffDly         :0 s
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shOffTime        :unused
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shOffTimeMode    :absolut
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shOnDly          :0 s
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shOnTime         :unused
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shOnTimeMode     :absolut
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shSwJtDlyOff     :off
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shSwJtDlyOn      :on
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shSwJtOff        :dlyOn
   3:CUL_HM_HM_SEC_SC_2_2770C8_chn:01   shSwJtOn         :dlyOff
Raspberry Pi 2 B
Funk: HM_CFG_USB2, HM-CFG-LAN 8*HM_CC_RT_DN, 3*HM-SEC-SD, 3*HM_TC_IT_WM_W_EU, 1*HM-LC-Dim1TPBU-FM,5*HM-SEC-SC-2, 1*HM-SEC-SCo
Wired: HMW: CFG-LAN, 8*LC_Bl1_DR, LC_Dim1L_DR

cjung

Neuer Stand:
Ich hatte die Batterien jetzt für eine Stunde aus dem SC-2 um die vielen Status Messages zu verhindern.
Nach dem Einlegen, ist das SC-2 wieder auf dem normalen Rhythmus.

Damit bleibt nur noch das Schalten des SW1-FM als Problem.
Raspberry Pi 2 B
Funk: HM_CFG_USB2, HM-CFG-LAN 8*HM_CC_RT_DN, 3*HM-SEC-SD, 3*HM_TC_IT_WM_W_EU, 1*HM-LC-Dim1TPBU-FM,5*HM-SEC-SC-2, 1*HM-SEC-SCo
Wired: HMW: CFG-LAN, 8*LC_Bl1_DR, LC_Dim1L_DR

Puschel74

Hallo,

sollte das per direktem peering nicht klappen kannst du noch DOIF bzw. ein einfaches notify verwenden.

Grüße
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Brockmann

Zitat von: Puschel74 am 02 November 2014, 13:12:58
sollte das per direktem peering nicht klappen kannst du noch DOIF bzw. ein einfaches notify verwenden.
Das ist den Beteiligten vermutlich klar. Nur hier geht es um eine unter Umständen lebenswichtige Funktion, die vermutlich außerdem in der Betriebserlaubnis für die Feuerstätte vorgeschrieben ist.
Da wäre mir wohler, wenn es sich mit einem direkten Peering regeln lässt und somit auch funktioniert, wenn FHEM - warum auch immer - mal nicht so tut, wie es soll.

(Wobei ich an der Stelle ehrlich gesagt nicht mal auf eine Funkverbindung setzen, sondern eine rein drahtgebundene Lösung bevorzugen würde.)

Puschel74

Hallo,

ZitatDas ist den Beteiligten vermutlich klar.
Keine Panik - mir auch.

ZitatWobei ich an der Stelle ehrlich gesagt nicht mal auf eine Funkverbindung setzen, sondern eine rein drahtgebundene Lösung bevorzugen würde.
Genau darauf wollte ich hinaus.

grüße
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

cjung

Ich habe nochmal etwas im Forum herumgesucht und habe den Weg zu den Statemachines gefunden, die im "Heimautomatisierung mit fhem - für Einsteiger Version 4.0" ab Seite 80 beschrieben sind.
Offenbar muss ich da noch tiefer rein.

Gibt es einen Weg, das zu debuggen ? Alternativ muss ich das wohl einzeln auseinandertüfteln.
Hat sich jemand außerhalb der PDF damit eingehender beschäftigt ?

Raspberry Pi 2 B
Funk: HM_CFG_USB2, HM-CFG-LAN 8*HM_CC_RT_DN, 3*HM-SEC-SD, 3*HM_TC_IT_WM_W_EU, 1*HM-LC-Dim1TPBU-FM,5*HM-SEC-SC-2, 1*HM-SEC-SCo
Wired: HMW: CFG-LAN, 8*LC_Bl1_DR, LC_Dim1L_DR

martinp876

ZitatGibt es einen Weg, das zu debuggen ?
nein

ZitatAlternativ muss ich das wohl einzeln auseinandertüfteln.
wenn dir der text nicht reicht. Das Bild zeigt alle Übergänge - was immer dir fehlt... keine Ahnung.

ZitatHat sich jemand außerhalb der PDF damit eingehender beschäftigt ?
ausserhalb des PDF? nun, im PDF konnte ich es weder lernen, noch testen oder verstehen.
Jeder, der es nutzt hat zumindest die Grundzüge verstanden.
Verstehe leider überhaupt nicht, was dein Problem ist. Wenn du weisst, wie eine statemachine i.a. funktioniert sollte es kein Problem für dich sein, alles komplett straight forward.
Solltest du zum ersten mal eine statemachin sehen kannst du dir einmal die Theorie dazu ansehen. Gibt jede Menge dazu im Internet.

cjung

#9
Nachdem ich bisher so viele Codebeispiele im Forum gefunden habe, hier mein erstes (einfaches) Beispiel für alle Anfänger, wie ich es einer bin, zurück.

Es ist zwar noch nicht unabhängig von der Zentrale, aber es funktioniert mit den notify's sehr  gut:
define KuecheAbzugNotifyAn notify CUL_HM_HM_SEC_SC_2_XXXXXX:open set CUL_HM_HM_LC_SW1_FM_YYYYYY on
define KuecheAbzugNotifyAus notify CUL_HM_HM_SEC_SC_2_XXXXXX:close set CUL_HM_HM_LC_SW1_FM_YYYYYY off

Für die Abnahme durch den Schornsteinfeger sollte das reichen.

Zufrieden bin ich damit aber natürlich noch nicht: Ich will das ganze noch unabhängig von der Zentrale hinbekommen.
Aus den Statemachines ist mir nicht klar, wo ich den Wert ermitteln kann, der vom SC_2 zurückgesendet wird. Es gibt ja nur Open und Close.
In den Statemachines wird ja prinzipiell auf den Schwellwert verglichen. Ist open = 200 und Close = 0 ?

Raspberry Pi 2 B
Funk: HM_CFG_USB2, HM-CFG-LAN 8*HM_CC_RT_DN, 3*HM-SEC-SD, 3*HM_TC_IT_WM_W_EU, 1*HM-LC-Dim1TPBU-FM,5*HM-SEC-SC-2, 1*HM-SEC-SCo
Wired: HMW: CFG-LAN, 8*LC_Bl1_DR, LC_Dim1L_DR

martinp876

ZitatIst open = 200 und Close = 0 ?
korrekt.
sollte man mit einem Template wie einen mdir einrichten können

Pfriemler

Sorry dass ich mich erst jetzt reinhängen kann ... Besteht noch Interesse an einer direkten HM-Lösung?  Da der Aktor bei Dir ja offenbar nur beim Öffnen toggelt, würde ein einfacher Registerbefehl reichen damit der Aktor dem Status des Fensters direkt folgt. Habs gerade nicht im Kopf. Sehe heute abend mal nach.

Geht nich gips nich
"Ä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 ..."

cjung

Hallo Pfriemler, ja ich vermute das würde mir helfen.
Raspberry Pi 2 B
Funk: HM_CFG_USB2, HM-CFG-LAN 8*HM_CC_RT_DN, 3*HM-SEC-SD, 3*HM_TC_IT_WM_W_EU, 1*HM-LC-Dim1TPBU-FM,5*HM-SEC-SC-2, 1*HM-SEC-SCo
Wired: HMW: CFG-LAN, 8*LC_Bl1_DR, LC_Dim1L_DR

Pfriemler

Also: Voraussetzung ist, dass Fensterkontakt und Aktor (also der Schalter, der die Abzugshaube schalten soll) z.B. über FHEM gepeert sind.
Üblicherweise ändert sich danach der Zustand des Aktors dann nur bei jeder Fensteröffnung, während eine Fensterschließung ignoriert wird.

Eine ähnliche Frage hatte ich hier gestellt: http://forum.fhem.de/index.php/topic,21848.msg153108.html#msg153108
und umfassend beantwortet bekommen. Im zweiten Beitrag erläutert Martin genau, warum das so ist.

Kurz wiederholt: die Register shCtOn und ShCtOff legen - einzeln für jedes gepeerte Gerät - fest, auf welche Triggerwerte der Aktor reagieren soll, wenn er gerade ein- bzw. ausgeschaltet ist. Beide stehen default auf "geLo" (größer oder gleich (equal) als Low), und Low steht default auf 50. Wenn jetzt der Fensterkontakt einen open-Status sendet, ist das ein Trigger mit dem Wert "200" (ist so festgelegt einfach) und der ist größer als 50 und dadurch löst der Aktor aus, faktisch kippt er seinen Zustand also. Beim closed kommt der Wert 0, und der Aktor ignoriert das Telegramm deshalb.

Nun muss einfach shCtOn auf "ltLo" (less than low, kleiner als low) gesetzt werden.

Ist der Aktor eingeschaltet (on), reagiert er nun auf einen Trigger<50, d.h. beim Schließen des Fensters geht er aus. Werte über 50 ignoriert er dafür.
Ist der Aktor ausgeschaltet, ist weiterhin shCtOff zuständig, dessen Wert auf "geLo" bleibt, das bedeutet, er reagiert nur auf Trigger >=50, also ein "open". Ein "closed" ignoriert er wie bisher.
Damit folgt der Aktor dem Fensterzustand sauber und synchronisiert sich automatisch darauf. Ein händisches Schalten des Aktors bringt das nicht durcheinander.

set <actorchannel> regSet shCtOn ltLo <sensorchannel> ist also alles.
Wenn ich Dein erstes Posting richtig deute, hieße das für Dich konkret
set CUL_HM_HM_LC_SW1_FM_2A5C76 regSet shCtOn ltLo CUL_HM_HM_SEC_SC_2_2770C8.

Der Aktor muss dazu nicht bedient werden, das Register wird automatisch prozessiert. Am SC-2 muss nichts geändert werden.
Nochmal zur Erinnerung: Das Register gibt es für jeden gepeerten Sensor einzeln. Du musst also nach "R-CUL_HM_HM_SEC_SC_2_2770C8-shCtOn" suchen, wenn es geklappt hat, wechselt
es auf den Wert "set_ltLo". Mit einem "getConfig" kannst Du die Manipulation prüfen, dann sollte dort nur noch "ltLo" stehen.
"Ä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 ..."

cjung

Hallo Pfriemler,

Perfekt, es funktioniert, genau das habe ich gesucht.
Damit kann ich jetzt auch mehrere SC-2's an der Dunstabzugshaube eintragen.

Vielen herzlichen Dank für Deine Beschreibung.

Gruß
Christoph
Raspberry Pi 2 B
Funk: HM_CFG_USB2, HM-CFG-LAN 8*HM_CC_RT_DN, 3*HM-SEC-SD, 3*HM_TC_IT_WM_W_EU, 1*HM-LC-Dim1TPBU-FM,5*HM-SEC-SC-2, 1*HM-SEC-SCo
Wired: HMW: CFG-LAN, 8*LC_Bl1_DR, LC_Dim1L_DR

olfi

#15
Hallo ,

da ich vor kurzem genau vor der gleichen Aufgabenstellung stand (neuer Kaminofen), möchte ich hier noch mal für vielleicht andere die sowas auch umsetzen müssen, etwas anmerken.
Wenn diese Dunstabzugsschaltung für den Betrieb der Feuerstätte vorgeschrieben wurde, dann muss Du in jedem Fall sicherstellen dass sie IMMER funktioniert bzw. bei Störung in "Sicherheitsstellung" (Dunstabzugshaube aus) geht. Sprich, wenn der Fensterkontakt abfällt, Batterie leer ist oder sonst was passiert, darf die Dunstabzugshaube in keinem Fall angehen.
Aus diesem Grund habe ich mich leider gegen eine HM Lösung entschieden und eine DIBt geprüfte Fensterschaltung verbaut.
Aber das muss jeder für sich selbst entscheiden.

FHEMAN

Hallo, also noch einmal für Beginner - wie mich - einfach ausgedrückt zusammengefasst:
Man kann neben der Programmierung über die Zentrale (pairing) auch die direkte, ausfallsichere Verknüpfung (peering) von Tür-/Fensterkontaktschaltern mit Steckdosen herstellen. Dies erfolgt über das Herabsetzen des Schaltschwellwerts mittels folgender Befehle
# "HM-SEC-SCo" vorher umbenannt in "TuerFensterKontakt.1"
# "HM-ES-PMSw1-Pl" (bzw "CUL_HM_HM_ES_PMSw1_Pl_XXXXXX") vorher umbenannt in "Schaltsteckdose.1.Sw"
set TuerFensterKontakt.1 peerChan 0 Schaltsteckdose.1.Sw single set
set Schaltsteckdose.1.Sw regSet shCtOn ltLo TuerFensterKontakt.1

Mal sehen, wann ich das mit dem "regSet" verstehe.. auf jeden Fall funktioniert es sehr gut!

Gruß
Ron
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

sig10680

Hallo Leute,

ich möchte nochmal das Thema aufgreifen. Ich habe folgendes Problem.

2 Fensterkontakte HM-SEC-SCO
1 Schaltsteckdose HM-LC-Sw1

Alle sind gepeert und funktionieren fast.

Wenn ich das 1. Fenster auf habe schaltet die Steckdose ein
Wenn ich das 2. Fenster auf mache bleibt die Steckdose an (soweit gut)

mach ich aber eines der beiden Fenster zu geht die Steckdose aus obwohl noch ein Fenster auf ist.

Was muss ich in Regset einstellen? Ich habe folgende Einstellung:

shCTOn = ltLo
shCTOff = geLo
eingestellt?!

vielleicht kann mir jemand helfen!

Danke Tobias

Pfriemler

Interessantes Problem, für das ich spontan keine Lösung weiß. Über FHEM würde ich über den Zustand der SCos ein DOIF bauen und fertig. Das ist aber letztlich nicht, ebenso wenig wie ein direktes peeren, hinreichend sicher im Sinne der Vorschriften , wie olfi drei Beiträge zuvor schrieb.

Die SCos so zu peeren, dass die Steckdose dem Zustand folgt, ist ja die erste Herausforderung. Damit lässt sich aber immer nur eine Art ODER realisieren: Ein Einschaltbefehl von einem der beiden SCo genügt, ebenso auch ein Ausschaltbefehl.

Orakel:
Eine Möglichkeit wäre eventuell (ungeprüft), die Steckdose mit jedem offen-Telegramm eines SCo für eine begrenzte Zeit einzuschalten. Das könnten z.B. 70 oder 90 Minuten sein, weil ein SCo sich praktisch stündlich mit seinem aktuellen Zustand meldet. Bleibt die Meldung aus, z.B. auch wenn der SCo defekt oder tot ist, schaltet die Steckdose spätestens dann aus. Gibt es vorher einen Ausschaltbefehl (durch einen "closed"-Zustand), dann sofort danach.
Weiter: Zudem lässt sich je Peer der TimeMode ändern von "absolute" auf "minimal". Bei Aktoren mit gepeerten Bewegungsmeldern und Tastern kann man damit erreichen, dass eine Zeitvorgabe durch einen Taster (was auch ein dauerhaftes Einschalten sein kann) nicht durch eine Bewegungsmelder mit kürzerer Aktivzeit überschrieben wird (bei "absolute" gilt der jeweils letzte gemeldete Wert, wenn also bspw ein Licht per Taster dauerhaft eingeschaltet wurde und ein Bewegungsmelder danach eine zeitlich begrenzte Einschaltdauer triggert, würde das Licht nach dieser Zeit ausgehen). Hier könnte es vielleicht (Versuch!) bedeuten, dass bspw. ein Ausschaltbefehl vom SCo #2 den Einschaltbefehl vom SCo #1 nicht überschreibt und umgekehrt.
Konkret würde das bedeuten, shOnTime für jeden SCO auf bspw. 5400 zu setzen (90 Minuten) und shOnTimeMode auf "minimal".
Ich kann das mangels Geräten gerade nicht testen.
"Ä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 ..."

sig10680

Zitat von: Pfriemler am 27 Juni 2017, 23:40:52

Hier könnte es vielleicht (Versuch!) bedeuten, dass bspw. ein Ausschaltbefehl vom SCo #2 den Einschaltbefehl vom SCo #1 nicht überschreibt und umgekehrt.
Konkret würde das bedeuten, shOnTime für jeden SCO auf bspw. 5400 zu setzen (90 Minuten) und shOnTimeMode auf "minimal".
Ich kann das mangels Geräten gerade nicht testen.

Hallo,

mittels DOIF funktioniert es ja Prima, nur wollte ich es so direkt ohne FHEM machen falls der Pi mal nicht funktioniert (warum auch immer). Ich werde es mal testen mit den beiden ogen genannten Registern.

Beide Fensterkontakte mittels shOnTime auf 5400 und shOnTimeMode auf "minimal"!

bin gespannt
Danke Tobias

Pfriemler

Hm ... wenn ich mir das nach einer durchschlafenen Nacht nochmal so überlege, fürchte ich es klappt nicht. Mir fällt nämlich auf, dass ich ein per Bewegungsmelder eingeschaltetes Wohnzimmerlicht auch problemlos ausschalten kann am Wandtaster, was meiner Theorie widerspräche.
Ungeachtet dessen wäre eine Zeitsteuerung gerade beim ursprünglichen Fall Dunstabzugshaube+Fenster+Kamin dennoch ein kleines Sicherheitsplus.
Eigentlich ist das ein klassischer Fall für virtuelle Kanäle im Aktor, aber sowas haben die Zwischenstecker ja alle nicht.

Gesendet von meinem SM-G900FD mit Tapatalk

"Ä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 ..."

Brockmann

Ist ein interessantes Problem, für das es meiner Meinung nach aber keine Lösung in der vorgestellten Konfiguration gibt (2 SCOs, 1 Sw). Das Peeren ist meinem Verständnis nach eine direkte Verknüpfung zwischen zwei Devices. Da kann man über den Condition Table zwar einiges machen, aber eine Dreierbeziehung wird trotzdem nicht daraus. Wäre aber vielleicht sinnvoll, noch mal einen neuen Thread dafür aufzumachen. Vielleicht gibt es ja doch eine Lösung dafür.

Damit es etwas konstruktiver wird:
Du könntest statt der SCOs an beiden Fenstern eigene Kontakte anbringen (mechanische Schaltkontakte oder Reed-Schalter) und diese über eine kleine Logikschaltung miteinander verknüpfen:
Wenn einer oder beide offen -> open, wenn beide zu - closed. Die Ausgänge dieser Schaltung könntest Du dann an ein HM-MOD-EM-8 anschließen. Dann hast Du in dem HM-MOD-EM-8 einen Kanal, der den Zustand beider Fenster widerspiegelt und den Du mit dem Switch peeren kannst.

sig10680

Hallo an alle die mitwirken,

mir fällt gerade ein man könnte es doch auch mit dem HM-TC-IT-WM-W-EU Funk-Wandthermostat probieren?! Da sind bereits beide Fensterkontakte angemeldet. Würde der Zwischenstecker denn in verbindung mit dem Wandthermostat funktionieren?!

Tobias

papa

#23
Das hatten wir schon mal irgendwo. Die Lösung ist eine ODER-Schaltung mit 2 Steckdosen. Du brauchst also ein  HM-LC-Sw2 und peerst jeden Kanal einzeln. Die geschalteten Ausgänge werden dann parallel an den Verbraucher angeschlossen. Somit ist der Verbrauchen geschaltet, wenn mindestens ein Kanal an ist.

Bei einem Dimmer würde man einfach einen virtuellen Kanal mit ODER-Logik nehmen. Das gibt es aber leider bei Switches nicht- soweit ich weiss.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire