Abgezweigt aus diversen anderen Homematic-Threads, hier mal der "Forschungsthread" zu den OTA Updates, die CCU2 an bestimmte Homematic Komponenten ausliefern kann.
Damit verknüpft sich natürlich auch die Frage/das Ziel, solche Updates vielleicht irgendwann per fhem durchführen zu können.
Aktueller Stand:
1. Geräte, für die ein OTA Update derzeit vorgesehen/möglich ist:
- Heizungsregler HM_CC_RT_DN
- Regensensor HM-SEN_RD_O
2. Technische Möglichkeiten, die auf CCU2 verfügbar sind:
- SSH Zugang ist vorhanden
- strace ist auf der CCU2 installiert
Hier die aktuelle Prozessliste einer laufenden CCU2:
# ps
PID USER COMMAND
1 root init
2 root [kthreadd]
3 root [ksoftirqd/0]
5 root [kworker/u:0]
6 root [rcu_kthread]
7 root [khelper]
8 root [kdevtmpfs]
9 root [netns]
10 root [sync_supers]
11 root [bdi-default]
12 root [kintegrityd]
13 root [kblockd]
14 root [rpciod]
15 root [kworker/0:1]
16 root [kswapd0]
17 root [fsnotify_mark]
18 root [nfsiod]
19 root [crypto]
24 root [mtdblock0]
25 root [mtdblock1]
26 root [mtdblock2]
27 root [mtdblock3]
28 root [mtdblock4]
29 root [mtdblock5]
30 root [mtdblock6]
31 root [mtdblock7]
32 root [ubi_bgt0d]
33 root [ubi_bgt1d]
34 root [kworker/u:1]
37 root [deferwq]
38 root [devfreq_wq]
43 root [ubifs_bgt1_0]
82 root [eq3spi.0]
89 root [file-storage]
92 root [khubd]
95 root /usr/sbin/crond
99 root /sbin/syslogd -m 0
101 root /sbin/klogd
104 root /lib/udev/udevd -d
113 root watchdog -t 30 /dev/watchdog
128 root udhcpd -S /etc/udhcpd.usb0.conf
138 root /lib/udev/udevd -d
139 root /lib/udev/udevd -d
254 root udhcpc -x hostname homematic-ccu2 -V eQ3-CCU2 -b -s /bin/dhcp.sc
260 root /usr/sbin/ifplugd -i eth0 -fI -u0 -d10
288 root /bin/eq3configd
289 root /bin/ssdpd
299 root ntpclient -h ntp.homematic.com -l
305 root /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
337 root /bin/rfd -d -f /etc/config/rfd.conf -l 5
347 root java -Xmx32m -Dlog4j.configuration=file:///etc/config/log4j.xml
384 root /bin/ReGaHss -f /etc/rega.conf -l 2
388 root /bin/hss_led
450 root /sbin/getty -L ttyAMA0 115200 vt100
451 root /sbin/getty -L ttyGS0 115200 vt100
481 root [kworker/0:2]
530 root /usr/sbin/sshd
540 root {sshd} sshd: root@pts/0
545 root -sh
663 root ps
Hat jemand eine Idee, welches der eigentlich relevante Prozess sein könnte?
Hat jemand eine Idee, wofür die anderen Prozesse (288-388) sind?
288 root /bin/eq3configd
289 root /bin/ssdpd
299 root ntpclient -h ntp.homematic.com -l
305 root /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
337 root /bin/rfd -d -f /etc/config/rfd.conf -l 5
347 root java -Xmx32m -Dlog4j.configuration=file:///etc/config/log4j.xml
384 root /bin/ReGaHss -f /etc/rega.conf -l 2
388 root /bin/hss_led
Mal zum "Ausblenden":
289: ssh-Deamon
299: ntpClient zum Zeiteinstellen (holt sich Zeit von ntp.homematic.com)
305: lighttpd: Webserver, alternative zu apache
der rest ... ???
Zitat von: Wernieman am 30 Januar 2014, 14:49:16
289 root /bin/ssdpd
289: ssh-Deamon
das glaubst Du doch selbst nicht, oder?
Der SSH-Dämon läuft als 530 und heißt auch sshd (und nicht ssdpd)
288 root /bin/eq3configd
337 root /bin/rfd -d -f /etc/config/rfd.conf -l 5
347 root java -Xmx32m -Dlog4j.configuration=file:///etc/config/log4j.xml
384 root /bin/ReGaHss -f /etc/rega.conf -l 2
388 root /bin/hss_led
rfd: Ist der Dienst der per XML-RPC die HM-RF Kommunikation abwickelt. Also der Homematic-Funk Software Layer
ReGaHss: Ist die Logic-Schicht. Der CCU. Also alles was das UI der CCU Logisch macht.
hss_led: Das ist der Dienst der die LED- und Taster der CCU2 ansprechbar macht.
Gruß
Dirk
@betateilchen
Ups .. da war ich mal wider "Betriebsblind" sorry
Wollte eigentlich schreiben:
SSDP (Simple Service Discovery Protocol)
http://de.wikipedia.org/wiki/SSDP
Habe beim schreiben zu sehr weitergedacht :o(
@Dirk danke :)
(Taster hab ich übrigens an der CCU2 noch keine entdeckt, ich hab sie aber noch nicht aufgeschraubt)
Das heißt, rfd und ReGaHss dürften vermutlich die zwei Dinge sein, die uns am meisten interessieren.
Stimmt, Taster hat nur die CCU1.
ZitatDas heißt, rfd und ReGaHss dürften vermutlich die zwei Dinge sein, die uns am meisten interessieren.
Korrekt.
Wenn der Firmwareupdate etwa vergleichsweise wie bei HM-Wired funktioniert, Dann wird die Firmware Byteweise in den normalen Messages zum Device geschickt.
Und dafür ist rfd zuständig.
Update:
Link gelöscht. Ist wohl nur für registrierte Benutzer sichtbar.
Moin,
Zum verifizieren kann man auch lsof verwenden. Es zeigt alle Handels aller Prozesse an. Da kannst du dann sehen welche pid das device geöffnet hat.
Gruß
Jan
@Dirk,
die normalen messages scheinen es nicht zu sein. Diese könnten wir ja sonst mit einem "monitor HMLAN" sniffen. Das ist schon versucht worden. Es kam die Message "enter boot loader" dann war Schluss. Die Messages sind also zumindest modifiziert.
Denkbar ist, dass zum Update einiges umgeschaltet wird - so die Übertragungsgeschwindigkeit (weniger pausen), die message länge, der Overhead. Könnte sein, dass ein neuer Process für den Update gestartet wird - oder die sonstige Verarbeitung gestoppt wird.
eQ3 muss bei dieser unüblichen Datenmenge und dem sonstigen Verkehr in der Luft die Geschichte zügig und sicher über die Bühne geht. Es besteht eh die Frage was passiert, sollte der update unterborchen werden. kann das Device dann auf die alte Load zurückfallen und man darf noch einmal probieren?
netstat sollte die Kommunikationspfade beschreiben - aber wenn sie möglicherweise transient sind kann man sie vorher und nacher nicht sehen.
Es kommt auf den ersten Test an.
Interessant wäre vorab einfach einmal den normalen traffic zu tracen - wenn das klappt und der update den gleichen Pfad nimmt/process nutzt können wir ansetzen
Gruss Martin
Interessant finde ich, dass es zwei unterschiedliche Updateverfahren für HM-Geräte gibt: Der RT muss manuall in den Update-Modus geschaltet werden, der Regensensor aber nicht. Die Übertragung der Firmware zum Regensensor hat relativ lange gedauert (mindestens eine Minute), der Sensor hat dabei munter vor sich hingeblinkt. Ich gehe davon aus, dass die neue Firmware nicht sofort geschrieben wird, sondern erst komplett übertragen, dann geprüft und dann das Update stattfindet.
So funktioniert das auch bei der CCU2: Erst wird die Firmware auf die CCU2 hochgeladen, dann muss das eigentlich Update als nächster Schritt explizit gestartet werden. Sollte bei der Übertragung zur CCU2 etwas schiefgehen, wird das als Fehler gemeldet.
Zitat von: martinp876 am 30 Januar 2014, 19:46:50
die normalen messages scheinen es nicht zu sein. Diese könnten wir ja sonst mit einem "monitor HMLAN" sniffen. Das ist schon versucht worden. Es kam die Message "enter boot loader" dann war Schluss. Die Messages sind also zumindest modifiziert.
Also war das eine falsche Vermutung.
ZitatDenkbar ist, dass zum Update einiges umgeschaltet wird - so die Übertragungsgeschwindigkeit (weniger pausen), die message länge, der Overhead.
Das würde ich dann auch sagen. Wenn, so wie betateilchen beschreibt, der Updateprozess relativ lange dauert, dann ist auch denkbar, dass das auf einer anderen Frequenz im 868 Mhz-Bereich stattfindet. Nämlich auf einer, auf der länger gesendet werden darf.
Hat schon mal jemand versucht während dem Update mit einem SDR o.ä. zu schauen ob die Übertragung während des Updates ggf. auf einer anderen Frequenz stattfindet?
Dann könnte man den CUL entsprechend umstellen und mitlauschen.
Zitat von: betateilchen am 30 Januar 2014, 20:13:26
Ich gehe davon aus, dass die neue Firmware nicht sofort geschrieben wird, sondern erst komplett übertragen, dann geprüft und dann das Update stattfindet.
Das würde ich auch vermuten.
Im Regensensor Werkelt ein Mikrokontroller von ST (STM8L151C8U6). Dieser hat bis zu 64 KB Flash Memory.
Für die Firmware des Sensors sollten 32 KB locker ausreichen, so dass beim Update vermutlich freie Bereiche des Flashes beschrieben werden.
Nach dem Update over the Air wird der Inhalt der übertragenen Daten dann vermutlich überprüft. Checksumme. Ggf. auch noch eine Signatur.
Diese Prüfung könnte sogar "Sektorweise" erfolgen, so dass nach einem Übertragungsfehler nur noch die fehlenden und fehlerhaften Daten übertragen werden brauchen.
Falls dann alles stimmt, kann der Bootloader den Temporären Programmcode dann in den Hauptbereich kopieren / verschieben.
Somit kann man Übertragunsfehler 100 %ig ausschließen.
Gruß
Dirk
cool... gestern hab ich das anstehende Firmwareupdate 2.7.8 der CCU2 gemacht und was passiert heute? Neue Firmware 2.7.14 verfügbar... 8)
Also nochmal alles von vorne.
auf dem Web ist 2.7.14 noch nicht zu finden.
Über den detaillierten Updateprozess ist es mühselig zu Diskutieren. Ist genug Flash da um 2 Images zu halten? Hat das Flash 2 oder mehr Bänke? War wird alles geprüft vor dem Schreiben? Ist der Bootloader auch in dem Flash? Ist genut RAM zu Verfügung das image ggf zwischen zu speichern? Hat man das Schreiben zeitich auf nach dem Download verschoben um processing-power für dem Message-transfere zu haben? es gibt viele Möglichkeiten.
Wichtig ist, dass zumindest einige Tests (checksumme) durchgeführt werden, bevor das Device umschaltet. Das müsste eQ3 schon machen zur eignen Sicherheit - und wir haben auch mehr spielraum zum Testen.
Die Imagefiles müssten in der CCU Fw eigentlich voliegen - ich habe keinen Entpacker für das Image. Kann einer das File des T mir zukommen lassen?
Schicke dir die Files Per PM.
Gruß
Jan
Hier mal was zur Größe der Firmwarefiles...
# ls -al
total 1416
drwxr-xr-x 4 root root 1608 Jan 30 10:56 .
drwxr-xr-x 20 root root 1448 Jan 30 10:56 ..
-rwxr-xr-x 1 root root 57880 Jan 30 10:56 coprocessor_update.eq3
-rwxr-xr-x 1 root root 1539 Jan 30 10:56 fwmap
-rwxr-xr-x 1 root root 136112 Jan 30 10:56 hm-cc-rt-dn_update.eq3
-rwxr-xr-x 1 root root 125920 Jan 30 10:56 hm-lgw-o-tw-w-eu_update.eq3
-rwxr-xr-x 1 root root 67096 Jan 30 10:56 hm-sen-rd-o_update.eq3
-rwxr-xr-x 1 root root 146872 Jan 30 10:56 hmw-lgw-o-dr-gs-eu_update.eq3
-rwxr-xr-x 1 root root 86413 Jan 30 10:56 hmw_io12_sw14_dr_hw0.hex
-rwxr-xr-x 1 root root 86413 Jan 30 10:56 hmw_io12_sw7_dr_hw0.hex
-rwxr-xr-x 1 root root 86413 Jan 30 10:56 hmw_io_12_fm_hw0.hex
-rwxr-xr-x 1 root root 86413 Jan 30 10:56 hmw_io_4_fm_hw0.hex
-rwxr-xr-x 1 root root 86413 Jan 30 10:56 hmw_io_sr_fm_hw0_unstable.hex
-rwxr-xr-x 1 root root 86413 Jan 30 10:56 hmw_lc_bl1_dr_hw0.hex
-rwxr-xr-x 1 root root 86413 Jan 30 10:56 hmw_lc_dim1l_dr_hw0.hex
-rwxr-xr-x 1 root root 86413 Jan 30 10:56 hmw_lc_sw2_dr_hw0.hex
-rwxr-xr-x 1 root root 86413 Jan 30 10:56 hmw_sen_sc_12_dr_hw0.hex
-rwxr-xr-x 1 root root 86413 Jan 30 10:56 hmw_sen_sc_12_fm_hw0.hex
drwxr-xr-x 2 root root 1344 Jan 30 10:56 hs485types
drwxr-xr-x 3 root root 7472 Jan 30 10:56 rftypes
# cat fwmap
#Type Filename Version
#Module types reported by firmware
#Hardware types reported by bootloader
#HomeMatic Wired
H16V0 hmw_io_4_fm_hw0.hex @0x77F0 #HMW-IO-4-FM
H17V0 hmw_lc_sw2_dr_hw0.hex @0x77F0 #HMW-LC-Sw2-DR
H18V0 hmw_io12_sw7_dr_hw0.hex @0x77F0 #HMW-IO-12-Sw7-DR
H20V0 hmw_lc_dim1l_dr_hw0.hex @0x77F0 #HMW-LC-Dim1L-DR
H21V0 hmw_lc_bl1_dr_hw0.hex @0x77F0 #HMW-LC-Bl1-DR
H22V0 hmw_io_sr_fm_hw0_unstable.hex @0x77F0 #HMW-IO-SR-FM(UNSTABLE)
H25V0 hmw_sen_sc_12_dr_hw0.hex @0x77F0 #HMW-Sen-SC-12-DR
H26V0 hmw_sen_sc_12_fm_hw0.hex @0x77F0 #HMW-Sen-SC-12-FM
H27V0 hmw_io_12_fm_hw0.hex @0x77F0 #HMW-IO-12-FM
H28V0 hmw_io12_sw14_dr_hw0.hex @0x77F0 #HMW-IO-12-SW14-DR
#Coprozessor
ARM7 hss_comm.enc 0.056
CCU2 coprocessor_update.eq3 1.0.11 #CoProzessor CCU2
#Gateways
HMW-LGW-O-DR-GS-EU hmw-lgw-o-dr-gs-eu_update.eq3 1.0.5
HM-LGW-O-TW-W-EU hm-lgw-o-tw-w-eu_update.eq3 1.1.3
#HomeMatic RF
149 hm-cc-rt-dn_update.eq3 1.2 # HM-CC-RT-DN
167 hm-sen-rd-o_update.eq3 1.4 #HM-Sen-RD-O
Welche XML Files hättest Du denn gerne?
# ls -al
total 2400
drwxr-xr-x 3 root root 7472 Jan 30 10:56 .
drwxr-xr-x 4 root root 1608 Jan 30 10:56 ..
drwxr-xr-x 2 root root 240 Jan 30 10:56 replaceMap
-rwxr-xr-x 1 root root 7310 Jan 30 10:56 rf_4dis.xml
-rwxr-xr-x 1 root root 3638 Jan 30 10:56 rf_ash550.xml
-rwxr-xr-x 1 root root 39689 Jan 30 10:56 rf_bl.xml
-rwxr-xr-x 1 root root 38788 Jan 30 10:56 rf_bl_644.xml
-rwxr-xr-x 1 root root 38543 Jan 30 10:56 rf_bl_conf_644.xml
-rwxr-xr-x 1 root root 37705 Jan 30 10:56 rf_bl_conf_644_le_v2_1.xml
-rwxr-xr-x 1 root root 38472 Jan 30 10:56 rf_bl_le_v2_3.xml
-rwxr-xr-x 1 root root 70348 Jan 30 10:56 rf_cc_rt_dn.xml
-rwxr-xr-x 1 root root 74682 Jan 30 10:56 rf_cc_rt_dn_bom.xml
-rwxr-xr-x 1 root root 94279 Jan 30 10:56 rf_cc_tc.xml
-rwxr-xr-x 1 root root 93331 Jan 30 10:56 rf_cc_tc_le_v1_9.xml
-rwxr-xr-x 1 root root 3295 Jan 30 10:56 rf_cc_vd.xml
-rwxr-xr-x 1 root root 3649 Jan 30 10:56 rf_central.xml
-rwxr-xr-x 1 root root 38899 Jan 30 10:56 rf_cf.xml
-rwxr-xr-x 1 root root 42021 Jan 30 10:56 rf_cfm.xml
-rwxr-xr-x 1 root root 24205 Jan 30 10:56 rf_cm.xml
-rwxr-xr-x 1 root root 6496 Jan 30 10:56 rf_cmm.xml
-rwxr-xr-x 1 root root 32838 Jan 30 10:56 rf_d.xml
-rwxr-xr-x 1 root root 31140 Jan 30 10:56 rf_d_le_v1_7.xml
-rwxr-xr-x 1 root root 31357 Jan 30 10:56 rf_d_le_v1_9.xml
-rwxr-xr-x 1 root root 20341 Jan 30 10:56 rf_ddc.xml
-rwxr-xr-x 1 root root 41283 Jan 30 10:56 rf_dim_1l_644.xml
-rwxr-xr-x 1 root root 40049 Jan 30 10:56 rf_dim_1l_644_le_v2_4.xml
-rwxr-xr-x 1 root root 41947 Jan 30 10:56 rf_dim_1pwm_644.xml
-rwxr-xr-x 1 root root 40847 Jan 30 10:56 rf_dim_1pwm_644_le_v2_4.xml
-rwxr-xr-x 1 root root 43042 Jan 30 10:56 rf_dim_1t_644.xml
-rwxr-xr-x 1 root root 41663 Jan 30 10:56 rf_dim_1t_644_le_v2_4.xml
-rwxr-xr-x 1 root root 41977 Jan 30 10:56 rf_dim_1tconf_644.xml
-rwxr-xr-x 1 root root 41158 Jan 30 10:56 rf_dim_1tconf_644_le_v2_4.xml
-rwxr-xr-x 1 root root 40875 Jan 30 10:56 rf_dim_2l_644.xml
-rwxr-xr-x 1 root root 39779 Jan 30 10:56 rf_dim_2l_644_le_v2_4.xml
-rwxr-xr-x 1 root root 42211 Jan 30 10:56 rf_dim_2t_644.xml
-rwxr-xr-x 1 root root 41115 Jan 30 10:56 rf_dim_2t_644_le_v2_4.xml
-rwxr-xr-x 1 root root 33991 Jan 30 10:56 rf_dim_t.xml
-rwxr-xr-x 1 root root 32747 Jan 30 10:56 rf_dim_t_le_v1_9.xml
-rwxr-xr-x 1 root root 33905 Jan 30 10:56 rf_es_pmsw.xml
-rwxr-xr-x 1 root root 20747 Jan 30 10:56 rf_fs_ba.xml
-rwxr-xr-x 1 root root 15212 Jan 30 10:56 rf_keymatic.xml
-rwxr-xr-x 1 root root 6493 Jan 30 10:56 rf_ks550.xml
-rwxr-xr-x 1 root root 7155 Jan 30 10:56 rf_ou_led16_ge_v1_1.xml
-rwxr-xr-x 1 root root 6529 Jan 30 10:56 rf_ou_led16_le_v1_0.xml
-rwxr-xr-x 1 root root 7499 Jan 30 10:56 rf_pb-2-wm55_ge_v1_4.xml
-rwxr-xr-x 1 root root 7293 Jan 30 10:56 rf_pb-2-wm55_le_v1_3.xml
-rwxr-xr-x 1 root root 7234 Jan 30 10:56 rf_pbi.xml
-rwxr-xr-x 1 root root 7573 Jan 30 10:56 rf_rc-4-2.xml
-rwxr-xr-x 1 root root 6911 Jan 30 10:56 rf_rc-key4-2.xml
-rwxr-xr-x 1 root root 6911 Jan 30 10:56 rf_rc-sec4-2.xml
-rwxr-xr-x 1 root root 8386 Jan 30 10:56 rf_rc.xml
-rwxr-xr-x 1 root root 7736 Jan 30 10:56 rf_rc_12.xml
-rwxr-xr-x 1 root root 19385 Jan 30 10:56 rf_rc_19.xml
-rwxr-xr-x 1 root root 6942 Jan 30 10:56 rf_rc_single_on.xml
-rwxr-xr-x 1 root root 8997 Jan 30 10:56 rf_rd.xml
-rwxr-xr-x 1 root root 8072 Jan 30 10:56 rf_rd_le_v1_3.xml
-rwxr-xr-x 1 root root 49686 Jan 30 10:56 rf_rep.xml
-rwxr-xr-x 1 root root 40392 Jan 30 10:56 rf_resc_win_pcb_sc.xml
-rwxr-xr-x 1 root root 8299 Jan 30 10:56 rf_rhs.xml
-rwxr-xr-x 1 root root 7910 Jan 30 10:56 rf_rhs_e_v1_7.xml
-rwxr-xr-x 1 root root 7730 Jan 30 10:56 rf_rhs_le_v1_6.xml
-rwxr-xr-x 1 root root 59776 Jan 30 10:56 rf_roto_wdf_solar.xml
-rwxr-xr-x 1 root root 25423 Jan 30 10:56 rf_s.xml
-rwxr-xr-x 1 root root 2642 Jan 30 10:56 rf_s550ia.xml
-rwxr-xr-x 1 root root 21725 Jan 30 10:56 rf_s_1conf_644.xml
-rwxr-xr-x 1 root root 20645 Jan 30 10:56 rf_s_1conf_644_le_v2_1.xml
-rwxr-xr-x 1 root root 21617 Jan 30 10:56 rf_s_1conf_644_le_v2_3.xml
-rwxr-xr-x 1 root root 20898 Jan 30 10:56 rf_s_4_ba.xml
-rwxr-xr-x 1 root root 23599 Jan 30 10:56 rf_s_644.xml
-rwxr-xr-x 1 root root 20737 Jan 30 10:56 rf_s_ba.xml
-rwxr-xr-x 1 root root 18842 Jan 30 10:56 rf_s_le_v1_5.xml
-rwxr-xr-x 1 root root 25103 Jan 30 10:56 rf_s_le_v2_3.xml
-rwxr-xr-x 1 root root 16571 Jan 30 10:56 rf_s_mega168.xml
-rwxr-xr-x 1 root root 7763 Jan 30 10:56 rf_sc.xml
-rwxr-xr-x 1 root root 7186 Jan 30 10:56 rf_sc_e_v1_7.xml
-rwxr-xr-x 1 root root 7006 Jan 30 10:56 rf_sc_le_v1_6.xml
-rwxr-xr-x 1 root root 6322 Jan 30 10:56 rf_scd_v1_0.xml
-rwxr-xr-x 1 root root 6695 Jan 30 10:56 rf_sci_3.xml
-rwxr-xr-x 1 root root 8850 Jan 30 10:56 rf_sec_mdir.xml
-rwxr-xr-x 1 root root 8625 Jan 30 10:56 rf_sec_mdir_v1_5.xml
-rwxr-xr-x 1 root root 5878 Jan 30 10:56 rf_sec_sd.xml
-rwxr-xr-x 1 root root 5542 Jan 30 10:56 rf_sec_sd_schueco.xml
-rwxr-xr-x 1 root root 25511 Jan 30 10:56 rf_sec_sfa.xml
-rwxr-xr-x 1 root root 5851 Jan 30 10:56 rf_sen_ep.xml
-rwxr-xr-x 1 root root 8180 Jan 30 10:56 rf_sen_mdir.xml
-rwxr-xr-x 1 root root 7946 Jan 30 10:56 rf_sen_mdir_v1_5.xml
-rwxr-xr-x 1 root root 8540 Jan 30 10:56 rf_sen_wa_od.xml
-rwxr-xr-x 1 root root 4345 Jan 30 10:56 rf_swi.xml
-rwxr-xr-x 1 root root 164176 Jan 30 10:56 rf_tc_it_wm-w-eu.xml
-rwxr-xr-x 1 root root 6709 Jan 30 10:56 rf_tis.xml
-rwxr-xr-x 1 root root 6305 Jan 30 10:56 rf_tis_le_v1_0.xml
-rwxr-xr-x 1 root root 5690 Jan 30 10:56 rf_wds30_ot2.xml
-rwxr-xr-x 1 root root 3466 Jan 30 10:56 rf_wds40_th_i_2.xml
-rwxr-xr-x 1 root root 6510 Jan 30 10:56 rf_wds_v1_0.xml
-rwxr-xr-x 1 root root 7250 Jan 30 10:56 rf_wds_v1_1.xml
-rwxr-xr-x 1 root root 23400 Jan 30 10:56 rf_winmatic.xml
-rwxr-xr-x 1 root root 4073 Jan 30 10:56 rf_ws550.xml
#
Wie geil ist DAS denn???
Ich habe jetzt folgendes probiert:
- die bidcos-ID meiner CCU2 auf die gleiche Adresse gesetzt wie mein fhem
- drei untereinander gepeerte HM-Komponenten im Wohnzimmer (RT-DN, SEC-RHS und WDS-TH) über "Geräte anlernen" in die WebUI der CCU2 hinzugefügt
Und nun kann ich die Heizungsregelung sowohl über fhem als auch über die CCU2 gleichzeitig (!) vornehmen. Wenn ich in fhem ein set desired-temp ausführe, wird die neue Solltemperatur sofort im WebUI der CCU2 angezeigt. (natürlich funktioniert das auch umgekehrt)
(http://up.picr.de/17220926ry.png)
Hi betateilchen,
hast du schon mal mit strace probiert? Mein Vorschlag:
lsof | grep /dev/ttyAPP0 # spalte 2 ist die pid
strace -s9999 -o bidcos.strace -eread,write,ioctl -p pid_von_oben
Mich würde interessieren ob danach was sinnvolles in der bidcos.strace steht. Einfach bei normalen Operationen (wie Temperatur setzen). Dann wissen wir ob das prinzipiell geht oder nicht. Wenn kein lsof installiert sein sollte müsstest du etwas raten aber vermutlich ist es der rfd.
Wenn es jemand mit HMLan probieren will geht das ganze natürlich etwas anders. Zuerst AES für HMLAN deaktivieren. Dann:
tcpdump -s 0 -w bidcos.network -ni eth0 host ip_of_your_hmlan
Danach sehen wir alles was an HMLAN gesendet wird auf dem LAN. Zusätzlich kann man auch das strace von laufen lassen. Da sieht man das meiste auch:
strace -s9999 -o bidcos.strace -eread,write,ioctl,trace=network -p pid
Gruß,
Jan
Gruß,
Jan
@Betateilchen,
Hast du nicht auch ein TV-Stick und eine SDR-Software rumliegen.
Schau doch mal ob das Übertragen der Firmware auf einem anderen Kanal passiert.
869,3 Mhz bis 870 Mhz währ der Interessante Bereich. Darunter (868 Mhz bis 869,3 Mhz) ist der erlaubte Duty Cycle < 1%, teilweise < 0,1%.
Gruß
Dirk
@jab ich hab mal an einem RT die Solltemperatur auf 17° gestellt:
# cat bidcos.strace
read(5, "\0", 32) = 1
read(11, "Bin\0\0\0\0G\0\0\0\10setValue\0\0\0\3\0\0\0\3\0\0\0\fKEQ0578824:4\0\0\0\3\0\0\0\17SET_TEMPERATURE\0\0\0\4\"\0\0\0\0\0\0\5", 4095) = 79
read(11, 0xbef647a8, 4095) = -1 EAGAIN (Resource temporarily unavailable)
ioctl(7, TCFLSH, 0) = 0
write(7, "\375\0\21\1k\2\0\0^\260\21\22p\0!\300\270\206\4\"\352\320", 22) = 22
write(6, "\0", 1) = 1
read(5, "\0", 32) = 1
read(11, "", 4095) = 0
read(5, "\0", 32) = 1
read(11, "Bin\0\0\0\0\32\0\0\0\22system.listMethods\0\0\0\0", 4095) = 34
read(11, 0xbef647a8, 4095) = -1 EAGAIN (Resource temporarily unavailable)
read(11, "", 4095)
Zitat von: Dirk am 31 Januar 2014, 15:30:43Hast du nicht auch ein TV-Stick und eine SDR-Software rumliegen.
...
869,3 Mhz bis 870 Mhz währ der Interessante Bereich. Darunter (868 Mhz bis 869,3 Mhz) ist der erlaubte Duty Cycle < 1%, teilweise < 0,1%
Homematic arbeitet bei einem getConfig in beide Richtungen auf einer Frequenz um die 869.75 MHz
@betateilchen:
Nach dem kurzen snippet würde ich vermuten, dass er das hier an das Funkmodul schickt (da man das open nicht sieht und daher nicht weiß welcher Handle was ist):
\375\0\21\1k\2\0\0^\260\21\22p\0!\300\270\206\4\"\352\320
Daraus werde zumindest ich nicht direkt schlau. Schade. Einen Versuch war es wert.
Laut Signatur hast du doch ein HM-USB-CFG2 + hmland. Hat mal jemand probiert ob hmland mit der CCU2 funktioniert? Das wäre sonst eine Möglichkeit wo man das die Kommunikation auf dem LAN mitlesen könnte. Ansonsten brauchen wir wohl doch einen HMLAN.
Gruß,
Jan
Zitat von: betateilchen am 31 Januar 2014, 15:45:01
Homematic arbeitet bei einem getConfig in beide Richtungen auf einer Frequenz um die 869.75 MHz
Während des Firmwareupdates?
Zitat von: martinp876 am 30 Januar 2014, 19:46:50
die normalen messages scheinen es nicht zu sein. Diese könnten wir ja sonst mit einem "monitor HMLAN" sniffen. Das ist schon versucht worden. Es kam die Message "enter boot loader" dann war Schluss. Die Messages sind also zumindest modifiziert.
Meine Theorie ist, dass der Firmwareupdate auf einer anderen Frequenz läuft, da dieser recht lange dauert und dabei sonst das erlaubte DuttyCycle für die "normale" Frequenz überschritten wird. Das währe nicht zulässig.
Daher die Idee auf einer anderen Frequenz zu lauschen wenn das OTA-Update übertragen wird.
ZitatWährend des Firmwareupdates?
nein, während eines "normalen" getConfig, wie ich bereit oben geschrieben hatte.
ZitatHat mal jemand probiert ob hmland mit der CCU2 funktioniert?
Ja, geht nicht.
(http://up.picr.de/17222563ap.jpg)
- der einzelne rote Punkt ist ein FS20 Schaltbefehl,
- die beiden roten Punkte nebeneinander sind ein Homematic Schaltbefehl
Abend,
ich habe mir das ganze mal schnell mit einem Debugger angesehen. Folgendes passiert:
- Packet wird geschickt um das Gerät in den Bootloader zu starten (afaik es startet neu in den Bootloader)
- Die Datenrate wird auf 100k geändert
- Update wird gesendet
Ich gucke es mir später mal genauer an. Dutycycle wird beachtet. Es kann zu wenig da sein.
Gruß,
Jan
Im Anhang das strace eines Firmwareupdates.
Und ich würde sagen, da wird nicht nur die Frequenz geändert, sondern auch das Modulationsverfahren. Muss aber erstmal die Screenshots sortieren.
(http://up.picr.de/17225476tm.png)
(http://up.picr.de/17225479wf.jpg)
(http://up.picr.de/17225481ak.jpg)
Abend,
also wenn ich das richtig lesen kann dann wird der Dutycycle geändert und die Datenrate. Sieht mir allerdings so aus als wenn da trotzdem "normale" BidCos Meldungen gesendet werden. Ich gucke es mir aber noch etwas näher an.
Gruß,
Jan
Zitat... dann wird der Dutycycle geändert
Den Dutycycle kann man nicht ändern, denn dieser ist im verwendeten Frequenzbereich festgelegt.
Von 868,0 Mhz bis 868,6 Mhz sind nur < 1% Sendezeit erlaubt.
Man muss auf eine andere Frequenz ausweichen wenn man länger senden möchte.
In diesem Fall > 869,3 Mhz. Die Bilder von Betateilchen könnten diese Theorie auch bestätigen.
Ok ich habe es für euch mal genauer analysiert. Dutycycle wird nicht geändert sondern nur gecheckt. Codefluss ist so (ohne Fehlerbehandlung):
1. BidcosInterfaceConcentrator::DutyCycleForUpdate(int,UpdateFile &)
-> checkt ob möglicherweise nicht genug duty frei ist
2. BidcosFrameStartBootloader::BidcosFrameStartBootloader(void)
- StructuredFrame::setType(0xCA0911) (ka warum da so viel hinter steht)
- BidcosFrame::setCtrl(0x80)
- BidcosFrame::setReceiverAddress(0x70)
- RFManager::getBidcosAddress -> BidcosFrame::setSenderAddress
- BidcosInterfaceConcentrator::sendFrame
3. Warten auf response (uninteressant)
4. RFDevice::set100kDataRate
5. In loop: BidcosInterfaceConcentrator::SendUpdataFrame(std::string const&,int)
- Auth wird resettet. Also keine AES o.ä.
- Message Type ist 0xCA wenn ich das richtig interpretiere
- jeweils 0xC bytes der firmware pro message
6. BidcosInterfaceConcentrator::SetInterfaceTo10kMode(int)
EDIT: So ganz verstehe ich noch nicht wie das mit dem Umschalten funktioniert. Folgende Funktionen habe ich gefunden.
set100kDataRate:
Type: 0xCB
Ctrl: 0x0
Empfänger: 0x70
Message: (0x16 / 22 Zeichen)
0x10 0x5B 0x11 0xF8 0x15 0x47 0xB 0x8 0x1A 0x1C 0x19 0x1D 0x1B 0xC7 0x1C 0x0 0x1D 0xB2 0x21 0xB6 0x23 0xEA 0x0
HM2::CCU2CommController::setDataRate100k
payload: 0xE9 0xCA
Gruß,
Jan
Zitat von: jab am 31 Januar 2014, 23:09:15
EDIT: So ganz verstehe ich noch nicht wie das mit dem Umschalten funktioniert. Folgende Funktionen habe ich gefunden.
set100kDataRate:
Type: 0xCB
Ctrl: 0x0
Empfänger: 0x70
Message: (0x16 / 22 Zeichen)
0x10 0x5B 0x11 0xF8 0x15 0x47 0xB 0x8 0x1A 0x1C 0x19 0x1D 0x1B 0xC7 0x1C 0x0 0x1D 0xB2 0x21 0xB6 0x23 0xEA 0x0
Hey, das ist die CC1101-Konfiguration. Damit kann man dem CUL beibringen, mitzulauschen.
0x10 -> 0x5B (Exponent der Datenrate in den untersten 4 Bit -> 11)
0x11 -> 0xF8 (Mantisse der Datenrate -> 248)
Laut cc1101.pdf (http://www.ti.com/lit/ds/symlink/cc1101.pdf), Seite 35:
R_data = (((256+248)*2^11)/(2^28))*26000000
R_data = 99975.5848
:-)
Daneben werden noch eine Menge anderer Register angefasst (0x1A, 0x1C, 0x1D, 0x21, 0x23) die bisher bei BidCos im Default-Zustand waren und andere überschrieben (0x0B, 0x10, 0x11, 0x15, 0x19, 0x1B). Erklärungen dazu im cc1101.pdf, ab Seite 71.
Ich versuche da heute Abend mal was in die culfw reinzufrickeln, um den Empfang zu ermöglichen.
Gruß
Michael
Sehr cool. Wir haben jetzt ja auch einen USB dump für den Hm usb cfg Stick. Da habe ich schon etwas experimentiert aber bin leider noch nicht ganz durch. Dann hätten wir zwei Geräte die 100k unterstützen.
Außerdem will ich einen atmel bootloader bauen der auch update per 100k Mode unterstützt. Dann kann man die custom Firmware auch damit updaten.
Allerdings Alles noch wip. Kann noch ein paar Tage dauern.
Gruß
Jan
Zitat von: jab am 10 Februar 2014, 14:10:33
Sehr cool. Wir haben jetzt ja auch einen USB dump für den Hm usb cfg Stick. Da habe ich schon etwas experimentiert aber bin leider noch nicht ganz durch. Dann hätten wir zwei Geräte die 100k unterstützen.
Nice :-)
Habe jetzt mal die Parameter in die culfw commited: http://sourceforge.net/p/culfw/code/401/
Um den Code zu benutzen, muss man "HAS_ASKSIN_FUP" in der Board-config definieren und dann den FUP-Modus mit "AR" aktivieren. Ein "Ar" schaltet wieder auf den normalen AskSin-Modus zurück.
Getestet habe ich den Empfang jetzt nicht, da das remote ohne Firmware-Update relativ schlecht geht, habe aber gedacht, dass es evtl. für jemand anderes schonmal nützlich ist. Ohne das zusätzliche Board-Flag ändert sich nichts, das habe ich auch (remote) getestet.
Falls das weitere Datenformat BidCos-ähnlich ist (d.h. Längen-Byte als erstes Byte und danach wie bei BidCos ge-XORte Daten, dann sollte sogar das senden mit "As" funktionieren.
Zitat
Außerdem will ich einen atmel bootloader bauen der auch update per 100k Mode unterstützt. Dann kann man die custom Firmware auch damit updaten.
Hört sich gut an :-)
Gruß
Michael
@jan
wird die firmware plain übertragen? ansonsten müsstest du doch an die verschlüsselung ran?
ich bin immer noch auf der suche meiner lib das aes protokoll beizubringen :-)
Hi,
@horst: im USB ist eh nichts verschlüsselt. Sieht mit aber auch alles unverschlüsselt aus da er vorher aes resettet im code.
@michael: ist relativ sicher normales Bidcos. Er nutzt die gleichen messages wie vorher im code. Kann höchstens sein dass der USB Stick das ändert.
Gruß
Jan
d.h. man könnte das Firmware Update durch einen Disassembler jagen?
Ich hätte vermutet das die Firmware verschlüsselt übertragen wird, im seriellen EEprom verschlüsselt abgelegt wird und
dann über den Bootloader entschlüsselt und ins Flash geschrieben wird.
Damit würde dann auch nichts passieren falls bei der Update Übertragung was schief geht. Aber wie gesagt, dass
war nur eine Vermutung...
Hi Horst,
Ja disassembler geht. Daher habe ich die Infos ja.
Man kann die RTs definitiv kaputt flashen. Man bekommt sie aber immer noch in den bootloader.
Gruß
Jan
So, die culfw kann mit AR das Firmwareupdate mitschneiden und sollte auch mit As senden können.
Im Anhang der 100k-Teil eines Updates.
EDIT: Irgendwie fehlt da ziemlich viel, vielleicht ist das mit dem Längenbyte doch anders... Anscheinend sind das immer nur die letzten Bytes eines Update-Pakets...
Gruß
Michael
Abend,
das sieht schon gut aus. Allerdings fehlt da wirklich einiges. Im USB sieht es so aus:
00000000: 53 00 00 08 21 00 00 00 00 00 01 00 08 f1 c4 13
00000010: 2a 20 ca 12 04 08 22 0f 80 ba 6e 4f 6d 7d 9c 38
00000020: 2a 2a 80 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000000: 53 00 00 08 2a 00 00 00 00 00 01 00 08 f1 c4 13
00000010: 2b 20 ca 12 04 08 22 0f 80 22 2b 8d 24 c1 72 d7
00000020: 92 db e8 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
In deinem Dump (unterschiedliche HMID aber sonst gleiche Msg):
A132A20CA00000021B983BA6E4F6D7D9C382A2A80
A132B20CA00000021B983222B8D24C172D792DBE8
Den Code zum lesen der Firmware kann man relativ einfach bekommen. Da gibt es potentiell zwei Quellen: CCU2 Firmware (Binary rfd; C++ Code mit Debug symbols) oder den Firmware Updater (.NET habe ich im Debugger nicht auf bekommen).
Gruß,
Jan
Abend,
so ich habe mal etwas geschaut. Die Firmware ist in 580 Byte Blöcke (jeweils 4Byte Länge und dann die Daten) organisiert. Parsen kann man das ganze mit folgendem Code:
<?php
$f = fopen("hm-cc-rt-dn_update.eq3", "r");
while(! feof($f)) {
$lenStr = fread($f, 4);
if (feof($f)) {
break;
}
$len = hexdec($lenStr) * 2;
$bytes = fread($f, $len);
echo $bytes . "\n";
}
Das deckt sich auch mit dem alignment im Funk.
EDIT: Der Debugger kann mit dem resultierenden Binary auch was anfangen (mit xxd kann man es von hex nach bin konvertieren). Weiß jemand was für ein Controller auf dem HM-CC-RT-DN genau drauf ist?
Gruß,
Jan
Zitat von: jab am 10 Februar 2014, 22:28:45
EDIT: Der Debugger kann mit dem resultierenden Binary auch was anfangen (mit xxd kann man es von hex nach bin konvertieren). Weiß jemand was für ein Controller auf dem HM-CC-RT-DN genau drauf ist?
Ich bin mir ziemlich sicher, dass das Ding verschlüsselt ist und der Bootloader auf dem HM-CC-RT-DN die Daten vor dem Flashen entschlüsselt. Sonst hätten wir jetzt den Default-AES-Key im Klartext.
Selbst die Firmware für das Wired-Zeugs ist verschlüsselt, genauso wie die Firmware für den USB-Stick (den man seit gerade eben auch unter Linux flashen kann).
Kannst Du mir evtl. den USB-Dump zukommen lassen?
Vielleicht finde ich heraus, welche Pakete ich mit dem CUL nicht empfange.
Gruß
Michael
ZitatSelbst die Firmware für das Wired-Zeugs ist verschlüsselt
Ist sie nicht.
Gruß
Dirk
Zitat von: Dirk am 10 Februar 2014, 22:55:51
Ist sie nicht.
Ok, dann bin ich schon still. Das sind gute Nachrichten.
Dann ist es die Funk-Firmware hoffentlich auch nicht :-)
Gruß
Michael
Zitat von: mgernoth am 10 Februar 2014, 22:53:35USB-Stick (den man seit gerade eben auch unter Linux flashen kann)
Hab ich was verpaßt?
Zitat von: mgernoth am 10 Februar 2014, 22:53:35
Vielleicht finde ich heraus, welche Pakete ich mit dem CUL nicht empfange.
Das war zu einfach, die Pakete sind länger als die 30 hartkodierten Bytes in der culfw.
Neuer Sniff im Anhang.
Zitat von: betateilchen am 10 Februar 2014, 23:04:09
Hab ich was verpaßt?
Nur das hier: http://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb/commit/b5e57d268fe86cf58116c03166d45c130280dfb6
Gruß
Michael
Abend,
Zitat von: mgernoth am 10 Februar 2014, 22:53:35
Ich bin mir ziemlich sicher, dass das Ding verschlüsselt ist und der Bootloader auf dem HM-CC-RT-DN die Daten vor dem Flashen entschlüsselt. Sonst hätten wir jetzt den Default-AES-Key im Klartext.
Selbst die Firmware für das Wired-Zeugs ist verschlüsselt, genauso wie die Firmware für den USB-Stick (den man seit gerade eben auch unter Linux flashen kann).
Das ist nicht verschlüsselt. Dafür zeigt mir mein Debugger zu viele gültige AVR Opcodes an. Allerdings habe ich den richtigen Atmega noch nicht erraten und die Configuration der Datensegmente muss ich mir noch mal angucken. Daher die Frage ob jemand mal reingeguckt hat und mir sagen kann was das für ein Controller ist.
Den AES Key + den genauen Input für AES sollte man da drin finden denke ich.
Zitat von: mgernoth am 10 Februar 2014, 22:53:35
Kannst Du mir evtl. den USB-Dump zukommen lassen?
Vielleicht finde ich heraus, welche Pakete ich mit dem CUL nicht empfange.
Den Dump hat Mr P für mich netterweise gemacht. Leider kein Wireshark Format aber trotzdem fast selbsterklärend:
https://owncloud.isengard.at/public.php?service=files&t=ad61f7970e54b8fe7683a8c78d353cff
EDIT: Dein Dump sieht super aus! Entspricht genau dem Firmware File. Format ist so:
Vorne weg: A134420CA00000021B983 (ist klar denke ich) dann jeweils 70 Byte Teile der Firmware (inkl der 4 Byte Längenangabe). Solange bis der Block zu ende ist. In unserem Sample sind das immer 580Bytes außer beim letzten Block. Die letzte Nachricht (außer beim letzten Block) ist also nur noch 20 Byte groß. Der ganze Block wird vom Gerät bestätigt. Dann geht es mit dem nächsten weiter.
Gruß,
Jan
ZitatDen AES Key + den genauen Input für AES sollte man da drin finden denke ich.
Nicht unbedingt.
Der könnte genauso gut im Bootloader stecken. bzw. zusammen mit dem Bootloader in ungenutzten Bereichen des Flash's stecken.
Zumindest währ das leichtsinnig den sonst so gut geschützten Schlüssel so leicht zugänglich zu machen.
Gruß
Dirk
Zitat von: Dirk am 11 Februar 2014, 00:09:03
Nicht unbedingt.
Der könnte genauso gut im Bootloader stecken. bzw. zusammen mit dem Bootloader in ungenutzten Bereichen des Flash's stecken.
Zumindest währ das leichtsinnig den sonst so gut geschützten Schlüssel so leicht zugänglich zu machen.
Da hast du recht. Die Frage ist ob der aus eq3 Sicht überhaupt gut geschützt ist, denn es kann ja jeder mit HMLAN oder dem Stick mit den Geräten reden. Für mich wäre die konkrete Implementierung der AES Signierung viel interessanter. Ansonsten könnte man versuchen den Key mit einem eigenen "Firmwareupdate" aus dem Flash zu lesen.
Gruß,
Jan
ZitatAnsonsten könnte man versuchen den Key mit einem eigenen "Firmwareupdate" aus dem Flash zu lesen.
Das ist korrekt. Die Idee hatte ich auch schon.
Daher vermute ich, damit das nicht so leicht geht, dass die Firmware, wenn diese nicht verschlüsselt ist, zumindest irgendeine Art Signatur hat.
Zitat von: Dirk am 11 Februar 2014, 00:16:04
Daher vermute ich, damit das nicht so leicht geht, dass die Firmware, wenn diese nicht verschlüsselt ist, zumindest irgendeine Art Signatur hat.
Sieht für mich nach einem einfachen "Entropietest" leider doch verschlüsselt aus:
-rw-r--r-- 1 michael michael 67588 Feb 11 00:12 hm_cc_rt_dn_update_V1_2_007_131202.bin
$ bzip2 hm_cc_rt_dn_update_V1_2_007_131202.bin
-rw-r--r-- 1 michael michael 68236 Feb 11 00:12 hm_cc_rt_dn_update_V1_2_007_131202.bin.bz2
Bei einem anderen AVR-Binary (Ethersex Bootloader, keine Strings) sieht das etwas anders aus:
-rwxr-xr-x 1 michael michael 6016 Jun 7 2012 ethersex.bin
$ bzip2 ethersex.bin
-rwxr-xr-x 1 michael michael 4756 Jun 7 2012 ethersex.bin.bz2
Gruß
Michael
Falls die Firmware verschlüsselt ist kann mein Debugger die Verschlüsselung on the fly knacken. Solche schönen Callgraphen wie im Anhang entstehen nicht durch Zufall. Sobald man die Längen aus dem Hex entfernt wird das ganze gültiger AVR Code. Die Liste der Fehler ist ziemlich klein und wird vermutlich fast leer wenn man den richtigen Controller auswählt.
Gruß,
Jan
Zitat von: jab am 11 Februar 2014, 01:04:09Die Liste der Fehler ist ziemlich klein und wird vermutlich fast leer wenn man den richtigen Controller auswählt.
das heißt, irgendjemand müsste mal so einen Regler sezieren? Na mal schauen, ob ich heute abend dazu komme :)
Abend,
ich habe gestern schon etwas angefangen. Leider ist so ein Microcontroller schwerer zu verstehen als ein C++ Binary mit Debugsymbols. Ich habe angefangen alle Funktionen ausgehend von den Interrupthandlern zu benennen. Leider fehlen mir aktuell noch zu viele Infos über die Hardware: Was ist an welchem Pin? Welcher ADC misst was? Welcher Interrupts wird wofür benutzt? Welcher Controller ist das überhaupt genau? Hat wirklich noch niemand das Ding aufgemacht? Ich wäre an Bildern sehr interessiert! Ansonsten muss ich mir wohl noch ein Spiel RT kaufen.
Gruß,
Jan
Zitat von: jab am 11 Februar 2014, 17:27:54
ich habe gestern schon etwas angefangen. Leider ist so ein Microcontroller schwerer zu verstehen als ein C++ Binary mit Debugsymbols.
Ich hatte so gehofft, dass Du sinnvollen Code bekommst und wir mehr über die fehlenden HM-Teile (hauptsächlich AES) lernen können, aber leider muss ich Dir jetzt das Innenleben eines HM-CC-RT-DN zeigen (der, den ich gestern mehrmals geflashed habe). :-(
Originalgröße auf: https://rmdir.de/~michael/hm-cc-rt-dn/
Gruß
Michael
ok... dann kann ich meinen RT ja nun wieder zusammenschrauben 8)
Hi,
@Michael: Danke für die Bilder! STM8L152 erklärt warum es Fehler im Disassembler gibt. Der ist etwas exotisch. Scheinbar decken sich die Opcodes großteils mit den von AVR Atmega. IDA Pro unterstützt den nicht direkt. Ich schau ob ich noch einen anderen Disassembler finde.
Gruß,
Jan
Hi! Alle Achtung! Super Idee . Super Team.
Was ist denn mit einer HM-RC-4-2 . Laut pdf lässt die sich auch OTA flashen und der Code ist sicher viel einfacher gestrickt.
http://www.eq-3.de/Downloads/eq3/pdf_FAQ/OTAU_Firmware-Update.pdf
Das Verfahren dürfte auch bei der Fernbedienung nicht viel anders/einfacher sein.
Das simpelste Update war bisher beim Regensensor - da war am Gerät selbst überhaupt nichts zu tun.
fernbedienung müsste vom code viel einfacher zu verstehen sein, da sind keine state maschines drin zur abfrage von irgendwelchen sensoren
oder ausgabe devices. aus meiner sicht hängen da die tasten am pin change interrupt und gut.
ausserdem ist da mit hoher wahrscheinlichkeit ein atmel drin, der auch noch von ida unterstützt wird.
habe gerade mal im usb-update tool nachgeschaut, da finde ich nur leider keine firmware für die fernbedienung...
ich könnte heute abend mal ein paar fotos vom innenleben machen...
@trilu: Geht es Dir jetzt eigentlich um die OTA Updates oder um die Firmware selbst?
mir gehts um die firmware :-)
ich brauche den aes teil für meine lib 8)
Hier im Thread geht es aber ursprünglich um das Übertragungsverfahren der Updates, nicht um deren Inhalt 8)
Ich bin der Meinung, wir sollten hier nicht zwei Themen vermischen, sonst wird es genauso unübersichlich wie der Thread zu Deiner Lib, aus dem ich mich deshalb längst ausgeklinkt habe.
der hat gesessen :'(
Zitat von: betateilchen am 12 Februar 2014, 10:53:22
Das simpelste Update war bisher beim Regensensor - da war am Gerät selbst überhaupt nichts zu tun.
Wie, muss man den nicht in den FUP modus bringen? Das heist ich kann einfach den Regensensor meines Nachbarn kaputt-flashen, wenn ich dem seine Seriennummer (mitgesnifft) habe? Das Firmware update Tool verlangt ja nicht mal den AES key.
Grüße
Pech. In der neuen CCU2 sw 2.7.16 tauchen nur drei Geräte für OTA auf. Der Heizkörper-Thermostat , der Regensensor und ein Funk Lan Gateway.
Zitat von: Robbi24 am 12 Februar 2014, 12:05:24
Pech. In der neuen CCU2 sw 2.7.16 tauchen nur drei Geräte für OTA auf. Der Heizkörper-Thermostat , der Regensensor und ein Funk Lan Gateway.
Das ist kein Pech. Es gibt vermutlich aktuell nicht mehr Geräte, für die ein Update zur Verfügung steht.
Zitat von: Samsi am 12 Februar 2014, 12:02:08Wie, muss man den nicht in den FUP modus bringen?
Nein, muss man nicht.
Hi,
so für die AES Gedanken habe ich einen neuen Thread eröffnet: http://forum.fhem.de/index.php/topic,20121.0.html
Back to Topic:
- Wir können die CCU konfigurieren und das Update mitsniffen
- Wie die Firmware gelesen wird wissen wir
- Wir haben USB + Funkdump
Offen:
- Wie setzt man den USB Stick in den 100k Mode. Das bekommt man sicher aus dem USB Dump.
- Bekommt man HMLAN in den 100k Mode? Bisher unbekannt. Kann man ggf im rfd Binary nachgucken.
- Wie startet das Update? Müssen wir im USB und/oder Funk dump nachgucken
- Wie bekommt die Zentrale CCU2 die Geräte in den Bootloader? Oder geht nur der manuelle Weg?
Gruß,
Jan
Der USB-Stick wird mit G64 in den 100k-Mode geschaltet und mit G0A wieder zurück.
Senden und Empfangen geht genauso wie im 10k-Mode.
Im 100k-Mode funktioniert eine bidirektionale Kommunikation mit einem CUL im 100k-Mode.
Mal sehen ob ich am Wochenende dazu komme, das Firmwareupdate per USB-Stick und CUL zu implementieren. Ich fange mit dem USB-Stick an und versuche es erstmal ausserhalb von fhem.
Gruß
Michael
Moin Michael,
das klingt super. Ich habe mit hmland auch schon etwas experimentiert. Du bist da aber vermutlich viel schneller. Die Frage ist ob wir Firmwareupdate per FHEM aktuell überhaupt vernünftig supporten können. Oder kannst du von dem USB Dump auf das Lan Protokoll schließen?
Falls du noch irgendwelche Funktionen o.ä. aus den Binaries brauchst kann ich dir gerne noch Dinge raussuchen.
Gruß,
Jan
Hi Jan,
Zitat von: jab am 15 Februar 2014, 12:24:05
das klingt super. Ich habe mit hmland auch schon etwas experimentiert. Du bist da aber vermutlich viel schneller. Die Frage ist ob wir Firmwareupdate per FHEM aktuell überhaupt vernünftig supporten können. Oder kannst du von dem USB Dump auf das Lan Protokoll schließen?
Wenn es so ist wie bei allen anderen Kommandos, dann funktioniert es genau gleich. Die Daten nach dem Kommando werden nur HEX übertragen, nicht Binär wie beim USB-Stick. Reagiert denn ein HMLAN auf "G64" (dann sollte er keine normalen HM-Messages mehr empfangen)? Evtl. muss man dem auch noch eine neuere Firmware verpassen davor.
Habe gerade keinen HMLAN mehr hier, den kann ich mir aber am Montag wieder mitnehmen.
Zitat
Falls du noch irgendwelche Funktionen o.ä. aus den Binaries brauchst kann ich dir gerne noch Dinge raussuchen.
Ich muss mal schauen, ob ich noch ein passendes IDA irgendwo habe...
Aber fürs FW-Update brauche ich glaube ich nichts. Der USB-Dump enthält alles was man braucht.
Gruß
Michael
So, jetzt kann man mit dem HM-CFG-USB die RTs auch unter Linux updaten.
Hier ein erfolgreicher Flash mit einem Missing-Ack dazwischen:
deepthought [~/hmcfgusb]> ./flash-ota hm_cc_rt_dn_update_V1_2_007_131202.eq3 KEQ0577793
HomeMatic OTA flasher version 0.093-git
Reading firmware from hm_cc_rt_dn_update_V1_2_007_131202.eq3...
Firmware with 234 blocks successfully read.
HM-CFG-USB opened
Entering 10k-mode
Waiting for device with serial KEQ0577793
Device with serial KEQ0577793 (hmid: 21b982) entered firmware-update-mode
Adding HMID
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Initiating firmware upload!
Flashing 234 blocks: 0084/0234 /
Invalid status: 0008
Flashing 234 blocks: 0234/0234 /
Entering 10k-mode
Waiting for device to reboot
Device rebooted
Gruß
Michael
Abend Michael,
das klingt ja schon sehr gut. Leider klappt das ganz bei mir nicht:
sudo ./flash-ota ~/Downloads/hm-cc-rt-dn_update.eq3 KEQ0734117
HomeMatic OTA flasher version 0.093-git
Reading firmware from /home/jan/Downloads/hm-cc-rt-dn_update.eq3...
Firmware with 234 blocks successfully read.
HM-CFG-USB opened
Entering 10k-mode
Waiting for device with serial KEQ0734117
Device with serial KEQ0734117 (hmid: 2325b7) entered firmware-update-mode
Adding HMID
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Invalid status: 0008
Invalid status: 0008
Invalid status: 0008
Invalid status: 0008
Entering 10k-mode
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Invalid status: 0008
Invalid status: 0008
Invalid status: 0008
Invalid status: 0008
Entering 10k-mode
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Invalid status: 0008
Invalid status: 0008
Invalid status: 0008
Invalid status: 0008
Das geht endlos so weiter. Habe es am Raspberry Pi mit Rasbian und an meinem Thinkpad mit Ubuntu probiert. Beides mal gleiches Bild.
Allerdings hat es mit dem Windowstool und meinem HM-USB-CFG2 auch nicht funktioniert. Das Windowstool hat den angeblich geupdatet, aber so sicher bin ich mir da nicht. FHEM sagt Firmware "0.967".
EDIT: Ich habe mal das File "hmusbif.03c7.enc" geflashed. Leider ohne dass sich bisher was verändert hat.
Gruß,
Jan
Morgen Jan,
Zitat von: jab am 16 Februar 2014, 03:37:06
das klingt ja schon sehr gut. Leider klappt das ganz bei mir nicht:
sudo ./flash-ota ~/Downloads/hm-cc-rt-dn_update.eq3 KEQ0734117
HomeMatic OTA flasher version 0.093-git
Reading firmware from /home/jan/Downloads/hm-cc-rt-dn_update.eq3...
Firmware with 234 blocks successfully read.
HM-CFG-USB opened
Entering 10k-mode
Waiting for device with serial KEQ0734117
Device with serial KEQ0734117 (hmid: 2325b7) entered firmware-update-mode
Adding HMID
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Invalid status: 0008
Invalid status: 0008
Invalid status: 0008
Invalid status: 0008
Entering 10k-mode
Initiating remote switch to 100k
...
Das geht endlos so weiter. Habe es am Raspberry Pi mit Rasbian und an meinem Thinkpad mit Ubuntu probiert. Beides mal gleiches Bild.
Hmm, das bedeutet also, dass sich der HM-CC-RT-DN bei Dir nicht mehr meldet, wenn er getriggered wurde, in den 100k-Modus zu wechseln. Das kann jetzt am USB-Stick, am HM-CC-RT-DN oder an meinem grauenhaften Code von gestern Nacht liegen.
Der Status 0008 heisst "Missing ACK".
Zitat
Allerdings hat es mit dem Windowstool und meinem HM-USB-CFG2 auch nicht funktioniert. Das Windowstool hat den angeblich geupdatet, aber so sicher bin ich mir da nicht. FHEM sagt Firmware "0.967".
Wie hat sich der Fehler beim Windowstool geäußert? Hat es nicht angefangen zu flashen?
Firmware Version 0.967 ist richtig (0x3c7).
Zitat
EDIT: Ich habe mal das File "hmusbif.03c7.enc" geflashed. Leider ohne dass sich bisher was verändert hat.
War zu erwarten, die lief schon ;-)
EDIT: Die Batterien im HM-CC-RT-DN sind ok? Konnte das gerade mit sehr niedriger Betriebsspannung reproduzieren..
Gruß
Michael
Zitat von: mgernoth am 16 Februar 2014, 09:15:43
Hmm, das bedeutet also, dass sich der HM-CC-RT-DN bei Dir nicht mehr meldet, wenn er getriggered wurde, in den 100k-Modus zu wechseln. Das kann jetzt am USB-Stick, am HM-CC-RT-DN oder an meinem grauenhaften Code von gestern Nacht liegen.
Und natürlich lags an meinem Code ;-)
Ich hatte das immer nur mit einem frisch geflashten USB-Stick getestet, der nach dem flashen kein Fhem gesehen hat und deswegen die hmId 000000 hatte. Wenn man in den ausgehenden Paketen die hmId des Sticks setzt (und nicht 000000), dann sollte es jetzt auch bei Dir gehen.
Gruß
Michael
cool :)
Alle Daumen hoch für diesen Fortschritt!
Moin Michael,
sehr cool. Ich habe es getestet und es geht. Erster Versuch vom Raspberry PI war ein Fehlschlag:
sudo ./flash-ota ~/hm-cc-rt-dn_update.eq3 KEQ0734117
HomeMatic OTA flasher version 0.093-git
Reading firmware from /home/pi/hm-cc-rt-dn_update.eq3...
Firmware with 234 blocks successfully read.
HM-CFG-USB opened
HM-CFG-USB firmware version: 967
Entering 10k-mode
Waiting for device with serial KEQ0734117
Device with serial KEQ0734117 (hmid: 2325b7) entered firmware-update-mode
Adding HMID
usb-transfer took more than 100ms (2856ms), this may lead to timing problems!
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 234 blocks: 0023/0234 |
Invalid status: 0408
Flashing 234 blocks: 0023/0234 /
Invalid status: 0408
Flashing 234 blocks: 0023/0234 -
Invalid status: 0408
Too many errors, giving up!
Danach zeigte der Gerät CRC also vermutlich einen CRC Fehler in seiner Firmware.
Ich habe es dann noch mal von meinem Notebook aus probiert und da lief es erfolgreich durch:
sudo ./flash-ota ~/Downloads/hm-cc-rt-dn_update.eq3 KEQ0734117
HomeMatic OTA flasher version 0.093-git
Reading firmware from /home/jan/Downloads/hm-cc-rt-dn_update.eq3...
Firmware with 234 blocks successfully read.
HM-CFG-USB opened
HM-CFG-USB firmware version: 967
Entering 10k-mode
Waiting for device with serial KEQ0734117
Device with serial KEQ0734117 (hmid: 2325b7) entered firmware-update-mode
Adding HMID
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 234 blocks: 0161/0234 -
Invalid status: 0008
Flashing 234 blocks: 0234/0234 /
Entering 10k-mode
Waiting for device to reboot
Device rebooted
EDIT: Das Problem hatte ich bei einem RT auch mit meinem Notebook:
sudo ./flash-ota ~/Downloads/hm-cc-rt-dn_update.eq3 KEQ0654122
HomeMatic OTA flasher version 0.093-git
Reading firmware from /home/jan/Downloads/hm-cc-rt-dn_update.eq3...
Firmware with 234 blocks successfully read.
HM-CFG-USB opened
HM-CFG-USB firmware version: 967
Entering 10k-mode
Waiting for device with serial KEQ0654122
Device with serial KEQ0654122 (hmid: 2356a0) entered firmware-update-mode
Adding HMID
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 234 blocks: 0173/0234 -
Invalid status: 0408
Flashing 234 blocks: 0173/0234 \
Invalid status: 0408
Flashing 234 blocks: 0173/0234 |
Invalid status: 0408
Too many errors, giving up!
Kann man die Anzahl der retries erhöhen? Oder eine Pause zwischen den retries einbauen?
Gruß,
Jan
ich könnte bei Gelegenheit auf einem Beaglebone Black testen.
Zitat von: jab am 16 Februar 2014, 14:33:27
sehr cool. Ich habe es getestet und es geht. Erster Versuch vom Raspberry PI war ein Fehlschlag:
Invalid status: 0408
Too many errors, giving up!
Danach zeigte der Gerät CRC also vermutlich einen CRC Fehler in seiner Firmware.
Aeh, 0408 heisst, dass der Stick keine Sendecredits mehr hat. Ich muss wirklich noch an den Fehlermeldungen basteln ;-)
Evtl. reboote ich den Stick einfach vor dem flashen...
Zitat
Kann man die Anzahl der retries erhöhen? Oder eine Pause zwischen den retries einbauen?
Können kann man natürlich, bringt aber in dem Fall nix, ausser die Pause soll 1h sein...
Ich mach die Anzahl mal als define und baue den Reboot ein.
Gruß
Michael
Hi,
ok das mit dem Duty Cycle macht Sinn. Habe einige mal geflashed.
EDIT: Nach dem Neustart des Sticks klappt es auch auf dem Raspberry PI sehr gut.
Tolle Arbeit! Vielen Dank!
Gruß,
Jan
Zitat von: mgernoth am 16 Februar 2014, 11:45:25Habe es übrigens gerade auf einem Beaglebone ausprobiert (ohne Hub). Läuft ohne Verrenkungen problemlos durch:
Mit 4,99 Euro-Hub vom Kaffeeröster auch.
Hallo,
ist es eigentlich möglich auch mit einem HM-CFG-LAN per oha zu flashen?
Natürlich habe ich es mit sudo ./flash-ota ˜/Downloads/hm-cc-rt-dn_update.eq3 KEQ0xxxxxx versucht leider mit folgendem Ergebnis:
HomeMatic OTA flasher version 0.094-git
Reading firmware from ˜/Downloads/hm-cc-rt-dn_update.eq3...
Firmware with 234 blocks successfully read.
Can't find/open hmcfgusb!
Can't initialize HM-CFG-USB
Das einzige was ich noch an Hardware habe wäre ein CUL433 V3.3 ....
Viele Grüße,
mod25
Zitat von: mod25 am 03 März 2014, 22:32:42
Das einzige was ich noch an Hardware habe wäre ein CUL433 V3.3 ....
Wenn es damit auch nicht funktioniert, kannst Du es ja mal mit dem Kühlschrank probieren...
Zitat von: betateilchen am 03 März 2014, 22:40:52
Wenn es damit auch nicht funktioniert, kannst Du es ja mal mit dem Kühlschrank probieren...
Ich hatte gedacht man könne den cul auf 868 setzen und somit zum hm bringen... aber ich habe jetzt gerade erst meine Fauxpas entdeckt, hierbei geht es ja gänzlich um die Hardware und nicht das Protokoll.
@betateilchen: wie sieht es mit dem HM-CFG-LAN nun aus?
geht net.