HM-CFG-USB: Umzug von Pi3/Stretch auf Pi4/Duster - Probleme

dadoc · 12 März 2021, 13:41:37

Hallo zusammen,
ich versuche gerade, das System vom Pi 3 auf einen Pi 4 (Duster) umzuziehen - dort dann auch inkl. debmatic und HMCCU.
Hat auch alles leidlich geklappt, aber ich bekomme den HM-CFG-USB nicht zum Laufen (der bislang auf dem Pi 3 / Stretch problemlos lief).
Kompilieren und Start, alles als root, funktioniert ohne Mucken, aber dann kommt:

Code Auswählen

 Client 127.0.0.1 connected!
Can't claim interface: Resource busy
Can't find/open HM-CFG-USB!
Can't initialize HM-CFG-USB!
2021-03-12 13:37:59.689819: Connection to 127.0.0.1 closed!
2021-03-12 13:38:00.690025: Client 127.0.0.1 connected!
[...]

als Schleife, bis es dann aufgibt.
Und natürlich auch bei ./hmland -i

Code Auswählen

Can't claim interface: Resource busy
Can't find/open HM-CFG-USB!
Can't initialize HM-CFG-USB!
root@raspberrypi:~/hmcfgusb#

lsusb zeigt den Stick korrekt an:

Code Auswählen

Bus 001 Device 003: ID 1b1f:c00f eQ-3 Entwicklung GmbH HM-CFG-USB/HM-CFG-USB-2 [HomeMatic Configuration adapter]

In fhem habe ich das Device neu angelegt:

Code Auswählen

define hmusb HMLAN 127.0.0.1:1234
setuuid hmusb 604b59d1-f33f-9bf2-c3a5-aa5818c27c0b6080
attr hmusb hmId 424242
attr hmusb hmLanQlen 1_min
attr hmusb loadLevel 0:low,40:batchLevel,90:high,99:suspended

Leider komme ich nun mit meinen Linux-Kenntnissen an die Grenze, um den Fehler zu finden.
Könnt Ihr mir helfen?
Danke & viele Grüße
Martin

frank · 12 März 2021, 15:07:17

Zitatdort dann auch inkl. debmatic und HMCCU.

meine debmatic "krallt" sich den hmusb, der dann in cul_hm nicht mehr greifbar ist.

was zeigt denn "debmatic-info" auf der konsole?

dadoc · 12 März 2021, 15:32:56

Tatsächlich!

Code Auswählen

debmatic version: 3.55.10-66
Kernel modules: Available
Raw UART dev:   Available
HMRF Hardware:  HM-CFG-USB-2
 Connected via: GPIO (/dev/raw-uart)
 Board serial:  JEQ0700605
 Radio MAC:     0x71C5A5
HMIP Hardware:  HM-MOD-RPI-PCB
 SGTIN:         3014F711A061A7DBE9975F90
 Radio MAC:     0xBB1351

Deswegen geht vermutlich auch HMUARTLGW, mit dem ich in meiner Verzweiflung versucht habe, den Stick "abzulösen".
Und jetzt?

dadoc · 12 März 2021, 15:47:53

Sobald ich debmatic stoppe (systemctl stop debmatic.service), klappt das wieder wie gewohnt.
Irgendeine Chance, die in friedlicher Koexistenz auf einem Raspi laufen zu haben?

frank · 12 März 2021, 16:05:52

probiere mal das:

Zitat von: deimos am 12 Mai 2020, 20:41:19
Hi,

ich habe das mit dem HM-CFG-USB-2 grade umgesetzt und eine entsprechende Version im testing APT Repository eingespielt. Wenn man in der Datei /etc/default/debmatic die Zeile
Code Auswählen Erweitern
AVOID_HM_CFG_USB_2=1 einfügt, dann wird das HM-CFG-USB-2 nicht mehr in debmatic erkannt/genutzt.

Viele Grüße
Alex

dadoc · 12 März 2021, 18:22:14

Danke Frank, das klingt vielversprechend. Allerdings habe ich kein /etc/default/debmatic, sondern nur:

Code Auswählen

root@raspberrypi:~# find / -iname "debmatic"
/etc/network/if-down.d/debmatic
/etc/network/if-up.d/debmatic
/etc/debmatic
/usr/lib/networkd-dispatcher/routable.d/debmatic
/usr/lib/networkd-dispatcher/off.d/debmatic
/usr/lib/debmatic
/usr/share/debmatic

Wo sollte das rein? Oder /etc/default/debmatic erstellen und das als einzigen Eintrag?

frank · 12 März 2021, 18:40:37

da ich es selbst noch nicht probiert habe, habe ich vorhin mal die datei gesucht.

auf meinem pi3/buster mit debmatic fw 3.53 ist sie vorhanden. es stehen nur 2 zeilen drin mit id und seriennummer (DEB....) analog wie bei anderen homematic devices.

dadoc · 12 März 2021, 21:13:35

Registriere eben erst, dass man dafür wohl die Version im testing APT Repository nehmen müsste? Allerdings läuft bei mir aktuell 3.55.10-66, da sollte es dann wohl schon umgesetzt sein?
Ich habe jetzt mal eine Textdatei in /etc/default erstellt und AVOID_HM_CFG_USB_2=1 eingefügt; allerdings erstmal ohne Effekt. Erst wenn ich debmatic stoppte (systemctl stop debmatic.service), konnte hmland wieder arbeiten.
ABER: Dann habe ich den Autostart von hmland mit systemd eingerichtet (vorher immer nur manuell mit ./hmland -p 1234 -D), reboot, und nun scheint es zu gehen. D.h. fhem/HM und debmatic laufen parallel. Vielleicht liegt es ja an der Reihenfolge beim Booten?
debmatic-info zeigt allerdings immer noch

Code Auswählen


debmatic version: 3.55.10-66
Kernel modules: Available
Raw UART dev:   Available
HMRF Hardware:  HM-CFG-USB-2
 Connected via: GPIO (/dev/raw-uart)
 Board serial:  JEQ0700605
 Radio MAC:     0x71C5A5
HMIP Hardware:  HM-MOD-RPI-PCB
 SGTIN:         3014F711A061A7DBE9975F90
 Radio MAC:     0xBB1351

Das verstehe ich aber eh nicht so richtig. Der USB Stick soll "Connected via: GPIO (/dev/raw-uart)" sein?
Naja, jetzt beobachte ich das erstmal, ob es stabil bleibt.
Vielen Dank, Frank, da wäre ich wohl im Leben nicht von selbst draufgekommen.

frank · 12 März 2021, 22:00:41

die ankündigung von alex mit dem testing release ist ja schon ewig her. aber möglich dass das feature immer noch dort schlummert, da vielleicht keine rückmeldungen kamen.

probiere mal ein reboot vom pi und schaue danach nochmal nach debmatic-info.

frank · 12 März 2021, 22:12:00

ok, du hast schon gebootet.

fhem, besser hmccu, darf sowieso erst nach debmatic starten, damit die ccu server bereits laufen.

dadoc · 12 März 2021, 22:25:18

Ja, ich habe gebootet, aber debmatic-info zeigt das oben gepostete.
hmland startet jetzt mit

Code Auswählen

[Unit]
Description=Homematic LAN Adapter service
After=network.target

[Service]
ExecStart=/root/hmcfgusb/hmland -p 1234

[Install]
WantedBy=multi-user.target

HMCCU starte ich mit 3 Minuten Verzögerung über

Code Auswählen

define d_ccu HMCCU 192.168.1.10 ccudelay=180
Alles friedlich im Moment, mal gespannt, ob das so bleibt.

dadoc · 13 März 2021, 12:06:39

Leider eine ziemlich wackelige Angelegenheit. Nach einem Reboot soeben war der HM-USB-CFG erneut nicht mehr verfügbar in fhem, erst nach Stoppen von debmatic wieder. Zuvor schon hatte zwar sowohl fhem als auch debmatic funktioniert, aber das HM-IP-Device (habe derzeit nur eines in debmatic angelernt) war in fhem nicht mehr ansprechbar bzw. übertrug nicht die aktuellen Werte (Temperatur und Feuchtigkeit). RCP Status inaktiv; die devicelist ließ sich allerdings abrufen.

Zudem habe ich das fhem-Log voll mit Meldungen wie

Code Auswählen

hmusb: Unknown code A2150008E575D37BB1351000014FD175228AFBE63F0BFF239CC84C9E99B2541237EBF::-23:hmusb, help me!

Möglicherweise ist es (noch) keine gute Idee, alles auf einem Raspi laufen zu lassen,wenn man die CULs nicht sauber auseinanderedividiert bekommt?

frank · 14 März 2021, 11:59:43

ZitatLeider eine ziemlich wackelige Angelegenheit. Nach einem Reboot soeben war der HM-USB-CFG erneut nicht mehr verfügbar in fhem, erst nach Stoppen von debmatic wieder.

hört sich für mich danach an, dass es noch nicht im stable release integriert ist, oder noch nicht richtig funktioniert.
schildere doch dein problem mal alexreinert. entweder im git oder im homematic-forum im bereich debmatic.

Code Auswählen

hmusb: Unknown code A2150008E575D37BB1351000014FD175228AFBE63F0BFF239CC84C9E99B2541237EBF::-23:hmusb, help me!
das ist doch normal, wenn man keine vccu in cul_hm verwendet.

dadoc · 14 März 2021, 12:58:02

Zitat von: frank am 14 März 2021, 11:59:43
schildere doch dein problem mal alexreinert. entweder im git oder im homematic-forum im bereich debmatic.

Das werde ich tun. Da mir fhem gestern aus blauem Himmel kein erreichbares Web-UI mehr bot (Server nicht erreichbar, restart und reboot halfen nicht), aber de facto (ausweislich logs & status) ohne Fehlermeldungen lief, wenn auch ohne Funktionalität beim Cul-HM, habe ich jetzt erstmal debmatic deinstalliert und das GPIO-Funkmodul abgezogen. Muss ja auch auf den WAF achten...

Code Auswählen

hmusb: Unknown code A2150008E575D37BB1351000014FD175228AFBE63F0BFF239CC84C9E99B2541237EBF::-23:hmusb, help me!
das ist doch normal, wenn man keine vccu in cul_hm verwendet.
[/quote]
Ich verwende vccu seit Langem:

Code Auswählen

FVERSION   10_CUL_HM.pm:0.238560/2021-02-28
   IODev      hmusb
   NAME       vccu
   NOTIFYDEV  global
   NR         53
   NTFY_ORDER 50-vccu
   STATE      hmusb:UAS,
   TYPE       CUL_HM
   assignedIOs hmusb

Das sind Funktelegramme vom HmIP-STHO (Temperatur/Feuchtigkeit), die beim Cul ankommen, unabhängig davon, ob das Device an einer CCU angelernt ist (ich habe es derzeit an Raspberrymatic auf einem Pi3) oder nicht. Da kein Device angelegt wird und auch in den vccu-Readings nichts zu sehen ist, kann ich es auch nicht ignorieren. Oder mache ich da etwas falsch?

frank · 14 März 2021, 13:31:26

Code Auswählen

STATE hmusb:UAS,
das bedeutet unassigned. set vccu update sollte spätestens ok bringen.

die vccu weiss natürlich nicht, dass es hmip nachrichten sind und versucht nach bidcos manier daraus den sender zu ermitteln. wer weiss schon ob das bei hmip zutrifft.
die liste der unknown-readings sollte sich erhöhen. eventuell sind irgendwann alle meldungen weg.