Hi,
nimmt jemand den Homematic Funk-Neigungssensor HM-Sec-TiS aktiv zur Garagentorübwerwachung her?
Gibt es irgendwelche Probleme im Betrieb?
Wie lange hält die Batterie bei euch im Schnitt?
Bin für Erfahrungen dankbar.
LG
Ich benutze den HM-SEC-SCO fürs Garagentor, ist zwar nicht das selbe, aber er tuts eben auch für weniger Investment. Batterie jetzt schon fast 3 Jahre in Betrieb.
Ich habe damals auch den optischen Fenstersensor genommen. Mußte nur den Antennendraht aus dem Gehäuse führen, um die Funkanbindung zu verbessern. Als Information reichte mir auch, ob auf oder ganz geschlossen.
Ich nutze den Tis seit Jahren. Und würde ihn nicht wieder kaufen.
a) Der hat Schwierigkeiten, aus der geschlossenen Blechgarage heraus ein HM-IO in nur wenigen Metern Entfernung zu erreichen. transmDevTryMax kann helfen.
b) billige Li-Kekse (CR 2032) sorgen regelmäßig für verfrühte Batteriewarnungen besonders bei Kälte. Normalerweise hält die Batterie weit mehr als ein Jahr bei mehrmals täglichen Bewegungen.
c) Das Ding reagierte eine Zeitlang auch auf Fußbälle am Garagentor oder Sturmböen. Ich habe die eventFilterTime auf 4s verlängert. Verbaut ist nämlich kein Neigungssensor wie beim modernen Hm-IP-Pendant, sondern ein schlichter Rüttelkontakt mit Rollkugel.
d) das Ding kann kein lazyKonfig. Man muss bei Registeränderungen das Gehäuse öffnen und den Knopf betätigen.
und auch in diesem Zusammenhang:
e) den Vollidioten, der dieses Gehäuse konstruiert hat (die eQ3 bei allen wetterfesten Geräten einsetzt und das ich leider auch bei meinem "Dirk's" Außensensor benutze), sollte man erschießen und vierteilen. Vier Schrauben wechselseitig zu lösen und festzuschrauben (weil sich eine Schraube prompt festfrisst wenn man sie zu weit dreht) geht mir bei jedem Batteriewechsel (den ich wegen zu billiger Batterien im letzten Jahr 3x durchführen musste) SOWAS VON auf den Wecker. "Isch hab SON'N HALS, hab isch!" :-)
Glücklicherweise hat mein Garagentorantrieb eine eigene Positionserfassung und der TiS hat eher Warnfunktion, etwa weil ein Tor aufgeht, ohne dass der Antrieb benutzt wurde (Notentriegelung, Einbruch). Er schaltet auch die Garagenbeleuchtung aus, die aber aus Sicherheitsgründen eh nur zeitbegrenzt aktiviert wird.
Ich habe meinen seit Ende 2016 im Einsatz, musste letztes Jahr im September die Batterie wechseln, also knapp 3 Jahre bei 3-4 Toröffnungen am Tag und aktiviertem AES. Sonst keinerlei Probleme.
Ein Kollege musste nach etwa 5 Jahren die Anschlussstellen des Sensors auf der Platine nachlöten, ansonsten auch unauffällig.
Bei e) gebe ich dem Pfriemler recht :) damit ist auch d) recht nervig :) Kommt aber zum Glück bei mir nicht so häufig vor.
Zitat von: Gernott am 16 April 2020, 20:55:30
Ich habe damals auch den optischen Fenstersensor genommen. Mußte nur den Antennendraht aus dem Gehäuse führen, um die Funkanbindung zu verbessern. Als Information reichte mir auch, ob auf oder ganz geschlossen.
Zitat von: Dittel am 16 April 2020, 17:52:30
Ich benutze den HM-SEC-SCO fürs Garagentor, ist zwar nicht das selbe, aber er tuts eben auch für weniger Investment. Batterie jetzt schon fast 3 Jahre in Betrieb.
Ich hab in alten Forenbeiträgen gelesen, dass es mit dem optischen Fensterkontakt oft Sendeprobleme mit dem Metal-Tor gibt... und auch bei kleinster Abweichung, der Kontakt nicht auslöst.... was ja bei einem Garagentor leicht passieren kann (hat ja ein wenig Spiel mit Laufrollen etc.) Hattet ihr diesbzgl. keine Probleme?
Zitat von: Pfriemler am 16 April 2020, 23:04:09
Ich nutze den Tis seit Jahren. Und würde ihn nicht wieder kaufen.
a) Der hat Schwierigkeiten, aus der geschlossenen Blechgarage heraus ein HM-IO in nur wenigen Metern Entfernung zu erreichen. transmDevTryMax kann helfen.
b) billige Li-Kekse (CR 2032) sorgen regelmäßig für verfrühte Batteriewarnungen besonders bei Kälte. Normalerweise hält die Batterie weit mehr als ein Jahr bei mehrmals täglichen Bewegungen.
c) Das Ding reagierte eine Zeitlang auch auf Fußbälle am Garagentor oder Sturmböen. Ich habe die eventFilterTime auf 4s verlängert. Verbaut ist nämlich kein Neigungssensor wie beim modernen Hm-IP-Pendant, sondern ein schlichter Rüttelkontakt mit Rollkugel.
d) das Ding kann kein lazyKonfig. Man muss bei Registeränderungen das Gehäuse öffnen und den Knopf betätigen.
und auch in diesem Zusammenhang:
e) den Vollidioten, der dieses Gehäuse konstruiert hat (die eQ3 bei allen wetterfesten Geräten einsetzt und das ich leider auch bei meinem "Dirk's" Außensensor benutze), sollte man erschießen und vierteilen. Vier Schrauben wechselseitig zu lösen und festzuschrauben (weil sich eine Schraube prompt festfrisst wenn man sie zu weit dreht) geht mir bei jedem Batteriewechsel (den ich wegen zu billiger Batterien im letzten Jahr 3x durchführen musste) SOWAS VON auf den Wecker. "Isch hab SON'N HALS, hab isch!" :-)
Glücklicherweise hat mein Garagentorantrieb eine eigene Positionserfassung und der TiS hat eher Warnfunktion, etwa weil ein Tor aufgeht, ohne dass der Antrieb benutzt wurde (Notentriegelung, Einbruch). Er schaltet auch die Garagenbeleuchtung aus, die aber aus Sicherheitsgründen eh nur zeitbegrenzt aktiviert wird.
In Summe, lesen sich deine Erfahrungen eher negativ.... Würdest du im Nachhinein nochmal zum TiS greifen, oder eher den sogar günstigeren Fensterkontakt probieren?
Danke euch für die Beiträge!
Meine Empfehlung steht im zweiten Satz meines Statements.
Der SCo hat mit Reflexionsfolie eigentlich eine recht hohe Positionstoleranz.
Zitat von: NewMatic am 17 April 2020, 07:40:23
Ich hab in alten Forenbeiträgen gelesen, dass es mit dem optischen Fensterkontakt oft Sendeprobleme mit dem Metal-Tor gibt... und auch bei kleinster Abweichung, der Kontakt nicht auslöst.... was ja bei einem Garagentor leicht passieren kann (hat ja ein wenig Spiel mit Laufrollen etc.) Hattet ihr diesbzgl. keine Probleme?
Ich habe mir als Reflektor einen Alu-Winkel an den Metallrahmen des Holztors genietet. Das Holz ist mit Heißkleber hingepappt, darauf der Sensor geschraubt. Funktioniert perfekt.
Kleiner Tip:
Perfekte Anzeige dazu ist die mechanische Klappanzeige HM-DIS-TD-T. Da hört man im ganzen Haus, wenn sich das Tor öffnet und schließt.
Genau so. Und die Antenne haste noch herausgeführt.
Wenn ich für den TiS noch eine bessere Verwendung hätte, wäre inzwischen auch ein SCo am Werk. Ich habe zwar noch zwei Kanäle auf einem dauerstromversorgten 8-Kanal-Modul in der Garage übrig, aber ich mag es, einen zweiten autarken Sender für den Status zu haben, zumal die Garage praktisch frei zugänglich ist.
Danke für die Antworten und besonders das Bild.
Ich werde mich jetzt eher nach einem HM-SEC-SCO umsehen!
Danke!
Zitat von: Pfriemler am 16 April 2020, 23:04:09
Ich nutze den Tis seit Jahren. Und würde ihn nicht wieder kaufen.
a) Der hat Schwierigkeiten, aus der geschlossenen Blechgarage heraus ein HM-IO in nur wenigen Metern Entfernung zu erreichen. transmDevTryMax kann helfen.
b) billige Li-Kekse (CR 2032) sorgen regelmäßig für verfrühte Batteriewarnungen besonders bei Kälte. Normalerweise hält die Batterie weit mehr als ein Jahr bei mehrmals täglichen Bewegungen.
c) Das Ding reagierte eine Zeitlang auch auf Fußbälle am Garagentor oder Sturmböen. Ich habe die eventFilterTime auf 4s verlängert. Verbaut ist nämlich kein Neigungssensor wie beim modernen Hm-IP-Pendant, sondern ein schlichter Rüttelkontakt mit Rollkugel.
d) das Ding kann kein lazyKonfig. Man muss bei Registeränderungen das Gehäuse öffnen und den Knopf betätigen.
und auch in diesem Zusammenhang:
e) den Vollidioten, der dieses Gehäuse konstruiert hat (die eQ3 bei allen wetterfesten Geräten einsetzt und das ich leider auch bei meinem "Dirk's" Außensensor benutze), sollte man erschießen und vierteilen. Vier Schrauben wechselseitig zu lösen und festzuschrauben (weil sich eine Schraube prompt festfrisst wenn man sie zu weit dreht) geht mir bei jedem Batteriewechsel (den ich wegen zu billiger Batterien im letzten Jahr 3x durchführen musste) SOWAS VON auf den Wecker. "Isch hab SON'N HALS, hab isch!" :-)
Glücklicherweise hat mein Garagentorantrieb eine eigene Positionserfassung und der TiS hat eher Warnfunktion, etwa weil ein Tor aufgeht, ohne dass der Antrieb benutzt wurde (Notentriegelung, Einbruch). Er schaltet auch die Garagenbeleuchtung aus, die aber aus Sicherheitsgründen eh nur zeitbegrenzt aktiviert wird.
Zitat von: Pfriemler am 16 April 2020, 23:04:09
Ich nutze den Tis seit Jahren. Und würde ihn nicht wieder kaufen.
a) Der hat Schwierigkeiten, aus der geschlossenen Blechgarage heraus ein HM-IO in nur wenigen Metern Entfernung zu erreichen. transmDevTryMax kann helfen.
b) billige Li-Kekse (CR 2032) sorgen regelmäßig für verfrühte Batteriewarnungen besonders bei Kälte. Normalerweise hält die Batterie weit mehr als ein Jahr bei mehrmals täglichen Bewegungen.
c) Das Ding reagierte eine Zeitlang auch auf Fußbälle am Garagentor oder Sturmböen. Ich habe die eventFilterTime auf 4s verlängert. Verbaut ist nämlich kein Neigungssensor wie beim modernen Hm-IP-Pendant, sondern ein schlichter Rüttelkontakt mit Rollkugel.
d) das Ding kann kein lazyKonfig. Man muss bei Registeränderungen das Gehäuse öffnen und den Knopf betätigen.
und auch in diesem Zusammenhang:
e) den Vollidioten, der dieses Gehäuse konstruiert hat (die eQ3 bei allen wetterfesten Geräten einsetzt und das ich leider auch bei meinem "Dirk's" Außensensor benutze), sollte man erschießen und vierteilen. Vier Schrauben wechselseitig zu lösen und festzuschrauben (weil sich eine Schraube prompt festfrisst wenn man sie zu weit dreht) geht mir bei jedem Batteriewechsel (den ich wegen zu billiger Batterien im letzten Jahr 3x durchführen musste) SOWAS VON auf den Wecker. "Isch hab SON'N HALS, hab isch!" :-)
Glücklicherweise hat mein Garagentorantrieb eine eigene Positionserfassung und der TiS hat eher Warnfunktion, etwa weil ein Tor aufgeht, ohne dass der Antrieb benutzt wurde (Notentriegelung, Einbruch). Er schaltet auch die Garagenbeleuchtung aus, die aber aus Sicherheitsgründen eh nur zeitbegrenzt aktiviert wird.
Weiß jemand, wie man beim Fensterkontakt den Wert für transmDevTryMax auslesen und setzen kann?
Geht beim SCo genauso wie bei jedem HM-Gerät: getConfig und regSet.
Danke für die Info.
getConfig gibt es bei mir im popup bei get nicht. Daher habe ich keine Info, welcher Wert im Register steht.
Eingabe mit set regSet transDevTryMax 5 wird ohne Fehlermeldung akzeptiert, aber ob der Wert gesetzt wird, kann ich nicht kontrollieren.
Mein device sieht so aus:
Internals:
CHANGED
CUL868T_MSGCNT 88
CUL868T_RAWMSG A0DC386106B5CAD0000000601C800::-71:CUL868T
CUL868T_RSSI -71
CUL868T_TIME 2020-07-23 10:50:35
DEF 6B5CAD
FUUID 5e6ff4f4-f33f-f21b-3208-b2957f3d4ffdcde8
IODev CUL868T
LASTInputDev CUL868T
MSGCNT 88
NAME HM_6B5CAD
NOTIFYDEV global
NR 241
NTFY_ORDER 50-HM_6B5CAD
STATE open
TYPE CUL_HM
chanNo 01
lastMsg No:C3 - t:10 s:6B5CAD d:000000 0601C800
protCmdPend 3 CMDs_pending
protLastRcv 2020-07-23 10:50:35
protRcv 88 last_at:2020-07-23 10:50:35
protState CMDs_pending
rssi_at_CUL868T cnt:88 min:-78.5 max:-65.5 avg:-70.55 lst:-71
READINGS:
2020-07-20 01:18:26 Activity alive
2020-03-16 02:27:12 D-firmware 1.0
2020-03-16 02:27:12 D-serialNr PEQ2233556
2020-03-17 21:22:15 R-cyclicInfoMsg set_on
2020-07-23 10:50:35 alive yes
2020-07-23 10:50:35 battery ok
2020-07-23 10:50:35 contact open (to broadcast)
2020-06-07 21:01:56 powerOn 2020-06-07 21:01:56
2020-07-23 10:50:35 recentStateType info
2020-07-23 10:50:35 sabotageError off
2020-07-23 10:50:35 state open
2020-07-21 16:02:52 trigDst_broadcast noConfig
2020-07-21 16:02:52 trigger_cnt 213
cmdStack:
++A001F100006B5CAD00050000000000
++A001F100006B5CAD00081405
++A001F100006B5CAD0006
helper:
HM_CMDNR 195
mId 00C7
peerFriend peerAct,peerVirt
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +6B5CAD,02,00,00
nextSend 1595494235.56241
prefIO
rxt 2
vccu
p:
6B5CAD
00
00
00
mRssi:
mNo C3
io:
CUL868T:
-69
-69
prt:
bErr 0
sProc 2
sleeping 1
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
rssi:
at_CUL868T:
avg -70.5511363636364
cnt 88
lst -71
max -65.5
min -78.5
shadowReg:
RegL_00. 14:05
Attributes:
actCycle 002:50
actStatus alive
alias FK_SchlZi (HM_6B5CAD)
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
group Fensterkontakte
icon fts_window_1wbb_open
model HM-SEC-SCO
room Alarm,CUL_HM,HM_devices,Heizung,Schalter
serialNr PEQ2233556
subType threeStateSensor
mfg
Zitat von: McShire am 23 Juli 2020, 11:46:05
getConfig gibt es bei mir im popup bei get nicht.
Nö. Geht bei keinem von uns. Steht aber schon immer im Popup für set.
Unter get finden sich alle Aktionen, die FHEM aus eigenen Infos berechnen kann.
"getConfig" ist aber ein aktiver Befehl an das Gerät zu Abfrage der geräteinternen Einstellungen. Deswegen ist die Einordnung bei "set" schon durchaus sinnvoll.
Nachtrag:
protCmdPend 3 CMDs_pendingDa der Sensor so "doof" ist und m.W. nicht einmal lazyConfig unterstützt, ... mann, wir reden ja vom SCo. Aber trotzdem solltest Du alle set-Befehl (am besten einzeln) beim Sensor mit Tastendruck bestätigen.
Bis dahin wirst Du niemals "CMDs_done" im Status sehen.
Nachtrag 2: Vor allem solltest Du den Sensor erst einmal pairen:
2020-07-23 10:50:35 contact open (to broadcast)ist ein sicherer Beweis dafür dass das nicht passiert ist.
Vor dem Pairen sicherheitshalber: "set HM_6B5CAD clear msgEvents". Das löscht die im Cache gespeicherten Set-Befehle.
Danke für alle deine Hinweise.
Das habe ich alles nicht gewusst und viel dazugelernt.
In diesr Form steht es auch sonst nigendwo beschrieben,
Ich hatte vorher alle Beiträge die ich gefunden habe, Wiki, Forum, Reference, Google durchsucht,
aber dieses so für Laien verständlich nicht gefunden.
gepaired ist er eigentlich mit dem SelbstbauCUL, er funktioniert jedenfalls, das device wirde mit autocreate erstellt.
Der CUL ist:
Internals:
CMDS ABCEeFfGhiKklMmRTtUVWXxYZz
CUL868T_MSGCNT 843
CUL868T_TIME 2020-07-23 12:36:59
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.2:1.0-port0@38400 0000
DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.2:1.0-port0@38400
FD 9
FHTID 0000
FUUID 5e6ab559-f33f-f21b-d127-0fc9ec736e579e2a
NAME CUL868T
NR 119
NR_CMD_LAST_H 13
PARTIAL
RAWMSG A0D2386106B5E1A000000060100001A
RSSI -61
STATE Initialized
TYPE CUL
VERSION V 1.67 nanoCUL868
initString X21
Ar
MatchList:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2020-04-13 19:48:06 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2020-07-20 01:18:17 cmds A B C E e F f G h i K k l M m R T t U V W X x Y Z z
2020-03-17 06:41:30 raw 6
2020-07-23 12:36:59 state Initialized
2020-03-16 22:53:47 version No answer
XMIT_TIME:
1595499475.23019
1595499475.66513
1595499475.66779
1595500060.9261
1595500061.19986
1595500061.29653
1595500061.49708
1595500061.5955
1595500061.81618
1595500061.91212
1595500062.12618
1595500062.223
1595500062.42253
helper:
6B9B51:
QUEUE:
Attributes:
group rf_Transceiver
icon cul_868
rfmode HomeMatic
room CUL_HM,CUL_alle,Heizung,Schalter,Steckdosen
verbose 5
Muss ich zum Pairen noch etwas machen?
mfg
Welches ist denn wohl der empfohlene Wert für transDevTryMax?
Selten, aber doch manchmal werden die Änderungen der Kontakte nicht oder erst nach langer Zeit richtig erfasst.
Daher die Idee den Wert für transDevTryMax zu setzen.
mfg
Definiere "funktionieren".
Homematic-Geräte senden Informationen zu ihrem geänderten Status immer. Wenn sie nicht an eine Zentrale gebunden sind, gehen die Meldungen "broadcast", also ungerichtet (real ist es die hmId 000000).
Geräte, die in Betrieb genommen werden (u.a. Anlernmodus), senden eine Info-Msg mit Informationen, die FHEM einseitig nutzt um ein Gerät per autocreate anzulegen. Die Nachrichten dieses Gerätes werden dann dort angezeigt. Das ist noch kein Pairen.
Erst das Pairen bindet das Gerät an eine Zentrale. Erst nach dem Pairen akzeptiert das Gerät Befehle und Konfigurationdaten von dieser Zentrale.
Einen empfohlenen Wert für transmDevTryMax gibt es nicht. Meine SCo arbeiten mit 6.
Hier (https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale) wird vom Einsatz von CUL als HM-IO-Device abgeraten:
ZitatErfahrungsgemäß ist der Einsatz originaler HomeMatic IOs empfehlenswert, da es bei allen CUL-Derivaten immer wieder zu Schwierigkeiten kommen kann, vor allem in größeren Installationen und bei der Kommunikation mit komplexeren Geräten. Wer dennoch einen CUL für HomeMatic verwenden will, sollte eine speziell für den Betrieb mit HomeMatic optimierte CUL-firmware (tsculfw - TimeStamp Firmware) verwenden. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING_ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen! Zusätzlich sind unbedingt die Hinweise im Artikel AES_Encryption zu beachten!
Du könntest Dir viel Zeit bei der Fehlersuche ersparen, wenn Du gleich ein "richtiges" HM-Device nutzen würdest. Hier werden gerade "richtige" IO-Devices angeboten:
https://forum.fhem.de/index.php/topic,112948.0.html (https://forum.fhem.de/index.php/topic,112948.0.html)
https://forum.fhem.de/index.php/topic,112631.0.html (https://forum.fhem.de/index.php/topic,112631.0.html)
Oder installiere zumindest die tsculfw.
Danke für alle Eure Infos. Werde sie beherzigen.
Habe meinen Fehler gefunden.
Auch bei mehrfacher Kontrolle habe ich immer wieder drüberweg gelesen:
Habe immer das m vergessen. Es heißt transmDevTryMax und nicht transDevTryMax.
Das hatte ich nur beim set richtig geschrieben und daher keine Fehlermeldung erhalten.
Jetzt funktioniert alles, habe 9 Fensterkontakte von ELV im Einsatz.
Viel dazugelernt.
mfg
Habe jetzt alle gepairt, nun steht nicht mehr (to broadcast) sondern (to CUL868T) in den Readings.
Nun kann ich mich dem nächsten Thema widmen. Danke für die Unterstützung.
mfg