Hallo,
ich habe jetzt schon einige HM Komponenten im Betrieb und bin eigentlich mit der Zuverlässigkeit (im Gegensatz zu den FS20) sehr zufrieden.
Jetzt ich nachträglich den Überwachungsbereich meiner drahtgenbundene Terxon Alarmanlage erweitern. Der Plan ist mit den Fensterkontakten den HM-LC-Sw4-WM zu schalten und damit die Alarmeingänge zu bedienen.
Auch nach tagelangen empirischen ermittelm fand ich die richtige Konfiguration der Register nicht heraus, ich gebe das jetzt auf und hoffe auf Unterstützung aus dem Forum das mir jetzt sehr viel Informationen gegeben hat.
Beschreibung der Sollfunktion (wichtige Voraussetzung, soll ohne FHEM auch funktionieren):
HM-Sec-SC = WG_Gartentuer
HM-LC-Sw4-WM_Sw1 = AA_SW1_1
WG_Gartentuer geschlossen -> AA_SW1_1 Kontakt geschlossen
WG_Gartentuer offen -> AA_SW1_1 Kontakt offen
Leider passiert nur ein togglen des Zustandes beim Öffnen des HM-Sec-SC (beim schliessen passiert nix), das entspricht genau der Funtkion des Tasters auf dem HM-LC-Sw4-WM.
Ich bin mir sicher mit Änderunge des Register shActionType und ff ist das einstellbar, aber ich habe die Logik einfach nicht verstanden und auch keine brauchbare Beschreibung gefunden.
Hat da jemand eine Idee oder eine brauchbare Beschreibung?
hier noch der list des AA_SW1_1
Internals:
DEF 1E485501
EVENTS 69
NAME AA_SW1_1
NR 651
STATE off
TRIGGERTIME 2013-04-07 12:41:14
TYPE CUL_HM
chanNo 01
device AA_SW1
CHANGED:
R-WG_Gartentuer_chn-01-shSwJtOn: off
R-WG_Gartentuer_chn-01-shOffTimeMode: absolut
R-WG_Gartentuer_chn-01-shSwJtOff: on
R-WG_Gartentuer_chn-01-shOnTimeMode: absolut
R-WG_Gartentuer_chn-01-lgOnTime: 111600 s
R-WG_Gartentuer_chn-01-shActionType: jmpToTarget
Readings:
2013-04-07 11:16:09 CommandAccepted yes
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-lgActionType jmpToTarget
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-lgCtDlyOff geLo
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-lgCtDlyOn geLo
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-lgCtOff geLo
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-lgCtOn geLo
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-lgCtValHi 100
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-lgCtValLo 50
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-lgMultiExec on
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-lgOffDly 0 s
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-lgOffTime 111600 s
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-lgOffTimeMode absolut
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-lgOnDly 0 s
2013-04-07 12:42:23 R-WG_Gartentuer_chn-01-lgOnTime 111600 s
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-lgOnTimeMode absolut
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-lgSwJtDlyOff off
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-lgSwJtDlyOn on
2013-04-07 11:27:58 R-WG_Gartentuer_chn-01-lgSwJtOff dlyOn
2013-04-07 11:27:58 R-WG_Gartentuer_chn-01-lgSwJtOn dlyOff
2013-04-07 12:42:23 R-WG_Gartentuer_chn-01-shActionType jmpToTarget
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-shCtDlyOff geLo
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-shCtDlyOn geLo
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-shCtOff geLo
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-shCtOn geLo
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-shCtValHi 100
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-shCtValLo 50
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-shOffDly 0 s
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-shOffTime 111600 s
2013-04-07 12:42:23 R-WG_Gartentuer_chn-01-shOffTimeMode absolut
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-shOnDly 0 s
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-shOnTime 111600 s
2013-04-07 12:42:23 R-WG_Gartentuer_chn-01-shOnTimeMode absolut
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-shSwJtDlyOff off
2013-04-07 11:16:00 R-WG_Gartentuer_chn-01-shSwJtDlyOn on
2013-04-07 12:42:23 R-WG_Gartentuer_chn-01-shSwJtOff on
2013-04-07 12:42:23 R-WG_Gartentuer_chn-01-shSwJtOn off
2013-04-07 12:28:04 R-broadcast-lgActionType set_jmpToTarget
2013-04-07 12:28:04 R-broadcast-lgCtDlyOff set_geLo
2013-04-07 12:28:04 R-broadcast-lgCtDlyOn set_geLo
2013-04-07 12:28:04 R-broadcast-lgCtOff set_geLo
2013-04-07 12:28:04 R-broadcast-lgCtOn set_geLo
2013-04-07 12:28:04 R-broadcast-lgCtValHi set_100
2013-04-07 12:28:04 R-broadcast-lgCtValLo set_50
2013-04-07 12:28:04 R-broadcast-lgMultiExec set_on
2013-04-07 12:28:04 R-broadcast-lgOffDly set_0 s
2013-04-07 12:28:04 R-broadcast-lgOffTime set_111600 s
2013-04-07 12:28:04 R-broadcast-lgOffTimeMode set_absolut
2013-04-07 12:28:04 R-broadcast-lgOnDly set_0 s
2013-04-07 12:28:04 R-broadcast-lgOnTime set_111600 s
2013-04-07 12:28:04 R-broadcast-lgOnTimeMode set_absolut
2013-04-07 12:28:04 R-broadcast-lgSwJtDlyOff set_off
2013-04-07 12:28:04 R-broadcast-lgSwJtDlyOn set_on
2013-04-07 12:28:04 R-broadcast-lgSwJtOff set_dlyOn
2013-04-07 12:28:04 R-broadcast-lgSwJtOn set_dlyOff
2013-04-07 12:28:04 R-broadcast-shActionType set_off
2013-04-07 12:28:04 R-broadcast-shCtDlyOff set_geLo
2013-04-07 12:28:04 R-broadcast-shCtDlyOn set_geLo
2013-04-07 12:28:04 R-broadcast-shCtOff set_geLo
2013-04-07 12:28:04 R-broadcast-shCtOn set_geLo
2013-04-07 12:28:04 R-broadcast-shCtValHi set_100
2013-04-07 12:28:04 R-broadcast-shCtValLo set_50
2013-04-07 12:28:04 R-broadcast-shOffDly set_0 s
2013-04-07 12:28:04 R-broadcast-shOffTime set_111600 s
2013-04-07 12:28:04 R-broadcast-shOffTimeMode set_absolut
2013-04-07 12:28:04 R-broadcast-shOnDly set_0 s
2013-04-07 12:28:04 R-broadcast-shOnTime set_111600 s
2013-04-07 12:28:04 R-broadcast-shOnTimeMode set_absolut
2013-04-07 12:28:04 R-broadcast-shSwJtDlyOff set_off
2013-04-07 12:28:04 R-broadcast-shSwJtDlyOn set_on
2013-04-07 12:28:04 R-broadcast-shSwJtOff set_dlyOn
2013-04-07 12:28:04 R-broadcast-shSwJtOn set_dlyOff
2013-04-06 19:18:04 R-intKeyVisib set_visib
2013-04-06 19:23:17 R-self01-lgActionType jmpToTarget
2013-04-06 19:23:17 R-self01-lgCtDlyOff geLo
2013-04-06 19:23:17 R-self01-lgCtDlyOn geLo
2013-04-06 19:23:17 R-self01-lgCtOff geLo
2013-04-06 19:23:17 R-self01-lgCtOn geLo
2013-04-06 19:23:17 R-self01-lgCtValHi 100
2013-04-06 19:23:17 R-self01-lgCtValLo 50
2013-04-06 19:23:17 R-self01-lgMultiExec on
2013-04-06 19:23:17 R-self01-lgOffDly 0 s
2013-04-06 19:23:17 R-self01-lgOffTime 111600 s
2013-04-06 19:23:17 R-self01-lgOffTimeMode absolut
2013-04-06 19:23:17 R-self01-lgOnDly 0 s
2013-04-06 19:23:17 R-self01-lgOnTime 111600 s
2013-04-06 19:23:17 R-self01-lgOnTimeMode absolut
2013-04-06 19:23:17 R-self01-lgSwJtDlyOff off
2013-04-06 19:23:17 R-self01-lgSwJtDlyOn on
2013-04-06 19:23:17 R-self01-lgSwJtOff dlyOn
2013-04-06 19:23:17 R-self01-lgSwJtOn dlyOff
2013-04-06 19:23:17 R-self01-shActionType jmpToTarget
2013-04-06 19:23:17 R-self01-shCtDlyOff geLo
2013-04-06 19:23:17 R-self01-shCtDlyOn geLo
2013-04-06 19:23:17 R-self01-shCtOff geLo
2013-04-06 19:23:17 R-self01-shCtOn geLo
2013-04-06 19:23:17 R-self01-shCtValHi 100
2013-04-06 19:23:17 R-self01-shCtValLo 50
2013-04-06 19:23:17 R-self01-shOffDly 0 s
2013-04-06 19:23:17 R-self01-shOffTime 111600 s
2013-04-06 19:23:17 R-self01-shOffTimeMode absolut
2013-04-06 19:23:17 R-self01-shOnDly 0 s
2013-04-06 19:23:17 R-self01-shOnTime 111600 s
2013-04-06 19:23:17 R-self01-shOnTimeMode absolut
2013-04-06 19:23:17 R-self01-shSwJtDlyOff off
2013-04-06 19:23:17 R-self01-shSwJtDlyOn on
2013-04-06 19:23:17 R-self01-shSwJtOff dlyOn
2013-04-06 19:23:17 R-self01-shSwJtOn dlyOff
2013-04-06 12:33:07 R-sign off
2013-04-07 12:42:22 RegL_03:WG_Gartentuer_chn:01 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:36 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
2013-04-07 12:41:14 deviceMsg off (to broadcast)
2013-04-07 12:41:14 level 0 %
2013-04-07 12:42:21 peerList WG_Gartentuer_chn:01,
2013-04-07 12:41:14 state off
Helper:
count 16
peerIDsRaw ,1E5B5901,00000000
Role:
chn 1
Shadowreg:
RegL_00: 02:81
RegL_03: 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:00 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
Attributes:
model HM-LC-SW4-WM
peerIDs 00000000,1E5B5901,
room CUL_HM
webCmd toggle:on:off:statusRequest
Hi schka17,
also erst einmal irritieren mich die R-broadcast. Kann ein darstellungsproblem sein. Da readings nie komplett gelöscht werden solltest du es einmal machen
set name clear readings
dann neu lesen. Die Broadcast sind hoffentlich dann weg...
Zum shutter-contact: ich gehe davon aus, dass der nur 'kurze' trigger schickt. Evtl. kannst du die messages einmal aufzeichnen, vom Öffnen und vom Schliessen.
Weiter gehe ich davon aus, dass der SC immer den gleichen Trigger schickt, nur
mit dem Zusatz 'offen' und 'zu'.
Damit macht es keinen sinn, die JT zu nutzen
R-WG_Gartentuer_chn-01-shActionType off
Somit sind dann egal
R-WG_Gartentuer_chn-01-shSwJtDlyOff
R-WG_Gartentuer_chn-01-shSwJtDlyOn
R-WG_Gartentuer_chn-01-shSwJtOff
R-WG_Gartentuer_chn-01-shSwJtOn
Genutzt wird dann die Condition Table:
Grenzen einstellen (sollte passen)
R-WG_Gartentuer_chn-01-shCtValHi 100
R-WG_Gartentuer_chn-01-shCtValLo 50
und die Tabelle
R-WG_Gartentuer_chn-01-shCtDlyOff geHi
R-WG_Gartentuer_chn-01-shCtDlyOn off
R-WG_Gartentuer_chn-01-shCtOff ltLo
R-WG_Gartentuer_chn-01-shCtOn off
Die Zeiten sollte passen
R-WG_Gartentuer_chn-01-shOffDly 0 s
R-WG_Gartentuer_chn-01-shOnDly 0 s
R-WG_Gartentuer_chn-01-shOffTime 111600 s
R-WG_Gartentuer_chn-01-shOnTime 111600 s
was die machen weiss ich nicht
R-WG_Gartentuer_chn-01-shOnTimeMode absolut
R-WG_Gartentuer_chn-01-shOffTimeMode absolut
Gruss,
Martin
Hallo Martin,
ich habe jetzt einen testschalter genommen TK_test1 (statt WG_Gartentuer), weil dauernd die Tür aufzumachen war mir zu mühsam.
dieser liefert folgende Meldungen:
2013-04-07_18:23:21 TK_test1 open
2013-04-07_18:23:21 TK_test1 contact: open (to HMLAN)
2013-04-07_18:23:22 TK_test1 closed
2013-04-07_18:23:22 TK_test1 contact: closed (to HMLAN)
ich hab leider zwei fehlermeldungen bekommen:
fhem> set AA_SW1_1 regSet shCtDlyOn off TK_test1
invalid value. use:geLo,between,outside,ltLo,geHi,ltHi
fhem> set AA_SW1_1 regSet shCtOn off TK_test1
invalid value. use:geLo,between,outside,ltLo,geHi,ltHi
Habe vergeblich versucht der Logik zu folgen und habe alternative Einträge gewählt, hier der ListAuszug
2013-04-07 18:49:43 R-TK_test1_chn-01-shActionType off
2013-04-07 18:49:43 R-TK_test1_chn-01-shCtDlyOff geHi
2013-04-07 18:49:43 R-TK_test1_chn-01-shCtDlyOn geLo
2013-04-07 18:49:43 R-TK_test1_chn-01-shCtOff ltLo
2013-04-07 18:49:43 R-TK_test1_chn-01-shCtOn ltHi
2013-04-07 18:12:52 R-TK_test1_chn-01-shCtValHi 100
2013-04-07 18:12:52 R-TK_test1_chn-01-shCtValLo 50
2013-04-07 18:12:52 R-TK_test1_chn-01-shOffDly 0 s
2013-04-07 18:12:52 R-TK_test1_chn-01-shOffTime 111600 s
2013-04-07 18:49:43 R-TK_test1_chn-01-shOffTimeMode absolut
2013-04-07 18:12:52 R-TK_test1_chn-01-shOnDly 0 s
2013-04-07 18:12:52 R-TK_test1_chn-01-shOnTime 111600 s
2013-04-07 18:49:43 R-TK_test1_chn-01-shOnTimeMode absolut
2013-04-07 18:49:43 R-TK_test1_chn-01-shSwJtDlyOff on
2013-04-07 18:49:43 R-TK_test1_chn-01-shSwJtDlyOn off
2013-04-07 18:12:52 R-TK_test1_chn-01-shSwJtOff on
2013-04-07 18:12:52 R-TK_test1_chn-01-shSwJtOn off
jetzt reagiert der AA_SW1_1 nicht mehr auf den Fenstersensor.
gruss
karl
Hallo Karl,
kannst du die roh-messages des Fensterkontakts aufzeichnen und kommentieren:
dazu
attr global verbose 1
attr <hmlan> loglevel 1
dann sie ergebnisse im haupt-logfile abfassen.
fhem> set AA_SW1_1 regSet shCtDlyOn off TK_test1
fhem> set AA_SW1_1 regSet shCtOn off TK_test1
mein Fehler, off gibt es nicht.
R-WG_Gartentuer_chn-01-shCtDlyOff geHi
R-WG_Gartentuer_chn-01-shCtDlyOn geHi
R-WG_Gartentuer_chn-01-shCtOff ltLo
R-WG_Gartentuer_chn-01-shCtOn ltLo
Ich muss auch immer probieren - ausserden brauche ich die Messages...
Die Logik ist, dass der SC eine wert mitschickt,also offen oder zu. Das ist warscheinlich 0% und 100%. Da werte in 0.5 schritten angegeben werden wird der SC einen Wert liefern der entweder 0 oder 200 ist (umgerechnet eben 0 oder 100 %)
Du legst 2 Grenzwerte fest, high und low
2013-04-07 18:12:52 R-TK_test1_chn-01-shCtValHi 100
2013-04-07 18:12:52 R-TK_test1_chn-01-shCtValLo 50
Der Aktor soll schalten, wenn die bedingung erfüllt ist, also greater-equal-high, less-then-low,....
2013-04-07 18:49:43 R-TK_test1_chn-01-shCtDlyOff geHi
2013-04-07 18:49:43 R-TK_test1_chn-01-shCtDlyOn geLo
2013-04-07 18:49:43 R-TK_test1_chn-01-shCtOff ltLo
2013-04-07 18:49:43 R-TK_test1_chn-01-shCtOn ltHi
Dann sollte er in den Zustand springen. Könnte auch sein, dass er aus dem Zustand herausspringt..., macht aber weniger sinn.
Was der SC liefert kannst du imSC einstellen, also ob offen 100% ist oder umgekehrt. Du kannst sogar in beiden Stellungen 100% schicken.
Wird man in den Messages sehen
Gruss
Martin
Hallo Martin,
hier das log. einmal öffnen, schliessen.
-------------------
2013.04.07 20:45:16 1: HMLAN/RAW: /E1E7B7D,0000,2A14BA84,FF,FFB4,4DA4411E7B7D10F5FB014AC8
2013.04.07 20:45:16 1: HMLAN_Parse: HMLAN S:E1E7B7D stat:0000 t:2A14BA84 d:FF r:FFB4 m:4DA4411E7B7D10F5FB014AC8
2013.04.07 20:45:16 1: HMLAN: manual ACK
2013.04.07 20:45:16 1: HMLAN: Skip ACK
2013.04.07 20:45:16 1: HMLAN_Send: SE5D10FF6,00,00000000,01,E5D10FF6,4D800210F5FB1E7B7D0101C800
2013.04.07 20:45:16 1: HMLAN/RAW: /RE5D10FF6,0002,00000000,FF,7FFF,4D800210F5FB1E7B7D0101C800
2013.04.07 20:45:16 1: HMLAN_Parse: HMLAN S:RE5D10FF6 stat:0002 t:00000000 d:FF r:7FFF m:4D800210F5FB1E7B7D0101C800
2013.04.07 20:45:16 1: HMLAN_Parse: discard
2013.04.07 20:45:18 1: HMLAN/RAW: /E1E7B7D,0000,2A14C542,FF,FFAF,4EA4411E7B7D10F5FB014B00
2013.04.07 20:45:18 1: HMLAN_Parse: HMLAN S:E1E7B7D stat:0000 t:2A14C542 d:FF r:FFAF m:4EA4411E7B7D10F5FB014B00
2013.04.07 20:45:18 1: HMLAN: manual ACK
2013.04.07 20:45:18 1: HMLAN: Skip ACK
2013.04.07 20:45:18 1: HMLAN_Send: SE5D11AB3,00,00000000,01,E5D11AB3,4E800210F5FB1E7B7D0101C800
2013.04.07 20:45:20 1: HMLAN/RAW: /RE5D11AB3,0002,00000000,FF,7FFF,4E800210F5FB1E7B7D0101C800
2013.04.07 20:45:20 1: HMLAN_Parse: HMLAN S:RE5D11AB3 stat:0002 t:00000000 d:FF r:7FFF m:4E800210F5FB1E7B7D0101C800
2013.04.07 20:45:20 1: HMLAN_Parse: discard
----
gruss
karl
Hallo Karl,
wie erwartet sendet der SC den Level, und zwar 0=closed und 200=open.
Das kannst du jetzt fuer den Aktor verwenden.
Fuer die Grenzen ist also ok, da wir auf groesser/kleiner Abfragen:
R-WG_Gartentuer_chn-01-shCtValHi 100
R-WG_Gartentuer_chn-01-shCtValLo 50
Wie gesagt, getestet habe ich die CT noch nicht, klar ist, dass die Werte geprueft werden und das Schalten beeinflussen. Wenn der Wert nicht stimmt wird nicht geschaltet.
Ich denke (nicht sicher) dass die jump-table (jt...) nicht relevant ist.
Du kannst es aber einmal ausprobieren, also ActionType auf jumpToTarget stellen.
Gruss
Martin
Hallo Martin,
kurz hatte ich geglaubt ich habs verstanden, der Zustand ist wieder vorbei. Ich habe jetzt aber trotzdem eine Konfiguration die genauso funktioniert wie ich es wollte, hier der list des channels (für den Testschalter)
2013-04-08 18:23:33 R-TK_test1_chn-01-shActionType set_jmpToTarget
2013-04-08 18:20:34 R-TK_test1_chn-01-shCtDlyOff geHi
2013-04-08 18:20:34 R-TK_test1_chn-01-shCtDlyOn geHi
2013-04-08 18:33:16 R-TK_test1_chn-01-shCtOff set_ltLo
2013-04-08 18:33:16 R-TK_test1_chn-01-shCtOn set_geHi
2013-04-08 18:20:34 R-TK_test1_chn-01-shCtValHi 100
2013-04-08 18:20:34 R-TK_test1_chn-01-shCtValLo 50
2013-04-08 18:20:34 R-TK_test1_chn-01-shOffDly 0 s
2013-04-08 18:20:34 R-TK_test1_chn-01-shOffTime 111600 s
2013-04-08 18:23:33 R-TK_test1_chn-01-shOffTimeMode set_absolut
2013-04-08 18:20:34 R-TK_test1_chn-01-shOnDly 0 s
2013-04-08 18:20:34 R-TK_test1_chn-01-shOnTime 111600 s
2013-04-08 18:23:33 R-TK_test1_chn-01-shOnTimeMode set_absolut
2013-04-08 18:20:34 R-TK_test1_chn-01-shSwJtDlyOff on
2013-04-08 18:20:34 R-TK_test1_chn-01-shSwJtDlyOn off
2013-04-08 18:20:34 R-TK_test1_chn-01-shSwJtOff on
2013-04-08 18:20:34 R-TK_test1_chn-01-shSwJtOn off
danke für die Unterstützung, auch wenn ich es noch immer vollsändig verstehe, aber so tut es jetzt wie gewünscht (wenn nicht noch irgendein timer zuschlägt)
Gruss
Karl
Hallo Karl,
will ich einmal versuchen zu verstehen - und zu erklaeren
R-TK_test1_chn-01-shActionType set_jmpToTarget
"set_" : du hast nach dem letzten setze kein getConfig gemacht.
dieser 'peer-link' arbeitet nach der JT, also die folgenden 4:
R-TK_test1_chn-01-shSwJtDlyOff on
Falls Channel im State DelayOff (ausschaltverzoegerung: Licht noch an, aber separater timer laeuft), und Trigger kommt gehe sofort nach Zustand "on"
Falls kein Trigger kommt gehe nach off (licht aus) wenn Timer zu Ende
R-TK_test1_chn-01-shSwJtDlyOn off
Falls Channel im State DelayOn (Einschaltverzoegerung: Licht noch aus, aber separater timer laeuft), und Trigger kommt gehe sofort nach Zustand "off"
Falls kein Trigger kommt gehe nach on (licht aus) wenn Timer zu Ende
R-TK_test1_chn-01-shSwJtOff on
Falls Channel im State Off (Licht aus), und Trigger kommt gehe sofort nach Zustand "on"
Falls kein Trigger kommt gehe nach dlyOn sobald Timer zu Ende
R-TK_test1_chn-01-shSwJtOn off
Falls Channel im State On (Licht an), und Trigger kommt gehe sofort nach Zustand "off"
Falls kein Trigger kommt gehe nach dlyOff sobald Timer zu Ende
Die zugehoerigen timer sind:
R-TK_test1_chn-01-shOffDly 0 s #keine Wartezeit, sofort in den naechsten Zustand
R-TK_test1_chn-01-shOffTime 111600 s #max ^= zustand wird nicht automatisch verlassen
R-TK_test1_chn-01-shOnDly 0 s #keine Wartezeit, sofort in den naechsten Zustand
R-TK_test1_chn-01-shOnTime 111600 s #max ^= zustand wird nicht automatisch verlassen
Somit hiesst dies:
die beiden delay Zustaende werden nicht angesprungen. Es kann aber sein, dass ein weiterer Peer diese Zustaende benutzt. Demnach koennte der Channel schon im Zustand dlyOn verweilen, eben durch einen trigger eines anderen Peers.
Ansonsten (ohne weiteren Peer) sind die beiden dly 2-fach ausgeschaltet: Verweildauer ist '0' UND es wird aus 'on' direkt nach 'off' verzweigt ohne ueber dlyOff zu gehen.
Nun die Condition table, da bin ich mir nicht so sicher wie bei der JT, wie schon erwaehnt.
Die schwellwerte: Den Kontakt sendet 0 oder 200, somit habe die Grenzen einen netten Puffer. Zwischenwerte gibt es eh nicht.
R-TK_test1_chn-01-shCtValHi 100
R-TK_test1_chn-01-shCtValLo 50
R-TK_test1_chn-01-shCtOff ltLo
#wenn chn im Zustand off und ein trigger kommt pruefe den Wert. Wenn Wert kleiner 50 fuehre Trigger aus.
=> 200^=Fenster offen: Trigger wird weggefiltert=> bleibe in OFF
=> 0^= Fenster zu: Trigger wird ausgefuehrt => JT springt nach ON
R-TK_test1_chn-01-shCtOn geHi #
#wenn chn im Zustand on und ein trigger kommt pruefe den Wert. Wenn Wert groesserGleich 100 fuehre Trigger aus.
=> 200^=Fenster offen: Trigger wird ausgefuehrt=> JT springt nach OFF
=> 0^= Fenster zu: Trigger wird weggefiltert => bleibe in ON
Die beiden funktionieren entsprechend, sind aber nicht relevant
R-TK_test1_chn-01-shCtDlyOff geHi #
R-TK_test1_chn-01-shCtDlyOn geHi #
und die beiden kann ich nicht deuten...
R-TK_test1_chn-01-shOffTimeMode set_absolut
R-TK_test1_chn-01-shOnTimeMode set_absolut
Der Aktor geht also mit jedem "fenster offen" nach off und Fenster zu nach 'on'
Alles korrekt so?
ich wuerde diesen umsetzen, damit alles aufgeraeumt ist.
R-TK_test1_chn-01-shCtDlyOff ltLo
Gruss
Martin
Hallo Martin,
du hast natürlich recht, habe kein getConfig gemacht. hier ist die aktuellste list:
2013-04-09 13:58:46 R-TK_test1_chn-01-shActionType jmpToTarget
2013-04-09 16:38:13 R-TK_test1_chn-01-shCtDlyOff ltLo
2013-04-09 16:38:13 R-TK_test1_chn-01-shCtDlyOn geHi
2013-04-09 13:58:46 R-TK_test1_chn-01-shCtOff ltLo
2013-04-09 13:58:46 R-TK_test1_chn-01-shCtOn geHi
2013-04-08 18:20:34 R-TK_test1_chn-01-shCtValHi 100
2013-04-08 18:20:34 R-TK_test1_chn-01-shCtValLo 50
2013-04-08 18:20:34 R-TK_test1_chn-01-shOffDly 0 s
2013-04-08 18:20:34 R-TK_test1_chn-01-shOffTime 111600 s
2013-04-09 13:58:46 R-TK_test1_chn-01-shOffTimeMode absolut
2013-04-08 18:20:34 R-TK_test1_chn-01-shOnDly 0 s
2013-04-08 18:20:34 R-TK_test1_chn-01-shOnTime 111600 s
2013-04-09 13:58:46 R-TK_test1_chn-01-shOnTimeMode absolut
2013-04-08 18:20:34 R-TK_test1_chn-01-shSwJtDlyOff on
2013-04-08 18:20:34 R-TK_test1_chn-01-shSwJtDlyOn off
2013-04-08 18:20:34 R-TK_test1_chn-01-shSwJtOff on
2013-04-08 18:20:34 R-TK_test1_chn-01-shSwJtOn off
Funktioniert jetzt mit einem SC genauso wie geplant:
Tür/Fenster geschlossen -> Ch01 Relais on (alarmanlage meldet alle Türen/Fenster geschlossen
Tür/Fenster offen -> Ch01 Relais aus -A Alarm bei Alarmanlage
Wenn ich es richtig verstanden habe kann ich die Ein/Ausschaltverzögerung auch auf off setzten?
So, jetzt kommt die WG_Gartentuer ins Spiel, ich habe natürlich nicht nur einen sondern zwei Kontakte, und bei einem anderen Kreis drei Kontakte. jetzt brauche ich eine (ich glaube d.h.)NOR Verknüpfung, nur wenn alle Kontakte geschlossen sind soll auch das Relais des Kanals on (geschlossen) sein. Sollte einer der Kontakt offen sein dann soll auch der Kanal off sein.
Muss ich jetzt hier die Werte der einzelnen Peers zusammenzählen, d.h. die Schwellwerte entsprechend hochsetzen?
die nächste Frage wäre noch, ich nehme an der Sabotagekontakt wird auch einen Wert liefern, den muss ich natürlich auch bedenken, denn der soll ja auch Alarm auslösen.
Ich nehme an dass das die Zeile aus dem Log ist wo du vorher den Statuswert des SC ausgelesen hast?
HMLAN_Parse: HMLAN S:E1E7B7D stat:0000 t:2A14BA84 d:FF r:FFB4 m:4DA4411E7B7D10F5FB014AC8
Wenn ich das ein bischen erklärt bekomme kann ich das für den Sabotagekontakt selber auslesen.
gruß
Karl
ZitatWenn ich es richtig verstanden habe kann ich die Ein/Ausschaltverzögerung auch auf off setzten?
Ich denke du denkst falsch.
Die Aktoren arbeiten in statemachines. Die hier hat 4 Zustaende. dlyon,on,dlyoff,off.
im Prinzip rotiert der Zustand immer in diesem Kreis. Wenn der Aktor in den Zustand kommt bleibt er drin, bis die Zeit abgelaufen ist (jeder hat einen Timer).
Der Maxwert bei on und off ist forever, nicht so bei dly.
Wenn du also bei allen timern 10 einstellst wird das Licht immer on, 10sec dlyOff, 10 sec off, 10sec off 10sec dlyon.
Soweit klar?
Normal ist dass mindestens ein Zustand 'forever' ist, on oder/und off.
So jetzt kommen die Trigger. Wenn ein trigger kommt und das Licht ist im Zustand "on" wird ohne verzug in den Zustand gesprungen, der in "shSwJtOn" steht. Wenn da off steht wird in den Zustand off gesprungen. Wenn darin dlyOn steht wird in diesen Zustand gesprungen. Und wenn on drinsteht wird der on-timer neu gestartet.
Hoffe es hilft zu Verstehen.
deine Message ist die Falsche.
Zum Ersten solltest du nachsehen, dass die Sabotage message auch freigeschaltet ist. hast du die Register einmal nachgesehen?
Dann brauche wir eine Info-message. oder eine Ack.
ich werde einbauen, dass es einen Event gibt, fehlt noch. Logs waeren gut, auch die kompletten Register.
Aktuell sollte eigentich Cover open/closed kommen anstelle von Sabotage. Kannst du dies sehen?
Gruss
Martin
ja die messages seh ich:
2013-04-09 20:10:03 CUL_HM TK_test1 alive: yes
2013-04-09 20:10:03 CUL_HM TK_test1 battery: ok
2013-04-09 20:10:03 CUL_HM TK_test1 cover: closed
2013-04-09 20:10:03 CUL_HM TK_test1 closed
2013-04-09 20:10:03 CUL_HM TK_test1 contact: closed (to HMLAN)
hier das log:
einmal cover öffnen, dann schliessen
2013.04.09 20:13:56 1: HMLAN/RAW: /E1E7B7D,0000,00094B31,FF,FFBD,95A6101E7B7D10F5FB0601000E
2013.04.09 20:13:56 1: HMLAN_Parse: HMLAN S:E1E7B7D stat:0000 t:00094B31 d:FF r:FFBD m:95A6101E7B7D10F5FB0601000E
2013.04.09 20:13:56 1: HMLAN: Skip ACK
2013.04.09 20:13:57 1: HMLAN_Send: K
2013.04.09 20:13:57 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0315745,1C6584,10F5FB,00094E2D,0000
2013.04.09 20:13:57 1: HMLAN_Parse: HMLAN V:03C1 sNo:JEQ0315745 d:1C6584 O:10F5FB m:00094E2D IDcnt:0000
2013.04.09 20:14:00 1: HMLAN/RAW: /E1E7B7D,0000,000959E4,FF,FFB6,95A6101E7B7D10F5FB0601000E
2013.04.09 20:14:00 1: HMLAN_Parse: HMLAN S:E1E7B7D stat:0000 t:000959E4 d:FF r:FFB6 m:95A6101E7B7D10F5FB0601000E
2013.04.09 20:14:02 1: HMLAN/RAW: /E1E7B7D,0000,00095DD3,FF,FFBC,95A6101E7B7D10F5FB0601000E
2013.04.09 20:14:02 1: HMLAN_Parse: HMLAN S:E1E7B7D stat:0000 t:00095DD3 d:FF r:FFBC m:95A6101E7B7D10F5FB0601000E
2013.04.09 20:14:03 1: HMLAN/RAW: /E1E7B7D,0000,000965B6,FF,FFAE,95A6101E7B7D10F5FB0601000E
2013.04.09 20:14:03 1: HMLAN_Parse: HMLAN S:E1E7B7D stat:0000 t:000965B6 d:FF r:FFAE m:95A6101E7B7D10F5FB0601000E
2013.04.09 20:14:08 1: HMLAN/RAW: /E1E7B7D,0000,00097580,FF,FFB4,95A6101E7B7D10F5FB0601000E
2013.04.09 20:14:08 1: HMLAN_Parse: HMLAN S:E1E7B7D stat:0000 t:00097580 d:FF r:FFB4 m:95A6101E7B7D10F5FB0601000E
2013.04.09 20:14:15 0: HMLAN/RAW: /E1E7B7D,0000,00099520,FF,FFB3,95A6101E7B7D10F5FB0601000E
2013.04.09 20:14:15 0: HMLAN_Parse: HMLAN S:E1E7B7D stat:0000 t:00099520 d:FF r:FFB3 m:95A6101E7B7D10F5FB0601000E
2013.04.09 20:14:22 0: HMLAN_Send: K
2013.04.09 20:14:22 0: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0315745,1C6584,10F5FB,0009AFE0,0000
2013.04.09 20:14:22 0: HMLAN_Parse: HMLAN V:03C1 sNo:JEQ0315745 d:1C6584 O:10F5FB m:0009AFE0 IDcnt:0000
und der list befehl
Internals:
DEF 1E7B7D
EVENTS 3
HMLAN_MSGCNT 18
HMLAN_RAWMSG E1E7B7D,0000,00099520,FF,FFB3,95A6101E7B7D10F5FB0601000E
HMLAN_RSSI -77
HMLAN_TIME 2013-04-09 20:14:15
IODev HMLAN
LASTInputDev HMLAN
MSGCNT 18
NAME TK_test1
NR 744
STATE closed
TRIGGERTIME 2013-04-09 20:13:56
TYPE CUL_HM
lastMsg No:95 - t:10 s:1E7B7D d:10F5FB 0601000E
protCmdPend 9 CMDs_pending
protLastRcv 2013-04-09 20:14:15
protState CMDs_pending
rssi_at_HMLAN avg:-73.94 min:-83 max:-67 lst:-77 cnt:18
Readings:
2013-04-09 20:03:17 Activity: alive
2013-04-09 20:08:47 R-sabotageMsg set_on
2013-04-09 20:13:56 alive yes
2013-04-09 20:13:56 battery ok
2013-04-09 20:13:56 contact closed (to HMLAN)
2013-04-09 20:13:56 cover open
2013-04-09 20:13:56 state closed
cmdStack:
++A00110F5FB1E7B7D00050000000000
++A00110F5FB1E7B7D00081001
++A00110F5FB1E7B7D0006
++A00110F5FB1E7B7D00040000000000
++A00110F5FB1E7B7D0103
++A00110F5FB1E7B7D01040000000001
++A00110F5FB1E7B7D00040000000000
++A00110F5FB1E7B7D0103
++A00110F5FB1E7B7D01040000000001
Helper:
getCfgList all
getCfgListNo 4
mId 002F
rxType 12
Respwait:
Role:
chn 1
dev 1
Rpt:
IO HMLAN
msg A0D95A6101E7B7D10F5FB0601000E::-67:HMLAN
ts 1365531236.71715
ack:
HASH(0xb50100)
95800210F5FB1E7B7D00
Rssi:
At_hmlan:
avg -73.9444444444444
cnt 18
lst -77
max -67
min -83
Shadowreg:
RegL_00: 10:01
Attributes:
actCycle 028:00
actStatus alive
expert 2_full
firmware 2.0
model HM-SEC-SC
peerIDs
room development
serialNr JEQ0720585
subType threeStateSensor
achja, hat keine effekt auf den switch gehabt.
lg
karl
Karl,
cover habe ich fuer den sec-sc gegen sabotage ausgetauscht.
Deine Logs zeigen nur ein Event. Kannst du es noch einmal machen - und deutlich laenger Warten?
Ich denke HMLAN braucht noch eine Verbesserung bei den Acks an dieser Stelle.
das "list" zeigt, dass die Kommandos noch nicht abgesendet waren, hast du sicher gesehen.
"protState CMDs_pending"
Anlernen druecken um es auszufuehren
Gruss
Martin
Hallo Martin,
hier nun der neue trace, habs jetzt ein paarmal geöffnet und geschlossen, sollten alle Meldungen enthalten:
------------------------------------
2013.04.14 15:28:12 0: HMLAN_Parse: HMLAN R:E1E7B7D stat:0000 t:180580B0 d:FF r:FFB9 m:BA A610 1E7B7D 10F5FB 0601C800
2013.04.14 15:28:27 0: HMLAN_Send: HMLAN I:K
2013.04.14 15:28:28 0: HMLAN_Parse: HMLAN V:03C1 sNo:JEQ0315745 d:1C6584 O:10F5FB m:1805BA7A IDcnt:0004
2013.04.14 15:28:39 1: HMLAN_Parse: HMLAN R:E1E7B7D stat:0000 t:1805EB27 d:FF r:FFBA m:BB A610 1E7B7D 10F5FB 0601C80E
2013.04.14 15:28:43 1: HMLAN_Parse: HMLAN R:E1E7B7D stat:0000 t:1805F8D4 d:FF r:FFB6 m:BC A610 1E7B7D 10F5FB 0601C800
2013.04.14 15:28:46 1: HMLAN_Parse: HMLAN R:E1E7B7D stat:0000 t:18060681 d:FF r:FFB7 m:BD A610 1E7B7D 10F5FB 0601C80E
2013.04.14 15:28:50 1: HMLAN_Parse: HMLAN R:E1E7B7D stat:0000 t:18061623 d:FF r:FFB6 m:BE A610 1E7B7D 10F5FB 0601C800
2013.04.14 15:28:52 1: HMLAN_Send: HMLAN I:K
2013.04.14 15:28:52 1: HMLAN_Parse: HMLAN V:03C1 sNo:JEQ0315745 d:1C6584 O:10F5FB m:18061C40 IDcnt:0004
2013.04.14 15:28:54 1: HMLAN_Parse: HMLAN R:E1E7B7D stat:0000 t:180625C3 d:FF r:FFB9 m:BF A610 1E7B7D 10F5FB 0601C80E
2013.04.14 15:28:59 1: HMLAN_Parse: HMLAN R:E1E7B7D stat:0000 t:1806365D d:FF r:FFBB m:C0 A610 1E7B7D 10F5FB 0601C800
Hallo Karl,
du solltest jetzt die sabotage meldungen erhalten haben - korrekt?
Im Log kommt staendig auf/zu. Ist das so korrekt?
Gruss
Martin
Ja, das ist korrekt, ich habs ein paar mal geöffnet und geschlossen.
Gruss karl
dann sind deine Probleme geloest (diese jedenfalls)?
Gruss
Martin
Naja fast.
Eigentlich soll ja auch bei sabotage ein alarm ausgelöst werden, also fenster offen -> alarm, sabotagekontakt offen -> Alarm.
Geht das?
Gruss
Karl
Hi Karl,
wieso nicht? Du kannst doch auf jedes reading ein notify setzen
define <nfName> notify <channame> <action>
oder
define <nfName> notify <channame>:<reading> <action>
in deinem Fall 2teres
define allSaboAlarm notify .*sabotageError.* {Log 1,"sabotage fuer $Name ist $EVENT "}
Log ist natuerlich nicht clever, evtl eine email, den Tuergong,...
Weniger elegant ist es sich viele Notifies zu basteln: schlechte wartung, erhoehter Performance bedarf. Sieht im extremen so aus
define SaboAlarm1 notify Fenster1:.*sabotageError:on.* <onAction1>
define SaboAlarm2 notify Fenster1:.*sabotageError:off.* <offAction1>
define SaboAlarm3 notify Fenster2:.*sabotageError:on.* <onAction2>
define SaboAlarm4 notify Fenster2:.*sabotageError:off.* <offAction2>
Schau dir die Notifies an, die koennen viel.
Frage beantwortet?
Gruss
Martin
Sorry, Ich war nicht exakt mit meiner anforderung, es soll auch ohne fhem funktionieren, ich hab damit immer noch das problem das nach ein bis zwei tagen der fhem.pl prozess auf 99% cpu geht und dann geht nichts mehr.
Aber auch abgesehen davon sollten alle sicherheitsrelevanten abläufe auch ohne fhem funktionieren, also auch bei stromausfall, ausfall fhem usw.
Ich dachte mir eigentlich dass dieser schalter auch eine wert liefert den ich in den registern mit einbeziehen kann und entsprechend schalte, liege ch da falsch?
Gruss
Karl
Das geht so nicht.
Ganz klar ist mir nicht, was du vor hattest. Wenn Sabotage 'kommt' das Licht einschalten oder den Tuergong? Nicht ironisch gemeint, aber ich verstehe nicht, welchen Aktor du triggern wolltest.
Erwarten wuerde ich, dass bei Sabotage (falls es mich interessiert) Aktionen wie emails laufen oder ich ein Alarm-window am Smartphone betreibe.
Jedenfalls sehe nich nicht, dass Aktoren auf die status-bytes eines Sensors reagieren koennen. Das kann nur die Zentrale auswerten und ggf weitere Schritte einleiten.
Gruss
Martin
Hallo Karl,
Zitat von: schka17 schrieb am Di, 16 April 2013 17:03... ich hab damit immer noch das problem das nach ein bis zwei tagen der fhem.pl prozess auf 99% cpu geht und dann geht nichts mehr. ...
dann sollten wir vlt. in einem anderen Thread versuchen das Problem der 99%-Auslastung zu beheben? Dann kannst du auch ruhigen Gewissens die von dir gewünschte Aufgabe deiner Fhem-Zentrale überlassen.
Gruß
Thomas
Danke, das habe ich schon probiert.
Link (http://forum.fhem.de/index.php?topic=12234.0)
Aber zum anderen thema, ich habe natürlich auch überall sabotagekreise bei den verdrahteten sensoren, mein plan war das ein kanal des switches den alarmeingang schaltet und auf kanal 2 der sabotagealarm ausgelöst wird. Das eine ganz normale funktion der alarmanlage, und dort funktionieren alle alrmierungsfunktionen (telefonanruf, weil alles andere ist keine alarmierung sondern eine mehr oder weniger zuverlässige benachrichtigung) auch zb ohne stromversorgung weil eben ein notstrom akku eingebaut ist. Ich will mir eigentlich für den rasbperry nicht auch noch eine usv hinstellen.
Und jetzt auch ohne frtzibox einen telefonanruf auszulösen ist mir doch ein bischen zu aufwendig, zumal ich bei der alarmanalge dafür nur einen kontakt betätigen muss und je nach alarm, einbruch, sabotage. Wasser, stromausfall, feuer die entsprechende alarmierung erfolgt.
Aber wenn das nicht funktioniert dann werde ich mit geringen risiko leben, alles andere funktioniert ja soweit mal zufriedenstellend,zumindest bis den loopenden prozess ( als laie formuliert), also danke für die unterstützung. Das loopen hab ich mit einem unschönen workaround im griff, nämlich fhem einmal am tag restarten( das hilft auch beim ir empfangsproblem des CUNO) aber das soll kein dauerzustand bleiben.
Gruss
Karl