Hallo zusammen,
gestern ist mir aufgefallen, dass angeblich unsere Haustür geöffnet ist.
Ich überwache diese mit einem HM-SEC-SC-2 Fensterkontakt.
Da FHEM bei battery ein low angezeigt hat, habe ich die Batterien gewechselt.
Das hat aber leider nichts gebracht.
Das System verhält sich wie folgt:
- Türe wird geöffnet
- LED des HM-SEC-SC-2 leuchtet orange (etwas unregelmäßig)
- nach mehreren Sekunden leuchtet die LED dann Rot.
Soweit ich das verstehe, hat der Sensor keine Bestätigung vom CUN bekommen, wenn die LED rot statt grün leuchtet.
Durch die lange Dauer der organgenen LED ist die Türe u.U. schon wieder zu, sodass kein closed an die Zentrale geschickt werden kann und die Tür den Status open behält.
Ich habe diese Sensoren auch an Fenstern verbaut und dort verhalten diese sich ähnlich, nur dass da schon das open nicht angezeigt wird.
Den CUN (CUNx von busware), der per Ethernet mit FHEM verbunden ist, habe ich schon stromlos gemacht. Das hat aber auch nichts gebracht.
Was muss ich tun, damit der Handshake zwischen dem CUN und den Sensoren wieder funktioniert?
Gruß
Markus
zeig erst einmal ein list vom sc2.
"Dieses Verhalten" habe ich vor Kurzem auch bei einem Drehgriffkontakt beobachtet.
Bei der nächsten Betätigung war dann wieder alles korrekt.
Alle anderen funktionieren noch immer problemlos.
Ich meine mich zu erinnern, dass ich schon mal über ähnliche Probleme mit diesen Sensoren nach einigen Jahren Betrieb gelesen habe...
Vielleicht wird das Transceiver-Modul schlechter. :-\
Kann natürlich auch an irgendwelchen anderen Störungen im Übertragungsweg liegen.
Es kann also auch sein, dass es nicht zwingend mit dem CUN zusammenhängt (ich habe HMLAN im Einsatz).
Zitat von: frank am 09 Juli 2019, 09:17:10
zeig erst einmal ein list vom sc2.
Anbei das list:
Internals:
CUN1_MSGCNT 6
CUN1_RAWMSG A0C0FA2414D29E3A1B2C3010FC8::-53.5:CUN1
CUN1_RSSI -53.5
CUN1_TIME 2019-07-09 06:56:58
DEF 4D29E3
FUUID 5c5a9078-f33f-939b-6ee1-713fb3f2ed817ae4
IODev CUN1
LASTInputDev CUN1
MSGCNT 6
NAME EingangsTuer
NOTIFYDEV global
NR 229
NTFY_ORDER 50-EingangsTuer
STATE open
TYPE CUL_HM
chanNo 01
lastMsg No:0F - t:41 s:4D29E3 d:A1B2C3 010FC8
protLastRcv 2019-07-09 06:56:58
protRcv 3 last_at:2019-07-09 06:56:58
protSnd 12 last_at:2019-07-09 06:56:58
protState CMDs_done
rssi_at_CUN1 cnt:6 min:-56 max:-53 avg:-53.91 lst:-53.5
READINGS:
2019-07-08 19:07:43 Activity alive
2016-11-27 17:50:03 CommandAccepted yes
2016-11-27 17:50:03 D-firmware 2.4
2016-11-27 17:50:03 D-serialNr NEQ0758042
2016-11-27 17:48:59 R-cyclicInfoMsg set_on
2016-11-27 17:43:59 R-pairCentral set_0xA1B2C3
2019-05-12 10:07:32 alive yes
2019-07-09 06:56:58 battery ok
2019-07-09 06:56:58 contact open (to VCCU)
2018-06-13 18:53:28 powerOn 2018-06-13 18:53:28
2019-05-12 10:07:32 recentStateType info
2019-05-12 10:07:32 sabotageError on
2019-07-09 06:56:58 state open
2019-07-09 06:56:58 trigger_cnt 15
helper:
HM_CMDNR 15
mId 002F
peerFriend peerAct,peerVirt
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 4
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +4D29E3,00,00,00
nextSend 1562648218.91785
rxt 0
vccu VCCU
p:
4D29E3
00
00
00
prefIO:
CUN1
mRssi:
mNo 0F
io:
CUN1:
-47.5
-47.5
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
rpt:
IO CUN1
flg A
ts 1562648218.81825
ack:
HASH(0x6b124e8)
0F8002A1B2C34D29E300
HASH(0x6b124e8)
0F8002A1B2C34D29E30101C800
rssi:
at_CUN1:
avg -53.9166666666667
cnt 6
lst -53.5
max -53
min -56
tmpl:
Attributes:
IODev CUN1
IOgrp VCCU:CUN1
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
devStateIcon closed:fts_door_right@green open.*:fts_door_right_open@red
expert 2_raw
firmware 2.4
group Türen
model HM-SEC-SC-2
room CUL_HM,Eingang,TürenFenster
serialNr NEQ0758042
subType ThreeStateSensor
Zitat von: Hollo am 09 Juli 2019, 09:47:32
"Vielleicht wird das Transceiver-Modul schlechter. :-\
Das wäre natürlich der GAU, wenn man nach 3 Jahren Betrieb die kompletten Sensoren austauschen müsste :(
kürzliche kommunikationsprobleme kann ich nicht erkennen.
es gibt aber einige konfigurations merkwürdigkeiten.
hast du das device selbst angelegt, oder automatisch über autocreate?
"get hminfo models -f SEC-SC" zeigt bei mir
models filtered:SEC-SC
subType name ID supportedMode Info List channels
threeStateSensor HM-SEC-SC 002F config 28:00 1,4
threeStateSensor HM-SEC-SC-2 00B1 config 28:00 1,4
threeStateSensor HM-SEC-SCo 00C7 config,wakeup,lazyConf 02:50 1,4
was zeigt hminfo bei dir an?
mid im list zeigt 002F. das ist aber ein sc und kein sc2. also passt attr model nicht.
ausserdem ist das attr subType falsch geschrieben. es müsste "threeStateSensor" heissen.
auch sollte ein ungepeertes device attr peerIDs=00000000 anzeigen.
zusätzlich fehlen fhem einige infos, da einige readings "set_........" anzeigen.
wenn du gerade die batterie gewechselt hast, passt auch powerOn nicht.
angeblich ist seit einem monat das gehäuse offen => sabotageError=on.
wenn deine hminfo models ausgabe mit meiner identisch ist, würde ich folgendes versuchen:
1. attr model und subType anpassen
2. attr expert=251_anything setzen
3. set getConfig auslösen
4. den taster am device kurz drücken, eventuell wiederholen bis cmds_done erreicht ist.
5. ein frisches, erfolgreiches list posten.
Zitat von: MarkusAutomaticus am 09 Juli 2019, 10:05:20
2016-11-27 17:43:59 R-pairCentral set_0xA1B2C3
na was sagt uns das set_ ? und wo ist das Reading PairedTo ....
Zitat von: Wzut am 09 Juli 2019, 11:56:37
na was sagt uns das set_ ? und wo ist das Reading PairedTo ....
Keine Ahnung.
Dass das Pairing futsch ist und man den Sensor neu pairen müsste?
Gruß
Markus
Zitat von: frank am 09 Juli 2019, 11:31:27
kürzliche kommunikationsprobleme kann ich nicht erkennen.
[...]
Vielen Dank für die ausführliche Analyse!
Das schau ich mir in Ruhe an, wenn ich wieder zuhause bin.
Gruß
Markus
Zitat von: Wzut am 09 Juli 2019, 11:56:37
na was sagt uns das set_ ? und wo ist das Reading PairedTo ....
Zitat von: frank am 09 Juli 2019, 11:31:27
zusätzlich fehlen fhem einige infos, da einige readings "set_........" anzeigen.
das pairing ist aber noch da, denn:
2019-07-09 06:56:58 contact open (to VCCU)
Zitat von: frank am 09 Juli 2019, 11:31:27
"get hminfo models -f SEC-SC" zeigt bei mir
bringt bei mir:
subType name ID supportedMode Info List channels
threeStateSensor HM-SEC-SC 002F config 28:00 1,4
threeStateSensor HM-SEC-SC-2 00B1 config 28:00 1,4
threeStateSensor HM-SEC-SCO 00C7 config,wakeup,lazyConf 02:50 1,4
Gruß
Markus
Zitat von: frank am 09 Juli 2019, 11:31:27
wenn deine hminfo models ausgabe mit meiner identisch ist, würde ich folgendes versuchen:
1. attr model und subType anpassen
2. attr expert=251_anything setzen
3. set getConfig auslösen
4. den taster am device kurz drücken, eventuell wiederholen bis cmds_done erreicht ist.
5. ein frisches, erfolgreiches list posten.
Der Taster ist das Teil, was man mit einem Pin in dem Loch betätigen muss, oder?
Hier bringt das Drücken nichts, es stauen sich immer mehr CMDs an.
Aktuelle list:
Internals:
DEF 4D29E3
FUUID 5c5a9078-f33f-939b-6ee1-713fb3f2ed817ae4
IODev CUN1
NAME EingangsTuer
NOTIFYDEV global
NR 229
NTFY_ORDER 50-EingangsTuer
STATE open
TYPE CUL_HM
chanNo 01
protCmdPend 10 CMDs_pending
protState CMDs_pending
READINGS:
2019-07-09 18:50:45 Activity alive
2016-11-27 17:50:03 CommandAccepted yes
2016-11-27 17:50:03 D-firmware 2.4
2016-11-27 17:50:03 D-serialNr NEQ0758042
2016-11-27 17:48:59 R-cyclicInfoMsg set_on
2016-11-27 17:43:59 R-pairCentral set_0xA1B2C3
2019-05-12 10:07:32 alive yes
2019-07-09 16:42:42 battery ok
2019-07-09 16:42:42 contact open (to VCCU)
2018-06-13 18:53:28 powerOn 2018-06-13 18:53:28
2019-05-12 10:07:32 recentStateType info
2019-05-12 10:07:32 sabotageError on
2019-07-09 16:42:42 state open
2019-07-09 16:42:42 trigger_cnt 21
cmdStack:
++A001A1B2C34D29E300040000000000
++A001A1B2C34D29E301040000000001
++A001A1B2C34D29E30103
++A001A1B2C34D29E300040000000000
++A001A1B2C34D29E301040000000001
++A001A1B2C34D29E30103
++A001A1B2C34D29E300040000000000
++A001A1B2C34D29E301040000000001
++A001A1B2C34D29E30103
++8401A1B2C3000000010A4E455130373538303432
helper:
HM_CMDNR 13
getCfgList all
getCfgListNo ,4
mId 002F
peerFriend peerAct,peerVirt
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 4
expert:
def 1
det 1
raw 1
tpl 1
io:
newChn +4D29E3,00,00,00
rxt 0
vccu VCCU
p:
4D29E3
00
00
00
prefIO:
CUN1
mRssi:
mNo
prt:
bErr 0
sProc 2
q:
qReqConf
qReqStat
role:
chn 1
dev 1
tmpl:
Attributes:
IODev CUN1
IOgrp VCCU:CUN1
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
devStateIcon closed:fts_door_right@green open.*:fts_door_right_open@red
expert 251_anything
firmware 2.4
group Türen
model HM-SEC-SC-2
room CUL_HM,Eingang,TürenFenster
serialNr NEQ0758042
subType threeStateSensor
ich würde mal sniffen. also verbose=4 beim cun und in fhem.log nach den messages schauen, wenn man getconfig versucht.
leuchtet die led beim kurzen drücken? immer?
was ist mit den restlichen fragen?
zur not mal werkreset probieren, siehe BA. anschliessend natürlich neu pairen.
Ich würde die VCCU in den pairing Mode bringen und dann den Pairing Taster noch mal drücken. So mache ich das immer.
Zitat von: CoolTux am 10 Juli 2019, 08:39:39
Ich würde die VCCU in den pairing Mode bringen und dann den Pairing Taster noch mal drücken. So mache ich das immer.
Hat man danach dann nicht ein neues Device für das mal alles (Notifies, plots, etc) neu machen muss?
Gruß
Markus
das/die fhem devices nicht löschen, also "drüber" pairen.
dann ändert sich in fhem nichts.
Nein hat man nicht, da das Device ja schon da ist.
Aktueller Stand:
Der Sensor und auch ein anderer HM Sensor lassen sich nicht pairen.
Ich habe den CUN1 in den pairforsec 30 Modus versetzt und an den Sensoren mit einem spitzen Gegenstand den Pairing Modus herbei geführt.
Dabei hat die LED mehrfach orange geblinkt, um dann schließlich rot zu werden.
Ein dritter Sensor hat zwischendurch mal funktiert (LED = grün), um kurz darauf auch wieder nicht zu tun.
Ich habe den Eindruck, dass FHEM bzw. der CUN einfach zu langsam arbeitet, um den handshake rechtzeitig abzuschließen.
Die Prozessorauslastung auf meinem NUC dümpelt dabei im einstelligen Prozentbereich.
Es ist irgendwie sehr ärgerlich, wenn plötzlich und unerwartet etwas Probleme macht, was man längst als funktionierend abgehakt hat.
Da will kein Gefühl von Zuverlässigkeit aufkommen, wie man es sich zum Absichern von Türen und Fenstern ja gerade wünscht.
Gruß
Markus
CUN1 an einem NUK. Ohne genau zu wissen was das ist klingt das alles doch sehr nach Basteln in meinen Augen. Warum kein Pi mit entsprechenden Aufsatz von Hersteller dessen Endgeräte Du verwendest?
Zitat von: CoolTux am 12 Juli 2019, 09:35:59
CUN1 an einem NUK. Ohne genau zu wissen was das ist klingt das alles doch sehr nach Basteln in meinen Augen. Warum kein Pi mit entsprechenden Aufsatz von Hersteller dessen Endgeräte Du verwendest?
Ein NUC ist ein Mini-PC von Intel, den man nur noch mit RAM und einer SSD austatten muss.
Er hat Gigagbit Ethernet, USB3 und PCI Express, sowie eine SATA Festplattenanbindung.
Von der Intel Core-i CPU ganz zu schweigen.
Das ist eine solide Hardware und von einer Bastelei weit entfernt.
Für mich fällt eher ein Raspi in den Bereich der Bastelei.
Der CUNx stammt von busware.de und ist per Ethernet mit dem NUC, auf dem Fhem läuft, verbunden.
Das alles hat bis vor Kurzem anstandslos funktioniert.
Außer dass ich Fhem und das Ubuntu regelmäßig per Updates auf dem Laufenden halte, habe ich nichts gemacht
und jetzt stehe ich kurz davor, den ganzen HomeMatic Teil über Bord zu werfen, was das Hobby unnötig verteuert.
Da wird man sich doch wohl mal ein wenig ärgern dürfen ;-)
Gruß
Markus
Ich hatte mal ein Gespräch mit jemanden bei dem auf einer Seite die HM Komponenten ausgefallen sind. Am Ende kam raus das von einem Gerät ohne Meldung die Batterie leer war. Das gab eine Funkstörung weil das Teil wohl leise vor sich hin wimmerte die ganze Zeit.
Moin
Und immer wieder der gern gegebene Hinweis CUL/CUN sind nicht die IO-devs der Wahl!
Gerade die Fensterkontakte machen gerne Probleme!
Gruss Christoph
poste doch mal die rawmessages, wie im wiki sniffen beschrieben, damit man das problem genau erkennt.
Zitat von: CoolTux am 10 Juli 2019, 08:39:39
Ich würde die VCCU in den pairing Mode bringen und dann den Pairing Taster noch mal drücken. So mache ich das immer.
Zitat von: MarkusAutomaticus
Ich habe den CUN1 in den pairforsec 30 Modus versetzt und an den Sensoren mit einem spitzen Gegenstand den Pairing Modus herbei geführt.
Wenn du eine VCCU hast, musst du die in den Pairing- Mode versetzen.
Als Funk- Interface für HM empfehle ich dir dieses Modul (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi) in Verbindung mit einem USB- Adapter. Bei mir macht sich dieser (https://www.amazon.de/gp/product/B078W5L8W1/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1) ganz gut: Er liefert genaue 3,3V und man kann das Sendemodul ohne die Unterplatine direkt drauflöten. Die Spannungs- Pins passen 1:1 und RX/TX werden mit kurzen drähten verbunden (keine Widerstände einbauen!). Das Ganze passt dann sogar in das Gehäuse eines defekten HM-USB-CFG-2.
Gruß
Frank