Neue Firmware Homematic Thermostat HM-CC-RT-DN v1.5 und HM-TC-IT-WM-W-EU v1.4

Begonnen von hoppel118, 10 November 2018, 23:37:28

Vorheriges Thema - Nächstes Thema

hoppel118

Tolle Sache! Dann werde ich mich bei Gelegenheit auch mal damit beschäftigen.

Danke für die Info!

Gruß Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

vbs

Also bei mir hat sich das Verhalten so geändert, dass das Ding erstmal gar nix mehr macht... Das Firmware-Update ist wohl fehlschgeschlagen. Der DN zeigt beim Booten sofort "FUP" and und dann wechselt er nach ein paar Sekunden auf "CrC". Laut Handbuch soll man dann das Firmware-Update nochmal machen. Klappt aber nicht...

Ich rufe es auf mit (wie beim ersten Mal)

set wz_hmRt fwUpdate FHEM/firmware/hm_cc_rt_dn_update_V1_5_003_171004.eq3


Das Log sagt dann nur:
2018.12.06 20:34:14.643 2 : CUL_HM fwUpdate started for wz_hmRt
2018.12.06 20:34:14.646 3 : CUL_HM set wz_hmRt fwUpdate FHEM/firmware/hm_cc_rt_dn_update_V1_5_003_171004.eq3
2018.12.06 20:34:24.651 2 : CUL_HM fwUpdate wz_hmRt end. IO-speed: normal


Hab auch schon versucht, beim Batterien einlegen die beiden äußeren Tasten zu drücken und dann direkt das Update anzustoßen. Aber leider auch ohne Erfolg. Beschreibung von hier:
https://homematic-forum.de/forum/viewtopic.php?t=45499
https://www.elv.de/topic/heizkoerperthermostat-hm-cc-rt-dn-firmwareupdate.html

Ich hab auch schon versucht, wieder die 1.4 zu flashen, aber gleiches Ergebnis.

Ich habe momentan einen MapleCUL mit HM-MOD-UART, aber ein HM-CFG-USB hätte ich auch noch... Hat noch jemand eine Idee, wie ich das Ding wieder zum Leben erwecken könnte?

vbs

Mit dem Homematic Flasher Tool hat es dann noch auf Anhieb geklappt... ist offenbar doch immer gut den HM-CFG-USB noch da zu haben für solche Fälle...

vbs

Vielleicht stell ich mich ja zu dusselig an, aber das FW-Update per HM-MOD-UART über FHEM hat dreimal von dreimal nicht funktioniert (beim RT-DN). Musste jedes Mal hinterher mit dem HM-CFG-USB und dem Windows-Tool ran.
TC flashen ging jedoch zweimal problemlos per FHEM.

Hinterher neu pairen nicht vergessen, damit FHEM die neue FW-Version mitbekommt.

frank

ZitatHinterher neu pairen nicht vergessen, damit FHEM die neue FW-Version mitbekommt.
du musst nur den "countdown" am device starten, also eine anlernmessage senden. pairen ist nicht nôtig.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

hoppel118

#35
Wenn ich die Updates mache, dann sowieso per HM-CFG-USB-2.

Zitat von: frank am 06 Dezember 2018, 21:27:27
du musst nur den "countdown" am device starten, also eine anlernmessage senden. pairen ist nicht nôtig.

Wie macht man das? Der einzige Countdown, den ich kenne, erscheint nach dem Einlegen der Batterien.

Gruß Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

vbs

Den Boost-Button für 5 Sek. gedrückt halten. Also genau so, als wenn du das Pairen starten würdest (nur eben ohne die Zentrale in den Pairing-Modus zu setzen).

hoppel118

Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

Beta-User

Zitat von: vbs am 06 Dezember 2018, 21:16:09
Vielleicht stell ich mich ja zu dusselig an, aber das FW-Update per HM-MOD-UART über FHEM hat dreimal von dreimal nicht funktioniert (beim RT-DN).
Habe nicht ganz dieselbe Bilanz bisher (CUL_HM mit VCCU:HMUART,CUL,MapleCUL@STACKABLE):
Ein TC ging problemlos, danach noch 2 RT's. Danach habe ich kurz gezögert (eigentlich ist klar, dass mehr wie 2-3 updates pro Stunde nicht drin sind bzw. dazu führen, dass die VCCU auf ein anderes IO wie den HMUART (Pi-PCB an USB) ausweicht) => CrC-Fehler bei zwei weiteren.
Den einen habe ich heute morgen reanimiert, dann einen weiteren angeschubst => CrC beim dritten (war aber auch wieder mit FHEM-Bordmitteln zu reanimieren, mehrfach "clear all" + Batterie raus + äußere Tasten beim Wiedereinsetzen, kurz Warten + set ...fwUpdate ...). Einer ist jetzt noch auf CrC, der kommt dann heute abend dran (ist auch eher am äußeren Ende der Funkstrecke, -70@HMUART, werde den also erst mal abschrauben).

Fazit: nie mehr wie 2 Updates pro Stunde und immer sicherstellen, dass das update auch wirklich komplett durchgelaufen war. Wenn zuviel Traffic drumrum ist, geht es gerne schief ::) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

vbs

Hm, scheint sich bei mir etwas anders zu verhalten tatsächlich. Bei mir gingen alle 3 DN-RT schief und kein einziger TC (von 2). Angefangen hab ich mit einem DN-RT, also da war nichts überlastet.
Wiederum mit dem HM-USB-CFG und dem Homematic Windows Tool konnte ich dann unter gleichen Bedingungen alle 3 DN-RTs am Stück flashen ohne ein Problem.

Also ich denke nicht, dass es bei mir etwas mit Überlast/Traffic zu tun hatte. Irgendwas scheint FHEM anders zu machen als das Windows-Tool. So sieht es für mich zumindest aus.

Beta-User

Was letztlich das Problem ist? Keine Ahnung, vielleicht ist auch der Pi (unter bestimmten Rahmenbedingungen zum Teil) zu langsam?
Bei dem diffusen Bild sieht es mir danach aus, als gäbe es nicht DIE Ursache, sondern mehrere Einflüsse, die gerne zum Zusammenbruch des Systems führen. Die RT's (und v.a. die Rolladenaktoren) sind nach meiner Erfahrung auch besonders empfindlich.

Das Windows-Tool hat dann auch "nur" 3 updates gemacht - wie gesagt, die ersten drei gingen bei mir in FHEM auch reibungslos, erst danach wurde es (erwartungsgemäß...) doof. Das mit den 3 updates ist ein persönlicher Erfahrungswert, den ich mitteilen wollte, aber keine naturwissenschaftliche Erkenntnis :) . Wer also jetzt das WE Zeit hat, mag es beachten oder eben auch nicht...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Jamo

Ich hatte auch die CRC Fehler, letztendlich geholfen hat, das ich HM-CC-RT-DN vom Heizkörper abgeschraubt habe, und 1 meter neben den HM-CFG-USB gelegt habe,
ansonsten ist die Funkstrecke zu gross (zu viele Wände dazwischen). Wenn man einen Laptop hat, kann man natürlich damit auch zum Heizkörper laufen.
Die HM-TC-IT-WM-W-EU habe ich dann auch neben den PC gelegt um das FW update zu machen.

Wenn man den CRC Fehler im Display hat, einfach das FW-update nochmal anschubsen, also die beiden äusseren Tasten gleichzeitig drücken, und dann die Batterie wieder einlegen, bis das FUP erscheint.

Überlast hatte ich auch, dann muss man den HM-CFG-USB einmal vom PC abziehen (stromlos machen), danach gehts direkt wieder.

Ich habe für 5 HM-TC-IT-WM-W-EU und 6 HM-CC-RT-DN etwa 45 minuten gebraucht, mit an-und abschrauben, und nachher wieder die Adaptierfahrt.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Beta-User

@inoma:
Das war FHEM-seitig durchgeführt, oder war das auch mit dem von vbs benutzten Windows-Tool?

Danke jedenfalls für die Bestätigung des Erfahrungswerts, dass ca. 3 updates das Funkbudget soweit ausschöpfen, dass man danach warten oder anderweitig für Reserven sorgen muß. (Mein Pi-HM-PCB steckt am internen USB-Anschluß, das Gehäuse wollte ich nicht extra öffnen, da warte ich lieber immer mal wieder ;D ).

Allgemeine Anmerkung noch: Zu nah' kann auch ein Problem sein; nach meiner Erfahrung sind einige Meter und eine Wand (beim Pi-PCB und auch beim CUL mit externer Antenne - ja, auch damit habe ich schon erfolgreich in der Vergangenheit updates gemacht!) gar nicht sooo schlecht, am meisten Probleme machten z.B. (mind. beim Pairen) der RT und die FK's im selben Raum wie der Server (2-4m Luftlinie) und der direkt nebenan (~2m+ eine Wand).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

vbs

Bei meinen erfolgreichen RT-Flashes mit Windows-Tool hatte ich nur ungefähr 1 m Abstand zwischen RT und HM-CFG-USB (ohne Wand).

Newbie

Hallo Gemeinde,

hab hier auch einige Thermostate geupdatet, bei 3 ging es schief (CRC). Bei mir funktionierte es dann mit der optionalen waittime im SET-Befehl. Aber musste mindestens 20sec sein (bei ca. 18sec die mittlere Taste am Thermostat kurz gedrückt, so das statt CRC FUP im Display steht), bei weniger als 20sec immer Abbruch vom Update.
fhem-6.1 (configDB+DbLog)  auf ODROID-XU4