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

Begonnen von mgernoth, 30 Mai 2013, 17:06:32

Vorheriges Thema - Nächstes Thema

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:

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

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:

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


Nun kann man den neuen HMLAN in Fhem einbinden:


define hmusb HMLAN 127.0.0.1:1234
attr hmusb hmId 424242


Danach sollte der hmland Debug-Ausgaben ausgeben:

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


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:

cp hmcfgusb.rules /etc/udev/rules.d/


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

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


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


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!


Die aktuelle Firmwareversion kann so herausgefunden werden:


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


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

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


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


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


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:

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


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:08ich versuche diesen Dienst auf einem (ubuntu) Linux auf dem wandboard zum Fliegen zu kriegen - leider scheitert es am Linken:

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:25Habe gerade einen Fix eingecheckt, jetzt sollte es tun.
Solltest Du einen git-checkout benutzen, bringt Dich ein "git pull" auf den aktuellen Stand.

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:

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


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:50Es kompiliert wunderbar und läuft soweit ich das sehen kann:

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


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.

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

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.

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

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

betateilchen

Ich habe das Ganze jetzt mal versucht, auf dem Raspberry zu installieren. Kompilieren funktioniert einwandfrei, beim Starten passiert aber folgendes:


/opt/hmcfgusb # ./hmland -D -p 1234
Client 127.0.0.1 connected!
Can't find/open hmcfgusb!
Can't initialize HM-CFG-USB!
Connection to 127.0.0.1 closed!



  • ein lsusb liefert keinen Hinweis auf den Stick.
  • wenn ich den Stick einstecke, gibt es im syslog keinen Hinweis auf irgendein neues USB Gerät

Was kann denn da schieflaufen?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

mgernoth

Hallo,

Zitat von: betateilchen schrieb am Mi, 03 Juli 2013 13:54Ich habe das Ganze jetzt mal versucht, auf dem Raspberry zu installieren. Kompilieren funktioniert einwandfrei, beim Starten passiert aber folgendes:


...
Can't find/open hmcfgusb!
...


Das USB-Gerät wird nicht gefunden, passt auch zu Deinen folgenden Aussagen.

Zitat
  • ein lsusb liefert keinen Hinweis auf den Stick.
  • wenn ich den Stick einstecke, gibt es im syslog keinen Hinweis auf irgendein neues USB Gerät

Was kann denn da schieflaufen?

Hmm, also eigentlich sollte im Log auf jeden Fall etwas erscheinen und auch lsusb das Gerät zeigen. Wenn der Stick nicht in lsusb auftaucht, kann der hmland auch nicht funktionieren...

Welchen Kernel benutzt Du? Der USB-Stack des RPi ist ziemlich kaputt, mit aktuellen Kerneln aus rpi-update ist es aber erträglich. Damit lief zumindest bei mir der HM-CFG-USB an einem RPi, schön war es aber nicht, da der USB-Stack manche Transfers etwas verzögert. Könnte aber evtl. demnächst behoben werden.

Gruß
  Michael

betateilchen

Hallo Michael,

danke für Deine schnelle Reaktion. Der Raspberry ist auf dem aktuellsten Stand,

Linux rasp-fhem 3.6.11+ #474 PREEMPT Thu Jun 13 17:14:42 BST 2013 armv6l

Das mit dem USB Stack mag schon stimmen, aber bisher habe ich sämtliche USB Geräte trotzdem zum Laufen gebracht, sogar SDR via DVB-T Stick. Und zumindest im Log sollte ja irgendwas passieren, wenn man den Stick anschließt.

Ich hab mal eine "doofe" Frage: Funktioniert der Stick eigentlich out-of-the-box oder muss der irgendwie (z.B. unter Windows) konfiguriert werden? Ich habe den nämlich einfach ausgepackt und angesteckt. Wenn ich den Stick an mein MacBook anschließe, wird er korrekt erkannt.

Viele Grüße
Udo

edit:

ist das der Stick?

Bus 001 Device 005: ID 1b1f:c00f

auf einem zweiten Raspberry wird mir diese Info bei einem lsusb ausgegeben, auf dem Raspberry mit FHEM allerdings nicht.

eedit:

auf dem zweiten Raspi die Source per git ausgecheckt und kompiliert - der Stick läuft problemlos.

Also irgendwas muss auf dem ersten Raspi faul sein - ich geh mal auf die Suche.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Problem gelöst - es lag nicht an Deiner Software und auch nicht an meinem Stick oder Raspberry, sondern einfach an meiner eigenen Dussligkeit: ich hatte das Datenkabel zwischen Raspberry und dem neu eingesetzten USB Hub vergessen (http://www.smiliesuche.de/smileys/kopf-gegen-wand/kopf-gegen-wand-smilies-0005.gif)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

mgernoth

Hi,

sowas passiert jedem.

Freut mich aber zu hören, dass es jetzt bei Dir funktioniert. :-)

Gruß
  Michael

betateilchen

Das Pairing mit Tür-/Fensterkontakten (meine aktuelle Aufgabe) ist aber noch ein reines Glücksspiel. Mehr als einen Kontakt pro Tag bekomme ich noch nicht zum Laufen. Das Pairen eines zweiten Gerätes schlägt danach regelmäßig fehl.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

mgernoth

Hallo,

Zitat von: betateilchen schrieb am Do, 04 Juli 2013 19:47Das Pairing mit Tür-/Fensterkontakten (meine aktuelle Aufgabe) ist aber noch ein reines Glücksspiel. Mehr als einen Kontakt pro Tag bekomme ich noch nicht zum Laufen. Das Pairen eines zweiten Gerätes schlägt danach regelmäßig fehl.

Wie äussert sich das bzw. wie/woran scheitert es?

Kannst Du evtl. mal die Protokollierung hochdrehen?
attr hmcfgusb hmProtocolEvents 5

Gruß
  Michael

betateilchen

Das äußert sich in einer undefinierbaren Lichtorgel am Kontakt selbst.

Und ich bekomme folgende Fehlermeldungen:


2013.07.04 20:13:52 3: Device Melder_FSr added to ActionDetector with 028:00 time
Use of uninitialized value $updt in concatenation (.) or string at ./FHEM/00_HMLAN.pm line 472.
Use of uninitialized value $updt in concatenation (.) or string at ./FHEM/00_HMLAN.pm line 473.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

mgernoth

Hallo,

da scheint der Channel des TFK im Fhem nicht zu existieren, das ist sehr merkwürdig...

Kannst Du den hmland im Debug-Modus (-D) laufen lassen, ein Pairing durchführen und mir die Ausgabe des hmland per PM/Mail schicken?

Edit: Ursache für Fehlermeldung verbessert

Gruß
  Michael

betateilchen

Hallo Michael,

typischer Vorführeffekt: inzwischen sind alle Fensterkontakte mit dem USB Stick gepaired.

Für die Statistik:

erfolgreich gepaired sind:

4 * HM-SEC-SC
1 * HM-WDS10-TH-O
1 * HM-SEC-SD inkl. virtuellem Master-Device

noch einzurichten (derzeit noch mit HMLAN in Betrieb) sind:

1 * HM-TC-CC
1 * HM-TC-VD
1 * HM-SEC-RHS
1 * HM-LC-Sw1PBU-FM
1 * HM-LC-SW1-BA-PCB
1 * HM-RC-4-2

geplant sind:

weitere 3 * HM-SEC-SC

Aber heute habe ich keine Lust mehr.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!