Aufgrund mehrfacher Schreibfehler auf meine SD-Karte bin ich vom PI auf einen CubieTruck umgezogen. Seitdem habe ich u.a. folgende Probleme (ausgerechnet zum Beginn der Heizperiode, der WAF ist ziemlich im Eimer).
Die Verbindung HM-Sec-RHS zu den HM-CC-RT-DN (2 x) funktioniert nicht mehr einwandfrei. Die ganzen letzten Monate zuvor hatte ich nie Probleme damit.
Generell leuchtet jetzt nach einer Betätigung des Drehgriffs die Led am HM-Sec-RHS rot (d.h.: mindestens ein Aktor hat den (letzten) bidirektionalen Befehl nicht bestätigt). FHEM erkennt den Zustand des HM-Sec-RHS immer richtig (Open, Closed oder Tilted), die Thermostate erkennen manchmal beide den jeweiligen Zustand, manchmal nur einer und hin und wieder keiner von beiden. Alle beteiligten Geräte (HM-Sec-RHS, HM-CC-RT-DN, HMLan) sind im gleichen Raum. Übertragungsprobleme schließe ich eigentlich aus, da in den vergangenen Monaten ja alles funktioniert hat (nach Betätigung des Drehgriffs war die Led immer grün, die Thermostate haben richtig reagiert).
Eine Übersicht über die RSSI-Werte habe ich dennoch gezogen:
rssi done:
Device :receive from last avg min<max count
Wz.Fenster_Drehgriff:HMLAN1 Wz.Fenster_Drehgriff -68.0 -71.1 -77.0< -68.0 11
Wz.Thermostat_Essecke:HMLAN1 Wz.Thermostat_Essecke -57.0 -56.6 -68.0< -51.0 612
Wz.Thermostat_Essecke:Wz.Thermostat_Essecke HMLAN1 -52.0 -52.0 -52.0< -52.0 2
Wz.Thermostat_TV:HMLAN1 Wz.Thermostat_TV -52.0 -51.7 -56.0< -51.0 607
Wz.Thermostat_TV:Wz.Thermostat_TV HMLAN1 -47.0 -47.0 -47.0< -47.0 1
Ich habe schon das Peering und Pairing zurückgesetzt und den HM-Sec-RHS komplett neu eingerichtet mit folgendem Ablauf:
set Wz.Fenster_Drehgriff peerChan 0 Wz.Thermostat_Essecke_WindowRec single unset
# Drücken der Anlerntaste
set Wz.Fenster_Drehgriff peerChan 0 Wz.Thermostat_TV_WindowRec single unset
# Drücken der Anlerntaste
# Save config - rereadcfg
# HM-Sec-RHS Funk-Fenster-Drehgriffkontakt auf Auslieferungszustand zurückgesetzt
# Anlerntaste > 5 sek (blinkt langsam rot)
# Anlerntaste > 5 sek (blinkt schneller rot)
# Pairing lösen
set Wz.Fenster_Drehgriff unpair
# Neustart
set HMLAN1 hmPairSerial KEQ0550478
# am HM-Sec-RHS Anlernmodus gedrückt
# Zustandsänderung mit einer Verzögerung (3 Sekunden) senden (zur Vermeidung von Kommunikationsproblemen)
set Wz.Fenster_Drehgriff regSet eventDlyTime 3
# Anlerntaste am Sensor drücken
set Wz.Fenster_Drehgriff getConfig
# Anlerntaste am Sensor drücken
# Regelmäßige Batteriemeldung
set Wz.Fenster_Drehgriff regSet cyclicInfoMsg on
# Anlerntaste am Sensor zu drücken
# Kontrolle:
set Wz.Fenster_Drehgriff getConfig
# Anlerntaste am Sensor zu drücken
# Register R-cyclicInfoMsg steht auf "on". Ab jetzt kommt regelmäßig eine Batteriemeldung, wenn der Drehgriff etwa 24 Stunden lang nicht betätigt wurde
# Die interne Fernster auf Erkennung an den Thermostaten wie folgt abschalten:
set Wz.Thermostat_Essecke_Clima regSet winOpnMode off
set Wz.Thermostat_TV_Clima regSet winOpnMode off
# warten, bis CMD_pending gewechselt auf CMDs_done
# Den Fensterschalter mit dem Heizungsventil HM-CC-RT-DN peeren. Das läuft über Kanal 03 WindowRec mit:
set Wz.Fenster_Drehgriff peerChan 0 Wz.Thermostat_Essecke_WindowRec single
# Anlerntaste am Drehgriff-Sensor drücken
set Wz.Fenster_Drehgriff peerChan 0 Wz.Thermostat_TV_WindowRec single
# Anlerntaste am Drehgriff-Sensor zu drücken
# Kontrollieren am Kanal 3, ob Schalter gepeert ist, anschließend
set Wz.Thermostat_Essecke_WindowRec regSet winOpnTemp 16 Wz.Fenster_Drehgriff
set Wz.Thermostat_TV_WindowRec regSet winOpnTemp 16 Wz.Fenster_Drehgriff
Save Config
Rereadcfg
Ein Listing der Geräte bzw. Kanäle (Wz.Fenster_Drehgriff, Wz.Thermostat_Essecke_WindowRec und Wz.Thermostat_TV_WindowRec) zeigt folgenden:
Internals:
DEF 21E7DC
HMLAN1_MSGCNT 8
HMLAN1_RAWMSG E21E7DC,0000,06BA459E,FF,FFBA,20A04121E7DC22EC4D011300
HMLAN1_RSSI -70
HMLAN1_TIME 2014-10-03 18:01:47
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 8
NAME Wz.Fenster_Drehgriff
NR 50
STATE closed
TYPE CUL_HM
lastMsg No:20 - t:41 s:21E7DC d:22EC4D 011300
peerList Wz.Thermostat_Essecke_WindowRec,Wz.Thermostat_TV_WindowRec,
protLastRcv 2014-10-03 18:01:47
protSnd 4 last_at:2014-10-03 18:01:46
protState CMDs_done
rssi_at_HMLAN1 avg:-72.25 min:-77 max:-70 lst:-70 cnt:8
Readings:
2014-10-03 08:46:19 Activity alive
2014-10-02 11:06:13 CommandAccepted yes
2014-10-02 11:06:11 D-firmware 2.1
2014-10-02 11:06:11 D-serialNr KEQ0550478
2014-10-02 11:06:13 PairedTo 0x272E57
2014-10-02 11:05:22 R-Wz.Thermostat_Essecke_WindowRec-expectAES off
2014-10-02 11:05:22 R-Wz.Thermostat_Essecke_WindowRec-peerNeedsBurst on
2014-10-02 11:06:15 R-Wz.Thermostat_TV_WindowRec-expectAES off
2014-10-02 11:06:15 R-Wz.Thermostat_TV_WindowRec-peerNeedsBurst on
2014-10-02 10:53:12 R-cyclicInfoMsg on
2014-10-02 10:46:23 R-eventDlyTime 3 s
2014-10-02 10:45:10 R-ledOnTime 0.5 s
2014-10-02 10:45:10 R-msgRhsPosA closed
2014-10-02 10:45:10 R-msgRhsPosB open
2014-10-02 10:45:10 R-msgRhsPosC tilted
2014-10-02 10:49:23 R-pairCentral 0x272E57
2014-10-02 10:45:10 R-sign off
2014-10-02 10:45:10 R-transmDevTryMax 6
2014-10-02 10:45:10 R-transmitTryMax 6
2014-10-02 11:06:13 RegL_00: 02:01 09:01 0A:27 0B:2E 0C:57 10:01 14:06 00:00
2014-10-02 11:06:13 RegL_01: 08:00 20:6C 21:03 22:64 30:06 00:00
2014-10-02 11:06:14 RegL_04:Wz.Thermostat_Essecke_WindowRec 01:01 00:00
2014-10-02 11:06:15 RegL_04:Wz.Thermostat_TV_WindowRec 01:01 00:00
2014-10-02 11:11:44 alive yes
2014-10-03 18:01:47 battery ok
2014-10-03 18:01:47 contact closed (to Wz.Thermostat_TV)
2014-10-02 11:11:44 cover closed
2014-10-03 08:46:19 peerList Wz.Thermostat_Essecke_WindowRec,Wz.Thermostat_TV_WindowRec,
2014-10-02 11:11:44 recentStateType info
2014-10-03 18:01:47 state closed
Helper:
mId 0030
rxType 4
Io:
newChn +21E7DC,00,01,FE1F
nextSend 1412352107.17952
prefIO
rxt 0
vccu
p:
21E7DC
00
01
FE1F
Mrssi:
mNo 20
Io:
HMLAN1 -68
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmlan1:
avg -72.25
cnt 8
lst -70
max -70
min -77
Attributes:
IODev HMLAN1
actCycle 028:00
actStatus alive
autoReadReg 4
expert 2_full
firmware 2.1
model HM-SEC-RHS
peerIDs 00000000,22DE8003,22EC4D03,
room Wohnzimmer
serialNr KEQ0550478
subType threeStateSensor
Internals:
DEF 22DE8003
NAME Wz.Thermostat_Essecke_WindowRec
NR 28
STATE last:Wz.Fenster_Drehgriff :open
TYPE CUL_HM
chanNo 03
device Wz.Thermostat_Essecke
peerList Wz.Fenster_Drehgriff,
Readings:
2014-10-02 11:09:20 R-Wz.Fenster_Drehgriff_chn-01-shCtValLo 50
2014-10-02 11:09:20 R-Wz.Fenster_Drehgriff_chn-01-winOpnTemp 16 C
2014-10-02 11:07:17 R-sign off
2014-10-02 11:09:19 RegL_01: 08:00 00:00
2014-10-02 11:09:20 RegL_03:Wz.Fenster_Drehgriff_chn:01 04:32 00:00
2014-10-02 11:09:20 RegL_07:Wz.Fenster_Drehgriff_chn:01 05:20 00:00
2014-10-03 08:46:19 peerList Wz.Fenster_Drehgriff,
2014-10-02 10:32:10 state unpeered
2014-10-02 11:12:08 trigLast Wz.Fenster_Drehgriff :open
2014-10-02 11:12:08 trig_Wz.Fenster_Drehgriff open
Helper:
Role:
chn 1
Attributes:
model HM-CC-RT-DN
peerIDs 00000000,21E7DC01,
stateFormat last:trigLast
Internals:
DEF 22EC4D03
NAME Wz.Thermostat_TV_WindowRec
NR 37
STATE last:Wz.Fenster_Drehgriff :closed
TYPE CUL_HM
chanNo 03
device Wz.Thermostat_TV
peerList Wz.Fenster_Drehgriff,
Readings:
2014-10-02 11:11:01 R-Wz.Fenster_Drehgriff_chn-01-shCtValLo 50
2014-10-02 11:11:01 R-Wz.Fenster_Drehgriff_chn-01-winOpnTemp 16 C
2014-10-02 11:06:20 R-sign off
2014-10-02 11:11:00 RegL_01: 08:00 00:00
2014-10-02 11:11:01 RegL_03:Wz.Fenster_Drehgriff_chn:01 04:32 00:00
2014-10-02 11:11:01 RegL_07:Wz.Fenster_Drehgriff_chn:01 05:20 00:00
2014-10-03 08:46:19 peerList Wz.Fenster_Drehgriff,
2014-10-02 10:32:10 state unpeered
2014-10-03 18:01:47 trigLast Wz.Fenster_Drehgriff :closed
2014-10-03 18:01:47 trig_Wz.Fenster_Drehgriff closed
Helper:
Role:
chn 1
Attributes:
model HM-CC-RT-DN
peerIDs 00000000,21E7DC01,
stateFormat last:trigLast
set hm peerCheck bzw. set hm configCheck zeigt keine Hinweise/Fehler (zu diesen Geräten), im allgemeinem Log sehe ich nichts ungewöhnliches.
Im Log des HM-Sec-RHS sehe ich Ungereimtheiten:
2014-10-02_11:12:04 Wz.Fenster_Drehgriff battery: ok
2014-10-02_11:12:04 Wz.Fenster_Drehgriff open
2014-10-02_11:12:04 Wz.Fenster_Drehgriff contact: open (to HMLAN1)
2014-10-02_11:12:06 Wz.Fenster_Drehgriff battery: ok
2014-10-02_11:12:06 Wz.Fenster_Drehgriff open
2014-10-02_11:12:06 Wz.Fenster_Drehgriff contact: open (to Wz.Thermostat_TV)
2014-10-02_11:12:08 Wz.Fenster_Drehgriff battery: ok
2014-10-02_11:12:08 Wz.Fenster_Drehgriff open
2014-10-02_11:12:08 Wz.Fenster_Drehgriff contact: open (to Wz.Thermostat_Essecke)
2014-10-02_11:38:26 Wz.Fenster_Drehgriff battery: ok
2014-10-02_11:38:26 Wz.Fenster_Drehgriff closed
2014-10-02_11:38:26 Wz.Fenster_Drehgriff contact: closed (to HMLAN1)
2014-10-02_11:38:27 Wz.Fenster_Drehgriff battery: ok
2014-10-02_11:38:27 Wz.Fenster_Drehgriff closed
2014-10-02_11:38:27 Wz.Fenster_Drehgriff contact: closed (to Wz.Thermostat_TV)
2014-10-02_20:44:24 Wz.Fenster_Drehgriff Activity: alive
2014-10-03_08:46:19 Wz.Fenster_Drehgriff Activity: alive
2014-10-03_09:42:01 Wz.Fenster_Drehgriff battery: ok
2014-10-03_09:42:01 Wz.Fenster_Drehgriff open
2014-10-03_09:42:01 Wz.Fenster_Drehgriff contact: open (to HMLAN1)
2014-10-03_09:42:02 Wz.Fenster_Drehgriff battery: ok
2014-10-03_09:42:02 Wz.Fenster_Drehgriff open
2014-10-03_09:42:02 Wz.Fenster_Drehgriff contact: open (to Wz.Thermostat_TV)
2014-10-03_09:44:17 Wz.Fenster_Drehgriff battery: ok
2014-10-03_09:44:17 Wz.Fenster_Drehgriff closed
2014-10-03_09:44:17 Wz.Fenster_Drehgriff contact: closed (to HMLAN1)
2014-10-03_09:44:17 Wz.Fenster_Drehgriff battery: ok
2014-10-03_09:44:17 Wz.Fenster_Drehgriff closed
2014-10-03_09:44:17 Wz.Fenster_Drehgriff contact: closed (to Wz.Thermostat_TV)
2014-10-03_16:42:30 Wz.Fenster_Drehgriff battery: ok
2014-10-03_16:42:30 Wz.Fenster_Drehgriff open
2014-10-03_16:42:30 Wz.Fenster_Drehgriff contact: open (to HMLAN1)
2014-10-03_16:42:31 Wz.Fenster_Drehgriff battery: ok
2014-10-03_16:42:31 Wz.Fenster_Drehgriff open
2014-10-03_16:42:31 Wz.Fenster_Drehgriff contact: open (to Wz.Thermostat_TV)
2014-10-03_18:01:46 Wz.Fenster_Drehgriff battery: ok
2014-10-03_18:01:46 Wz.Fenster_Drehgriff closed
2014-10-03_18:01:46 Wz.Fenster_Drehgriff contact: closed (to HMLAN1)
2014-10-03_18:01:47 Wz.Fenster_Drehgriff battery: ok
2014-10-03_18:01:47 Wz.Fenster_Drehgriff closed
2014-10-03_18:01:47 Wz.Fenster_Drehgriff contact: closed (to Wz.Thermostat_TV)
Wz.Thermostat_TV scheint lt. Log das Schalten immer mit zu bekommen, der Wz.Thermostat_Essecke dagegen nicht. Die Symbole auf den Thermostaten sagen aber das Gegenteil (Wz.Thermostat_Essecke zeigt das Fenster-offen-Symbol, der Wz.Thermostat_TV dagegen nicht). Und nein: die Namen der Thermostate sind nicht vertauscht. Ich habe sie daraufhin extra noch einmal kontrolliert .
Ich hoffe, es kann mir einer helfen.
ZitatIm Log des HM-Sec-RHS sehe ich Ungereimtheiten:
ZitatWz.Thermostat_TV scheint lt. Log das Schalten immer mit zu bekommen, der Wz.Thermostat_Essecke dagegen nicht.
es ist eher so, dass der fensterkontakt nicht immer an alle teilnehmer sendet (to HMLAN1, to Wz.Thermostat_TV, to Wz.Thermostat_Essecke). daher sind die anzeigen an den thermostaten wohl ok.
2014-10-02_11:12:08 Wz.Fenster_Drehgriff contact: open (to Wz.Thermostat_Essecke)das war die letzte message vom fk an diesen thermostaten. vielleicht hat der fk den peer "verloren". mach doch mal einen neuen getconfig vom fk. und poste dann nochmal ein list.
gruss frank
Danke für die Unterstützung.
Folgendes habe ich gemacht (bin mit den Begrifflichkeiten noch nicht immer ganz sicher, daher schreibe ich lieber komplett auf, was ich gemacht habe)
set Wz.Fenster_Drehgriff getConfig
# Anlerntaste: Anzeige am FK: kurz Orange, dann etwas länger Grün
list Wz.Fenster_Drehgriff
mit diesem Ergebnis. Die Peers scheinen mir noch korrekt zu sein.
Internals:
DEF 21E7DC
HMLAN1_MSGCNT 43
HMLAN1_RAWMSG RDAB252BC,0001,0AADDE90,FF,FFBC,BDA01021E7DC272E570201010000
HMLAN1_RSSI -68
HMLAN1_TIME 2014-10-04 12:26:32
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 43
NAME Wz.Fenster_Drehgriff
NR 50
STATE closed
TYPE CUL_HM
lastMsg No:BD - t:10 s:21E7DC d:272E57 0201010000
peerList Wz.Thermostat_Essecke_WindowRec,Wz.Thermostat_TV_WindowRec,
protCmdDel 3
protLastRcv 2014-10-04 12:26:32
protResndFail 1 last_at:2014-10-04 12:20:27
protSnd 30 last_at:2014-10-04 12:26:32
protState CMDs_done
rssi_at_HMLAN1 avg:-68.83 min:-77 max:-60 lst:-68 cnt:43
Readings:
2014-10-04 12:26:30 Activity alive
2014-10-02 11:06:13 CommandAccepted yes
2014-10-04 12:26:30 D-firmware 2.1
2014-10-04 12:26:30 D-serialNr KEQ0550478
2014-10-04 12:26:30 PairedTo 0x272E57
2014-10-04 12:21:49 R-Wz.Thermostat_Essecke_WindowRec-expectAES off
2014-10-04 12:21:49 R-Wz.Thermostat_Essecke_WindowRec-peerNeedsBurst on
2014-10-04 12:21:49 R-Wz.Thermostat_TV_WindowRec-expectAES off
2014-10-04 12:21:49 R-Wz.Thermostat_TV_WindowRec-peerNeedsBurst on
2014-10-04 12:21:47 R-cyclicInfoMsg on
2014-10-02 10:46:23 R-eventDlyTime 3 s
2014-10-02 10:45:10 R-ledOnTime 0.5 s
2014-10-04 12:21:48 R-msgRhsPosA closed
2014-10-04 12:21:48 R-msgRhsPosB open
2014-10-04 12:21:48 R-msgRhsPosC tilted
2014-10-04 12:21:47 R-pairCentral 0x272E57
2014-10-04 12:21:48 R-sign off
2014-10-04 12:21:47 R-transmDevTryMax 6
2014-10-04 12:21:48 R-transmitTryMax 6
2014-10-04 12:26:30 RegL_00: 02:01 09:01 0A:27 0B:2E 0C:57 10:01 14:06 00:00
2014-10-04 12:26:31 RegL_01: 08:00 20:6C 21:03 22:64 30:06 00:00
2014-10-04 12:26:32 RegL_04:Wz.Thermostat_Essecke_WindowRec 01:01 00:00
2014-10-04 12:26:32 RegL_04:Wz.Thermostat_TV_WindowRec 01:01 00:00
2014-10-04 12:20:21 alive yes
2014-10-04 12:25:48 battery ok
2014-10-04 12:25:48 contact closed (to Wz.Thermostat_TV)
2014-10-04 12:20:21 cover open
2014-10-04 12:26:31 peerList Wz.Thermostat_Essecke_WindowRec,Wz.Thermostat_TV_WindowRec,
2014-10-04 12:20:21 recentStateType info
2014-10-04 12:25:48 state closed
Helper:
cSnd 01272E5721E7DC010422EC4D0304
mId 0030
peerIDsRaw ,22DE8003,22EC4D03,00000000
rxType 4
Io:
newChn +21E7DC,00,01,FE1F
nextSend 1412418392.83135
prefIO
rxt 0
vccu
p:
21E7DC
00
01
FE1F
Mrssi:
mNo BD
Io:
HMLAN1 -66
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMLAN1
flg A
ts 1412418392.75233
ack:
HASH(0x2b417d0)
BD8002272E5721E7DC00
Rssi:
At_hmlan1:
avg -68.8372093023256
cnt 43
lst -68
max -60
min -77
Shadowreg:
Attributes:
IODev HMLAN1
actCycle 028:00
actStatus alive
autoReadReg 4
expert 2_full
firmware 2.1
model HM-SEC-RHS
peerIDs 00000000,22DE8003,22EC4D03,
room Wohnzimmer
serialNr KEQ0550478
subType threeStateSensor
Die Fehlermeldung ,,protResndFail 1 last_at:2014-10-04 12:20:27" habe ich vermutlich verursacht durch zu spätes Drücken der Anlerntaste.
Ich habe dann den kompletten Vorgang wiederholt mit diesem Ergebnis.
Holger
sieht für mich korrekt aus.
jetzt könntest du nochmal am esszimmer-thermostat ein aktuelles getconfig am device (channel0) machen und list vom device und winrec_channel posten. wenn da nichts zu sehen ist, mal rawmessages loggen http://forum.fhem.de/index.php/topic,16563.0.html (http://forum.fhem.de/index.php/topic,16563.0.html), wenn das fenster betätigt wird. mehrmals auf/zu, aber nicht zu schnell hintereinander.
Folgendes habe ich jetzt gemacht:
set Wz.Thermostat_Essecke getConfig
Ich habe gewartet, bis der Status wieder auf CMDs_done stand.
Danach ein list Wz.Thermostat_Essecke
Internals:
DEF 22DE80
HMLAN1_MSGCNT 859
HMLAN1_RAWMSG RDBE4931C,0001,0100E71F,FF,FFC8,51801022DE80272E570205200000
HMLAN1_RSSI -56
HMLAN1_TIME 2014-10-04 18:01:03
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 859
NAME Wz.Thermostat_Essecke
NR 24
STATE CMDs_done
TYPE CUL_HM
channel_01 Wz.Thermostat_Essecke_Weather
channel_02 Wz.Thermostat_Essecke_Climate
channel_03 Wz.Thermostat_Essecke_WindowRec
channel_04 Wz.Thermostat_Essecke_Clima
channel_05 Wz.Thermostat_Essecke_ClimaTeam
channel_06 Wz.Thermostat_Essecke_remote
lastMsg No:51 - t:10 s:22DE80 d:272E57 0205200000
protLastRcv 2014-10-04 18:01:03
protResnd 2 last_at:2014-10-04 13:07:06
protSnd 42 last_at:2014-10-04 18:01:03
protState CMDs_done
rssi_HMLAN1 avg:-52 min:-52 max:-52 lst:-52 cnt:3
rssi_at_HMLAN1 avg:-56.46 min:-68 max:-51 lst:-56 cnt:859
Readings:
2014-10-03 08:46:19 Activity alive
2014-10-04 18:00:53 CommandAccepted yes
2014-10-02 10:01:21 D-firmware 1.3
2014-10-02 10:01:21 D-serialNr KEQ0733049
2014-10-04 18:00:54 PairedTo 0x272E57
2014-04-13 16:48:00 R-backOnTime 10 s
2014-10-04 18:00:54 R-btnLock off
2014-10-04 18:00:54 R-burstRx on
2014-10-04 18:00:54 R-cyclicInfoMsg on
2014-10-04 18:00:54 R-cyclicInfoMsgDis 0
2014-10-04 18:00:54 R-globalBtnLock off
2014-10-04 18:00:54 R-localResDis off
2014-04-13 16:48:00 R-lowBatLimitRT 2.1 V
2014-10-04 18:00:54 R-modusBtnLock off
2014-10-04 18:00:54 R-pairCentral 0x272E57
2014-10-04 18:00:53 RegL_00: 01:01 02:01 09:01 0A:27 0B:2E 0C:57 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00
2014-10-04 18:00:52 actuator 100
2014-10-04 13:09:24 battery ok
2014-10-04 18:00:52 batteryLevel 2.9
2014-10-04 18:00:52 desired-temp 21.5
2014-10-04 18:00:52 measured-temp 21.3
2014-08-30 11:08:40 powerOn -
2014-08-30 11:08:40 recentStateType info
2014-10-04 18:01:03 state CMDs_done
2014-10-04 13:07:00 time-request -
Regl_07::
VAL
Helper:
cSnd 01272E5722DE80030421E7DC0107
mId 0095
rxType 140
Io:
newChn +22DE80,00,01,00
nextSend 1412438463.42805
prefIO
rxt 2
vccu
p:
22DE80
00
01
00
Mrssi:
mNo 51
Io:
HMLAN1 -54
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
Hmlan1:
avg -52
cnt 3
lst -52
max -52
min -52
At_hmlan1:
avg -56.4633294528522
cnt 859
lst -56
max -51
min -68
Shregw:
07 04
Shadowreg:
Attributes:
IODev HMLAN1
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 1.3
icon hc_wht_regler
model HM-CC-RT-DN
room Wohnzimmer
serialNr KEQ0733049
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
Und ein list Wz.Thermostat_Essecke_WindowRec
Internals:
DEF 22DE8003
NAME Wz.Thermostat_Essecke_WindowRec
NR 28
STATE last:Wz.Fenster_Drehgriff :open
TYPE CUL_HM
chanNo 03
device Wz.Thermostat_Essecke
peerList Wz.Fenster_Drehgriff,
Readings:
2014-10-04 18:01:03 R-Wz.Fenster_Drehgriff_chn-01-shCtValLo 50
2014-10-04 18:01:03 R-Wz.Fenster_Drehgriff_chn-01-winOpnTemp 16 C
2014-10-04 18:00:56 R-sign off
2014-10-04 18:00:56 RegL_01: 08:00 00:00
2014-10-04 18:01:02 RegL_03:Wz.Fenster_Drehgriff_chn:01 04:32 00:00
2014-10-04 18:01:03 RegL_07:Wz.Fenster_Drehgriff_chn:01 05:20 00:00
2014-10-04 18:00:55 peerList Wz.Fenster_Drehgriff,
2014-10-02 10:32:10 state unpeered
2014-10-04 16:55:07 trigLast Wz.Fenster_Drehgriff :open
2014-10-04 16:55:07 trig_Wz.Fenster_Drehgriff open
Helper:
peerIDsRaw ,21E7DC01,00000000
Role:
chn 1
Shadowreg:
Attributes:
model HM-CC-RT-DN
peerIDs 00000000,21E7DC01,
stateFormat last:trigLast
Danach habe ich folgendes eingegeben:
attr global verbose 1
attr global mseclog 1
attr HMLAN1 logIDs all,sys
und anschließend den HM-Sec-RHS mehrmals (mit Pausen) betätigt.
Und hier das erzeugte Logfile
Mit welchen Einstellungen setze ich das Logging eigentlich wieder auf die normalen Einstellungen zurück? Habe da jetzt auf die Schnelle nichts gefunden.
ZitatMit welchen Einstellungen setze ich das Logging eigentlich wieder auf die normalen Einstellungen zurück? Habe da jetzt auf die Schnelle nichts gefunden.
durch löschen der attribute werden wieder die default werte eingestellt.
das esszimmer thermostat empfängt wohl alles vom fensterkontakt. fhem kann das senden der zustände tiltet und closed nicht empfangen. fhem sieht aber die empfangsbestätigungen des thermostates. somit sollte der thermostat die korrekte anzeige des fensters zeigen.
fhem sieht alle meldungen vom fk zum tv thermostat, kann aber manche empfangsbestätigungen des thermostates zum fk nicht sehen. wahrscheinlich auch hier korrekte anzeige am thermostat.
die statusmeldungen zur zentrale kommen wohl alle an.
fazit: fhem kann nicht alle funkmeldungen empfangen. besonders vom fk und tv thermostat. vom fk zu den thermostaten ist wohl alles in ordnung (jetzt). somit funkprobleme. eventuell neue batterien. hmlan besser positionieren. zweites io besorgen.
gruss frank
Hallo Frank,
zunächst erst einmal meinen herzlichsten Dank zur Unterstützung - ich weiß das zu schätzen.
Da ja
a) die Monate zuvor alles funktioniert hatte
b) Batterien lt. Meldungen alle noch ok sind
c) die Funkentfernung innerhalb weniger Meter liegt (direkter Sichtkontakt ohne irgendetwas dazwischen)
werde ich alle beteiligten Geräte auf Werkseinstellung zurücksetzen und von vorne anfangen >:(
Ob ich wirklich mit Homematic und Fhem auf die richtige Schiene gesetzt habe, muss sich dann endgültig zeigen. So tief habe ich in die Materie eigentlich nie wirklich einsteigen wollen.
Danke und Gruß
Holger
P.S. bzgl. Logging. Ich habe ein rereadcfg gemacht und müsste daher doch eigentlich wieder meine alten Einstellungen haben
Zitata) die Monate zuvor alles funktioniert hatte
ich dachte du bist mit fhem umgezogen. steht dein hmlan exakt an der selben stelle und die gleiche lage im raum?
Zitatb) Batterien lt. Meldungen alle noch ok sind
da würde ich nicht drauf wetten wollen. ;) wenn low, dann aber schnell.
Zitatc) die Funkentfernung innerhalb weniger Meter liegt (direkter Sichtkontakt ohne irgendetwas dazwischen)
bezieht sich das auf den hmlan?
ZitatIch habe ein rereadcfg gemacht und müsste daher doch eigentlich wieder meine alten Einstellungen haben
das hat aber nichts mit den registereinstellungen im device zu tun. dafür gibt es bei hminfo funktionen.
Zitatich dachte du bist mit fhem umgezogen
Umgezogen bin ich von einem Raspberry-Pi auf einen Cubietruck. Hintergrund dazu: innerhalb von 2 Wochen wurde 2 x die SD-Karte so beschrieben, dass sie nicht mehr lesbar war (zu dem Zeitpunkt waren meine aktuellen Sicherungen leider noch auf der SD-Karte selber und damit weg. Zum Glück hatte ich aber noch meine schriftlichen Aufzeichnungen, von daher nicht ganz so schlimm.
Auf dem Cubietruck läuft eine HD. Und jetzt sichere ich zusätzlich täglich das fhem-Verzeichnis auf mein NAS :)
Zitatsteht dein hmlan exakt an der selben stelle und die gleiche lage im raum?
Ja. meine Homematic-Geräte stehen unverändert an gleicher Stelle. Max. Entfernung HMLAN zu Thermostat_Essecke 7,5 m (nichts dazwischen, zu den anderen Geräten im Wohnzimmer sind die Entfernungen noch kürzer. Meinen Garagentor-Sensor durch mehrere Beton- und Ziegelwände kann ich problemlos empfangen.
ZitatBatterien
Habe keine einzige low-Meldung, alle mit Status: ok
Zitatdie Funkentfernung innerhalb weniger Meter liegt (direkter Sichtkontakt ohne irgendetwas dazwischen)
bezieht sich in diesem Fall auf HMLAN, fk, Thermostate (s. auch oben)
Zitatdas hat aber nichts mit den registereinstellungen im device zu tun. dafür gibt es bei hminfo funktionen
aber das Logging ist zumindest ausgeschaltet, wodurch auch immer
Wie lauten denn die Standardeinstellungen, wenn man nicht das folgende Logging haben möchte?
attr global verbose 1
attr global mseclog 1
attr HMLAN1 logIDs all,sysGruß
Holger
Hallo omega, die Standarteinstellung ist attr global verbose 3 und die beiden anderen attr löschen/auskommentieren.
VG
Frank
Hallo Frank,
langsam bin ich am verzweifeln. Ich will ja die Thermostate und den fk neu aufsetzen.
Das unset des Peering hat auch geklappt, der fk ist mit unpair abgemeldet.
Aber die Thermostate bekomme ich nicht raus.
Nach einem set Wz.Thermostat_Essecke unpair
geht das Device auf CMDs_Pending und nichts passiert. Habe auch schon versucht, mit burstXmit etwas zu bewegen, aber es passiert nicht wirklich etwas.
Der 2. Thermostat Wz.Thermostat_TV reagiert überhaupt nicht mehr (im Event-log habe ich ihn schon mit dem Staus "dead" gesehen, aktuell im Action-Log scheint aber alles ok zu sein. Ich möchte doch keine Diplomarbeit schreiben.
Ich möchte
- ein unpair machen
- die Devices auf Werkseinstellung zurücksetzen
- neu starten
Die nächste Alternative wäre ansonsten wohl ein delete.
Gruß
Holger
Dann setze doch die devices direkt am device auf Werkseinstellung zurück und lösche das device in fhem. Dann neu pairen und dannach die peers setzen.
VG
Frank
ZitatIch will ja die Thermostate und den fk neu aufsetzen.
dazu muss man aber nicht das pairing entfernen, sondern ein reset der devices veranlassen. entweder über fhem oder am device direkt. danach ist das pairing ebenfalls verloren. ohne pairing, kann die zentrale (fhem) keine konfigurationen mehr machen. das lässt ein ungepairtes device nicht zu.
nach dem reset also als erstes wieder mit der zentrale pairen. dann getconfig damit die zentrale die aktuelle devicekonfiguration erhält. danach kannst du über fhem an der konfiguration schrauben. nach jeder änderung getconfig anstossen, um zu sehen, dass die änderung erfolgreich durchgeführt wurde und fhem die geänderte konfiguration erhält.
Zitatgeht das Device auf CMDs_Pending und nichts passiert.
das hört sich aber danach an, dass das pairing entfernt wurde. fhem hat nun keine kontrolle mehr über das device.
ZitatDie nächste Alternative wäre ansonsten wohl ein delete.
ein delete ist eigentlich völlig überflüssig. mache einfach vor einem neuen pairing ein set clear all, dann werden alle device konfigurationsdaten aus fhem gelöscht.
und immer daran denken zwischendurch save zu machen, sonst sind die aktionen nach einem neustart nicht mehr in fhem verfügbar.
gruss frank
Ups, und ich habe zwei Threads verwechselt ???
VG
Frank
Deine Ergänzungen habe ich leider zu spät gesehen.
Habe mich bis eben durch alles durchgequält. Wie fast zu erwarten gab es diverse Probleme, bis das neue Pairing endlich funktioniert hatte. Ebenso Peering klappte zunächst nur vom fk (habe immer gewartet, bis CMDS_done). Dann waren Register im fk falsch gesetzt (peerNeedsBust war off), und und und...
Ende vom Lied (nachdem konfigurationstechnisch wieder alles ok war): null Änderung zum vorherigen Verhalten. Zufallsbedingt erkennt mal der eine oder der andere Thermostat das geöffnete Fenster.
Alle Batterien habe ich auch gewechselt (hatten zwar alle noch volle Volt-Zahl, aber was probiert man nicht alles...).
Jetzt muss ich selber erst einmal abschalten und dann überlegen, wie ich überhaupt weiter vorgehen will.
VG
Holger
ZitatZufallsbedingt erkennt mal der eine oder der andere Thermostat das geöffnete Fenster.
wie meinst du das? nach deinem log von gestern sollten die thermostate den fk korrekt erkennen und den fensterzustand auf dem display anzeigen. nur dein fhem (logs) bekommt nicht alles mit.
Folgende Aufzeichnungen habe ich gestern parallel zum Log gemacht (wollte ich eigentlich auch aufschreiben, hatte ich dann aber leider vergessen)
Wz.Fenster_Drehgriff (EE = Thermostat_Essecke, TV = Thermostat_TV)
Open Led: Rot
EE: ok (zeigt Fenster-offen-Symbol, desired Temp = 16.0)
TV: ok (zeigt Fenster-offen-Symbol, desired Temp = 16.0)
Closed Led: Rot
EE: ok (Fenster-offen-Symbol weg, desired Temp = 21.5)
TV: ok (Fenster-offen-Symbol weg, desired Temp = 21.5)
Open Led: Rot
EE: ok
TV: ok
Tilted Led: Rot
EE: ok
TV: ok
Closed: Led: Rot
EE: ok
TV: Fehler (zeigt Fenster-offen-Symbol. Desired Temp = 16.0)
Open Led: Rot
EE: ok
TV: ok
Closed Led: Rot
EE: ok
TV: Fehler (zeigt Fenster-offen-Symbol. Desired Temp = 16.0)
Soweit ich mich noch entsinne, habe ich danach den Test beendet und die Daten zusammengestellt.
Später, bei weiteren Tests, hatte ich immer einen Fehler, mal bei EE, mal bei TV. Manchmal wurde eine richtige Einstellung erst bei Umstellen auf Tilted erkannt.
Das größte Problem ist wohl, dass es kein eindeutiges Verhalten gibt (außer, dass die Led nach dem Schalten immer Rot leuchtet anstatt grün).
Gruß
Holger
nach dieser liste hast du 2 fehler am tv-thermostat. jedes mal hat der fk die message an den thermostat gesendet, aber fhem konnte keine bestätigung empfangen. demnach wurde auch nichts gesendet. eigentlich dachte ich, die devices würden mehrere versuche des sendens machen. trotzdem bleibt die frage der roten led, obwohl alles funktioniert. ist der fk noch irgendwo anders als peer eingetragen?
2014.10.04 18:08:35.389 0: HMLAN_Parse: HMLAN1 R:E21E7DC stat:0000 t:0107CD3F d:FF r:FFBB m:6A A041 21E7DC 22EC4D 012D00
2014.10.04 18:11:53.153 0: HMLAN_Parse: HMLAN1 R:E21E7DC stat:0000 t:010AD1E2 d:FF r:FFBC m:70 A041 21E7DC 22EC4D 012F00
bei dir gibt es definitiv funkprobleme. warum auch immer. störfelder (wlan, dect, mikrowelle, tv, andere komponenten)? fhem sieht teilweise die antworten eines thermostat auf die zustandsmeldung des fk an den thermostat. die auslösende zustandsänderungsmeldung des fk aber nicht.
also erst einmal damit beginnen, dass fhem alles empfangen kann. ein erster schritt. sonst ist loggen auch nur spekulation.
edit: voraussetzung über "update" aktualisiertes fhem.
gruss frank
@frank
Ich denke der Hinweis auf Update wird den Fehler beheben. Wenn man im Forum, in verschiedene Threads schaut, hat es oft an veralteten Modulen gehangen. Oft wird auch davon ausgegangen das die Installation von fhem 5.5 auf dem neusten Stand ist, ohne zu wissen das, dass der Stand von ca. einem Jahr ist.
VG
Frank
ZitatOft wird auch davon ausgegangen das die Installation von fhem 5.5 auf dem neusten Stand ist,
leider wahr, obwohl schon seit einiger zeit folgendes dabei steht:
ZitatDownload
Last released version: (as of 2013-09-29): fhem-5.5.tar.gz, fhem-5.5.deb, fhem-5.5-fb7390.image, fhem-5.5-fb7270.zip
See the CHANGED file for the change history or the svn log for a more detailed log.
Note: the FHEM development is a continuous one, and a release is only a starting point for the update process. Please use the update command to get the most recent version, especially if you want to report issues in the forum.
Nightly SVN version: a tarball, or from the fhem commandline via update.
das zeigt dann immer wieder das globale problem mit dem "lesen" auf. vielleicht sollte das mal jemand rot einfärben. ;)
gruss frank
nicht rot - kann ich nicht sehen ;) - blau ist besser im Kontrast zu schwarz :D
Gleich 2 x Frank - das ist gut...
Version ist (sollte zumindest sein lt. meinen Aufzeichnungen) vom 01.10.2014 (sowohl notice ... als auch update)
Folgende Moduldaten habe ich:
# $Id: fhem.pl 6425 2014-08-19 20:55:00Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 6478 2014-08-28 15:01:04Z martinp876 $
# $Id: 70_EGPM.pm 5344 2014-03-27 20:06:31Z alexus2033 $
# $Id: 17_EGPM2LAN.pm 5344 2014-03-27 20:06:31Z alexus2033 $
# $Id: 01_FHEMWEB.pm 6447 2014-08-24 07:38:52Z rudolfkoenig $
# $Id: 92_FileLog.pm 5876 2014-05-16 19:54:51Z rudolfkoenig $
# $Id: 00_HMLAN.pm 6471 2014-08-27 12:32:38Z martinp876 $
# $Id: 98_HMinfo.pm 6468 2014-08-27 08:13:42Z martinp876 $
./FHEM/99_MyUtils.pm: No such file or directory
# $Id: 73_PRESENCE.pm 6341 2014-08-01 21:56:21Z markusbloch $
# $Id: 99_SUNRISE_EL.pm 5851 2014-05-13 19:39:03Z rudolfkoenig $
# $Id: 98_SVG.pm 6446 2014-08-23 10:09:44Z rudolfkoenig $
# $Id: 99_Utils.pm 6446 2014-08-23 10:09:44Z rudolfkoenig $
# $Id: 90_at.pm 5319 2014-03-25 10:11:47Z rudolfkoenig $
# $Id: 98_autocreate.pm 6436 2014-08-21 05:40:35Z rudolfkoenig $
# $Id: 98_dummy.pm 4934 2014-02-15 08:23:12Z rudolfkoenig $
# $Id: 91_eventTypes.pm 6428 2014-08-20 11:51:27Z rudolfkoenig $
# $Id: 91_notify.pm 6371 2014-08-07 05:33:37Z rudolfkoenig $
# $Id: 33_readingsGroup.pm 6262 2014-07-16 07:46:03Z justme1968 $
# $Id: 98_structure.pm 6401 2014-08-13 07:00:48Z rudolfkoenig $
# $Id: 98_telnet.pm 4844 2014-02-08 07:54:03Z rudolfkoenig $
# $Id: 91_watchdog.pm 5622 2014-04-24 08:04:29Z rudolfkoenig $
hmmmm...
Ein erneutes update bringt nichts - auch nicht den Hinweis: nothing to do,
ein update check dagegen listet etliche Module auf. Da eh schon alles egal ist, habe ich ein update force ausgelöst. Der rödelt gerade vor sich hin....
und FHEM "stirbt". Ich hoffe mal, dass update force direkt den notwendigen restart auslöst.
War anscheinend so, FHEM ist wieder da und jetzt nach einem update check auch mit der Meldung: nothing to do. OK: dann ist bei den vorherigen Updates tatsächlich was schiefgelaufen aber jetzt sollte alles ok sein.
Auf ein Neues:
Leider nein. Led immer Rot bei jedem Schaltvorgang.
Beim 1. Öffnen lief TV wieder auf Fehler. Bei den folgenden Schaltvorgängen danach waren zumindest die Anzeigen an den Thermostaten ok.
Ich hatte damals ähnliche Probleme mit einigen HM-SEC-SC-2, da lag es an der Firmware. Mit Firm. 2.4 zeigte er brav grün, die mit Firm. 2.2 zeigten rot. Habe das Ganze dann über virtuelle Buttons gelöst. Geht bestimmt auch, wenn du das über eine vccu machst (vccu stellt ja auch virtuelle Buttons bereit). Nur wie das mit den peeren dann ist, weis ich nicht mehr so genau, da hat aber Martin bestimmt die Lösung parat. Ich denke du peerst den Drehgriff mit einem virtuellen Button der vccu und den RT ebenfalls mit dem virt. Button der vccu. Ob das stimmt weis ich leider nicht. Ich hab mir damals "händisch" virtuelle Buttons ohne vccu angelegt (gab es zu der Zeit noch nicht). Das Ganze geht bei mir dann über ein notify.
Fenster_Kueche {if(Value("Fenster_Kueche") eq "closed" && Value("KuecheWindow") eq "open")
{fhem "set Kueche_Heizung burstXmit; set myVirtualHM_Btn1 postEvent closed; set KuecheWindow closed"}
elsif (Value("Fenster_Kueche") eq "open" && Value("KuecheWindow") eq "closed")
{fhem "set Kueche_Heizung burstXmit; set myVirtualHM_Btn1 postEvent open; set KuecheWindow open" } }
VG
Frank
@franky08: Bin ziemlicher FHEM-Anfänger – also m.E. noch viel zu weit entfernt, um eine VCCU zu definieren + virtuelle Buttons und was weiß ich noch...
Trotzdem danke.
Ich habe jetzt folgende Tests gemacht: den Wz. Fenster_Drehgriff habe ich aus den Peerings entfernt, danach ein unpair.
Danach habe ich einen weiteren Sensor (HM-Sec-SC-2 mit Firmware 2.4) eingerichtet.
Solange der Sensor mit keinem Thermostat gepeert ist, funktioniert er einwandfrei (Led ist grün nach jedem Schaltvorgang). Nachdem ich ihn mit den Thermostaten gepeert habe, war bei jedem Schaltvorgang die Led wieder rot. Allerdings wurde der Schaltvorgang als solches von den Thermostaten immer einwandfrei umgesetzt. Da ich den Sensor noch nicht montiert habe, habe ich ihn mal dicht an den Thermostaten / HMLAN-Adapter und auch mal weit entfernt geschaltet – ohne Unterschied, d.h. für mich erst einmal: kein Funkproblem.
Danach habe ich den SC2 mit jedem Thermostat einzeln verbunden – auch hier kein Unterschied: Led immer rot.
Nach meinem letzten Versuch (erneute Neueinrichtung mit getconfig und Anlerntaste nach jedem einzelnen Schritt) hatte ich bei hm configCheck immer folgende Fehlermeldung:
configCheck done:
Register changes pending
Wz.Thermostat_Essecke
Wz.Thermostat_TV
Ich hatte immer gewartet, bis CMDs_done, bevor ich weitergemacht hatte. Auch ein set Wz.Thermostat_Essecke mit anschließendem Drücken der Anlerntaste bzw. set Wz.Thermostat_Essecke_ WindowRec mit anschließendem Drücken der Anlerntaste haben die Fehlermeldung nicht beseitigt. Auch ein Warten über Nacht brachte keine Änderung.
Danach habe ich folgendes gemacht:
• FHEM gestoppt
• Mit der Homematic-Software HMLAN wieder auf AES-Kommunikation umgestellt
• Mit dem HM-Konfigurator die Thermostaten und den Fensterkontakt angelernt und anschließend eine direkte Geräteverknüpfung eingerichtet. Danach war bei jedem Schaltvorgang die Led Grün :) – so, wie es sein soll.
• Mit der Homematic-Software HMLAN die AES-Kommunikation wieder deaktiviert
• FHEM gestartet
• Hm configCheck: Fehler waren weg :)
• Fensterkontakt geschaltet: Led waren wieder Rot nach jedem Schaltvorgang >:( >:( >:( .
Jetzt bin ich mit meinem Latein endgültig am Ende. Bei der Originalsoftware läuft die Kommunikation richtig, unter FHEM läuft (bei identischen Geräte-Einstellungen) etwas falsch.
Hallo Omega, die Bestätigung mit grün, beim Fensterkontakt habe ich bei mir nur über "Umwege" hinnbekommen. Definiere dir unbedingt eine vccu:
http://forum.fhem.de/index.php/topic,23008.0.html
Dann peerst du deinen Fensterkontakt mit dem vccu, dass Pairing lässt du so wie es ist. Dann bekommt der Fensterkontakt von vccu eine Bestätigung und quittiert mit grün.
Hier im Forum, unter Homematic findest du etliches zu vccu.
P.S. Sonst ist mit deiner Konfiguration alles OK, da brauchst du nicht weiter drüber nachzugrübeln
VG
Frank
ZitatBei der Originalsoftware läuft die Kommunikation richtig, unter FHEM läuft (bei identischen Geräte-Einstellungen) etwas falsch.
das kann dann nur die kommunikation zwischen fk und fhem (hmlan) sein. wenn du den fk entpairst, müsste er also grün anzeigen. seltsam. ???
gruss frank
@frank
Das hängt mit der Firmware zusammen, die auf dem Sec-SC ist. Habe das vor langer Zeit mit Martin mal durchgetestet und müsste hier im Thread zu finden sein. Es gab unterschiedliche Firmwareversionen, mit mancher ging es, grün und mit einer anderen rot. Aber was wie war weis ich jetzt nicht mehr.
Müsste das hier gewesen sein:
http://forum.fhem.de/index.php/topic,22688.0.html
P.s. Wie ich gerade sehe, gab es mit der Firm. 2.4 allerdings nie Probleme. Nur die 2.2 war zickig
VG
Frank
ZitatNur die 2.2 war zickig
und wie es aussieht auch die 2.1 vom rhs.
ist ja ein schönes durcheinander. da hast du aber fleissig pairen und peeren geübt. ;D
gruss frank
Ok – zunächst habe ich flüchtig den 12-seitigen Threat zu VCCU quergelesen.
Danach den Artikel Virtueller_Controller_VCCU im Wiki. Verstanden habe ich dennoch nicht, was mir eine VCCU bringt, solange ich nur ein einziges IO-Device (mein HMLAN) verwende?
Dann zum Verständnis meine Sicht.
Ich definiere eine VCCU. Ok, ich habe dann zusätzlich ein virtuelles Device. Das kann aber doch nicht senden, dass kann nur mein HMLAN.
Wenn ich meinen Fensterkontakt mit der VCCU peere. OK. Woher wissen dann aber die Thermostate, dass es beim Schalten für sie etwas zu tun gibt? Vermutlich muss ich also auch die Thermostate irgendwie an die VCCU anbinden. Wie?
Muss ich dann meine ganzen anderen Geräte auch an die VCCU anbinden? Oder geht das sowohl als auch?
Ich fühle mich etwas überfordert, mit meinen geringen FHEM-Kenntnissen ein Thema anzugehen, dass bisher anscheinend überwiegend nur von Profis durchgeführt wurde, zu dem wohl eine Wiki-Seite noch aussteht und zu dem konkrete Beispiele einer kompletten Einrichtung (und damit meine ich anfängerfreundlich Befehl für Befehl) noch nicht vorhanden sind (zumindest habe ich keine gefunden). Es wird ja immer gerne auf die Anfängerdokumentation verwiesen (verstehe ich) – aber über eine VCCU habe ich da nichts gefunden. Mir ist auch klar, dass hier ganz viel auf freiwilliger Basis erstellt wird – das finde ich auch toll und ich bin dankbar dafür.
Im Moment kann ich mich nicht entscheiden, wie ich weitermache. Das muss erst mal sacken.
Viele Grüße
Holger
Zitatzu dem wohl eine Wiki-Seite noch aussteht
http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU (http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU)
Hatte ich doch schon gesehen gehabt:
ZitatDanach den Artikel Virtueller_Controller_VCCU im Wiki
aber eben auch:
ZitatTodo: Das VCCU-Konzept scheint bedeutend (und komplex) genug, dass eine eigene Wiki-Seite gerechtfertigt wäre. Es muss sie nur noch jemand erstellen...
gesehen auf http://www.fhemwiki.de/wiki/CUL_HM#Virtuelle_CCU_.28VCCU.29
Mein Wunsch wäre, dass sich die Spezialisten beim Schreiben der Wiki-Seiten etwas mehr auch an Anfänger richten. Gerade bei komplexen Themen ...
Für die alten Hasen mag ja viele selbsterklärend sein.
Nochmal - damit ich jetzt nicht falsch verstanden werde: Ich bin dankbar dafür, was hier alles auf die Beine gestellt wird.
Viele Grüße
Holger
Hallo Omega, mach einfach ein define vccu CUL_HM <die ID von deinem IO Interface, HMLAN>
dann gibst du als Attribut bei deinen devices ein: attr vccu IOgrp vccu
Und dann peerst du die "problemdevices" mit vccu, wie im WIKI beschrieben.
VG
Frank
P.S. Bin noch auf Arbeit :(
Die 1. Anweisung ist ja noch einfach
define vccu CUL_HM 272E57Danach soll lt. Wiki http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU ein
attr vccu model FHEM-CCU kommen.
Die Anweisung wird auch problemlos verarbeitet.
Danach finde ich die vccu unter den CUL_HM-Geräten versehen mit 3?. Stimmt das wirklich so?
Nächste Frage zum Wiki-Eintrag. Hier steht unter Einrichten:
Zitatattr ccu IOList <io1>[,<io2>,...]
Soll es wirklich ccu heißen (oder fehlt nur das "v")?
Was bedeutet IOList? Ich finde ich in der Commandref nichts dazu.
Als nächstes folgende Frage:
Zitatdann gibst du als Attribut bei deinen devices ein: attr vccu IOgrp vccu
Der Befehl wird auch klaglos ausgeführt, nur der Sinn erschließt sich mir nicht. Die vccu weiß doch, dass sie eine vccu ist.
Vermutlich soll ich eingeben:
attr <hier soll wahrscheinlich der Name eines meiner devices stehen> IOgrp vccuUnd dann kommt das größte Problem - peering.
Vermutlich brauche ich zunächst ein
set vccu virtual 10Damit habe ich 10 Kanäle - die ich danach wohl noch individuell konfigurieren muss. Aber wie (Anweisung) und als was (Button, Actor, Sensor)? Laufen meine 3 problematischen Geräte über einen Kanal oder brauche ich für jedes Gerät einen eigenen? Sorry: null Plan
Viele Grüße
Holger
ZitatDanach finde ich die vccu unter den CUL_HM-Geräten versehen mit 3?. Stimmt das wirklich so?
klar. Die vccu hat keinen status - ist nichts passiert. ok, ich könnte etwas einbauen wie init....
ZitatSoll es wirklich ccu heißen (oder fehlt nur das "v")?
v hatte gefehlt
ZitatWas bedeutet IOList? Ich finde ich in der Commandref nichts dazu.
erklärt es das wiki nicht?
ZitatSind IOs durch das Attribut IOList einer vccu zugewiesen....
ios werden der vccu zugewiesen.
ZitatDer Befehl wird auch klaglos ausgeführt, nur der Sinn erschließt sich mir nicht. Die vccu weiß doch, dass sie eine vccu ist.
der Befehl ist sinnlos, halte dich an das wiki:
attr <dev> IOgrp <vccu>:<preferedIO>und die Beschreibung hierzu.
ZitatDamit habe ich 10 Kanäle
korrekt
Zitatdie ich danach wohl noch individuell konfigurieren muss.
viel konfigurieren kann man nicht. peeren ist das wesentliche.
Zitatund als was (Button, Actor, Sensor)
alles.
erst einmal peerst du es mit etwas - also aktor oder sensor. Auch gemischt geht... könnte aber zu Problemen führen.
Wenn ein Kanal gepeert ist mit einem Aktor - also als sensor -
set vccu_Btn1 peerChan 0 aktorchannel.....
kannst du
set vccu_Btn1 press auslösen - dann bist du eine remote (buttonPressSensor)
set vccu_Btn1 postEvent value auslösen - dann bist du eine sensor mit werteübergabe
oder
set remoteChannel peerChan 0 ccu_Btn1 ..... - dann bist du ein aktor. kann natürlich nicht viel aggieren... ist ja nur sw
ZitatLaufen meine 3 problematischen Geräte über einen Kanal oder brauche ich für jedes Gerät einen eigenen? Sorry: null Plan
was sind problematische geräte? was willst du erreichen? geht beides - kommt auf das ziel an
Hallo Martin,
danke für deine Unterstützung.
Manchmal ist es etwas problematisch, sich an das Wiki zu halten...
Ich vermute, dass die Anweisung
attr vccu model FHEM-CCU, die bei mir zu 3? führt, falsch geschrieben ist.
Korrekt - vermute ich - wäre
attr vccu model CCU-FHEMZumindest habe ich jetzt diese Schreibweise mittlerweile des öfteren im Forum gefunden. Und dann sind auch die 3? weg.
IOlist:
Zitaterklärt es das wiki nicht?
Scheinbar nicht wirklich, ansonsten hätte ich nicht gefragt. Nach langem Lesen glaube ich mittlerweile, dass damit vorhandene HMLAN-Adapter oder HM-USB-CFG2-Adapter gemeint sein könnten.
Zitatwas sind problematische geräte?
Problematisch sind/waren meine beiden Thermostate und der Fensterkontakt, die nicht mehr korrekt miteinander geredet haben. FK ist immer rot nach dem Schalten.
Hierzu habe ich mittlerweile ein update (vccu habe ich mangels Erkenntnisse erst einmal zurückgestellt).
Die Störungen wurden verursacht durch ein LED16_Statusanzeige HM-OU-LED16 device.
Nachdem ich das Gerät und die dazugehörigen notifys (nur Löschen der notifys hat nicht ausgereicht) gelöscht habe, hat die Kommunikation zwischen FK und Thermostaten wieder einwandfrei funktioniert.
Viele Grüße
Holger