Hallo,
nachdem mir hier im Forum das HM-MOD-RPI-PCB doch sehr an das Herz gelegt wurde um meine Homematic Probleme zu lösen habe ich dieses Modul nun endlich mal zusammen gebaut(war ja nicht viel) und auf meinen Raspi installiert.
Hierzu habe ich die Anleitungen
- https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
- https://wiki.fhem.de/wiki/HMUARTLGW
befolgt und es hat auch alles soweit geklappt.
Dann habe ich die Schnittstelle in fhem angelegt
Internals:
CNT 0
Clients :CUL_HM:
DEF /dev/ttyAMA0
DevState 0
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 15
FUUID 6010283a-f33f-f700-ceb2-53f8681a1ff4a32a
LastOpen 1611674674.46065
NAME myHmUART
NOTIFYDEV global
NR 854
NTFY_ORDER 50-myHmUART
PARTIAL
RAWMSG 0400
STATE opened
TYPE HMUARTLGW
XmitOpen 0
model HM-MOD-UART
Helper:
Log:
Resolve 1
IDs:
MatchList:
1:CUL_HM ^A......................
READINGS:
2021-01-26 15:59:45 D-HMIdAssigned F11034
2021-01-26 15:59:45 D-HMIdOriginal 71C670
2021-01-26 15:59:45 D-firmware 1.2.1 (outdated)
2021-01-26 15:59:45 D-serialNr REQ0915144
2021-01-26 16:14:34 D-type HM-MOD-UART
2021-01-26 16:24:34 cond disconnected
2021-01-26 16:02:26 load 0
2021-01-26 16:14:34 loadLvl suspended
2021-01-26 16:24:34 state opened
Attributes:
hmId F11034
room CUL
Da die Firmware outdated war habe ich mir die neue Firmware von Q3 geladen und hier den update der Firmware in fhem angestossen.
Hier kam aber immer die Meldung, dass das Device disconnected ist. Diese Meldung kam 3 mal dann war das Device wieder connected. Dann fing das Spiel von vorne an.
Dann habe ich fhem und den Raspi auf den neusten Softwarestand gebracht und den Update erneut versucht.
Im Device(Schnittstelle) steht das Reading cond auf init dann wieder auf disconnected.
Lötstellen und Kontaktierungen sind alle überprüft und OK.
Wie kann ich diese Schnittstelle updaten und zum laufen bekommen oder hat die einen Schuss ?
Hier weiß ich nun leider nicht weiter.
Danke und viele Grüße
Sven
hast du versucht die Firmware auch ohne FHEM zu aktualisieren, so wie in der oben verlinkte Anleitung ?
Das hier hast du auch durchgeführt?
https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule
Gruß, Joachim
Hallo,
Verwendung UART für Zusatzmodule - dies habe ich durchgeführt und die Ausgaben kommen da wie angegeben.
Die Firmware habe ich nur versucht über fhem zu aktualisieren, hier muss ich was überlesen haben.
Welchen Link meinst du ?
Bin hier scheinbar Betriebsblind.
Viele Grüsse
Sven
Zitat von: sven.scherf am 26 Januar 2021, 16:33:23
Da die Firmware outdated war habe ich mir die neue Firmware von Q3 geladen und hier den update der Firmware in fhem angestossen.
Die neue Firmware von Q3 meint was?
Firmware Update geht so: https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Firmware_Update_des_UART-Moduls_mit_FHEM
Alle anderen Methoden empfehle ich nicht!
Ich vermute aber, es ist noch etwas mit der Schnittstelle faul. Das Gerät "spricht", aber ein zweites Gerät will an die Schnittstelle. Wenn das so ist klappt das Firmware Update auch nicht.
Schreib einfach auf, was genau Du alles gemacht hast. Dann könnte einer von uns sagen ob was fehlt ;)
Gruß Otto
Hallo,
ich habe für fhem einen Rapi 4 mit 8GB Ram im Einsatz.
Dieser hat an USB derzeit zwei Culs. Einen von Busware und einen Eigenbau für 433MHZ.
Diese funktionieren mit den bekannten Problemen.
Ja ich wollte die Firmware für den HM-MOD-RPI-PCB updaten da in dem Device fhem mir sagte D-firmware 1.2.1(outdated)
In den Readings von dem Device wechselt cond von init zu disconnected und dies hin und her.
Was habe ich gemacht.
Raspi shell
# seriell-getty Dienst für ttyAMA0 dauerhaft deaktivieren
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service
Nano /boot/config.txt
enable_uart=1 = war so eingestellt
dtoverlay=miniuart-bt = Eingetragen
core_freq=250 = überprüft, war so eingestellt
# dtoverlay=pi3-miniuart-bt = Eintrag deaktiviert
reboot des Raspi
ls -l /dev/ttyAMA0 ->
zeigt mir
crw-rw---- 1 root dialout 204, 64 Jan 27 09:40 /dev/ttyAMA0
ls -l /dev/serial* ->
zeigt mir
lrwxrwxrwx 1 root root 7 Jan 26 17:17 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 Jan 26 17:17 /dev/serial1 -> ttyS0
/dev/serial:
insgesamt 0
drwxr-xr-x 2 root root 80 Jan 26 17:17 by-id
drwxr-xr-x 2 root root 80 Jan 26 17:17 by-path
hcitool dev ->
zeigt mir
die Mac-Adresse vom BT Adapter
get-apt update && get-apt upgrade
in fhem
attr initialUsbCheck disable 1 -> dies funktionierte so nicht da habe ich es in der fhem.cfg direkt controlliert.
# Disable this to avoid looking for new USB devices on startup
# define initialUsbCheck notify global:INITIALIZED usb create
# setuuid initialUsbCheck 5e53f420-f33f-f700-ce3a-8e570fd4a76b0aa3
socat hatte ich installiert aber dann wieder gelöscht da dies ja nur für die Verwendung im Netzwerk benötigt wird.
Bei mir soll das Device auf dem Raspi laufen wo fhem installiert ist.
Beide CULs bei dem Raspi werden direkt über /dev/.... angesprochen.
Zum testen habe ich dann mal beide CULs abgezogen und den Raspi neu gestartet.
Hier war dann auch das gleiche Problem, dass der Adapter HM-MOD-RPI-PCB in den Readings cond immer den Status wechselt.
Danke Otto, der Tip mit dem Update von dem Device ausserhalb von fhem hat gefruchtet und ich konnte es updaten und nun stimmt auch der Status in fhem der cond steht auf OK.
Nun habe ich noch das Problem es in die virtuelle CCU einzubinden um damit meine Homematik Aktoren zu schalten.
Ich habe Verstanden, dass die IODev in den Devices nicht angefasst werden
In IOgrp steht bei den Devices meine CCU(HM_VCCU) drin.
In der Virtuellen CCU habe ich unter IOList die neue Schnittstelle eingetragen hier das List meiner Virtuellen CCU
Internals:
DEF F11034
FUUID 5fa44270-f33f-f700-691a-9585f81a143c537c
IODev CUL_0
NAME HM_VCCU
NOTIFYDEV global
NR 42
NTFY_ORDER 50-HM_VCCU
STATE CUL_0:disconnected,myHmUART:ok
TYPE CUL_HM
assignedIOs CUL_0,myHmUART
channel_01 HM_VCCU_Btn1
READINGS:
2021-01-26 15:48:00 CommandAccepted yes
2021-01-27 10:43:52 IOopen 1
2020-11-06 17:52:01 cfgState ok
2021-01-27 10:43:52 state CUL_0:disconnected,myHmUART:ok
2021-01-11 15:19:59 unknown_16DA6D received
2021-01-27 09:44:20 unknown_20A1CD received
2020-11-21 18:49:27 unknown_2EF052 received
2021-01-18 11:32:00 unknown_334ABC received
2021-01-27 09:56:32 unknown_34EFD8 received
2021-01-27 07:42:20 unknown_3F976B received
2021-01-27 09:59:57 unknown_41A48F received
2021-01-27 09:54:21 unknown_459CF5 received
2021-01-27 07:46:40 unknown_48ECB4 received
2021-01-27 09:20:04 unknown_4DA266 received
2021-01-27 10:00:32 unknown_58C986 received
2021-01-21 06:01:03 unknown_5F840D received
2021-01-27 09:16:34 unknown_635650 received
2021-01-27 10:06:36 unknown_686A89 received
2021-01-23 15:33:27 unknown_69690D received
2021-01-27 09:29:46 unknown_6EB269 received
2021-01-08 17:46:46 unknown_76F15D received
2021-01-27 07:00:01 unknown_7FC494 received
2021-01-26 22:47:16 unknown_805D13 received
2021-01-27 09:47:37 unknown_810D9D received
2021-01-23 17:32:19 unknown_8C2E11 received
2021-01-27 10:09:55 unknown_95CD3F received
2021-01-27 00:02:25 unknown_A12945 received
2021-01-08 15:00:26 unknown_AA82EE received
2020-11-21 01:52:13 unknown_ACF426 received
2021-01-27 10:10:17 unknown_AF5EF3 received
2021-01-27 10:06:36 unknown_B4AB02 received
helper:
HM_CMDNR 127
mId FFF0
peerFriend peerSens,peerAct
peerOpt -:virtual
regLst
rxType 1
cmds:
TmplKey :no:1611739897.40315
TmplTs 1611739897.40315
cmdKey 0:1:1::HM_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 HM_VCCU,Names
peerOpt Ausb_SW1_Eing,Ausb_SW2_Eing,Ausb_SW3_Eing_nop,Ausb_SW4_Gar,Ausb_SW5_Gar_nop,Ausb_SW6_Gar_nop,BadK_Fenster,BadK_Thermostat_WindowRec,BadK_Thermostat_remote,Bad_Fenster,Bad_La_Dusche,Bad_La_Haupt,Bad_La_Spiegel,Bad_Rol,Bad_Thermostat_WindowRec,Bad_Thermostat_remote,Bue_FensterL,Bue_FensterR,Bue_La,Bue_Rol_Fenster,Esse_Fenster_links,Esse_Fenster_rechts,Esse_La,Esse_Rol,Esse_funk_1_Btn_01,Esse_funk_1_Btn_02,FB1_Ch01,FB1_Ch02,FB1_Ch03,FB1_Ch04,FB1_Ch05,FB1_Ch06,FB1_Ch07,FB1_Ch08,Flur_FT01_Ch01,Flur_FT01_Ch02,Flur_FT02_Btn_01,Flur_FT02_Btn_02,Flur_FT02_Btn_03,Flur_FT02_Btn_04,Flur_FT02_Btn_05,Flur_FT02_Btn_06,Flur_FT03_Btn_01,Flur_FT03_Btn_02,Flur_La_Bild,Flur_La_Garderobe,Flur_La_Haupt,Flur_La_Telefon,HM_38C49B_Sw1_V_01,HM_38C49B_Sw1_V_02,HM_6977D7,Kel_FT01_Btn_01,Kel_FT01_Btn_02,Kel_La_Haupt,Kue_Fenster_LinksLinks,Kue_Fenster_LinksRechts,Kue_Fenster_RechtsLinks,Kue_Fenster_RechtsRechts,Kue_Heizung,Kue_La_1,Kue_La_2,Kue_La_3,Kue_Rol_Li,Kue_Rol_Re,Kue_Thermostat_WindowRec,Kue_Thermostat_remote,Schl_FT_Btn_01,Schl_FT_Btn_02,Schl_FT_Btn_03,Schl_FT_Btn_04,Schl_FT_Btn_05,Schl_FT_Btn_06,Schl_Fenster_links,Schl_Fenster_rechts,Schl_La_Bett,Schl_La_Haupt,Schl_La_Schrank,Schl_Rol_Fenster_Aktor,Schl_Rol_Tuer,Schl_Thermostat_WindowRec,Schl_Thermostat_remote,Schl_Tuer_Status,WC_Fenster,WC_La,WC_Rol,WC_Thermostat_WindowRec,WC_Thermostat_remote,Wz_La_Spot,Wz_Rol_Fenster,Wz_Rol_Tuer_Aktor,Wz_Tuer_Status
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
listDevice noArg
param -param-
expert:
def 1
det 0
raw 0
tpl 0
io:
prefIO
vccu HM_VCCU
ioList:
CUL_0
myHmUART
mRssi:
mNo
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
IODev CUL_0
IOList CUL_0,myHmUART
IOgrp HM_VCCU
model CCU-FHEM
room CCU
subType virtual
webCmd virtual:update
Das Schalten funktioniert jedoch noch nicht.
Habe ich hier was übersehen ?
P.S.ja habe ich.
ein Stop - Start von fhem brachte hier ich Lösung.
Vielen Dank euch allen ihr habt mir sehr geholfen.
Viele Grüße
Sven
Hallo sven,
warum das nicht funktioniert, erschließt sich mir nicht, aber ist egal. Du hast es ja deaktiviert:
attr initialUsbCheck disable 1
Eigentlich sieht alles gut aus, aber ich bleibe dabei: Irgendein Prozesse kämpft um die UART Schnittstelle. Jetzt muss ich mal überlegen, ob mir noch was einfällt was wir da schon alles hatten. :-[
Als OS ist raspberry os (raspbian) im Einsatz?
Irgendein Dienst der die USB Schnittstellen bedient?
Nach einem Neustart von FHEM (nicht des gesamten Systems) wird es auch nicht besser?
Wird irgendein GPIO Modul geladen?
Versucht die config zu strukturieren? :) https://forum.fhem.de/index.php?topic=109671.0
Gruß Otto
Da haben wir jetzt parallel geschrieben.
Zu deinem neuen Problem:
Hat denn der Aktor (bzw- alle CUL_HM Geräte) auch ein passendes IOgrp Attribute? Ja steht drin habs erst jetzt gelsesn.
Dann poste doch ein list von dem Versuchs Aktor ;)
Gruß Otto
Hallo,
es geht alles :)
Hier der Testaktor
Internals:
CFGFN ./aktoren.cfg
CUL_0_MSGCNT 3
CUL_0_RAWMSG A0EF0800237D94EF11034010100002B::-49.5:CUL_0
CUL_0_RSSI -49.5
CUL_0_TIME 2021-01-27 10:59:27
DEF 37D94E
FUUID 5cbaebfb-f33f-3d5f-fd1a-83ea948fe1d4ac8d
IODev CUL_0
LASTInputDev myHmUART
MSGCNT 6
NAME Bue_La
NOTIFYDEV global
NR 62
NTFY_ORDER 50-Bue_La
STATE off
TYPE CUL_HM
chanNo 01
lastMsg No:F0 - t:02 s:37D94E d:F11034 010100002B
myHmUART_MSGCNT 3
myHmUART_RAWMSG 0500003CF0800237D94EF11034010100002B
myHmUART_RSSI -60
myHmUART_TIME 2021-01-27 10:59:27
protLastRcv 2021-01-27 10:59:27
protRcv 3 last_at:2021-01-27 10:59:27
protResnd 1 last_at:2021-01-27 10:59:27
protSnd 4 last_at:2021-01-27 10:59:21
protState CMDs_done
rssi_CUL_0 cnt:2 min:-46 max:-43 avg:-44.5 lst:-43
rssi_at_CUL_0 cnt:3 min:-49.5 max:-48 avg:-49 lst:-49.5
rssi_at_myHmUART cnt:3 min:-63 max:-57 avg:-60 lst:-60
rssi_myHmUART cnt:1 min:-69 max:-69 avg:-69 lst:-69
READINGS:
2021-01-27 10:59:27 CommandAccepted yes
2020-11-05 16:47:31 D-firmware 2.3
2020-11-05 16:47:31 D-serialNr MEQ0224573
2020-12-23 08:23:29 PairedTo 0xF11034
2020-08-25 19:27:58 R-Bue_Rol_Fenster_chn-01-lgActionType jmpToTarget
2020-08-25 19:27:58 R-Bue_Rol_Fenster_chn-01-shActionType jmpToTarget
2020-11-05 16:47:36 R-pairCentral 0xF11034
2020-08-25 19:27:56 R-sign off
2020-12-23 08:23:29 RegL_00. 00:00 02:01 0A:F1 0B:10 0C:34 15:FF 18:00
2020-12-23 08:23:29 RegL_01. 00:00 08:00 30:06 57:24
2020-12-23 08:23:59 cfgState ok
2021-01-27 10:59:27 commState CMDs_done
2021-01-27 10:59:27 deviceMsg off (to HM_VCCU)
2021-01-27 10:59:27 level 0
2021-01-27 10:59:27 pct 0
2020-12-23 08:23:22 powerOn 2020-12-23 08:23:22
2021-01-27 10:59:27 recentStateType ack
2021-01-27 10:59:27 state off
2021-01-27 10:59:27 timedOn off
helper:
HM_CMDNR 240
cSnd 11F1103437D94E0201C80000,11F1103437D94E0201000000
dlvlCmd ++A011F1103437D94E0201000000
mId 0069
peerFriend peerSens,peerVirt
peerIDsState complete
peerOpt 3:switch
regLst 0,1,3p
rxType 1
supp_Pair_Rep 0
cmds:
TmplKey :no:1611741536.37771
TmplTs 1611741536.37771
cmdKey 1:1:0::Bue_La:0069:01:
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
getVersion noArg
inhibit [(on|{off})]
off noArg
on noArg
on-for-timer -ontime-
on-till -time-
pair noArg
peerBulk -peer1,peer2,...- [({set}|unset)]
peerIODev [IO] -btn- [({set}|unset)] 'not for future use'
peerSmart -peerOpt-
press [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
statusRequest noArg
toggle noArg
tplDel -tplDel-
tplSet_0 -tplChan-
unpair noArg
lst:
condition slider,0,1,255
peer Bue_La,Names
peerOpt Ausb_SW1_Eing,Ausb_SW2_Eing,Ausb_SW3_Eing_nop,Ausb_SW4_Gar,Ausb_SW5_Gar_nop,Ausb_SW6_Gar_nop,BadK_Fenster,Bad_Fenster,Bue_FensterL,Bue_FensterR,Esse_Fenster_links,Esse_Fenster_rechts,Esse_funk_1_Btn_01,Esse_funk_1_Btn_02,FB1_Ch01,FB1_Ch02,FB1_Ch03,FB1_Ch04,FB1_Ch05,FB1_Ch06,FB1_Ch07,FB1_Ch08,Flur_FT01_Ch01,Flur_FT01_Ch02,Flur_FT02_Btn_01,Flur_FT02_Btn_02,Flur_FT02_Btn_03,Flur_FT02_Btn_04,Flur_FT02_Btn_05,Flur_FT02_Btn_06,Flur_FT03_Btn_01,Flur_FT03_Btn_02,HM_6977D7,HM_VCCU_Btn1,Kel_FT01_Btn_01,Kel_FT01_Btn_02,Kue_Fenster_LinksLinks,Kue_Fenster_LinksRechts,Kue_Fenster_RechtsLinks,Kue_Fenster_RechtsRechts,Schl_FT_Btn_01,Schl_FT_Btn_02,Schl_FT_Btn_03,Schl_FT_Btn_04,Schl_FT_Btn_05,Schl_FT_Btn_06,Schl_Fenster_links,Schl_Fenster_rechts,Schl_Tuer_Status,WC_Fenster,Wz_Tuer_Status
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +37D94E,00,00,00
nextSend 1611741567.74232
prefIO
rxt 0
vccu HM_VCCU
p:
37D94E
00
00
00
mRssi:
mNo F0
io:
CUL_0:
-41.5
-41.5
myHmUART:
-60
-60
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
rssi:
CUL_0:
avg -44.5
cnt 2
lst -43
max -43
min -46
at_CUL_0:
avg -49
cnt 3
lst -49.5
max -48
min -49.5
at_myHmUART:
avg -60
cnt 3
lst -60
max -57
min -63
myHmUART:
avg -69
cnt 1
lst -69
max -69
min -69
tmpl:
Attributes:
IODev CUL_0
IOgrp HM_VCCU
alexaName Büro Licht
alexaRoom test
autoReadReg 4_reqStatus
expert defReg,rawReg
firmware 2.3
genericDeviceType switch
model HM-LC-SW1PBU-FM
peerIDs 00000000
room Buero,alexa
serialNr MEQ0224573
subType switch
userattr Lichterkette Lichterkette_map mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude
webCmd statusRequest:toggle:on:off
Kann die Virtuelle CCU beide Schnittstellen sprich den CUL und den HM-MOD-RPI-PCB gleichzeitig nutzen oder ist es hier besser den CUL aus der IOList raus zu nehmen ?
Die Lösung, dass die Schnittstelle HM-MOD-RPI-PCB in fhem funktionierte nach dem Eintragen in der Virtuellen CCU fhem zu stoppen und wieder zu starten, dann ist die Schnittstelle auch in der CCU in den Internals aufgetaucht was vorher nicht der Fall war.
Viele Grüße
Sven
ZitatKann die Virtuelle CCU beide Schnittstellen sprich den CUL und den HM-MOD-RPI-PCB gleichzeitig nutzen oder ist es hier besser den CUL aus der IOList raus zu nehmen ?
Ja.
Das genau ist ja der eigentliche Sinn und Zweck.
Es kann sein, dass Du in Problemfällen (pairen von Hm "Zicken") den CUL einfach zeitweise deaktivierst oder über IOgrp VCCU:IO einen bevorzugst.