Hallo,
ich verzweifle gerade etwas.
Ich habe seit etwa 2 Jahren problemlos eine FHEM-Installation mit mehreren Homematic-Geräten am laufen. Alles funktionierte wunderbar, bis plötzlich ein Rolladenaktor seinen Dienst verweigerte. Es ist ein HM-LC-BL1PBU-FM, der auch gar nicht mal der ist, der vielleicht am weitesten weg von der Antenne des 868MHz-CUL ist oder wo es besonders viele Wände oder sonstwas gäbe.
In FHEM ist das Device mit dem state "MISSING ACK" gelistet. Ich habe an gleicher Stelle auch ein Heizkörperthermostat von Homematic, etwa 50cm entfernt davon, 2 Stockwerke darunter, also empfangstechnisch wesentlich kritischer, weitere Homematic-Geräte, die alle problemlos funktionieren.
Erster Gedanke was "Gerät defekt". Also neues bestellt und eingebaut und in FHEM ausgetauscht...Ergebnis "MISSING ACK"!!!
Wenn ich den Rolladen per Tastendruck am Homematic-Device per Hand verfahre, funktioniert das und im Device-Overview in FHEM wird das auch angeziegt, z.B. im Reading "deviceMsg". Der Funkkontakt vom Device in Richtung FHEM scheint also zu funktionieren, nur nicht in die Richtung von FH>EM zum Device.
Hat jemand ne Idee, woran das liegen kann? Auch das jetzige Problem-Gerät hat vorher jahrelang problemlos funktioniert. Ich habe auch nichts neues angeschafft an funk-produzierenden Geräten, was vielleicht dafür verantwortlich sein könnte.
Ich bin für jeden Hinweis dankbar!
Gruß,
Thomas
Zitat von: musicnrw am 11 März 2020, 16:49:30
Es ist ein HM-LC-BL1PBU-FM, der auch gar nicht mal der ist, der vielleicht am weitesten weg von der Antenne des 868MHz-CUL ist oder wo es besonders viele Wände oder sonstwas gäbe.
In FHEM ist das Device mit dem state "MISSING ACK" gelistet. Ich habe an gleicher Stelle auch ein Heizkörperthermostat von Homematic, etwa 50cm entfernt davon, 2 Stockwerke darunter, also empfangstechnisch wesentlich kritischer, weitere Homematic-Geräte, die alle problemlos funktionieren.
Mit Suche nach CUL, Missing Ack und Homematic findest du gefühlt 3Mio Einträge...
Jaja, es lief ja und so weiter...
ABER: ein CUL ist nun mal für Homematic letzte Wahl...
Max. noch mit der TS-CUL-FW...
Grund (kurz, Ausführlich bitte Suche bemühen):
Timing. Fhem tut etwas und reagiert nicht schnell genug auf Anfragen/Pakete vom Gerät -> missing ACK
(Edit: fhem entwickelt sich weiter -> Timing wird "anders" [schlechter] oder du "entwicklest" weiter -> Timing wird "anders" [schlechter])
"Originale" Funkmodule (z.B. HMOD-PCB) machen viel in Firmware (was beim CUL eben fhem mitmachen muss) -> weniger/keine Funkprobleme
EDIT2: auch ich hatte einen CUL und auch (lange) keine Probleme. Dann kam plötzlich der "Klingelsensor" -> missing ack... ;) Danach habe ich die TS-CUL-FW geflasht und es war gut. (Allerdings war das für mich keine Dauerlösung und das HMOD-PCB kostet kaum/nicht mehr als ein Selbstbau-CUL)
EDIT3: hier noch ein paar links https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi bzw. https://forum.fhem.de/index.php/topic,24436.0.html
Gruß, Joachim
Hi Joachim,
vielen Dank für Deine ausführliche Antwort.
Ich werde wohl erstmal das flashen mit der TS-CUL-FW Firmware versuchen.
Wenn ich den ultimativen Schritt zu einem Original Funkmodul (z.B. HMOD-PCB) mache, muss ich dann alle HM-Geräte neu pairen?
Gruß,
Thomas
Vorausgesetzt du hast eine HMID vergeben (attr CUL hmid XXXXXX) oder weißt sie zumindest (ein list vom CUL würde helfen ;) ), dann: NEIN!
Am einfachsten: definiere eine vccu -> https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
(schadet auch ohne 2 IOs nicht / ist bei meinen Installationen [mit je nur einem HM-Funkmodul] "standard")
packe dort den CUL rein und dann später das HMOD-PCB und entweder entfernst du dann den CUL oder lässt ihn...
(allerdings sind 2 Funkdongle in "direkter" Nähe nicht unbedingt gut [auch wenn die vccu das "regelt" / aber bei bestimmten Dingen wie Pairen etc. sind 2 IOs nicht wirklich hilfreich / im Gegenteil], daher würde ich den CUL dann "weglegen" ;) )
Gruß, Joachim
Hallo Joachim,
im Dateianhang ein Screenshot vom Listing meines CUL.
Kannst Du mir beschreiben, was genau ich tun muss, um den CUL gegen den HM-MOD-RPI-PCB HomeMatic Funkmodul auszutauschen?
Danke!
Thomas
Bitte keine Screenshots...
Einfach:
list Device-Name
in FHEMWEB-cmd und die Ausgabe hier in "code-Tags" (das '#' im "Menü") posten...
So wie ich geschrieben habe:
eine vccu erstellen (siehe Wiki Link), dann (wenn du ihn hast) den HMOD-PCB definieren und als weiteres IODev der vccu hinzufügen...
Fertig...
Wenn du dann willst einfach den CUL "löschen" und aus der vccu austragen und abstecken...
Wenn du soweit bist einfach im Forum suchen (ist bestimmt schon 1000mal beschrieben worden) und bei Fragen/Problemen einfach noch mal melden...
Gruß, Joachim
Hallo Joachim,
ok, hab das listing gemacht. Da ich da so ein Attribukt mit dem Namen hmID finde, denke ich, dass ich das also recht problemlos austauschen kann?!
Bei ELV hab ich auch ein Funkmodul mit dem Namen RPI-RF-MOD gefunden. Wäre das auch eine Alternative, die ich nach gleichem Muster einsetzen könnte?
Internals:
CMDS ABCEeFfGhiKklMmRTtUVWXxYZz
CUL868_MSGCNT 6108
CUL868_TIME 2020-03-13 10:15:50
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@38400 0000
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@38400
FD 11
FHTID 0000
FUUID 5c77fe93-f33f-9d3c-833c-a254a4f20217faca
NAME CUL868
NR 43
NR_CMD_LAST_H 8
PARTIAL
RAWMSG A0F2386105131830000000A98C80F194013
RSSI -64.5
STATE Initialized
TYPE CUL
VERSION V 1.67 nanoCUL868
initString X21
Ar
MatchList:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2020-03-01 16:23:03 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2020-03-11 15:40:32 cmds A B C E e F f G h i K k l M m R T t U V W X x Y Z z
2020-03-13 10:15:50 state Initialized
XMIT_TIME:
1584089549.0276
1584089549.12737
1584090227.96559
1584090228.24498
1584090228.54107
1584090359.60051
1584090359.88012
1584090360.17517
helper:
3A28E2:
QUEUE:
3A38ED:
QUEUE:
422E14:
QUEUE:
513183:
QUEUE:
54A91E:
QUEUE:
54AA5C:
QUEUE:
550603:
QUEUE:
550609:
QUEUE:
557613:
QUEUE:
560640:
QUEUE:
56065F:
QUEUE:
678BCE:
QUEUE:
68F324:
QUEUE:
Attributes:
hmId AABBCC
rfmode HomeMatic
Gruß,
Thomas
Danke für das list... :)
...ich hatte das Attribut auch schon im Screenshot gesehen... ;)
War eher für die Zukunft gedacht...
...ein list ist besser als ein Screenshot...
RPI-RF-MOD: NEIN!!!
Das geht NICHT direkt mit fhem!
Nur mit einer CCU!
(Nicht verwechseln mit vccu!)
D.h. mit Bausatz Charly oder debMatic oder Raspberrymatic oder...
Wenn du allerdings vor hast auch mal Homematic IP zu nutzen, dann wirst du eine CCU brauchen...
Homematic "Classic" geht auch mit CCU...
...aber Homematic IP nicht DIREKT mit fhem.
Nur über CCU und dann mittels HMCCU-Modul (statt jetzt CUL_HM)...
Gruß, Joachim
Hallo,
ich habe heute den HM-MOD-RPI-PCB bekommen und am Raspberry angesteckt.
Ich habe mich an die Anleitung von Otto gehalten: http://heinz-otto.blogspot.com/2016/07/raspberry-pi-homematic-modul.html
Ich habe also die /boot/config.txt editiert und danach den serial-getty Dienst deaktiviert und dann den Raspi neu gestartet.
Danach habe ich in FHEM folgende Befehle ausgeführt
define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId AABBCC
Das Ergebnis ist Internals:
CNT 1
Clients :CUL_HM:
DEF /dev/ttyAMA0
DevState 1
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 38
FUUID 5e70c04f-f33f-9d3c-0aab-e0d049a2b6165fe0
FirmwareFile /opt/fhem/FHEM/firmware/coprocessor_update.eq3
LastOpen 1584458554.04362
NAME myHmUART
NOTIFYDEV global
NR 450
NTFY_ORDER 50-myHmUART
PARTIAL
STATE opened
TYPE HMUARTLGW
XmitOpen 0
model HM-MOD-UART
Helper:
AckPending:
1:
cmd 00
dst 0
frame FD00030001009E03
resend 3
time 1584458555.04679
LastSendLen:
3
Log:
IDs:
MatchList:
1:CUL_HM ^A......................
READINGS:
2020-03-17 13:47:08 D-type HM-MOD-UART
2020-03-17 16:22:35 cond init
2020-03-17 13:47:08 loadLvl suspended
2020-03-17 16:22:34 state opened
Attributes:
hmId AABBCC
Weiterhin habe ich in FHEM die VCCU definert, und zwar so:
define VCCU CUL_HM AABBCC
attr VCCU IOList CUL868
attr VCCU IOgrp VCCU
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update
wobei mein heutiger CUL, den ich ja durch das neue Funkmodul ersetzen möchte, CUL868 heisst und die hmID AABBCC hat.
Ich kann mir nur überhaupt nicht vorstellen, wie FHEM jetzt wissen soll, dass es den HM-MOD jetzt für die Kommunikation zu den Homematic-Geräten verwenden soll anstelle des "alten" CULs. Da fehlt doch bestimmt noch irgendwas, oder?
Und daher habe ich auch aktuell keinerlei Verbindung zu meinen Homematic-Geräten mehr.
Kann mir da jemand helfen? Joachim, ich wäre Dir für Unterstützung sehr dankbar.
Gruß,
Thomas
Hi,
warum nehmen immer alle die ältesten Artikel aus dem Internet :( wobei der generell noch richtig ist :)
Dein Modul ist noch nicht wirklich eingebunden, das reagiert noch nicht!
Also bitte geh nochmal die Schritte durch:
https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Wenn das Modul läuft musst Du dies vervollständigen!
attr VCCU IOList CUL868
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
Gruß Otto
Hallo Otto,
danke für Deine Hilfe.
Ich bin die Schritte jetzt nochmal durchgegangen und im Logfile finde ich diese Einträge
Opening myHmUART device /dev/ttyAMA0
Setting myHmUART serial parameters to 115200,8,N,1
myHmUART device opened
Ein listing der VCCU liefert das:
Internals:
DEF AABBCC
FUUID 5e70bff1-f33f-9d3c-ec49-2195890ab7e21bed
IODev CUL868
NAME VCCU
NOTIFYDEV global
NR 452
NTFY_ORDER 50-VCCU
STATE myHmUART:UAS,CUL868:ok
TYPE CUL_HM
assignedIOs CUL868,myHmUART
channel_01 VCCU_Btn1
READINGS:
2020-03-17 17:45:36 IOopen 1
2020-03-17 17:45:36 state myHmUART:UAS,CUL868:ok
helper:
HM_CMDNR 107
mId FFF0
peerFriend peerSens,peerAct
peerOpt -:virtual
regLst 0
rxType 1
expert:
def 1
det 0
raw 0
tpl 0
io:
prefIO
vccu VCCU
ioList:
CUL868
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
IODev CUL868
IOList CUL868
IOgrp VCCU
model CCU-FHEM
subType virtual
webCmd virtual:update
Ist das ok oder fehlt mir da immer noch was? Müsste im Logfile nicht noch was bzgl. "HMUARTLGW" auftauchen?
Gruß,
Thomas
Zitat von: musicnrw am 17 März 2020, 17:58:59
Müsste im Logfile nicht noch was bzgl. "HMUARTLGW" auftauchen?
Hast du doch selbst gepostet ;)
Zitat
Opening myHmUART device /dev/ttyAMA0
Setting myHmUART serial parameters to 115200,8,N,1
myHmUART device opened
EDIT: bei der vccu fehlt noch der myHMUART als IODev in der IOList (wie Otto bereits geschrieben hatte)...
Zu sehen auch hier:
Zitat
2020-03-17 17:45:36 state myHmUART:UAS,CUL868:ok
UAS: unassigned / nicht zugeordnet
EDIT: und wie ebenfalls schon mal geschrieben: wenn du bereits ein Gerät angelernt hast bzw. versucht hast es anzulernen BEVOR du die hmid (die du jetzt hast) "vergeben" hast, dann musst du das/die Gerät/e zurücksetzen! Und neu pairen... Ansonsten: loslegen mit PAIREN... :)
EDIT: evtl. den CUL (jetzt) rausnehmen. 2 IOs sind beim Pairen oft nicht gut... Und das HMUART ist deutlich besser (sofern Funk-technisch nicht schlecht[er] positioniert)...
Gruß, Joachim
Was da im Logfile steht, kann ichnicht richtig zu ordnen, das sagt meines Erachtens nicht viel.
Die readings müssen anders aussehen als in deinem list, etwa so:
READINGS:
2020-03-11 10:51:26 D-HMIdAssigned 200DB8
2020-03-11 10:51:26 D-HMIdOriginal 4709B3
2020-03-11 10:51:26 D-firmware 1.4.1
2020-03-11 10:51:27 D-serialNr NEQ0229647
2020-03-11 10:50:33 D-type HM-MOD-UART
2020-03-11 10:51:27 cond ok
2020-03-17 18:43:41 load 3
2020-03-11 10:51:27 loadLvl low
2020-03-11 10:51:21 state opened
Gruß Otto
So, jetzt sieht das Listing so aus:
Internals:
AssignedPeerCnt 0
CNT 62
Clients :CUL_HM:
DEF /dev/ttyAMA0
DEVCNT 62
DevState 99
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 39
FUUID 5e70c04f-f33f-9d3c-0aab-e0d049a2b6165fe0
LastOpen 1584468594.76708
NAME myHmUART
NOTIFYDEV global
NR 454
NTFY_ORDER 50-myHmUART
PARTIAL
RAWMSG 040200
RSSI -70
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model HM-MOD-UART
msgLoadCurrent 0
msgLoadHistory -/-/-/-/-/-/-/-/-/-/-/-
msgLoadHistoryAbs 0/-/-/-/-/-/-/-/-/-/-/-/-
owner AABBCC
owner_CCU VCCU
Helper:
CreditTimer 3
FW 66561
Initialized 1
AckPending:
LastSendLen:
3
3
Log:
IDs:
RoundTrip:
Delay 0.0027320384979248
loadLvl:
lastHistory 1584468624.58776
MatchList:
1:CUL_HM ^A......................
Peers:
READINGS:
2020-03-17 19:10:24 D-HMIdAssigned AABBCC
2020-03-17 19:10:24 D-HMIdOriginal 6D0EBF
2020-03-17 19:10:24 D-firmware 1.4.1
2020-03-17 19:10:24 D-serialNr QEQ0410835
2020-03-17 18:50:12 D-type HM-MOD-UART
2020-03-17 19:10:24 cond ok
2020-03-17 19:10:24 load 0
2020-03-17 19:10:24 loadLvl low
2020-03-17 19:09:54 state opened
helper:
Attributes:
hmId AABBCC
Muss ich denn jetzt jedes Homematic-Gerät neu pairen? Ich dachte gemäß der Tatsache, dass ich meinem CUl auch ein hmID-Attribut gegeben hatte, wäre das nun beim Einsatz der VCCU nicht mehr nötig?!
Danke und Gruß
Thomas
Hallo Thomas,
nein musst Du generell nicht, Was gepairt war, bleibt gepairt. Was nicht richtig gepairt war, wird dadurch aber auch nicht besser ;)
Allerdings sollten Problemfälle jetzt leichter gepairt werden können 👍
Hast Du ergänzt?
attr VCCU IOList CUL868,myHmUART
Gruß Otto
Vielen Dank Euch beiden, ich glaub es funktioniert!
Auch der Rolladen, der bislang immer ein MISSING ACK meldete, wird jetzt wieder angesprochen.
Ich beobachte es mal und gebe nochmal Feedback.
Gruß,
Thomas
und natürlich in jedem hauptdevice zusätzlich "attr IOgrp" setzen.
ich würde den cul auch in der vccu belassen (fallback).
dann aber auch unbedingt den hmuart als prefered io in den devices setzen, damit sich der cul nicht "vordrängelt".
also "attr <device> IOgrp VCCU:myHmUART".
<device> könnte man mit TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6}:FILTER=DEF!=AABBCC ersetzen :9
wenn es viele HM Geräte sind :)
Sorry, jetzt verstehe ich gar nichts mehr...
Und was verstehe ich genau unter "Hauptdevice"? Ist das das myHmUART bzw. der CUL?
Zitat von: musicnrw am 17 März 2020, 20:42:18
Sorry, jetzt verstehe ich gar nichts mehr...
Und was verstehe ich genau unter "Hauptdevice"? Ist das das myHmUART bzw. der CUL?
Nein.
(Fast / Fensterkontakt wäre z.B. eine Ausnahme) jedes Homematic Device per CUL_HM hat ein "Hauptdevice" und dann entsprechende (Unter)Kanäle...
Z.B. das Thermostat hat das Hauptdevice und dann noch Kanäle wie _Clima, _Climate, _Weather, ...
Gruß, Joachim
Hallo,
vielen Dank nochmal. Die Sache funktioniert einwandfrei, ich bin sehr zufrieden. Auch die RSSI-Werte sind mit dem HM-MOD deutlich besser als mit dem CUL.
Ich mache das Thema zu.
Gruß,
Thomas