Hallo liebe Gemeinde,
mal wieder ersuche ich Eure Hilfe zu einem Thema, dass nominell bereits mehrfach existiert, deren Lösungen bei mir allerdings leider noch nicht zum Ziel geführt haben.
Ich versuche die Heizungsthermostate HM-CC-RT-DN von Homematik mit FHEM zu verbinden, also zu pairen, was allerdings soweit nicht gelingt. Als IO-Gerät nutze ich das Funkmodul HM-MOD-RPI-UART kombiniert mit einem CP2102 USB-Adapter gemäß der Anleitung unter https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi). Am R-Pi per USB angeschlossen wurde dann folgendes Device angelegt:
Internals:
AssignedPeerCnt 0
CFGFN
CNT 20
Clients :CUL_HM:
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
DEVCNT 20
DevState 99
DevType UART
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0@115200
FD 9
FUUID 5d4992c1-f33f-9576-29f3-4eabcc864b988864
LastOpen 1565102851.54698
NAME USB_HmUART
NOTIFYDEV global
NR 26323
NTFY_ORDER 50-USB_HmUART
PARTIAL
RAWMSG 040200
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model HM-MOD-UART
msgLoadCurrent 0
msgLoadHistory -/-/-/-/-/-/-/-/-/-/-/-
msgLoadHistoryAbs 0/-/-/-/-/-/-/-/-/-/-/-/-
owner 6BD03D
Helper:
CreditTimer 4
FW 66561
Initialized 1
AckPending:
LastSendLen:
3
3
Log:
IDs:
RoundTrip:
Delay 0.00626397132873535
loadLvl:
lastHistory 1565102855.62054
MatchList:
1:CUL_HM ^A......................
Peers:
READINGS:
2019-08-06 16:47:35 D-HMIdAssigned 6BD03D
2019-08-06 16:47:35 D-HMIdOriginal 6BD03D
2019-08-06 16:47:35 D-firmware 1.4.1
2019-08-06 16:47:35 D-serialNr PEQ2218024
2019-08-06 16:46:25 D-type HM-MOD-UART
2019-08-06 16:47:35 cond ok
2019-08-06 16:47:35 load 0
2019-08-06 16:47:35 loadLvl low
2019-08-06 16:47:31 state opened
Attributes:
Meines Erachtens so weit so gut, oder entdeckt jemand hier schon Unstimmigkeiten?
Nun beginne ich damit, das erste Thermostat zu pairen. Entsprechend:
set USB_HmUART hmPairForSec 300
Anschließen am Thermostat die mittlere Taste gedrückt bis die 30 Sekungen heruntergezählt werden. Nach etwa 1 bis 2 Sekungen erscheint im "Event Monitor" folgendes ... allerdings zählt es am Thermostat während dessen weiter bis 0 herunter:
2019-08-06 17:10:28 Global global UNDEFINED HM_6AD67E CUL_HM 6AD67E
2019-08-06 17:10:28 Global global DEFINED HM_6AD67E
2019-08-06 17:10:28 Global global DEFINED FileLog_HM_6AD67E
2019-08-06 17:10:28 Global global DEFINED HM_6AD67E_Weather
2019-08-06 17:10:29 Global global DEFINED HM_6AD67E_Climate
2019-08-06 17:10:29 Global global DEFINED HM_6AD67E_WindowRec
2019-08-06 17:10:29 Global global DEFINED HM_6AD67E_Clima
2019-08-06 17:10:29 Global global DEFINED HM_6AD67E_ClimaTeam
2019-08-06 17:10:29 Global global DEFINED HM_6AD67E_remote
2019-08-06 17:10:30 CUL_HM ActionDetector alive:1 dead:0 unkn:0 off:0
2019-08-06 17:10:30 CUL_HM ActionDetector status_HM_6AD67E: alive
2019-08-06 17:10:30 CUL_HM HM_6AD67E Activity: alive
2019-08-06 17:10:30 CUL_HM HM_6AD67E D-firmware: 1.5
2019-08-06 17:10:30 CUL_HM HM_6AD67E D-serialNr: PEQ1316454
2019-08-06 17:10:30 CUL_HM HM_6AD67E CMDs_pending
Das automatisch angelegte Device sie wie folgt aus:
Internals:
CFGFN
DEF 6AD67E
FUUID 5d499864-f33f-9576-c0ab-73c41768c4e53ff0
IODev USB_HmUART
LASTInputDev USB_HmUART
MSGCNT 1
NAME HM_6AD67E
NOTIFYDEV global
NR 26408
NTFY_ORDER 50-HM_6AD67E
STATE CMDs_pending
TYPE CUL_HM
USB_HmUART_MSGCNT 1
USB_HmUART_RAWMSG 050000380184006AD67E000000150095504551313331363435345900FFFF
USB_HmUART_RSSI -56
USB_HmUART_TIME 2019-08-06 17:10:30
channel_01 HM_6AD67E_Weather
channel_02 HM_6AD67E_Climate
channel_03 HM_6AD67E_WindowRec
channel_04 HM_6AD67E_Clima
channel_05 HM_6AD67E_ClimaTeam
channel_06 HM_6AD67E_remote
lastMsg No:01 - t:00 s:6AD67E d:000000 150095504551313331363435345900FFFF
protCmdPend 3 CMDs_pending
protLastRcv 2019-08-06 17:10:29
protRcv 2 last_at:2019-08-06 17:10:29
protState CMDs_pending
rssi_at_USB_HmUART cnt:2 min:-56 max:-56 avg:-56 lst:-56
READINGS:
2019-08-06 17:10:29 Activity alive
2019-08-06 17:10:29 D-firmware 1.5
2019-08-06 17:10:29 D-serialNr PEQ1316454
2019-08-06 17:10:29 R-pairCentral set_0xF10000
2019-08-06 17:10:29 state CMDs_pending
cmdStack:
++A001F100006AD67E00050000000000
++A001F100006AD67E000802010AF10B000C00
++A001F100006AD67E0006
helper:
HM_CMDNR 1
PONtest 1
mId 0095
peerFriend
peerOpt -:thermostat
regLst 0
rxType 140
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +6AD67E,02,00,00
nextSend 1565104227.97448
prefIO
rxt 2
vccu
p:
6AD67E
00
00
00
mRssi:
mNo 01
io:
USB_HmUART:
-50
-50
prt:
bErr 0
sProc 2
q:
qReqConf 00
qReqStat
role:
dev 1
prs 1
rssi:
at_USB_HmUART:
avg -56
cnt 2
lst -56
max -56
min -56
shRegW:
07 04
shadowReg:
RegL_00. 02:01 0A:F1 0B:00 0C:00
Attributes:
IODev USB_HmUART
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.5
model HM-CC-RT-DN
room CUL_HM
serialNr PEQ1316454
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
Auch die einzelnen Kanäle wurde erstellt, allerdings liefern diese keine Werte, nur "???". Auffällig, aber für mich nicht nach zu vollziehen ist, dass die Zeile ..
R-pairCentral set_0xF10000
.. bei meinen vielen Versuchen mal "F10000", hin und wieder aber auch die korrekte HMID ("6BD03D") anzeigt. Ideen, wo das "F10000" herkommen könnte?
Jedenfalls konnte ich jeweils keine unterschiedlichen Pairing-Ergebnisse feststellen. Der Reading "state" des "HM_6AD67E" bleibt auf "CMDs_pending", das Reading "Activity" wechselt zu "dead".
Erneutes Pairing führt zu keinelei Veränderung, auch nach mehr als 24 Stunden ohne Zutun ist alles wie gehabt. Befehle wie ..
set <HM-Gerät> getConfig
.. führen nur zur Erhöhung der Anzahl an "CMDs pending". Auch eine VCCU habe ich nach bestem Wissen und Gewissen schon probiert, leide rebenfalls mit dem selben Ergebnis.
Zuguterletzt noch die Infos vom HM configCheck (mal mit, mal ohne den Hinweis auf die nicht übereinstimmenden HMIDs):
configCheck done:
missing register list
HM_6AD67E: RegL_00.
HM_6AD67E_Clima: RegL_01.,RegL_07.
HM_6AD67E_ClimaTeam: RegL_01.
HM_6AD67E_Climate: RegL_01.
HM_6AD67E_Weather: RegL_01.
HM_6AD67E_WindowRec: RegL_01.
HM_6AD67E_remote: RegL_01.
Register changes pending
HM_6AD67E
peer list incomplete. Use getConfig to read it.
incomplete: HM_6AD67E_Clima:
incomplete: HM_6AD67E_ClimaTeam:
incomplete: HM_6AD67E_Climate:
incomplete: HM_6AD67E_Weather:
incomplete: HM_6AD67E_WindowRec:
incomplete: HM_6AD67E_remote:
templist mismatch
HM_6AD67E_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
Habt ihr Ideen oder Hinweise?
Herzlichen Dank im Voraus,
viele Grüße
Tim
Wenn R-pairCentral set_0xFxxxxxx auf deinem richtigen ID kommt, aber CMD_pending immer noch steht, dann die mittlere Taste am Thermostat wie für ein pairing (bis es runterzählt) so oft wie nötig (bis CMD_done) nochmal drucken
Er hat noch was zu senden/verarbeiten.
Ansonsten einfach warten, bis das Thermostat sich oft genug selbst geweckt hat.
Du musst in deinem System noch irgend einen CUL (oder Derivate)
in deinem System definiert haben
die
set_0xF10000
kommt definitiv nicht vom HMUART, und da du schreibst, es wäre abwechselnt, schlagen sich die zwei I/Os um die Anlernmessage.
wenn du schon keine vccu nutzt, würde ich zumindestens das attr hmID beim hmuart setzen.
Hallo zuammen,
zunächst herzlichen Dank an alle für die Zeit, die Antworten, Vorschläge und Hinweise!
@frank
Wie von mir kurz geschrieben, habe ich das Ganze auch mit VCCU probiert, dass die dort vergebene HMID ordnungsgemäß an das USB_HmUART weitergegeben hat. Leider mit gleichem Ergebnis.
Auch ist in meinem "list" zum USB_HmUART das Reading "D-HMIdAssigned 6BD03D" zu sehen, welches durch das Attribut "HMID 6BD03D" ensteht, das im "list" selbst leider unbeabsichtigt beim copy-paste auf der Strecke geblieben zu sein scheint.
@amenomade
Leider hat in meinem Falle wiederholtes Betätigen der Pairing-Taste (30-Sekunden-Counter) auch bei den Versuchen mit übereinstimmenden IDs nicht zum Erfolg geführt.
@fhem-hm-knecht
Neben dem HMIO betreibe ich noch ein 433er sowie einen 868er NanoCUL, jeweils mit CUL-FW bzw. aCUL-FW. Die CUL-Devices selbst habe ich nicht entfernt, jedoch alle automatisch erstellten Device, die auf empfangenen Signalen dieser beiden CULs basierten. Ob diese mit dem nun funktionierden Zustand zu tun hat, kann ich im Augenblick nicht zweifelsfrei bestätigen.
Die bzw. eine vermeindliche Lösung meiner Situation bestand in der zufällig durchgeführten Abfolge dieser Vorgänge:
1) USB_HmUART so zurücksetzen, dass keine Geräte gepairt sind
2) USB_HmUART in "Pairing"-Modus versetzen
3) Thermostat in "Pairing"-Modus versetzen (mittlere Taste beim HM-CC-RT-DN drücken, bis 30-Sekunden-Counter erscheint)
--> Device und Channels werden in FHEM erstellt (danach passierte wie zuvor nicht mehr)
4) Thermostat komplett auf Werkseinstellungen zurücksetzen (Zeit einstellen, Einstellungslauf, ...)
5) Thermostat erneut in "Pairing"-Modus versetzen
==> innerhalb einer Minute hat FHEM das Pairing komplett abgeschlossen (Readings: "CMDs done" / "R-pairCentral 0x6BD03D")
Der zumindest bei mir relevante Unterschied zu @amenomade Hinweis bzw. den Tipps in den anderen Forenbeiträgen ist der zwischenzeitliche RESET des Thermostats.
Eine letzte Sache ist noch geblieben:
templist mismatch
HM_6AD4E9_Clima: HM_6AD4E9_Clima not found in file ./tempList.cfg
HM_6AD5C4_Clima: HM_6AD5C4_Clima not found in file ./tempList.cfg
HM_6AD67E_Clima: HM_6AD67E_Clima not found in file ./tempList.cfg
Ggf. noch kurz eine Aussage zur Relevanz dieser Meldung des HM-configChecks!?
Noch einmal herzlichen Dank an Euch, bis zum nächsten Mal,
liebe Grüße
Tim
Hallo Tim,
geht normalerweise mit dem hmInfo Modul zu fixen:
Auszug aus der Doku:
tempList [filter][save|restore|verify] [<file>]
Diese Funktion ermöglicht die Verarbeitung von temporären Temperaturlisten für Thermostate. Die Listen können in Dateien abgelegt, mit den aktuellen Werten verglichen und an das Gerät gesendet werden.
save speichert die aktuellen tempList Werte des Systems in eine Datei.
Zu beachten ist, dass die aktuell in FHEM vorhandenen Werte benutzt werden. Der Benutzer muss selbst sicher stellen, dass diese mit den Werten im Gerät überein stimmen.
Der Befehl arbeitet nicht kummulativ. Alle evtl. vorher in der Datei vorhandenen Werte werden überschrieben.
Gruß Otto
Hallo Otto,
auch Dir herzlichen Dank für die Informationen!
Viele Grüße
Tim