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:
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
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:
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:
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
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?
Tatsächlich!
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?
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?
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
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
Danke Frank, das klingt vielversprechend. Allerdings habe ich kein /etc/default/debmatic, sondern nur:
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?
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.
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
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.
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.
ok, du hast schon gebootet.
fhem, besser hmccu, darf sowieso erst nach debmatic starten, damit die ccu server bereits laufen.
Ja, ich habe gebootet, aber debmatic-info zeigt das oben gepostete.
hmland startet jetzt mit
[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
define d_ccu HMCCU 192.168.1.10 ccudelay=180
Alles friedlich im Moment, mal gespannt, ob das so bleibt.
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
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?
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.
hmusb: Unknown code A2150008E575D37BB1351000014FD175228AFBE63F0BFF239CC84C9E99B2541237EBF::-23:hmusb, help me!das ist doch normal, wenn man keine vccu in cul_hm verwendet.
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...
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:
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?
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.
Zitat von: frank am 14 März 2021, 13:31:26
das bedeutet unassigned. set vccu update sollte spätestens ok bringen.
Leider nicht, das UAS bleibt. auch wenn ich das attr IOdev lösche und wieder anlege und auch wenn ich per assignIO den hmusb zuweise.
Kann das was mit dem "unmus" mit hmland und dem Stick bzw. des Neueinrichten des CULs zu tun haben?
EDIT: set assignIO hmusb unset hat gerade zu meiner Überraschung zu
IODev hmusb
NAME vccu
NOTIFYDEV global
NR 53
STATE IOs_ok
TYPE CUL_HM
assignedIOs
channel_01 vccu_Btn1geführt...
zeig mal ein list der vccu
Internals:
DEF 424242
FUUID 5c7b92e6-f33f-e02c-043c-240e6779ab2dc9f6
IODev hmusb
NAME vccu
NOTIFYDEV global
NR 53
STATE IOs_ok
TYPE CUL_HM
assignedIOs
channel_01 vccu_Btn1
channel_15 vccu_Btn21
channel_16 vccu_Btn22
channel_17 vccu_Btn23
channel_18 vccu_Btn24
channel_19 vccu_Btn25
channel_1A vccu_Btn26
channel_1B vccu_Btn27
channel_1C vccu_Btn28
channel_1D vccu_Btn29
channel_1E vccu_Btn30
channel_1F vccu_Btn31
channel_20 vccu_Btn32
channel_21 vccu_Btn33
channel_22 vccu_Btn34
channel_23 vccu_Btn35
channel_24 vccu_Btn36
channel_25 vccu_Btn37
channel_26 vccu_Btn38
channel_27 vccu_Btn39
channel_28 vccu_Btn40
READINGS:
2021-03-14 20:09:00 IOopen 0
2021-03-14 20:09:00 state IOs_ok
helper:
HM_CMDNR 74
mId FFF0
peerFriend peerSens,peerAct
peerOpt -:virtual
regLst
rxType 1
ack:
cmds:
TmplKey :no:1615747286.97875
TmplTs 1615747286.97875
cmdKey 0:1:1::vccu:FFF0:00:
cmdLst:
assignIO -IO- [({set}|unset)]
clear [(readings|rssi|msgErrors|{msgErrors}|unknownDev)]
defIgnUnknown noArg
hmPairForSec [-sec-]
hmPairSerial -serial-
peerSmart -peerOpt-
tplSet_0 -tplChan-
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt CUL_HM_HM_RC_19_107841_Disp,HM_1269DD_Btn_13,HM_1269DD_Btn_14,HM_1269DD_Btn_15,HM_1269DD_Btn_16,HM_1269DD_Btn_17,HM_1269DD_Btn_18,HM_1269DD_Btn_19,HM_1269DD_Btn_20,HM_303933_Btn_03,HM_303933_Btn_04,HM_303933_Btn_05,HM_303933_Btn_06,HM_353DC1_Sw_03,HM_353DC1_Sw_04,HM_353DC1_Sw_05,HM_353DC1_Sw_06,HM_353DC1_Sw_07,HM_353DC1_Sw_08,HM_3872D5_light,HM_3872D5_lock,HM_3872D5_open,HM_3872D5_unlock,HM_3FFEE0,HM_3FFEFE,HM_4B118E_Sw,HM_4B118E_Sw1_V_01,HM_4B118E_Sw1_V_02,HM_573D20_Sw_01,HM_573D20_Sw_03,HM_573D20_Sw_04,HM_652E9A_Btn_01,HM_652E9A_Btn_02,HM_652E9A_Btn_03,HM_652E9A_Btn_04,HM_652E9A_Btn_06,HM_653129_Btn_05,HM_653129_Btn_06,HM_6AEE6F_WindowRec,HM_6AEE6F_remote,HM_6DAE6B_Btn_01,HM_6DAE6B_Btn_02,HM_6DAE6B_Btn_03,HM_6DAE6B_Btn_04,HM_6DAE6B_Btn_05,HM_6DAE6B_Btn_06,HM_Switch01_Btn_01_Dim_01,HM_Switch01_Btn_02_Dim_01,HM_Switch01_Btn_03_Dim_02,HM_Switch01_Btn_04_Dim_02,HM_Switch01_Btn_05_Dim_03,HM_Switch01_Btn_06_Dim_03,HM_Switch01_Btn_07_Dim_04,HM_Switch01_Btn_08_Dim_04,HM_Switch01_Btn_09_Dim_05,HM_Switch01_Btn_10_Dim_05,HM_Switch01_Btn_11_Dim_06,HM_Switch01_Btn_12_Dim_06,HM_Switch02_Btn_03_Dim_08,HM_Switch02_Btn_04_Dim_08,HM_Switch03_Btn_01_Dim_09,HM_Switch03_Btn_02_Dim_09,HT_AZ_WindowRec,HT_AZ_remote,HT_BAD_FEN_WindowRec,HT_BAD_FEN_remote,HT_Bad_Handtuch_WindowRec,HT_Bad_Handtuch_remote,HT_Hall_WindowRec,HT_Hall_remote,HT_KUE_LI_WindowRec,HT_KUE_LI_remote,HT_KUE_RE_WindowRec,HT_KUE_RE_remote,HT_WC_WindowRec,HT_WC_remote,HT_WZ_LI_WindowRec,HT_WZ_LI_remote,HT_WZ_RE_WindowRec,HT_WZ_RE_remote,Klima,LI.FLU.STRAHLER,RC19_B0,RC19_B1,RC19_B11,RC19_B12,RC19_B13,RC19_B14,RC19_B17,RC19_B2,RC19_B3,RC19_B4,RC19_B5,RC19_B6,RC19_B7,RC19_B8,RC19_B9,Regensensor_Regen,Rolladen_WZ_Tuer,Rolladen_WZ_links,Rolladen_WZ_rechts,Rolllaeden_Bad_l,Rolllaeden_Bad_r,Rolllaeden_Kueche_l,Rolllaeden_Kueche_r,Sw_Vel_AZ_off,Sw_Vel_AZ_on,THERMOSTAT_Bad_WindowRec,THERMOSTAT_Bad_remote,THERMOSTAT_Kueche_WindowRec,THERMOSTAT_Kueche_remote,THERMOSTAT_WZ_WindowRec,THERMOSTAT_WZ_remote,Temp_HM_Switch_Btn_11,Vel_HA_Btn_01,Vel_HA_Btn_02,Vel_SP_Btn_05,Vel_SP_Btn_06,Vel_SP_RC19_B15,Vel_SP_RC19_B16,Vel_WC_Btn_03,Vel_WC_Btn_04,Winmatic_SZ,blutooth1,k1_schaltaktor_sirene,k2_schaltaktor_led_blink,keyremote_1_1,keyremote_1_2,keyremote_1_3,keyremote_1_4,motion_portal_Btn_01,motion_portal_Btn_02,motion_portal_Motion,reedcontrol_Sw_01,reedcontrol_Sw_02,reedcontrol_Sw_03,roll1,roll2,schaltaktor_portal_3,schaltaktor_portal_4
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
list [({normal}|full)]
listDevice noArg
param -param-
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu
ioList:
mRssi:
mNo
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
IODev hmusb
expert defReg,rawReg
hmKey 01:7a89cc18e82474af4f2720a0fe18527a
model CCU-FHEM
room CUL_HM,Settings
subType virtual
webCmd virtual:update
deiner vccu ist kein io zugeordnet.
=> attr vccu IOList hmusb
ausserdem fehlt
=> attr IOgrp vccu
jedes hauptdevice benötigt die zwei attribute IODev und IOgrp. auch virtuelle.
Zitat von: frank am 14 März 2021, 22:32:21
deiner vccu ist kein io zugeordnet.
Danke, das wäre mir jetzt nicht aufgefallen, da bei den Internals und Attribute ja der Anschein erweckt wird, hmusb seit der vccu als IO korrekt zugeordnet.
Zitat
ausserdem fehlt
=> attr IOgrp vccu
Wieso das bei der vccu nicht mehr da war ist mir schleierhaft. Bei sämtlichen Devices ist es noch vorhanden (seinerzeit nachträglich angelegt).
[/quote]
Jetzt bin ich mal gespannt, ob die Telegrammflut aufhört...
Das sieht gut aus, auch die Readings der vccu befüllen sich. Vielen Dank Frank für Hilfe und Geduld. An debmatic werde ich mich dann diese Woche nochmal versuchen.