Hallo in die Runde,
ich habe ein Problm mit einem HM-SEC-SC-2. Anlernen funktioniert ohne Probleme und nach einem getconfig läuft alles tutti. Doch nach ein paar mal betätigen (ca. 15-20 mal), oder aber bei nichtbetätigen nach ca. 20-30 Min. quittiert der FK nicht mehr mit Grün sondern die LED leuchtet lange Orange um am Ende mit Rot zu quittieren.
Der FK ist gepaired via VCCU mit einem HMLAN (Ver. 0965) und gepeered mit einem HM Schaltaktor. Der gepeerte Schaltaktor funktioniert auch einwandfrei, auch wenn der FK mit Rot quittiert schaltet der Aktor trotzdem.
set EgSenFkHmKuecheWest peerChan 0 EgAktHmKuecheAbzug single set
set EgAktHmKuecheAbzug regSet shCtOn ltLo EgSenFkHmKuecheWest
Ein list ergibt
Internals:
DEF 30D946
HMLAN1_MSGCNT 789
HMLAN1_RAWMSG E30D946,0000,255FA72A,FF,FFB6,1FA04130D94627AB2E010AC8
HMLAN1_RSSI -74
HMLAN1_TIME 2018-06-10 08:49:50
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 789
NAME EgSenFkHmKuecheWest
NOTIFYDEV global
NR 226
NTFY_ORDER 50-EgSenFkHmKuecheWest
STATE open
TYPE CUL_HM
lastMsg No:1F - t:41 s:30D946 d:27AB2E 010AC8
peerList 27AB2E01,EgAktHmKuecheAbzug,
protLastRcv 2018-06-10 08:49:50
protResnd 10 last_at:2018-06-09 17:29:06
protSnd 193 last_at:2018-06-10 08:49:44
protState CMDs_done
rssi_at_HMLAN1 avg:-72.07 min:-99 max:-60 lst:-74 cnt:789
Helper:
DBLOG:
contact:
myDbLog:
TIME 1528613385.24668
VALUE open (to 27AB2E)
READINGS:
2018-06-09 17:23:51 Activity alive
2018-02-07 21:04:52 Batteriewechsel01 1
2018-06-10 11:33:24 Batteriewechsel02 1
2018-02-25 17:46:40 CommandAccepted no
2018-06-09 17:23:51 D-firmware 2.4
2018-06-09 17:23:51 D-serialNr LEQ1091813
2018-06-09 17:29:10 PairedTo 0x29A1CA
2017-12-28 10:33:22 R-27AB2E01-expectAES off
2017-12-28 10:33:22 R-27AB2E01-peerNeedsBurst off
2018-06-09 17:29:13 R-EgAktHmKuecheAbzug_chn-01-expectAES off
2018-06-09 17:29:13 R-EgAktHmKuecheAbzug_chn-01-peerNeedsBurst off
2018-02-04 13:39:06 R-cyclicInfoMsg on
2017-12-28 10:33:17 R-eventDlyTime 0 s
2017-12-28 10:33:17 R-ledOnTime 0.5 s
2017-12-28 10:33:17 R-msgScPosA closed
2017-12-28 10:33:17 R-msgScPosB open
2018-02-05 19:14:50 R-pairCentral 0x29A1CA
2018-02-04 13:39:06 R-sabotageMsg on
2017-12-28 10:33:17 R-sign off
2018-02-04 13:39:06 R-transmDevTryMax 6
2017-12-28 10:33:17 R-transmitTryMax 6
2018-06-09 17:29:10 RegL_00. 02:01 09:01 0A:29 0B:A1 0C:CA 10:01 14:06 00:00
2018-06-09 17:29:11 RegL_01. 08:00 20:60 21:00 22:64 30:06 00:00
2018-06-09 17:29:12 RegL_04.27AB2E01 01:00 00:00
2018-06-09 17:29:13 RegL_04.EgAktHmKuecheAbzug_chn-01 01:00 00:00
2018-06-09 17:28:47 alive yes
2018-06-10 08:49:45 battery ok
2018-06-10 08:49:45 contact open (to 27AB2E)
2018-06-09 17:29:11 peerList 27AB2E01,EgAktHmKuecheAbzug,
2018-06-09 17:28:42 powerOn 2018-06-09 17:28:42
2018-06-09 17:28:47 recentStateType info
2018-06-09 17:28:47 sabotageError off
2018-06-10 08:49:45 state open
2018-06-10 08:49:45 trigger_cnt 10
helper:
HM_CMDNR 31
PONtest 0
cSnd 0129A1CA30D946010427AB2E0104,0129A1CA30D946010453F8C10104
cfgChkResult No regs found for:
EgSenFkHmKuecheWest type:threeStateSensor -
list:peer register :value
0: cyclicInfoMsg :on
0: pairCentral :0x29A1CA
0: sabotageMsg :on
0: transmDevTryMax :6
1: eventDlyTime :0 s
1: ledOnTime :0.5 s
1: msgScPosA :closed
1: msgScPosB :open
1: sign :off
1: transmitTryMax :6
4:27AB2E01 expectAES :off
4:27AB2E01 peerNeedsBurst :off
4:EgAktHmKuecheAbzug_chn-01 expectAES :off
4:EgAktHmKuecheAbzug_chn-01 peerNeedsBurst :off
mId 00B1
peerIDsRaw ,27AB2E01,53F8C101,00000000
regLst ,0,1,4p
rxType 28
supp_Pair_Rep 0
ack:
expert:
def 1
det 1
raw 1
tpl 1
io:
newCh 1
newChn +30D946,00,00,00
nextSend 1528613390.66562
rxt 2
vccu vccu
p:
30D946
00
00
00
prefIO:
HMLAN1
mRssi:
mNo 1F
io:
HMLAN1:
-72
-72
prt:
bErr 0
sProc 0
sleeping 1
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_HMLAN1:
avg -72.0773130544993
cnt 789
lst -74
max -60
min -99
shadowReg:
tmpl:
nb:
cnt 2
Attributes:
EgFenster stcEgFenster
IODev HMLAN1
IOgrp vccu:HMLAN1
actCycle 028:00
actStatus alive
autoReadReg 5_readMissing
expert 251_anything
firmware 2.4
model HM-SEC-SC-2
peerIDs 00000000,27AB2E01,53F8C101,
room EG_Kueche
serialNr LEQ1091813
subType threeStateSensor
userattr EgFenster EgFenster_map structexclude
Ein reglist zeigt folgendes
list: register | range | peer | description
0: cyclicInfoMsg | literal | | cyclic message options:on_100,on,off
0: pairCentral | 0 to 16777215 | | pairing to central
0: sabotageMsg | literal | | enable sabotage message options:on,off
0: transmDevTryMax | 1 to 10 | | max message re-transmit
1: eventDlyTime | 0 to 7620s | | filters short events, causes reporting delay
1: ledOnTime | 0 to 1.275s | | LED ontime
1: msgScPosA | literal | | Message for position A options:open,closed,noMsg
1: msgScPosB | literal | | Message for position B options:open,closed,noMsg
1: sign | literal | | signature (AES) options:on,off
1: transmitTryMax | 1 to 10 | | max message re-transmit
4: expectAES | literal | required | expect AES options:on,off
4: peerNeedsBurst | literal | required | peer expects burst options:on,off
Und ein regtable ergibt
No regs found for:
EgSenFkHmKuecheWest type:threeStateSensor -
list:peer register :value
0: cyclicInfoMsg :on
0: pairCentral :0x29A1CA
0: sabotageMsg :on
0: transmDevTryMax :6
Was mir noch aufgefallen ist, wenn der FK mit Rot quittiert dann bringt ein regtable keine Ausgabe. Es scheint als wenn der FK dann nicht antwortet.
Wäre dankbar wenn jemand eine Idee hätte, wie ich das Problem lösen könnte.
Danke und Grüße
Fritz
Blick in die Anleitung sagt folgendes
Orangees leuchten : Daten werden übertragen
Danach rot: Mdt 1 Aktor hat keine Rückmeldung übergeben
Danach grün: alle Übertragungen I.O.
Was hast du denn alles zu dem Sensor verbunden
Nur fhem oder auch direkt Aktoren
Wenn er rot leuchtet, hat der Aktor der direkt verbunden ist, AUCH Richtig geschalten?
Ist der Sensor manchmal UNREACHABLE in FHEM?
EDIT:
Habs Grad gelesen:
Der Aktor schaltet dann auch, damit stellt sich nur die Frage ob in dem Moment dann auch das Signal an FHEM kommt...
Was aber dann anscheinend ja nicht der Fall ist
Somit Fehler gefunden
Aus irgendeinem Grund hast du Verbindungsprobleme
Gesendet von meinem ONEPLUS A5000 mit Tapatalk
Danke für den Hinweis,
Zitat von: Sebigamer4 am 11 Juni 2018, 10:50:26
Was hast du denn alles zu dem Sensor verbunden
Nur fhem oder auch direkt Aktoren
Mit HMLAN via VCCu gepairt und mit einem HM-LC-Sw1-FM gepeert
Zitat von: Sebigamer4 am 11 Juni 2018, 10:50:26
Wenn er rot leuchtet, hat der Aktor der direkt verbunden ist, AUCH Richtig geschalten?
Ja, der Atkor schaltet immer korrekt, auch wenn der FK mit rot quittiert.
Zitat von: Sebigamer4 am 11 Juni 2018, 10:50:26
Ist der Sensor manchmal UNREACHABLE in FHEM?
Nein, der Sensor ist nicht unreachable.
Grüße Fritz
Hi,
mir fallen drei Dinge auf:
ZitatDer FK ist gepaired via VCCU mit einem HMLAN (Ver. 0965) und gepeered mit einem HM Schaltaktor. Der gepeerte Schaltaktor funktioniert auch einwandfrei, auch wenn der FK mit Rot quittiert schaltet der Aktor trotzdem.
Es sind aber zwei Peers
ZitatpeerIDs 00000000,27AB2E01,53F8C101,
Und Wiederholungen und die RSSI Werte sind manchmal offenbar sehr gering (kleiner als -80):
ZitatprotResnd 10 last_at:2018-06-09 17:29:06
...
rssi_at_HMLAN1 avg:-72.07 min:-99 max:-60 lst:-74 cnt:789
Du könntest mal die RSSI Werte loggen und schauen ob es Situationen gibt wo diese einbrechen.
Wenn alles immer sauber schaltet, kann es eben wie schon vermutet sein, dass nur die Quittung nicht ankommt.
Gruß Otto
Zitat von: Otto123 am 11 Juni 2018, 11:01:46
Es sind aber zwei Peers
Zitat
peerIDs 00000000,27AB2E01,53F8C101,
Danke, das werde ich mal checken.
Zitat von: Otto123 am 11 Juni 2018, 11:01:46
Und Wiederholungen und die RSSI Werte sind manchmal offenbar sehr gering (kleiner als -80):
Funkproblem würde ich erst einmal ausschließen. Sonst müsste es ja mal funktionieren und mal nicht. Aber wenn der FK ersteinaml soweit ist und nur mit rot quittiert kommt er da auch nicht mehr raus. Der FK quittiert dann immmer mit rot. Erst nach einem getconfig quittiert der FK dann wieder für eine gewisse Zeit mit grün.
Grüße Fritz
Hallo Fritz,
das hatte ich nicht so verstanden und kann es nicht so richtig deuten. Keine spezielle Idee dazu.
Um den Peer zu finden:
list TYPE=CUL_HM:FILTER=DEF=27AB2E01|53F8C101
Gruß Otto
Schau mal, ob im Fehlerfall "CMDs_pending" im Fensterkontakt stehen. Ich würde vermuten, dass FHEM versucht, dem Kontakt was mitzuteilen, und da immer irgendwas dazwischenhagelt und der Datenverkehr daher mit rot abgeschlossen wird.
Falls, dann setze mal statt getConfig ein "set EgSenFkHmKuecheWest clear msgEvents" und schaue, ob danach wieder grün wird.
Nachtrag: Sehe gerade
autoReadReg 5_readMissing
Wann auch immer FHEM der Meinung sein sollte, dass da was vermisst wird, wird es die Readings vom Kontakt anfordern. Der SC-2 unterstützt zwar lazyConfig, aber wenn die Verbindung lausig ist, kann das Zusammenspiel mit dem gepeerten Aktor im Kontaktfall was verhageln, was ohne den Aktor, nur mit FHEM, per getConfig dann funktioniert.
Eigentlich könntest Du auch auf 0_off stellen und nur bei Bedarf manuell anfordern.
Hallo Otto123, hallo Pfriemler.
Dank Eurer Unterstützung konnte ich das Problem lösen. Zum einen habe ich das überflüssige peering gelöscht und zum Zweiten habe ich das Attribut autoReadReg von 5_readMissing auf 0_off gestellt. Nun quittiert der FK dauerhaft mit grün.
Ob nun am Ende das peering oder aber das Attribut autoReadReg 5_readMissing das Problem waren habe ich nicht mehr nachgeforscht. Ich tippe aber mal auf das Attribut autoReadReg . Aber sei es drum, Hauptsache das Problem ist behoben.
Nochmal Danke und bis zum nächsten Problem ;-)
Grüße Fritz