Ich habe einen HM-LC-Sw1PBU-FM laut Wiki (https://wiki.fhem.de/wiki/HM-LC-Sw1PBU-FM_Alternative_Firmware#Bootloader_flashen (https://wiki.fhem.de/wiki/HM-LC-Sw1PBU-FM_Alternative_Firmware#Bootloader_flashen) und https://wiki.fhem.de/wiki/HM-LC-Sw1PBU-FM_Alternative_Firmware_am_Raspi_bauen_u._flashen (https://wiki.fhem.de/wiki/HM-LC-Sw1PBU-FM_Alternative_Firmware_am_Raspi_bauen_u._flashen)) mit der alternativen Firmware bespielt.
Die Modifikationen https://forum.fhem.de/index.php/topic,18071.msg275891.html#msg275891 (https://forum.fhem.de/index.php/topic,18071.msg275891.html#msg275891) habe ich auch drin. Den Bootloader kann ich bauen, aber beim Einspielen per avrdude kommt immer ein Fehler. Ich habe daher den Bootloader aus https://forum.fhem.de/index.php/topic,18071.0.html (https://forum.fhem.de/index.php/topic,18071.0.html) genommen, meine SN reingepatched und geflashed. Soweit läuft der Schalter.
Er bleibt aber immer wieder mal hängen. Anders als unter https://forum.fhem.de/index.php/topic,18071.0.html (https://forum.fhem.de/index.php/topic,18071.0.html) beschrieben ist dabei nicht die Anzeige Strom "fließt"/"fließt nicht" das Problem, sondern der Schalter reagiert einfach nicht mehr. Auch werden Tastenbefehle (die Tasterwippe ist mit einer anderen Lampe gepeered) nicht erkannt.
Wenn ich den Schalter kurz stromlos mache, läuft er danach wieder. Manchmal fängt er sich auch nach einer Weile wieder von selbst und reagiert dann wieder.
Als Fehler kommt entweder "MISSING ACK" oder "RESPONSE TIMEOUT". Er ist nicht nur von fhem nicht mehr erreichbar, sondern aufgehängt. Tastendrücke auf Wippe oder Config-Schalter zeigen keine Reaktion. Andere Firmware/Bootloader mit anderen Einstellungen zeigen gleiches Verhalten.
Hat jemand ein ähnliches Problem oder eine Idee, wo man ansetzen könnte?
list device
Internals:
BNO 0
BNOCNT 1
DEF xxxxxx
FUUID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx
HMLAN1_MSGCNT 20399
HMLAN1_RAWMSG xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
HMLAN1_RSSI -63
HMLAN1_TIME 2019-07-02 16:27:28
HMLAN2_MSGCNT 20419
HMLAN2_RAWMSG xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
HMLAN2_RSSI -39
HMLAN2_TIME 2019-07-02 16:27:28
IODev HMLAN2
LASTInputDev HMLAN2
MSGCNT 40818
NAME eg_LichtFlur_Aussenlicht
NOTIFYDEV global
NR 484
NTFY_ORDER 50-eg_LichtFlur_Aussenlicht
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
channel_01 eg_LichtFlur_Aussenlicht_Btn_1
channel_02 eg_LichtFlur_Aussenlicht_Btn_2
channel_03 eg_LichtFlur_Aussenlicht_Sw_1
channel_04 eg_LichtFlur_Aussenlicht_Sw_2
lastMsg No:0F - t:10 s:xxxxxx d:xxxxxx 0604C80000
protCmdDel 100
protLastRcv 2019-07-02 16:27:28
protRcv 333 last_at:2019-07-02 16:27:28
protRcvB 21 last_at:2019-07-02 16:25:51
protResnd 53 last_at:2019-07-02 16:32:00
protResndFail 17 last_at:2019-07-02 16:32:04
protSnd 380 last_at:2019-07-02 16:31:45
protState CMDs_done_Errors:1
rssi_at_HMLAN1 cnt:20399 min:-93 max:-49 avg:-68.84 lst:-63
rssi_at_HMLAN2 cnt:20419 min:-71 max:-12 avg:-43.07 lst:-39
READINGS:
2019-07-01 20:50:40 CommandAccepted yes
2019-07-01 20:49:15 D-firmware 1.5
2019-07-01 20:49:15 D-serialNr NEQxxxxxxx
2019-07-02 15:59:21 PairedTo 0xxxxxxx
2019-07-01 20:49:19 R-pairCentral 0xxxxxxx
2019-07-02 16:35:10 RegL_00.
2019-07-02 16:25:51 battery ok
2019-05-27 13:12:24 fwUpdate fail:notInBootLoader
2019-05-25 13:58:40 sabotageAttack_ErrIoAttack cnt 1
2019-07-02 16:32:04 state RESPONSE TIMEOUT:RegisterRead
helper:
HM_CMDNR 18
PONtest 1
addVal 1
cSnd 01xxxxxxxxxxxx00040000000000,01xxxxxxxxxxxx00040000000000
mId F0A9
peerFriend
peerOpt -:remoteAndSwitch
regLst 0
rxType 1
supp_Pair_Rep 0
tmplChg 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +xxxxxx,00,01,00
nextSend 1562077648.45365
prefIO
rxt 0
vccu vccu
p:
xxxxxx
00
01
00
mRssi:
mNo 0F
io:
HMLAN1:
-63
-63
HMLAN2:
-31
-31
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
prs 1
rpt:
IO HMLAN1
flg A
ts 1562077648.15043
ack:
HASH(0x5571a4d26fc0)
0F8002xxxxxxxxxxxx00
rssi:
at_HMLAN1:
avg -68.84455120349
cnt 20399
lst -63
max -49
min -93
at_HMLAN2:
avg -43.0766932758705
cnt 20419
lst -39
max -12
min -71
shadowReg:
tmpl:
role:
Attributes:
IODev HMLAN1
IOgrp vccu
aesCommReq 0
autoReadReg 4_reqStatus
event-min-interval .*:300
event-on-change-reading .*
expert 2_raw
firmware 1.5
model HM-LC-Sw1PBU-FM-CustomFW
room EG
serialNr NEQxxxxxxx
subType remoteAndSwitch
webCmd getConfig:clear msgEvents
Hi,
ich habe leider das gleiche Verhalten und noch keine Ahnung, wie man es fixen kann. Am liebsten würde ich die original Firmware wieder zurückflashen, aber ich kann sie nirgends finden.
Komischerweise lief es am Anfang locker ein halbes Jahr ohne Probleme durch und mittlerweile kommen die Aufhänger immer schneller (teilweise schon ein Tag nach Reset durch stromlos schalten)
Falls jemand im Forum eine Lösung kennt, wäre ich natürlich auch interessiert.
suche mal im forum nach "c26".
eventuell ein defekter kondensator.
HM ... an C26 glaube ich erst mal nicht. Hängt ein bisschen vom programmierten "brown out"-Verhalten ab. Typisch für defekte C26 ist aber eher der permanent wiederholte Selbst-Reset, der ja hier gerade nicht stattfindet. Findet dieses brown out - Verhalten aber nicht statt, bleibt der Prozessor in einer Hängeschleife, wenn der Spannungseinbruch für den Reset nicht reicht.
Gerade wenn der Aktor nach einem Reset für eine Weile (Minuten bis Stunden) normal arbeitet, spricht das eher nicht für den C26.
die alternative firmware nutzt ja eine strommessschaltung für externe wechsel-/kreuzschalter, die normalerweise ungenutzt bleibt.
eine schleichende versorgungsspannungsänderung könnte eventuell die detektion verändern.
zumindestens beinhaltet die fehlerbeschreibung eine sich ändernde zeitkonstante. das erinnert mich sofort an sterbende kondensatoren.
irgendwann muss c26 sowieso raus. ;)
Zitat von: frank am 16 März 2020, 21:50:47
suche mal im forum nach "c26".
eventuell ein defekter kondensator.
Das könnte der Fall sein - nur ist das einer der neuesten Schalter bei mir und wird bei mir nur 2* täglich geschaltet (also wenn er tut ;-). Die meisten meiner anderen Schalter sind deutlich älter und werden öfters betätigt.
Bei diesem Schalter hatte ich auch Probleme mit dem Einspielen des Bootloaders - ich musste den compilierten aus dem Forum nehmen und meine SN reinpatchen, sonst hätte das nicht geklappt. Die Reset-Folge funktioniert trotzdem nicht. Ich habe die alternative Firmware im Verdacht - oder mich, vielleicht habe ich auch an einer Stelle irgend etwas gehörig verbockt. Aber dann sollte er eigentlich gar nicht laufen, was er dann doch für eine Weile tut. Mein aktueller Workaround ist ein Umbau auf einen Shelly 1PM.
Zitat von: frank am 16 März 2020, 23:08:21
die alternative firmware nutzt ja eine strommessschaltung für externe wechsel-/kreuzschalter, die normalerweise ungenutzt bleibt.
eine schleichende versorgungsspannungsänderung könnte eventuell die detektion verändern.
Glaub ich eher nicht. Geht/geht nicht ist ein relativ klarer Punkt, der leicht zu erkennen ist.
Zitatirgendwann muss c26 sowieso raus. ;)
Das allerdings ist wieder mal frank-wahr. Schaden tut es jedenfalls gar nichts, das als erstes zu versuchen.
Die Häufigkeit der Nutzung sagt auch nichts über das Alterungsverhalten aus. Interessant, dass das mit dem Reset nicht klappt. Fast so, als bräuchte die Mimik eine kleine Zeit zum Abkühlen und Sammeln, bevor es wieder grenzwertig tut.
Auf den Kondensator bin ich auch schon gestoßen, da ich nach einer Nutzungsdauer von mittlerweile ca. 5 Jahren Probleme mit einigen Homematic Schaltaktoren bekommen habe. Ich habe die Kondensatoren deshalb bei drei problematischen Geräten getauscht, unter anderem beim umgeflashten Schaltaktor mit Custom Firmware. Bei den zwei unmodifizierten Geräten habe ich seither keinen einzigen Reset / Absturz mehr gehabt und die Aktoren laufen seit über 3 Monaten stabil durch. Die Aufhänger des Aktors mit Custom Firmware treten allerdings unverändert weiterhin häufig auf.
Meiner Meinung nach kann man diesen Punkt deshalb ausschließen.
Hi all,
ich habe auch 3 der Dinger mit der alternativen Firmware.
Vor 2 Wochen sind 2(!) in exakt dem gleichen Moment hängen geblieben.
Bevor jetzt wieder all C26 rufen:
Ich habe einen brandneuen HM-LC-sw1pbu-fm ebenfalls mit der alternativen Firmware bespielt und dort passierte sofort, exakt das gleiche.
Was sich im Setup geändert hat: es sind mehr HM-Devices dazu gekommen.
Ich habe herausgefunden, dass es wohl ein Timeout-Problem im Protokoll-Ablauf gibt.
In der Register.h der Firmware, wo man auch die HMID einstellt (sofern kein flashbarer Bootloader) wird eine Timeout-Zeit definiert:
const uint16_t timeOut = 700;
Diese habe ich auf 600 (ms) reduziert. Damit laufen die Schalter deutlich stabiler. Unter 500 (ms) stürzen die Dinger gleich wieder ab.
Es scheint also tatsächlich mit der Protokoll-StateMachine zusammen zu hängen. Keine Ahnung, ob sich da in FHEM was geändert hat, oder ob einfach der erhöhte Traffic das Problem ist.
Außerdem habe ich in der Nachbarschaft HMIP dazu bekommen ....
Ich hoffe das hilft.
LG