Asksin++ Firmware Update OTA Probleme

Begonnen von SirBen, 19 Juni 2019, 11:14:44

Vorheriges Thema - Nächstes Thema

SirBen

Moin,
ich habe mit Asksin++ einen HM-LC-BL1-FM (Rolladen Aktor) gebaut. Dieser funktioniert ohne Probleme.
Als CUL habe ich einen Selbstbau CUL (NANO CUL) mit der culfw 1.67.

Jetzt habe ich den OTA Bootloader auf dem Rolladen Aktor und würde gerne zu Testzwecken probieren, ein Update OTA zu flashen.
Ich habe das über die FHEM Seite probiert (set HM_120203 fwUpdate ...).
Das steht im Log:
2019.06.19 10:41:02 2: CUL_HM fwUpdate started for HM_120203
2019.06.19 10:41:02 3: CUL_HM set HM_120203 fwUpdate ./Homematic-FirmwareUpdate/HM_Blinds_Wohnzimmer3_2019_03.ino.eightanaloginputs_201906190657.eq3
2019.06.19 10:41:12 2: CUL_HM fwUpdate HM_120203 end. IO-speed: normal
2019.06.19 10:41:17 3: CUL_HM set HM_120203 getConfig


Die Serielle Ausgabe vom Pro Mini:
-> 0A 0A 30 11 310388 120203 CA  - 15095
<- 0A 0A 80 02 120203 310388 00  - 15220
BOOTLOADER


AskSin OTA Bootloader V0.7.0

TX bootloader sequence
Wait for CB msg
Timeout
CRC OK
Start App
AskSin++ V4.0.2 (Jun 19 2019 10:03:17)
Address Space: 32 - 563
CC init1
CC Version: 04
- ready
Config Freq: 0x2165E2
Switch from 00 to 06
New Level: 0
<- 0E 01 A2 10 120203 310388 06 01 00 00 00  - 2162
-> 0A 01 80 02 310388 120203 00  - 2316
waitAck: 01
USW.....


Mit dem Tool hmcfgusb habe ich es auch probiert, da passiert aber nichts weiter....
~src/hmcfgusb (git)-[master] # ./flash-ota -c /dev/ttyUSB0 -f /opt/fhem/Homematic-FirmwareUpdate/HM_Blinds_Wohnzimmer3_2019_03.ino.eightanaloginputs_201906190657.eq3 -s HM_120203
HomeMatic OTA flasher version 0.103-git

Reading firmware from /opt/fhem/Homematic-FirmwareUpdate/HM_Blinds_Wohnzimmer3_2019_03.ino.eightanaloginputs_201906190657.eq3...
Firmware with 224 blocks successfully read.
Opening culfw-device at path /dev/ttyUSB0 with speed 38400
Requesting firmware version
culfw-device firmware version: 1.67
Entering 10k-mode
Waiting for device with serial HM_120203


Kann mir jemand sagen, was ich falsch mache?

Danke und Gruß Ben

tndx

Bin kein großer Experte, deswegen sind die Antworten mit Vorsicht zu genießen, aber folgendes fällt mir auf:

1. Du hast offenbar bereits eine Firmware geflasht, deswegen wird die automatisch gebootet, anstelle dass der Bootloader auf OTA-Empfang geht. Dafür ist es notwendig, beim Power-On die Config-Taste gedrückt zu halten.

2. Laut Deiner seriellen Ausgabe nutzst Du eine abweichende Frequenz (0x2165E2 anstelle 0x216550), defektes CC1101-Modul? In dem Fall wird die korrigierte Frequenz aus dem EEPROM nur von der Firmware interpretiert, aber nicht von dem OTA-Booloader, d.h. der funkt auf der originalen Frequenz, die aber tatsächlich irgendeine andere ist, die nicht von Deinem CUL wahrgenommen wird. Um das zu korrigieren, musst Du den Bootloader patchen, s. auch https://forum.fhem.de/index.php/topic,91740.msg898573.html#msg898573

SirBen

Defekt ist das Funkmodul nicht. Ich wollte nur den bestmöglichen Empfang sicherstellen.

Soweit ich das verstanden habe, muss man die config Taste nur bei älteren HomeMatic Geräten drücken. Die neueren gehen automatisch in den OTA Bootloader und warten auf die Flash Datei. Ich interpretiere die Serielle Ausgabe mal so, dass das Gerät auf die Flash Datei wartet.

Noch eine andere Frage, die Firmware Version ist unverändert (2.4). Deswegen wird da aber nichts blockiert, oder?

frank

Waiting for device with serial HM_120203
hm seriennummern haben 10 zeichen. vielleicht ist das entscheidend.
es kommt jedenfalls keine passende antwort.
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

SirBen

Danke für die Hinweise!
Ich habe mal die Serial wie im Bootloader definiert ("RolloWohn3") eingegeben, aber auch damit passiert nichts.
Es wird seitens hmcgfusb auch nichts gesendet.  :-\

Und bei FHEM mit fwUpdate kann man keine Serial eingeben.

frank

#5
das tool sendet erst, wenn es die message mit der sn empfängt. bis dahin gilt "waiting".
du musst das device dazu bringen. zb manuel wie tndx es beschrieben hat.

über fhem ist es ähnlich, wenn du bei set fwUpdate die optionale waittime angibst.
hier sollten die 6-stelligen ids von bootloader und fw identisch sein.

edit: fhem kennt die sn vom pairen, siehe device details.
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

tndx

Zitat von: SirBen am 19 Juni 2019, 12:10:08
[...] Ich interpretiere die Serielle Ausgabe mal so, dass das Gerät auf die Flash Datei wartet.

Noch eine andere Frage, die Firmware Version ist unverändert (2.4). Deswegen wird da aber nichts blockiert, oder?

Das ist falsch, denn der Bootloader sagt ja "Start App", damit wird die Firmware gebootet.

Die Versionsnummer ist dem Bootloader egal, zumindest mit hmcfgusb wird meines Wissens ohne Rücksicht auf irgendwas geflasht.

papa

Puh - ich versuch mal zu sortieren.

Also die Frequenz liegt schon ganz schön weit weg von der Standardfrequenz. Das könnte auf jeden Fall schon mal der Grund für Probleme sein.

Dann zu Flashen per flash-ota. Da hast Du die FHEM-Gerätebezeicnung und nicht die Serial im Kommando. Das geht so nicht. Du musst zwingend die Serial angeben. Du kannst dann einfach flash-ota starten. Dort kommt dann das "Waiting for device with serial XXXXXXXXXX". Dann machst Du am Gerät nen Reset und dabei den Config-Taster gedrückt halten. Nun sollte der Bootloader in den Updatemodus gehen und der Flashvorgang starten. Wenn das nicht geht, hast Du mit hoher Sicherheit ein Problem mit der Frequenz.
Alternative kannst Du auch in FHEM den Befehl "set HM_120203 fwUpdate onlyEnterBootLoader". Das startet auch das Gerät neu und aktiviert das Update per Bootloader.

Ein komplettes Update aus FHEM ist auch möglich. Allerdings haben ältere Bootloaderversionen das Problem, dass sie auf eine bestimmte Nachricht warten, die FHEM nicht schickt (flash-ota aber schon). Das habe ich vor längerer Zeit mal gefixt. Wenn es also ein aktueller Bootloader ist, sollte das kein Problem sein. Dann kann aber auch wieder das Frequenzproblem zuschlagen.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

SirBen

Guten Morgen,
ich bin leider erst jetzt dazu gekommen, die Frequenz für den Bootloader anzupassen.
Und es hat wirklich daran gelegen! Vielen Dank an alle!

Interessieren würde mich noch, wie man anhand der HEX Zahlen sagen kann, wie die Frequenz ist.  :o

Hier noch meine Vorgehensweise für alle, die später auf diesen Threat stoßen:
Die HEX Datei mit dem Bootloader, die auf den Pro Mini geflasht wurde mit Notepad++ öffnen und nach den HEX Zahlen 0D210E650F50 suchen. Bei mir war die Zahlenkette getrennt durch einen Zeilenumbruch. Daher ist das manchmal etwas schwieriger die richtigen Zahlen zu finden.
Von 0D210E650F50 stehen 21, 65, 50 für die Frequenz. In meinem Fall muss die Frequenz 21, 65, E2 sein. Bei jedem Start vom Pro Mini gibt es die Anzeige der Frequenz (wenn man den Freq Sketch benutzt hatte): Config Freq: 0x2165E2.
Also, Frequenz in der HEX Datei geändert, auf den Pro Mini geflasht, fertig.
In FHEM muss dann nur "set <device> fwUpdate <Pfad inkl eq3 Datei>" angegeben werden und der Pro Mini geht direkt in den OTA Bootloader und startet das Update. Ich musste das Gerät nicht manuell irgendwie in den Modus versetzen.
-> 0A 0A 30 11 310388 120203 CA  - 7057
<- 0A 0A 80 02 120203 310388 00  - 7178
BOOTLOADER


AskSin OTA Bootloader V0.7.0

TX bootloader sequence
Wait for CB msg
Got CB msg
Switch to 100k mode
Receive firmware
...Timeout
CRC OK
Start App
AskSin++ V4.0.2 (Jun 19 2019 10:03:17)
Address Space: 32 - 563
CC init1
CC Version: 04
- ready
Config Freq: 0x2165E2
Switch from 00 to 06
New Level: 0
<- 0E 01 A2 10 120203 310388 06 01 00 00 00  - 2162
-> 0A 01 80 02 310388 120203 00  - 2316
waitAck: 01


Vielen Dank nochmal für die schnelle Hilfe.
Gruß Ben

P.S.: Jetzt gibt es nur noch ein Problem mit dem Longpressverhalten. Aber dazu mache ich lieber ein neues Thema auf.

Tom Major

Zitat von: SirBen am 20 Juni 2019, 07:18:04

Interessieren würde mich noch, wie man anhand der HEX Zahlen sagen kann, wie die Frequenz ist.  :o


siehe CC1101 datasheet Seite 75
fCar = fOsc/2^16*FREQ[23:0]

fOsc sind die 26MHz vom Quarz
FREQ[23:0] sind die 3 8bit Freq. Register (quasi die Hexzahlen)

Hatte mal früher ein Excel für eigene Kalkulationen gemacht:
https://github.com/TomMajor/SmartHome/tree/master/Info/CC1101_Frequenz
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

SirBen

Das passt hier vielleicht nicht so richtig rein, aber ich wollte die anderen Pro minis auch gerne auf OTA Bootloader umstellen und habe in der seriellen Ausgabe folgendes:


AskSin OTA Bootloader V0.7.0

Start App
AskSin++ V4.0.3 (J⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮(⸮⸮+⸮⸮)

⸮Y⸮⸮ͥ⸮⸮iAAQ ⸮ - ready⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮,-⸮⸮׫ ⸮⸮⸮⸮⸮YAAA⸮⸮⸮⸮⸮qA⸮⸮⸮⸮⸮⸮⸮F
N⸮⸮⸮̥⸮⸮⸮⸮⸮⸮⸮<-⸮⸮⸮⸮⸮⸮⸮P&$&T⸮⸮S⸮S⸮‚⸮҂⸮ƀ⸮⸮⸮⸮⸮⸮⸮AAAUAeb6⸮⸮-> ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮&''d⸮⸮VR I⸮⸮⸮R⸮⸮⸮х⸮⸮uAab
-> 10 02 A0 01 310388 120201 00 04 00 00 00 00 00  - 2828
<- 18 02 80 10 120201 310388 02 0A 31 0B 03 0C 88 02 01 15 FF 18 00 00 00  - 2961
-> 10 03 A0 01 310388 120201 01 04 00 00 00 ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮<- 1A 03 A0 10 120201 ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮MHLLHLLH&&$&R i⸮⸮⸮R⸮-> 0A 0⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮P⸮-'$&⸮⸮<- 0E 03 80 10 120201 310388 02 5⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮-> ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮LHLLHL&$$ i⸮⸮⸮R⸮<- 16 04 80 10 120201 310388 01 12 02 01 01 12 02 01 02 00 00 00 00  - 3749
-> 10⸮⸮5 ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮LH⸮L⸮&$$ iʊ⸮R⸮<- 1A 05 A0 10 120201 310388 02 01 00 02 00 03 00 1C 00 04 32 05 64 06 00 07 FF  - 4052
-> 0A 05 8⸮⸮⸮2⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮KHM⸮&'⸮WV⸮⸮⸮iAae⸮<- 1A 0⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮LL&''$&&$&'$&&$F⸮⸮SS⸮⸮S⸮⸮⸮⸮⸮*⸮⸮́⸮⸮⸮⸮⸮⸮5⸮⸮⸮⸮⸮)⸮-⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮&⸮T⸮⸮SR ⸮⸮⸮⸮R⸮⸮⸮⸮⸮⸮⸮⸮⸮)⸮<- 1A 05 A0 10 120201 310388⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮L⸮⸮⸮⸮⸮҂⸮‚⸮΂⸮⸮⸮⸮ ⸮⸮⸮⸮⸮с⸮Ɂ⸮⸮⸮⸮⸮⸮⸮)⸮-⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮&⸮P⸮⸮SR ⸮⸮⸮څ⸮х⸮⸮qAab
<-⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮MH⸮⸮⸮º2⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮Ea⸮AQQAa⸮AUqAAUAqya])⸮-> ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮LL&''d⸮⸮RR ⸮ª⸮R⸮⸮⸮⸮⸮⸮iAE ⸮<-⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮L&&&&&⸮V⸮⸮"⸮eMAe⸮Asf ⸮⸮⸮⸮⸮⸮⸮⸮⸮('d⸮2⸮⸮⸮AAAaaAA]Aiqrp-> 10 ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮LHLLHL
⸮,&$⸮&$F⸮⸮R ⸮⸮⸮⸮R⸮<- 1A 06 A0 10 120201 3103⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮L($&&$⸮⸮‹
⸮  ⸮2⸮5UIAm⸮-> 0A 06 80 02 310388 120201 00  - 5388⸮⸮⸮⸮⸮⸮⸮⸮:⸮⸮⸮⸮<-⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮08 00 09 FF 0A 01 0B 11 0C 12 0D 68 1E 68 0F 00  - 5435
-> 0A 0⸮ ⸮⸮⸮⸮⸮⸮31⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮<- 1A 06 A0 10 120201 31038⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮-> 0A 06 80 02 310388 120201 00  - 5812
waitAck: 01
<- 1A 06 A0 10 120201 310388 02 85 64 86 00 87 FF 88 00 89 ⸮Ơ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮MNMN⸮-> 0A⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮L&&&⸮&$&&$⸮ ɂ⸮⸮R⸮⸮⸮⸮⸮⸮⸮⸮⸮)⸮<- 18 06 80 10 120201 ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮Ơ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮


Der Freq Sketch lief ohne Probleme durch und die Frequenz habe ich in der HEX Datei wieder geändert.

Auf einem weiteren Pro Mini kommt das:
⸮⸮⸮⸮⸮⸮ O⸮⸮ B⸮⸮⸮⸮⸮⸮⸮⸮⸮ ⸮0.7.0

⸮t⸮⸮⸮ ⸮⸮⸮
AskSin++ V4.0.3 (Jun 21 2019 07:06:38)
Address Space: 32 - 563
CC init1
CC Version: 04
- ready
Config Freq: 0x2165E2
Switch from 00 to 06   delay: FFFFFFFF
New Level: 0


Dazu muss ich sagen, dass die beiden neuen Pro Minis von einem anderen Lieferanten sind.

Die Funktion ist allerdings komplett gegeben. Habe beide zu Testzwecken in Betrieb genommen. Mich wundert nur die serielle Ausgabe.

papa

Das sieht stark nach einem Taktproblem aus. Die Rate der Seriellen scheint nicht stabil zu sein. Deshalb kommen manchmal auf der Konsole Zeichen, die nicht korrekt gelesen wurden.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

SirBen

Das bedeutet ein Problem mit dem Pro Mini? Oder gibts da noch was Software seitiges?
Bei dem einen ist es der bootloader beim anderen die Firmware die nicht richtig angezeigt wird.  ???

papa

BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

hkueller

Hallo Zusammen,

Ich hab den gleichen Fehler - OTA Bootloader Meldung kommt noch, Anschließende Firmware Meldungen (ebenfalls HM-LC-BM1-FM) zeigt nur Schrott auf dem Seriellen Monitor.
Auch bei mir handelt es sich um einen billigen Nachbau. Aber das ist kein HW Fehler. In meinem Fall lag das daran, das auf dem Board ein externer Quarz für den 8MHz Takt verwendet wird.
Die Fuses für den OTA stellen aber auf den internen Taktgeber des AVR's um. Ein Reflash auf den Orginal Bootloader mit avrdude funktionierte, aber ein Flaschen per USB/FDDI war danach unmöglich.
Setzt man mit avrdude geänderte Fuses:
avrdude -p m328p -c stk500v2 -P /dev/ttyACM0 -U hfuse:w:0xd0:m -U lfuse:w:0xff:m -U efuse:w:0xfd:m
mag er wieder.
Flasht man die OTA Firmware nun mit diesen Fuses funktioniert der Boot beinahe einwandfrei.

Ich brauch für meine CC1101 als Frequenzsetting 2165F2.
Mit Standard bootloader, Freqtest und anschließendem Flashen des Sketches funktioniert das Problemlos.
per OTA mit (entsprechend für OTA angepasstem) gleichem Sketch, liest weiß dieser (obwohl beim generieren des OTA mit angegeben) nichts von dem Frequenzsetting, und die Kommunikation per HomeMatic funktioniert nur sporadisch.
Beim Startup auf dem Seriellen Monitor kommt auch die Meldung "Config Freq: 0x2165F2" nicht.
Hat hier jemand eine Idee ?
fhem auf Fedora KVM instance mit >300 Homematic Devices