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

[frank]

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

Code Auswählen Erweitern

  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.

Code Auswählen Erweitern

    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

[T.ihmann]

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

[frank]

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

[T.ihmann]

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

[martinp876]

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?

[frank]

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.

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

Wird 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:

Aktuell 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

[frank]

hallo thomas,

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

[T.ihmann]

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.

[Mr. P]

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.

[T.ihmann]

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

[jab]

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

[frank]

hallo jan,

martins ablauf funktioniert (aktuell) folgendermassen:

nach absetzen von

Code Auswählen Erweitern

set mydevice fwUpdate myfirmware.eq3 20
sendet fhem

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

2014.05.12 16:25:37.618 4: CUL_send:  cul868AR
und fängt umgehend mit dem senden der firmware daten an

Code Auswählen Erweitern

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

[martinp876]

Hi Frank,

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.

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.

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.

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 

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.

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

@Jan

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

Code Auswählen Erweitern

11 ssssss dddddd CA
in den bootloader.
Die

20CB 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.

2. 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?

Code Auswählen Erweitern

0010 xxxxxx 000000 004B455130353736363035

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)

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

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

Siehe oben - die CB message schaltet quasi direkt

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)

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.

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)

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.

7. Gerät startet neu nach einem Timeout

korrekt.

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

.
korrekt

Ggf 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

[frank]

hallo martin,

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

Code Auswählen Erweitern

    if ($blocks < $step){#last block
#      CUL_HM_FWupdateSpeed($name,10);
      CUL_HM_FWupdateEnd("done");
      Log3 $name,2,"CUL_HM fwUpdate completed";
    }

[martinp876]

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

muss 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