HM-CC-RT-DN firmware update durchführen

Begonnen von Andreas_, 07 November 2014, 11:55:38

Vorheriges Thema - Nächstes Thema

wkarl

Hallo,

ich hänge mich mal hier mit rein. Nachdem ich den HMUSB bekommen und in fhem integriert habe, standen die ersten Updates an. Das Update der Dokumentation nach angestoßen erscheint auf dem DN die Anzeige FUP. Nach der typischen Initialisierungsprozedur (INS, ADA) war der DN wieder zurück und kommuniziert mit fhem problemlos. Allerdings zeigt er als FW-Version immer noch die 1.0. Auch nach einem 'clear readings' und erneutem 'getConfig'.

Kann man explizit irgendwie die FW auslesen?

ciao walter
FHEM 5.7 & TabletUI 2.2 auf Fedora22 Server auf NUC5i5RYK
CUL 868 > FAST EnergyCam
HMLAN > HomeMatic TCs & VDs, Bewegungsmelder, Schalter, Taster, Steckdosen

tpm88

Hallo Walter,

das steht u.a. ca 3 Posts weiter oben und im Wiki...
http://forum.fhem.de/index.php/topic,28810.msg222164.html#msg222164
http://www.fhemwiki.de/wiki/HomeMatic_Firmware_Update

getConfig liest zumindest beim RT-DN _NICHT_ die neue FW-Version. Du mußt nach dem Update die mittlere Taste etwas länger (3sec +) drücken, wie wenn Du den RT-DN in den Pairing-Modus bringen möchtest. Dann überträgt das Thermostat von sich aus die FW-Version an FHEM.

Gruß
Tobias
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

blu

#32
Hallo zusammen,

bei zwei meiner drei HM-CC-RT-DN habe ich die Firmware via CUL geupdatet, eines von 1.0, das andere von 1.3 auf 1.4.
Das dritte HM-CC-RT-DN (aktuell 1.3) bricht mit einem CRC-Fehler auf dem Display ab. In der Logdatei steht:
pi@raspyFHEM /opt/fhem $ tail -15 ./log/wz.heizungL-2015.log
2015-01-05_23:06:56 wz.heizungL set_fwUpdate hm_cc_rt_dn_update_V1_4_001_141020.eq3 30
2015-01-05_23:08:15 wz.heizungL fwUpdate: fail:Block84
2015-01-05_23:08:15 wz.heizungL CMDs_done_FWupdate
2015-01-05_23:14:55 wz.heizungL CMDs_FWupdate

wobei das Update die Fehler immer in unterschiedlichen Blöcken meldet. FHEM habe ich neu gestartet, um der 1%-Regel vorzubeugen - daran kann es also nicht liegen.
In den Readings des Unglücks-RT fiel mir auf, dass "R-pairCentral   0x272727" nicht wie bei den anderen Devices gesetzt ist. Kann es daran liegen? Und falls ja, wie paire ich das RT neu?
Ein "set wz.heizungL pair" hat nicht geholfen.
Danke für Tipps, gerne liefere ich evtl. benötigte Details nach.
lg blu
ps Auszug aus der opt/fhem/log/fhem-2015-01.log:
2015.01.05 23:06:56.801 2: CUL_HM fwUpdate started for wz.heizungL
2015.01.05 23:06:56.823 3: CUL_HM set wz.heizungL fwUpdate hm_cc_rt_dn_update_V1_4_001_141020.eq3 30
2015.01.05 23:07:04.617 2: CUL_HM fwUpdate wz.heizungL entered mode. IO-speed: fast
2015.01.05 23:08:15.060 2: CUL_HM fwUpdate wz.heizungL end. IO-speed: normal

edit: gerade noch entdeckt:
tail -500 ./log/fhem-2015-01.log | grep WARNING
2015.01.05 22:51:01.589 1: PERL WARNING: Use of uninitialized value $mNo in sprintf at /opt/fhem/FHEM/10_CUL_HM.pm line 5429.
2015.01.05 23:01:47.794 1: PERL WARNING: Use of uninitialized value $mNo in sprintf at /opt/fhem/FHEM/10_CUL_HM.pm line 5429.
2015.01.05 23:56:50.450 1: PERL WARNING: Use of uninitialized value in string eq at /opt/fhem/FHEM/10_CUL_HM.pm line 7000.
RasPi2, FHEM 5.6, HM-LAN-CFG
HM-CC-RT-DN, HM-LC-SW1-FM, HM-LC-SW1-PL2, HM-LC-Sw1PBU-FM, HM-Sen-MDIR-O,  HM-SEC-SCo, HM-PB-2-WM55-2, HM-PB-6-WM55, HM-ES-TX-WM (+ Ferraris)

Mr. P

Zitat von: blu am 06 Januar 2015, 00:03:34
Das dritte HM-CC-RT-DN (aktuell 1.3) bricht mit einem CRC-Fehler auf dem Display ab.
Hej blu,
gepairt braucht der RT für das FW-Update nicht sein.
Wenn zwei deiner drei RTs durchlaufen, kann man den CUL schon mal als Fehlerquelle ausschließen. Und da das Update anläuft, würde ich auch ein grundsätzliches Problem beim dritten RT ausschließen.

An der Stelle gibt es jetzt drei Möglichkeiten:
1) Logge einmal die Raw-Messages mit und poste sie hier,
2) wie groß ist der Abstand zwischen CUL und RT? Wenn dieser zu gering oder zu groß ist, kann das zu Problemen führen oder
3) du probierst einmal mit dem flash-ota Tool zu flashen. Das ist (oder zumindest war - kann sich mittlerweile auch schon geändert haben) etwas umgänglicher mit Übertragungsfehlern und du siehst eben auch sehr gut, ob Pakete nicht vom RT bestätigt werden können und es deshalb nicht klappt.

Beim Versuch mit der alternativen Software diese aber entweder auf einem anderen Computer mit dem CUL ausführen oder FHEM vorher beenden, wenn es das selbe Device ist, auf dem deine Steuerung läuft.
Greetz,
   Mr. P

blu

Zitat von: Mr. P am 06 Januar 2015, 00:51:44
1) Logge einmal die Raw-Messages mit und poste sie hier,
2) wie groß ist der Abstand zwischen CUL und RT? Wenn dieser zu gering oder zu groß ist, kann das zu Problemen führen oder
3) du probierst einmal mit dem flash-ota Tool zu flashen.
Hi,
und vielen Dank für deine Hinweise.
ad 1) Zunächst habe ich in der /opt/fhem/fhem.cfg die raw messages aktiviert
attr addvaltrigger rawmsg 1
ad 2) Dann das Ventil ausgebaut und zwei Stockwerke hoch neben den CUL transportiert und das FW-Update erneut angestoßen und siehe da: es funkionierte :-)

3) habe ich dann nicht mehr ausprobiert. Auf Wunsch kann ich die Logs noch nachreichen, wird ws. nicht nötig sein. Hätte nicht gedacht, dass der Abstand die Fehlerursache ist, denn das Update auf dem zweiten Wohnzimmerthermostat (1 m daneben) hat sofort geklappt...

Danke für die Hilfe  :)
LG blu
RasPi2, FHEM 5.6, HM-LAN-CFG
HM-CC-RT-DN, HM-LC-SW1-FM, HM-LC-SW1-PL2, HM-LC-Sw1PBU-FM, HM-Sen-MDIR-O,  HM-SEC-SCo, HM-PB-2-WM55-2, HM-PB-6-WM55, HM-ES-TX-WM (+ Ferraris)

TheME

Servus,

muss leider das Thema nochmals hervorholen....

Bin leider immernoch nicht im Stande mein hm-cc-rt-dn von FW1.1 zu aktualisieren....

Habs in FHEM mit
set  CUL_HM_HM_CC_RT_DN_255130 fwUpdate /opt/fhem/HM_Upd/hm_cc_rt_dn_update_V1_4_001_141020.eq3

angestoßen (testweise auch mit verschiedenen Time-Werten) und bekomme dann folgendes im Eventviewer:

2016-01-20 18:02:37 CUL_HM CUL_HM_HM_CC_RT_DN_255130 CMDs_FWupdate
2016.01.20 18:02:37 2 : CUL_HM fwUpdate started for CUL_HM_HM_CC_RT_DN_255130
2016-01-20 18:02:37 CUL_HM CUL_HM_HM_CC_RT_DN_255130 set_fwUpdate /opt/fhem/HM_Upd/hm_cc_rt_dn_update_V1_4_001_141020.eq3 10
2016.01.20 18:02:37 3 : CUL_HM set CUL_HM_HM_CC_RT_DN_255130 fwUpdate /opt/fhem/HM_Upd/hm_cc_rt_dn_update_V1_4_001_141020.eq3 10
2016.01.20 18:02:38 2 : CUL_HM fwUpdate CUL_HM_HM_CC_RT_DN_255130 entered mode. IO-speed: fast
2016-01-20 18:03:09 CUL_HM CUL_HM_HM_CC_RT_DN_255130 fwUpdate: fail:Block1
2016-01-20 18:03:09 CUL_HM CUL_HM_HM_CC_RT_DN_255130 CMDs_done_FWupdate
2016.01.20 18:03:09 2 : CUL_HM fwUpdate CUL_HM_HM_CC_RT_DN_255130 end. IO-speed: normal


Habe auch verschiedene Abstände (1m, 2m, 5m, 7m) probiert, immer das gleiche Ergebnis....
Im Display des Thermostats erscheint FUP, und nach kurzer Zeit startet er wieder 'normal', mit Anzeige der alten Firmware 1.1.

Bei mir läuft fhem auf einem RaspberryPi und busware SCC v1.0 mit aktueller FW1.61. fhem ist natürlich auch aktuell.

Habs dann auch mal per Putty mit dem CUL/HM-CFG-USB-Tool probiert:
sudo ./flash-ota -c /dev/ttyAMA0 -f hm_cc_rt_dn_update_V1_4_001_141020.eq3 -s KEQ1039298

Bekomme dann folgenden Output:

HomeMatic OTA flasher version 0.097-git

Reading firmware from hm_cc_rt_dn_update_V1_4_001_141020.eq3...
Firmware with 234 blocks successfully read.
Opening culfw-device at path /dev/ttyAMA0 with speed 38400
Requesting firmware-version
culfw-device firmware version: 1.61
Entering 10k-mode
Waiting for device with serial KEQ1039298
Device with serial KEQ1039298 (hmid: 255130) entered firmware-update-mode
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?

Missing ACK!

Missing ACK!

Missing ACK!

Missing ACK!
No!
Entering 10k-mode
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?

Missing ACK!

Missing ACK!

Missing ACK!

Missing ACK!
No!
Entering 10k-mode
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?

Missing ACK!

Missing ACK!

Missing ACK!

Missing ACK!
No!
Entering 10k-mode
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?

Missing ACK!

Missing ACK!

Missing ACK!

Missing ACK!
No!
Entering 10k-mode
Too many errors, giving up!


Kann es sein, dass FWupdate mit dem busware_scc garnicht möglich ist oder mache ich irgendwo einen Fehler....?

TheME

Zitat von: TheME am 20 Januar 2016, 18:26:25...
Bin leider immernoch nicht im Stande mein hm-cc-rt-dn von FW1.1 zu aktualisieren....
....

Hat niemand einen Tip oder kann sagen ob es mit dem busware SCC funktioniert?

frank

Entering 10k-mode
Waiting for device with serial KEQ1039298
Device with serial KEQ1039298 (hmid: 255130) entered firmware-update-mode
Initiating remote switch to 100k
Entering 100k-mode

im 10k mode scheint alles zu funktionieren. nach dem umschalten in den 100k mode passiert nichts mehr.
ich tippe auf die fw vom scc. unterstützt sie den 100k mode?
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

frank

HomeMatic OTA flasher version 0.097-git
ist wohl auch nicht das neueste.
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

martinp876

Die fw 1.1 ist zickig. Die kann nicht remote gestartet werden. Hier muss die Zeit mit angegeben werden, am Ende des Kommandos. Dann wartet fehm auf die messages von RT. Nun muss innerhalb der Zeit der RT in den bootmode gebracht werden, mit drücken von 2 tasten, wenn ich mich recht erinnere.dann sollte es klappen. Nicht zu nahe an die cul legen, mindnestabstand

TheME

Hi.
Habe nun die Lösung gefunden:

Fehler lag in der culfw-Firmware 1.61.
Nach einem Update der culfw auf den aktuellen Stand (1.66) klappte das FW-Update des HM-CC-RT-DN auf Anhieb ohne Probleme.

laurine

Moin zusammen,

bei mir laufen 5 Stk. CC-RT-DN an einen HMLAN mit Fhem auf einem Synology. Die CC-RT-DN sind schon was älter, haben alle noch FW 1.0 drauf. Kann ich die mit fhem und dem HMLAN updaten? Also die Fw meine ich. Welche Vorteile bringt das?

Danke,
laurine

frank

mach ein fw-check und klicke auf den changelog link.  ;)
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

laurine

Zitat von: frank am 10 Februar 2016, 10:11:24
mach ein fw-check und klicke auf den changelog link.  ;)
Das mit dem changelog-link ist schwierig da gerade die downloads-Seite von eq-3 nicht erreichbar ist. Schon seit gestern.... 
Mein Frage zielte aber darauf ab, ob jemand direkt "hier" ruft und sagt, weshalb es besonders wichtig ist die fw zu aktualisieren.

weshalb fw-check? ICh weiß doch, dass die bei mir alt ist.

Kann man die FW der cc rt dn mit dem HMLAN aktualisieren?

Gruß, laurine

MarcelK

Zitat von: laurine am 10 Februar 2016, 12:12:37
Kann man die FW der cc rt dn mit dem HMLAN aktualisieren?
Nein, HMLAN kann das generell nicht.