Fensterdrehgeriffkontakt - Die nächste Runde

Begonnen von papa, 02 April 2020, 09:37:44

Vorheriges Thema - Nächstes Thema

rvideobaer

Hallo,

im Modus - HM-Sec-RHS-2 wird da auch die zusätzliche Fenster offen Meldung ausgegeben?

Gruß Rolf
Raspberry Pi 2, HM-Uart,1x HM-LC-Sw1PBU-FM, 1x HM-RC-2-PBU-FM,1x HM-LC-SW4-DR,1x HM-LC-Sw1-Pl-DN-R1,1x HM-TC-IT-WM-W-EU, 5x HM-CC-RT-DN und noch mehr

papa

Es gibt immer nur eine "Fenster Offen" Meldung. Wenn allerdings der 3 Sensor-Pin in Sketch definiert ist, muss dieser auch geschlossen sein, damit die "Fenster Zu" Meldung kommt. Es muss also der Griff auf geschlossen stehen (Magnet am Griff muss oben stehen) und der seitliche Sensor muss am Magnet sein.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

rvideobaer

Hallo,

und wie ist das dann in der gekippt Stellung?
Zur Zeit habe ich bei mir 2 Sensoren am Fenster 1x Drehgriff und einmal optisch. Da ich eine Jalousie habe die nur Funktioniert wenn das Fenster am Rahmen anliegt egal wie der Griff steht und ich würde das gerne über diesen 3. Kontakt lösen.

Gru0 Rolf
Raspberry Pi 2, HM-Uart,1x HM-LC-Sw1PBU-FM, 1x HM-RC-2-PBU-FM,1x HM-LC-SW4-DR,1x HM-LC-Sw1-Pl-DN-R1,1x HM-TC-IT-WM-W-EU, 5x HM-CC-RT-DN und noch mehr

papa

Wenn der Griff auf gekippt steht - also Magnet unten - dann spielt der Zustand des 3. Sensors keine Rolle. Es ist dann immer gekippt.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

rvideobaer

Hallo,

Ok, also nicht optimal für mich, lässt sich das anders auswerten das der 3. Kontakt unabhängig angezeigt wird? Meinetwegen auch als Sabotagekontakt?

Gruß Rolf
Raspberry Pi 2, HM-Uart,1x HM-LC-Sw1PBU-FM, 1x HM-RC-2-PBU-FM,1x HM-LC-SW4-DR,1x HM-LC-Sw1-Pl-DN-R1,1x HM-TC-IT-WM-W-EU, 5x HM-CC-RT-DN und noch mehr

Pfriemler

Ich muss mal einwerfen, dass mich diese Art der Umsetzung auch nicht befriedigt.

Es wäre vielleicht überlegenswert, aus dem threeStateSensor einen fourStateSensor zu entwickeln.
Ein threestate hat ja 0,100,200 = closed,tilted,open im Angebot.
Meine Idee wäre 0,50,100,200 = closed,unlocked,tilted,open zu senden.
unlocked ist dabei ein Fenster, welches nicht verriegelt ist, aber am Rahmen anliegt. Ob der Griff auf "open" oder "tilted" steht, könnte dabei egal sein.

Drehgriffsensor RHS und Fensterkontakt SCo fasse ich bei mir in einem DOIF zusammen, dass neben den genannten vier Zuständen auch noch "burglary" kennt - das ist ein Fenstergriff auf "closed" bei offenem Fensterflügel. Das passiert meist, wenn jemand das Fenster mit einem Kuhfuß aufzuhebeln versucht.

Auch die Innensirene/Minialarmanlage kennt eine weitere vom 0/100/200-Schema abweichende innere Wertestufe für "teilscharf". Das wäre also keine neue Erfindung.

rvideobaer könnte seine Rolladen dann fahren lassen, solange der gesendete Wert unter 100 liegt (für peering interessant) bzw. "closed" oder "unlocked".

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

papa

Sollte relativ einfach machbar sein. Lass mich mal ne Nacht drüber schlafen ;-)
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

papa

Zitat von: rvideobaer am 03 Mai 2020, 16:32:48
Ok, also nicht optimal für mich, lässt sich das anders auswerten das der 3. Kontakt unabhängig angezeigt wird? Meinetwegen auch als Sabotagekontakt?
Du kannst den 3. Sensor direkt als Sabotage-Kontakt im Sketch definieren. Das geht ohne Probleme. Hatte ich aber auch schon am Anfang mal für die schmale Variante erwähnt.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

rvideobaer

Hallo,

damit werde ich mich näher beschäftigen wenn meine Platinen da sind. Der Vorschlag von Pfriemler klingt aber auch gut da er vielleicht die weitreichendsten Möglichkeiten zur Konfiguration bietet.

Gruß Rolf
Raspberry Pi 2, HM-Uart,1x HM-LC-Sw1PBU-FM, 1x HM-RC-2-PBU-FM,1x HM-LC-SW4-DR,1x HM-LC-Sw1-Pl-DN-R1,1x HM-TC-IT-WM-W-EU, 5x HM-CC-RT-DN und noch mehr

papa

Ich muss hier mal vor der chinesischen TLE4913 Quelle warnen. Ich habe mahr als 50% Ausschuß bei den Dingern. Die machen einfach nichts. Das ist absolut nervig  >:(
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

rvideobaer

Hallo,

kann man das vor dem Einbau testen?

Gruß Rolf
Raspberry Pi 2, HM-Uart,1x HM-LC-Sw1PBU-FM, 1x HM-RC-2-PBU-FM,1x HM-LC-SW4-DR,1x HM-LC-Sw1-Pl-DN-R1,1x HM-TC-IT-WM-W-EU, 5x HM-CC-RT-DN und noch mehr

gloob

#116
Zitat von: papa am 03 Mai 2020, 19:45:27
Ich muss hier mal vor der chinesischen TLE4913 Quelle warnen. Ich habe mahr als 50% Ausschuß bei den Dingern. Die machen einfach nichts. Das ist absolut nervig  >:(

Reagieren die TLE4913 garnicht oder liegt es am zu schwachen Magneten?

Ich habe meine TLE4913 bei einer anderen Quelle gekauft und werde hier berichten.

Zitat von: rvideobaer am 03 Mai 2020, 19:49:15

kann man das vor dem Einbau testen?

Sollte halbwegs gut möglich sein, einfach auf eine Platine auflegen und leicht andrücken. Das ganze sollte auch ohne anlöten funktionieren. 
Die Signale sind dann auf der Console sichtbar.
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

papa

Die reagieren auf gar nichts. Ich habe noch eine Platine vom 1. Prototypen und pappe jeden da erst mal drauf. Da ist dann einfach eine LED dran, die leuchten muss, wenn der Magnet in die Nähe kommt.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

papa

Zitat von: Pfriemler am 03 Mai 2020, 19:02:05
Ich muss mal einwerfen, dass mich diese Art der Umsetzung auch nicht befriedigt.
Es gibt halt wie immer unterschiedliche Anforderungen.
Zitat von: Pfriemler am 03 Mai 2020, 19:02:05
Meine Idee wäre 0,50,100,200 = closed,unlocked,tilted,open zu senden.
unlocked ist dabei ein Fenster, welches nicht verriegelt ist, aber am Rahmen anliegt. Ob der Griff auf "open" oder "tilted" steht, könnte dabei egal sein.
Ich habe im RHS-Sketch ein neues Define USE_FOUR_STATES eingeführt. Wenn das gesetzt ist, wird der "unlocked" State entsprechend Deinem Vorschlag unterstützt. Damit das funktioniert, ist sowohl die akteullest AskSin++ (4.1.5) und die aktuellen HMMsg.pm & HMConfig_AskSinPPCustom.pm erforderlich. Schaut Euch das ganze mal in Ruhe an, ob es so passt.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

gloob

#119
Kann es sein, dass aktuell die zyklischen Statusmeldungen nicht funktionieren?
Ich hatte heute einen Kommunikationserror in der CCU obwohl testweise

#define CYCLETIME seconds2ticks(60UL * 1)

gesetzt ist.

16:48:15.171 -> AskSin++ V4.1.3 (May  4 2020 15:45:06)
16:48:15.171 -> Address Space: 32 - 102
16:48:15.171 -> 00000000
16:48:15.171 -> Init Storage: CAFEBE97
16:48:15.449 -> CC init1
16:48:15.482 -> CC Version: 14
16:48:15.482 ->  - ready
16:48:15.482 -> Config Freq: 0x216512
16:48:15.482 -> Activate Cycle Msg
16:48:18.865 -> <- 0E 01 86 10 095634 000000 06 01 C8 00 00  - 3698
16:48:24.203 -> ignore 0F 72 86 10 37EF85 000000 0A B0 EB 0C 1B 00  - 8976
16:48:27.699 -> ignore 13 12 00 83 2200EE F00001 07 71 9E 88 14 31 5B 1A 83 4A  - 12492
16:48:35.917 ->  debounce
16:48:35.950 ->  pressed
16:48:36.087 ->  released
16:48:36.158 -> <- 1A 02 84 00 095634 000000 22 00 C3 70 61 70 61 32 32 32 31 31 31 80 01 01 00  - 15378
16:48:36.158 ->
16:48:36.193 -> -> 10 0C A0 01 00FFFF 095634 00 05 00 00 00 00 00  - 15415
16:48:36.301 -> <- 0A 0C 80 02 095634 00FFFF 00  - 15536
16:48:36.336 -> -> 13 15 A0 01 00FFFF 095634 00 08 02 01 0A 00 0B FF 0C FF  - 15579
16:48:36.483 -> <- 0A 15 80 02 095634 00FFFF 00  - 15697
16:48:36.521 -> -> 0B 1E A0 01 00FFFF 095634 00 06  - 15728
16:48:36.521 -> Activate Cycle Msg
16:48:36.628 -> <- 0A 1E 82 02 095634 00FFFF 00  - 15857
16:48:37.015 -> ignore 0F 66 86 10 227A4A 000000 0A 28 D8 10 00 40  - 16250
16:48:44.050 -> ignore 0C B3 86 5A 2711AF 000000 28 E4 32  - 2325


Im Arduino Log sieht man leider auch keine Messages.
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway