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

[Clyde]

Habe die startfhem und fhem.cfg geändert auf Port 50001, was aber keinen Unterschied gemacht hat. Wie/Wo komme ich an die HMLAN.LOG?

2013.11.28 12:00:47 2: HMLAN_Parse: hmusb new condition disconnected
2013.11.28 12:00:47 3: Opening hmusb device 127.0.0.1:50001
2013.11.28 12:00:47 3: Can't connect to 127.0.0.1:50001: Connection refused
2013.11.28 12:00:47 1: Including ./log/fhem.save
2013.11.28 12:00:48 1: usb create starting
2013.11.28 12:00:48 1: usb create end

[marc2]

Hallo Clyde !

Beim Starten des hmland im Skript startfhem solltest Du eigentlich eine Umleitung von STDOUT und STDERR
in eine Datei sehen:

Code Auswählen Erweitern

/var/media/ftp/bin/hmland -l 127.0.0.1 -p 1000 -d -r 04:00 >[b] /var/media/ftp/fhem/log/hmland.log[/b] 2>&1

Diese Datei (in obigem Fall /var/media/ftp/fhem/log/hmland.log) ist das Logfile des hmland. Sie wird bei jedem
Neustart des hmland überschrieben.

Gruß, Marc

[Clyde]

Nach einigem Getüddel steht nun unter HMLAN ein hmusb mit Status opened in der Liste. 

HMLAND.LOG zeigte zuerst folgende Resultate

./hmland: can't load library 'libusb-1.0.so.0'

Der Dateiname ist aber 'libusb-1.0.so.0.1.0' ??

Ein shutdown in der Kommandozeile und ein Ausführen per Telnet "./startfhem"
brachte nun plötzlich folgende erfreuliche Zeile zustande

Daemon with PID 9364 started!

Folgende startfhem ist nun bei mir erfolgreich:

#!/bin/sh

home=/var/InternerSpeicher/fhem

cd $home

trap "" SIGHUP
modprobe cdc_acm
modprobe ftdi_sio
sleep 2

ln -sf $home/FHEM/fhemcmd.sh /var/fhemcmd

PATH=$home:$PATH
export PATH

export LD_LIBRARY_PATH=$home/lib
export PERL5LIB=$home/lib/perl5/site_perl/5.12.2/mips-linux:$home/lib/perl5/site_perl/5.12.2:$home/lib/perl5/5.12.2/mips-linux:$home/lib/perl5/5.12.2

#chmod 750 /var/InternerSpeicher/fhem/lib/hmland
ps | grep hmland | grep -v -q grep || $home/lib/hmland -l 127.0.0.1 -p 1000 -D -r 04:00
#  >/var/media/ftp/fhem/log/hmland.log 2>&1
sleep 2

perl fhem.pl fhem.cfg

Logfile:

2013.11.29 12:07:30 2: HMLAN_Parse: hmusb new condition disconnected
2013.11.29 12:07:30 3: Opening hmusb device 127.0.0.1:1000
2013.11.29 12:07:30 3: hmusb device opened
2013.11.29 12:07:30 2: HMLAN_Parse: hmusb new condition init
2013.11.29 12:07:30 1: Including ./log/fhem.save
2013.11.29 12:07:30 1: usb create starting
2013.11.29 12:07:31 1: usb create end

Leider habe ich jetzt keine Zeit weiterzumachen, aber sieht soweit ja schon gut aus.
Frage mich aber warum es nicht auf Anhieb funktionierte. Zuhause werde ich dann nochmal
einem Kaltstart versuchen.

[marc2]

Hallo Clyde,

dann hattest Du den Link nicht so wie hier beschrieben angelegt:

http://forum.fhem.de/index.php/topic,13071.msg86196.html#msg86196

Aber schön, dass es jetzt funktioniert.

Gruß, Marc

[Gandalv]

Hallo,

nachdem ich die Rechte angepasst hatte, lag es nur noch am Namen der Libusb.
Der Aufrufname war nicht der gleiche wied er Dateiname.
Dateiname angepasst und nun läuft es wunderbar

[Clyde]

Ja es funktioniert nun. Die HM Geräte lassen sich ansprechen.

Vielen Dank! 

[Loctotex]

Kann ich den HM-USB-CFG auch mit Fhem unter Windows nutzen?

[marc2]

Hallo Loctotex !

Ich bin nicht wirklich ein Kleinweich Freund, und würde mein Glück daher ggf. mit Cygwin probieren. Theoretisch
sollte es aber möglich sein, den hmland auch auch nativ unter Windows zu übersetzen, wenn man die richtige
Entwicklungsumgebung dafür hat. Bei Cygwin muss man darauf achten, dass die korrekte libusb-1.0 dabei ist.
Dies ist out of the box nur bei der 32bit Version der Fall. Für 64 bit müsste man sie sich wohl selber übersetzen.

Gruß, Marc

[marc2]

Moin !

Rein Interesse halber, hat schon jemand den HM-CFG-USB an einer 7270 am laufen ?

Gruß, Marc

[mere]

Hallo zusammen,

ich habe mit Interesse diesen Beitrag verfolgt und konnte auch als Newbie sehr einfach und schnell auf meinem Raspberry, zusammen mit FHEM, den USB-Stick zum Fliegen bekommen. Jetzt bin ich am testen mit einem HM-CC-RT-DN Thermostat (aktuell mein einziges Homematic-Device). das Pairen funktionert über das Autosave in FHEM problemlos. Aber irgendwie war es dann damit auch erledigt. Es findet danach keine Kommunikation mehr statt. Ich kann zwar ein getConfig auslösen, was im Log auftaucht aber Antwort bekomme ich darauf keine und der Zeitstempel für LastRcv verbleibt auf dem Zeitpunkt der Kopplung.

Was mache ich noch falsch?

Gruss

[Loctotex]

Hallo Loctotex !

Ich bin nicht wirklich ein Kleinweich Freund, und würde mein Glück daher ggf. mit Cygwin probieren.

Das könnte evtl gehen. Jetzt muss ich mir nur mal ein Stick besorgen.

Code Auswählen Erweitern


$ make
gcc -MMD -O2 -Wall -I/opt/local/include -g   -c -o hmland.o hmland.c
hmland.c:50:1: Warnung: »optarg« ohne Attribut »dllimport« redeklariert: vorheriges »dllimport« ignoriert [-Wattributes]
extern char *optarg;
^
gcc -MMD -O2 -Wall -I/opt/local/include -g   -c -o hmcfgusb.o hmcfgusb.c
hmcfgusb.c:57:0: Warnung: »INTERFACE« redefiniert [standardmäßig aktiviert]
#define INTERFACE 0
^
In file included from /usr/include/w32api/windows.h:108:0,
                 from /usr/include/libusb-1.0/libusb.h:40,
                 from hmcfgusb.c:33:
/usr/include/w32api/commdlg.h:575:0: Anmerkung: dies ist die Stelle der vorherigen Definition
#define INTERFACE IPrintDialogServices
^
hmcfgusb.c: In Funktion »hmcfgusb_init«:
hmcfgusb.c:348:2: Warnung: Übergabe des Arguments 2 von »hmcfgusb_prepare_int« von inkompatiblem Zeigertyp [standardmäßig aktiviert]
  dev->transfer = hmcfgusb_prepare_int(devh, hmcfgusb_interrupt, cb_data);
  ^
hmcfgusb.c:204:32: Anmerkung: »libusb_transfer_cb_fn« erwartet, aber Argument hat Typ »void (*)(struct libusb_transfer *)«
static struct libusb_transfer *hmcfgusb_prepare_int(libusb_device_handle *devh, libusb_transfer_cb_fn cb, void *data)
                                ^
gcc -L/opt/local/lib  hmland.o hmcfgusb.o  -lusb-1.0 -o hmland
gcc -MMD -O2 -Wall -I/opt/local/include -g   -c -o hmsniff.o hmsniff.c
gcc -L/opt/local/lib  hmsniff.o hmcfgusb.o  -lusb-1.0 -o hmsniff



[b_s101]

Hi,

erstmal vielen Dank für das Tool. Ich habe meine Pläne für den Einsatz von Homematic schon schwinden sehen bevor ich überhaupt mit FHEM anfangen konnte. Aber der erste Teil war keine richtige Hürde.

Falls jemand ein Startscript für Debian (und Derivate) benötigt:

Code Auswählen Erweitern

#! /bin/sh
# /etc/init.d/hmcfgusb

PID=/var/run/hmland.pid

case "$1" in
  start)
    echo "Starting hmland"
    /usr/local/bin/hmcfgusb/hmland -p 1234 -l 127.0.0.1 -d -r 03:33 -P
    sleep 2
    if [ ! -f $PID ]; then
    echo "Could not start hmland"
fi
    ;;
  stop)
    echo "Stopping hmland"
pkill -F $PID
    sleep 2
    if [  -f $PID ]; then
    echo "Could not stop hmland"
fi
    ;;
  *)
    echo "Usage: /etc/init.d/hmcfgusb {start|stop}"
    exit 1
    ;;
esac

exit 0
Die Zeile für den Aufruf von hmland muss ggf. angepasst werden.
Das Script am besten als /etc/init.d/hmcfgusb speichern, ausführbar machen und mit

Code Auswählen Erweitern

update-rc.d hmcfgusb defaults
beim Systemstart starten.

[chrisdash]

Hallo zusammen,

ich habe mit Interesse diesen Beitrag verfolgt und konnte auch als Newbie sehr einfach und schnell auf meinem Raspberry, zusammen mit FHEM, den USB-Stick zum Fliegen bekommen. Jetzt bin ich am testen mit einem HM-CC-RT-DN Thermostat (aktuell mein einziges Homematic-Device). das Pairen funktionert über das Autosave in FHEM problemlos. Aber irgendwie war es dann damit auch erledigt. Es findet danach keine Kommunikation mehr statt. Ich kann zwar ein getConfig auslösen, was im Log auftaucht aber Antwort bekomme ich darauf keine und der Zeitstempel für LastRcv verbleibt auf dem Zeitpunkt der Kopplung.

Was mache ich noch falsch?

Gruss

Hallo mere,
wenn du eine Lösung findet, lass sie mich bitte wissen... ich habe meinen HM-CFG-USB-2 direkt an meinem Heimserver angeschlossen, eine Atom 230 CPU in einem Mini-ITX Board. Darauf ist Debian squeeze installiert. Und an sich läuft der Stick auch mittels hmland, aber er sendet wohl keine Befehle. Jedenfalls liefert getConfig nie etwas zurück und ich kann über das web interface von fhem auch keine Temperaturen bei meinen HM-CC-RT-DN setzen. Pairen hat aber offenbar funktioniert, denn die ID meines Sticks ist unter pairedTo eingetragen. Der Server zeichnet auch fleißig readings der fünf HM-CC-RT-DN in einer Datenbank auf, ohne Unterbrechungen, die drahtlose Kommunikation scheint also an sich nicht das Problem zu sein. Laut Logging des hmland dauert die USB-Kommunikation mit dem Stick aber immer so 50-60ms, das erscheint mir ganz schön hoch (kein Hub!).

Hi,

erstmal vielen Dank für das Tool. Ich habe meine Pläne für den Einsatz von Homematic schon schwinden sehen bevor ich überhaupt mit FHEM anfangen konnte. Aber der erste Teil war keine richtige Hürde.

Falls jemand ein Startscript für Debian (und Derivate) benötigt:

Code Auswählen Erweitern

#! /bin/sh
# /etc/init.d/hmcfgusb

PID=/var/run/hmland.pid

case "$1" in
  start)
    echo "Starting hmland"
    /usr/local/bin/hmcfgusb/hmland -p 1234 -l 127.0.0.1 -d -r 03:33 -P
    sleep 2
    if [ ! -f $PID ]; then
    echo "Could not start hmland"
fi
    ;;
  stop)
    echo "Stopping hmland"
pkill -F $PID
    sleep 2
    if [  -f $PID ]; then
    echo "Could not stop hmland"
fi
    ;;
  *)
    echo "Usage: /etc/init.d/hmcfgusb {start|stop}"
    exit 1
    ;;
esac

exit 0
Die Zeile für den Aufruf von hmland muss ggf. angepasst werden.
Das Script am besten als /etc/init.d/hmcfgusb speichern, ausführbar machen und mit

Code Auswählen Erweitern

update-rc.d hmcfgusb defaults
beim Systemstart starten.

Vielen Dank für das Script, kann ich für mein Debian gut gebrauchen! Du hast beim Aufruf von hmland dessen Ausgaben nicht in eine Datei umgeleitet, ist das Absicht? Gut, wenn deiner einwandfrei läuft, brauchst du das Logging vielleicht nicht...

Viele Grüße
Christian

[b_s101]

Genau, mein Stick läuft bisher völlig problemlos, daher benötige ich kein Logging. System ist ein Raspberry Pi mit einem selbstgebauten Raspbian, as nur das Nötigste beinhaltet. Das Pairing hat auch direkt aus dem Stand funktioniert. Bisher kann ich nicht meckern

[chrisdash]

usb-transfer took 63ms!
usb-transfer took 43ms!
usb-transfer took 57ms!
usb-transfer took 66ms!
usb-transfer took 55ms!
usb-transfer took 56ms!

Sind diese Werte zu hoch? Ist das möglicherweise die Ursache für nicht funktionierende Kommunikation mit den HM-CC-RT-DN ohne burst? Der Stick hängt an einem älteren Mini-DTX board mit Intel Atom 230 (Diamondville), darauf ein aktuelles Debian squeeze.