Peeren zur Reichweitenvergrößerung

hugo · 12 Februar 2019, 18:39:00

Hallo zusammen,
Ich verwende einen HM-Sensor (HM-SEC-SC) zur Garagentor Überwachung. Leider ist die Reichweite nicht ausreichend. Da ich in der Funkzwischenstrecke einen 4-Fach Schalter (HM-LC-SW4-PCB) habe, bei dem nur 3 Schalter genutzt werden, war jetzt meine Idee den Sensor mit dem 4. Schalter zu Peeren und den Status für das Garagentor von diesem Schalter zu übernehmen.
Könnte dies so funktionieren?

Würde ein "set Garagentor peerChan 0 Schalter_Bt4 single" schon reichen oder muss ich noch was berücksichtigen?
Wie kann ich überprüfen, ob das Peeren funktioniert hat.

KernSani · 14 Februar 2019, 00:22:31

da hier keine Antwort zu kommen scheint... Vielleicht mal nach Homematic verschieben (Button ganz unten links)

rvideobaer · 14 Februar 2019, 09:38:25

Hallo,

am besten Du probierst es aus, kann sein das du beim Schaltaktor noch ein Register ändern musst. Das hatte ich bei mir da habe ich ein Wandthermostat mit einem Schaltaktor verbunden und er hat immer nur auf das einschaltsignal reagiert. Aber probiere doch erst einmal beide zu verbinden.

Gruß Rolf

Otto123 · 14 Februar 2019, 09:45:03

Zitat von: hugo am 12 Februar 2019, 18:39:00
Könnte dies so funktionieren?

Würde ein "set Garagentor peerChan 0 Schalter_Bt4 single" schon reichen oder muss ich noch was berücksichtigen?
Wie kann ich überprüfen, ob das Peeren funktioniert hat.

Hallo,

schräge Idee, ob das gewünschte Ergebnis erzielt werden kann weiß nicht.
Zum peeren -> https://wiki.fhem.de/wiki/Homematic_Peering_Beispiele
Ich würde den Standard (dual set both)verwenden und schauen was passiert:

Code Auswählen

set Garagentor peerChan 0 Schalter_Bt4
Falls dein Aktor wirklich _Bt4 heisst?

Das peeren wird allerdings in die Hose gehen, wenn Du keinen Funkkontakt zu Garagentor hast

Denk doch über einen FUNK IO nach?

Gruß Otto

Beta-User · 14 Februar 2019, 10:30:33

Was evtl. ein Problem sein könnte: zum Peeren muß gepairt sein. Dann wird aber der Sec immer versuchen, auch an die Zentrale zu senden. Das geht auf die Batterielebensdauer, wenn es nicht klappt.

Du solltest also nach dem Peeren den Sec wieder ent-Pairen.

Pfriemler · 14 Februar 2019, 12:02:55

Zitat von: hugo am 12 Februar 2019, 18:39:00
Würde ein "set Garagentor peerChan 0 Schalter_Bt4 single" schon reichen oder muss ich noch was berücksichtigen?
Wie kann ich überprüfen, ob das Peeren funktioniert hat.

Abgesehen von dem Problem, dass Du zum Peeren den HM-SEC-SC in die Reichweite der Garage bringen musst (wobei bei meiner Blechgarage die Erreichbarkeit bei offenem Tor viel besser ist als bei geschlossenem - wie das nur kommt

), empfehle ich Dir mal diesen Wiki-Beitrag (Automatisches Licht mit Tür oder Tor) durchzulesen. Mit der dort beschriebenen Modifikation wird der Schaltzustand des Aktors dem Torzustand folgen, ohne dieses reagiert er nur auf das Öffnen und schaltet dann nur hin und her.
Sonst natürlich eine clevere Idee, die funktionieren wird. edit: Und ja: single peeren, nicht dual.

hugo · 14 Februar 2019, 12:37:35

ZitatFalls dein Aktor wirklich _Bt4 heisst?

Der HM-LC-SW4-PCB hat doch 4 Tasten, ich dachte ich muss einen davon peeren.

ZitatDas peeren wird allerdings in die Hose gehen, wenn Du keinen Funkkontakt zu Garagentor hast

Würde den Sensor zum peeren ausbauen.

ZitatDenk doch über einen FUNK IO nach?

In der Garage habe ich leider kein WLAN-Empfang.

Wie kann ich sehen ob richtig gepeert wurde?

@Pfriemler Danke für den Hinweis auf den Wiki-Beitrag.

Werde es einfach einmal testen, wird schon klappen.

Otto123 · 14 Februar 2019, 12:46:52

Zitat von: hugo am 14 Februar 2019, 12:37:35
Der HM-LC-SW4-PCB hat doch 4 Tasten, ich dachte ich muss einen davon peeren.

Bei mir heissen die Schalter per default immer Sw04 und die Tasten Btn_04

Ich wegen dem Namen kurz etwas verwirrt.

Pfriemler hat aber darauf hingewiesen single zu peeren, also dann vergiss meinem Einwand mit dem Standard (dual)
Ich habe noch keinen Kontakt mit einem Aktor gepeert ich weiß es einfach nicht. Theoretisch kann auch sein, dass dual oder single identisch ist? Immerhin hat der Kontakt ja keine zweite "Taste"

Beta-User · 14 Februar 2019, 12:57:57

Zitat von: hugo am 14 Februar 2019, 12:37:35
Wie kann ich sehen ob richtig gepeert wurde?

Müßte über getConfig in Erfahrung zu bringen sein. Dabei immer bei den Batterie-Geräten darauf achten, dass keine messages mehr pending sind, bevor man das absetzt. Dann entweder Knopf drücken oder das Teil (mehrfach) auslösen.

Pfriemler · 14 Februar 2019, 14:26:29

Ja, ich habe solche Aktor-folgt-Sensor-Szenarien schon reichlich ausprobiert ...
dual peer funktoniert auch irgendwie, stellt aber im Aktor üblicherweise eben getrennte Aktionen für zwei Tasten bereit, d.h. hier würde der Kontakt vermutlich nur ausschalten. Kann man mit Registern natürlich alles auch hinbiegen, aber der Weg über single und das Umdefinieren der einen Aktorschwelle ist einfach schneller. Wenn es nicht gar längst ein Template dafür gibt.

Dann sehe ich natürlich _Btn4 auch kritisch - es muss natürlich der Name des vierten Schaltkanals des HM-LC-Sw4-PCB sein, wie auch immer er nun wirklich heißt, und das ist - Einwand berechtigt - üblicherweise was wie _Sw4 oder _Sw04. Die Buttons in diesem Gerät sind einzeln gar nicht ansprech- oder auswertbar und sind nur für das Bearbeiten interner Peerings mit "self0x" (x=1...4) relevant.

ZitatDann entweder Knopf drücken oder das Teil (mehrfach) auslösen.

Hängt vom Alter des HM-Sec-SC ab. Ältere können noch kein lazy Config - müssen also immer per Knöpfchen angeschubst werden.

Ob richtig gepeert wurde, sieht man in der peerList beider Geräte nach getConfig. Funktionierte das Peeren, erzeugt ein Kontaktöffnen zunächst das beschriebene Ein- und Ausschalten, auf=an, zu=(nichts), auf=aus, zu=(nichts) usw. Erst nach dem Setzen des beschriebenen Registers auf "ltLo" muss der Aktor sauber dem Kontakt folgen: auf = an, zu = aus, und zwar auch wenn zwischendurch am Aktor manuell umgeschaltet wird.

Otto123 · 14 Februar 2019, 15:28:30

Da muss ich vorsichtig widersprechen: Alle sicherheitsrelevanten Konfigurationen (darunter wird peeren auch fallen) sind bei bei den SEC Geräten eventuell nur mit Konfigtaste und nicht durch auslösen machbar.
Bei meinem SEC-SCo ist ein Auslösen der Lichtschranke während einer Konfigurationsänderung nicht förderlich. Man muss da unbedingt aufpassen den Knopf zu drücken ohne auszulösen (was manchmal gar nicht so einfach ist)

Beim auslösen passiert zwar eine Datenübertragung (sichtbar) aber die Konfigurationsänderung wird verworfen.

martinp876 · 14 Februar 2019, 20:50:10

Also ist doch einfach: single peeren, sonst wird versucht 2 buttons zu peeren. Du hast nur einen (den sensor) - erstes problem.
Weiter wird der aktor nur auf oder zu schalten bei einem der dual Kanäle. Du brauchst toggel.
Der sensor wird einen trigger senden mit jeder aktion. Der aktor wird dann schalten und meldet - nicht den trigger sondern - die Statusänderung an die Zentrale. Wenn sich der status nicht ändert auch keine meldung ( meist!).

Nun kannst du es besser. Der sc sendet einen level, meine ich. Also offen oder zu. Wenn du willst kannst du das mit demmschaltzustand des sw4 verbinden durch nutzen der shCt... Register.
Coole idee.

Nicht vergessen, die batterien werden nicht überwacht.

Ich würde den sc programmieren und auslesen. Dann einbauen, das io device auf ein dummy setzen ( es macht keinen sinn zu senden) und autoreadreg abschalten, und auch actcycle abklemmen. Dann lässt fhem das device in ruhe. Alternativ alles auf dummy setzen ( also de sc)
Die alternative ist der selektive repeater!.

Pfriemler · 14 Februar 2019, 21:22:27

Zitat von: Otto123 am 14 Februar 2019, 15:28:30
Da muss ich vorsichtig widersprechen: ...

Zu recht, zu recht ...

ZitatAlle sicherheitsrelevanten Konfigurationen (darunter wird peeren auch fallen) sind bei bei den SEC Geräten eventuell nur mit Konfigtaste und nicht durch auslösen machbar.

Nicht nach meiner Erfahrung. Wo Du recht hast: Die -SC(-2) unterstützen gar kein lazyConfig, aber ansonsten etliche -SEC-Geräte wie die SCo, der RHS (Griffsensor), WDS (Wasserstandsmelder, wobei das da wenig Sinn macht

) usw usf.

ZitatBeim auslösen passiert zwar eine Datenübertragung (sichtbar) aber die Konfigurationsänderung wird verworfen.

Ich meine Gegenteiliges beobachtet zu haben, aber ich checke das nochmal. Dann wäre ja lazyConfig reichlich sinnlos...

@Martin: Ich glaube, die Idee den Schaltzustand des Schaltaltors (bzw. seine Events) statt die Events des -SC zu überwachen war genau des TE Idee.
Die Vorschläge bezüglich actCycle und autoReadReg kann ich nur bestätigen! Dummy-IO wird dann aber nicht nötig sein, wenn FHEM nichts mehr senden will. Und sollte man doch mal wieder was konfigurieren wollen, sucht man sich dann den Wolf.
Man könnte dann noch die sonst für die Batterieüberwachung unverzichtbare zyklische Meldung deaktiveren:

Code Auswählen

set <NameMeines_HM-SEC-SC> regSet cyclicInfoMsg off
Da der so aktivierte SC (und auch jeder optische SCo etwa jede Stunde) ihren Status aktualisieren, verwendet man ja dort üblicherweise ein event-on-change-reading (state oder .*), was man nun auch am Schaltkanal tun sollte - wenn nicht schon längst wie empfohlen geschehen.

martinp876 · 16 Februar 2019, 08:23:30

@ Pfriemler: schon klar, dass es die Idee war. Aber hier unbedingt die Programmierung der CT beachten - sonst bekommt man nur Änderungen mit, nicht den Zustand! Bzw der Zustand des Sw ist zufällig. Toggle ist nicht sinnvoll - zu unsicher.

Bei LacyConfig werden konfigurationen sowie bspw getConfig übertragen. Voraussetzung ist allerdings das peeren des kanals mit der Zentrale. Das passiert wenn a) garnicht gepeert ist oder b) einer der Peers ein Kanal der vccu (oder des IO ... - nicht empfohlen) ist.

event-on-change-reading .* empfehle ich unablässig für ALLE CUL_HM entities. Daher führe ich bei jeden Reboot ein

Code Auswählen

attr TYPE=CUL_HM event-on-change-reading .*
aus.

Pfriemler · 16 Februar 2019, 17:43:25

Zitat von: martinp876 am 16 Februar 2019, 08:23:30
... unbedingt die Programmierung der CT beachten - sonst bekommt man nur Änderungen mit, nicht den Zustand! Bzw der Zustand des Sw ist zufällig. Toggle ist nicht sinnvoll - zu unsicher.

Das ist es ja nicht mal allein - ohne Eingriff reagiert der Sw nur auf jedes zweite Event, es gibt gar keine Zuordnung, bzw. der Schalter wechselt halb so oft den Zustand wie das Tor.

ZitatBei LacyConfig werden konfigurationen sowie bspw getConfig übertragen. Voraussetzung ist allerdings das peeren des kanals mit der Zentrale. Das passiert wenn a) garnicht gepeert ist oder b) einer der Peers ein Kanal der vccu (oder des IO ... - nicht empfohlen) ist.

Soll heißen, ein zentralengepairtes Gerät, welches broadcast sendet, kann nicht lazy-konfiguriert werden?

Zitatevent-on-change-reading .* empfehle ich unablässig für ALLE CUL_HM entities.

Weiß ich doch

:

Zitat von: Pfriemler am 14 Februar 2019, 21:22:27
... event-on-change-reading (state oder .*), was man nun auch am Schaltkanal tun sollte - wenn nicht schon längst wie empfohlen geschehen.

Nur

Code Auswählen

attr TYPE=CUL_HM event-on-change-reading .*
unterschreibe ich nicht - es sollte der Mindeststandard sein, aber es empfiehlt sich durchaus, ggf. noch mehr Einschränkungen zu machen. Fensterkontakte erzeugen bei mir nur auf "contact,battery,sabotage" ein Event, bei Temperatursensoren ist es meist nur eine Temperatur. Würde ich das so global bei mir setzen, hätte ich hinterher viel mehr Events als gewünscht ...