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

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

Vorheriges Thema - Nächstes Thema

betateilchen

Wozu? Das Modul für den Stick gibt es schon, es heißt HMLAN.

Der hmland ist der Gerätetreiber, der gebraucht wird, um den Stick überhaupt mit irgendeinem Modul nutzen zu können, hier geht es um eine Hardwarefrage, nicht um eine Anwendungssoftware. Das ist in etwa vergleichbar mit der ethersex-Firmware, die man auf ein AVR Net-IO Board installieren muss, um es dann mit dem Modul ECMD in FHEM nutzen zu können.

Ich vermute, diese (in meinen Augen) geniale Softwarelösung mit dem Dämon wird irgendwann Bestandteil von FHEM (z.B. in ./contrib) und dann generell mit "ausgeliefert". Wir reden hier schließlich nur von einer einzigen ausführbaren Datei die man irgendwo starten muss. Den größten Vorteil sehe ich darin, dass diese Datei irgendwo im Netzwerk laufen kann und nicht an die Hardware gebunden ist, auf der FHEM läuft.

(nur meine Meinung, es darf gerne jeder eine andere haben)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

marc2

Moin !

Nachdem ich mir nun einen anständigen USB HUB besorgt und an die 7390
gesteckt habe, kann ich den HM-CFG-USB nun auch über den USB HUB an
der 7390 betreiben.

Gruß, Marc

marc2

Hi !

Nachdem das ganze auch über den USB HUB vier Tage problemlos lief, war am Montag
um 22:32 Uhr komischer Weise schluss. Im Log standen keine Fehlermeldungen aber
der USBCFG hat keine Messages mehr gesendet, wohl aber empfangen. Ich habe dann
einen anderen USBCFG an den HUB angeschlossen. Dieser hat dann prinzipiell wieder
funktioniert, allerdings meldete der hmland dann wieder mögliche Timingprobleme
auf dem USB Bus (~ 120ms). Ich habe den HUB daraufhin wieder entfernt. Jetzt läuft
auch der ursprüngliche USBCFG wieder einwandfrei. Die Kombination Fritzbox, USB HUB
und HMLAN USBCFG scheint also tendenziell zu USB Timingproblemen und damit
Fehlfunktionen zu führen. Hat ausser mir zwischenzeitlich sonst noch jemand
diese Kombination getestet, der seine Erfahrungen einbringen könnte ?

Gruß, Marc

Tobias

ich würde das grundsätzlich nicht so stehen lassen. Vieles steht und fällt mit der Güte des USB-Hubs.
Ich hatte schon Hubs gehabt, die alle 5 min den Link verloren hatten und der REchner dahinter die Devices neu initialisieren musste.
Gute Erfahrungen habe ich mit einem 7er König Hub (30€) und einem DLINK DUB-H7 (30€)

(http://www.smargo.de/images/product_images/popup_images/4_0.jpg)
(http://dstatic.computeruniverse.net/images/500/90087713573f9489b4114025b0057bd9.jpg)
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

betateilchen

den DLINK H7 habe ich auch - eine echte "install-and-forget"-Lösung: einmal installieren, funktioniert ewig
-----------------------
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,

Zitat von: marc2 schrieb am Mi, 24 Juli 2013 23:37Nachdem das ganze auch über den USB HUB vier Tage problemlos lief, war am Montag
um 22:32 Uhr komischer Weise schluss. Im Log standen keine Fehlermeldungen aber
der USBCFG hat keine Messages mehr gesendet, wohl aber empfangen.

Hmm, das ist schon irgendwie komisch, dass sowohl Du als auch betateilchen das gleiche Verhalten hattet, bei dem der USB-Stick nur noch empfangen aber nicht gesendet hat. Und bei Udo hat auch nur das aus- und einstecken den HMCFGUSB geholfen. Evtl. hat die Firmware von dem Ding ein Problem, wenn es zu lange läuft (Bei Udo hätte der Stick selber ein Ack generieren müssen, ohne dass eine Kommunikation mit Fhem nötig gewesen wäre).

Ich weiss auch mittlerweile, wie man den Stick (auf eine sehr unschöne Art und Weise) rebooten kann, dann baue ich demnächst ein periodisches Reboot alle 24h (parametrisierbar) ein. Während des Reboots ist der Stick dann für eine Minute weg...

Gruß
  Michael

betateilchen

Hallo Michael,

guter Plan. Kannst Du das dann auch gleich noch als "set <device> reboot" einbauen, damit man das auch machen kann, ohne jedes Mal zum Verteilerkasten rennen zu müssen, falls das Problem zwischen den 24 Stunden auftritt?

Viele Grüße
Udo
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

marc2

Hi !

Nach den ursprünglichen Problemen mit einem Noname HUB hatte ich mir
immerhin einen netten LogiLink HUB für die Aufwandmontage gegönnt. Es lief
ja immerhin auch einige Tage einwandfrei bis plötzlich das Sendeproblem
aufgetreten ist. Die Meldung "usb-transfer took more than 100ms" sieht
man nur wenn man STDERR des hmland in eine Datei umleitet. Da ich
dies anfänglich nicht getan habe und die Meldung nicht ständig auftritt,
kann ich  nicht mit Gewissheit sagen, ob dies nicht auch vorher schon
aufgetreten ist. Mit Gewissheit (aufgrund einiger Tests heute Abend) kann ich aber
sagen, dass sie ohne USB-HUB nicht auftreten). Der Overhead durch den
USB HUB beträgt demnach mindestens bis zu 30ms (die gemeldeten Werte liegen
zwischen 101ms und 129ms). Auch wenn sie meistens über 90% idle ist, könnte ich
mir vorstellen, dass meine gute alte 7390 mit der Masse an HM und MAX Devices,
Events etc. inzwischen etwas überlastet ist. Im MAX Umfeld (mit CUNO) habe ich
in letzter Zeit vermehrt das Problem, dass ACKs scheinbar nicht schnell
genug versendet werden. Da sich hier in den letzten Wochen und Monaten
wenig getan hat, kann es eigentlich weder am CUNO noch an CUL_MAX liegen,
sondern schlicht daran, dass FHEM auf der 7390 nicht mehr schnell genug
hinterher kommt. Im selben Umfeld sehe obiges Timingproblem. Die Sendeproblematik
scheint ein anderes Thema zu sein.

Gruß, Marc

betateilchen

Zitat von: marc2 schrieb am Do, 25 Juli 2013 23:04habe ich in letzter Zeit vermehrt das Problem, dass ACKs scheinbar nicht schnell genug versendet werden. Da sich hier in den letzten Wochen und Monaten wenig getan hat, kann es eigentlich weder am CUNO noch an CUL_MAX liegen, sondern schlicht daran, dass FHEM auf der 7390 nicht mehr schnell genug hinterher kommt.

Bei mir müssten die ACK aber direkt vom Stick zum HM-device geschickt werden, ohne dass FHEM und/oder mein Raspberry dabei im Spiel wären. Deshalb ist das Problem sehr wohl am Stick selbst zu suchen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

marc2

Wie gesagt, die  "usb-transfer took more than 100ms" und das Sendeproblem
sind zwei Paar Schuhe. Letzteres scheint ja nach einem Firmware Problem des
Sticks auszusehen. Die Ursache des ersten Problems isr mir noch nicht klar.
Aufgrund der aktuellen Erfahrungen mit MAX und ähnlichen Effekten mit HM, als
ich noch eine reine CUL/CUNO Umgebung für HM gefahren habe, weisen darauf hin,
dass es wirklich die Last der 7390 sein könnte.

Gruß, Marc

betateilchen

Zitat von: marc2 schrieb am Fr, 26 Juli 2013 13:07Wie gesagt, die  "usb-transfer took more than 100ms" und das Sendeproblem sind zwei Paar Schuhe.

Ja, das simmt.
Aber das usb-transfer... Problem ist nicht auf die Fritzbox reduziert, das taucht auch z.B. beim RaspberryPi auf, wenn man den hmland dort laufen läßt.
Kommt vermutlich einfach daher, dass USB (genau wie Landhausstil und Laminatfußboden) von Anfang an ein Irrweg war, bei dem es aber kein zurück gibt.



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

Laffer72

Hallo,

habe das ganze mal auf meiner Fritzbox 7390 wie ein Stück weiter oben beschrieben eingerichtet. USB-Stick steckt und leuchtet.
Habe im Log immer diese Fehlermeldung

2013.07.26 21:43:41 3: Opening hmusb device 127.0.0.1:1234
2013.07.26 21:43:41 3: Can't connect to 127.0.0.1:1234: Connection refused

Das Device hmusb wird als disconnected geführt

Wenn ich hmland über telnet auf derFB starte mit
./hmland -l 127.0.0.1:1234 -p 1000 -d
kommt die Meldung:
inet_ntop: Success
Daemon with PIDXXXX startet

Vielleicht hat ja einer von Euch Ahnung woran es hackt. Würde mich über einen Tip freuen.

Schönen Abend noch

Reinhard


Raspberry Pi Rev.B, FB7390 (FHEM2FHEM), Sonos, Smarter Coffee
Osram Lightify:2m LED-Streifen, 5m-LED-Streifen, Gartenspot, Surface 28W, Classic E14,E27, Classic RGBW E27, PAR16 GU10, Plug
CUL868:FS20-ST, FS20-DI, FS20-FMS, FS20-ES1
HMUSB:HM-Sec-RHS,HM-Sec-MDIR2
Jeelink868:TX-29-IT, TFA30.315

Laffer72

Bin jetzt schon ein bisserl weiter. Der Aufruf
./hmland -D -p 1234

bewirkt in fhem, daß das Device als opend bezeichnet wird.

Es scheint, daß der Aufruf in der startfhem nicht wirklich funktioniert.

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/var/media/ftp/lib

/var/media/ftp/lib/hmland -d -p 1234
sleep 2

So stehts in meiner startfhem. (Vorher hatte ich den Eintrag mit ps und grep, aber das scheint genausowenig zu funktionieren.

Wer weis Rat :-?
Raspberry Pi Rev.B, FB7390 (FHEM2FHEM), Sonos, Smarter Coffee
Osram Lightify:2m LED-Streifen, 5m-LED-Streifen, Gartenspot, Surface 28W, Classic E14,E27, Classic RGBW E27, PAR16 GU10, Plug
CUL868:FS20-ST, FS20-DI, FS20-FMS, FS20-ES1
HMUSB:HM-Sec-RHS,HM-Sec-MDIR2
Jeelink868:TX-29-IT, TFA30.315

marc2

Hallo Reinhard,

das

ps | grep hmland | grep -v -q grep

stellt nur sicher, dass der hmland nicht mehrfach gestartet wird. Wenn FHEM
das Device als OPEN bezeichnet, scheint ja erst einmal alles zu funktionieren,
mit Ausnahme des Autostarts (ist ja schon mal etwas). Ändere mal den Aufruf in
Deiner startfhem wie folgt ab:

/var/media/ftp/lib/hmland -d -p 1234 > /var/media/ftp/lib/hmland.log 2>&1

Danach FHEM und den hmalnd stoppen und mit startfhem wieder starten. Der
Inhalt der Datei /var/media/ftp/lib/hmland.log würde mich dann interessieren.
Ich denke, dass der hmland aus Deinem startfhem heraus die libusb-1 nicht
findet obwohl der LD_LIRARY_PATH ja gesetzt wird.

Achja, was für ein FritzOS benutzt Du ? Übersetzt habe ich das ganze auf einem
gefreezten 5.52.

Gruß, Marc
 

marc2

Hi !

Ich hatte den hmland eben mal im Debug Modus laufen (direkt an der 7390).
Da werden Laufzeiten von um die 40ms angezeigt. Der Hub führt also
offensichtlich zu einer recht brutalen Verzügerung von bis zu 90ms. Werde
wohl doch mal einen DLink testen müssen ....

Gruß, Marc