[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