Hallo liebe Leute,
ich versuche nach Anleitung einen opt. Fensterkontakt mit einem Heizkörperthermostat zu peeren: bei Fensteröffnung -> Temperaturabsenkung.
Beide Teile wurden vorher in FHEM gepairt, der Fensterkontakt funktioniert schon seit Monaten für eine Alarmanlage einwandfrei.
Frage: in den Anleitungen wurde bisher nie explizit der opt. Fensterkontakt erwähnt, nur der magnetische. Ist der optische dafür geeignet?
Das Absenken der Solltemperatur funktioniert auch MANCHMAL, dann sehr oft wieder nicht. Habe schon so ziemlich alles probiert, Peeren, getconfig mehrfach, Unpeeren, wieder neu Peeren.
Im RT sieht es ok aus:
Internals:
CFGFN ./FHEM/fhem_geraete.cfg
DEF 44E88103
NAME HT_Gaeste_WC_WindowRec
NR 150
NTFY_ORDER 50-HT_Gaeste_WC_WindowRec
STATE last:trigLast
TYPE CUL_HM
chanNo 03
device HT_Gaeste_WC
peerList Melder_Gaeste_WC,
Readings:
2016-01-30 14:59:41 R-sign off
2016-02-03 14:49:19 RegL_01. 08:00 00:00
2016-02-03 14:49:20 RegL_03.Melder_Gaeste_WC_chn-01 04:32 00:00
2016-02-03 14:49:20 RegL_07.Melder_Gaeste_WC_chn-01 05:18 00:00
2016-02-03 15:09:25 peerList Melder_Gaeste_WC,
2016-02-03 15:09:25 state unknown
Helper:
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Attributes:
group Heizkörperthermostat
model HM-CC-RT-DN
peerIDs 00000000,444CD201,
room Heizung
stateFormat last:trigLast
Aber im Fensterkontakt:
CFGFN ./FHEM/fhem_geraete.cfg
DEF 444CD2
IODev CUL_0
NAME Melder_Gaeste_WC
NR 373
NTFY_ORDER 50-Melder_Gaeste_WC
STATE closed
TYPE CUL_HM
Readings:
2016-02-03 15:09:25 Activity alive
2016-02-03 14:51:02 D-firmware 1.0
2016-02-03 14:51:02 D-serialNr MEQ1657962
2016-02-03 14:49:04 R-HT_Gaeste_WC_WindowRec-expectAES set_off
2016-02-03 14:49:04 R-HT_Gaeste_WC_WindowRec-peerNeedsBurst set_on
2016-02-03 14:50:38 battery ok
2016-02-03 14:50:38 contact closed (to broadcast)
2016-02-03 14:50:38 state closed
2016-02-03 14:50:38 trigger_cnt 223
Helper:
HM_CMDNR 1
mId 00C7
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +444CD2,00,00,00
prefIO
rxt 2
vccu
p:
444CD2
00
00
00
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf 00
qReqStat
Role:
chn 1
dev 1
Attributes:
IODev CUL_0
actCycle 000:50
actStatus alive
autoReadReg 4_reqStatus
devStateIcon open:10px-kreis-rot closed:10px-kreis-gruen
expert 2_full
firmware 1.0
group Fenster/Tür
model HM-SEC-SCo
peerIDs 00000000,
room Alarmanlage
serialNr MEQ1657962
subType threeStateSensor
sieht R-HT_Gaeste_WC_WindowRec-expectAES und
R-HT_Gaeste_WC_WindowRec-peerNeedsBurst verdächtig aus.
Ähnliche Probleme habe ich mit dem Wandthermostat in einem anderen Raum und dem dortigen Fensterkontakt: funktioniert ein paar Mal, danach Ende.
Der Rest (Temperaturregelung per FHEM usw.) läuft einwandfrei.
(Neueste FHEM-Version, Raspberry PI 2, CUL).
Vielen Dank!
Der Fensterkontakt ist noch nicht fertig. Nochmal Anlerntaste drücken damit die Daten übertragen werden.
Hallo Otto,
danke, das habe ich jetzt auch gemacht, aber es hat nichts gebracht. Beim Öffnen des Fensters kommt direkt nach dem Peeren vielleicht nach dem 2. oder 3. Mal eine Reaktion am HT. Dann erscheint das Fenstersymbol und die 12 °C werden angefahren. Beim Schließen klappt es dann auch nicht immer, ist zufällig. Nach einer Zeit lang reagiert der HT gar nicht mehr auf den Kontakt.
Zusatzinfo:
Um Hardwareprobleme auszuschließen: Das Gleiche habe ich in einem anderen Raum, hier ist ein Wandthermostat, der z. T. 2 HT steuert, alle Teile mit FHEM gepairt, dann erst Wandthermostat mit HTs gepeert. Normale Heizungsregelung klappt einwandfrei.
Nur wenn ich den dortigen Fensterkontakt mit dem Wandthermostat peere, habe ich den gleichen Effekt wie oben: im Wandthermostat steht der Fensterkontakt schön in der Peerlist, aber im Fensterkontakt stehen diese beiden komischen Readingseinträge:
2016-02-04 15:56:38 R-Wohnzimmerthermostat_WindowRec-expectAES set_off
2016-02-04 15:56:38 R-Wohnzimmerthermostat_WindowRec-peerNeedsBurst set_on
Über den Zustand "set_off" bzw. "set_on" kommen die Readings nicht hinweg, müssten die nicht irgendwann auf "on" oder "off" stehen?
Habe danach natürlich auch wieder ein getconfig an beiden Devices gemacht, keine Änderung.
Hier nochmal alles:
CFGFN ./FHEM/fhem_geraete.cfg
CUL_0_MSGCNT 61
CUL_0_RAWMSG A0ECEA01037B1BAF112340100000000::-59:CUL_0
CUL_0_RSSI -59
CUL_0_TIME 2016-02-04 16:03:10
DEF 37B1BA
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 61
NAME Melder_Wohnzimmer_links
NR 355
NTFY_ORDER 50-Melder_Wohnzimmer_links
STATE closed
TYPE CUL_HM
lastMsg No:CE - t:10 s:37B1BA d:F11234 0100000000
protCmdDel 6
protLastRcv 2016-02-04 16:03:10
protNack 1 last_at:2016-02-04 15:56:47
protSnd 15 last_at:2016-02-04 16:03:10
protState CMDs_done
rssi_at_CUL_0 max:-53.5 lst:-59 avg:-59.6 cnt:61 min:-65.5
Readings:
2016-02-04 16:03:09 Activity alive
2016-02-04 15:56:47 CommandAccepted no
2016-02-04 16:03:09 D-firmware 1.0
2016-02-04 16:03:09 D-serialNr MEQ0285779
2016-02-04 16:03:10 PairedTo 0x000000
2016-02-04 15:56:38 R-Wohnzimmerthermostat_WindowRec-expectAES set_off
2016-02-04 15:56:38 R-Wohnzimmerthermostat_WindowRec-peerNeedsBurst set_on
2016-01-31 16:09:02 R-cyclicInfoMsg on
2016-01-31 16:09:03 R-eventDlyTime 0 s
2016-01-31 16:09:02 R-pairCentral 0x000000
2016-01-31 16:09:02 R-sabotageMsg on
2016-01-31 16:09:03 R-sign on
2016-02-04 16:03:10 RegL_00. 02:00 09:01 0A:00 0B:00 0C:00 10:01 14:06 00:00
2016-02-04 16:03:10 RegL_01. 08:01 20:9C 21:00 30:06 00:00
2016-02-04 15:56:47 aesKeyNbr 00
2016-02-04 15:49:02 alive yes
2016-02-04 16:02:21 battery ok
2016-02-04 16:02:21 contact closed (to broadcast)
2016-02-04 15:49:02 recentStateType info
2016-02-04 15:49:02 sabotageError off
2016-02-04 16:02:21 state closed
2016-02-04 16:02:21 trigger_cnt 252
Helper:
HM_CMDNR 206
cSnd 01F1123437B1BA01040000000001,01F1123437B1BA0103
mId 00C7
peerIDsRaw ,00000000
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +37B1BA,00,00,00
nextSend 1454598190.73895
prefIO
rxt 2
vccu
p:
37B1BA
00
00
00
Mrssi:
mNo CE
Io:
CUL_0 -57
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO CUL_0
flg A
ts 1454598190.64297
ack:
HASH(0x20c0668)
CE8002F1123437B1BA00
Rssi:
At_cul_0:
avg -59.6065573770492
cnt 61
lst -59
max -53.5
min -65.5
Shadowreg:
RegL_04.Wohnzimmerthermostat_WindowRec 01:01
Attributes:
IODev CUL_0
actCycle 000:50
actStatus alive
autoReadReg 4_reqStatus
devStateIcon open:10px-kreis-rot closed:10px-kreis-gruen
expert 2_full
firmware 1.0
group Fenster/Tür
model HM-SEC-SCo
peerIDs 00000000,
room Alarmanlage
serialNr MEQ0285779
subType threeStateSensor
Wie schon gesagt, habe bereits auch ein "unset" und wieder neues "set" gemacht:
set Melder_Wohnzimmer_links peerChan 0 Wohnzimmerthermostat_WindowRec single set
(gefolgt von getconfig an beiden Devices)
sowie ein
set Melder_Wohnzimmer_links peerChan 0 Wohnzimmerthermostat_WindowRec single unset
(+ getconfig und anschließend wieder ein set).
Ich komme nicht weiter.
ohne pairing wird das alles nichts. siehe wiki pairen.
2016-02-04 16:03:10 PairedTo 0x000000
Tausend Dank, werde ich mir anschauen!
Habe im Pairing-Wiki und Foreneinträge nachgelesen. Bei mir ist irgendwie ein Mischmasch von 2 hmIDs in den Geräten:
meine FHEM-Installation ist schon 3 Jahre alt, habe aber immer die neueste FHEM-Version geupdatet.
Mir fällt auf, dass neuere Geräte - wie die Fensterkontakte und Thermostate - alle mit 0x000000 als FHEM-Zentrale gepairt sind (s. oben), ältere Geräte aber noch mit
"PairedTo 0xF11234". Das will ich jetzt aufräumen und eine neue hmID und alle Geräte neu pairen vergeben, aber das klappt nicht oder ich mache immer den gleichen Fehler.
Habe vor Erstellen der hmID mit bspw.
set Melder_Arbeitszimmer_Tuer regSet pairCentral FF0430
ein Gerät auf die neue hmID FF0430 gesetzt:
PairedTo
0x000000
R-pairCentral
set_0xFF0430
Der Set-Befehl kann aber trotz getconfig nicht abgearbeitet werden, ich sehe das Gerät immer noch, es müsste doch beim Schreiben der neuen Pairzentrale nicht mehr ansprechbar sein, oder?
Die Readings kommen auch noch alle durch, es ist so, als wäre nichts passiert :-\
Habe auch Werkseinstellung und ein neues Pairen mit neuer hmID und Neustart FHEM-Server versucht, kein Erfolg. Das Pairen greift nicht.
Hat noch einer eine Idee? Habe schon Kopfschmerzen..
Vielen Dank!
Wenn 000000in den pairen steht ist es nicht gepairt.
Manchmal kann man das pairing Register setzen, eher selten. Am besten man pairt ganz normal, dann wird das Register gesetzt. Sollte das device schon gepairt sein ist es am einfachsten, es zu resetten.
Wenn nicht gepairt ist funktioniert das getconfig nicht.
Danke, Martin!
Ich habe > 35 Geräte.
Leider funktioniert bei mir das Pairing jetzt bei keinem Gerät mehr. Meine CUL_0-Definition in fhem.cfg sieht so aus:
define CUL_0 CUL /dev/ttyACM0@9600 1234
attr CUL_0 hmId FF0430
attr CUL_0 rfmode HomeMatic
define hm HMinfo
attr hm room System
attr hm sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorErr:ok,error:none,uncertain:[no|yes],smoke_detect:none,cover:closed
attr hm sumStatus battery,sabotageError,powerError,motor
attr hm webCmd update:protoEvents short:rssi:peerXref:configCheck:models
Nach dem Rücksetzen z. B. eines Fensterkontakts auf Werkseinstellung (5 s Taster drücken -> rotes Blinken, nochmal 5 s Taster drücken) und starten des CUL_0-Pairings mit
set CUL_0 hmPairForSec 180 und dann Drücken des Fensterkontakttasters klappt das Pairing nicht. Der Fensterkontakt blinkt einfach orange weiter und hört dann irgendwann auf.
Bei einer LED-16-Display-Anzeige ebenfalls nicht: Werkseinstellung durch 5 s Drücken mittlerer Taster auf Rückseite, blinkt rot, danach nochmal 5 s Drücken, blinkt kurz rot, dann 1 s rot.
Anlernen: CUL in Anlernmodus, Drücken des Tasters für 5 s: blinkt rot, aber es kommt kein Grün.
Es wird immer mysteriöser, es sieht so aus, als wenn ich noch nicht mal mehr die Werkseinstellung hinbekomme.
Um ein Gerät neu zu pairen, muss ich aus der fhem.cfg doch nicht die zugehörigen Einträge entfernen, oder?
ZitatUm ein Gerät neu zu pairen, muss ich aus der fhem.cfg doch nicht die zugehörigen Einträge entfernen, oder?
nein.
wenn die geräte einen aes-key von dir bekommen haben, funktioniert reset nicht.
ansonnsten leere die cmd-queue mit clear msgEvents bevor du pairst. sniffe das pairen wie im wiki sniffen beschrieben, dann sieht man, was passiert.
Zitat von: frank am 05 Februar 2016, 09:37:25
wenn die geräte einen aes-key von dir bekommen haben, funktioniert reset nicht.
ansonnsten leere die cmd-queue mit clear msgEvents bevor du pairst. sniffe das pairen wie im wiki sniffen beschrieben, dann sieht man, was passiert.
Nein, habe noch nie einen AES-Key vergeben. clear MsgEvents probiere ich aus und dann sniffen.
Eine Frage vorweg: da ich eine neue hmId vergeben habe, warum kann ich denn noch alles sehen und bedienen?
Nach diesem Thread hier:
http://forum.fhem.de/index.php/topic,27444.15.html (http://forum.fhem.de/index.php/topic,27444.15.html)
müsste doch, sofort nachdem ich einen neue hmId vergeben habe, die Kommunikation zu den Geräten abbrechen, oder?
Es sieht so aus, als wenn der CUL die neue hmId noch gar nicht angenommen hat.
So sieht das Sniffen des Pairings aus, hmId ist FF3004 (alte hmId war F11234):
Melder_Arbeitszimmer_Tuer ist auf Werkseinstellung resetted worden (zumindest Versuch), dann Pairen mit CUL_0
Merkwürdig finde ich das "need Crypt::Rijndael to answer signing request with CUL".
2016.02.05 10:16:12.376 4: CUL_Parse: CUL_0 A 14 95 A270 A64793 F11234 00CF3027FA0000006209C41C -60
2016.02.05 10:16:13.079 4: CUL_Parse: CUL_0 A 14 95 A270 A64793 F11234 00CF3027FA0000006209C41C -60
2016.02.05 10:16:13.782 4: CUL_Parse: CUL_0 A 14 95 A270 A64793 F11234 00CF3027FA0000006209C41C -60
2016.02.05 10:16:23.649 4: CUL_Parse: CUL_0 A 0D 00 8610 37B1A6 000000 060100002B -52.5
2016.02.05 10:16:23.751 4: CUL_send: CUL_0As 09 02 A112 FF3004 37B1A6
2016.02.05 10:16:23.896 4: CUL_send: CUL_0As 0C 04 A011 FF3004 20F767 800202
2016.02.05 10:16:24.053 4: CUL_Parse: CUL_0 A 0A 04 8002 20F767 FF3004 806C -20
2016.02.05 10:16:24.502 4: CUL_Parse: CUL_0 A 0F 3C 8610 44E8FD 000000 0AACCA90640034 -48
2016.02.05 10:16:25.871 4: CUL_Parse: CUL_0 A 0C 01 8641 37B1A6 000000 0101002C -52
2016.02.05 10:16:25.972 4: CUL_send: CUL_0As 09 01 A112 FF3004 37B1A6
2016.02.05 10:16:26.135 4: CUL_send: CUL_0As 0C 05 A011 FF3004 20F767 800202
2016.02.05 10:16:26.291 4: CUL_Parse: CUL_0 A 0A 05 8002 20F767 FF3004 806C -20
2016.02.05 10:16:32.505 4: CUL_Parse: CUL_0 A 1A 02 8400 37B1A6 000000 1000C74D4551303238353735388081010124 -56
2016.02.05 10:16:32.606 4: CUL_send: CUL_0As 10 03 A001 FF3004 37B1A6 00050000000000
2016.02.05 10:16:32.805 4: CUL_Parse: CUL_0 A 11 03 A002 37B1A6 FF3004 04159F2B510A880025 -55.5
2016.02.05 10:16:32.809 1: CUL_HM Melder_Arbeitszimmer_Tuer need Crypt::Rijndael to answer signing request with CUL
2016.02.05 10:16:32.906 4: CUL_send: CUL_0As 0A 03 8002 FF3004 37B1A6 00
2016.02.05 10:16:32.918 4: CUL_send: CUL_0As 13 04 A001 FF3004 37B1A6 000802010AFF0B300C04
2016.02.05 10:16:38.715 4: CUL_Parse: CUL_0 A 14 ED 845E 370497 000000 80358B000000000008E3FE1D -59.5
Erster Erfolg!
Habe anhand des Logs libcrypt-rijndael-perl nachinstalliert.
Dann den Fensterkontakt noch mal auf Werkseinstellung, dann ein Pairing versucht, nach getconfig steht jetzt endlich:
Paired_to 0xFF0430 drin! (Die neue HM-ID)
Werde weitere Geräte neu pairen, melde mich wenn ok.
Danke vielmals! Ich hoffe, das war's.
Zitatmüsste doch, sofort nachdem ich einen neue hmId vergeben habe, die Kommunikation zu den Geräten abbrechen, oder?
würde ich so erwarten. eventuell hilft restart.
empfangen geht aber immer.
Hallo Frank und alle anderen,
habe mittlerweile einige der Geräte mit der neuen hmId gepairt, sieht alles prima aus. Dafür war jeweils - je nach Funkmodus - ein Rücksetzen auf Werkseinstellung notwendig.
Auch der opt. Fensterkontakt im Gäste-WC "schaltet" jetzt den Heizkörperthermostat bei offenem Fenster. Danke nochmal für den Hinweis auf das fehlende Pairing.
Im HT kommt jetzt auch
STATE
last:Melder_Gaeste_WC:closed
an, endlich!
Im Melder_Gaeste_WC steht jetzt auch richtigerweise:
RegL_04.HT_Gaeste_WC_WindowRec
01:80 00:00
Allerdings habe ich 2 Fragen.
1. Im Melder_Gaeste_WC kommen immer noch die beiden folgenden Readings vor, sind die ok, kann das mal jemand bestätigen?
R-HT_Gaeste_WC_WindowRec-expectAES
on
2016-02-08 18:10:22
R-HT_Gaeste_WC_WindowRec-peerNeedsBurst
off
Muss ich da was ändern? Ich habe R-sign auf off gestellt, benutze kein AES.
2. Das Pairing hatte bei mir ursprünglich die hmId 0xF11234, damit sind einige Geräte gepairt, dann gibt es einige Geräte, die sind anscheinen gar nicht gepairt (0x000000) und einige sind jetzt mit neuer hmId gepair (0xFF0430). Nun das Lustige: ich kann jetzt immer noch alle Geräte sehen und bedienen! Wie ist das möglich? Ich habe das Wiki mehrfach durchgelesen, danach kann das nicht sein, und Frank hat das ja auch erwartet.
Lediglich das Peeren setzt ein vorhandenes Pairing voraus.
Ich hatte Pairing immer als Anlernen an die Zentrale verstanden - mit der eindeutigen hmId, aber da ich mittlerweile 3 hmIds in den Geräte verstreut habe und ich alle bedienen kann, verstehe ich es nicht mehr.
Wer hat eine Erklärung?
Vielen Dank!
Wenn ein sco mit einem RT gepeert ist ohne AES sollte AES auf off stehen. Peerneedsburts muss an sein.
Wenn in den reedings die zentrale nicht angezeigt wird kann es daran liegen, dass kein getconfig gemacht wurde und die readings schlicht alt sind.
Wenn ein device nicht gepairt ist sind manche Kommandos dennoch möglich. Es hängt von device ab. Manches würde ich als bug der hmfw bezeichnen. Detailliert verfolge ich das nicht.
Versuche ein getconfig zu machen. Pairen wo es immer noch nicht gemacht ist. Sichere und lade die Registerreadings über hminfo archConfig loadConfig.
Danke für die Erklärung!
Gruß Friedhelm