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

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

Vorheriges Thema - Nächstes Thema

Django.Edwards

Zitat von: JanS am 24 März 2014, 19:17:22
Mal ne andere Frage:
Hat denn mal wer beobachtet, ob das "Aufhängen" des Adapters im Sendebetrieb mit der neuen Firmware (0.967) von eQ3 noch auftritt?
Releasenotes sind irgendwie keine zu finden, leider.

EDIT:typo korrigiert

Also bei mir läuft der Adapter seit mehreren Tagen durch, ohne sich aufzuhängen. Beobachte das aber weiter.
Wenn nicht, kann man ja immer noch die Reboot-Option wieder einschalten.

Wirklich klasse Arbeit die hier geleistet wird!

der-Lolo

Hallo zusammen,
ich habe etwas komisches bemerkt -
erstmal schaut alles ganz normal aus, da ich den HM-USB nachts um 3 neustarte.
Zitat2014.03.31 03:00:08 1: 127.0.0.1:1234 disconnected, waiting to reappear
2014.03.31 03:00:08 1: HMLAN_Parse: hmusb new condition disconnected
2014.03.31 03:00:08 1: 127.0.0.1:1234 reappeared (hmusb)
2014.03.31 03:00:08 1: HMLAN_Parse: hmusb new condition init
2014.03.31 03:00:09 1: 127.0.0.1:1234 disconnected, waiting to reappear
2014.03.31 03:00:09 1: HMLAN_Parse: hmusb new condition disconnected
2014.03.31 03:00:09 1: 127.0.0.1:1234 reappeared (hmusb)
2014.03.31 03:00:09 1: HMLAN_Parse: hmusb new condition init
Es dauerte allerdings ein wenig länger als normal, und anschliessend war der Bluetooth Dongle nicht mehr erreichbar..
Zitat
2014.03.31 03:01:16 1: 127.0.0.1:1234 reappeared (hmusb)
2014.03.31 03:01:16 1: HMLAN_Parse: hmusb new condition init
2014.03.31 03:01:18 1: HMLAN_Parse: hmusb new condition ok
2014.03.31 03:04:21 1: Perfmon: possible freeze starting at 03:04:20, delay is 1.278
2014.03.31 03:04:59 3: Watchdog wd_s4mini_away triggered
2014.03.31 03:04:59 2: ROOMMATE set rr_Christin absent
2014.03.31 03:05:05 1: Christin ist gegangen...
2014.03.31 03:05:05 1: Perfmon: possible freeze starting at 03:05:00, delay is 5.498
2014.03.31 03:06:28 3: Watchdog wd_z1compact_away triggered
2014.03.31 03:06:28 2: ROOMMATE set rr_Micha absent
2014.03.31 03:06:38 1: Micha ist gegangen...
Über die Anwesenheit schalten wir unsere Heizung - gut, so schlimm ist es ja nicht mehr wenn die Heizung aus ist - aber trotzdem würde ich dieses problemchen gerne beheben.

Hat jemand eine Idee wie ich nach dem HM-USB restart schauen kann ob der Bluetooth Adapter noch läuft?

bzw. ist der erstarrt mit der neuen Firmware wirklich nicht mehr notwendig?

Einzig ein neustarten des Beagle konnte Bluetooth wieder zum leben erwecken...
Vor kurzem hatte ich ein ähnliches verhalten - konnte aber den Hergang nicht so wie diesmal nachvollziehen.
Es passiert also nicht jede nacht - aber gelegentlich.

Joachim

Schau mal bei udev,
könnte sein dass sich die Adresse der USB-Geräte ändert.

Gruß Joachim
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

der-Lolo

Ok - udev...
Ich glaube ich verstehe wie das gemeint ist, ich gebe also den Devices am USB Bus einfach einen symlink und in fhem erfolgt dann die definition der devices über den symlink?

unter etc/udev/rules.d/ habe ich eine 50-fhem.rules angelegt und dort

KERNEL=="ttyUSB*", ATTRS{product}=="Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)", SYMLINK+="bluetooth"
KERNEL=="ttyUSB*", ATTRS{product}=="Linux Foundation Multifunction Composite Gadget", SYMLINK+="hm_usb"

eingetragen. Das habe ich aus dem fhemwiki eben mit den ausgaben von meinen lsusb angepasst...

In meiner Config habe ich ein
define hmusb HMLAN 127.0.0.1:1234
dort sollte dann vermutlich etwas stehen wie
define hmusb HMLAN /dev/hm_usb
den Port? muss ich den auch mitgeben?
und für Bluetooth? Muss ich da auch was eintragen?

Im FHEMWIKI - gibt es auch noch eine Zeile
KERNEL=="tty*", SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="204b", MODE="0666", BUS=="usb", SYMLINK+="CUL"
und unten drunter die Erklärung das die rechte auch gesetzt würden...

sorry - aber es geht ums Produktivsystem, möchte nichts falsch machen und ungern experimentieren.

nochmal kurz die Fragen in meinem Kopf


  • brauch die 50-fhem.rules noch irgendwelche besonderen rechte?
  • Wann wird ausgeführt? Beim nächstem reboot?
  • muss ich bei der /dev/hm_usb definition noch einen port mitgeben?
  • eine definition für bluetooth habe ich glaube ich gar nicht, übernimmt das presence für mich?
  • ist es überhaupt der richtige weg das problem zu lösen? (weil ja bei einem reboot keine Vertauschung stattfindet)

Joachim

Erst mal kontrollieren, ob es sich wirklich um sich ändernde Ports handelt, dann weitersehen.
War ersteinmal nur ein Ansatzpunkt.
Also dmesg | grep tty und nachsehen, wer welchem Port zugeteilt ist, dann bei Deinem oben beschriebenen Problem nachsehen, ob sich der Port geändert hat.
Nicht immer blind versuchen, Fehler zu beseitigen, deren Ursche man nicht kennt.

Gruß Joachim
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

betateilchen

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

Joachim

#336
?
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

betateilchen

Der Homematic USB Stick wird in fhem IMMER über die IP und den Port definiert, den der hmland auf Betriebssystemebene verwendet. Das ist das einzige relevante Kriterium und nicht irgendwelche device-Namen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Joachim

FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

der-Lolo

das dmesg | grep tty hab ich trotzdem mal abgesetzt.


Zitatroot@BeagleBoneBlack:~# dmesg | grep tty
[    0.000000] Kernel command line: console=ttyO0,115200n8 root=UUID=c51c5460-839c-4fb9-a32e-f8198498754c ro rootfstype=ext4 rootwait fixrtc ip=
[    0.525106] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0
[    1.270887] console [ttyO0] enabled
[   27.420915] cdc_acm 1-1.4.1:1.2: ttyACM0: USB ACM device
root@BeagleBoneBlack:~#

Da versteh ich aber wie so oft nur Bahnhof...

docloy

Hab heute den Raspberry Pi UK aufgesetzt, FHEM installiert und hmland kompiliert. Fhem startet automatisch (bin dem Tutorial gefolgt: http://www.meintechblog.de/2013/05/fhem-server-auf-dem-raspberry-pi-in-einer-stunde-einrichten/ ).
Nur den hmland muss ich noch händisch starten.
Wie kann ich das am besten automatisieren?

der-Lolo


docloy

Den Anhang hatte ich vorhin übersehen. Habe es runtergeladen und auf den rpi geschoben und ausführbar gemacht. Konnte es auch starten, aber es tut sich im Webinterface keine Änderung der Stick bleibt disconnected.
Starte ich hmland manuell geht es. Pfade sind gleich: /opt/hmcfgusb/hmland

Hat jemand noch ne Idee? Steh' da grad total auf dem Schlauch und komm nicht weiter....

Naja jetzt geh ich erst mal pennen ;)

der-Lolo

hast du auch noch ein Stückchen weiter gelesen und ein update rc.d gemacht?

betateilchen

der hmland braucht kein eigenes Startskript, binde ihn einfach in das Startskript von fhem mit ein, das ist viel einfacher.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!