Hallo zusammen,
ich verzweifele an der Inbetriebnahme meiner Homematic-Komponenten mit FHEM. Ich habe seit einiger Zeit einige Heizkörper-Thermostate HM-CC-RT-DN sowie einen Jalouise-Aktor von Homematic. Nun habe ich endlich mal die Zeit gefunden, die Komponenten in Betrieb zu nehmen. Meine Vorkenntnisse sind minimal. Wie es aussieht, bekomme ich weder Thermostate noch Jalousieaktor angelernt.
Über die Suche konnte ich leider keinen Thread finden, der zu einer Lösung des Problems führte.
Folgende Schritte habe ich durchgeführt:
- CULV3 am PC mit FLIP geflasht (erfolgreich wie ich glaube, er blinkt zumindest im Sekundentakt am Pi)
- Raspbian Jessie Lite vom 26.2.2016 auf die Micro-SD Karte geflasht, Dateisystem expandiert
- FHEM mittels apt-get installiert (Version 5.7)
- Rechte für den CUL gesetzt (sudo usermod -a -G tty pi && sudo usermod -a -G tty fhem)
- Rechte für den FHEM Ordner gesetzt (cd /opt && sudo chmod -R a+w fhem)
- Über die FHEM Oberfläche den CUL in den Homematic Modus versetzt (attr CUL_0 rfmode HomeMatic)
- Werksreset am Heizkörperthermostat durchgeführt
- Am Heizkörperthermostat den Anlernknopf gedrückt, 30 s zählen runter
- Über den Befehl set CUL_0 hmPairSerial LEQ0786217 den Thermostat gepaired
Der Countdown am Thermostat zählt runter auf Null --> komisch
Wenn ich den pairing Vorgang wiederhole, zählt er wieder runter. Auch bei Benutzung von hmPairForSec.
Ich bekomme den Thermostat angezeigt, jedoch nach getConfig Fehlermeldungen wie NACK, Commands pending für lange Zeit, Missing Ack, etc. Ich denke, dass der Pairing-Prozess nicht erfolgreich ist.
Folgende Logs bekomme ich:
2016.03.06 09:40:28 1: Including fhem.cfg
2016.03.06 09:40:28 3: telnetPort: port 7072 opened
2016.03.06 09:40:29 3: WEB: port 8083 opened
2016.03.06 09:40:29 3: WEBphone: port 8084 opened
2016.03.06 09:40:29 3: WEBtablet: port 8085 opened
2016.03.06 09:40:29 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2016.03.06 09:40:29 1: usb create starting
2016.03.06 09:40:30 3: Probing CUL device /dev/ttyACM0
2016.03.06 09:40:30 1: define CUL_0 CUL /dev/ttyACM0@9600 1034
2016.03.06 09:40:30 3: Opening CUL_0 device /dev/ttyACM0
2016.03.06 09:40:30 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.03.06 09:40:30 3: CUL_0 device opened
2016.03.06 09:40:30 3: CUL_0: Possible commands: BbCFiAZNkGMKUYRTVWXefmLltux
2016.03.06 09:40:30 3: Probing CUL device /dev/ttyAMA0
2016.03.06 09:40:30 3: Can't open /dev/ttyAMA0: Permission denied
2016.03.06 09:40:30 1: usb create end
2016.03.06 09:40:30 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.03.06 09:40:30 0: Featurelevel: 5.7
2016.03.06 09:40:30 0: Server started with 10 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 3172)
2016.03.06 09:43:09 2: Switched CUL_0 rfmode to HomeMatic
2016.03.06 09:43:40 3: CUL_0: Unknown code A0FC0861022B6660000000AA4DD8C041E::-77.5:CUL_0, help me!
2016.03.06 09:46:09 3: CUL_0: Unknown code A0FC1861022B6660000000AA4DD8C031E::-80:CUL_0, help me!
2016.03.06 09:46:31 2: CUL_HM Unknown device HM_2F01C2 is now defined
2016.03.06 09:46:31 2: autocreate: define HM_2F01C2 CUL_HM 2F01C2
2016.03.06 09:46:31 2: autocreate: define FileLog_HM_2F01C2 FileLog ./log/HM_2F01C2-%Y.log HM_2F01C2
2016.03.06 09:46:31 3: Device HM_2F01C2 added to ActionDetector with 000:10 time
2016.03.06 09:46:36 3: Device HM_2F01C2 added to ActionDetector with 000:10 time
2016.03.06 09:48:24 3: CUL_0: Unknown code A0FC2861022B6660000000AA4DE8C011E::-78:CUL_0, help me!
2016.03.06 09:50:25 3: CUL_0: Unknown code A0FC3861022B6660000000AA4DF8C001E::-81:CUL_0, help me!
2016.03.06 09:53:01 3: CUL_HM set HM_2F01C2 getConfig
2016.03.06 09:53:01 3: CUL_HM set HM_2F01C2 getConfig
2016.03.06 09:53:16 3: CUL_0: Unknown code A0FC4861022B6660000000AA4DF8C001E::-81:CUL_0, help me!
CFGFN
CMDS BbCFiAZNkGMKUYRTVWXefmLltux
CUL_0_MSGCNT 8
CUL_0_TIME 2016-03-06 09:53:16
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
DEF /dev/ttyACM0@9600 1034
DeviceName /dev/ttyACM0@9600
FD 5
FHTID 1034
HM_CMDNR 2
NAME CUL_0
NR 20
PARTIAL
RAWMSG A0FC4861022B6660000000AA4DF8C001EF2
RSSI -81
STATE Initialized
TYPE CUL
VERSION V 1.65 CUL868
hmPairSerial LEQ0786217
initString X21 Ar
Internals
CFGFN
CUL_0_MSGCNT 3
CUL_0_RAWMSG A1A0184002F01C20000001400954C4551303738363231375900FFFF::-60:CUL_0
CUL_0_RSSI -60
CUL_0_TIME 2016-03-06 09:51:44
DEF 2F01C2
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 3
NAME HM_2F01C2
NR 40
NTFY_ORDER 50-HM_2F01C2
STATE CMDs_pending
TYPE CUL_HM
channel_01 HM_2F01C2_Weather
channel_02 HM_2F01C2_Climate
channel_03 HM_2F01C2_WindowRec
channel_04 HM_2F01C2_Clima
channel_05 HM_2F01C2_ClimaTeam
channel_06 HM_2F01C2_remote
lastMsg No:01 - t:00 s:2F01C2 d:000000 1400954C4551303738363231375900FFFF
protCmdPend 28 CMDs_pending
protLastRcv 2016-03-06 09:51:44
protState CMDs_pending
rssi_at_CUL_0 min:-65 max:-59.5 cnt:3 avg:-61.5 lst:-60
Ich hoffe, meine Problembeschreibung ist vollständig und nachvollziehbar.
Eine mangelnde Stromversorgung des RPi kann ich ausschließen, das Netzteil hat 2100 mA.
Ich hatte vor einiger Zeit, kurz nach dem Kauf einmal quick & dirty den CUL mit einem Thermostat in Betrieb genommen. Ich meine, das pairing hätte damals problemlos funktioniert und ich konnte den einen Test-Thermostat steuern.
Welchen Fehler könnte ich gemacht haben? Kann es sein, dass es ein Phänomen der aktuellen Raspbian oder FHEM Version ist?
Vielen Dank für Eure Hilfe
Hans-Georg
moin, meiner Meinung nach, musst du in dem Device auf set getConfig gehen
und noch mal den Anlernkonopf drücken dann wird er auch gepairt
gruß
Danke für den Tipp.
Ich habe es ausprobiert, in beiden Reihenfolgen (erst getConfig oder erst den Anlernmodus aktiviert). Beide Male zählt der Countdown runter auf 0 ohne wirkliches Ergebnis. Der einzige Unterschied ist, dass mittlerweile 126 CMDs_pending angesammelt sind.
Grüße
Hans-Georg
ZitatÜber den Befehl set CUL_0 hmPairSerial LEQ0786217 den Thermostat gepaired
es funktioniert nur hmPairForSec mit batterie devices.
Danke, ich habe mit PairForSec probiert. Das Verhalten ist ganz komisch. Ich habe erst den besagten RT versucht zu Pairen. Ohne Erfolg. Der Countdown zählte immer auf 0 runter ohne Ergebnis. Dann habe ich spaßeshalber mal einen anderen RT probiert, als FHEM noch im PairForSec Modus war. Der RT hat sofort auf dem Display mit AC bestätigt. Dann habe ich den ersten wieder probiert. Der hat dann auch sofort mit AC bestätigt.
Ich bin mir nicht ganz sicher, ob beide Geräte korrekt angelernt wurden. Der RT, der am Anfang nicht zu motivieren war, scheint ok:
Readings
Activity alive 2016-03-06 10:59:43
CommandAccepted yes 2016-03-06 11:05:11
D-firmware 1.4 2016-03-06 10:59:43
D-serialNr LEQ0786217 2016-03-06 10:59:43
PairedTo 0xF11034 2016-03-06 11:05:12
R-backOnTime 10 s 2016-03-06 11:02:19
R-burstRx on 2016-03-06 11:02:19
R-cyclicInfoMsg on 2016-03-06 11:02:19
R-cyclicInfoMsgDis 0 2016-03-06 11:02:19
R-pairCentral 0xF11034 2016-03-06 11:02:19
RegL_00: 01:01 02:01 09:01 0A:F1 0B:10 0C:34 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00 2016-03-06 11:05:12
RegL_07:
actuator 1 2016-03-06 11:05:11
batteryLevel 2.9 2016-03-06 11:05:11
controlMode auto 2016-03-06 10:59:33
desired-temp 21.0 2016-03-06 11:05:11
measured-temp 22.9 2016-03-06 11:05:11
motorErr ok 2016-03-06 11:05:11
state CMDs_done 2016-03-06 11:05:19
time-request - 2016-03-06 11:00:14
Der andere, der sofort AC bestätigt hat, eher nicht:
Readings
Activity dead 2016-03-06 11:09:43
CommandAccepted yes 2016-03-06 10:59:33
D-firmware 1.1 2016-03-06 10:59:25
D-serialNr KEQ0729069 2016-03-06 10:59:25
sabotageAttackId_ErrIoId_2F01C2 cnt:17 2016-03-06 10:59:30
state CMDs_pending 2016-03-06 11:03:35
Er hat eine ältere FW und die Meldung sabotageAttackId_ErrIoId_2F01C2 cnt:17 macht mich stutzig.
Danke und Gruß
Hans-Georg
ist der oben nicht das RT und unten ein Fensterkontakt ??
Zitatich habe mit PairForSec probiert.
es geht immer nur ein mal.
schau mal im wiki pairen, damit du ein erfolgreiches pairen erkennen kannst.
ansonnsten immer ein list <device> posten, damit alle infos vorhanden sind.
Zitat
ist der oben nicht das RT und unten ein Fensterkontakt ??
Ein Fensterkontakt befindet sich nicht in meinem Besitz, nominell sollten das die gleichen Gerätetypen sein, bis auf den FW Stand (1.1 vs. 1.4). In der Übersicht werden sie auch beide als thermostat angezeigt:
thermostat
HM_22BEE7 CMDs_pending
HM_2F01C2 CMDs_done
Der HM_22BEE7 bekommt seine CMDs_pending allerdings nicht abgebaut.
Ich habe einige Male versucht, ihn über PairForSec neu anzulernen, leider ohne Erfolg.
Die Ausgabe für das anscheinend noch nicht gepairte HM_22BEE7 sieht folgendermaßen aus:
Internals:
CFGFN
CUL_0_MSGCNT 28
CUL_0_RAWMSG A0A79A45922BEE72F01C2A8::-41.5:CUL_0
CUL_0_RSSI -41.5
CUL_0_TIME 2016-03-06 11:27:25
DEF 22BEE7
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 28
NAME HM_22BEE7
NR 119
NTFY_ORDER 50-HM_22BEE7
STATE CMDs_pending
TYPE CUL_HM
channel_01 HM_22BEE7_Weather
channel_02 HM_22BEE7_Climate
channel_03 HM_22BEE7_WindowRec
channel_04 HM_22BEE7_Clima
channel_05 HM_22BEE7_ClimaTeam
channel_06 HM_22BEE7_remote
lastMsg No:79 - t:59 s:22BEE7 d:2F01C2 A8
protCmdPend 27 CMDs pending
protErrIoId_2F01C2 17 last_at:2016-03-06 10:59:30
protLastRcv 2016-03-06 11:27:25
protResnd 1 last_at:2016-03-06 11:26:37
protSnd 1 last_at:2016-03-06 11:26:32
protState CMDs_pending
rssi_at_CUL_0 lst:-41.5 avg:-40.35 cnt:28 max:-38.5 min:-42.5
Readings:
2016-03-06 11:46:32 Activity dead
2016-03-06 10:59:33 CommandAccepted yes
2016-03-06 11:26:32 D-firmware 1.1
2016-03-06 11:26:32 D-serialNr KEQ0729069
2016-03-06 11:27:25 controlMode auto
2016-03-06 11:27:25 desired-temp 21.0
2016-03-06 10:59:30 sabotageAttackId_ErrIoId_2F01C2 cnt:17
2016-03-06 11:26:37 state CMDs_pending
Regl_00::
VAL
cmdStack:
++A001F1103422BEE700040000000000
++A001F1103422BEE70103
++A001F1103422BEE701040000000001
++A001F1103422BEE70203
++A001F1103422BEE702040000000001
++A001F1103422BEE70303
++A001F1103422BEE703040000000001
++A001F1103422BEE70403
++A001F1103422BEE704040000000001
++A001F1103422BEE700040000000007
++A001F1103422BEE70503
++A001F1103422BEE705040000000001
++A001F1103422BEE70603
++A001F1103422BEE706040000000001
++A001F1103422BEE700040000000000
++A001F1103422BEE70103
++A001F1103422BEE701040000000001
++A001F1103422BEE70203
++A001F1103422BEE702040000000001
++A001F1103422BEE70303
++A001F1103422BEE703040000000001
++A001F1103422BEE70403
++A001F1103422BEE704040000000001
++A001F1103422BEE700040000000007
++A001F1103422BEE70503
++A001F1103422BEE705040000000001
++A001F1103422BEE70603
++A001F1103422BEE706040000000001
Helper:
HM_CMDNR 121
cSnd ,01F1103422BEE700040000000000
mId 0095
rxType 140
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +22BEE7,02,00,00
nextSend 1457263645.47374
prefIO
rxt 2
vccu
p:
22BEE7
00
00
00
Mrssi:
mNo 79
Io:
CUL_0 -39.5
Prt:
bErr 0
sProc 2
sleeping 1
wuReSent 2
Q:
qReqConf
qReqStat
Role:
dev 1
prs 1
Rssi:
At_cul_0:
avg -40.3571428571429
cnt 28
lst -41.5
max -38.5
min -42.5
Shregw:
07 04
Attributes:
IODev CUL_0
actCycle 000:10
actStatus dead
autoReadReg 4_reqStatus
expert 2_full
firmware 1.1
model HM-CC-RT-DN
room CUL_HM
serialNr KEQ0729069
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
Nachtrag:
Unmittelbar nach meinem letzten Beitrag habe ich noch einmal PairForSec aufgerufen, nach dem einige Zeit vergangen ist. Anscheinend hat der zweite Thermostat danach erfolgreich gepaired. Ich bin allerdings etwas ratlos, warum.
Das Log lautet nun:
Internals:
CFGFN
CUL_0_MSGCNT 64
CUL_0_RAWMSG A0E1F801022BEE7F110340208000000::-40:CUL_0
CUL_0_RSSI -40
CUL_0_TIME 2016-03-06 11:58:12
DEF 22BEE7
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 64
NAME HM_22BEE7
NR 119
NTFY_ORDER 50-HM_22BEE7
STATE CMDs_done
TYPE CUL_HM
channel_01 HM_22BEE7_Weather
channel_02 HM_22BEE7_Climate
channel_03 HM_22BEE7_WindowRec
channel_04 HM_22BEE7_Clima
channel_05 HM_22BEE7_ClimaTeam
channel_06 HM_22BEE7_remote
lastMsg No:1F - t:10 s:22BEE7 d:F11034 0208000000
protErrIoId_2F01C2 17 last_at:2016-03-06 10:59:30
protLastRcv 2016-03-06 11:58:12
protResnd 1 last_at:2016-03-06 11:26:37
protSnd 35 last_at:2016-03-06 11:58:12
protState CMDs_done
rssi_at_CUL_0 max:-35.5 min:-42.5 lst:-40 avg:-40.15 cnt:64
Readings:
2016-03-06 11:57:06 Activity alive
2016-03-06 11:58:04 CommandAccepted yes
2016-03-06 11:57:06 D-firmware 1.1
2016-03-06 11:57:06 D-serialNr KEQ0729069
2016-03-06 11:58:05 PairedTo 0xF11034
2016-03-06 11:58:05 R-backOnTime 10 s
2016-03-06 11:58:05 R-burstRx on
2016-03-06 11:58:05 R-cyclicInfoMsg on
2016-03-06 11:58:05 R-cyclicInfoMsgDis 0
2016-03-06 11:58:05 R-pairCentral 0xF11034
2016-03-06 11:58:05 RegL_00: 01:01 02:01 09:01 0A:F1 0B:10 0C:34 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00
2016-03-06 11:58:04 actuator 0
2016-03-06 11:58:04 batteryLevel 2.8
2016-03-06 11:27:25 controlMode auto
2016-03-06 11:58:04 desired-temp 21.0
2016-03-06 11:58:04 measured-temp 23.0
2016-03-06 11:58:04 motorErr ok
2016-03-06 10:59:30 sabotageAttackId_ErrIoId_2F01C2 cnt:17
2016-03-06 11:58:12 state CMDs_done
2016-03-06 11:57:37 time-request -
Regl_07::
VAL
Helper:
HM_CMDNR 31
cSnd 01F1103422BEE70603,01F1103422BEE706040000000001
mId 0095
rxType 140
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +22BEE7,00,00,00
nextSend 1457265492.47734
prefIO
rxt 2
vccu
p:
22BEE7
00
00
00
Mrssi:
mNo 1F
Io:
CUL_0 -38
Prt:
bErr 0
sProc 0
try 1
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
prs 1
Rssi:
At_cul_0:
avg -40.15625
cnt 64
lst -40
max -35.5
min -42.5
Shregw:
07 04
Shadowreg:
Attributes:
IODev CUL_0
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 1.1
model HM-CC-RT-DN
room CUL_HM
serialNr KEQ0729069
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
Sieht in meinen Augen jetzt gut aus, vielen Dank. Ich bin nur etwas ratlos, warum es jetzt geht.
Danke für die Unterstützung, nach dem Mittag werde ich versuchen, ob Kommandos angenommen werden und mich danach meinem Jalousieaktor zuwenden.
Grüße
Hans-Georg
Hallo zusammen,
danke für die Unterstützung. Mittlerweile laufen die 5 Heizungsregler sowie der Jalousieaktor. Nachdem ich gestern den ganzen Tag daran verzweifelt war, ging es heute nahezu problemlos. Warum kann ich letztlich nicht sagen. Ich meine nicht, dass ich heute etwas grundsätzlich anders gemacht habe.
Einzige Auffälligkeit: Der Jalouisieaktor fährt immer in die selbe Richtung, egal ob ich ein up oder down Kommando gebe. Naja, um das Finetuning kümmere ich mich am Nachmittag.
Viele Grüße
Hans-Georg
wenn die cmd queue bereits voll ist, werden die "neuen" pairing cmds natürlich hinten angestellt. alle ca 3 min werden wahrscheinlich nur 1-2 cmds abgearbeitet, was dann sehr lange dauern kann.
bei pending cmds am besten die queue leeren, bevor ein neues cmd gesendet wird => clear msgEvents.