CMD: set <device> fwUpdate <filename> [<waittime>]

Samsi · 12 Mai 2014, 13:49:08

@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

martinp876 · 12 Mai 2014, 15:10:53

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

frank · 12 Mai 2014, 15:15:04

Zitatso, das Kommando ist jetzt freigeschaltet.

cool.

auch für hmusb, oder nur cul?

gruss frank

martinp876 · 12 Mai 2014, 15:22:06

hmUSB noch nicht.
Du kannst aber die Sperre entfernen und testen

Code Auswählen

#    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.

frank · 12 Mai 2014, 15:39:46

et voila!

Code Auswählen

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

frank · 12 Mai 2014, 17:13:03

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:

Code Auswählen

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:

Code Auswählen

{$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

martinp876 · 12 Mai 2014, 17:31:12

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?

frank · 12 Mai 2014, 18:24:10

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

Code Auswählen

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

windows version

Code Auswählen

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.

martinp876 · 12 Mai 2014, 19:47:24

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

frank · 13 Mai 2014, 11:12:51

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.

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

gruss frank

martinp876 · 13 Mai 2014, 11:24:03

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);
}

frank · 13 Mai 2014, 11:31:20

ZitatWie gesagt - kann ein zeitliches Problem sein.

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

jab · 13 Mai 2014, 11:40:00

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

frank · 13 Mai 2014, 14:32:51

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

martinp876 · 13 Mai 2014, 19:48:20

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)