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

[danielsen]

Die gute Nachricht ... es läuft! Allerdings eher schlecht als recht.

Setup:
RaspberryPie B mit HM USB und FHEM 5.5 s
1 X HM-CC-RT-DN Funk-Heizkörperthermostat

Problem:
Ab und zu kommen Schlatvorgänge nicht an
Wenn er schaltet, dann dauert Schaltvorgang set desired-temp recht lange

Logs:

Terminal:
Daemon with PID 2384 started!

Code Auswählen Erweitern

usb-transfer took more than 100ms (609ms), this may lead to timing problems!
usb-transfer took more than 100ms (573ms), this may lead to timing problems!

Logs-FHEM:

Code Auswählen Erweitern

2013.12.27 16:48:23 1: 127.0.0.1:1234 reappeared (hmusb)
2013.12.27 16:48:23 2: HMLAN_Parse: hmusb new condition init
2013.12.27 16:49:39 2: CUL_HM set BZ.Heizung_Climate_tr desired-temp 22.0
2013.12.27 16:49:41 2: HMLAN_Parse: hmusb new condition ok
2013.12.27 16:54:06 2: CUL_HM set BZ.Heizung_Climate_tr desired-temp 21.5
2013.12.27 17:15:56 2: CUL_HM set BZ.Heizung_Climate_tr desired-temp 16.0
2013.12.27 17:16:04 2: HMLAN_Parse: hmusb new condition Warning-HighLoad
2013.12.27 17:16:20 2: HMLAN_Parse: hmusb new condition ERROR-Overload
2013.12.27 17:22:20 2: HMLAN_Parse: hmusb new condition Overload-released

Hat jemand Erfahrungen oder Ideen wie ich die Warnings etc. los werde? Bei einem Thermostat dürfte doch kein Overload stattfinden ....
Die hohe Transfertime scheint ja vom RPie zu kommen. Was wirklich schade wäre!

Freue mich über Tipps, Grüße

[volschin]

600ms ist katastrophal. Hast du den Stick an einem Hub oder direkt am RasPi?
Wenn direkt Wechsel mal auf den anderen USB-Port und prüfe, ob sich die Zeiten verbessern.

[danielsen]

Der USB Stick hängt direkt am RPie. Ich werde nachher mal den zweiten USB Port ausprobieren. Schreibt der hmcfgusb eigentlich auch eine Log? Dann muss nicht immer der Terminal mit laufen lassen.

Was genau sagen denn diese Logs vom FHEM-Server aus?
2013.12.27 17:16:04 2: HMLAN_Parse: hmusb new condition Warning-HighLoad
2013.12.27 17:16:20 2: HMLAN_Parse: hmusb new condition ERROR-Overload
2013.12.27 17:22:20 2: HMLAN_Parse: hmusb new condition Overload-released

Danke und grüße

[marc2]

Hi !

Der hmland schreibt seine Meldungen nach STDOUT and STDERR. Du musst die Ausgabe beim Starten
also in ein Logfile Deiner Wahl umleiten, Beispiel:

Code Auswählen Erweitern

hmland -l 127.0.0.1 -p 1000 -d > /var/media/ftp/hmland.log 2>&1

Gruß, Marc

[jab]

Die Timingmeldungen habe ich manchmal auch auf meinem RPi. Generell habe ich aber keine Probleme dadurch. Das passiert wenn FHEM hohe Load erzeugt. Z.b. beim starten. Ich würde sagen ich habe das so drei Mal am Tag ca.

Gruß,
Jan

[HerrDesChaos234]

Hi,

Ich habe die Beiträge bezüglich der USB Probleme beim RaspberryPi bei Verwendung des Homematic CFG USB Sticks gelesen.
Ich selber hatte vor das RaspberryPi (leider China Version) mit FHEM + HM CFG USB + HM-CC-RT-DN zu verwenden.

In Anbetracht der Probleme stellt sich mir jetzt folgende Frage:

a) UK RaspberryPi statt China Pi
b) Beagle Bone Black statt Raspberry Pi
c) HMLan Adapter statt HM CFG USB

Preislich alles ähnlich und noch kann ich den HM CFG USB zurück schicken.

Was wäre euer Ratschlag?
Ich bin ganz froh das es für das Pi mit Wheezy generell sehr viele Infos/Anleitungen im Netz gibt. Das ist beim BBB wohl etwas schlechter, denke aber das ich mit dem BBB und Ubuntu auch zurecht kommen würde. Das Angstrom Linux ist mir nicht geheuer. Was verwendet ihr denn auf dem BBB und bekommt man da FHEM genau so Problemlos zum laufen wie auf dem Pi?

Schönen Gruß,
HDC

[jab]

Also mein RaspberryPi läuft klasse mit Stick und FHEM. Steht auch Made in China drauf. Timing Probleme gibts bei mir wirklich nur bei hoher load. Vielleicht sollte ich hmland einfach mit einer höheren Priorität laufen lassen. Teste Ich die tage mal.


Gruß
Jan

[betateilchen]

Was verwendet ihr denn auf dem BBB

Ein blankes Debian Linux.

und bekommt man da FHEM genau so Problemlos zum laufen wie auf dem Pi?

Ja.

Und mach Dir keine Sorgen wegen "beim BBB gibts weniger Infos ..." - das kann einfach daran liegen, dass der BBB sehr viel weniger Probleme macht als der Raspberry (jedenfalls meine Erfahrung: BBB einmal in Betrieb nehmen und dann vergessen. Beim Raspberry musste ich irgendwie immer "nacharbeiten" um den stabil in Betrieb zu halten)

[jab]

So ich hab mal hmland mit höherer Priorität getestet auf dem Raspberry Pi. Damit klappt es hervorragend. Keinerlei Timeouts mehr. Ich starte es dann so:

chrt 30 /opt/hmcfgusb/hmland -d -P -l 127.0.0.1 -p $port 2>&1 > /var/log/hmland.log

Mein Initscript hänge ich mal an falls es noch jemand nutzen will.


Gruß,
Jan

[volschin]

Meine Empfehlung: Pack Dir trotzdem den Reset-Parameter in den Aufruf rein, der hilft deutlich beim langfristigen Betrieb.

Gruß
Veit

[jab]

Laut --help ist der Default auf alle 24h resetten. Das deckt sich auch mit dem Log von FHEM. Öfter als alle 24h sollte doch auch nicht helfen oder?

Gruß,
Jan

[marc2]

Nein, die Erfahrung hat gezeigt, dass der Stick rund zwei Tage durchhält, bevor die Firmware austickt.
Ein Reset alle 24h reicht also auf jeden Fall.

Gruß, Marc

[volschin]

Upps, war mir gar nicht klar, dass das jetzt der Default ist. Ich habe mir den Reset auf nachts um 3 Uhr gestellt. Da wird typischerweise nichts geschalten und die Auszeit beträgt bei mir rund 20 Sekunden.

Gruß
Veit

[danielsen]

hi,

ich hatte erst Hoffnung als ich die Idee mit dem chrt gesehen hatte:

So ich hab mal hmland mit höherer Priorität getestet auf dem Raspberry Pi. Damit klappt es hervorragend. Keinerlei Timeouts mehr. Ich starte es dann so:

chrt 30 /opt/hmcfgusb/hmland -d -P -l 127.0.0.1 -p $port 2>&1 > /var/log/hmland.log

Mein Initscript hänge ich mal an falls es noch jemand nutzen will.


Gruß,
Jan

und habe das ganze gleich ausprobiert. Leider erfolglos - anbei der Log von der gestrigen Nacht:

Code Auswählen Erweitern

Daemon with PID 2503 started!
usb-transfer took more than 100ms (991ms), this may lead to timing problems!
Can't send null frame: Input/output error
usb-transfer took more than 100ms (109ms), this may lead to timing problems!
usb-transfer took more than 100ms (569ms), this may lead to timing problems!
usb-transfer took more than 100ms (260ms), this may lead to timing problems!
usb-transfer took more than 100ms (271ms), this may lead to timing problems!
usb-transfer took more than 100ms (307ms), this may lead to timing problems!
usb-transfer took more than 100ms (532ms), this may lead to timing problems!
usb-transfer took more than 100ms (263ms), this may lead to timing problems!
usb-transfer took more than 100ms (194ms), this may lead to timing problems!
usb-transfer took more than 100ms (186ms), this may lead to timing problems!
usb-transfer took more than 100ms (274ms), this may lead to timing problems!
usb-transfer took more than 100ms (307ms), this may lead to timing problems!
usb-transfer took more than 100ms (533ms), this may lead to timing problems!
Can't send null frame: Input/output error
usb-transfer took more than 100ms (271ms), this may lead to timing problems!
usb-transfer took more than 100ms (149ms), this may lead to timing problems!
usb-transfer took more than 100ms (262ms), this may lead to timing problems!
usb-transfer took more than 100ms (157ms), this may lead to timing problems!
usb-transfer took more than 100ms (757ms), this may lead to timing problems!
usb-transfer took more than 100ms (272ms), this may lead to timing problems!
usb-transfer took more than 100ms (280ms), this may lead to timing problems!
usb-transfer took more than 100ms (279ms), this may lead to timing problems!
usb-transfer took more than 100ms (561ms), this may lead to timing problems!
usb-transfer took more than 100ms (269ms), this may lead to timing problems!
usb-transfer took more than 100ms (15307ms), this may lead to timing problems!
usb-transfer took more than 100ms (113ms), this may lead to timing problems!
usb-transfer took more than 100ms (227ms), this may lead to timing problems!
usb-transfer took more than 100ms (916ms), this may lead to timing problems!

Das ganze ist identisch am anderen USB-Port des RPie. Langsam bin ich am verzweifeln. Hat noch jemand eine Idee? Kann man an der fhem.cfg noch was tunen?

Viele Grüße
Daniel

[juppzupp]

Wie sieht die load auf dem rpi aus?
Was hängt noch am USB?
Hast du viel last (gewollt / ungewollt) auf dem Ethernet (hängt auch am USB)?
Welche Parameter bekommt der kernel beim boot, was steht in der cmdline.txt?
Andere Auffälligkeiten im log des rpi? (Kern.log etc)