Dies ist eine kleine Zusammenfassung, wie man die Heizungsregler updated.
1) Firmware 1.0:
- Vorarbeit: Die akutelle update-Datei (hm_cc_rt_dn_update_V1_4_001_141020.eq3) ins FHEM-Verzeichnis kopieren.
- ZUERST an FHEM den Befehl
set <DEV> fwUpdate <hm_cc_rt_dn_update_V1_4_001_141020.eq3> <Delay> eingeben.
<Delay> ist die Zeit, die Du brauchst um an dem Regler den nächsten Punkt zu erledigen. Mindestzeit 10 (10 Sekunden).
- DANN Batterie am Regler raus (es reicht aus, eine Batterie zu entfernen), die beiden äußeren Knöpfe drücken, Batterie
wieder rein, "FUP" erscheint im Display.
Wenn nach kurzer Zeit ein Reset oder anderer Fehler kommt, hat es nicht geklappt. Dann nochmal.
Ab Firmware 1.1:
- Hier müssen die Batterien nicht entfernt werden. es reicht, den mittleren Knopf für 3 Sekunden zu drücken.
Sollte das nicht funktionieren, wie bei firmware 1.0 Batterien entfernen.
Danach die Devices aus FHEM löschen und neu anlernen, sonst stimmt die angezeigte Firmwareversion nicht
oder besser
System nach dem firmwareupdate komplett neu aufsetzen.
Selbst danach mußte ich 2 Regler noch mal komplett löschen und neu einlernen.
Diese beiden Regler habe ich durch Batterie entfernen geresettet. Beim Anlernen zeigten Sie dann immer noch F4, also habe ich den Batterie-Reset nochmal durchgeführt und dann noch über das Menü (Linke Taste lange drücken, mit Drehrad auf "res" drehen, mittlere Taste drücken, dann mit Drehrad auf "yes" drehen und mit mittlerer Taste bestätigen.
Vielleicht gehört dieser Beitrag nicht hierher, vielleicht kann jemand das WIKI ergänzen. Mich hat es viel Zeit gekostet das rauszukriegen.
Mit was hast du das Update gemacht? Mit einem HM-CFG-USB?
Ich habe vor kurzem alle meine RTs mit einem HM-CFG-USB-2 unter Windows auf Version 1.4 upgedatet.
Ich musste keine Devices löschen etc.
Damit bei meinen Devices die Versionsnummer korrekt ist, musste ich nur die Anlerntaste am Device drücken und danach in Fhem "save" klicken.
Habe alles so gemacht wie es im Wiki erklärt ist.
Ich habe mit meiner Fritzbox und Cul über FHEM das update gemacht.
(In FHEM bietet die Oberfläche ja sogar den Befehl fwUpdate an, wenn man das Device öffnet. )
Ich habe auch irgendwo gelesen, das man das Gerät neu anlernen muß / soll.
Natürlich habe ich erst mal so versucht (mit getconfig) .. hat aber bei mir nicht funktioniert.
LG Andreas
Zitat von: dancatt am 07 November 2014, 12:29:01
Ich musste keine Devices löschen etc.
Damit bei meinen Devices die Versionsnummer korrekt ist, musste ich nur die Anlerntaste am Device drücken und danach in Fhem "save" klicken.
Gleiche Erfahrung auch mit einer CUL und Update mit FHEM set <dev> fwUpdate.
Kein Löschen, Neuanlernen, etc nötig. Einzig _NACH_ dem Update 1x die Anlerntaste am RT-DN etwas länger drücken. Und save nicht vergessen :-)
ZitatAb Firmware 1.1:
- Hier müssen die Batterien nicht entfernt werden. es reicht, den mittleren Knopf für 3 Sekunden zu drücken.
selsbt das nicht nach dem Ppdatebefehl (OHNE Delay) in fhem legen meine sofort los und stehen auf update. nix knopf drücken
Zitat
Danach die Devices aus FHEM löschen und neu anlernen, sonst stimmt die angezeigte Firmwareversion nicht oder besser System nach dem firmwareupdate komplett neu aufsetzen.
nicht notwendig.
ZitatUnd save nicht vergessen :-)
was macht das und wo speichert man?
Zitat
selsbt das nicht nach dem updatebefehl in fhem legen meine sofort los und stehen auf update. nix knopf drücken
stimmt.... das fiel mir auch an einem auf - ich hatte verschiedene FW-Versionen bei den 13 Reglern.
ZitatEinzig _NACH_ dem Update 1x die Anlerntaste am RT-DN etwas länger drücken.
auch das ist nur notwendig, wenn man die neue firmwareversion in fhem angezeigt bekommen möchte. mittlerweile gibt es wohl auch bei einigen devices die funktion set getversion. konnte ich aber noch nicht testen.
mit getconfig bekommt man auch keine fw-version, ist aber vielleicht sinnvoll, da ein fw update andere werte gesetzt haben könnte.
Zitatauch das ist nur notwendig, wenn man die neue firmwareversion in fhem angezeigt bekommen möchte. mittlerweile gibt es wohl auch bei einigen devices die funktion set getversion.
geht bei diesem Regler aktuell nicht, hab es grade probiert.
Ich habe das jetzt bei meinen Reglern auch durch und vielleicht sollte man noch erwähnen, dass man in dem Fall, dass es abbricht nicht sofort nochmal (und am Ende immer wieder) probieren sollte, sondern erst einmal prüfen, ob der HM-CFG-USB vielleicht im Overload ist. Ist mir nämlich mehrfach so ergangen: Update bricht ab und Regler meldet CRC - war beim ersten mal ein ganz schöner Schreck, aber wenn man weiß, dass man einfach mal eine Weile warten muss (bei mir über eine halbe Stunde, da er immer wieder mit unterschiedlichem Fortschritt ins Overload kam), ist alles super...
HMinfo meldet für einen HM-CFG-USB2 nach einem FW-Update 264% ;)
IODevs:hmusb:opened pending=0 condition:ok
msgLoadEst: 1hour:264% 10min steps: 0/263/0/0/0/0
Zitat von: RoBra81 am 07 November 2014, 13:18:07sondern erst einmal prüfen, ob der HM-CFG-USB vielleicht im Overload ist. Ist mir nämlich mehrfach so ergangen: Update bricht ab und Regler meldet CRC
Deshalb mache ich die Updates immer über das Homematic Update Tool, da bekommt man nämlich für diesen Fehlerfall eine sinnvolle Fehlermeldung zurück ("duty cycle erreicht" oder so ähnlich) und weiss, was Sache ist.
schlussendlich ist die Lösung in beiden Fällen den HMUSB vor dem update einfach einmal zu ziehen und stecken. Die einzige Möglichkeit, das Problem zu lösen, falld der duty-cycle überschritten wird.
Die Berechnung in FHEM beim Update ist nicht korrekt, da die höhere Geschwindigkeit nicht berücksichtigt wird. HMUSB könnte somit 1000%
Zitat von: martinp876 am 09 November 2014, 09:34:05
schlussendlich ist die Lösung in beiden Fällen den HMUSB vor dem update einfach einmal zu ziehen und stecken. Die einzige Möglichkeit, das Problem zu lösen, falld der duty-cycle überschritten wird.
Offtopic:
Über diese 1%-Regel (22 Sekunden pro Stunde) kann ich nur den Kopf schütteln. So weit geht der Sender nun auch nicht dass es da ernsthaft Probleme gibt.
In meiner Nachbarschaft gibt es schon mal gar keine Homematic-Devices...
Oder von welcher Annahme ging die BNetzA da aus? Dass 1000 Leute in einer Turnhalle wohnen und alle auf 868 Mhz senden?
Bei mir ist nach ca. 3-4 Updates am RT erstmal der Duty Cycle erreicht...
Zitat(22 Sekunden pro Stunde)
ich dachte 1% von 3600s würde etwas anderes ergeben.
Nach mehreren erfolglosen Versuchen aus FHEM heraus, hatte ich letzten Endes mit der Linux-Variante wie unter http://www.fhemwiki.de/wiki/HomeMatic_Firmware_Update (http://www.fhemwiki.de/wiki/HomeMatic_Firmware_Update) vorgestellt Erfolg. Update von 1.1 auf 1.4 lief über CUL problemlos. Für einen HM CFG USB war ich zu geizig. :)
Zitat von: heikoh81 am 09 November 2014, 17:57:04
Offtopic:
Über diese 1%-Regel (22 Sekunden pro Stunde) kann ich nur den Kopf schütteln.
1% von einer Stunde = 36 Sekunden,
aber davon abgesehen: Ich staune, dass Homematic sich immer noch mit der 1% Regel rumschlagen muss, anstatt endlich einmal auf LBT umzustellen, wo man sich über duty-cycle keine Gedanken mehr zu machen braucht. Gerade bei der weiteren Verbreitung von OTA Updates wird doch das Problem immer gravierender.
Zitat von: betateilchen am 10 November 2014, 15:00:57
aber davon abgesehen: Ich staune, dass Homematic sich immer noch mit der 1% Regel rumschlagen muss, anstatt endlich einmal auf LBT umzustellen, wo man sich über duty-cycle keine Gedanken mehr zu machen braucht. Gerade bei der weiteren Verbreitung von OTA Updates wird doch das Problem immer gravierender.
Umstellung mal so eben? Wie ist es mit der installierten Basis und der Abwärtskompatibilät? Dann alle zig- oder hunderttausend bisher verkaufter HM Devices durch Neue ersetzten? Das schafft glückliche Käufer und Berge von nutzlosen Elektronikmüll. Technischer Fortschritt gut und schön - aber alle paar Jahre einen neuen Trend? Früher verbaute man Haustechnik (Lichtschalter etc) für eine Nutzungsdauer von (mehreren) 10 Jahren...
Wo ist das Problem bei OTA Updates? Wie oft macht man ein Firmware Update im Jahr? Außerdem wird da ja in den Fast Modus umgeschaltet, um die 1% Regel einzuhalten.
Nur meine zwei [OT] cent...
Zitat von: heikoh81 am 09 November 2014, 17:57:04
Bei mir ist nach ca. 3-4 Updates am RT erstmal der Duty Cycle erreicht...
5 Stück nach einander mit fhem updated ohne Probleme. Sollte man wirklich mal Probleme bekommen reicht es meine ich einmal fhem neu zu starten und der Counter ist zurückgesetzt
Hallo,
funktioniert so ein firmware upgrade auch mit dem HMLAN?
Grüße,
herrmie
Zitat
funktioniert so ein firmware upgrade auch mit dem HMLAN?
Soweit ich weiß nicht
Ich versuche mich auch am Update, bekomme das aber irgendwie nicht auf die Reihe.
Im Log staht fwUpdate: fail:Block1
Momentan ist V1.1 drauf. Ich verwende einen Raspberry Pi mit busware SCC. fhem ist auf dem neusten Stand.....
Kann mir jemand helfen?!
Hej TheME,
wenn du direkt in FHEM Probleme hast, dann verwende am besten flash-ota von:
https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb (https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb)
Dort bekommst du etwas mehr Output und im Problemfall konnte ich damit bislang immer noch meine RTs flashen. ;-)
Ich habe neulich einen RT-DN mit USB-CFG auf 1.4 geupdatet und ich meine ich hab das Gerät gar nicht angefasst. Weder Batterien raus noch einen Knopf gedrückt. Kann das sein? Ich sehe jetzt jedoch in fhem Version "1.4" in den Readings.
FHEM versucht das Device in den FUP-Modus zu bringen. Das funktioniert meines Wissens aber Version 1.1. Voraussetzung ist allerdings immer, daß burstRx = on für das Device gesetzt ist. Sonst empfängt der RT den Befehl zum Umschalten in den Firmware Update Modus nicht...
Tobias
Ja, das ist so, danke für die Aufklärung. Burst ist on und ich hatte vorher Version 1.1... Könnte man im ersten Post ergänzen, dass in diesem Fall das Gerät gar nicht angefasst werden muss.
Um das Update durchzuführen, musst du das nicht.
Aber um nach dem Update die Kalibrationsfahrt zu starten (und damit den RT wieder in den normalen Programmmodus zu versetzen), musst du sehr wohl auf den Knopf drücken... ebenso wie um anschließend die aktuelle Versionsnummer zu übermitteln.
Zitat von: Mr. P am 21 November 2014, 11:18:31
...
wenn du direkt in FHEM Probleme hast, dann verwende am besten flash-ota
...
Habs eben versucht, und davor auch noch den
burstRx auf
on gesetzt - klappt leider auch nicht.
Bekomme mit hmcfgusb folgenden Output:
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!Hatte zwischenzeitlich auch noch die FW vom SCC upgedatet (von 1.60 auf 1.61), aber das hat ja leider auch nix gebracht....
Dann gibt es natürlich noch die Möglichkeit, dass du das Gerät zu weit weg oder auch zu nah zum SCC aufgestellt hast.
Hat es hier alles schon gegeben. :-)
Zitat von: Mr. P am 23 November 2014, 11:31:24
Dann gibt es natürlich noch die Möglichkeit, dass du das Gerät zu weit weg oder auch zu nah zum SCC aufgestellt hast.
Hat es hier alles schon gegeben. :-)
Hatte das auch schon gelesen und diverse Entfernungen von 1m bis 5m probiert, aber leider ebenfalls ohne Erfolg :(
Hatte das Update auch mit einem 2. HM-CC-RT-DN probiert. Dieser wurde mit v1.3 geliefert. Leider mit dem gleichen Problem....
Zitat von: TheME am 23 November 2014, 17:24:08
Hatte das auch schon gelesen und diverse Entfernungen von 1m bis 5m probiert, aber leider ebenfalls ohne Erfolg :(
Ich dachte eher an ~10m oder zumindest eine schöne dicke Wand zwischen den beiden Komponenten.
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
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://forum.fhem.de/index.php/topic,28810.msg222164.html#msg222164)
http://www.fhemwiki.de/wiki/HomeMatic_Firmware_Update (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
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.
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.
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 1ad 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
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....?
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?
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?
HomeMatic OTA flasher version 0.097-git
ist wohl auch nicht das neueste.
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
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) (http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/) klappte das FW-Update des HM-CC-RT-DN auf Anhieb ohne Probleme.
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
mach ein fw-check und klicke auf den changelog link. ;)
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
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.
ZitatDas mit dem changelog-link ist schwierig da gerade die downloads-Seite von eq-3 nicht erreichbar ist. Schon seit gestern....
nö, der fw-check geht trotzdem, obwohl die seite nicht erreichbar ist. auch die generierten changelog/download links. :)
Changelog:
Version 1.4.001 - 14/10/20
--------------------------------------------------------------
** Bug
* Modification the radio data interpretation function, if check for CONFIG_SERIALNUMBER it is also necessary to
check the frame typ for FRAME_CONFIGURATION.
* Modification the direct link button-switch profile.
Version 1.3.001 - 14/04/24
--------------------------------------------------------------
** Bug
* Change in config_rt(...,...), parameter configuration is start at parameterposition 20.
The weekly program transfer to the partner was incorrect if the first timestep > 21:15 o'clock
* If party-mode bring into action, always the long status-message is send out instead of the
short status-message. The party-temperature is add as last byte at the long status-message.
Version 1.2.007 - 13/12/02
--------------------------------------------------------------
** Bug
* If all shutter-contacts cleared from device and window-open-temperature is active, temperature return from
window-open-temperature to old temperature.
* Internal window-open detection, send to partners.
* Central-Order "Boost", "Comfort", "Lowering", "Change Temperature" still running, if Party-Pre-Stage is active.
** ChangeRequest
* The operation mode still shows in lcd if a thermal control is known.
Version 1.1.001 - 13/09/16
--------------------------------------------------------------
** Bug
* Correction at takeover the actualtemperature and the settemperature, high-byte shift was not correct.
* Correction at takeover ccu-radio-order, if internal window-open is detected, it has to reset.
* Correction by the radio synchronization, if a thermal control is known, the device must synchronize to the
radio-datapacket actual/set-temperature.
Zitat von: MarcelK am 10 Februar 2016, 12:14:18
Nein, HMLAN kann das generell nicht.
Mit einem CUL geht das? Ich habe hier noch einen CC1101-USB-Lite 868 MHz ungenutzt rumliegen den ich dafür verwenden könnte.
Zitat von: laurine am 11 Februar 2016, 19:48:40
Mit einem CUL geht das? Ich habe hier noch einen CC1101-USB-Lite 868 MHz ungenutzt rumliegen den ich dafür verwenden könnte.
Zumindest ist es --> hier --< (http://www.fhemwiki.de/wiki/HomeMatic_Firmware_Update) beschrieben.
Peter