Neue Firmware für HM_LC_Sw1PBU_FM mit getrenntem Aktor, Taster + Wechselschalter

Begonnen von jab, 29 Dezember 2013, 22:04:10

Vorheriges Thema - Nächstes Thema

hexenmeister

Moin!

Habe neulich bei EQ3 neue Firmwareversion für den Rolladen UP-Aktor entdeckt. Habe sie heute erfogreich per Funk geflasht. Es geht wohl auch bei dem HM_LC_Sw1PBU_FM. Da frage ich mich, ob das erstmaliges Löten überhaupt notwendig ist. War diese Methode noch nicht bekannt oder woran hat es gescheit? An der Signatur?

Grüße,

Alexander

Mr. P

Zitat von: hexenmeister am 20 Juli 2014, 22:44:06
Habe neulich bei EQ3 neue Firmwareversion für den Rolladen UP-Aktor entdeckt. Habe sie heute erfogreich per Funk geflasht. Es geht wohl auch bei dem HM_LC_Sw1PBU_FM. Da frage ich mich, ob das erstmaliges Löten überhaupt notwendig ist. War diese Methode noch nicht bekannt oder woran hat es gescheit? An der Signatur?
Very nice! :-)
Die Funktion war bislang wohl einfach unbekannt und natürlich stellt sich die Frage, was dabei neu geflasht wird: Nur die Schalter Firmware oder auch der Bootloader gleich mit.
Was hexenmeister zu meinen scheint, ist folgendes aus der Update-Anleitung:
1. Netzspannung ausschalten / vom Gerät trennen (Ggfs. Sicherheitshinweise der Installation beachten!),
2. den Aus/runter-Taster (UP-Markenschalter) bzw. den Bedientaster von Kanal 1 (sonstige Aktoren) drücken und festhalten,
3. bei immer noch gedrückt gehaltener Taste den Aktor wieder mit Netzspannung versorgen.
4. Sobald die LED schnell blinkt, kann die Taste losgelassen werden. Das Update wird jetzt durchgeführt.

Hat noch jemand einen "jungfräulichen" Schalter bei sich und Lust und Laune auszuprobieren, was dabei passiert? :-)
Greetz,
   Mr. P

unimatrix

hab keinen jungfräulichen mehr. Ob die eq3-Firmware signiert ist und der eq3-Bootloader das dann checkt, weiß ich nicht. Es ist mir ehrlich gesagt auch egal. Mit der eigenen FW macht es einfach mehr Spass :)

Ich habe dazu übrigens nix gefunden. Vll hat eq3 ja die Anregung von hier aufgenommen und nun auch die Features eingebaut? :)

Mr. P

Zitat von: unimatrix am 21 Juli 2014, 02:32:42
Ich habe dazu übrigens nix gefunden. Vll hat eq3 ja die Anregung von hier aufgenommen und nun auch die Features eingebaut? :)
Das Update gibt es nur für den HM-LC-BI1PBU-FM und betrifft dort auch nur:
** Bugfix
   * Reset kann aus dem Anlernmodus heraus ausgeführt werden 
   * StatusInfo Verzögerung und Zufallsanteil falsch initialisiert
   * einschlafende Konfiguration bei AES aktiv
Greetz,
   Mr. P

hexenmeister

Genau das meine ich ;)
Wenn das ausgenutzt werden kann, dann braucht man an dem Schalter weder zu löten, noch ihm aufzumachen, was die "Ausprobier-Schwelle" für viele erheblich niedriger setzt.
Außerdem wird evtl. auch der Weg zurück möglich sein. Da ist man dann auch eher zum experimentieren bereit.
EQ3 hat wohl OTA schon immer im Auge gehabt. Es schlummert vermutlich in allen HM Geräten.

Mr. P

Zitat von: hexenmeister am 21 Juli 2014, 07:20:20
Außerdem wird evtl. auch der Weg zurück möglich sein. Da ist man dann auch eher zum experimentieren bereit.
Naja... Solange eq-3 kein Firmware-Update-File für den Schalter anbietet, bleibt es vorerst trotzdem ein One-Way Experiment.
Greetz,
   Mr. P

trilu

Das ganze wird auf absehbare Zeit immer ein oneway bleiben. Die Updateprozedur basiert auf einem eq3 Bootloader, der wird hier aber überschrieben...
Eigene Software über den original EQ3 Bootloader einspielen geht nicht, da wir kein signiertes Update erzeugen können...
Das einzige was helfen könnte, wäre ein Systemdump.

Viele Grüße
Horst

unimatrix

man könnte testen ob man die eq3-Software über den Custom-BL einspielen kann (bzw. ob sie dann läuft).

Habe mich allerdings gefragt, wie eq3- das mit dem Signaturcheck macht. da der Flash 64 kbyte hat gibt es nichts wo man das Image puffern kann bevor man die Signatur checkt um es dann ins Flash zu schreiben. Der Flashversuch eines nicht-signierten Images müsste ja dann zu einem nicht mehr laufenden Gerät führen, ebenso ein abgebrochener Flash-Vorgang. Das externe Eeprom hat auch nur 32 kbit. Es sei denn sie limitieren ihre SW auf diese Größe...

So lange es keine neue FW für den Schalter gibt, sind das Spekulationen.

Das mit der "Hürde" finde ich schon ok. Wer nicht 6 oder 8 Leitungen anlöten will (eine Arbeit von 2 Minuten) der sollte es auch lieber nicht flashen. Wer einfach nur ein funktionierendes System haben will, ohne Zeit, sich darüber im Detail gedanken zu machen, der ist mit der eq3-Firmware richtig.

Die Hauptidee der Lib war ja auch glaube ich der Nachbau von Devices, das Flashen von CustomFW in bestehende Devices ist nur ein Nebeneffekt.

Edit: Es sind natürlich nur 32 KBit nicht KByte (beim 24C32). Habe das externe EEPROM mal ausgelesen. Sind nur die ersten 64 Byte mit irgendeinem Zeug beschrieben. Die HMID meiner Zentrale ist nicht dabei. Das EEPROM müsste ja aus Zeiten der Standard-FW noch unangetastet sein.

Wie schon an anderer Stelle gesagt. Wenn mir irgendjemand den Schaltplan /die Bauanleitung für den PBU Dimmaktor gibt, dann erkläre ich mich bereit, einen meiner für erste Tests zu zerflashen. Das Entwickeln von dem Phasenabschnittsdimmer könnte aber ohne angeschllossenen Leistungsteil schwierig werden. Und ob ich das damit dann gleichzeitig noch an den UART meines PIs anschließen möchte, ist eine andere Frage...müsste man sich ggf. ein Testbed mit galvanischer Trennung bauen. Wenn man denn den Schaltplan erstmal hat...

hexenmeister

Den schaltplan für up dimmer habe ich. Der lag dem Bausatz bei.  Kann ich die später per pm zukommen lassen.

T.ihmann

Verstehe ich es richtig, daß ich mir die entsprechende Firmware für den Rolladenaktor bei EQ3 runterladen muß und dann per

set device fwUpdate <file> 100

das Update starten kann, dann die Runter Taste lang drücke und dann das Update startet ?

Welche Änderungen sind denn in der aktuellen Firmware vorhanden ? Gibt es bei EQ3 ein Changelog ?

frank

könnte man das fw-update des jalousie-schalters bitte in einem neuen thread behandeln? dieser thread ist bereits sehr unübersichtlich und muss nicht noch unnötigerweise mit nicht passenden themen belastet werden. ausserdem hätten andere mit der selben thematik auch etwas davon. danke.

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

kossmann


Dirk

Ich habe mich mal an dem OTA-Bootloader etwas "ausgetobt"
Der Fork liegt aktuell hier: https://github.com/kc-GitHub/Asksin_OTA_Bootloader

Was habe ich gemacht?

  • Eine config.h angelegt und fast alle Hardware abhängigen Einstellungen (Ports, Debugausgabe ja/nein, CRC ja/nein, usw) hier abgelegt.
    So ist es hoffentlich möglich verschiedene Konfigurationen ohne eine komplette überarbeitung des Kern-Codes zu nutzen.
    In der beiliegenden config.h habe ich alle Einstellungen für den Atmega328p und die Pinkonfiguration des Universalsensors eingestellt

  • Ich habe die Arduino-Reste entfernt und entsprechend ersetzt. Somit wird der Code fast 1k kleiner. Jetzt bekomme ich den Bootloader mit CRC und Debugausgaben gerade noch in die 4k Bootloaderbereich des Atmega328

  • Die Status-LED welche man aktivieren kann, blinkt jetzt während der Bootloader das Programm flasht.

  • Device-Type, Seriennummer und Adresse kann man an eine fixe Adresse in die letzten 16 Bytes des Bootloaderbereiches schreiben. Damit kann die Applikation auf diese Daten zugreifen und bei Bedarf nutzen. Dieses Verhalten kann man in der config.h ein- oder ausschalten

  • Die Debugausgaben habe ich etwas "verstümmelt" Damit der Code mit Debugausgaben etwas kleiner wird. Man kann diese aber noch interpretieren. Außerdem kann man in der config.h die Debugausgaben ein- oder ausschalten.

  • Das Makefile habe ich etwas angepasst

Ich glaube das war es erst einmal.
Auf meinem Sensor mit dem Atmea328p funktioniert das aktuell. Es ist aber möglich und auch wahrscheinlich das hier noch ein paar Fehler drin sind.
Insbesondere ist der Code für Timer und Interrupt noch nicht konfigurierbar. Wenn man also einen anderen Timer oder Interrupt für den GDO0 benutzen möchte muss man noch im Code was ändern. Vielleicht hat dazu ja noch jemand eine Idee.

Aktuell komme ich auf folgende Codegrößen:

  • 2852 Bytes: Ohne alles
  • 3194 Bytes: Mit LED+ CRC
  • 4036 Bytes: Mit LED+ CRC + Debug

Viele Grüße
Dirk

Ps: Ich habe keinen eigenen Tread für den Bootloader gefunden. Ich hoffe hier ist der Beitrag gut ausfgehoben.

jab

Hi Dirk,

Ziemlich cool. Wenn du magst kannst du auch einen Pull Request stellen oder ich gebe dir, wie unimatrix auch, commit Rechte.

Gruß
Jan

Dirk

Hi Jan,

Ja, können wir machen.
Vielleicht kannst du es ja vorher noch mal testen.

Ich hab noch eine neue Idee.
Ich würde gerne dem Bootloader eine Verschlüsselung beibringen. Vor allem wenn man den Bootloader per Funk startet, und wir können den Funk ja noch nicht verschlüssel, kann jeder mit bissl KnowHow das Device "zerflashen" oder eine "Bösartige" FW drauf flashen.

Angriffe in der Form gibt es zwar eher noch nicht, aber in Zukunft wird das verutlich anders aussehen.

Damit das kompakt bleibt, habe ich mal nach "einfachen" Verschlüsselungsmethoden gesucht. Das hier fand ich interessant:
http://de.wikipedia.org/wiki/XTEA

Das sollte dann auch noch in die 4k vom Atmega328 passen.

Die Programme zum Flashen flash-ota usw. sollten davon nix mitbekommen, weil das eq3-file vorher verschlüsselt wird.
Was hältst du / ihr davon?

Gruß
Dirk