Ich habe einen nagelneuen HM-LC-SW1-BA-PCB (Schaltaktor für Batteriebetrieb), Firmware 1.7, ordentlich gepaired und gepeered. Leider taucht das Problem auf, dass der sich nach einer (noch) nicht genau bestimmten Zeit verabschiedet: Alle Kommandos werden dann ignoriert, MISSING ACK
Nach derzeitiger Beobachtung ist dies nach ein paar Stunden der Fall, kann aber auch kürzer sein.
Drückt man in diesem Fall die Anlerntaste für 3 Sekunden, meldet er sich wieder bei der HMCCU - bis er nach einiger Zeit wieder abstirbt.
Dieses Verhalten ist reproduzierbar, und neu: Mit einem entsprechenden Gerät unter FW Version 1.6 trat das im jahrelangen Betrieb nicht auf.
Hat jemand eine Idee, woran das liegen kann ?
LG
pah
Hier das Listing
Internals:
CFGFN
DEF 66C09C
HMCFG_MSGCNT 393
HMCFG_RAWMSG R5605DBBD,0021,02ADA021,01,FFCD,AD800266C09C0000410101C880374D76E6B4
HMCFG_RSSI -51
HMCFG_TIME 2018-08-20 08:29:09
HMLAN_MSGCNT 332
HMLAN_RAWMSG E66C09C,0000,02AB8EDA,FF,FFC2,AD800266C09C0000410101C880374D76E6B4
HMLAN_RSSI -62
HMLAN_TIME 2018-08-20 08:29:09
IODev HMCFG
LASTInputDev HMCFG
MSGCNT 725
NAME A.Hof.Tuer.A
NOTIFYDEV global
NR 26807
STATE unlocked
TYPE CUL_HM
lastMsg No:AD - t:02 s:66C09C d:000041 0101C880374D76E6B4
peerList A.Hof.Tuer.Btn,
protCmdDel 110
protCondBurst unknown
protEvt_AESCom-ok 91 last_at:2018-08-20 08:29:09
protIOdly 6 last_at:2018-08-19 22:50:49
protIOerr 5 last_at:2018-08-19 22:51:49
protLastRcv 2018-08-20 08:29:09
protResnd 48 last_at:2018-08-20 06:30:23
protResndFail 46 last_at:2018-08-20 06:30:27
protSnd 375 last_at:2018-08-20 08:29:09
protState CMDs_done
rssi_HMCFG cnt:79 min:-68 max:-52 avg:-55.4 lst:-55
rssi_HMLAN cnt:40 min:-67 max:-54 avg:-63.1 lst:-63
rssi_at_HMCFG cnt:312 min:-72 max:-46 avg:-54.45 lst:-51
rssi_at_HMLAN cnt:311 min:-79 max:-56 avg:-61.99 lst:-62
READINGS:
2018-08-19 22:44:06 Activity alive
2018-08-20 08:29:09 CommandAccepted yes
2018-08-20 08:26:47 D-firmware 1.7
2018-08-20 08:26:47 D-serialNr OEQ2624669
2018-08-20 08:28:50 PairedTo 0x000041
2018-08-18 10:12:47 R-A.Hof.Tuer.Btn-lgActionType jmpToTarget
2018-08-18 10:12:47 R-A.Hof.Tuer.Btn-shActionType jmpToTarget
2018-08-20 08:26:52 R-pairCentral 0x000041
2018-08-19 10:41:07 R-sign on
2018-08-20 08:28:50 RegL_00. 02:01 05:00 0A:00 0B:00 0C:41 12:69 00:00
2018-08-20 08:28:50 RegL_01. 08:01 00:00
2018-08-20 08:28:52 RegL_03.A.Hof.Tuer.Btn 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63 00:00
2018-08-20 08:29:09 aesCommToDev ok
2018-08-20 08:29:09 aesKeyNbr 02
2018-08-20 08:29:09 battery low
2018-08-20 08:29:09 deviceMsg on (to HMCCU)
2018-08-20 08:29:09 level 100
2018-08-20 08:29:09 pct 100
2018-08-20 08:28:51 peerList A.Hof.Tuer.Btn,
2018-08-18 09:37:00 powerOn 2018-08-18 09:37:00
2018-08-20 08:29:09 recentStateType ack
2018-08-20 08:29:09 state on
2018-08-20 08:29:09 timedOn off
2018-08-18 10:16:42 trigLast A.Hof.Tuer.Btn:long
2018-08-18 10:16:42 trig_A.Hof.Tuer.Btn Long_2
helper:
HM_CMDNR 173
PONtest 0
cSnd 1100004166C09C0201C80000,1100004166C09C0201C80000
dlvlCmd ++A01100004166C09C0201C80000
mId 006C
peerIDsRaw ,00004101,00000000
regLst ,0,1,3p
rxType 2
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +66C09C,00,01,00
nextSend 1534746549.50286
prefIO
rxt 0
vccu HMCCU
p:
66C09C
00
01
00
mRssi:
mNo AD
io:
HMCFG:
-45
-45
HMLAN:
-62
-62
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
rssi:
HMCFG:
avg -55.4050632911392
cnt 79
lst -55
max -52
min -68
HMLAN:
avg -63.1
cnt 40
lst -63
max -54
min -67
at_HMCFG:
avg -54.4583333333333
cnt 312
lst -51
max -46
min -72
at_HMLAN:
avg -61.9935691318328
cnt 311
lst -62
max -56
min -79
shadowReg:
tmpl:
Attributes:
IODev HMLAN
IOgrp HMCCU:HMLAN
actCycle 600:00
actStatus alive
autoReadReg 4_reqStatus
burstAccess 1_auto
devStateIcon locked:locked.svg unlocked:unlocked.svg
devStateStyle style="text-align:left;;font-weight:bold;;"
eventMap /on:unlocked/off:locked/
expert 2_raw
firmware 1.7
group DoorControl
model HM-LC-SW1-BA-PCB
msgRepeat 1
peerIDs 00000000,00004101,
room Kontrollraum
serialNr OEQ2624669
subType switch
webCmd
Hallo Peter,
Zitat2018-08-20 08:29:09 battery low
eventuell ist es das battery reading. Das steht auf low.
Möglicherweise schaltet die 1.7 Firmware dann nach einer gewissen Zeit auf absolutes Stromsparen, um die Batterie nicht bis zum Tod mit möglichem Auslaufen leer zu saugen?
Du hast das default lowBatLimitBA von 10.5V eingestellt.
Das Limit kannst Du bis runter auf 5V beim HM-LC-SW1-BA-PCB einstellen.
Ich habe nur Firmware 1.6 und kann daher das Verhalten leider nicht testen oder nachvollziehen.
Ich habe nur einen mit Firmware 1.6, bei dem es auf low (weil knapp unter 5V versorgt) steht und der macht trotzdem weiter.
Gruß, Ansgar.
Den Verdacht hatte ich auch schon, betreibe deshalb seit gestern einen zweiten neuen Schalter - wird derzeit bei ansonsten Default-Einstellungen mit 14 V versorgt. Bisher kein Ausfall.
Edit: Doch, jetzt ist das Ding weg. Register ist auf 10.5 V, Spannungsversorgung war mit 14 V.
Edit Edit: Auch wenn man bei einer Spannungsversorgung das lowBat-Register auf 5 stellt, (und damit die batteryLow condition vermeidet), verabschiedet sich das Gerät nach ein paar Stunden :( :(
Bei FW 1.6 habe ich das Problem ebenfalls nicht gehabt.
LG
pah
Einen anderen Seiteneffekt hatte ich mit dem Jalousieaktor HM-LC-Ja1PBU-FM. Dieser zeigte nach einem Jahr Betrieb exakt dieses Verhalten sodass nach dem erneuten Anlernen einige Stunden später ein Missing Ack in FHEM kam. Die Ursache konnte ich bisher nicht ermitteln. Habe letztendlich diesen Aktor gegen EnOcean (Eltako) getauscht. Da sich in dem Schalterverbund noch weitere Homematic Aktoren befinden gehe ich von einem Kommunikationsproblem aus. Daher verwende ich nun im Mix EnOcean bei meinen Jalousieaktoren.
Als mögliche Ursache vermute kann es auch ein Qualitätsproblem sein. Nach einem Jahr Bauteilalterung (in meinem Fall) sollte zwar nicht sein ist aber denkbar
Gruß,
Klaus
Das ist ja alles ganz großer Mist.
Zurückschicken und ELV um Nachbesserung bitten.
Das Setup ist elektronisch sonst einwandfrei? Keine Versorgungsspikes?
Ich habe jetzt parallel 2 x FW 1.7 und 1 x 1.6 im Test - bei den 1.7ern tritt das Problem reproduzierbar auf, mit unterschiedlichen Spannungsversorgungen.
Der erste Verdacht - lowBatt - hat sich nicht bestätigt.
Im Moment stelle ich fest, dass bei ledMode = on erst einmal keine Ausfälle auftreten. Warten wir mal den Tag ab.
LG
pah
Seit Jahren habe ich mehrere mit 1.6 installiert, mit 2*2 1,2v Akkus. Immer zeigten sie low batt an. Nie ein Problem gehabt.
Seit ein paar Tagen zickte einer von ihnen herum. Weder auf einer ccu, noch in fhem bekam ich ihn zum laufen.schaltete man via Taste an dem Modul, hat die Ccu und fhem den Status auch geändert, jedoch von der CDU, oder fhem kam ein Fehler.
Testweise hatte ich das Teil auf Werkseinstellungen resettet und neu angelernt. Problem blieb bestehen.
5v Netzteil angeschlossen. Werksreset, neu anlernen. Problem blieb bestehen.
Mittels 5v Netzteil Reset durchgeführt. Mit den Teilen in Richtung ccu (ca. 1m Abstand) anlernen- funktioniert.
Netzteil ab, wieder mit Akkus verbunden, läuft. An die alte Stelle verbracht, nur das Modul etwas näher in Richtung ccu.
Alles gut. Evtl. hab ich dort in der Ecke seit neuestem eine Störquelle. Egal. Abwarten.....
Hmmm.
Den 1.6er hatte ich seit 2015 im Außenbereich in Betrieb, vor vier Wochen ist er dann mit dem "Missing Ack" ausgestiegen. Daraufhin nach dem Urlaub ausgebaut, weil ich ihn für defekt hielt, und durch einen neuen 1.7er ersetzt - mit den beschriebenen Problemen.
Allerdings ist der 1.6er inzwischen mirakulös wieder zum Leben erwacht - und ist gegenwärtig im Vergleichstest mit den beiden 1.7ern. Und machte darin überhaupt keine Mucken, hat sich (im Gegensatz zu den 1.7ern) nicht einmal verabschiedet. Allerdings erfolgte dieser Test bisher im Innenbereich, also fast um die Ecke zum HMLAN.
Der 1.7er im Außenbereich verabschiedete sich bis heute früh nach wie vor in unregelmäßigen Abständen komplett. An ein Problem der Stromversorgung glaube ich nicht ganz - kann das aber noch nicht ausschließen, weil an diesen 5V auch das Panikschloss für die Hoftür hängt.
Der (Test-) 1.7er im Innenbereich lief einen halben Tag gut (lowBatt Register auf 10.5 V, Versorgung mit 14 V). Dann habe ich ihn (nach Strafandrohung meiner Liebsten...) vom Wohnzimmer in den Keller verlegt, woraufhin er sich nach einer Stunde verabschiedete (das war die Meldung drei Posts früher).
Ich habe im Außenbereich seit 2015 noch einen weiteren 1.6er laufen, einziger Unterschied: ledMode=on. Keine Ausfälle, keine Probleme.
Derzeit laufen die beiden 1.7er und der (alte) 1.6er testweise im Außenbereich (soll eigentlich heißen: In größerer Entfernung vom HMLAN), alle mit 5V und ledMode=on.
Sehn wir mal.
LG
pah
Wo habt ihr denn die Firmware 1.7 für diesen Batterie-Aktor her?
Auf der eQ3-Homepage finde ich hierzu nichts.
Ist drin gewesen, habe die Dinger vor 2 Wochen bei ELV neu bestellt.
LG
pah
Ich antworte mir mal selbst:
Ob man es glaubt oder nicht, seit ich bei den beiden 1.7ern ledMode=on gesetzt habe, (heute morgen 8:00) ist keiner mehr "abgestorben".
Ich muss übrigens noch korrigieren: Der vierte Schaltaktor ist kein 1.6er und seit 2015 in Betrieb, sondern einer mit Firmware 1.5 und im Dauereinsatz seit 2014. Der macht am wenigstens Probleme...
LG
pah
LED mode auf on ist aber natürlich ein Batteriefresser... damit ist das Ding ja nicht mehr sinnvoll einsetzbar.
Was sagt denn ELV?
Zitat von: connormcl am 22 August 2018, 23:53:25
LED mode auf on ist aber natürlich ein Batteriefresser... damit ist das Ding ja nicht mehr sinnvoll einsetzbar.
Bei einem Aktor, der die meiste Zeit darauf wartet, für ein paar Sekunden aktiviert zu werden, ist das völlig unerheblich. Tür- und Garagentoröffner im Privatbereich etwa.
Übrigens befeuere ich seit Monaten einen -Ba mit ledMode off störungsfrei ... leider mit FW 1.5 ...
Nee nee, das ist nicht schön.
24 Stunden hat es jetzt gehalten mit ledMode=on - und heute morgen sind die beiden 1.7er wieder mausetot.
Der eine ließ sich im 2. Versuch wieder wecken - der andere nicht.
LG
pah
Hm...da kam doch letztens ein Update des cul_hm Modul. Ich habe meine Batterie Aktoren mittlerweile auf ein raspberrymatic migriert.
Dort funktionieren sie wieder tadellos und zuverlässig. Ein klein wenig habe ich das cul_hm Modul im Verdacht. Nun kann ich aber nicht mehr sagen welche Aktion zum Erfolg führte. Weg von fhem und hin zu raspberrymatic, Reset auf Werkseinstellungen, etwas näher zum cul.
Bin neugierig geworden und habe mal meinen -BA-PCB wieder aus der Bastelkiste geholt. Den hatte ich ausgemustert, weil das Reading "battery" nicht so wollte wie ich.
Jetzt also im Dauertest auf meinem Testsystem mit ledMode = off und Fw 1.7
Läuft "schon" 5 Minuten.... Ich werde berichten.
"Etwas näher zum CUL" - das wäre in der Tat auch noch ne Möglichkeit.
Der eine 1.7er lief einen halben Tag problemlos, bis ich ihn in den Keller gesteckt habe. Und tatsächlich ist derjenige, der heute morgen nicht mehr zum Aufstehen zu bewegen war, etwas weiter von den HMCFG / HMLAN entfernt.
Ich werde also heute abend mal testen, den derzeit noch "braven" 1.7er und den 1.6er etwas weiter weg zu stellen.
Aber warum das mit ledMode=on 24 Stunden geht, und mit ledMode=off schon nach wenigen Stunden nicht mehr, ist mir schleierhaft.
LG
pah
Sieh an, sieh an.
Habe heute den 1.6er und den bisher braven 1.7er weitere 15 m entfernt.
HMCFG_RSSI -57
HMLAN_RSSI -69
Kurzzeitig problemlos bedienbar - und dann nach ca. 20 Minuten geht der 1.7er in "Missing Ack".
Es hat also (auch?) etwas mit der Signalstärke zu tun.
LG
pah
Hallo Peter,
mit 1.6er Firmware und seit 24h ledMode off kein Unterschied zu ledMode on. COC RSSI bei ca. -62
Mehr kann ich wohl leider nicht beitragen.
Gruß, Ansgar.
Was mir bei meinem Ausfall der HM-LC-Ja1PBU-FM in Punkto Rssi aufgefallen ist dass die über den Tag hinweg unterschiedlich stark war. Ab etwa 95 gab es dann keine Kommunikation zum CUL mehr und der Missing Ack kam dann. Zudem konnte ich beobachten dass wenn ich den HM-LC-Ja1PBU-FM aus der Unterputzdose heraus hängen ließ dieser über mehrere Tage wieder vernünftig lief. Nun kommt die weibliche Aspekte ins Spiel das eine derartige Verkabelung keine Alternative ist. Nachdem ich den Aktor wieder eingebaut hatte fingen die Probleme wieder von vorne an.
Erst der Tausch auf Eltako TF61J brachte hier den Erfolg.
Vermutlich können es Kommunikative Probleme bei den Homematic's untereinander gewesen sein oder Bauteilalterung.
Zur Zeit stehen meine Jalousieaktoren unter erhöhter Beobachtung
ok, meiner läuft nun ca. 23 Stunden ohne Probleme.
fw 1.7 ledMode=off, rssi = satt
Betrieb mit HM-CFG-USB-2
rssi_at_hmusb cnt:90 min:-45 max:-30 avg:-40.21 lst:-41
rssi_hmusb cnt:16 min:-44 max:-29 avg:-37.56 lst:-40
Jetzt kommt er weiter weg und denn schau ma ma
im list vom actor sind auch probleme mit den gateways erkennbar (ioerr, iodly).
eigentlich sollte der hmlan das bevorzugte io sein. das internal IODev zeigt aber HMCFG als aktuelles io.
disconnects vom hmlan? neueste fw beim hmlan (0.965)?
gibt es eventuell zusammenhänge mit dem umschalten der io?
Gute Fragen.
Gibt es irgendeine Quelle, aus der man lernen kann, wie diese Zusammenhänge sind ? Mir sind sie jedenfalls (noch) unklar, dafür benötige ich Hilfe.
Was könnte ich testen ? Bin für jeden Tipp dankbar.
Fakten:
- Firmware beim HMLAN ist 0.964, also nicht die Neueste. Damit hatte ich aber noch nie ein Problem (Edit: Eine FW 0.965 finde ich bei eQ-3 nicht - hat die jemand herumliegen?)
- Der HMCFG zeigt diverse Disconnects, mehr jedenfalls als der HMLAN.
- Der betreffende 1.7er geht auch denn in den Scheintod, wenn IODev und LastInputDev beide gleich HMCFG sind.
- Der betreffende 1.7er hat HMCFG_RSSI=-69 und HMLAN_RSSI=-57.
- Der zweite 1.7er befindet sich im Moment in größerer Entfernung als der erste, hat aber aus baulichen Gründen besseren Empfang mit HMCFG_RSSI=-50 und HMLAN_RSSI=-74
- Ein 1.5er hat HMCFG_RSSI=-67 und HMLAN_RSSI=-68, macht aber überhaupt keine Probleme
LG
pah
List HMLAN:
Internals:
CFGFN
DEF 192.168.0.xx
DeviceName 192.168.0.xx:1000
FD 31
HMLAN_MSGCNT 14525
HMLAN_TIME 2018-08-25 06:47:25
IFmodel LAN
NAME HMLAN
NR 10
NTFY_ORDER 50-HMLAN
PARTIAL
RAWMSG E24898C,0000,1C0F2B3C,FF,FFBC,2D861024898C0000000AA0D00B0E40
RSSI -68
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 40 report:39
msgKeepAlive dlyMax:32.175 bufferMin:7
msgLoadCurrent 1
msgLoadHistoryAbs 5min steps: 1/1/1/1/1/1/1/1/1/1/1/1
msgParseDly min:-9471 max:5705 last:14 cnt:14026
owner 000041
owner_CCU HMCCU
uptime 005 130:45:56.156
READINGS:
2018-08-23 16:12:47 D-HMIdAssigned 000041
2018-08-23 16:12:47 D-HMIdOriginal 1EA282
2018-08-23 16:12:47 D-firmware 0.964
2018-08-23 16:12:47 D-serialNr JEQ0706117
2018-08-23 22:08:23 Xmit-Events init:2 disconnected:3 ok:2
2018-08-23 22:08:23 cond ok
2018-08-25 06:47:23 loadLvl low
2018-08-19 19:59:16 prot_Warning-HighLoad last
2018-08-23 22:07:17 prot_disconnected last
2018-08-23 22:08:23 prot_init last
2018-06-21 12:44:55 prot_keepAlive last
2018-08-23 22:08:23 prot_ok last
2018-08-23 22:08:23 state opened
helper:
assIdCnt 40
assIdRep 39
info 03C4,JEQ0706117,1EA282,000041
setTime 46849
cnd:
0 2
253 3
255 2
dly:
cnt 14026
lst 14
max 5705
min -9471
ids:
20931C:
cfg +20931C,00,01,00
name BZ.F
21E564:
cfg +21E564,00,01,00
name GB.F
239034:
cfg +239034,00,01,00
chn 02
flg 0
msg
name A.Ga.Tor
to 1535130084.28507
248CD5:
cfg +248CD5,00,01,00
chn 02
flg 0
msg
name WZ.HMHz2
to 1535165713.31761
249572:
cfg +249572,00,01,00
chn 02
flg 0
msg
name BZ.HMHz
to 1535167150.27885
24978A:
cfg +24978A,00,01,00
chn 02
flg 0
msg
name WZ.HMHz1
to 1535165396.58448
26959D:
cfg +26959D,00,01,00
name DZ.F
26CF53:
cfg +26CF53,00,01,00
name UG.WD0
26DD27:
cfg +26DD27,00,01,06
name X.HMT
27120D:
cfg +27120D,00,01,00
chn 02
flg 0
msg
name WZ.HMTh
to 1535135757.29517
28438B:
cfg +28438B,00,01,00
name WZ.HMT
2E85B6:
cfg +2E85B6,00,01,00
chn 02
flg 0
msg
name GB.HMHz
to 1535170545.02887
2E9400:
cfg +2E9400,00,01,00
chn 02
flg 0
msg
name BI.HMHz
to 1535167420.45063
2E96A4:
cfg +2E96A4,00,01,00
chn 02
flg 0
msg
name K.HMHz
to 1535165915.33385
2FB2B2:
cfg +2FB2B2,00,01,00
name J.HMT
322AD6:
cfg +322AD6,00,01,00
chn 80
flg 0
msg
name WZ.Gong
to 1535130084.94017
331A3E:
cfg +331A3E,00,01,00
chn 02
flg 0
msg
name HM_331A3E
to 1535141526.54314
39910C:
cfg +39910C,00,01,00
name EB.Klingel
3EFA6D:
cfg +3EFA6D,00,01,00
name P.HMT
3F5079:
cfg +3F5079,00,01,00
chn 80
flg 0
msg
name A.Door.Tuer
to 1535140804.14284
4E614E:
cfg +4E614E,00,01,00
chn 01
flg 0
msg
name ZK.Multi
to 1535153428.3302
4E99B2:
cfg +4E99B2,00,01,00
name WZ.HMU
4F4417:
cfg +4F4417,00,01,00
chn 01
flg 0
msg
name A.Door.K
to 1535137799.66129
50B653:
cfg +50B653,00,01,00
chn 02
flg 0
msg
name WZ.KTuer
to 1535142314.47532
50F7DF:
cfg +50F7DF,00,01,00
name WZ.Key1
50F833:
cfg +50F833,00,01,00
name WZ.Key3
50F97B:
cfg +50F97B,00,01,00
name WZ.Key2
53A63D:
cfg +53A63D,00,01,00
chn 02
flg 0
msg
name WZ.Decke
to 1535142313.32369
5793C5:
cfg +5793C5,00,01,00
chn 02
flg 0
msg
name WZ.4x
to 1535142312.08902
57C8C4:
cfg +57C8C4,00,01,00
chn 01
flg 0
msg
name EB.Multi
to 1535139956.99576
58E3C7:
cfg +58E3C7,00,01,00
chn 02
flg 0
msg
name WZ.Kamin
to 1535142315.05133
591C17:
cfg +591C17,00,01,00
chn 02
flg 0
msg
name WZ.Roll.2
to 1535057195.51122
591F22:
cfg +591F22,00,01,00
chn 02
flg 0
msg
name WZ.Roll.3
to 1535057195.68139
591F2A:
cfg +591F2A,00,01,00
chn 02
flg 0
msg
name WZ.Roll.1
to 1535057195.0598
5945B4:
cfg +5945B4,00,01,00
chn 02
flg 0
msg
name WZ.Ess
to 1535142313.89951
5C7D6D:
cfg +5C7D6D,00,01,00
chn 02
flg 0
msg
name WZ.Roll.0
to 1535057195.3398
5D61A3:
cfg +5D61A3,00,01,00
chn 02
flg 0
msg
name EB.HMHz
to 1535170704.39525
606F87:
cfg +606F87,00,01,00
chn 02
flg 0
msg
name SZ.HMTh
to 1535106656.45493
66C09C:
cfg +66C09C,00,01,00
flg 0
name A.Hof.Tuer.A
66C09D:
flg 0
k:
BufMin 7
DlyMax 32.175
Next 1535172463.54677
Start 1535172443.54677
loadLvl:
bl 40
a:
99
90
40
0
h:
0 low
40 batchLevel
90 high
99 suspended
log:
all 0
sys 0
ids:
ARRAY(0x23aa340)
q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLastMax 1
loadNo 9
scnt 1
ald:
1
1
1
1
1
1
1
1
1
1
1
1
apIDs:
ref:
drft -0.000199990000499975
hmtL 470753972
kTs 0
offL 1534701689577
sysL 1535172443549
Attributes:
hmId 000041
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
room System
wdTimer 20
List HMCFG:
Internals:
CFGFN
DEF 192.168.0.xx
DeviceName 192.168.0.xx:1000
FD 12
HMCFG_MSGCNT 14046
HMCFG_TIME 2018-08-25 06:43:24
IFmodel USB
NAME HMCFG
NR 11
NTFY_ORDER 50-HMCFG
PARTIAL
RAWMSG E606F87,0000,1C0C9CE5,FF,FFB1,4F865A606F8700000024F032
RSSI -79
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 14
msgKeepAlive dlyMax:32.167 bufferMin:-27
msgLoadCurrent 0
msgLoadHistoryAbs 5min steps: 0/0/0/0/0/0/0/0/0/0/0/0
msgParseDly min:-36 max:13914 last:52 cnt:12118
owner 000041
owner_CCU HMCCU
uptime 005 130:43:08.645
READINGS:
2018-08-23 16:12:48 D-HMIdAssigned 000041
2018-08-23 16:12:48 D-HMIdOriginal 372D79
2018-08-23 16:12:48 D-firmware 0.964
2018-08-23 16:12:48 D-serialNr MEQ0232733
2018-08-25 05:49:52 Xmit-Events disconnected:168 init:112 Warning-HighLoad:1 ok:58
2018-08-25 05:49:52 cond ok
2018-08-25 06:43:11 loadLvl low
2018-08-19 19:40:25 prot_ERROR-Overload last
2018-08-24 10:00:13 prot_Warning-HighLoad last
2018-08-25 05:48:42 prot_disconnected last
2018-08-25 05:49:51 prot_init last
2018-08-02 15:29:18 prot_keepAlive last
2018-08-25 05:49:52 prot_ok last
2018-08-25 05:49:51 state opened
helper:
assIdCnt 14
assIdRep 14
info 03C4,MEQ0232733,372D79,000041
setTime 46849
cnd:
0 58
2 1
253 168
255 112
dly:
cnt 12118
lst 52
max 13914
min -36
ids:
1E0651:
cfg +1E0651,00,01,00
name TH.SD0
1E0B5E:
cfg +1E0B5E,00,01,00
name TH.SD1
1E1B36:
cfg +1E1B36,00,01,00
name TH.SD2
22E630:
cfg +22E630,00,01,00
chn 02
flg 0
msg
name SZ.HMHz
to 1535166603.70508
24898C:
cfg +24898C,00,01,00
chn 02
flg 0
msg
name DZ.HMHz
to 1535166831.68757
269397:
cfg +269397,00,01,00
name SZ.Tuer.K
38625A:
cfg +38625A,00,01,00
chn 01
flg 0
msg
name WZ.Tuer.K
to 1535133038.33018
47727F:
cfg +47727F,00,01,00
chn 02
flg 0
msg
name WZ.Strip
to 1535142312.58224
4EA407:
cfg +4EA407,00,01,00
chn 02
flg 0
msg
name AZ.F
to 1535054277.74849
4F902B:
cfg +4F902B,00,01,00
chn 01
flg 0
msg
name A.Hof.MD1
to 1535132973.91956
52EE75:
cfg +52EE75,00,01,00
flg 0
msg
name A.Mailbox.K
to 1535035226.71515
563375:
cfg +563375,00,01,00
chn 02
flg 0
msg
name WZ.Sofa
to 1535142311.76025
66C09C:
cfg +66C09C,00,01,00
chn 02
flg 0
msg
name HM_66C09C
to 1535141528.97084
66C09D:
cfg +66C09D,00,01,00
chn 02
flg 0
msg
name A.Hof.Tuer.A
to 1535171436.04659
k:
BufMin -27
DlyMax 32.167
Next 1535172216.67552
Start 1535172191.67552
loadLvl:
bl 40
a:
99
90
40
0
h:
0 low
40 batchLevel
90 high
99 suspended
log:
all 0
sys 0
ids:
ARRAY(0x2226c68)
q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLastMax 0
loadNo 8
scnt 9
ald:
0
0
0
0
0
0
0
0
0
0
0
0
apIDs:
ref:
drft -0.000440158457044536
hmtL 470575743
kTs 0
offL 1534701615938
sysL 1535172166641
Attributes:
hmId 000041
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
room System
verbose 0
Moin pah,
laut Fhem Wiki folgendes zu 0.965 Firmware:
ZitatDie aktuelle Firmware Version des HMLAN Konfigurators ist 0.965 (Stand Februar 2016). Ein Update ist mit dem "Firmware Update Tool" möglich, die Firmware ist Bestandteil des Tools.
http://www.eq-3.de/Downloads/Software/Firmware%20Update%20Tool/HM-Firmware-Update-Tool_V1_2_eQ-3_160211.zip
Grüße Newbee
mein BA-PCB im Paralleltest, aber mit HMUSB, funktionier seit ca. 24 Stunden.
rssi_at_hmusb cnt:4 min:-63 max:-62 avg:-62.75 lst:-62
rssi_hmusb cnt:3 min:-61 max:-60 avg:-60.66 lst:-60
Um die Feldstärke als Grund auszuschließen, werde ich das Device noch einmal weiter weg platzieren.
HMLAN = 0.965
HMUSB = 0.967
das wäre bereits seit 2 Jahren , die Pflicht Kür
2018-08-25 05:49:52 Xmit-Events disconnected:168 init:112 Warning-HighLoad:1 ok:58
ok, da gibt es ja einiges zu tun.
1. disconnects eleminieren:
fw 0.964, oder älter, hat ein massives problem mit homematicIP messages. diese können auch vom nachbarn kommen. also unbedingt updaten.
da normalerweise nach einem disconnect neu init(ialisiert) wird und abschliessend ein ok kommen sollte, wundern mich hier zusätzlich die sehr unterschiedlichen werte.
da disconnects unterschiedliche ursachen haben können, gibt es leider keine eindeutige empfehlung. scheinbar verursachen bei dir auch (manchmal?) fhem freezes disconnects, da die keepAlive readings existieren.
eventuell hast du dies auch schon durch setzen von "wdTimer 20" versucht zu verbessern. ein freeze freies fhem sollte immer mit dem default von 25sek funktionieren. zum aufspüren von freezes kann ich das modul freezemon empfehlen.
manchmal sind wohl auch "alternde" elkos im hmlan eine ursache. auch weitere ursachen, wie zb netzwerk, sind in folgendem thread, denke ich, ziehmlich umfassend dokumentiert. https://forum.fhem.de/index.php/topic,20776.0.html (https://forum.fhem.de/index.php/topic,20776.0.html)
2. zu hohe funklast der io
auch overload führt zum ausfall/wechsel des sendenden io. war das jetzt durch durch die tests bedingt oder kommt das häufiger vor? messsteckdosen könnten hier zb die ursache sein. auch schlechter empfang mit vielen wiederholungen, besonders im zusammenspiel mit burst und aes.
einn guten überblick bekommt man hierzu mit "get hminfo msgStat" und "get hminfo protoEvents all"
meintest du doku über vccu?
edit:
mist, jetzt hatte ich beim schreiben angenommen, dass der HMCFG auch ein hmlan ist. der name kam mir gleich komisch vor.
der hmusb hat natürlich zum teil andere disconnect ursachen. wie harry sagt, für diesen fw 0.967. ausserdem ist dann sicherlich auch der hmland zu alt.
daher ist auch die aktuelle load immer null und fhem versucht dann zb fehlende registerdaten ohne rücksicht auf das noch vorhandene sendekontingent zu holen.
Ich habe jetzt mal den HMLAN herausgenommen, den HMCFG sowie den hmland auf die neueste Version aktualisiert. Außerdem durch eine Verlagerung des HMCFG die Empfangsbedingungen etwas verbessert, der Aktor meldet jetzt einen RSSI von -54.
Damit sind alle einfachen Faktoren herausgenommen, jetzt warten wir es mal ab.
Edit: Denkste. Wieder nach einigen Stunden in den Scheintod gelangen.
LG
pah
Falls es zum Fehler-Eingrenzen hilft:
Ich habe 5 von den HM-LC-Sw1-Ba-PCB in der ganzen Weihnachtszeit im Einsatz - ohne Probleme.
Die haben alle FW 1.7! Allerdings betreibe ich die an einer CCU2.
LG,
Stephan.
mein BA-PCB im Paralleltest, aber mit HMUSB, funktioniert wieder seit über ca. 30 Stunden.
Damit waren die 3 Tests über je ca. 24 Stunden (jeweils mit Power off und Power on zwischen den Tests) erfolgreich. Das Device läuft ohne Probleme. Schlechter rssi als Grund scheidet m.E. aus.
rssi_at_hmusb cnt:4 min:-71 max:-69 avg:-70.25 lst:-69
rssi_hmusb cnt:3 min:-71 max:-67 avg:-68.66 lst:-67
Ich habe den Eindruck, dass es am Funkinterface bei pah liegen könnte.
Nein, Funkinterface scheidet aus.
Ich denke inzwischen, dass es irgendein Problem mit der Spannungsversorgung ist - ein 1.7er an einem anderen Netzteil macht keine Probleme.
Mal sehen, ob sich das durch ein paar Kondensatoren lösen lässt.
Edit: Weder das, noch durch eine andere Spannungsversorgung. Ich bleibe dran und versuche weiter, den Grund zu finden.
LG
pah
ich habe noch ein paar ideen:
1. attr burstAccess löschen.
das ist eigentlich nur für devices, die man wahlweise über burst wecken kann. dieser actor braucht aber immer burst. das attribut sollte zwar dann keinen einfluss haben, aber wer weiss...
2. attr actCycle löschen
hier hast du 600 std / 25 tage eingestellt. soll das so sein? nutzt du auch zusätzlich im actiondetector das attr actAutoTry?
zum testen eventuell auch mal löschen.
3. attr autoReadReg ausschalten / auf null setzen.
es gibt wohl 1,2 oder 3 devices, bei denen probleme auftreten, wenn das attribut gesetzt ist.
4. raw messages sniffen, wie im wiki beschrieben.
enweder erkennt man eine sonderbare kommunikation beim "ausstieg" des actors, oder ein vergleich der beiden fw zeigt besondere unterschiede.
5. ein at mit regelmässigem statusrequest könnte eventuell die tests forcieren/verkürzen.
6. hat der actor vielleicht ein burst problem?
gibt es bei dir viele burst messages? mit "get hminfo msgStat" kann man die anzahl der burst messages sehen, die von den io empfangen werden. hier werden auch eventuelle burst messages vom nachbarn gezählt.
zum monitoren, was der actor empfängt, sollte sich dieser in der nähe des messenden io befinden.
und noch etwas:
hin und wieder hat eq3 probleme mit aes.
also auch mal aes ausschalten.
Dank für die vielen Tipps. burstAccess und ActCycle sind schon länger weg, daran lag es auch nicht. Am AES auch nicht.
Weiter mit der Detektivarbeit.
LG
pah
Hallo Peter,
noch was zum Prüfen ins Blaue.
Schau mal, ob das Device mit get assignIDs beim IO gelisted wird. Bevor und wenn es abgestorben ist.
Gruß, Ansgar.
@noansi: Device wird vor und nach dem Absterben bei den assigned IDs korrekt gelistet.
Die Spannungsversorgung habe ich ja inzwischen auf mehrfache Weise ausgeschlossen.
Nächster Verdacht war, dass der Raspberry Pi mit dem HMCFG Netzwerkprobleme hat (möglich, weil über PowerLAN angeschlossen)
==> Nein, das war es auch nicht. Absterben trotz direktem Ethernetkabelanschluss
Nächster Verdacht war: Freezes auf der FHEM-Installation auf diesem speziellen Raspberry Pi (diese FHEM-Installation greift aber NICHT auf den HMCFG zu, der hmland mit HMCFG läuft einfach nebenher). Diese Freezes kommen von dem BOSE Soundtouch-Modul ( grrr.... ). Außerdem hat diese FHEM-Installation ziemlich viele HTTPMOD, die das Netzwerk blockieren könnten. Also noch einen Raspberry Pi daneben gestellt, auf dem keinerlei FHEM läuft, sondern nur ein hmland mit HMCFG.
==> Nein, das war es auch nicht. Absterben trotz dezidiertem Raspberry Pi für den HMCFG
Derzeit unternehme ich einen Versuch mit einem weiteren HM-Interface, HM-MOD-RPI-PCB mit noch einem weiteren separaten Raspberry Pi, der nur dieses Funkmodul bedient. Und der als assigned ID's nur die vier HM-LC-SW1-BA-PCB hat.
Mir stellt sich die Frage, warum eigentlich die 1.7er HM-LC-SW1-BA-PCB im "Missing Ack" Zustand verbleiben. Sie müssten doch eigentlich irgendwie wieder aufgeweckt werden?
LG
pah
Mir ist das alles auch zunehmend mystisch. MISSING_ACK heißt ja erst mal dass FHEM eine erwartete Antwort vom Gerät vermisst.
Im ersten Beitrag: 3 Sekunden zum Aufwecken? Was passiert eigentlich wenn man den Aktor einfach nur mit der Taste lokal schaltet? Schaltet er da? posaunt er seinen Status hinaus, liest das FHEM auch nicht?
Steuerbarkeit aus FHEM sollte unabhängig von MISSING_ACK sein, muss aber ein Burst sein. Denkbar, dass die Firmware nicht aufwacht bei den Bursts die FHEM senden kann.
Wo ist eigentlich Martin? :D
ZitatMir ist das alles auch zunehmend mystisch
Amen, Bruder, Amen.
Hat auch nicht geholfen, dass ein nagelneues dezidiertes Interface nur 2m entfernt vom Device stand (letzter oben beschriebener Versuch...).
Eine Option hab ich noch. Morgen ...
LG
pah
So, es scheint behoben (dem Himmel und allen Unterstützern sei Dank...)
Wenn es morgen noch läuft, werde ich hier eine Analyse posten - sonst sitze ich in der Ecke und lutsche am Daumen.
LG
pah
du machst es aber spannend.
hoffentlich kann ich heute einschlafen.
OK, scheint tatsächlich behoben zu sein.
Der BA-PCB sitzt zusammen mit einem Arduino und etwas Elektronik außen herum an meinem Hoftor und steuert das selbstverriegelnde Panikschloss. Der Arduino ist für den 1-Wire (genauer: iButton)-Kontakt zuständig, mit dem ich die Tür von außen entriegeln kann. Stromversorgung mit 5V.
Der 1.6er hatte sich im August nach einem Gewitter verabschiedet, gut, damit muss man im Außenbereich leben, also habe ich alle anderen Bauteile sorgfältig getestet und für gut befunden. Und den 1.7er eingebaut, womit die Probleme begannen.
Beim Test der Stromversorgung (irgendwo auf Seite 2 des Threads) habe ich den BA-PCB separat mit 5V versorgt. Sein Schaltausgang legt nur einen Pin des Arduino auf GND, das habe ich also so belassen.
Die "letzte Option", die ich oben genannt habe, war nun endlich die Richtige. Offenbar hatte das Schaltnetzteil (das sich im Innenbereich befindet) bei dem Gewitter etwas abbekommen, auf der Ausgangsseite war jedenfalls die Gleichspannung von 5V mit einer zusätzlichen hochfrequenten Wechselspannung von einigen Volt beaufschlagt. Dem Arduino hat das gar nichts ausgemacht, und bei einer Gleichspannungsmessung ist es natürlich auch nicht aufgefallen.
Auch bei separater Stromversorgung des BA-PCB wurde nun diese hochfrequente Wechselspannung über den Schaltausgang auf das Board des BA-PCB eingekoppelt (MOSFETs haben eine ziemlich hohe kapazitive Rückwirkung auf das Gate). Und zwar nicht so, dass der BA-PCB gestorben wäre oder gar nichts mehr gemacht hätte - aber doch so, dass er nach ein paar Stunden die Arbeit eingestellt hat. Man frage mich nicht, wieso erst nach ein paar Stunden...
Ich habe jetzt also das komplette Schaltnetzteil ersetzt, und die Kiste rennt.
Witzigerweise tut übrigens der 1.6er ebenfalls wieder, er war also "nur" scheintot.
Was lernen wir daraus:
1. Blitzschutz für Außenanlagen muss besser sein (ich habe seit Jahren die Funkenstrecken und Dioden dafür herumliegen, das aber nie wirklich implementiert).
2. In künftigen Anwendungen des BA-PCB werde ich den Schaltausgang sorgfältig absichern.
Danke an Alle, die sich gemeinsam mit mir Gedanken gemacht haben.
LG
pah
Also ich weiß nicht ... du hattest doch einen zweiten 1.7 im Test, der auch ausgestiegen ist - doch wohl nicht am gleichen monierten Netzteil?
Also dass das gewittergeschädigte Netzteil ein Problem datstellt : ja. Aber die Rückwirkung sehe ich trotzdem nicht so kritisch. Immerhin darf die geschaltete Spannung ja sonst auch reichlich über der Versorgung liegen, und dass die über die Mosfet- Kapazitäten gestreuten Ströme den Prozessor des Ba-PCB lahmlegen, glaube ich auch nicht - zumal ja ein langer Tastendruck das Ding wieder zum Leben erweckte nach Deiner Schilderung.
Denkbar, dass das eine (Schaltnetzteil) mit dem anderen (Firmware) gar nix zu tun hat?
ZitatAlso ich weiß nicht ... du hattest doch einen zweiten 1.7 im Test, der auch ausgestiegen ist - doch wohl nicht am gleichen monierten Netzteil?
Nein, anderes Netzteil. Warum der (und passend dazu der 1.6er) ausgestiegen ist, kann ich nicht mehr nachvollziehen - und Du hast Recht, es passt nicht ins Bild.
ZitatAber die Rückwirkung sehe ich trotzdem nicht so kritisch.
Vorsicht, es geht um hochfrequente Einkopplungen, das ist etwas anderes - die gehen problemlos
ZitatDenkbar, dass das eine (Schaltnetzteil) mit dem anderen (Firmware) gar nix zu tun hat?
Die Firmware der Interfaces habe ich als Erstes aktualisiert - auch mit der aktuellen Firmware gab es noch dieses Absterben.
Und Tatsache ist, dass erst nach der "letzten Option" (=kompletter Austausch des betreffenden Netzteils) die Sache behoben war.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 01 September 2018, 18:33:27
... es geht um hochfrequente Einkopplungen, das ist etwas anderes - die gehen problemlos
Na, ich vermute doch mal, dass die überlagerte Wechselspannung vom kaputten Netzteil die Schaltwandler-Frequenz hat. Nach meinen Erfahrungen liegt die selten über 100 kHz.
Die "Reverse Transfer Capacitance" des Mosfets liegt laut Datenblatt bei ca. 66 pF (15V). Ist die gemeint? Das würde einen Serienwiderstand von 24 kOhm ergeben - bei 10 Volt Amplitude der überlagerten Wechselspannung also weit weniger als 1mA eingekoppelter Strom. Das bringt den µP nicht durcheinander, denke ich doch stark. Da müsste schon der interne Takt durcheinandergewirbelt worden sein, so dass das timing nicht mehr stimmt. Aber das erklärt auch nicht, warum das Ding anfangs geht und erst nach Stunden aussteigt.
Genug der Kaffeestatzleserei ;D Ich drück die Daumen, dass es das nun wirklich endlich und dauerhaft war.
Genau diese 66 pF meine ich. Und die Frequenz stimmt auch - allerdings ist mit ziemlich vielen Oberwellen zu rechnen.
Nun müsste man aber noch genauer wissen, welchen Mikrocontroller eQ-3 hier verwendet. Der Aktor wäre nicht für Batteriebetrieb geeignet, wenn es auf Ströme von einem mA ankäme - relevanter ist die eingekoppelte Spannung. Bei einem hochohmigen Eingang sind 24 k Vorwiderstand so gut wie nichts.
ZitatDa müsste schon der interne Takt durcheinandergewirbelt worden sein, so dass das timing nicht mehr stimmt
Das wäre eine Möglichkeit - aber da lesen wir wirklich im Kaffeesatz. Könnte allerdings erklären, warum die Software dann Probleme machte.
ZitatDenkbar, dass das eine (Schaltnetzteil) mit dem anderen (Firmware) gar nix zu tun hat?
Habe jetzt beim erneuten Nachlesen erst verstanden, was eigentlich gemeint war. Der 1.6er ließ sich (an diesem Netzteil) gar nicht mehr durch einen langen Tastendruck wiederbeleben, der 1.7er schon.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 01 September 2018, 10:16:23
Die "letzte Option", die ich oben genannt habe, war nun endlich die Richtige. Offenbar hatte das Schaltnetzteil (das sich im Innenbereich befindet) bei dem Gewitter etwas abbekommen, auf der Ausgangsseite war jedenfalls die Gleichspannung von 5V mit einer zusätzlichen hochfrequenten Wechselspannung von einigen Volt beaufschlagt.
Hi Peter,
dann wäre zwar der Blitzschutz im Außenbereich natürlich auch nicht zu vernachlässigen, aber ich würde hier zuerst innen einen Kombiableiter der Klassen 1-3 im Verteilerschrank (von Citel gibt es so einen) und noch nen Feinschutz vor dieses und andere Schaltnetzteile ins Auge fassen. Der 1.6er wird doch dann auch nur an dem Netzteil verzweifelt sein.?