FHEM - Hausautomations-Systeme > Homematic

HomeMatic USB Konfigurations-Adapter (HM-CFG-USB) in Fhem nutzen

(1/218) > >>

mgernoth:
Hallo,

da ich mich zur Zeit mit HomeMatic beschäftige, habe ich nach dem günstigsten PC-Interface gesucht, welches die AES-Signierung implementiert. Dabei bin ich auf den HM-CFG-USB{,2} gestossen, welcher jedoch im Moment von Fhem noch nicht unterstützt wird (es gibt ein paar gänderte Perl-Module mit denen nur der Empfang von HM-Nachrichten möglich ist).

Um den Stick in Fhem zu integrieren bin ich nicht den normalen Weg eines Fhem-Moduls gegangen, sondern habe eine kleine Software geschrieben, welche einen HMLAN emuliert. Damit kann man den USB-Stick sowohl am Fhem-Rechner als auch an jedem anderen (Unix/Linux) Rechner im Netz anschliessen und ihn von Fhem aus benutzen.

Die HMLAN-Emulation findet sich hier: https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb

Um das ganze in Fhem zu benutzen, kann man die Software entweder als freigegebene Version (aktuell: 0.102) oder als Entwicklungsversion als .tar.gz herunterladen oder mit git clonen:

--- Code: ---git clone git://git.zerfleddert.de/hmcfgusb

--- Ende Code ---
Danach findet sich der Quellcode im Unterverzeichnis hmcfgusb.

Um die Software zu kompilieren, braucht man (neben make und gcc, bei Debian am besten build-essential installieren) noch das Development-Paket für libusb-1.0 (Debian: libusb-1.0-0-dev).
Wenn man die nötigen Voraussetzungen geschaffen hat, dann sollte die Software ohne Fehlermeldungen kompilieren und (zumindest als root) starten:

--- Code: ---deepthought [~/hmcfgusb]> make
gcc -MMD -O2 -Wall -I/opt/local/include -g   -c -o hmland.o hmland.c
gcc -MMD -O2 -Wall -I/opt/local/include -g   -c -o hmcfgusb.o hmcfgusb.c
gcc -L/opt/local/lib -lusb-1.0 -lm  hmland.o hmcfgusb.o   -o hmland

deepthought [~/hmcfgusb]> ./hmland -h
Syntax: ./hmland options

Possible options:
        -D              debug mode
        -d              daemon mode
        -h              this help
        -I              pretend to be HM-LAN-IF for compatibility with client-software (previous default)
        -i              interactive mode (connect HM-CFG-USB to terminal)
        -l ip           listen on given IP address only (for example 127.0.0.1)
        -L logfile      log network-communication to logfile
        -P              create PID file /var/run/hmland.pid in daemon mode
        -p n            listen on port n (default: 1000)
        -r n            reboot HM-CFG-USB after n seconds (0: no reboot, default: 86400 if FW < 0.967, 0 otherwise)
           hh:mm        reboot HM-CFG-USB daily at hh:mm
        -S serial       use HM-CFG-USB with given serial (for multiple hmland instances)
        -v              verbose mode
        -V              show version (0.102)

deepthought [~/hmcfgusb]> ./hmland -D -p 1234

--- Ende Code ---

Nun kann man den neuen HMLAN in Fhem einbinden:


--- Code: ---define hmusb HMLAN 127.0.0.1:1234
attr hmusb hmId 424242

--- Ende Code ---

Danach sollte der hmland Debug-Ausgaben ausgeben:

--- Code: ---Client 127.0.0.1 connected!

USB < 0x0000: 4b                                                K

USB > 0x0000: 48 09 48 4d 2d 55 53 42 2d 49 46 03 bc 0a 4a 45   H.HM-USB-IF...JE
USB > 0x0010: 51 30 35 33 35 31 32 32 1d b1 55 42 42 42 00 3a   Q0535122..UBBB.:
USB > 0x0020: 5f 66 00 01 00 00 00 00 00 00 00 00 00 00 00 00   _f..............
USB > 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
LAN < HHM-USB-IF,03BC,JEQ0535122,1DB155,424242,003A5F66,0001


LAN > A424242
...

--- Ende Code ---

Evtl. rebootet der HM-CFG-USB nach einer Änderung der hmId (A-Kommando), damit kommt aber sowohl der hmland wie auch Fhem klar (es dauert nur ein bisschen, bis der reconnect durchgeführt wurde).

Sollte man den hmland nicht als root ausführen wollen, kann man die hmcfgusb.rules in das Udev rules-Verzeichnis kopieren:

--- Code: ---cp hmcfgusb.rules /etc/udev/rules.d/

--- Ende Code ---

Wenn alles funktioniert, kann man den hmland ohne Debug-Ausgabe als Daemon starten:

--- Code: ---./hmland -d -p 1234
Daemon with PID 3065 started!

--- Ende Code ---

Selbst die Windows-Konfigurationssoftware scheint mit der Emulation sprechen zu können, hier habe ich aber noch keine richtigen Tests durchgeführt. Hierfür muss der hmland aber auf Port 1000 lauschen, wofür zwingend root-Rechte nötig sind.

Da der HM-CFG-USB mit Firmware < 0.967 gelegentlich das Senden einstellt, wird er in der Standardkonfiguration 24 Stunden nach Verbindungsaubau neugestartet, wenn eine alte Firmware erkannt wird. Dieses Verhalten kann mit dem Parameter -r beeinflusst werden. Der Stick sollte aber besser auf die aktuelle Firmware (siehe unten) aktualisiert werden, um das Problem richtig zu beheben.

Die Software ist in C mit der einzigen Abhängigkeit libusb-1.0 geschrieben, womit sie auch auf kleinen Routern mit OpenWRT oder z.B. einer Fritzbox genutzt werden kann. Fritzbox-Binaries finden sich in diesem Post, ein OpenWrt-Paket für die ar71xx-Platform gibt es hier.

Update der Firmware des HM-CFG-USB

Seit dem 10.2.2014 kann nun auch die Firmware des HM-CFG-USB aktualisiert werden. Hierzu wird mindestens die Version 0.092-git von hmcfgusb und eine Firmwaredatei (heisst meistens hmusbif.enc) benötigt. Die aktuellste Firmware (0.967) findet sich hier (extrahiert hier). Hat man diese Voraussetzungen geschaffen, kann man die Firmware nun aktualisieren (wichtig ist hierbei, dass hmland nicht parallel läuft):


--- Code: ---deepthought [~/hmcfgusb]> ./flash-hmcfgusb hmusbif.enc
HM-CFG-USB flasher version 0.102

Reading firmware from hmusbif.enc...
Firmware with 368 blocks successfully read.

HM-CFG-USB not in bootloader mode, entering bootloader.
Interrupt transfer not completed: Unknown error code 1 / 0x01!
Can't send null frame: Input/output error

Waiting for device to reappear...
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!

HM-CFG-USB opened.

Flashing 368 blocks: |

Firmware update successfull!

--- Ende Code ---

Die aktuelle Firmwareversion kann so herausgefunden werden:


--- Code: ---deepthought [~/hmcfgusb]> ./hmland -i
HHM-USB-IF,03C7,JEQ0535122,1DB155,000000,0001B663,0000

--- Ende Code ---

Die 03C7 ist hierbei die Version in Hex (in Dezimal: 967).

Update der Firmware von OTA-fähigen Geräten

Seit dem 16.2.2014 kann auch die Firmware von OTA-fähigen Geräten mit dem HM-CFG-USB aktualisiert werden, seit dem 5.3.2014 geht dies auch mit einem CULv3 oder COC. Diese Funktionalität ist mittlerweile auch direkt in Fhem integriert und von dort aus komfortabler nutzbar.

Möchte man einen HM-CC-RT-DN mit der Seriennummer KEQ0123456 mit Hilfe des HM-CFG-USB auf Version 1.3 updaten, kann folgendes Kommando benutzt werden (wichtig ist hierbei, dass hmland nicht parallel läuft):

--- Code: ---deepthought [~/hmcfgusb]> ./flash-ota -f hm_cc_rt_dn_update_V1_3_001_140314.eq3 -s KEQ0123456
HomeMatic OTA flasher version 0.102

Reading firmware from hm_cc_rt_dn_update_V1_3_001_140314.eq3...
Firmware with 234 blocks successfully read.

Rebooting HM-CFG-USB to avoid running out of credits

HM-CFG-USB not in bootloader mode, entering bootloader.
Interrupt transfer not completed: Unknown error code 1 / 0x01!
Can't send null frame: Input/output error
Waiting for device to reappear...
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB in bootloader mode, rebooting
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!

HM-CFG-USB opened

HM-CFG-USB firmware version: 967
Entering 10k-mode
Waiting for device with serial KEQ0123456
Device with serial KEQ0123456 (hmid: 012345) entered firmware-update-mode
Adding HMID
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 234 blocks: 0234/0234 -
Entering 10k-mode
Waiting for device to reboot

--- Ende Code ---

Benutzt man ein CUL an /dev/ttyACM0 funktioniert es so:


--- Code: ---deepthought [~/hmcfgusb]> ./flash-ota -f hm_cc_rt_dn_update_V1_3_001_140314.eq3 -s KEQ0123456 -c /dev/ttyACM0
HomeMatic OTA flasher version 0.102

Reading firmware from hm_cc_rt_dn_update_V1_3_001_140314.eq3...
Firmware with 234 blocks successfully read.
Opening culfw-device at path /dev/ttyACM0 with speed 38400
Requesting firmware-version
culfw-device firmware version: 1.58
Entering 10k-mode
Waiting for device with serial KEQ0123456
Device with serial KEQ0123456 (hmid: 012345) entered firmware-update-mode
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 234 blocks: 0234/0234 -
Entering 10k-mode
Waiting for device to reboot

--- Ende Code ---

Anstatt der Seriennummer des Geräts kann auch die HMID mit dem Parameter -D angegeben werden.

Wenn die Meldung "Waiting for device with serial..." erscheint, muss das Gerät manuell in den FUP-Modus versetzt werden. Beim HM-CC-RT-DN müssen hierbei beim Einlegen der Batterien die beiden äußeren Tasten gleichzeitig betätigt werden.

Um ein Gerät automatisch in den FUP-Modus zu versetzen, sind die Parameter -D (HMID des Geräts), -C (HMID der gepairten Zentrale) sowie evtl. -K (AES-Schlüssel im MD5 hmKey-Format) notwendig. Die zusätzliche Angabe der Seriennummer mit -s ist nicht notwendig. Sollte ein HM-CFG-USB mit richtig gesetzter Zentralen-ID verwendet werden, so kann auch -C weggelassen werden. Wenn die Zentrale mit -C angegeben wird, wird diese auf einem HM-CFG-USB gesetzt. Bei Verwendung eines culfw-Geräts muss die ID der Zentrale immer angegeben werden.

Falls jemand die Software benutzt, würde ich mich über Rückmeldungen freuen.

Gruß
  Michael

kuschelganxta:
Hi Michael,

ich versuche diesen Dienst auf einem (ubuntu) Linux auf dem wandboard zum Fliegen zu kriegen - leider scheitert es am Linken:

--- Code: ---
root@wandboard:/home/sascha/hmcfgusb# make
gcc -MMD -O2 -Wall -I/opt/local/include -g   -c -o hmland.o hmland.c
gcc -MMD -O2 -Wall -I/opt/local/include -g   -c -o hmcfgusb.o hmcfgusb.c
gcc -L/opt/local/lib -lusb-1.0 -lm  hmland.o hmcfgusb.o   -o hmland
hmcfgusb.o: In function `hmcfgusb_interrupt':
/home/sascha/hmcfgusb/hmcfgusb.c:246: undefined reference to `libusb_submit_transfer'
/home/sascha/hmcfgusb/hmcfgusb.c:249: undefined reference to `libusb_free_transfer'
/home/sascha/hmcfgusb/hmcfgusb.c:234: undefined reference to `libusb_free_transfer'
hmcfgusb.o: In function `hmcfgusb_send':
/home/sascha/hmcfgusb/hmcfgusb.c:149: undefined reference to `libusb_interrupt_transfer'
/home/sascha/hmcfgusb/hmcfgusb.c:156: undefined reference to `libusb_interrupt_transfer'
[weitere Fehler...]

--- Ende Code ---


Die Libs, devel-Pkgs sind installiert und funktionieren.
Hast du hier einen Tipp?

Danke & Grüße
Sascha

mgernoth:
Hi Sascha,


--- Zitat von: kuschelganxta schrieb am Mi, 12 Juni 2013 20:08 ---
ich versuche diesen Dienst auf einem (ubuntu) Linux auf dem wandboard zum Fliegen zu kriegen - leider scheitert es am Linken:

--- Ende Zitat ---


Danke für der Report, das kann ich auf einem Ubuntu Raring (allerdings auf der langweiligen Architektur x86_64) reproduzieren, liegt wohl an einem neueren Linker, der strikter auf die Parameterreihenfolge achtet. Die war falsch, deswegen kam es zu dem Fehler.
Habe gerade einen Fix eingecheckt, jetzt sollte es tun.

Solltest Du einen git-checkout benutzen, bringt Dich ein "git pull" auf den aktuellen Stand.

Gruß
  Michael

kuschelganxta:
Michael,


--- Zitat von: mgernoth schrieb am Mi, 12 Juni 2013 20:25 ---
Habe gerade einen Fix eingecheckt, jetzt sollte es tun.
Solltest Du einen git-checkout benutzen, bringt Dich ein "git pull" auf den aktuellen Stand.

--- Ende Zitat ---


Danke, danke, danke für den schnellen Fix, den Hinweis für git pull (benutze git nicht häufig ;) und natürlich die tolle Arbeit. Es kompiliert wunderbar und läuft soweit ich das sehen kann:

--- Code: ---
root@wandboard:/home/sascha/hmcfgusb# ./hmland -Di -p 1234

USB < 0x0000: 4b                                                K

USB > 0x0000: 48 09 48 4d 2d 55 53 42 2d 49 46 03 bc 0a 4a 45   H.HM-USB-IF...JE
USB > 0x0010: 51 30 31 32 30 37 39 31 1a ce 95 1a ce 95 00 00   Q0120791........
USB > 0x0020: 1c 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
USB > 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
LAN < HHM-USB-IF,03BC,JEQ0120791,1ACE95,1ACE95,00001C04,0000

HHM-USB-IF,03BC,JEQ0120791,1ACE95,1ACE95,00001C04,0000

--- Ende Code ---


Die Windows-Software kommt (mit Port 1000) klar, Geräte werden angezeigt. Das Programmieren scheint aber nicht möglich zu sein...egal ;)

Ist das HMLAN-Protokoll eigentlich irgendwo dokumentiert?
Ich würde gern diese Kombi in openHAB als Binding hibzufügen...

Herzlichen Dank,
Sascha

mgernoth:
Hi Sascha,


--- Zitat von: kuschelganxta schrieb am Mi, 12 Juni 2013 20:50 ---Es kompiliert wunderbar und läuft soweit ich das sehen kann:

--- Code: ---
root@wandboard:/home/sascha/hmcfgusb# ./hmland -Di -p 1234
...

--- Ende Code ---


--- Ende Zitat ---


Schön zu hören, dass es funktioniert :-)

Allerdings habe ich eine Mischung der Parameter "i" und "p" nicht vorgesehen, in diesem Fall wird das "p" ignoriert und der hmland läuft nur im interaktiven Modus.


--- Zitat ---
Die Windows-Software kommt (mit Port 1000) klar, Geräte werden angezeigt. Das Programmieren scheint aber nicht möglich zu sein...egal ;)

--- Ende Zitat ---


Hmm, ok. Bei mir hatte das eigentlich geklappt (ok, ich hab nur einen Knopfdruck simuliert...).
Das Wandaboard hat - wenn ich das richtig sehe - einen ARM (und ist damit little endian)? Dann sollten sich auch evtl. vorhandene Byteorder-Probleme nicht auswirken. Ich habe die Software nämlich bisher noch nicht auf Big-Endian getestet, wüsste aber keine Stelle, die dabei Probleme machen könnte.


--- Zitat ---
Ist das HMLAN-Protokoll eigentlich irgendwo dokumentiert?
Ich würde gern diese Kombi in openHAB als Binding hibzufügen...

--- Ende Zitat ---


Nein, nicht das ich wüsste, es ist aber nicht sehr komplex (wenn man nur senden (S) und empfangen (E und R) will).
Der beste Einstieg sollte FHEM/00_HMLAN.pm sein, und da die Funktion HMLAN_Parse bzw. HMLAN_Write.

Gruß
  Michael

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln