FHEM Forum

hallo martin,

ZitatWenn einer spielen will muss kann er die Zeile
    return "implementation pending";

auskommentieren.

ich möchte spielen und habe die zeile auskommentiert. nun ist der befehl wohl vom modell abhängig. was muss ich noch ändern/ergänzen, sodass ich mit dem

model      HM-LC-Sw1PBU-FM-CustomFW
spielen kann?

das file muss das *.eq3 - file sein? in welchem ordner wird es erwartet? fhem/FHEM?

gruss frank

Du musst das Kommando für dein Device zulassen. Also entweder in HMConfig ändern oder nachtragen, wie bei anderen kommados auch (private FW)

$HMConfig::culHmChanSets{<model>00}{fwUpdate} ="<filename>"

das 00 heisst, dass es das  Device betrifft, aber keinen Kanal.
<model>durch model ersetzen

besten dank.

durch einfügen des codes in zeile 18 der datei 99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm:
{$HMConfig::culHmChanSets{"HM-LC-Sw1PBU-FM-CustomFW00"}{fwUpdate} ="<filename>"};


steht nun der fwupdate befehl beim schalter device zur verfügung.

gruss frank

Hi,

@frank: Danke! Habe ich ins git aufgenommen.

@martin: Schickt FHEM eine Message für den Reboot oder kann/muss man man das Gerät selber neustarten? Die Message müsste ich dann noch implementieren. Spielt die Seriennummer des Gerätes eine Rolle? Aktuell stimmt die nicht mit der HMID überein.


Gruß,
Jan

FHEM schickt eine message zum Umschalten in den bootloader - damit wird auch die Datenrate verzehnfacht (muss das Device unterstützen, FHEM schaltet die CUL um)
Das ist notwendig um die maximale Sendelast nicht zu überschreiten.

Dann kommt der download - das Device macht nach diesem einen reboot - ich denke das ist timergesteuert. Wenn keinen Daten mehr kommen ist reboot angesagt.

Bei alter SW des RT funktioniert das Umschalten in den bootlader nicht per Kommando - daher funktioniert es eigentlich nicht. erst wenn die neue FW drauf ist kann man diese noch einmal einspielen - macht aber keinen sinn, klar.

Die Sereinnummern wird nicht downgeloaded (zum Glück), auch die HMId nicht. Die Seriennummer und die HMId stimmen nie überein.

Hi,

Zitat von: martinp876 am 08 Mai 2014, 13:48:32
FHEM schickt eine message zum Umschalten in den bootloader - damit wird auch die Datenrate verzehnfacht (muss das Device unterstützen, FHEM schaltet die CUL um)
Das ist notwendig um die maximale Sendelast nicht zu überschreiten.

Wie sieht die Message denn aus? Und auf welche Message wartet FHEM dann?

Der Windowsupdater wartet bis sich das Gerät sich meldet mit folgender Message:

14 00 00 10 23 25 B7 00 00 00 00 4B 45 51 30 37 33 34 31 31

In dieser Message ist hinten die Seriennummer drin. Das Windowstool und hmland gucken nur auf diese Nummer. Danach nehmen sie die hmid der Nachricht und nutzen sie um mit dem Gerät zu reden.

Zitat von: martinp876 am 08 Mai 2014, 13:48:32
Dann kommt der download - das Device macht nach diesem einen reboot - ich denke das ist timergesteuert. Wenn keinen Daten mehr kommen ist reboot angesagt.

Ja das ist so. Mach ich auch so. Nach 10s ohne Daten rebootet er.

Zitat von: martinp876 am 08 Mai 2014, 13:48:32
Bei alter SW des RT funktioniert das Umschalten in den bootlader nicht per Kommando - daher funktioniert es eigentlich nicht. erst wenn die neue FW drauf ist kann man diese noch einmal einspielen - macht aber keinen sinn, klar.

Ok das kann meine Firmware bisher auch nicht. Wenn du mir sagst wie die Message aussieht dann implementiere ich das noch.

Zitat von: martinp876 am 08 Mai 2014, 13:48:32
Die Sereinnummern wird nicht downgeloaded (zum Glück), auch die HMId nicht. Die Seriennummer und die HMId stimmen nie überein.

Naja normal kann man aus der Seriennumer die HMID errechnen. Und er schickt sie wie gesagt in der Message oben.

EDIT:
Meinen Code findest du hier: https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L171 Ist nicht sonderlich viel.



Gruß,
Jan

Hi,

unten der Beginn eines Downloads
send "AR" schaltet auf 10fache Geschwindigkeit.

ZitatWenn du mir sagst wie die Message aussieht dann implementiere ich das noch.

send:  As 1F 0B 20CB 1743BF 235EDB 105B11F815470B081A1C191D1BC71C001DB221B623EA
schaltet die Speed hoch. Faktisch werden wohl einige Register gesetzt - im Sender-chip

10:5B 11:F8 15:47 0B:08 1A:1C 19:1D 1B:C7 1C:00 1D:B2 21:B6 23:EA

ZitatNaja normal kann man aus der Seriennumer die HMID errechnen

ehlich? Hätte ich nicht gedacht. Ich denke das ist einfach, wenn er die seriennummer schickt steht die HMId vorne dabei  als absender.



10:40:18.824 send:  As 0A 0A 3011 1743BF 235EDB CA
10:40:19.337 Parse:  A 0A 0A 8002 235EDB 1743BF 00
10:40:19.974 Parse:  A 14 00 0010 235EDB 000000 004B455130353736363035
10:40:20.077 send:  As 1F 0B 20CB 1743BF 235EDB 105B11F815470B081A1C191D1BC71C001DB221B623EA
10:40:20.134 send:  AR
10:40:20.200 send:  As 27 0D 00CA 1743BF 235EDB 0122BDED0BDF9971E49F77E6C46F26D73B39221C152497C69F4417899350
10:40:20.317 send:  As 27 0E 00CA 1743BF 235EDB 5D08704EB8CE86973FBCD24D276C47B084514BB153DCFEFB40DFA466A14E
10:40:20.433 send:  As 27 0F 00CA 1743BF 235EDB CCD4AA80857F368D4FDDC635EEF0090F2BB7E920B9C95E4AD6510175F55F
10:40:20.549 send:  As 27 10 00CA 1743BF 235EDB 918D46BD79B8C88E002ED8B697C6D64FBF27FE8A7F6E2803537683278E37
10:40:20.665 send:  As 27 11 00CA 1743BF 235EDB 743088E07EF695786AE109551393865605DF4AB17D506062D841CE0F53CA
10:40:20.781 send:  As 27 12 00CA 1743BF 235EDB 3476A54FA1B1BD49D0157DA035AB3536C1C5597DD0F319A4A48D12B9F59F
10:40:20.898 send:  As 27 13 00CA 1743BF 235EDB 9CAEE5C549399A281C953285BA8A481C485A4D961A2611AC4D4EA21CCBDE
10:40:21.014 send:  As 27 14 00CA 1743BF 235EDB C276A28E83883CF1DDBF099FDF5CC6DCF2CD0A9C626CC1ACFAA3C7AA8345
10:40:21.131 send:  As 27 15 00CA 1743BF 235EDB D25D3A91DF4DE1AFF17E8D8307A1C9B8F4037300FBD8E18C70339712D7DD
10:40:21.249 send:  As 1F 16 20CA 1743BF 235EDB BFD5401DC9F72E76FC7B23D10370BD3DE2E6317912BF
10:40:21.418 Parse:  A 0A 16 0002 235EDB 1743BF 00
10:40:21.521 send:  As 27 17 00CA 1743BF 235EDB 0122D56AD97D1CA32EC5AA01F77F0E465468EE25A708DD903D9D3758BEBE
10:40:21.637 send:  As 27 18 00CA 1743BF 235EDB D31EA71507CDFF06F68E5045D9A5FCA8506D42B03F1EF3561BDC0A08EFE9
10:40:21.756 send:  As 27 19 00CA 1743BF 235EDB 8D48B75C86D379866E648850CC2FF596A5D3A7C0EF222F883971795BE4D1
10:40:21.875 send:  As 27 1A 00CA 1743BF 235EDB 90AE8895DA8D808024C34C2973B8D63DD5B21395FA27BDA6A787C9125230
10:40:21.994 send:  As 27 1B 00CA 1743BF 235EDB 0FA0262BA79BE52A98B7286BFE20819FB50ADE96646311F7A2453FB5F942
10:40:22.113 send:  As 27 1C 00CA 1743BF 235EDB C5A769AF1F7D6B71DC3AC03E9266A0C8CAB2305D80D220E7EA917548670E
10:40:22.232 send:  As 27 1D 00CA 1743BF 235EDB EBBAD9C811F7E832F60E7DB2C41665A12D44FD2FA9431F9ED3CDAFFE2F15
10:40:22.351 send:  As 27 1E 00CA 1743BF 235EDB EC36F0B1F0F3E1875CAC51A795A55B4D0824C81A1EAA1F0A368F92898320
10:40:22.470 send:  As 27 1F 00CA 1743BF 235EDB 1EC927EA44034509661A237C9951AB441BD495BF0C0C817DD73239BF471C
10:40:22.589 send:  As 1F 20 20CA 1743BF 235EDB D28D0E6BD8AB151C6CF3747906B6E9C6D9A50FC92E46
10:40:22.790 send:  As 0A 7E 3011 1743BF 235EDB CA
10:40:22.817 Parse:  A 0A 20 0002 235EDB 1743BF 00

hallo martin,

hier mal ein paar ergebnisse. das beste endete mit "fail:Block2". hat also zumindestens schon mal gestartet.

2014.05.12 02:02:13.901 4: CUL_send:  cul868As 0A 0A 3011 123ABC ABCDEF CA
2014.05.12 02:02:13.919 4: SND L:0A N:0A F:30 CMD:11 SRC:ccu DST:SwitchPBU02 CA (EnterBootLoader) (,BURST,BIDI)
2014.05.12 02:02:17.619 4: CUL_send:  cul868As 0A 0A 3011 123ABC ABCDEF CA
2014.05.12 02:02:18.534 4: CUL_Parse: cul868 A 14 00 0010 ABCDEF 000000 004B45513031323334353614 -64
2014.05.12 02:02:18.637 4: CUL_send:  cul868As 1F 0B 20CB 123ABC ABCDEF 105B11F815470B081A1C191D1BC71C001DB221B623EA
2014.05.12 02:02:18.658 4: SND L:1F N:0B F:20 CMD:CB SRC:ccu DST:SwitchPBU02 105B11F815470B081A1C191D1BC71C001DB221B623EA (,BIDI)
2014.05.12 02:02:18.825 4: CUL_send:  cul868AR     
2014.05.12 02:02:18.895 4: CUL_send:  cul868As 27 0D 00CA 123ABC ABCDEF 01000C94AA000C94B8200C94E5200C9412210C940F1F0C945E040C943904
2014.05.12 02:02:18.909 4: SND L:27 N:0D F:00 CMD:CA SRC:ccu DST:SwitchPBU02 01000C94AA000C94B8200C94E5200C9412210C940F1F0C945E040C943904 ()
2014.05.12 02:02:19.115 4: CUL_send:  cul868As 27 0E 00CA 123ABC ABCDEF 0C9414040C94E6010C94D2000C94D2000C94D2000C94D2000C94D2000C94
2014.05.12 02:02:19.129 4: SND L:27 N:0E F:00 CMD:CA SRC:ccu DST:SwitchPBU02 0C9414040C94E6010C94D2000C94D2000C94D2000C94D2000C94D2000C94 ()
2014.05.12 02:02:19.334 4: CUL_send:  cul868As 27 0F 00CA 123ABC ABCDEF D2000C94D2000C94D2000C94D2000C943F210C94D2000C944C230C949A23
2014.05.12 02:02:19.348 4: SND L:27 N:0F F:00 CMD:CA SRC:ccu DST:SwitchPBU02 D2000C94D2000C94D2000C94D2000C943F210C94D2000C944C230C949A23 ()
2014.05.12 02:02:19.546 4: CUL_send:  cul868As 27 10 00CA 123ABC ABCDEF 0C94D2000C94D2000C94D2000C94D2000C94D2000C94D20016F0A94B4551
2014.05.12 02:02:19.560 4: SND L:27 N:10 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 0C94D2000C94D2000C94D2000C94D2000C94D2000C94D20016F0A94B4551 ()
2014.05.12 02:02:19.757 4: CUL_send:  cul868As 27 11 00CA 123ABC ABCDEF 3031323334353610410100002E012E0206030D04E905CA063D070C0B060D
2014.05.12 02:02:19.771 4: SND L:27 N:11 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 3031323334353610410100002E012E0206030D04E905CA063D070C0B060D ()
2014.05.12 02:02:19.965 4: CUL_send:  cul868As 27 12 00CA 123ABC ABCDEF 210E650F6A10C811931203153416011730181819161B432156250026112D
2014.05.12 02:02:19.979 4: SND L:27 N:12 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 210E650F6A10C811931203153416011730181819161B432156250026112D ()
2014.05.12 02:02:20.173 4: CUL_send:  cul868As 27 13 00CA 123ABC ABCDEF 353EC3010EE51D1102261E1104181E3E00E61D4000F11DFFFFE71D000000
2014.05.12 02:02:20.187 4: SND L:27 N:13 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 353EC3010EE51D1102261E1104181E3E00E61D4000F11DFFFFE71D000000 ()
2014.05.12 02:02:20.381 4: CUL_send:  cul868As 27 14 00CA 123ABC ABCDEF 0000002100240027002A0000002200250028002B00000020002300260029
2014.05.12 02:02:20.395 4: SND L:27 N:14 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 0000002100240027002A0000002200250028002B00000020002300260029 ()
2014.05.12 02:02:20.593 4: CUL_send:  cul868As 1B 15 20CA 123ABC ABCDEF 000202020202020202040404040404040403
2014.05.12 02:02:20.610 4: SND L:1B N:15 F:20 CMD:CA SRC:ccu DST:SwitchPBU02 000202020202020202040404040404040403 (,BIDI)
2014.05.12 02:02:20.906 4: CUL_send:  cul868As 27 16 00CA 123ABC ABCDEF 010003030303030303010101010101010101020408102040800102040810
2014.05.12 02:02:20.921 4: SND L:27 N:16 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 010003030303030303010101010101010101020408102040800102040810 ()
2014.05.12 02:02:21.113 4: CUL_send:  cul868As 27 17 00CA 123ABC ABCDEF 204080010204081020408080402010080402010000000102000000000000
2014.05.12 02:02:21.127 4: SND L:27 N:17 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 204080010204081020408080402010080402010000000102000000000000 ()
2014.05.12 02:02:21.322 4: CUL_send:  cul868As 27 18 00CA 123ABC ABCDEF 00040307060000000000000000000000000000000000E81DE52411241FBE
2014.05.12 02:02:21.336 4: SND L:27 N:18 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 00040307060000000000000000000000000000000000E81DE52411241FBE ()
2014.05.12 02:02:21.543 4: CUL_send:  cul868As 27 19 00CA 123ABC ABCDEF CFEFD0E1DEBFCDBF12E0A0E0B1E0EAEBFDE402C005900D92AA3CB107D9F7
2014.05.12 02:02:21.558 4: SND L:27 N:19 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 CFEFD0E1DEBFCDBF12E0A0E0B1E0EAEBFDE402C005900D92AA3CB107D9F7 ()
2014.05.12 02:02:21.756 4: CUL_send:  cul868As 27 1A 00CA 123ABC ABCDEF 16E0AAECB2E001C01D92AA31B107E1F711E0C4E5D1E004C02297FE010E94
2014.05.12 02:02:21.770 4: SND L:27 N:1A F:00 CMD:CA SRC:ccu DST:SwitchPBU02 16E0AAECB2E001C01D92AA31B107E1F711E0C4E5D1E004C02297FE010E94 ()
2014.05.12 02:02:21.982 4: CUL_send:  cul868As 27 1B 00CA 123ABC ABCDEF A026C035D107C9F70E943B250C94DB260C940000A0E0B0E0EAEDF0E00C94
2014.05.12 02:02:21.996 4: SND L:27 N:1B F:00 CMD:CA SRC:ccu DST:SwitchPBU02 A026C035D107C9F70E943B250C94DB260C940000A0E0B0E0EAEDF0E00C94 ()
2014.05.12 02:02:22.193 4: CUL_send:  cul868As 27 1C 00CA 123ABC ABCDEF AC26EC01A880B980CA80DB80A114B104C104D10441F484E2A82E89EDB82E
2014.05.12 02:02:22.210 4: SND L:27 N:1C F:00 CMD:CA SRC:ccu DST:SwitchPBU02 AC26EC01A880B980CA80DB80A114B104C104D10441F484E2A82E89EDB82E ()
2014.05.12 02:02:22.406 4: CUL_send:  cul868As 27 1D 00CA 123ABC ABCDEF 8BE5C82E87E0D82EC601B5012DE133EF41E050E00E94832627EA31E440E0
2014.05.12 02:02:22.420 4: SND L:27 N:1D F:00 CMD:CA SRC:ccu DST:SwitchPBU02 8BE5C82E87E0D82EC601B5012DE133EF41E050E00E94832627EA31E440E0 ()
2014.05.12 02:02:22.578 4: CUL_send:  cul868As 1B 1E 20CA 123ABC ABCDEF 50E00E9442267B018C01C601B5012DE133EF
2014.05.12 02:02:22.595 4: SND L:1B N:1E F:20 CMD:CA SRC:ccu DST:SwitchPBU02 50E00E9442267B018C01C601B5012DE133EF (,BIDI)
2014.05.12 02:02:22.762 1: Perfmon: possible freeze starting at 02:02:19, delay is 3.761
2014.05.12 02:02:27.836 4: CUL_send:  cul868Ar

die meisten versuche sahen so aus und endeten mit "fail:notInBootLoader":

2014.05.12 01:35:11.804 4: CUL_send:  cul868As 0A 0A 3011 123ABC ABCDEF CA
2014.05.12 01:35:11.822 4: SND L:0A N:0A F:30 CMD:11 SRC:ccu DST:SwitchPBU02 CA (EnterBootLoader) (,BURST,BIDI)
2014.05.12 01:35:13.091 1: Perfmon: possible freeze starting at 01:35:12, delay is 1.09
2014.05.12 01:35:13.785 4: CUL_send:  cul868As 0A 0A 3011 123ABC ABCDEF CA
2014.05.12 01:35:16.811 4: CUL_send:  cul868Ar     
2014.05.12 01:35:17.658 4: CUL_Parse: cul868 A 14 00 0010 ABCDEF 000000 004B45513031323334353613 -64.5
2014.05.12 01:35:17.670 4: RCV L:14 N:00 F:00 CMD:10 SRC:SwitchPBU02 DST:broadcast 004B455130313233343536 (INFO_SERIAL SERIALNO:KEQ0123456) ()
2014.05.12 01:35:18.259 4: CUL_Parse: cul868 A 0B 96 A258 1BF81B D4D4D4 0000F5 -79.5
2014.05.12 01:35:18.274 4: RCV L:0B N:96 F:A2 CMD:58 SRC:Thermostat.WZ DST:TCControler.WZ 0000 (ClimateEvent CMD:0x00 ValvePos:0) (,WAKEMEUP,BIDI,RPTEN)
2014.05.12 01:35:18.575 4: CUL_send:  cul868As 0A 0A 3011 123ABC ABCDEF CA
2014.05.12 01:35:18.705 4: CUL_Parse: cul868 A 0E 96 8002 D4D4D4 1BF81B 01010000005E -27
2014.05.12 01:35:22.776 4: CUL_send:  cul868As 0A 0A 3011 123ABC ABCDEF CA


das verhalten ist wahrscheinlich so, wie du es beim rt mit dem 1. update beschrieben hast. die einzige möglichkeit das update überhaupt zu starten, besteht darin, den set fwupdate befehl als erstes zu starten und quasi sofort danach das device in den update-modus bekommen. ansonsten hat der cul bereits mit cul868Ar umgeschaltet, obwohl eigentlich noch keine antwort des bootloaders gekommen ist! müsste der cul mit der frequenzumschaltung nicht auf die antwort des device warten?
sonst machen die ca 15 sekunden updatemodus des cul ja gar keinen sinn. übigens wäre eine deutlich längere zeit sehr wünschenswert. meinen schalter musste ich zum testen mit cul extra aus der wand ausbauen, um überhaupt mit der zeit klar zu kommen. könnte man den befehl nicht so ähnlich gestalten wie bei "hmPairForSec". also zb "hmUpdateForSec 300".

mit dem windows-update-tool und dem hmusb funktioniert der bootloader von jan übrigens hervorragend. sozusagen müsste/sollte man das update mit cul eigentlich auch noch besser zum laufen bekommen können.

gruss frank

kannst du den update mit windows-sw loggen?

Moin Martin,

am besten du guckst in den Quellcode des Schalters. Das Verhalten ist genau wie beim Thermostat:
1. Gerät rebooten (manuell)
2. Gerät sendet Bereit Nachricht (noch im 1k Mode): https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L176
3. Gerät wartet auf 0xCB Nachricht (auch noch im 1k Mode): https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L213
4. Danach wechselt das Gerät in den 100k Mode (bzw setzt die Register aus der Nachricht): https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L225
5. Das Gerät wartet, dass der Flasher die 0xCB Nachricht im 100k Mode wiederholt: https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L250
6. Danach wartet das Gerät auf die Blöcke in weiteren 0xCA Nachrichten: https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L286
7. Gerät startet neu nach einem Timeout


Gruß,
Jan

Moin,

so ich habe mal etwas gebastelt. Allerdings blind da ich gerade auf Dienstreise bin. Wenn das Gerät jetzt eine 0xCB Nachricht bekommt rebootet er und der Bootloader sollte das Update übernehmen. Dafür habe ich einen neuen branch im git erstellt: https://github.com/jabdoa2/Asksin_HM_LC_Sw1PBU_FM/tree/updateReboot (wenn ihr den Code geclont habt einfach git checkout updateReboot machen).

Vorgeben ist jetzt so (nur 1 geändert):
1. Gerät rebootet wenn es 0xCB Nachricht bekommt
2. Gerät sendet Bereit Nachricht (noch im 1k Mode): https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L176
3. Gerät wartet auf 0xCB Nachricht (auch noch im 1k Mode): https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L213
4. Danach wechselt das Gerät in den 100k Mode (bzw setzt die Register aus der Nachricht): https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L225
5. Das Gerät wartet, dass der Flasher die 0xCB Nachricht im 100k Mode wiederholt: https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L250
6. Danach wartet das Gerät auf die Blöcke in weiteren 0xCA Nachrichten: https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L286
7. Gerät startet neu nach einem Timeout

Muss ich in dem Fall 2 und 3 skippen oder ist das richtig so? Gibt es irgendwo einen Mitschnitt vom FHEM Update ohne vorherigen Reboot?


Gruß,
Jan

hallo martin,

anbei das log.

schalter ABCDEF/KEQ0123456
alle 3 io haben die hmid 123ABC und sind mit einer vccu 123ABC assigned.

schalter habe ich vorher unpaired von fhem, damit keiner dazwischen funkt.
hmlan logged den schalter auf 10k.
cul logged im modus raw AR auf 100k.
hmusb hängt am windows laptop und macht das update über das homematic-update-tool.

komischerweise funkt der hmusb über windows mit der in fhem vergebenen hmid. hätte ich nicht gedacht.

edit:
wenn das windows-tool scharf gemacht wird, habe ich "unendlich" viel zeit, den update modus am device zu starten. ab dann gibt es funkverkehr.

gruss frank

Hallo,

ich wollte mich auch mal einklinken. Wenn ich das Richtig verstehe, könnten dann Fremde ein solche Message abschicken und dann eine fremde Firmware aufspielen. Ich weis nicht ob das so gut ist. Wenn das nur durch drücken auf den Config button neu gestartet werden kann fände ich das besser.
Wenn mich jemand ärgert indem er mein Licht ein oder Ausschaltet ist das eine Sache, wenn aber eine andere Firmware aufgespielt werden kann, ist das noch mal eine ganz andere Qualität Schabernack, die man dann machen kann und vermutlich auch schwer zu entdecken.

Grüße

@jan

ZitatWenn das Gerät jetzt eine 0xCB Nachricht bekommt rebootet er und der Bootloader sollte das Update übernehmen.

hört sich klasse an. werde ich mal mit einem schalter probieren.

ZitatGibt es irgendwo einen Mitschnitt vom FHEM Update ohne vorherigen Reboot?

verstehe ich nicht ganz. welches update und wer macht reboot.


@samsi

ZitatWenn ich das Richtig verstehe, könnten dann Fremde ein solche Message abschicken und dann eine fremde Firmware aufspielen.

das müsste natürlich vermieden werden. oder den bootloader-modus einstellbar machen (funkgesteuert/manuell)

gruss frank

hi,

@samsi - sicherheit
wenn man das ding manuell in den bootloader versetzen muss ist man im Haus - also kein Problem.
HM kann dies auch per message machen - es liegt nicht unserer Hand, diesen mode zu verbieten. Beachte, dass du hier AES einschalten kannst - außerdem kannst du überwachen mit den sabotage-messages.
Mehr geht sytembedingt nicht - meine ich zumindest. An fhem scheitert es erst einmal nicht.

@jab
das mit CB "auto-umschalten" ist wohl auch bei dem RTs "neu" mit der letzten FW. Da die selbstgebauten Devices kein AES unterstützen kann man sich hier überlegen, ob man es zulässt (samsi's Befürchtung). FHEM sollte es können - da es HM unterstützen soll...

@Frank,
prima log. Ich werde gleich einmal experimentieren
Gruss Martin

@martinp876

Ich hab ja auch nur die selbst geschriebene FW gemeint ;) deswegen hatte ich mich ja auch auf den Lichtschalter bezogen ;)

Das wir an den Thermostaten von HM nichts ändern können, ist schon klar. Das muss sich eq3 überlegen ob sie das zulassen wollen, das nicht AES aktivierte Thermostate evtl. durch fremde Kaputt geflasht werden können ;) und Ottonormaluser das evtl. gar nicht rafft und die Dinger dann als defekt zurückschickt ;)

so, das Kommando ist jetzt freigeschaltet.

set <device> fwUpdate <filename> [<waittime>]
waittime kann optional gesetzt werden - es ist die Zeit, die man hat, das Device in den updatemode zu versetzen.
Parallel wird es automatisch probiert. Ein RT mit FW 1.2 wird quasi sofort starten, egal welche Zeit man eingibt

Gruss Martin

Zitatso, das Kommando ist jetzt freigeschaltet.

cool.  :)

auch für hmusb, oder nur cul?

gruss frank

hmUSB noch nicht.
Du kannst aber die Sperre entfernen und testen
#    return "only thru CUL " if (!$hash->{IODev}->{TYPE}
#                                ||($hash->{IODev}->{TYPE} ne "CUL"));

Der Code ist drin - testen kann ich mangels device nicht.
Wie unterscheide ich HMUSB und HMLAN? hast du ein list des HMUSB? damit ich HMLAN blocken kann.

et voila!

Internals:
   DEF        127.0.0.1:1234
   DeviceName 127.0.0.1:1234
   FD         10
   HM_CMDNR   41
   NAME       hmusb1
   NR         28
   NTFY_ORDER 50-hmusb1
   PARTIAL
   RAWMSG     E1BF81B,0000,0072E9A2,FF,FFC4,E2A2581BF81BD4D4D400A4
   RSSI       -60
   STATE      opened
   TYPE       HMLAN
   XmitOpen   1
   assignedIDs 24AF1D,1DF7C6,266A86,1D252E,1DFDA5,1BF81B,1F64D8,1936FF
   assignedIDsCnt 8
   assignedIDsReport 8
   firmware   0.967
   hmusb1_MSGCNT 998
   hmusb1_TIME 2014-05-12 15:34:44
   msgKeepAlive dlyMax:5.554 bufferMin:0
   msgLoadEst 1hour:5% 10min steps: 0/0/0/0/0/1
   owner      123ABC
   owner_CCU  ccu
   serialNr   JEQ0121054
   uptime     000 02:05:36.322
   .clientArray:
     CUL_HM
   Readings:
     2014-05-12 13:30:48   Xmit-Events     ok:1
     2014-05-12 13:30:48   cond            ok
     2014-05-12 13:30:16   prot_disconnected last
     2014-05-12 13:30:16   prot_init       last
     2014-05-12 13:30:48   prot_ok         last
     2014-05-06 04:10:04   prot_timeout    last
   Assids:
     1936FF     1
     1BF81B     1
     1D252E     1
     1DF7C6     1
     1DFDA5     1
     1F64D8     1
     24AF1D     1
     266A86     1
   Helper:
     000001:
       flg        0
     123abc:
       flg        0
     1936ff:
       chn        01
       flg        0
       msg
       name       Thermostat.Bad
       to         1399894309.25274
     1bf81b:
       chn        01
       flg        0
       msg
       name       Thermostat.WZ
       to         1399894557.68309
     1d252e:
       chn        01
       flg        0
       msg
       name       Thermostat.Kueche
       to         1399898535.08203
     1df7c6:
       chn        01
       flg        0
       msg
       name       Tuer.WZ.Terrasse
       to         1399898797.97598
     1dfda5:
       chn        01
       flg        0
       msg
       name       Thermostat.SZ
       to         1399894398.71626
     1f64d8:
       chn        01
       flg        0
       msg
       name       DimUP01
       to         1399894260.93593
     24af1d:
       chn        03
       flg        0
       msg
       name       SwitchES01
       to         1399894274.47335
     266a86:
       chn        03
       flg        0
       msg
       name       DimPBU01
       to         1399894260.01187
     Bm:
       Hmlan_notify:
         cnt        3722
         dmx        0
         mAr        HASH(0xb43f98); HASH(0xd4fe80)
         max        32
         tot        48
       Hmlan_read:
         cnt        1106
         dmx        0
         mAr        HASH(0xb43f98)
         max        1512
         tot        38678
       Hmlan_set:
         cnt        151
         dmx        0
         mAr        HASH(0xb43f98); hmusb1; ?
         max        33
         tot        36
     K:
       BufMin     0
       DlyMax     5.554
       Next       1399901714.76101
       Start      1399901689.76101
     Log:
       all        0
       sys        0
       ids:
     Q:
       HMcndN     0
       answerPend 0
       hmLanQlen  1
       keepAliveRec 1
       keepAliveRpt 0
       apIDs:
       Cap:
         0          375
         1          350
         2          400
         3          225
         4          619
         5          400
         last       3
         sum        2369
     Ref:
       hmtL       7536322
       kTs        0
Attributes:
   event-on-change-reading .*
   group      IO-Devices
   hmId       123ABC
   hmLanQlen  1_min
   hmProtocolEvents 3_dumpTrigger
   logIDs
   room       90_Technik
   verbose    0
   wdTimer    25

hallo martin,

ich habe die neue version gerade getestet. mit manuellem reboot vom device und waittime=60 klappt der update start nun sauber. aber leider wieder abbruch mit "fail:Block2".

der fehler liegt, glaube ich, bei den msg-nummern. beim log vom windows-tool bleibt die msg-nummer bei den "ca" messages pro block gleich. bei deiner version wird jede message mit neuer nummer gesendet.

hier der log:

2014.05.12 16:25:22.635 4: CUL_send:  cul868As 0A 0A 3011 123ABC ABCDEF CA
2014.05.12 16:25:22.653 4: SND L:0A N:0A F:30 CMD:11 SRC:ccu DST:SwitchPBU02 CA (EnterBootLoader) (,BURST,BIDI)
2014.05.12 16:25:23.965 0: HMLAN_Parse: hmlan1 R:E123ABC   stat:0000 t:02707C8C d:FF r:FFDE     m:0A 3011 123ABC ABCDEF CA
2014.05.12 16:25:24.859 4: CUL_send:  cul868As 0A 0A 3011 123ABC ABCDEF CA
2014.05.12 16:25:25.247 0: HMLAN_Parse: hmlan1 R:E123ABC   stat:0000 t:0270853B d:FF r:FFDE     m:0A 3011 123ABC ABCDEF CA
2014.05.12 16:25:30.606 4: CUL_send:  cul868As 0A 0A 3011 123ABC ABCDEF CA
2014.05.12 16:25:30.994 0: HMLAN_Parse: hmlan1 R:E123ABC   stat:0000 t:02709BAF d:FF r:FFDF     m:0A 3011 123ABC ABCDEF CA
2014.05.12 16:25:32.559 4: CUL_Parse: cul868 A 0C 78 8670 1DFDA5 000000 008E4418 -62
2014.05.12 16:25:32.680 4: CUL_Parse: cul868 A 09 78 A112 123ABC 1DFDA5 5A -29
2014.05.12 16:25:32.813 4: CUL_Parse: cul868 A 0A 78 8002 1DFDA5 123ABC 0019 -61.5
2014.05.12 16:25:36.364 4: CUL_Parse: cul868 A 0B 86 A258 B4B4B4 1CE9F5 03D14E -35
2014.05.12 16:25:36.447 4: CUL_Parse: cul868 A 0E 86 8102 1CE9F5 B4B4B4 0101A4202E21 -57.5
2014.05.12 16:25:36.484 4: CUL_send:  cul868As 0A 0A 3011 123ABC ABCDEF CA
2014.05.12 16:25:36.507 4: CUL_Parse: cul868 A 0B 86 A258 B4B4B4 1CE9F5 03D14E -35
2014.05.12 16:25:36.872 0: HMLAN_Parse: hmlan1 R:E123ABC   stat:0000 t:0270B2A5 d:FF r:FFDE     m:0A 3011 123ABC ABCDEF CA
2014.05.12 16:25:37.065 4: CUL_Parse: cul868 A 16 89 A410 1CE9F5 B4B4B4 0400000000000509000A0F000020 -58
2014.05.12 16:25:37.406 4: CUL_Parse: cul868 A 14 00 0010 ABCDEF 000000 004B4551303132333435361C -60
2014.05.12 16:25:37.509 4: CUL_send:  cul868As 0F 0B 00CB 123ABC ABCDEF 105B11F81547
2014.05.12 16:25:37.523 4: SND L:0F N:0B F:00 CMD:CB SRC:ccu DST:SwitchPBU02 105B11F81547 ()
2014.05.12 16:25:37.618 4: CUL_send:  cul868AR     
2014.05.12 16:25:37.797 0: HMLAN_Parse: hmlan1 R:EABCDEF   stat:0000 t:0270B4C2 d:FF r:FFBF     m:00 0010 ABCDEF 000000 004B455130313233343536
2014.05.12 16:25:37.900 4: CUL_send:  cul868As 27 0D 00CA 123ABC ABCDEF 01000C94AA000C94B8200C94E5200C9412210C940F1F0C945E040C943904
2014.05.12 16:25:37.915 4: SND L:27 N:0D F:00 CMD:CA SRC:ccu DST:SwitchPBU02 01000C94AA000C94B8200C94E5200C9412210C940F1F0C945E040C943904 ()
2014.05.12 16:25:38.074 4: CUL_send:  cul868As 27 0E 00CA 123ABC ABCDEF 0C9414040C94E6010C94D2000C94D2000C94D2000C94D2000C94D2000C94
2014.05.12 16:25:38.088 4: SND L:27 N:0E F:00 CMD:CA SRC:ccu DST:SwitchPBU02 0C9414040C94E6010C94D2000C94D2000C94D2000C94D2000C94D2000C94 ()
2014.05.12 16:25:38.245 4: CUL_send:  cul868As 27 0F 00CA 123ABC ABCDEF D2000C94D2000C94D2000C94D2000C943F210C94D2000C944C230C949A23
2014.05.12 16:25:38.259 4: SND L:27 N:0F F:00 CMD:CA SRC:ccu DST:SwitchPBU02 D2000C94D2000C94D2000C94D2000C943F210C94D2000C944C230C949A23 ()
2014.05.12 16:25:38.419 4: CUL_send:  cul868As 27 10 00CA 123ABC ABCDEF 0C94D2000C94D2000C94D2000C94D2000C94D2000C94D20016F0A94B4551
2014.05.12 16:25:38.433 4: SND L:27 N:10 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 0C94D2000C94D2000C94D2000C94D2000C94D2000C94D20016F0A94B4551 ()
2014.05.12 16:25:38.595 4: CUL_send:  cul868As 27 11 00CA 123ABC ABCDEF 3031323334353610410100002E012E0206030D04E905CA063D070C0B060D
2014.05.12 16:25:38.608 4: SND L:27 N:11 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 3031323334353610410100002E012E0206030D04E905CA063D070C0B060D ()
2014.05.12 16:25:38.767 4: CUL_send:  cul868As 27 12 00CA 123ABC ABCDEF 210E650F6A10C811931203153416011730181819161B432156250026112D
2014.05.12 16:25:38.781 4: SND L:27 N:12 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 210E650F6A10C811931203153416011730181819161B432156250026112D ()
2014.05.12 16:25:38.938 4: CUL_send:  cul868As 27 13 00CA 123ABC ABCDEF 353EC3010EE51D1102261E1104181E3E00E61D4000F11DFFFFE71D000000
2014.05.12 16:25:38.952 4: SND L:27 N:13 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 353EC3010EE51D1102261E1104181E3E00E61D4000F11DFFFFE71D000000 ()
2014.05.12 16:25:39.113 4: CUL_send:  cul868As 27 14 00CA 123ABC ABCDEF 0000002100240027002A0000002200250028002B00000020002300260029
2014.05.12 16:25:39.127 4: SND L:27 N:14 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 0000002100240027002A0000002200250028002B00000020002300260029 ()
2014.05.12 16:25:39.284 4: CUL_send:  cul868As 1B 15 20CA 123ABC ABCDEF 000202020202020202040404040404040403
2014.05.12 16:25:39.301 4: SND L:1B N:15 F:20 CMD:CA SRC:ccu DST:SwitchPBU02 000202020202020202040404040404040403 (,BIDI)
2014.05.12 16:25:39.457 0: HMLAN_Parse: hmlan1 R:E123ABC   stat:0000 t:0270B54D d:FF r:FFDE     m:0B 00CB 123ABC ABCDEF 105B11F81547
2014.05.12 16:25:39.566 4: CUL_send:  cul868As 27 16 00CA 123ABC ABCDEF 010003030303030303010101010101010101020408102040800102040810
2014.05.12 16:25:39.580 4: SND L:27 N:16 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 010003030303030303010101010101010101020408102040800102040810 ()
2014.05.12 16:25:39.741 4: CUL_send:  cul868As 27 17 00CA 123ABC ABCDEF 204080010204081020408080402010080402010000000102000000000000
2014.05.12 16:25:39.755 4: SND L:27 N:17 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 204080010204081020408080402010080402010000000102000000000000 ()
2014.05.12 16:25:39.912 4: CUL_send:  cul868As 27 18 00CA 123ABC ABCDEF 00040307060000000000000000000000000000000000E81DE52411241FBE
2014.05.12 16:25:39.927 4: SND L:27 N:18 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 00040307060000000000000000000000000000000000E81DE52411241FBE ()
2014.05.12 16:25:40.084 4: CUL_send:  cul868As 27 19 00CA 123ABC ABCDEF CFEFD0E1DEBFCDBF12E0A0E0B1E0EAEBFDE402C005900D92AA3CB107D9F7
2014.05.12 16:25:40.098 4: SND L:27 N:19 F:00 CMD:CA SRC:ccu DST:SwitchPBU02 CFEFD0E1DEBFCDBF12E0A0E0B1E0EAEBFDE402C005900D92AA3CB107D9F7 ()
2014.05.12 16:25:40.256 4: CUL_send:  cul868As 27 1A 00CA 123ABC ABCDEF 16E0AAECB2E001C01D92AA31B107E1F711E0C4E5D1E004C02297FE010E94
2014.05.12 16:25:40.269 4: SND L:27 N:1A F:00 CMD:CA SRC:ccu DST:SwitchPBU02 16E0AAECB2E001C01D92AA31B107E1F711E0C4E5D1E004C02297FE010E94 ()
2014.05.12 16:25:40.428 4: CUL_send:  cul868As 27 1B 00CA 123ABC ABCDEF A026C035D107C9F70E943B250C94DB260C940000A0E0B0E0EAEDF0E00C94
2014.05.12 16:25:40.442 4: SND L:27 N:1B F:00 CMD:CA SRC:ccu DST:SwitchPBU02 A026C035D107C9F70E943B250C94DB260C940000A0E0B0E0EAEDF0E00C94 ()
2014.05.12 16:25:40.600 4: CUL_send:  cul868As 27 1C 00CA 123ABC ABCDEF AC26EC01A880B980CA80DB80A114B104C104D10441F484E2A82E89EDB82E
2014.05.12 16:25:40.614 4: SND L:27 N:1C F:00 CMD:CA SRC:ccu DST:SwitchPBU02 AC26EC01A880B980CA80DB80A114B104C104D10441F484E2A82E89EDB82E ()
2014.05.12 16:25:40.774 4: CUL_send:  cul868As 27 1D 00CA 123ABC ABCDEF 8BE5C82E87E0D82EC601B5012DE133EF41E050E00E94832627EA31E440E0
2014.05.12 16:25:40.788 4: SND L:27 N:1D F:00 CMD:CA SRC:ccu DST:SwitchPBU02 8BE5C82E87E0D82EC601B5012DE133EF41E050E00E94832627EA31E440E0 ()
2014.05.12 16:25:40.945 4: CUL_send:  cul868As 1B 1E 20CA 123ABC ABCDEF 50E00E9442267B018C01C601B5012DE133EF
2014.05.12 16:25:40.961 4: SND L:1B N:1E F:20 CMD:CA SRC:ccu DST:SwitchPBU02 50E00E9442267B018C01C601B5012DE133EF (,BIDI)
2014.05.12 16:25:41.128 1: Perfmon: possible freeze starting at 16:25:38, delay is 3.128
2014.05.12 16:25:46.183 4: CUL_send:  cul868Ar     
2014.05.12 16:25:46.904 4: CUL_Parse: cul868 A 0E 00 A410 ABCDEF 123ABC 06040000001D -59.5
2014.05.12 16:25:46.917 4: RCV L:0E N:00 F:A4 CMD:10 SRC:SwitchPBU02 DST:ccu 0604000000 (INFO_ACTUATOR_STATUS RSSI:0 CHANNEL:0x04 STATUS:0x00 UNKNOWN:0x00) (,CFG,BIDI,RPTEN)
2014.05.12 16:25:47.007 4: CUL_send:  cul868As 0A 00 8002 123ABC ABCDEF 00
2014.05.12 16:25:47.021 4: SND L:0A N:00 F:80 CMD:02 SRC:ccu DST:SwitchPBU02 00 (ACK) (,RPTEN)
2014.05.12 16:25:47.098 0: HMLAN_Parse: hmlan1 R:EABCDEF   stat:0000 t:0270D9DD d:FF r:FFBF     m:00 A410 ABCDEF 123ABC 0604000000
2014.05.12 16:25:47.110 0: HMLAN_Parse: hmlan1 R:E123ABC   stat:0000 t:0270DA63 d:FF r:FFDE     m:00 8002 123ABC ABCDEF 00
2014.05.12 16:25:47.624 0: HMLAN_Parse: hmlan1 R:EABCDEF   stat:0000 t:0270DC97 d:FF r:FFBF     m:01 A410 ABCDEF 123ABC 0603000000
2014.05.12 16:25:47.728 4: CUL_send:  cul868As 0A 01 8002 123ABC ABCDEF 00


@jan
da sich der befehl geändert hat, muss zeile 18 in 99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm geändert werden:
{$HMConfig::culHmChanSets{"HM-LC-Sw1PBU-FM-CustomFW00"}{fwUpdate} ="<filename> <bootTime> ..."};

@all
wer heute testen möchte, muss 10_CUL_HM.pm und HMConfig.pm aus svn holen und 99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm ändern.


gruss frank

da fehlt das ACK des Device.
Ich denke, das Umschalten des Device hat nicht funktioniert. Das Device meldet sich nicht.
hast du es noch einmal probiert?

Zitathast du es noch einmal probiert?

2 weitere versuche liefern exakt das selbe log wie eben. an der gleichen stelle mit der selben msgnummer ist ende.

Zitatda fehlt das ACK des Device.

stimmt. die cb msg am anfang wird schon nicht beantwortet. bei dir ist es 0x00CB beim windows-tool heisst es 0x20CB.

cul version
2014.05.12 16:25:37.509 4: CUL_send:  cul868As 0F 0B 00CB 123ABC ABCDEF 105B11F81547

windows version
2014.05.12 10:38:22.553 4: CUL_Parse: cul868 A 0F 43 20CB 123ABC ABCDEF 105B11F815472E -51
2014.05.12 10:38:22.562 4: RCV L:0F N:43 F:20 CMD:CB SRC:ccu DST:SwitchPBU02 105B11F81547 (,BIDI)
2014.05.12 10:38:22.790 4: CUL_Parse: cul868 A 0A 43 8002 ABCDEF 123ABC 0021 -57.5
2014.05.12 10:38:22.799 4: RCV L:0A N:43 F:80 CMD:02 SRC:SwitchPBU02 DST:ccu 00 (ACK) (,RPTEN)

oder das umschalten in den 100k modus geht zu schnell. sollte man da nicht auch erst auf antwort warten? aber eigentlich hätte der hmlan das auch mitbekommen müssen, falls es an 100k liegen würde.

die CUL schaltet um - HMLAN kann die messages ja nicht mehr sehen.

Das Device schaltet wohl nicht um.
Der Ablauf nach WinSW ist, dass das device umgeschaltet wird (msg ohne ACK-request) und nach dem Umschalten kommt die gleiche msg noch einmal - mit ack-request.
Ist alles klar soweit - das ack der ersten message wuerde nie ankommen, da es mit anderer Geschwindigkeit gesendet wird. Die 2. Message schaltet nichts mehr - ist aber ein Test, dass das Device auch geschaltet hat.
Machen kann man nichts mehr - ausser noch einmal warten - vielleicht ist das der Trick - dein System ist schneller (oder das Device langsamer) - die CUL faengt zu frueh das senden an. Wenn die erste message nicht erkannt wird gibt es Probleme.

Sicher ist, dass die 2. "schaltmessage" nach dem speed-change nicht notwendig ist - aber vielleicht hilfreich um nach dem Umschalten und vor dem Beginn zu synchronisieren.
Einbauen macht nur sinn, wenn man die message bei Bedarf mehrfach wiederholt - bis eben das Device "high-speed" bereit ist. Werde einmal experimentieren
Gruss Martin

moin martin,

ZitatSicher ist, dass die 2. "schaltmessage" nach dem speed-change nicht notwendig ist - aber vielleicht hilfreich um nach dem Umschalten und vor dem Beginn zu synchronisieren.

ich glaube wir waren gestern ein wenig blind.  8)

die 2. schaltmsg mit0x20CB senden wir gar nicht. ist wohl doch wichtig.

gruss frank

Zitatdie 2. schaltmsg mit0x20CB senden wir gar nicht. ist wohl doch wichtig.

denke ich nicht. Mein RT braucht es definitiv nicht - was ich gestern beschrieben habe. Das ist die message zum Umschalten der Datenrate. Die 2. kommt bereits mit der neuen Datenrate - also wenn schon geschaltet wurde.
Wie gesagt - kann ein zeitliches Problem sein.

p.s.
baue doch einmal ein delay ein - Zeile 4948 in CUL_HM
  if ($hash->{IODev}->{TYPE} ne "CUL"){
    my $msg = sprintf("G%02X",$speed);
    IOWrite($hash, "cmd",$msg);
    select(undef, undef, undef, 0.1);
  }

ZitatWie gesagt - kann ein zeitliches Problem sein.

oder jan hat es in seinem bootloader als zwingend notwendig eingebaut.

Moin,

ich habe das gestern schon mal geschrieben. Das Vorgehen ist so (jeder Schritt ist erforderlich):

Zitat von: jab am 12 Mai 2014, 10:24:36
1. Gerät rebootet wenn es 0xCB Nachricht bekommt
2. Gerät sendet Bereit Nachricht (noch im 10k Mode): https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L176
3. Gerät wartet auf 0xCB Nachricht. Kein ACK! (auch noch im 10k Mode): https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L213
4. Danach wechselt das Gerät in den 100k Mode (bzw setzt die Register aus der Nachricht): https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L225
5. Das Gerät wartet, dass der Flasher die 0xCB Nachricht im 100k Mode wiederholt und sendet ACK: https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L250
6. Danach wartet das Gerät auf die Blöcke in weiteren 0xCA Nachrichten. Am Ende des Blocks sendet er ein ACK: https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L286
7. Gerät startet neu nach einem Timeout

Verweise auf den Quellcode sind enthalten. Bisher alles sehr einfach gehalten und das Verhalten von flash-ota und dem Windowstool optimiert. Die Message ID muss immer gleich bleiben innerhalb eines Blocks. Am Ende sendet das Gerät erst ein ACK. Ansonsten erkennt der Bootloader die Blockboundaries nicht.

Was muss ich Ändern für FHEM? Vor dem Reboot durch die 0xCB Nachricht (1) kann ich ein ACK senden (muss das Gerät mit dem Reboot warten). Danach soll es direkt mit 6 weitermachen?



Gruß,
Jan

habe gerade die erste firmware für den custom-fw-schalter über cul und fhem geflasht.  :) :) :)

Hallo Jan,

mein RT lässt sich Flashen (ok - ist 1.2 auf 1.2)  auch ohne die 2. CB.
Die Boundarrays werden erkannt, das Device sendet brav alle geforderten ACKs für die Blöcke.

Der "normale" Ablauf ist:
1) System am laufen
2) FHEM sendet 3011<addr><addr>CA => device springt in den Bootloader
3) FHEM sendet "CB" um die Datenrate zu erhöhen - Es wird kein ACK angefordert - das Device muss dies nicht berücksichtgen, das macht die Zentrale => device schaltet um
4) FHEM 'könnte' CB mit ACK-request wiederholen. Operationell passiert nichts, ausser dass man nun weiss, dass das Device "schnell" ist.
5) FHEM beginnt mit dem Senden der CA messages. Die messagenummern kommen fortlaufend. Dei ersten beiden Bytes sind die Länge des Blocks in Byte. Sollte die Länge nicht stimmen - also nicht mit einer message enden - darf der block nicht "geackt" werden.

=> das Device wird immer ein ACK senden, wenn die Zentrale es anfordert - die Zentrale wird es an jedem BlockEnde anfordern.

@Frank,

wie hast du es geschafft? Mit dem Timer oder auf einem anderen Weg? Hast du Änderungen für Jan eingebaut?


Gruss Martin


4)

Zitatwie hast du es geschafft? Mit dem Timer oder auf einem anderen Weg? Hast du Änderungen für Jan eingebaut?

so wie der bootloader von jan es erwartet. so wie es in meinem log vom windowstool passiert:


1. ich sende die msg 0x20CB im 100k modus. dieser teil ist noch nicht stabil, da vor dem weiteren senden nicht auf antwort geprüft wird. es kommt ab und zu vor das der cul schon anfängt die blöcke zu senden bevor der schalter geantwortet hat. dann geht es schief.
  if ($step == 0){#check bootloader entered - now change speed
    return if ($mIn =~ m/$mNoA..02$dst${id}00/);
    Log3 $name,2,"CUL_HM fwUpdate $name entered mode - switch speed";
    $mNo = (++$mNo)%256; $mNoA = sprintf("%02X",$mNo);
    CUL_HM_SndCmd($hash,"${mNoA}00CB$id${dst}105B11F81547");
#    CUL_HM_SndCmd($hash,"${mNoA}20CB$id${dst}105B11F815470B081A1C191D1BC71C001DB221B623EA");
    select(undef, undef, undef, (0.04));
    CUL_HM_FWupdateSpeed($name,100);
    select(undef, undef, undef, (0.04));


    $mNo = (++$mNo)%256; $mNoA = sprintf("%02X",$mNo);
    CUL_HM_SndCmd($hash,"${mNoA}20CB$id${dst}105B11F81547");
    select(undef, undef, undef, (0.2));

#    $mNo = (++$mNo)%256; $mNoA = sprintf("%02X",$mNo);


    $modules{CUL_HM}{helper}{updateStep}++;
    $modules{CUL_HM}{helper}{updateNbr} = $mNo;
    RemoveInternalTimer("fail:notInBootLoader");
    #InternalTimer(gettimeofday()+0.3,"CUL_HM_FWupdateSim","${dst}${id}00",0);
    InternalTimer(gettimeofday()+5,"CUL_HM_FWupdateEnd","fail:SpeedChangeFailed",0);
  }

2. die msg nummern pro Block bleiben gleich. => einfach den msg zähler aus der foreach schleife.
auch hier gibt es probleme,  wenn nach dem senden von 0x20CA nicht auf antwort gewartet wird, bevor es weiter geht.
    else{# programming continue
      my $bl = ${$modules{CUL_HM}{helper}{updateData}}[$step-1];
      my $no = scalar(@{$bl});
      Log3 $name,5,"CUL_HM fwUpdate write block $step of $blocks: $no messages";


      $mNo = (++$mNo)%256; $mNoA = sprintf("%02X",$mNo);

      foreach my $msgP (@{$bl}){
        CUL_HM_SndCmd($hash, $mNoA.((--$no)?"00":"20")."CA$id$dst".$msgP);
        select(undef, undef, undef, (0.1));
      }


      $modules{CUL_HM}{helper}{updateStep}++;
      $modules{CUL_HM}{helper}{updateNbr} = $mNo;
      #InternalTimer(gettimeofday()+0.3,"CUL_HM_FWupdateSim","${dst}${id}00",0);
      InternalTimer(gettimeofday()+5,"CUL_HM_FWupdateEnd","fail:Block$step",0);
    }


gruss frank

Nur mal so zum Verständnis, Flashen OTA geht im Moment im CUL und HMland aber nicht über HMLAN ? Kann HMLAN dies prinzipiell nicht (hardwaremäßig) oder ist dies ein anderes Problem ?

Liebe Grüße,

Thomas

kann man nur spekulieren.
entweder hardware oder firmware. hmusb geht wohl auch nur mit fw>=0.967.
müsste mal jemand mit der neuesten firmware testen. eq3 unterstützt offiziell nur hmusb.
gruss frank

Ich habe ein HMLAN, wenn Interesse besteht kann ich gerne zum Testen beitragen.

ah - ok - es geht "nur" um die selbstgebaute FW.
HM wartet NICHT auf eine weitere CB.

Wird die "private" fw angepasst an HM? Oder ist das nicht zu schaffen?

hallo martin,

soweit ich hier die zusammenhänge verstehe, sieht es wie folgt aus:

1. es gibt eine software, exclusiv von eq3/homematic,  => windows-update-tool.

2. dieses tool sollen/müssen kunden benutzen, um ihre hm-devices zu updaten.

3. dieses tool sendet im 100k modus die 0x20CB message.

das ist also das offizielle update-verfahren von eq3/homematic.
dieses verfahren hat jan versucht einzubauen/zukopieren.

im gegensatz zu homematic, möchtest du diese message also lieber aus dem homematic-update-process streichen.

ZitatHM wartet NICHT auf eine weitere CB.

du kannst höchstens behaupten, dass dein rt mit firmware xy nicht reagiert. aber ob dieses verhalten allgemein gilt, kannst du, glaube ich, nicht behaupten.

ZitatWird die "private" fw angepasst an HM? Oder ist das nicht zu schaffen?

ich denke, es sollte für jan kein problem sein, den "privaten" bootloader, der zu 100% mit dem offiziellen homematic-windows-update-tool funktioniert, auch an deine interpretation des homematic-update-vervahrens anzupassen, so dass er auch damit zurecht kommt.

dazu muss er natürlich genaue instruktionen haben, wie dein verfahren funktioniert. dies hat er auch schon in diesem thread geäussert.

nachdem nun geklärt ist, dass fhem die 0x20CB-message im 100k modus nicht senden wird, kann man ja endlich weitermachen.

edit: ebenso wird man sich auch auf deine implementation des message-number-handlings während des updates einstellen müssen, so man über fhem updaten möchte.

edit2:

ZitatAktuell werde ich es nicht freigeben, weil
- die Version1.0 des RT nicht sauber startet. Und die ist aktuell Hauptgrund des update!

da stelle ich mir die frage, warum hat das windows-update-tool keine probleme? eventuell macht das tool ja irgendetwas anders. wer weiss das schon.  ;)

gruss frank

hallo thomas,

Zitat von: T.ihmann am 14 Mai 2014, 09:20:19
Ich habe ein HMLAN, wenn Interesse besteht kann ich gerne zum Testen beitragen.

hast du auch ein hm-device, das noch ein update benötigt?

gruss frank

Habe einen Homematic Schalter Funk-Schaltaktor für Markenschalter, 1fach Unterputzmontage, den ich mit der alternativen Firmware nutzen wollte. Da käme die Update Möglichkeit über FHEM mit einem HMLAN gerade recht.

Zitat von: T.ihmann am 14 Mai 2014, 14:23:30
Habe einen Homematic Schalter Funk-Schaltaktor für Markenschalter, 1fach Unterputzmontage, den ich mit der alternativen Firmware nutzen wollte. Da käme die Update Möglichkeit über FHEM mit einem HMLAN gerade recht.

Da musst du aber zuerst einmal mit dem Lötkolben ran, damit du den neuen Bootloader draufklatschen kannst. Das erste Mal bleibt dir leider nicht erspart.

Ja, ich weiß. Aber man braucht in Zukunft nicht immer den Aktor aus der Wand zu schrauben :D

Moin,

ich fixe das Ende der Woche wenn ich wieder aus London zurück bin. Verhalten ändere ich dahingehend:

1. Gerät rebootet wenn es 0xCB Nachricht bekommt. (Neu: Er sendet noch ein ACK vor dem Reboot wenn angefragt)
2. Gerät sendet Bereit Nachricht (noch im 10k Mode): https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L176
3. Gerät wartet auf 0xCB Nachricht. Kein ACK! (auch noch im 10k Mode): https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L213 (NEU: Das macht er nur nur bei einem manuellen Reboot. Nicht wenn er durch die 0xCB neugestartet wurde. Dann hat er die ja schon bekommen)
4. Danach wechselt das Gerät in den 100k Mode (bzw setzt die Register aus der Nachricht): https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L225
5. Das Gerät wartet, dass der Flasher die 0xCB Nachricht im 100k Mode wiederholt und sendet ACK: https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L250 (Das würde ich gerne in FHEM sehen, damit es einheitlich ist)
6. Danach wartet das Gerät auf die Blöcke in weiteren 0xCA Nachrichten. Am Ende des Blocks sendet er ein ACK: https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L286 (Auch das Verhalten würde ich gerne in FHEM sehen. Dann verhält er sich gleich zum eq3 Updater und flash-ota)
7. Gerät startet neu nach einem Timeout

Das Problem mit HMLAN ist, dass wir nicht wissen wie man den auf 100k Mode umstellt. Ggf geht es einfach nicht. Theoretisch können wir Firmwareupdate auch im 10k Mode machen in der Custom Firmware. Allerdings bekommen wir dann Probleme mit dem Sendekontingent von HMLAN. Die Custom Firmware muss sich natürlich auch an regulatorische Dinge halten, aber sie ist nicht technisch dazu gezwungen. Ggf muss man halt HMLAN wären des Updates 2/3 Mal rebooten.


Gruß,
Jan

hallo jan,

martins ablauf funktioniert (aktuell) folgendermassen:

nach absetzen von
set mydevice fwUpdate myfirmware.eq3 20
sendet fhem
2014.05.12 16:25:36.484 4: CUL_send:  cul868As 0A 0A 3011 123ABC ABCDEF CA
entweder das device geht dadurch automatisch in den update modus, oder der user hat 20 sekunden, dieses manuell zu machen. auf jeden fall muss als nächstes die message
2014.05.12 16:25:37.406 4: CUL_Parse: cul868 A 14 00 0010 ABCDEF 000000 004B4551303132333435361C -60
innerhalb der angegebenen zeit kommen, sonst bricht fhem den vorgang ab. kommt die message, sendet fhem
2014.05.12 16:25:37.509 4: CUL_send:  cul868As 0F 0B 00CB 123ABC ABCDEF 105B11F81547
und erwartet nichts mehr, sondern schaltet den cul in 100k
2014.05.12 16:25:37.618 4: CUL_send:  cul868AR
und fängt umgehend mit dem senden der firmware daten an
2014.05.12 16:25:37.900 4: CUL_send:  cul868As 27 0D 00CA 123ABC ABCDEF 01000C94AA000C94B8200C94E5200C9412210C940F1F0C945E040C943904
2014.05.12 16:25:38.074 4: CUL_send:  cul868As 27 0E 00CA 123ABC ABCDEF 0C9414040C94E6010C94D2000C94D2000C94D2000C94D2000C94D2000C94


somit wird dein vorgehen nicht funktionieren.

gruss frank

Hi Frank,

Zitatdu kannst höchstens behaupten, dass dein rt mit firmware xy nicht reagiert. aber ob dieses verhalten allgemein gilt, kannst du, glaube ich, nicht behaupten.

Korrekt. Ist inhaltlich aber auch schlüssig. Es stellt - wie ich schon 2-mal geschrieben habe - sicher, dass das Device im 100-mode angekommen ist. Es ist einfach eine message, auf die ein ACK kommen muss - und die im Bootloader gültig ist. Ausserdem darf sie nichts ändern. All das ist der Fall.
Die Implementierung wäre also, dann man die Message ggf. noch einmal wiederholen muss, falls keine Antwort kommt - das ist dann der eigentliche Zweck "prüfe, ob das Device bereit ist, wenn nicht warte und prüfe noch einmal".
Kann man machen - werde daran arbeiten. Die private-FW sollte aber auch ohne funktionieren. Sie darf nicht auf die message warten - muss sie aber ggf quittieren.

Zitatda stelle ich mir die frage, warum hat das windows-update-tool keine probleme? eventuell macht das tool ja irgendetwas anders. wer weiss das schon.

gute Frage. Fakt ist, dass mit der Aktuellen - und freigegebenen Version a) ein update  automatisch startet wenn es das Device unterstützt und b) der update manuell gestartet werden kann, wenn es das Device (die Version) nicht automatisch unterstützt.
Falls jemand einen Log  eines RT mit Version 1.1 oder 1.0 hat, der einen update mit der windows-sw macht kann ich noch einmal nachsehen. MeinDevice hat nicht reagiert - jetzt habe ich keins mehr  :(

Zitatedit: ebenso wird man sich auch auf deine implementation des message-number-handlings während des updates einstellen müssen, so man über fhem updaten möchte.

das habe ich bei einem Update mit CCU so gelogt - ist nicht meine Version - sorry.

@Jan

Zitat1. Gerät rebootet wenn es 0xCB Nachricht bekommt. (Neu: Er sendet noch ein ACK vor dem Reboot wenn angefragt)

es sollte in den Bootloader springen - das sollte schnell funktionieren.
ACKs sollten immer dann gesendet werden, wenn die messageflags eines anfordern. NIE aufgrund eines messagecodes. Es ist IMMER Sache des Senders ein Ack zu fordern. Du musst also nichts gegenüber dem ganz normalen messagehandling ändern -das sollte IMMER so sein.
Das Device soll mit der Message
11 ssssss dddddd CA
in den bootloader.
Die

Zitat20CB xxxxxx xxxxxx 105B11F815470B081A1C191D1BC71C001DB221B623EA

setzt die datenrate um Konkret werden hier Register gesetzt
10->5B
11->F8
15->47
0B->08
....

So sollte es implementiert werden - alles ander ist nicht konform - auch wenn es aktuell funktionieren sollte.

Zitat2. Gerät sendet Bereit Nachricht (noch im 10k Mode): https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L176
das ist die statusmessage nach reboot?

0010 xxxxxx 000000 004B455130353736363035

Zitat3. Gerät wartet auf 0xCB Nachricht. Kein ACK! (auch noch im 10k Mode): https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L213 (NEU: Das macht er nur nur bei einem manuellen Reboot. Nicht wenn er durch die 0xCB neugestartet wurde. Dann hat er die ja schon bekommen)

Siehe oben bezüglich ACK  und reboot. CB setzt Register im Chip und somit die Datenrate.

Zitat4. Danach wechselt das Gerät in den 100k Mode (bzw setzt die Register aus der Nachricht): https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L225

Siehe oben - die CB message schaltet quasi direkt

Zitat5. Das Gerät wartet, dass der Flasher die 0xCB Nachricht im 100k Mode wiederholt und sendet ACK: https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L250 (Das würde ich gerne in FHEM sehen, damit es einheitlich ist)

das Gerät wartet nicht. Sollte eine CB kommen wird sie bearbeitet, falls nicht auch gut. Es ist nicht Sache des Device ein Protokoll zu erzwingen.
Ack immer dann, wenn Flag gesetzt ist - sonst nie.

Zitat6. Danach wartet das Gerät auf die Blöcke in weiteren 0xCA Nachrichten. Am Ende des Blocks sendet er ein ACK: https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/bootloader.c#L286 (Auch das Verhalten würde ich gerne in FHEM sehen. Dann verhält er sich gleich zum eq3 Updater und flash-ota)

Auch hier gilt - wie immer. ACK immer dann, wenn der Sender eins möchte - nie aus eigenem Antrieb. Im Prinzip konnte die Zentrale zwischendurch ein CB schicken - dann soll es das Device eben verarbeiten.

Zitat7. Gerät startet neu nach einem Timeout

korrekt.

ZitatDas Problem mit HMLAN ist, dass wir nicht wissen wie man den auf 100k Mode umstellt. Ggf geht es einfach nicht. Theoretisch können wir Firmwareupdate auch im 10k Mode machen in der Custom Firmware. Allerdings bekommen wir dann Probleme mit dem Sendekontingent von HMLAN. Die Custom Firmware muss sich natürlich auch an regulatorische Dinge halten, aber sie ist nicht technisch dazu gezwungen

.
korrekt

ZitatGgf muss man halt HMLAN wären des Updates 2/3 Mal rebooten.

das verstehe ich nicht. a) wir können HMLAN nicht rebooten (oder meinst du custom-fw?) b) wen wir rebooten könnten kann es leicht zu einem timeout kommen.  den Ansatz verstehe ich nicht.

Gruss Martin

hallo martin,

Zitatdas habe ich bei einem Update mit CCU so gelogt

hat denn die ccu bei 100k die cb-message gesendet? und hattest du auch ein rt<fw1.2 damit geupdatet? mit oder ohne probleme?

anderes thema. das reading D-firmware.
aktuell wird es bei mir nach einem update durch fhem nur aktualisiert, wenn ich die anlerntaste am device betätige. muss ein automatisches aktualisieren nach update durch das device angestossen werden, oder baust du noch etwas in fhem ein?

anderes thema. zurückschalten des cul in den 10k mode.
aktuell wird nach einem erfolgreichen update das kommando "set cul raw Ar" 2 mal ausgeführt. kann hierdurch geändert werden.
    if ($blocks < $step){#last block
#      CUL_HM_FWupdateSpeed($name,10);
      CUL_HM_FWupdateEnd("done");
      Log3 $name,2,"CUL_HM fwUpdate completed";
    }

habe den update von 1.0 nach 1.2 getestet - den 2. CB habe ich nicht gesehen.

Zitatmuss ein automatisches aktualisieren nach update durch das device angestossen werden, oder baust du noch etwas in fhem ein?

verstehe ich nicht. Die sereinnummer wird immer aktuallisiert, wenn ich sie bekomme - z.B. mit jeder Anlernmessage.
Bei einigen Devices kann ich die Seriennummer abfragen, nicht bei allen.
Was du meinst ist die FW-version? Das ist noch einmal etwas anderes. Die kann ich nicht abfragen - zumindest kenne ich keine Message dazu. Habe ich eine message im Download übersehen?

doppel-ar remove => done

Gruss Martin

Moin Martin,

so ich hab mal angefangen den Code des Bootloaders aufzuräumen damit wir da funktional zusammen kommen. ACKs werden jetzt immer gesendet, wenn sie angefragt werden. Der Code sieht jetzt so aus:

        // go to standard 10k mode
        switch_radio_to_10k_mode();
        // send broadcast to allow windows tool or flash_ota to discover device
        send_bootloader_sequence();
        // wait for msg in 10k mode to change to 100k mode
        wait_for_CB_msg();
        // switch to 100k mode
        switch_radio_to_100k_mode();
        // this is needed for windows tool
        wait_for_CB_msg();
        // run the actual flashing
        flash_from_rf();


Ich werde noch einbauen, dass er wenn er durch FHEM/CCU2 während der Laufzeit angestoßen wurde nur noch folgendes ausführt:

        // CB already received directly switch to 100k mode
        switch_radio_to_100k_mode();
        // run the actual flashing
        flash_from_rf();


Ich habe noch eine Frage zum ACK und MsgId Handling während des flashens. Aktuell erwartetes Verhalten:
- Pro Block wird die MsgId erhöht. Vorher haben alle Nachrichten die gleiche MsgId
- Bei der letzten Nachricht des Blocks wird ACK angefordert.
- Wenn es ein Problem gab (dh kein ACK) sendet der Flasher den Block noch mal mit der gleichen MsgId

Deckt sich sich das mit dem erwarteten FHEM Verhalten?


Gruß,
Jan

warum ist das 2. wait_for_CB_msg notwendig? Wenn die kommt gut, wenn nicht auch gut. Es sollte eine CB oder CA message ok sein.

Eigentlich sollte der flash part unabhaengig von den CB messages sein.
mit einer CA message wird (wenn in bootloader) geflasht. Mit einer CB wird die speed umgeschaltet (mit den entsprechenden Settings koennte man das rueckschalten provizieren).
Das Device muss diese Sequenz nicht kontrollieren.

CA/CB sind nur im bootloader gueltig (bei CB bin ich mir nicht sicher)
Die anderen Messages sind nicht gueltig.
Den Ablauf kann die Zentrale gestalten wie sie lustig ist.

Das Device hat dann noch die Timersteuerung - wenn die Zentrale nicht mehr sendet wird rebootet - den Timerwert kenne ich nicht

Gruss Martin

Hi Martin,

die CB ist nicht notwendig aber wird von Windows und flash-ota erwartet. Kann man auch optional machen. Das war auch nicht meine Frage.
Ich weiß, dass theoretisch auch andere Settings kommen könnten. Prinzipbedingt muss das Gerät aber resettet werden bevor man in den Bootloader kommt und auch nur aus dem Bootloader kann man den Controller flashen.

Mein Hauptanliegen war folgende Frage:

Zitat von: jab am 17 Mai 2014, 15:54:51

Ich habe noch eine Frage zum ACK und MsgId Handling während des flashens. Aktuell erwartetes Verhalten:
- Pro Block wird die MsgId erhöht. Vorher haben alle Nachrichten die gleiche MsgId
- Bei der letzten Nachricht des Blocks wird ACK angefordert.
- Wenn es ein Problem gab (dh kein ACK) sendet der Flasher den Block noch mal mit der gleichen MsgId

Deckt sich sich das mit dem erwarteten FHEM Verhalten?

Gruß,
Jan

Hallo Jan,

ZitatIch weiß, dass theoretisch auch andere Settings kommen könnten. Prinzipbedingt muss das Gerät aber resettet werden bevor man in den Bootloader kommt und auch nur aus dem Bootloader kann man den Controller flashen.

schon klar.
Der Reset passiert aber mit der
3011 <src> <dst> CA
Nach dem Ack (das dauert beim RT ~0,5ec) ist das Device im bootloader.

Die Messages
<flag>CB  <src> <dst> <data>
<flag>CA  <src> <dst> <data>
muss man evtl in der operational SW garnicht können (habe ich nicht probiert). Zumindest für die CA ist dies wahrscheinlich. Diese Messages sind ausschliesslich im Bootloader gültig.

Zitatdie CB ist nicht notwendig aber wird von Windows und flash-ota erwartet.

Sorry, wenn ich hier wieder einmal haare spalte...
Die Windows SW erwartet das nicht, sie fordert es. Sie sendet den Request und erwartet eine Antwort. Das ist vollkommen ok - die Zentrale darf dies. Das Device ist slave und hat zu machen, was der Chef anordnet - also antworte. Das Device darf dies aber nicht "vorschreiben" (und tut es auch nicht, wenn es HM orginal ist).

Zur CB message - wenn du auch den CC1101 chip nutzt kannst du einfach die Werte des aus der Message in die Register schreiben. Das ist die Idee der message.

Gruss Martin

Hi Martin,

Magst du zu meinem Haupt Anliegen auch noch was sagen? Ist das von den Message IDs so konsistent oder erwartet FHEM das anders?


Gruß Jan

Hallo Jan,

hm - das war doch der Hauptpunkt....
die Zentrale gibt den Ablauf vor und darf ihn verändern.
Die message flags sind zu beachten - wie auch immer sie gesetzt sind.
Reset/enter bootcode kommt nach 11/CB, nicht nach CB/.. - oder aber nach Batterie einlegen/buttons drücken.
wenn das Device im Bootloader ist, ist die Datenrate erst einmal 10k. Das Umschalten auf 100k ist dann die 2. Message.

Ich könnte also sogar ohne Umschalten einen Download anstossen. Dem Device sollte das egal sein.

Die Bedeutung der Messages war (bis auf reboot) sowieso klar.

Stimmst du dem zu, oder siehst du Probleme? Wenn etwas von dem nicht realisierbar ist, lass es mich wissen.
Die 2. CB ist demnach nicht notwendig und darf vom Device nicht eingefordert werden.

Gruss Martin

Theoretisch gibt die zentrale den Ablauf vor. Praktisch müssen avr Controller in den Bootloader wechseln. Die RTs müssen das nicht die können vermutlich immer flashen.

Es ging mir um die Frage ob die Message ID innerhalb eines Blocks immer gleich bleibt. Ein ACK kann man dann ja ähnlich wie bei LongPress erst bei der letzten Nachricht des Blocks anfordern.

Der zweite Teil bezog sich auf das Retry Handling. Was passiert wenn der ACK ausbleibt? Flash-ota und das Windows Tool senden dann den gesamten Block mit der gleich Message ID nochmal.

Verhält sich FHEM bzgl Message ID und Retry gleich oder anders?


Gruß
Jan

ZitatDie RTs müssen das nicht die können vermutlich immer flashen.

nein, die müssen auch in den boot-loader- wie alle.
das passiert z.B. hier:
[code]10:40:18.824 send:  As 0A 0A 3011 1743BF 235EDB CA
10:40:19.337 Parse:  A 0A 0A 8002 235EDB 1743BF 00
10:40:19.974 Parse:  A 14 00 0010 235EDB 000000 004B455130353736363035[/code]
kommand
ack
und wenn der RT gebootet hat die Hallo-Wach

Hier ein  Beispielblock

10:40:20.200 send:  As 27 0D 00CA 1743BF 235EDB 0122BDED0BDF9971E49F77E6C46F26D73B39221C152497C69F4417899350
10:40:20.317 send:  As 27 0E 00CA 1743BF 235EDB 5D08704EB8CE86973FBCD24D276C47B084514BB153DCFEFB40DFA466A14E
10:40:20.433 send:  As 27 0F 00CA 1743BF 235EDB CCD4AA80857F368D4FDDC635EEF0090F2BB7E920B9C95E4AD6510175F55F
10:40:20.549 send:  As 27 10 00CA 1743BF 235EDB 918D46BD79B8C88E002ED8B697C6D64FBF27FE8A7F6E2803537683278E37
10:40:20.665 send:  As 27 11 00CA 1743BF 235EDB 743088E07EF695786AE109551393865605DF4AB17D506062D841CE0F53CA
10:40:20.781 send:  As 27 12 00CA 1743BF 235EDB 3476A54FA1B1BD49D0157DA035AB3536C1C5597DD0F319A4A48D12B9F59F
10:40:20.898 send:  As 27 13 00CA 1743BF 235EDB 9CAEE5C549399A281C953285BA8A481C485A4D961A2611AC4D4EA21CCBDE
10:40:21.014 send:  As 27 14 00CA 1743BF 235EDB C276A28E83883CF1DDBF099FDF5CC6DCF2CD0A9C626CC1ACFAA3C7AA8345
10:40:21.131 send:  As 27 15 00CA 1743BF 235EDB D25D3A91DF4DE1AFF17E8D8307A1C9B8F4037300FBD8E18C70339712D7DD
10:40:21.249 send:  As 1F 16 20CA 1743BF 235EDB BFD5401DC9F72E76FC7B23D10370BD3DE2E6317912BF
10:40:21.418 Parse:  A 0A 16 0002 235EDB 1743BF 00

ZitatVerhält sich FHEM bzgl Message ID und Retry gleich oder anders?

das muss ich erst einbauen. Aber korrekt - man muss den gesamten letzten Block wiederholen. Anders geht das ja technisch nicht, da nicht bekannt ist
- welche er messages ist nicht angekommen
- der header ist nur in der ersten message.

Werde ich nachholen.
Gruss Martin

Hallo Martin, Frank,

welche FW braucht der CUL damit ich mit diesem die RT´s mit der neuesten FW flashen kann?
Gut wäre ein kleines toDo  für die Ungeübten unter uns (wie ich)  ;)

Gruß
klaus

Der CUL braucht 1.58. Im Fhemwiki hab ich mal einen Beitrag angefangen, allerdings noch ohne flashen direkt über fhem, bisher nur übers terminal:
http://www.fhemwiki.de/wiki/HomeMatic_Firmware_Update

Hallo Strauch,

danke für die schnelle Antwort. Da muß ich wohl zunächst meine V 1.57 updaten.
Das es nur übers Terminal geht ist okay !

hallo martin,

ich versuche gerade unseren neuen selbstgebauten bootloader auch aus fhem füttern zu können. vom prinzip her scheint der ablauf jetzt zu stimmen. es gibt nun wohl aber timing probleme mit dem ack auf die 0x20CA message am ende des ersten daten-blocks.

2014.10.26 17:49:58.340 0: HMLAN_Send:  hmusb1 S:+266E75,00,01,00
2014.10.26 17:49:58.343 0: HMLAN_Send:  hmusb1 S:S4D5D4588 stat:  00 t:00000000 d:01 r:4D5D4588 m:0A 3011 1ACE1F 266E75 CA
2014.10.26 17:49:58.823 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:0409FF83 d:FF r:FFE3     m:0A 3011 1ACE1F 266E75 CA
2014.10.26 17:49:58.862 0: HMLAN_Parse: hmlan1 R:E266E75   stat:0000 t:0409FFAB d:FF r:FFCC     m:0A 8002 266E75 1ACE1F 00
2014.10.26 17:49:58.881 0: HMLAN_Parse: hmusb1 R:R4D5D4588 stat:0001 t:15896A51 d:FF r:FFBE     m:0A 8002 266E75 1ACE1F 00
2014.10.26 17:49:59.464 0: HMLAN_Parse: hmlan1 R:E266E75   stat:0000 t:040A0203 d:FF r:FFCC     m:00 0010 266E75 000000 004B455131313039373937
2014.10.26 17:49:59.557 0: HMLAN_Send:  hmusb1 S:S4D5D49F7 stat:  00 t:00000000 d:01 r:4D5D49F7 m:0B 00CB 1ACE1F 266E75 105B11F81547
2014.10.26 17:49:59.656 0: HMLAN_Send:  hmusb1 S:S4D5D4AAF stat:  00 t:00000000 d:01 r:4D5D4AAF m:0D 00CA 1ACE1F 266E75 01000C94B5070C9459390C9486390C94B3390C9494370C94930B0C946E0B
2014.10.26 17:49:59.663 0: HMLAN_Send:  hmusb1 S:S4D5D4AB7 stat:  00 t:00000000 d:01 r:4D5D4AB7 m:0E 00CA 1ACE1F 266E75 0C94490B0C94F8080C94DD070C94DD070C94DD070C94DD070C94DD070C94
2014.10.26 17:49:59.670 0: HMLAN_Send:  hmusb1 S:S4D5D4ABE stat:  00 t:00000000 d:01 r:4D5D4ABE m:0F 00CA 1ACE1F 266E75 DD070C94DD070C94DD070C94DD070C94E0390C94DD070C94223D0C94703D
2014.10.26 17:49:59.678 0: HMLAN_Send:  hmusb1 S:S4D5D4AC5 stat:  00 t:00000000 d:01 r:4D5D4AC5 m:10 00CA 1ACE1F 266E75 0C94DD070C94DD070C94DD070C94DD070C94DD070C94DD07290A00280029
2014.10.26 17:49:59.686 0: HMLAN_Send:  hmusb1 S:S4D5D4ACD stat:  00 t:00000000 d:01 r:4D5D4ACD m:11 00CA 1ACE1F 266E75 0020286C3A004B6E6F776E20636F6D6D616E64733A00206279746573004E
2014.10.26 17:49:59.693 0: HMLAN_Send:  hmusb1 S:S4D5D4AD5 stat:  00 t:00000000 d:01 r:4D5D4AD5 m:12 00CA 1ACE1F 266E75 6F7420656E6F75676820646174612C206E6565642000556E7265636F676E
2014.10.26 17:49:59.700 0: HMLAN_Send:  hmusb1 S:S4D5D4ADC stat:  00 t:00000000 d:01 r:4D5D4ADC m:13 00CA 1ACE1F 266E75 697A6564206368617261637465723A20002C206E7874533A00524C3A6164
2014.10.26 17:49:59.712 0: HMLAN_Send:  hmusb1 S:S4D5D4AE7 stat:  00 t:00000000 d:01 r:4D5D4AE7 m:14 00CA 1ACE1F 266E75 6A526C792C20637572533A002C204F666654696D653A002C204F6666446C
2014.10.26 17:49:59.720 0: HMLAN_Send:  hmusb1 S:S4D5D4AF0 stat:  00 t:00000000 d:01 r:4D5D4AF0 m:15 20CA 1ACE1F 266E75 793A002C204F6E54696D653A002C204F6E44
2014.10.26 17:49:59.748 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:040A02A5 d:FF r:FFE3     m:0B 00CB 1ACE1F 266E75 105B11F81547
2014.10.26 17:49:59.801 0: HMLAN_Parse: hmusb1 R:E266E75   stat:0000 t:15896CA4 d:FF r:FFBE     m:00 0010 266E75 000000 004B455131313039373937
2014.10.26 17:49:59.905 0: HMLAN_Delay: hmusb1 266E75
2014.10.26 17:49:59.911 0: HMLAN_Delay: hmusb1 266E75
2014.10.26 17:49:59.917 0: HMLAN_Delay: hmusb1 266E75
2014.10.26 17:49:59.923 0: HMLAN_Delay: hmusb1 266E75
2014.10.26 17:49:59.929 0: HMLAN_Delay: hmusb1 266E75
2014.10.26 17:49:59.937 0: HMLAN_Delay: hmusb1 266E75
2014.10.26 17:49:59.944 0: HMLAN_Delay: hmusb1 266E75
2014.10.26 17:49:59.950 0: HMLAN_Delay: hmusb1 266E75
2014.10.26 17:49:59.961 0: HMLAN_Parse: hmusb1 R:R4D5D49F7 stat:0002 t:00000000 d:FF r:7FFF     m:0B 00CB 1ACE1F 266E75 105B11F81547
2014.10.26 17:49:59.965 0: HMLAN_Parse: hmusb1 R:R4D5D4AAF stat:0002 t:00000000 d:FF r:7FFF     m:0D 00CA 1ACE1F 266E75 01000C94B5070C9459390C9486390C94B3390C9494370C94930B0C946E0B
2014.10.26 17:49:59.975 4: CUL_Parse: cul868 A 27 0D 00CA 1ACE1F 266E75 01000C94B5070C9459390C9486390C94B3390C9494370C94930B0C946E0B59 -29.5
2014.10.26 17:49:59.981 4: CUL_Parse: cul868 A 27 0E 00CA 1ACE1F 266E75 0C94490B0C94F8080C94DD070C94DD070C94DD070C94DD070C94DD070C9459 -29.5
2014.10.26 17:49:59.986 4: CUL_Parse: cul868 A 27 0F 00CA 1ACE1F 266E75 DD070C94DD070C94DD070C94DD070C94E0390C94DD070C94223D0C94703D59 -29.5
2014.10.26 17:50:00.039 0: HMLAN_Parse: hmusb1 R:R4D5D4AB7 stat:0002 t:00000000 d:FF r:7FFF     m:0E 00CA 1ACE1F 266E75 0C94490B0C94F8080C94DD070C94DD070C94DD070C94DD070C94DD070C94
2014.10.26 17:50:00.041 0: HMLAN_Parse: hmusb1 R:R4D5D4ABE stat:0002 t:00000000 d:FF r:7FFF     m:0F 00CA 1ACE1F 266E75 DD070C94DD070C94DD070C94DD070C94E0390C94DD070C94223D0C94703D
2014.10.26 17:50:00.046 4: CUL_Parse: cul868 A 27 10 00CA 1ACE1F 266E75 0C94DD070C94DD070C94DD070C94DD070C94DD070C94DD07290A0028002959 -29.5
2014.10.26 17:50:00.051 4: CUL_Parse: cul868 A 27 11 00CA 1ACE1F 266E75 0020286C3A004B6E6F776E20636F6D6D616E64733A00206279746573004E59 -29.5
2014.10.26 17:50:00.056 4: CUL_Parse: cul868 A 27 12 00CA 1ACE1F 266E75 6F7420656E6F75676820646174612C206E6565642000556E7265636F676E59 -29.5
2014.10.26 17:50:00.079 0: HMLAN_Parse: hmusb1 R:R4D5D4AC5 stat:0002 t:00000000 d:FF r:7FFF     m:10 00CA 1ACE1F 266E75 0C94DD070C94DD070C94DD070C94DD070C94DD070C94DD07290A00280029
2014.10.26 17:50:00.081 0: HMLAN_Parse: hmusb1 R:R4D5D4ACD stat:0002 t:00000000 d:FF r:7FFF     m:11 00CA 1ACE1F 266E75 0020286C3A004B6E6F776E20636F6D6D616E64733A00206279746573004E
2014.10.26 17:50:00.088 0: HMLAN_Parse: hmusb1 R:R4D5D4AD5 stat:0002 t:00000000 d:FF r:7FFF     m:12 00CA 1ACE1F 266E75 6F7420656E6F75676820646174612C206E6565642000556E7265636F676E
2014.10.26 17:50:00.110 4: CUL_Parse: cul868 A 27 13 00CA 1ACE1F 266E75 697A6564206368617261637465723A20002C206E7874533A00524C3A616459 -29.5
2014.10.26 17:50:00.130 0: HMLAN_Parse: hmusb1 R:R4D5D4ADC stat:0002 t:00000000 d:FF r:7FFF     m:13 00CA 1ACE1F 266E75 697A6564206368617261637465723A20002C206E7874533A00524C3A6164
2014.10.26 17:50:00.178 4: CUL_Parse: cul868 A 27 14 00CA 1ACE1F 266E75 6A526C792C20637572533A002C204F666654696D653A002C204F6666446C59 -29.5
2014.10.26 17:50:00.194 0: HMLAN_Parse: hmusb1 R:R4D5D4AE7 stat:0002 t:00000000 d:FF r:7FFF     m:14 00CA 1ACE1F 266E75 6A526C792C20637572533A002C204F666654696D653A002C204F6666446C
2014.10.26 17:50:00.236 4: CUL_Parse: cul868 A 1B 15 20CA 1ACE1F 266E75 793A002C204F6E54696D653A002C204F6E4459 -29.5
2014.10.26 17:50:00.259 4: CUL_Parse: cul868 A 0A 15 8002 266E75 1ACE1F 0035 -47.5
2014.10.26 17:50:00.289 0: HMLAN_Parse: hmusb1 R:R4D5D4AF0 stat:0001 t:15896FD1 d:FF r:FFC0     m:15 8002 266E75 1ACE1F 00
2014.10.26 17:50:00.388 0: HMLAN_Send:  hmusb1 S:S4D5D4D8A stat:  00 t:00000000 d:01 r:4D5D4D8A m:1E 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D
2014.10.26 17:50:00.454 4: CUL_Parse: cul868 A 1B 1E 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D59 -29.5
2014.10.26 17:50:00.629 4: CUL_Parse: cul868 A 1B 1E 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D59 -29.5
2014.10.26 17:50:00.829 4: CUL_Parse: cul868 A 1B 1E 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D59 -29.5
2014.10.26 17:50:01.025 0: HMLAN_Parse: hmusb1 R:R4D5D4D8A stat:0008 t:00000000 d:FF r:7FFF     m:1E 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D
2014.10.26 17:50:01.028 0: HMLAN_Parse: hmusb1 no ACK from 266E75
2014.10.26 17:50:04.978 0: HMLAN_Send:  hmusb1 S:S4D5D5F79 stat:  00 t:00000000 d:01 r:4D5D5F79 m:0B 00CA 1ACE1F 266E75 01006C793A002C206E7874533A00524C3A7472696767657234302C206375
2014.10.26 17:50:04.986 0: HMLAN_Send:  hmusb1 S:S4D5D5F82 stat:  00 t:00000000 d:01 r:4D5D5F82 m:0C 00CA 1ACE1F 266E75 72533A002C2064757261543A002C2072616D70543A002C206E7874533A00
2014.10.26 17:50:04.995 0: HMLAN_Send:  hmusb1 S:S4D5D5F8A stat:  00 t:00000000 d:01 r:4D5D5F8A m:0D 00CA 1ACE1F 266E75 524C3A7472696767657231312C2076616C3A002C2070496478323A20002C
2014.10.26 17:50:05.002 0: HMLAN_Send:  hmusb1 S:S4D5D5F92 stat:  00 t:00000000 d:01 r:4D5D5F92 m:0E 00CA 1ACE1F 266E75 2070496478313A200072656D6F76655065657246726F6D4D73672C20636E
2014.10.26 17:50:05.010 0: HMLAN_Send:  hmusb1 S:S4D5D5F9A stat:  00 t:00000000 d:01 r:4D5D5F9A m:0F 00CA 1ACE1F 266E75 6C3A20006164645065657246726F6D4D73672C20636E6C3A200061646450
2014.10.26 17:50:05.017 0: HMLAN_Send:  hmusb1 S:S4D5D5FA1 stat:  00 t:00000000 d:01 r:4D5D5FA1 m:10 00CA 1ACE1F 266E75 65657246726F6D4D73672C20636E6C3A20002C20646174613A2000736574
2014.10.26 17:50:05.026 0: HMLAN_Send:  hmusb1 S:S4D5D5FAA stat:  00 t:00000000 d:01 r:4D5D5FAA m:11 00CA 1ACE1F 266E75 4C69737446726F6D4D73672C206C656E3A20002C20646174613A20006765
2014.10.26 17:50:05.034 0: HMLAN_Send:  hmusb1 S:S4D5D5FB2 stat:  00 t:00000000 d:01 r:4D5D5FB2 m:12 00CA 1ACE1F 266E75 744C697374466F724D7367322C206C656E3A20002C20736C635074723A20
2014.10.26 17:50:05.041 0: HMLAN_Send:  hmusb1 S:S4D5D5FB9 stat:  00 t:00000000 d:01 r:4D5D5FB9 m:13 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D
2014.10.26 17:50:05.053 0: HMLAN_Parse: hmusb1 R:R4D5D5F79 stat:0002 t:00000000 d:FF r:7FFF     m:0B 00CA 1ACE1F 266E75 01006C793A002C206E7874533A00524C3A7472696767657234302C206375
2014.10.26 17:50:05.058 4: CUL_Parse: cul868 A 27 0B 00CA 1ACE1F 266E75 01006C793A002C206E7874533A00524C3A7472696767657234302C20637559 -29.5
2014.10.26 17:50:05.078 4: CUL_Parse: cul868 A 27 0C 00CA 1ACE1F 266E75 72533A002C2064757261543A002C2072616D70543A002C206E7874533A0059 -29.5
2014.10.26 17:50:05.089 0: HMLAN_Parse: hmusb1 R:R4D5D5F82 stat:0002 t:00000000 d:FF r:7FFF     m:0C 00CA 1ACE1F 266E75 72533A002C2064757261543A002C2072616D70543A002C206E7874533A00
2014.10.26 17:50:05.134 4: CUL_Parse: cul868 A 27 0D 00CA 1ACE1F 266E75 524C3A7472696767657231312C2076616C3A002C2070496478323A20002C59 -29.5
2014.10.26 17:50:05.153 0: HMLAN_Parse: hmusb1 R:R4D5D5F8A stat:0002 t:00000000 d:FF r:7FFF     m:0D 00CA 1ACE1F 266E75 524C3A7472696767657231312C2076616C3A002C2070496478323A20002C
2014.10.26 17:50:05.198 4: CUL_Parse: cul868 A 27 0E 00CA 1ACE1F 266E75 2070496478313A200072656D6F76655065657246726F6D4D73672C20636E59 -29.5
2014.10.26 17:50:05.217 0: HMLAN_Parse: hmusb1 R:R4D5D5F92 stat:0002 t:00000000 d:FF r:7FFF     m:0E 00CA 1ACE1F 266E75 2070496478313A200072656D6F76655065657246726F6D4D73672C20636E
2014.10.26 17:50:05.262 4: CUL_Parse: cul868 A 27 0F 00CA 1ACE1F 266E75 6C3A20006164645065657246726F6D4D73672C20636E6C3A20006164645058 -30
2014.10.26 17:50:05.281 0: HMLAN_Parse: hmusb1 R:R4D5D5F9A stat:0002 t:00000000 d:FF r:7FFF     m:0F 00CA 1ACE1F 266E75 6C3A20006164645065657246726F6D4D73672C20636E6C3A200061646450
2014.10.26 17:50:05.326 4: CUL_Parse: cul868 A 27 10 00CA 1ACE1F 266E75 65657246726F6D4D73672C20636E6C3A20002C20646174613A200073657459 -29.5
2014.10.26 17:50:05.346 0: HMLAN_Parse: hmusb1 R:R4D5D5FA1 stat:0002 t:00000000 d:FF r:7FFF     m:10 00CA 1ACE1F 266E75 65657246726F6D4D73672C20636E6C3A20002C20646174613A2000736574
2014.10.26 17:50:05.390 4: CUL_Parse: cul868 A 27 11 00CA 1ACE1F 266E75 4C69737446726F6D4D73672C206C656E3A20002C20646174613A2000676559 -29.5
2014.10.26 17:50:05.409 0: HMLAN_Parse: hmusb1 R:R4D5D5FAA stat:0002 t:00000000 d:FF r:7FFF     m:11 00CA 1ACE1F 266E75 4C69737446726F6D4D73672C206C656E3A20002C20646174613A20006765
2014.10.26 17:50:05.454 4: CUL_Parse: cul868 A 27 12 00CA 1ACE1F 266E75 744C697374466F724D7367322C206C656E3A20002C20736C635074723A2059 -29.5
2014.10.26 17:50:05.473 0: HMLAN_Parse: hmusb1 R:R4D5D5FB2 stat:0002 t:00000000 d:FF r:7FFF     m:12 00CA 1ACE1F 266E75 744C697374466F724D7367322C206C656E3A20002C20736C635074723A20
2014.10.26 17:50:05.530 4: CUL_Parse: cul868 A 1B 13 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D59 -29.5
2014.10.26 17:50:05.717 4: CUL_Parse: cul868 A 1B 13 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D59 -29.5
2014.10.26 17:50:05.917 4: CUL_Parse: cul868 A 1B 13 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D59 -29.5
2014.10.26 17:50:06.112 0: HMLAN_Parse: hmusb1 R:R4D5D5FB9 stat:0008 t:00000000 d:FF r:7FFF     m:13 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D
2014.10.26 17:50:06.115 0: HMLAN_Parse: hmusb1 no ACK from 266E75
2014.10.26 17:50:10.064 0: HMLAN_Send:  hmusb1 S:S4D5D7358 stat:  00 t:00000000 d:01 r:4D5D7358 m:0B 00CA 1ACE1F 266E75 01006C793A002C206E7874533A00524C3A7472696767657234302C206375
2014.10.26 17:50:10.072 0: HMLAN_Send:  hmusb1 S:S4D5D7360 stat:  00 t:00000000 d:01 r:4D5D7360 m:0C 00CA 1ACE1F 266E75 72533A002C2064757261543A002C2072616D70543A002C206E7874533A00
2014.10.26 17:50:10.080 0: HMLAN_Send:  hmusb1 S:S4D5D7367 stat:  00 t:00000000 d:01 r:4D5D7367 m:0D 00CA 1ACE1F 266E75 524C3A7472696767657231312C2076616C3A002C2070496478323A20002C
2014.10.26 17:50:10.088 0: HMLAN_Send:  hmusb1 S:S4D5D736F stat:  00 t:00000000 d:01 r:4D5D736F m:0E 00CA 1ACE1F 266E75 2070496478313A200072656D6F76655065657246726F6D4D73672C20636E
2014.10.26 17:50:10.096 0: HMLAN_Send:  hmusb1 S:S4D5D7377 stat:  00 t:00000000 d:01 r:4D5D7377 m:0F 00CA 1ACE1F 266E75 6C3A20006164645065657246726F6D4D73672C20636E6C3A200061646450
2014.10.26 17:50:10.103 0: HMLAN_Send:  hmusb1 S:S4D5D737F stat:  00 t:00000000 d:01 r:4D5D737F m:10 00CA 1ACE1F 266E75 65657246726F6D4D73672C20636E6C3A20002C20646174613A2000736574
2014.10.26 17:50:10.112 0: HMLAN_Send:  hmusb1 S:S4D5D7386 stat:  00 t:00000000 d:01 r:4D5D7386 m:11 00CA 1ACE1F 266E75 4C69737446726F6D4D73672C206C656E3A20002C20646174613A20006765
2014.10.26 17:50:10.119 0: HMLAN_Send:  hmusb1 S:S4D5D738F stat:  00 t:00000000 d:01 r:4D5D738F m:12 00CA 1ACE1F 266E75 744C697374466F724D7367322C206C656E3A20002C20736C635074723A20
2014.10.26 17:50:10.128 0: HMLAN_Send:  hmusb1 S:S4D5D7397 stat:  00 t:00000000 d:01 r:4D5D7397 m:13 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D
2014.10.26 17:50:10.138 0: HMLAN_Parse: hmusb1 R:R4D5D7358 stat:0002 t:00000000 d:FF r:7FFF     m:0B 00CA 1ACE1F 266E75 01006C793A002C206E7874533A00524C3A7472696767657234302C206375
2014.10.26 17:50:10.142 4: CUL_Parse: cul868 A 27 0B 00CA 1ACE1F 266E75 01006C793A002C206E7874533A00524C3A7472696767657234302C20637559 -29.5
2014.10.26 17:50:10.158 4: CUL_Parse: cul868 A 27 0C 00CA 1ACE1F 266E75 72533A002C2064757261543A002C2072616D70543A002C206E7874533A0059 -29.5
2014.10.26 17:50:10.190 0: HMLAN_Parse: hmusb1 R:R4D5D7360 stat:0002 t:00000000 d:FF r:7FFF     m:0C 00CA 1ACE1F 266E75 72533A002C2064757261543A002C2072616D70543A002C206E7874533A00
2014.10.26 17:50:10.222 4: CUL_Parse: cul868 A 27 0D 00CA 1ACE1F 266E75 524C3A7472696767657231312C2076616C3A002C2070496478323A20002C59 -29.5
2014.10.26 17:50:10.241 0: HMLAN_Parse: hmusb1 R:R4D5D7367 stat:0002 t:00000000 d:FF r:7FFF     m:0D 00CA 1ACE1F 266E75 524C3A7472696767657231312C2076616C3A002C2070496478323A20002C
2014.10.26 17:50:10.286 4: CUL_Parse: cul868 A 27 0E 00CA 1ACE1F 266E75 2070496478313A200072656D6F76655065657246726F6D4D73672C20636E59 -29.5
2014.10.26 17:50:10.305 0: HMLAN_Parse: hmusb1 R:R4D5D736F stat:0002 t:00000000 d:FF r:7FFF     m:0E 00CA 1ACE1F 266E75 2070496478313A200072656D6F76655065657246726F6D4D73672C20636E
2014.10.26 17:50:10.350 4: CUL_Parse: cul868 A 27 0F 00CA 1ACE1F 266E75 6C3A20006164645065657246726F6D4D73672C20636E6C3A20006164645059 -29.5
2014.10.26 17:50:10.369 0: HMLAN_Parse: hmusb1 R:R4D5D7377 stat:0002 t:00000000 d:FF r:7FFF     m:0F 00CA 1ACE1F 266E75 6C3A20006164645065657246726F6D4D73672C20636E6C3A200061646450
2014.10.26 17:50:10.414 4: CUL_Parse: cul868 A 27 10 00CA 1ACE1F 266E75 65657246726F6D4D73672C20636E6C3A20002C20646174613A200073657459 -29.5
2014.10.26 17:50:10.434 0: HMLAN_Parse: hmusb1 R:R4D5D737F stat:0002 t:00000000 d:FF r:7FFF     m:10 00CA 1ACE1F 266E75 65657246726F6D4D73672C20636E6C3A20002C20646174613A2000736574
2014.10.26 17:50:10.478 4: CUL_Parse: cul868 A 27 11 00CA 1ACE1F 266E75 4C69737446726F6D4D73672C206C656E3A20002C20646174613A2000676559 -29.5
2014.10.26 17:50:10.497 0: HMLAN_Parse: hmusb1 R:R4D5D7386 stat:0002 t:00000000 d:FF r:7FFF     m:11 00CA 1ACE1F 266E75 4C69737446726F6D4D73672C206C656E3A20002C20646174613A20006765
2014.10.26 17:50:10.542 4: CUL_Parse: cul868 A 27 12 00CA 1ACE1F 266E75 744C697374466F724D7367322C206C656E3A20002C20736C635074723A2059 -29.5
2014.10.26 17:50:10.561 0: HMLAN_Parse: hmusb1 R:R4D5D738F stat:0002 t:00000000 d:FF r:7FFF     m:12 00CA 1ACE1F 266E75 744C697374466F724D7367322C206C656E3A20002C20736C635074723A20
2014.10.26 17:50:10.605 4: CUL_Parse: cul868 A 1B 13 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D59 -29.5
2014.10.26 17:50:10.641 0: HMLAN_Parse: hmlan1 R:E266E75   stat:0000 t:040A2DAF d:FF r:FFCC     m:00 A410 266E75 1ACE1F 0604000000
2014.10.26 17:50:10.761 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:040A2E27 d:FF r:FFB9     m:00 8002 1ACE1F 266E75 00
2014.10.26 17:50:10.805 4: CUL_Parse: cul868 A 1B 13 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D59 -29.5
2014.10.26 17:50:11.017 4: CUL_Parse: cul868 A 1B 13 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D59 -29.5
2014.10.26 17:50:11.201 0: HMLAN_Parse: hmusb1 R:R4D5D7397 stat:0008 t:00000000 d:FF r:7FFF     m:13 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D
2014.10.26 17:50:11.204 0: HMLAN_Parse: hmusb1 no ACK from 266E75
2014.10.26 17:50:11.338 0: HMLAN_Parse: hmlan1 R:E266E75   stat:0000 t:040A3069 d:FF r:FFCC     m:01 A410 266E75 1ACE1F 0603000000
2014.10.26 17:50:11.458 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:040A30E1 d:FF r:FFB8     m:01 8002 1ACE1F 266E75 00
2014.10.26 17:50:15.149 0: HMLAN_Send:  hmusb1 S:S4D5D8735 stat:  00 t:00000000 d:01 r:4D5D8735 m:0B 00CA 1ACE1F 266E75 01006C793A002C206E7874533A00524C3A7472696767657234302C206375
2014.10.26 17:50:15.158 0: HMLAN_Send:  hmusb1 S:S4D5D873D stat:  00 t:00000000 d:01 r:4D5D873D m:0C 00CA 1ACE1F 266E75 72533A002C2064757261543A002C2072616D70543A002C206E7874533A00
2014.10.26 17:50:15.164 0: HMLAN_Send:  hmusb1 S:S4D5D8744 stat:  00 t:00000000 d:01 r:4D5D8744 m:0D 00CA 1ACE1F 266E75 524C3A7472696767657231312C2076616C3A002C2070496478323A20002C
2014.10.26 17:50:15.172 0: HMLAN_Send:  hmusb1 S:S4D5D874C stat:  00 t:00000000 d:01 r:4D5D874C m:0E 00CA 1ACE1F 266E75 2070496478313A200072656D6F76655065657246726F6D4D73672C20636E
2014.10.26 17:50:15.179 0: HMLAN_Send:  hmusb1 S:S4D5D8753 stat:  00 t:00000000 d:01 r:4D5D8753 m:0F 00CA 1ACE1F 266E75 6C3A20006164645065657246726F6D4D73672C20636E6C3A200061646450
2014.10.26 17:50:15.186 0: HMLAN_Send:  hmusb1 S:S4D5D875A stat:  00 t:00000000 d:01 r:4D5D875A m:10 00CA 1ACE1F 266E75 65657246726F6D4D73672C20636E6C3A20002C20646174613A2000736574
2014.10.26 17:50:15.194 0: HMLAN_Send:  hmusb1 S:S4D5D8762 stat:  00 t:00000000 d:01 r:4D5D8762 m:11 00CA 1ACE1F 266E75 4C69737446726F6D4D73672C206C656E3A20002C20646174613A20006765
2014.10.26 17:50:15.204 0: HMLAN_Send:  hmusb1 S:S4D5D876B stat:  00 t:00000000 d:01 r:4D5D876B m:12 00CA 1ACE1F 266E75 744C697374466F724D7367322C206C656E3A20002C20736C635074723A20
2014.10.26 17:50:15.213 0: HMLAN_Send:  hmusb1 S:S4D5D8774 stat:  00 t:00000000 d:01 r:4D5D8774 m:13 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D
2014.10.26 17:50:15.224 0: HMLAN_Parse: hmusb1 R:R4D5D8735 stat:0002 t:00000000 d:FF r:7FFF     m:0B 00CA 1ACE1F 266E75 01006C793A002C206E7874533A00524C3A7472696767657234302C206375
2014.10.26 17:50:15.228 4: CUL_Parse: cul868 A 27 0B 00CA 1ACE1F 266E75 01006C793A002C206E7874533A00524C3A7472696767657234302C20637559 -29.5
2014.10.26 17:50:15.246 4: CUL_Parse: cul868 A 27 0C 00CA 1ACE1F 266E75 72533A002C2064757261543A002C2072616D70543A002C206E7874533A0059 -29.5
2014.10.26 17:50:15.265 0: HMLAN_Parse: hmusb1 R:R4D5D873D stat:0002 t:00000000 d:FF r:7FFF     m:0C 00CA 1ACE1F 266E75 72533A002C2064757261543A002C2072616D70543A002C206E7874533A00
2014.10.26 17:50:15.311 4: CUL_Parse: cul868 A 27 0D 00CA 1ACE1F 266E75 524C3A7472696767657231312C2076616C3A002C2070496478323A20002C59 -29.5
2014.10.26 17:50:15.329 0: HMLAN_Parse: hmusb1 R:R4D5D8744 stat:0002 t:00000000 d:FF r:7FFF     m:0D 00CA 1ACE1F 266E75 524C3A7472696767657231312C2076616C3A002C2070496478323A20002C
2014.10.26 17:50:15.375 4: CUL_Parse: cul868 A 27 0E 00CA 1ACE1F 266E75 2070496478313A200072656D6F76655065657246726F6D4D73672C20636E59 -29.5
2014.10.26 17:50:15.393 0: HMLAN_Parse: hmusb1 R:R4D5D874C stat:0002 t:00000000 d:FF r:7FFF     m:0E 00CA 1ACE1F 266E75 2070496478313A200072656D6F76655065657246726F6D4D73672C20636E
2014.10.26 17:50:15.439 4: CUL_Parse: cul868 A 27 0F 00CA 1ACE1F 266E75 6C3A20006164645065657246726F6D4D73672C20636E6C3A20006164645059 -29.5
2014.10.26 17:50:15.457 0: HMLAN_Parse: hmusb1 R:R4D5D8753 stat:0002 t:00000000 d:FF r:7FFF     m:0F 00CA 1ACE1F 266E75 6C3A20006164645065657246726F6D4D73672C20636E6C3A200061646450
2014.10.26 17:50:15.503 4: CUL_Parse: cul868 A 27 10 00CA 1ACE1F 266E75 65657246726F6D4D73672C20636E6C3A20002C20646174613A200073657459 -29.5
2014.10.26 17:50:15.521 0: HMLAN_Parse: hmusb1 R:R4D5D875A stat:0002 t:00000000 d:FF r:7FFF     m:10 00CA 1ACE1F 266E75 65657246726F6D4D73672C20636E6C3A20002C20646174613A2000736574
2014.10.26 17:50:15.567 4: CUL_Parse: cul868 A 27 11 00CA 1ACE1F 266E75 4C69737446726F6D4D73672C206C656E3A20002C20646174613A2000676559 -29.5
2014.10.26 17:50:15.585 0: HMLAN_Parse: hmusb1 R:R4D5D8762 stat:0002 t:00000000 d:FF r:7FFF     m:11 00CA 1ACE1F 266E75 4C69737446726F6D4D73672C206C656E3A20002C20646174613A20006765
2014.10.26 17:50:15.631 4: CUL_Parse: cul868 A 27 12 00CA 1ACE1F 266E75 744C697374466F724D7367322C206C656E3A20002C20736C635074723A2059 -29.5
2014.10.26 17:50:15.652 0: HMLAN_Parse: hmusb1 R:R4D5D876B stat:0002 t:00000000 d:FF r:7FFF     m:12 00CA 1ACE1F 266E75 744C697374466F724D7367322C206C656E3A20002C20736C635074723A20
2014.10.26 17:50:15.693 4: CUL_Parse: cul868 A 1B 13 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D59 -29.5
2014.10.26 17:50:15.893 4: CUL_Parse: cul868 A 1B 13 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D59 -29.5
2014.10.26 17:50:16.093 4: CUL_Parse: cul868 A 1B 13 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D59 -29.5
2014.10.26 17:50:16.289 0: HMLAN_Parse: hmusb1 R:R4D5D8774 stat:0008 t:00000000 d:FF r:7FFF     m:13 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D
2014.10.26 17:50:16.292 0: HMLAN_Parse: hmusb1 no ACK from 266E75


abgesehen davon, dass der bootloader die wiederholungen des datenblocks noch nicht beherscht, würde mich zunächst einmal interessieren, warum das erste ack auf 0x20CA nicht funktioniert. mit dem windows-tool gibt es da keine probleme. hier in fhem ist es auch kein zufall. es passiert jedesmal genau gleich. kannst du erkennen um wieviel es zu spät kommt?

der cul monitort auf 100k, hmlan auf 10k und der hmusb macht das update. der schalter hat das attribut IOgrp=vccu:hmusb1. der cul steht bei der vccu nicht in IOList, wird aber als assignedIO gelistet mit dem status "UAS".

2014.10.26 17:49:59.905 0: HMLAN_Delay: hmusb1 266E75
was bedeuten diese logeinträge?

gruss frank

hallo martin,

ich habe nun eine ack wiederholung für 0x20ca eingebaut. das zweite ack wird nun erkannt und der ablauf geht weiter. aber das verfahren mit den wiederholungen auf fhem-seite scheint mir nicht ganz korrekt zu sein. siehe debug-ausgabe des bootloaders:

AskSin OTA Bootloader V0.7.2<\n>
<\n>
TX bootloader sequence<\n>
TX: 14 00 00 10 26 6E 75 00 00 00 00 4B 45 51 31 31 30 39 37 39 37 <\n>
Wait for CB msg<\n>
RX: 0F 0B 00 CB 1A CE 1F 26 6E 75 10 5B 11 F8 15 47 <\n>
Got CB msg<\n>
Switch to 100k mode<\n>
Wait for CB msg<\n>
RX: 27 0D 00 CA 1A CE 1F 26 6E 75 01 00 0C 94 B5 07 0C 94 59 39 0C 94 86 39 0C 94 B3 39 0C 94 94 37 0C 94 93 0B 0C 94 6E 0B <\n>
Got CA msg<\n>
Receive firmware<\n>
RX: 27 0E 00 CA 1A CE 1F 26 6E 75 0C 94 49 0B 0C 94 F8 08 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 <\n>
RX: 27 0F 00 CA 1A CE 1F 26 6E 75 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 E0 39 0C 94 DD 07 0C 94 22 3D 0C 94 70 3D <\n>
RX: 27 10 00 CA 1A CE 1F 26 6E 75 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 29 0A 00 28 00 29 <\n>
RX: 27 11 00 CA 1A CE 1F 26 6E 75 00 20 28 6C 3A 00 4B 6E 6F 77 6E 20 63 6F 6D 6D 61 6E 64 73 3A 00 20 62 79 74 65 73 00 4E <\n>
RX: 27 12 00 CA 1A CE 1F 26 6E 75 6F 74 20 65 6E 6F 75 67 68 20 64 61 74 61 2C 20 6E 65 65 64 20 00 55 6E 72 65 63 6F 67 6E <\n>
RX: 27 13 00 CA 1A CE 1F 26 6E 75 69 7A 65 64 20 63 68 61 72 61 63 74 65 72 3A 20 00 2C 20 6E 78 74 53 3A 00 52 4C 3A 61 64 <\n>
RX: 27 14 00 CA 1A CE 1F 26 6E 75 6A 52 6C 79 2C 20 63 75 72 53 3A 00 2C 20 4F 66 66 54 69 6D 65 3A 00 2C 20 4F 66 66 44 6C <\n>
RX: 1B 15 20 CA 1A CE 1F 26 6E 75 79 3A 00 2C 20 4F 6E 54 69 6D 65 3A 00 2C 20 4F 6E 44 <\n>
.TX ACK<\n>
RX: 1B 27 20 CA 1A CE 1F 26 6E 75 4D 65 73 73 61 67 65 2C 20 70 6C 65 61 73 65 20 72 65 <\n>
We got a new ack request<\n>
TX ACK<\n>
RX: 27 28 00 CA 1A CE 1F 26 6E 75 01 00 70 6F 72 74 21 00 2C 20 68 75 6D 3A 20 00 57 45 41 54 48 45 52 5F 45 56 45 4E 54 3B <\n>
RX: 27 29 00 CA 1A CE 1F 26 6E 75 20 74 65 6D 70 3A 20 00 2C 20 76 61 6C 76 65 50 6F 73 3A 20 00 43 4C 49 4D 41 54 45 5F 45 <\n>
RX: 27 2A 00 CA 1A CE 1F 26 6E 75 56 45 4E 54 3B 20 63 6D 64 3A 20 00 2C 20 76 61 6C 34 3A 20 00 2C 20 66 6C 64 34 3A 20 00 <\n>
RX: 27 2B 00 CA 1A CE 1F 26 6E 75 2C 20 76 61 6C 33 3A 20 00 2C 20 66 6C 64 33 3A 20 00 2C 20 76 61 6C 32 3A 20 00 2C 20 66 <\n>
RX: 27 2C 00 CA 1A CE 1F 26 6E 75 6C 64 32 3A 20 00 2C 20 76 61 6C 31 3A 20 00 2C 20 66 6C 64 31 3A 20 00 53 45 4E 53 4F 52 <\n>
RX: 27 2D 00 CA 1A CE 1F 26 6E 75 5F 44 41 54 41 3B 20 63 6D 64 3A 20 00 2C 20 6E 65 78 74 3A 20 00 2C 20 76 61 6C 75 65 3A <\n>
RX: 27 2E 00 CA 1A CE 1F 26 6E 75 20 00 2C 20 6C 6F 77 42 61 74 74 3A 20 00 2C 20 6C 6F 6E 67 3A 20 00 53 45 4E 53 4F 52 5F <\n>
RX: 27 2F 00 CA 1A CE 1F 26 6E 75 45 56 45 4E 54 3B 20 62 75 74 74 6F 6E 3A 20 00 2C 20 63 6F 75 6E 74 65 72 3A 20 00 2C 20 <\n>
RX: 1B 30 20 CA 1A CE 1F 26 6E 75 6C 6F 77 42 61 74 74 3A 20 00 2C 20 6C 6F 6E 67 3A 20 <\n>
.TX ACK


müsste die wiederholung der 20ca message nicht identisch mit der ersten sein? auch der sprung in der msgnummernfolge ist seltsam.

im weiteren verlauf des updates sind die wiederholten 20ca messages dann identisch zur ersten. auch die msgnummern sehen gut aus. was passiert denn, wenn ich mit nack auf 20ca antworte? wird der letzte block wiederholt?

RX: 27 CA 00 CA 1A CE 1F 26 6E 75 01 00 11 96 9C 93 11 97 12 96 5C 91 12 97 42 E0 08 C0 FD 01 E2 0F F3 1F 94 52 80 81 98 27 <\n>
RX: 27 CB 00 CA 1A CE 1F 26 6E 75 90 83 4F 5F 8C 91 24 2F 30 E0 48 17 98 F3 FD 01 E2 0F F3 1F 80 81 85 27 80 83 08 95 DB 01 <\n>
RX: 27 CC 00 CA 1A CE 1F 26 6E 75 11 96 9C 91 11 97 86 E7 89 27 11 96 8C 93 11 97 42 E0 09 C0 FD 01 E2 0F F3 1F 80 81 94 52 <\n>
RX: 27 CD 00 CA 1A CE 1F 26 6E 75 98 27 90 83 4F 5F 98 2F 8C 91 24 2F 30 E0 48 17 90 F3 FD 01 E2 0F F3 1F 80 81 12 96 9C 91 <\n>
RX: 27 CE 00 CA 1A CE 1F 26 6E 75 89 27 80 83 08 95 FC 01 80 81 8F 70 90 E0 08 95 DF 93 CF 93 00 D0 CD B7 DE B7 20 91 C2 06 <\n>
RX: 27 CF 00 CA 1A CE 1F 26 6E 75 30 91 C3 06 CE 01 01 96 21 15 31 05 19 F4 86 5C 96 40 02 C0 82 1B 93 0B 9A 83 89 83 89 81 <\n>
RX: 27 D0 00 CA 1A CE 1F 26 6E 75 9A 81 0F 90 0F 90 CF 91 DF 91 08 95 CF 93 DF 93 F8 94 88 23 19 F4 40 91 6B 00 11 C0 81 30 <\n>
RX: 1B D2 20 CA 1A CE 1F 26 6E 75 4E C0 90 E0 FC 01 EE 0F FF 1F E2 5A FC 4F 01 A4 F2 A5 <\n>
pageSize and blockPos differ<\n>
RX: 1B D2 20 CA 1A CE 1F 26 6E 75 4E C0 90 E0 FC 01 EE 0F FF 1F E2 5A FC 4F 01 A4 F2 A5 <\n>
We got a new ack request<\n>
TX ACK<\n>
RX: 27 D3 00 CA 1A CE 1F 26 6E 75 01 00 E0 2D 20 81 24 23 DC 01 A2 5A BC 4F D1 96 6C 91 D1 97 62 27 11 F4 78 94 39 C0 D1 96 <\n>
RX: 27 D4 00 CA 1A CE 1F 26 6E 75 2C 93 58 2F 44 27 46 0F 51 1D EF E5 F3 E0 A0 E0 B0 E0 80 81 91 81 48 17 59 07 21 F5 AA 0F <\n>
RX: 27 D5 00 CA 1A CE 1F 26 6E 75 BB 1F A2 5A BC 4F 55 96 CD 91 DC 91 56 97 40 E0 86 2F 90 E0 30 E0 82 23 93 23 89 2B 09 F0 <\n>
RX: 27 D6 00 CA 1A CE 1F 26 6E 75 41 E0 44 0F 88 81 8D 7F 84 2B 88 83 0E 94 34 3A 6E 5C 7F 4F 8F 4F 9F 4F 69 83 7A 83 8B 83 <\n>
RX: 27 D7 00 CA 1A CE 1F 26 6E 75 9C 83 88 81 81 60 88 83 05 C0 11 96 32 96 AA 30 B1 05 91 F6 78 94 DF 91 CF 91 08 95 1F 92 <\n>
RX: 27 D8 00 CA 1A CE 1F 26 6E 75 0F 92 0F B6 0F 92 11 24 2F 93 3F 93 4F 93 5F 93 6F 93 7F 93 8F 93 9F 93 AF 93 BF 93 EF 93 <\n>
RX: 27 D9 00 CA 1A CE 1F 26 6E 75 FF 93 83 E0 0E 94 DF 0A FF 91 EF 91 BF 91 AF 91 9F 91 8F 91 7F 91 6F 91 5F 91 4F 91 3F 91 <\n>
RX: 27 DA 00 CA 1A CE 1F 26 6E 75 2F 91 0F 90 0F BE 0F 90 1F 90 18 95 1F 92 0F 92 0F B6 0F 92 11 24 2F 93 3F 93 4F 93 5F 93 <\n>
RX: 1B DB 20 CA 1A CE 1F 26 6E 75 6F 93 7F 93 8F 93 9F 93 AF 93 BF 93 EF 93 FF 93 82 E0

und weiterhin die frage: warum funktioniert das erste ack auf 0x20ca nicht (letzter post)?

update: ich habe jetzt auch ein nack eingebaut, wenn die pagegrösse nicht gross genug ist. das funktioniert sehr gut. der block wird neu gesendet mit den selben msgnummern. in einem fall wurde ein block sogar 2 mal wiederholt. damit hat sich die eine frage erledigt.

gruss frank

ich habe nun mal den cul als io am schalter definiert, ohne vccu. verbose vom schalter auf 5. hier wird es etwas deutlicher. das problem ist das nicht/falsch reagieren von fhem auf die bootloader-antwort der ersten 20CA message. wie man sieht ist die antwort ein nack, aber trotzdem wird der 2. block gesendet und nicht der erste wiederholt.

2014.10.28 16:39:06.572 5: CUL_HM SwitchPBU02 protEvent:CMDs_FWupdate
2014.10.28 16:39:06.574 2: CUL_HM fwUpdate started for SwitchPBU02
2014.10.28 16:39:06.578 4: CUL_send:  cul868As 0A 0A 3011 1ACE1F 266E75 CA
2014.10.28 16:39:06.670 3: CUL_HM set SwitchPBU02 fwUpdate fwUpdates/switchpbu02/HM_LC_Sw1PBU_FM_2014-10-24_1v4.eq3 20
2014.10.28 16:39:06.691 4: CUL_Parse: cul868 A 0C C7 8670 1BF81B 000000 00934E21 -57.5
2014.10.28 16:39:06.980 4: CUL_Parse: cul868 A 0A 0A 8002 266E75 1ACE1F 8030 -50
2014.10.28 16:39:11.975 4: CUL_Parse: cul868 A 14 00 0010 266E75 000000 004B45513131303937393730 -50
2014.10.28 16:39:11.982 2: CUL_HM fwUpdate SwitchPBU02 entered mode. IO-speed: fast
2014.10.28 16:39:12.078 4: CUL_send:  cul868As 0F 0B 00CB 1ACE1F 266E75 105B11F81547
2014.10.28 16:39:12.134 4: CUL_send:  cul868AR     
2014.10.28 16:39:12.191 5: CUL_HM fwUpdate write block 1 of 224: 9 messages
2014.10.28 16:39:12.195 4: CUL_send:  cul868As 27 0D 00CA 1ACE1F 266E75 01000C94B5070C9459390C9486390C94B3390C9494370C94930B0C946E0B
2014.10.28 16:39:12.212 4: CUL_send:  cul868As 27 0E 00CA 1ACE1F 266E75 0C94490B0C94F8080C94DD070C94DD070C94DD070C94DD070C94DD070C94
2014.10.28 16:39:12.228 4: CUL_send:  cul868As 27 0F 00CA 1ACE1F 266E75 DD070C94DD070C94DD070C94DD070C94E0390C94DD070C94223D0C94703D
2014.10.28 16:39:12.245 4: CUL_send:  cul868As 27 10 00CA 1ACE1F 266E75 0C94DD070C94DD070C94DD070C94DD070C94DD070C94DD07290A00280029
2014.10.28 16:39:12.261 4: CUL_send:  cul868As 27 11 00CA 1ACE1F 266E75 0020286C3A004B6E6F776E20636F6D6D616E64733A00206279746573004E
2014.10.28 16:39:12.278 4: CUL_send:  cul868As 27 12 00CA 1ACE1F 266E75 6F7420656E6F75676820646174612C206E6565642000556E7265636F676E
2014.10.28 16:39:12.294 4: CUL_send:  cul868As 27 13 00CA 1ACE1F 266E75 697A6564206368617261637465723A20002C206E7874533A00524C3A6164
2014.10.28 16:39:12.310 4: CUL_send:  cul868As 27 14 00CA 1ACE1F 266E75 6A526C792C20637572533A002C204F666654696D653A002C204F6666446C
2014.10.28 16:39:12.326 4: CUL_send:  cul868As 1B 15 20CA 1ACE1F 266E75 793A002C204F6E54696D653A002C204F6E44
2014.10.28 16:39:12.365 5: CUL_HM fwUpdate write block 2 of 224: 9 messages
2014.10.28 16:39:12.369 4: CUL_send:  cul868As 27 16 00CA 1ACE1F 266E75 01006C793A002C206E7874533A00524C3A7472696767657234302C206375
2014.10.28 16:39:12.385 4: CUL_send:  cul868As 27 17 00CA 1ACE1F 266E75 72533A002C2064757261543A002C2072616D70543A002C206E7874533A00
2014.10.28 16:39:12.401 4: CUL_send:  cul868As 27 18 00CA 1ACE1F 266E75 524C3A7472696767657231312C2076616C3A002C2070496478323A20002C
2014.10.28 16:39:12.417 4: CUL_send:  cul868As 27 19 00CA 1ACE1F 266E75 2070496478313A200072656D6F76655065657246726F6D4D73672C20636E
2014.10.28 16:39:12.433 4: CUL_send:  cul868As 27 1A 00CA 1ACE1F 266E75 6C3A20006164645065657246726F6D4D73672C20636E6C3A200061646450
2014.10.28 16:39:12.449 4: CUL_send:  cul868As 27 1B 00CA 1ACE1F 266E75 65657246726F6D4D73672C20636E6C3A20002C20646174613A2000736574
2014.10.28 16:39:12.464 4: CUL_send:  cul868As 27 1C 00CA 1ACE1F 266E75 4C69737446726F6D4D73672C206C656E3A20002C20646174613A20006765
2014.10.28 16:39:12.481 4: CUL_send:  cul868As 27 1D 00CA 1ACE1F 266E75 744C697374466F724D7367322C206C656E3A20002C20736C635074723A20
2014.10.28 16:39:12.497 4: CUL_send:  cul868As 1B 1E 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D
2014.10.28 16:39:12.526 4: CUL_Parse: cul868 A 0A 15 8002 266E75 1ACE1F 8036 -47
2014.10.28 16:39:12.548 4: CUL_Parse: cul868 A 0A 1E 8002 266E75 1ACE1F 8036 -47
2014.10.28 16:39:17.527 4: CUL_send:  cul868Ar     
2014.10.28 16:39:17.680 5: CUL_HM SwitchPBU02 protEvent:CMDs_done_FWupdate
2014.10.28 16:39:17.682 2: CUL_HM fwUpdate SwitchPBU02 end. IO-speed: normal

im log vom bootloader erkennt man, dass message nummer 10 nicht empfangen wurde. daraufhin hat der bootloader das nack gesendet.

AskSin OTA Bootloader V0.7.2<\n>
<\n>
TX bootloader sequence<\n>
TX: 14 00 00 10 26 6E 75 00 00 00 00 4B 45 51 31 31 30 39 37 39 37 <\n>
Wait for CB msg<\n>
Data not for us<\n>
RX: 0F 0B 00 CB 1A CE 1F 26 6E 75 10 5B 11 F8 15 47 <\n>
Got CB msg<\n>
Switch to 100k mode<\n>
Wait for CB msg<\n>
RX: 27 0D 00 CA 1A CE 1F 26 6E 75 01 00 0C 94 B5 07 0C 94 59 39 0C 94 86 39 0C 94 B3 39 0C 94 94 37 0C 94 93 0B 0C 94 6E 0B <\n>
Got CA msg<\n>
Receive firmware<\n>
RX: 27 0E 00 CA 1A CE 1F 26 6E 75 0C 94 49 0B 0C 94 F8 08 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 <\n>
RX: 27 0F 00 CA 1A CE 1F 26 6E 75 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 E0 39 0C 94 DD 07 0C 94 22 3D 0C 94 70 3D <\n>
RX: 27 11 00 CA 1A CE 1F 26 6E 75 00 20 28 6C 3A 00 4B 6E 6F 77 6E 20 63 6F 6D 6D 61 6E 64 73 3A 00 20 62 79 74 65 73 00 4E <\n>
RX: 27 12 00 CA 1A CE 1F 26 6E 75 6F 74 20 65 6E 6F 75 67 68 20 64 61 74 61 2C 20 6E 65 65 64 20 00 55 6E 72 65 63 6F 67 6E <\n>
RX: 27 13 00 CA 1A CE 1F 26 6E 75 69 7A 65 64 20 63 68 61 72 61 63 74 65 72 3A 20 00 2C 20 6E 78 74 53 3A 00 52 4C 3A 61 64 <\n>
RX: 1B 15 20 CA 1A CE 1F 26 6E 75 79 3A 00 2C 20 4F 6E 54 69 6D 65 3A 00 2C 20 4F 6E 44 <\n>
pageSize and blockPos differ<\n>
TX NACK<\n>
RX: 27 17 00 CA 1A CE 1F 26 6E 75 72 53 3A 00 2C 20 64 75 72 61 54 3A 00 2C 20 72 61 6D 70 54 3A 00 2C 20 6E 78 74 53 3A 00 <\n>
blockLen differ pageSize<\n>
RX: 27 18 00 CA 1A CE 1F 26 6E 75 52 4C 3A 74 72 69 67 67 65 72 31 31 2C 20 76 61 6C 3A 00 2C 20 70 49 64 78 32 3A 20 00 2C <\n>
RX: 27 19 00 CA 1A CE 1F 26 6E 75 20 70 49 64 78 31 3A 20 00 72 65 6D 6F 76 65 50 65 65 72 46 72 6F 6D 4D 73 67 2C 20 63 6E <\n>
RX: 27 1A 00 CA 1A CE 1F 26 6E 75 6C 3A 20 00 61 64 64 50 65 65 72 46 72 6F 6D 4D 73 67 2C 20 63 6E 6C 3A 20 00 61 64 64 50 <\n>
RX: 27 1C 00 CA 1A CE 1F 26 6E 75 4C 69 73 74 46 72 6F 6D 4D 73 67 2C 20 6C 65 6E 3A 20 00 2C 20 64 61 74 61 3A 20 00 67 65 <\n>
RX: 27 1D 00 CA 1A CE 1F 26 6E 75 74 4C 69 73 74 46 6F 72 4D 73 67 32 2C 20 6C 65 6E 3A 20 00 2C 20 73 6C 63 50 74 72 3A 20 <\n>
RX: 1B 1E 20 CA 1A CE 1F 26 6E 75 00 20 6F 66 20 00 0A 67 65 74 4C 69 73 74 46 6F 72 4D <\n>
pageSize and blockPos differ<\n>
TX NACK<\n>
Timeout<\n>
CRC fail, Reboot

update: hier noch ein log, wo man schön erkennt, dass fhem doch auf die nacks reagiert. meiner meinung nach, aber viel zu spät. oder ist das der plan?

2014.10.28 17:26:05.024 5: CUL_HM SwitchPBU02 protEvent:CMDs_FWupdate
2014.10.28 17:26:05.027 2: CUL_HM fwUpdate started for SwitchPBU02
2014.10.28 17:26:05.031 4: CUL_send:  cul868As 0A 0A 3011 1ACE1F 266E75 CA
2014.10.28 17:26:05.125 3: CUL_HM set SwitchPBU02 fwUpdate fwUpdates/switchpbu02/HM_LC_Sw1PBU_FM_2014-10-24_1v4.eq3
2014.10.28 17:26:05.457 4: CUL_Parse: cul868 A 0A 0A 8002 266E75 1ACE1F 0031 -49.5
2014.10.28 17:26:06.079 2: CUL_HM fwUpdate SwitchPBU02 entered mode. IO-speed: fast
2014.10.28 17:26:06.160 4: CUL_send:  cul868As 0F 0B 00CB 1ACE1F 266E75 105B11F81547
2014.10.28 17:26:06.216 4: CUL_send:  cul868AR     
2014.10.28 17:26:06.274 5: CUL_HM fwUpdate write block 1 of 224: 9 messages
2014.10.28 17:26:06.278 4: CUL_send:  cul868As 27 0D 00CA 1ACE1F 266E75 01000C94B5070C9459390C9486390C94B3390C9494370C94930B0C946E0B
2014.10.28 17:26:06.294 4: CUL_send:  cul868As 27 0E 00CA 1ACE1F 266E75 0C94490B0C94F8080C94DD070C94DD070C94DD070C94DD070C94DD070C94
2014.10.28 17:26:06.311 4: CUL_send:  cul868As 27 0F 00CA 1ACE1F 266E75 DD070C94DD070C94DD070C94DD070C94E0390C94DD070C94223D0C94703D
2014.10.28 17:26:06.327 4: CUL_send:  cul868As 27 10 00CA 1ACE1F 266E75 0C94DD070C94DD070C94DD070C94DD070C94DD070C94DD07290A00280029
2014.10.28 17:26:06.343 4: CUL_send:  cul868As 27 11 00CA 1ACE1F 266E75 0020286C3A004B6E6F776E20636F6D6D616E64733A00206279746573004E
2014.10.28 17:26:06.360 4: CUL_send:  cul868As 27 12 00CA 1ACE1F 266E75 6F7420656E6F75676820646174612C206E6565642000556E7265636F676E
2014.10.28 17:26:06.376 4: CUL_send:  cul868As 27 13 00CA 1ACE1F 266E75 697A6564206368617261637465723A20002C206E7874533A00524C3A6164
2014.10.28 17:26:06.392 4: CUL_send:  cul868As 27 14 00CA 1ACE1F 266E75 6A526C792C20637572533A002C204F666654696D653A002C204F6666446C
2014.10.28 17:26:06.408 4: CUL_send:  cul868As 1B 15 20CA 1ACE1F 266E75 793A002C204F6E54696D653A002C204F6E44
2014.10.28 17:26:06.425 4: CUL_Parse: cul868 A 14 00 0010 266E75 000000 004B45513131303937393732 -49
2014.10.28 17:26:06.434 5: CUL_HM fwUpdate write block 2 of 224: 9 messages
2014.10.28 17:26:06.528 4: CUL_send:  cul868As 27 16 00CA 1ACE1F 266E75 01006C793A002C206E7874533A00524C3A7472696767657234302C206375
2014.10.28 17:26:06.544 4: CUL_send:  cul868As 27 17 00CA 1ACE1F 266E75 72533A002C2064757261543A002C2072616D70543A002C206E7874533A00
2014.10.28 17:26:06.560 4: CUL_send:  cul868As 27 18 00CA 1ACE1F 266E75 524C3A7472696767657231312C2076616C3A002C2070496478323A20002C
2014.10.28 17:26:06.577 4: CUL_send:  cul868As 27 19 00CA 1ACE1F 266E75 2070496478313A200072656D6F76655065657246726F6D4D73672C20636E
2014.10.28 17:26:06.593 4: CUL_send:  cul868As 27 1A 00CA 1ACE1F 266E75 6C3A20006164645065657246726F6D4D73672C20636E6C3A200061646450
2014.10.28 17:26:06.609 4: CUL_send:  cul868As 27 1B 00CA 1ACE1F 266E75 65657246726F6D4D73672C20636E6C3A20002C20646174613A2000736574
2014.10.28 17:26:06.625 4: CUL_send:  cul868As 27 1C 00CA 1ACE1F 266E75 4C69737446726F6D4D73672C206C656E3A20002C20646174613A20006765
2014.10.28 17:26:06.641 4: CUL_send:  cul868As 27 1D 00CA 1ACE1F 266E75 744C697374466F724D7367322C206C656E3A20002C20736C635074723A20
2014.10.28 17:26:06.657 4: CUL_send:  cul868As 1B 1E 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D
2014.10.28 17:26:06.713 5: CUL_HM fwUpdate write block 3 of 224: 9 messages
2014.10.28 17:26:06.807 4: CUL_send:  cul868As 27 1F 00CA 1ACE1F 266E75 01007367322C206D73675074723A20002C20706565723A20004C6F616469
2014.10.28 17:26:06.823 4: CUL_send:  cul868As 27 20 00CA 1ACE1F 266E75 6E67206C6973743320666F7220636E6C3A20002C20646174613A20006765
2014.10.28 17:26:06.840 4: CUL_send:  cul868As 27 21 00CA 1ACE1F 266E75 745265672C206C656E3A20002C20706565724964783A20002C207068794C
2014.10.28 17:26:06.856 4: CUL_send:  cul868As 27 22 00CA 1ACE1F 266E75 656E3A20002C20706879416464723A20002C20736C634C656E3A20006765
2014.10.28 17:26:06.873 4: CUL_send:  cul868As 27 23 00CA 1ACE1F 266E75 74536C69636544657461696C2C20736C635074723A20002C2073697A6520
2014.10.28 17:26:06.889 4: CUL_send:  cul868As 27 24 00CA 1ACE1F 266E75 6F663A20004C6F6164696E67205065657244422C207374617274733A2000
2014.10.28 17:26:06.905 4: CUL_send:  cul868As 27 25 00CA 1ACE1F 266E75 646F6E650A0066697273742073746172742064657465637465642C20666F
2014.10.28 17:26:06.921 4: CUL_send:  cul868As 27 26 00CA 1ACE1F 266E75 726D6174696E6720656570726F6D2E2E2E0A000A0A00556E6B6E6F776E20
2014.10.28 17:26:06.938 4: CUL_send:  cul868As 1B 27 20CA 1ACE1F 266E75 4D6573736167652C20706C65617365207265
2014.10.28 17:26:06.963 4: CUL_Parse: cul868 A 0A 15 8002 266E75 1ACE1F 803A -45
2014.10.28 17:26:06.969 4: CUL_Parse: cul868 A 0A 1E 8002 266E75 1ACE1F 8039 -45.5
2014.10.28 17:26:07.007 4: CUL_Parse: cul868 A 0A 27 8002 266E75 1ACE1F 8039 -45.5
2014.10.28 17:26:11.965 5: CUL_HM fwUpdate write block 3 of 224: 9 messages
2014.10.28 17:26:11.970 4: CUL_send:  cul868As 27 0B 00CA 1ACE1F 266E75 01007367322C206D73675074723A20002C20706565723A20004C6F616469
2014.10.28 17:26:11.987 4: CUL_send:  cul868As 27 0C 00CA 1ACE1F 266E75 6E67206C6973743320666F7220636E6C3A20002C20646174613A20006765
2014.10.28 17:26:12.003 4: CUL_send:  cul868As 27 0D 00CA 1ACE1F 266E75 745265672C206C656E3A20002C20706565724964783A20002C207068794C
2014.10.28 17:26:12.019 4: CUL_send:  cul868As 27 0E 00CA 1ACE1F 266E75 656E3A20002C20706879416464723A20002C20736C634C656E3A20006765
2014.10.28 17:26:12.035 4: CUL_send:  cul868As 27 0F 00CA 1ACE1F 266E75 74536C69636544657461696C2C20736C635074723A20002C2073697A6520
2014.10.28 17:26:12.051 4: CUL_send:  cul868As 27 10 00CA 1ACE1F 266E75 6F663A20004C6F6164696E67205065657244422C207374617274733A2000
2014.10.28 17:26:12.067 4: CUL_send:  cul868As 27 11 00CA 1ACE1F 266E75 646F6E650A0066697273742073746172742064657465637465642C20666F
2014.10.28 17:26:12.084 4: CUL_send:  cul868As 27 12 00CA 1ACE1F 266E75 726D6174696E6720656570726F6D2E2E2E0A000A0A00556E6B6E6F776E20
2014.10.28 17:26:12.100 4: CUL_send:  cul868As 1B 13 20CA 1ACE1F 266E75 4D6573736167652C20706C65617365207265
2014.10.28 17:26:12.155 4: CUL_Parse: cul868 A 0A 13 8002 266E75 1ACE1F 803A -45
2014.10.28 17:26:17.129 5: CUL_HM fwUpdate write block 3 of 224: 9 messages
2014.10.28 17:26:17.134 4: CUL_send:  cul868As 27 0B 00CA 1ACE1F 266E75 01007367322C206D73675074723A20002C20706565723A20004C6F616469
2014.10.28 17:26:17.150 4: CUL_send:  cul868As 27 0C 00CA 1ACE1F 266E75 6E67206C6973743320666F7220636E6C3A20002C20646174613A20006765
2014.10.28 17:26:17.166 4: CUL_send:  cul868As 27 0D 00CA 1ACE1F 266E75 745265672C206C656E3A20002C20706565724964783A20002C207068794C
2014.10.28 17:26:17.183 4: CUL_send:  cul868As 27 0E 00CA 1ACE1F 266E75 656E3A20002C20706879416464723A20002C20736C634C656E3A20006765
2014.10.28 17:26:17.199 4: CUL_send:  cul868As 27 0F 00CA 1ACE1F 266E75 74536C69636544657461696C2C20736C635074723A20002C2073697A6520
2014.10.28 17:26:17.215 4: CUL_send:  cul868As 27 10 00CA 1ACE1F 266E75 6F663A20004C6F6164696E67205065657244422C207374617274733A2000
2014.10.28 17:26:17.232 4: CUL_send:  cul868As 27 11 00CA 1ACE1F 266E75 646F6E650A0066697273742073746172742064657465637465642C20666F
2014.10.28 17:26:17.248 4: CUL_send:  cul868As 27 12 00CA 1ACE1F 266E75 726D6174696E6720656570726F6D2E2E2E0A000A0A00556E6B6E6F776E20
2014.10.28 17:26:17.264 4: CUL_send:  cul868As 1B 13 20CA 1ACE1F 266E75 4D6573736167652C20706C65617365207265
2014.10.28 17:26:17.319 4: CUL_Parse: cul868 A 0A 13 8002 266E75 1ACE1F 8039 -45.5
2014.10.28 17:26:22.292 5: CUL_HM fwUpdate write block 3 of 224: 9 messages
2014.10.28 17:26:22.297 4: CUL_send:  cul868As 27 0B 00CA 1ACE1F 266E75 01007367322C206D73675074723A20002C20706565723A20004C6F616469
2014.10.28 17:26:22.313 4: CUL_send:  cul868As 27 0C 00CA 1ACE1F 266E75 6E67206C6973743320666F7220636E6C3A20002C20646174613A20006765
2014.10.28 17:26:22.329 4: CUL_send:  cul868As 27 0D 00CA 1ACE1F 266E75 745265672C206C656E3A20002C20706565724964783A20002C207068794C
2014.10.28 17:26:22.345 4: CUL_send:  cul868As 27 0E 00CA 1ACE1F 266E75 656E3A20002C20706879416464723A20002C20736C634C656E3A20006765
2014.10.28 17:26:22.361 4: CUL_send:  cul868As 27 0F 00CA 1ACE1F 266E75 74536C69636544657461696C2C20736C635074723A20002C2073697A6520
2014.10.28 17:26:22.377 4: CUL_send:  cul868As 27 10 00CA 1ACE1F 266E75 6F663A20004C6F6164696E67205065657244422C207374617274733A2000
2014.10.28 17:26:22.393 4: CUL_send:  cul868As 27 11 00CA 1ACE1F 266E75 646F6E650A0066697273742073746172742064657465637465642C20666F
2014.10.28 17:26:22.409 4: CUL_send:  cul868As 27 12 00CA 1ACE1F 266E75 726D6174696E6720656570726F6D2E2E2E0A000A0A00556E6B6E6F776E20
2014.10.28 17:26:22.425 4: CUL_send:  cul868As 1B 13 20CA 1ACE1F 266E75 4D6573736167652C20706C65617365207265
2014.10.28 17:26:22.481 4: CUL_Parse: cul868 A 0A 13 8002 266E75 1ACE1F 803A -45
2014.10.28 17:26:27.452 4: CUL_send:  cul868Ar     
2014.10.28 17:26:27.566 5: CUL_HM SwitchPBU02 protEvent:CMDs_done_FWupdate
2014.10.28 17:26:27.567 2: CUL_HM fwUpdate SwitchPBU02 end. IO-speed: normal

gruss frank

      select(undef, undef, undef, (0.01));# no wait necessary - FHEM is slow anyway
wenn ich zeile 5393 in version 7694 von 10_cul_hm.pm freischalte funktioniert ein update über fhem tadellos.  :)

da stellt sich natürlich die frage, ob fhem schneller geworden ist, oder unser bootloader zu langsam.

komisch, dass das nur die erste antwort betrifft. so habe ich jetzt auch deutlich weniger übertragungsfehler. missing messages. das könnte auch der grund sein, dass doch einige beim update über fhem deutliche probleme haben.

bleibt das ausgebaut, oder kann man darüber verhandeln?  ;)

update: mit hmusb als iodev habe ich auch mit der verzögerung bisher 2 fehlschläge hintereinander.

gruss frank

hallo martin,

manchmal gibt es einen fehler mit den msgnummern. dann gibt es folgenden fehler in fhem.log:

2014.10.30 14:35:41.035 1: PERL WARNING: Use of uninitialized value $mNo in sprintf at ./FHEM/10_CUL_HM.pm line 5342.

2014.10.30 14:35:24.611 5: CUL_HM SwitchPBU02 protEvent:CMDs_FWupdate
2014.10.30 14:35:24.612 2: CUL_HM fwUpdate started for SwitchPBU02
2014.10.30 14:35:24.616 4: CUL_send:  cul868As 0A 0A 3011 1ACE1F 266E75 CA
2014.10.30 14:35:24.716 3: CUL_HM set SwitchPBU02 fwUpdate fwUpdates/switchpbu02/HM_LC_Sw1PBU_FM_2014-10-24_1v4.eq3 20
2014.10.30 14:35:24.770 4: CUL_Parse: cul868 A 09 82 A112 1ACE1F 1DFC2F 34 -48
2014.10.30 14:35:24.775 4: CUL_Parse: cul868 A 0A 82 8002 1DFC2F 1ACE1F 0019 -61.5
2014.10.30 14:35:24.781 4: CUL_Parse: cul868 A 0B 82 A258 B2B2B2 1DFC2F 03FA34 -48
2014.10.30 14:35:25.061 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:04BA74DB d:FF r:FFDD     m:0A 3011 1ACE1F 266E75 CA
2014.10.30 14:35:25.069 4: CUL_Parse: cul868 A 0A 0A 8002 266E75 1ACE1F 8037 -46.5
2014.10.30 14:35:32.670 4: CUL_Parse: cul868 A 14 45 805E 266EA5 1ACE1F 000000000000000000000013 -64.5
2014.10.30 14:35:35.234 4: CUL_Parse: cul868 A 14 00 0010 266E75 000000 004B45513131303937393737 -46.5
2014.10.30 14:35:35.240 2: CUL_HM fwUpdate SwitchPBU02 entered mode. IO-speed: fast
2014.10.30 14:35:35.337 4: CUL_send:  cul868As 0F 0B 00CB 1ACE1F 266E75 105B11F81547
2014.10.30 14:35:35.393 4: CUL_send:  cul868AR     
2014.10.30 14:35:35.450 5: CUL_HM fwUpdate write block 1 of 224: 9 messages
2014.10.30 14:35:35.454 4: CUL_send:  cul868As 27 0D 00CA 1ACE1F 266E75 01000C94B5070C9459390C9486390C94B3390C9494370C94930B0C946E0B
2014.10.30 14:35:35.470 4: CUL_send:  cul868As 27 0E 00CA 1ACE1F 266E75 0C94490B0C94F8080C94DD070C94DD070C94DD070C94DD070C94DD070C94
2014.10.30 14:35:35.487 4: CUL_send:  cul868As 27 0F 00CA 1ACE1F 266E75 DD070C94DD070C94DD070C94DD070C94E0390C94DD070C94223D0C94703D
2014.10.30 14:35:35.503 4: CUL_send:  cul868As 27 10 00CA 1ACE1F 266E75 0C94DD070C94DD070C94DD070C94DD070C94DD070C94DD07290A00280029
2014.10.30 14:35:35.519 4: CUL_send:  cul868As 27 11 00CA 1ACE1F 266E75 0020286C3A004B6E6F776E20636F6D6D616E64733A00206279746573004E
2014.10.30 14:35:35.535 4: CUL_send:  cul868As 27 12 00CA 1ACE1F 266E75 6F7420656E6F75676820646174612C206E6565642000556E7265636F676E
2014.10.30 14:35:35.552 4: CUL_send:  cul868As 27 13 00CA 1ACE1F 266E75 697A6564206368617261637465723A20002C206E7874533A00524C3A6164
2014.10.30 14:35:35.568 4: CUL_send:  cul868As 27 14 00CA 1ACE1F 266E75 6A526C792C20637572533A002C204F666654696D653A002C204F6666446C
2014.10.30 14:35:35.584 4: CUL_send:  cul868As 1B 15 20CA 1ACE1F 266E75 793A002C204F6E54696D653A002C204F6E44
2014.10.30 14:35:35.622 5: CUL_HM fwUpdate write block 2 of 224: 9 messages
2014.10.30 14:35:35.626 4: CUL_send:  cul868As 27 16 00CA 1ACE1F 266E75 01006C793A002C206E7874533A00524C3A7472696767657234302C206375
2014.10.30 14:35:35.642 4: CUL_send:  cul868As 27 17 00CA 1ACE1F 266E75 72533A002C2064757261543A002C2072616D70543A002C206E7874533A00
2014.10.30 14:35:35.658 4: CUL_send:  cul868As 27 18 00CA 1ACE1F 266E75 524C3A7472696767657231312C2076616C3A002C2070496478323A20002C
2014.10.30 14:35:35.673 4: CUL_send:  cul868As 27 19 00CA 1ACE1F 266E75 2070496478313A200072656D6F76655065657246726F6D4D73672C20636E
2014.10.30 14:35:35.689 4: CUL_send:  cul868As 27 1A 00CA 1ACE1F 266E75 6C3A20006164645065657246726F6D4D73672C20636E6C3A200061646450
2014.10.30 14:35:35.705 4: CUL_send:  cul868As 27 1B 00CA 1ACE1F 266E75 65657246726F6D4D73672C20636E6C3A20002C20646174613A2000736574
2014.10.30 14:35:35.721 4: CUL_send:  cul868As 27 1C 00CA 1ACE1F 266E75 4C69737446726F6D4D73672C206C656E3A20002C20646174613A20006765
2014.10.30 14:35:35.737 4: CUL_send:  cul868As 27 1D 00CA 1ACE1F 266E75 744C697374466F724D7367322C206C656E3A20002C20736C635074723A20
2014.10.30 14:35:35.753 4: CUL_send:  cul868As 1B 1E 20CA 1ACE1F 266E75 00206F6620000A6765744C697374466F724D
2014.10.30 14:35:35.775 0: HMLAN_Parse: hmusb1 R:E266E75   stat:0000 t:04BA9CD6 d:FF r:FFBB     m:00 0010 266E75 000000 004B455131313039373937
2014.10.30 14:35:35.783 5: CUL_HM fwUpdate write block 3 of 224: 9 messages
2014.10.30 14:35:35.879 4: CUL_send:  cul868As 27 1F 00CA 1ACE1F 266E75 01007367322C206D73675074723A20002C20706565723A20004C6F616469
2014.10.30 14:35:35.896 4: CUL_send:  cul868As 27 20 00CA 1ACE1F 266E75 6E67206C6973743320666F7220636E6C3A20002C20646174613A20006765
2014.10.30 14:35:35.912 4: CUL_send:  cul868As 27 21 00CA 1ACE1F 266E75 745265672C206C656E3A20002C20706565724964783A20002C207068794C
2014.10.30 14:35:35.928 4: CUL_send:  cul868As 27 22 00CA 1ACE1F 266E75 656E3A20002C20706879416464723A20002C20736C634C656E3A20006765
2014.10.30 14:35:35.944 4: CUL_send:  cul868As 27 23 00CA 1ACE1F 266E75 74536C69636544657461696C2C20736C635074723A20002C2073697A6520
2014.10.30 14:35:35.960 4: CUL_send:  cul868As 27 24 00CA 1ACE1F 266E75 6F663A20004C6F6164696E67205065657244422C207374617274733A2000
2014.10.30 14:35:35.976 4: CUL_send:  cul868As 27 25 00CA 1ACE1F 266E75 646F6E650A0066697273742073746172742064657465637465642C20666F
2014.10.30 14:35:35.992 4: CUL_send:  cul868As 27 26 00CA 1ACE1F 266E75 726D6174696E6720656570726F6D2E2E2E0A000A0A00556E6B6E6F776E20
2014.10.30 14:35:36.008 4: CUL_send:  cul868As 1B 27 20CA 1ACE1F 266E75 4D6573736167652C20706C65617365207265
2014.10.30 14:35:36.023 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:04BA9D61 d:FF r:FFDD     m:0B 00CB 1ACE1F 266E75 105B11F81547
2014.10.30 14:35:36.044 4: CUL_Parse: cul868 A 0A 1E 8002 266E75 1ACE1F 803F -42.5
2014.10.30 14:35:36.057 4: CUL_Parse: cul868 A 0A 27 8002 266E75 1ACE1F 803F -42.5
2014.10.30 14:35:41.035 1: PERL WARNING: Use of uninitialized value $mNo in sprintf at ./FHEM/10_CUL_HM.pm line 5342.
2014.10.30 14:35:41.042 5: CUL_HM fwUpdate write block 3 of 224: 9 messages
2014.10.30 14:35:41.046 4: CUL_send:  cul868As 27 01 00CA 1ACE1F 266E75 01007367322C206D73675074723A20002C20706565723A20004C6F616469
2014.10.30 14:35:41.062 4: CUL_send:  cul868As 27 02 00CA 1ACE1F 266E75 6E67206C6973743320666F7220636E6C3A20002C20646174613A20006765
2014.10.30 14:35:41.078 4: CUL_send:  cul868As 27 03 00CA 1ACE1F 266E75 745265672C206C656E3A20002C20706565724964783A20002C207068794C
2014.10.30 14:35:41.094 4: CUL_send:  cul868As 27 04 00CA 1ACE1F 266E75 656E3A20002C20706879416464723A20002C20736C634C656E3A20006765
2014.10.30 14:35:41.110 4: CUL_send:  cul868As 27 05 00CA 1ACE1F 266E75 74536C69636544657461696C2C20736C635074723A20002C2073697A6520
2014.10.30 14:35:41.125 4: CUL_send:  cul868As 27 06 00CA 1ACE1F 266E75 6F663A20004C6F6164696E67205065657244422C207374617274733A2000
2014.10.30 14:35:41.142 4: CUL_send:  cul868As 27 07 00CA 1ACE1F 266E75 646F6E650A0066697273742073746172742064657465637465642C20666F
2014.10.30 14:35:41.157 4: CUL_send:  cul868As 27 08 00CA 1ACE1F 266E75 726D6174696E6720656570726F6D2E2E2E0A000A0A00556E6B6E6F776E20
2014.10.30 14:35:41.174 4: CUL_send:  cul868As 1B 09 20CA 1ACE1F 266E75 4D6573736167652C20706C65617365207265
2014.10.30 14:35:41.265 4: CUL_Parse: cul868 A 0A 09 8002 266E75 1ACE1F 803F -42.5
2014.10.30 14:35:46.198 1: PERL WARNING: Use of uninitialized value $mNo in sprintf at ./FHEM/10_CUL_HM.pm line 5342.
2014.10.30 14:35:46.204 5: CUL_HM fwUpdate write block 3 of 224: 9 messages
2014.10.30 14:35:46.207 4: CUL_send:  cul868As 27 01 00CA 1ACE1F 266E75 01007367322C206D73675074723A20002C20706565723A20004C6F616469
2014.10.30 14:35:46.224 4: CUL_send:  cul868As 27 02 00CA 1ACE1F 266E75 6E67206C6973743320666F7220636E6C3A20002C20646174613A20006765
2014.10.30 14:35:46.240 4: CUL_send:  cul868As 27 03 00CA 1ACE1F 266E75 745265672C206C656E3A20002C20706565724964783A20002C207068794C
2014.10.30 14:35:46.255 4: CUL_send:  cul868As 27 04 00CA 1ACE1F 266E75 656E3A20002C20706879416464723A20002C20736C634C656E3A20006765
2014.10.30 14:35:46.272 4: CUL_send:  cul868As 27 05 00CA 1ACE1F 266E75 74536C69636544657461696C2C20736C635074723A20002C2073697A6520
2014.10.30 14:35:46.288 4: CUL_send:  cul868As 27 06 00CA 1ACE1F 266E75 6F663A20004C6F6164696E67205065657244422C207374617274733A2000
2014.10.30 14:35:46.304 4: CUL_send:  cul868As 27 07 00CA 1ACE1F 266E75 646F6E650A0066697273742073746172742064657465637465642C20666F
2014.10.30 14:35:46.320 4: CUL_send:  cul868As 27 08 00CA 1ACE1F 266E75 726D6174696E6720656570726F6D2E2E2E0A000A0A00556E6B6E6F776E20
2014.10.30 14:35:46.336 4: CUL_send:  cul868As 1B 09 20CA 1ACE1F 266E75 4D6573736167652C20706C65617365207265
2014.10.30 14:35:46.398 4: CUL_Parse: cul868 A 0A 09 8002 266E75 1ACE1F 803F -42.5
2014.10.30 14:35:51.360 1: PERL WARNING: Use of uninitialized value $mNo in sprintf at ./FHEM/10_CUL_HM.pm line 5342.
2014.10.30 14:35:51.366 5: CUL_HM fwUpdate write block 3 of 224: 9 messages
2014.10.30 14:35:51.370 4: CUL_send:  cul868As 27 01 00CA 1ACE1F 266E75 01007367322C206D73675074723A20002C20706565723A20004C6F616469
2014.10.30 14:35:51.386 4: CUL_send:  cul868As 27 02 00CA 1ACE1F 266E75 6E67206C6973743320666F7220636E6C3A20002C20646174613A20006765
2014.10.30 14:35:51.403 4: CUL_send:  cul868As 27 03 00CA 1ACE1F 266E75 745265672C206C656E3A20002C20706565724964783A20002C207068794C
2014.10.30 14:35:51.419 4: CUL_send:  cul868As 27 04 00CA 1ACE1F 266E75 656E3A20002C20706879416464723A20002C20736C634C656E3A20006765
2014.10.30 14:35:51.436 4: CUL_send:  cul868As 27 05 00CA 1ACE1F 266E75 74536C69636544657461696C2C20736C635074723A20002C2073697A6520
2014.10.30 14:35:51.452 4: CUL_send:  cul868As 27 06 00CA 1ACE1F 266E75 6F663A20004C6F6164696E67205065657244422C207374617274733A2000
2014.10.30 14:35:51.468 4: CUL_send:  cul868As 27 07 00CA 1ACE1F 266E75 646F6E650A0066697273742073746172742064657465637465642C20666F
2014.10.30 14:35:51.484 4: CUL_send:  cul868As 27 08 00CA 1ACE1F 266E75 726D6174696E6720656570726F6D2E2E2E0A000A0A00556E6B6E6F776E20
2014.10.30 14:35:51.500 4: CUL_send:  cul868As 1B 09 20CA 1ACE1F 266E75 4D6573736167652C20706C65617365207265
2014.10.30 14:35:56.674 4: CUL_send:  cul868Ar     
2014.10.30 14:35:56.794 5: CUL_HM SwitchPBU02 protEvent:CMDs_done_FWupdate


gruss frank