Hallo zusammen,
Meine ersten Heizungsteuerungskomponenten sind eingetroffen und ich habe mich durch das Wiki gekämpft.
HM-CC-RT-DN ist montiert und gepairt, ebenso HM-TC-IT-WM-W-EU. Die Kanäle 1&2 habe ich lt. Wiki gekoppelt und ich kann vom HM-TC-IT-WM-W-EU das Ventil steuern. Auch das Wochenprogramm ist angelegt.
Leider scheitere ich jetzt an der automatischen Absenkung bei Tür-Auf-Erkennung mit dem schon länger im Dienst stehenden Drehgriffsensor. Hier mal die angelegten Namen:
HM-TC-IT-WM-W-EU: HM_Hzg_T_WZ
HM-CC-RT-DN: HM_Hzg_V
HM-SEC-RHS: HM_WZ_Tuer_Terasse
Was habe ich nun getan:set HM_WZ_Tuer_Terasse peerChan 0 HM_Hzg_T_WZ_WindowRec single set
set HM_Hzg_T_WZ_WindowRec regSet winOpnTemp 6 HM_WZ_Tuer_TerasseUnd beim 2. Befehl bin ich mir unsicher, mit dem <fensterSensor> lt Wiki (http://www.fhemwiki.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP#Channel_.28Kanal.29_03_WindowRec). Eigentlich soll ich ja hier einen Kanal angeben und kein Device. Aber der Türkontakt hat ja keine Kanäle...
Und so steht der State vom HM_Hzg_T_WZ_WindowRec permanent auf unknown. Wer kann mir hier den korrekten Kanalnamen verraten - oder habe ich da noch einen ganz anderen Fehler drin?
hast du mit hminfo configcheck geprüft und fehler beseitigt?
OK, hatte ich zwar vorher gemacht, aber nach dem Türsensor erfolgreich ignoriert. Aber sorry- das sagt mir jetzt nicht viel:configCheck done:
Register changes pending
HM_Hzg_V_WZ
HM_WZ_Tuer_Terasse
peer not verified. Check that peer is set on both sides
HM_Hzg_T_WZ_WindowRec p:HM_WZ_Tuer_Terasse
unwissende Grüße
Niels
der peer scheint nur auf einer seite eingetragen (peerids) zu sein. hat eventuell mit den pending cmds zu tun.
homematic-basics:
- viele devices müssen erst aufgeweckt werden, um befehle entgegen zu nehmen. zb taster drücken.
- bei allen aktionen auf "cmds_done" achten.
- "set_xxx" werte in readings sind nicht verifiziert.
Zitat von: frank am 08 Dezember 2015, 12:58:12- bei allen aktionen auf "cmds_done" achten.
Jo, darauf hatte ich gewartet. OK, ich habe die Geräte nicht geweckt, aber das war erledigt.
Ich denke, dass der Name von dem Türsensor nicht gleich dem benötigten Kanalnamen ist, jedoch finde ich nicht, wie der korrekt aussehen müsste.
namentliche Grüße
Niels
ZitatIch denke, dass der Name von dem Türsensor nicht gleich dem benötigten Kanalnamen ist, jedoch finde ich nicht, wie der korrekt aussehen müsste.
den gibt es nicht und den brauchst du nicht, da es nur 1 channel gibt. dann ist der channel im device. sieht man das nicht?
die peerids hast du also nicht geprüft? befehl wiederholen, wenn nicht vollständig. was verstehst du nicht?
was ist mit infos? list von fk, hk device/winrec channel?
Zitat von: frank am 08 Dezember 2015, 15:58:48
den gibt es nicht und den brauchst du nicht, da es nur 1 channel gibt. dann ist der channel im device. sieht man das nicht?
die peerids hast du also nicht geprüft? befehl wiederholen, wenn nicht vollständig. was verstehst du nicht?
Tja, wenn ich wüsste, was ich nicht verstehe... Auf jeden Fall verstehe ich nicht, warum es nicht funktioniert 8)
Hier mal die Konfigs:
#Terassentuer
define HM_WZ_Tuer_Terasse CUL_HM 343E28
attr HM_WZ_Tuer_Terasse IODev HMLAN1
attr HM_WZ_Tuer_Terasse actCycle 028:00
attr HM_WZ_Tuer_Terasse actStatus alive
attr HM_WZ_Tuer_Terasse alias Terassentuer
attr HM_WZ_Tuer_Terasse autoReadReg 4_reqStatus
attr HM_WZ_Tuer_Terasse devStateIcon closed:fts_door tilted:fts_door_tilt open:fts_door_right_open
attr HM_WZ_Tuer_Terasse expert 2_full
attr HM_WZ_Tuer_Terasse firmware 2.4
attr HM_WZ_Tuer_Terasse group Sensoren
attr HM_WZ_Tuer_Terasse model HM-SEC-RHS
attr HM_WZ_Tuer_Terasse peerIDs 00000000,
attr HM_WZ_Tuer_Terasse room Wohnzimmer
attr HM_WZ_Tuer_Terasse serialNr LEQ1253568
attr HM_WZ_Tuer_Terasse subType threeStateSensor
#Ventil
define HM_Hzg_V_WZ CUL_HM 3CF9B6
attr HM_Hzg_V_WZ IODev HMLAN1
attr HM_Hzg_V_WZ actCycle 000:10
attr HM_Hzg_V_WZ actStatus alive
attr HM_Hzg_V_WZ alias Heizungsventil WZ
attr HM_Hzg_V_WZ autoReadReg 4_reqStatus
attr HM_Hzg_V_WZ expert 1_on
attr HM_Hzg_V_WZ firmware 1.4
attr HM_Hzg_V_WZ group Heizung
attr HM_Hzg_V_WZ model HM-CC-RT-DN
attr HM_Hzg_V_WZ room CUL_HM,Wohnzimmer
attr HM_Hzg_V_WZ serialNr MEQ0799359
attr HM_Hzg_V_WZ subType thermostat
define HM_Hzg_V_WZ_Weather CUL_HM 3CF9B601
attr HM_Hzg_V_WZ_Weather model HM-CC-RT-DN
attr HM_Hzg_V_WZ_Weather peerIDs 00000000,3800BA01,
define HM_Hzg_V_WZ_Climate CUL_HM 3CF9B602
attr HM_Hzg_V_WZ_Climate model HM-CC-RT-DN
attr HM_Hzg_V_WZ_Climate peerIDs 00000000,3800BA02,
define HM_Hzg_V_WZ_WindowRec CUL_HM 3CF9B603
attr HM_Hzg_V_WZ_WindowRec model HM-CC-RT-DN
attr HM_Hzg_V_WZ_WindowRec peerIDs 00000000,
attr HM_Hzg_V_WZ_WindowRec stateFormat last:trigLast
define HM_Hzg_V_WZ_Clima CUL_HM 3CF9B604
attr HM_Hzg_V_WZ_Clima model HM-CC-RT-DN
attr HM_Hzg_V_WZ_Clima peerIDs 00000000,
define HM_Hzg_V_WZ_ClimaTeam CUL_HM 3CF9B605
attr HM_Hzg_V_WZ_ClimaTeam model HM-CC-RT-DN
attr HM_Hzg_V_WZ_ClimaTeam peerIDs 00000000,
define HM_Hzg_V_WZ_remote CUL_HM 3CF9B606
attr HM_Hzg_V_WZ_remote model HM-CC-RT-DN
attr HM_Hzg_V_WZ_remote peerIDs 00000000,
#Thermostat
define HM_Hzg_T_WZ CUL_HM 3800BA
attr HM_Hzg_T_WZ IODev HMLAN1
attr HM_Hzg_T_WZ actCycle 000:10
attr HM_Hzg_T_WZ actStatus alive
attr HM_Hzg_T_WZ alias Wandregler WZ
attr HM_Hzg_T_WZ autoReadReg 4_reqStatus
attr HM_Hzg_T_WZ expert 1_on
attr HM_Hzg_T_WZ firmware 1.2
attr HM_Hzg_T_WZ group Heizung
attr HM_Hzg_T_WZ model HM-TC-IT-WM-W-EU
attr HM_Hzg_T_WZ msgRepeat 1
attr HM_Hzg_T_WZ room CUL_HM,Wohnzimmer
attr HM_Hzg_T_WZ serialNr MEQ0051053
attr HM_Hzg_T_WZ subType thermostat
attr HM_Hzg_T_WZ webCmd getConfig:clear msgEvents
define HM_Hzg_T_WZ_Weather CUL_HM 3800BA01
attr HM_Hzg_T_WZ_Weather model HM-TC-IT-WM-W-EU
attr HM_Hzg_T_WZ_Weather peerIDs 00000000,3CF9B601,
define HM_Hzg_T_WZ_Climate CUL_HM 3800BA02
attr HM_Hzg_T_WZ_Climate model HM-TC-IT-WM-W-EU
attr HM_Hzg_T_WZ_Climate peerIDs 00000000,3CF9B602,
define HM_Hzg_T_WZ_WindowRec CUL_HM 3800BA03
attr HM_Hzg_T_WZ_WindowRec model HM-TC-IT-WM-W-EU
attr HM_Hzg_T_WZ_WindowRec peerIDs 00000000,343E2801,Da fällt mir auch was bei auf:
attr HM_WZ_Tuer_Terasse peerIDs 00000000,Ist das gut so? Dafür habe ich ja eigentlich lt. Wki folgendes gemacht:
set HM_WZ_Tuer_Terasse peerChan 0 HM_Hzg_T_WZ_WindowRec single setUnd dafür gibt es auf der GUI
R-HM_Hzg_T_WZ_WindowRec-expectAES: set_off
R-HM_Hzg_T_WZ_WindowRec-peerNeedsBurst: set_onAch ja, und das verstehe ich auch nicht wirklich:
configCheck done: Register changes pending HM_WZ_Tuer_Terasse peer not verified. Check that peer is set on both sides HM_Hzg_T_WZ_WindowRec p:HM_WZ_Tuer_Terasse trigger sent to undefined device triggerUndefined: HM_Kuehlschrank:237389 triggerUndefined: HM_WZ_Tuer_Terasse:237389 templist mismatch HM_Hzg_T_WZ_Climate: failed Entries: HM_Hzg_T_WZ_Climate :R_P1_3_tempListTue mismatch 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0 ne 05:50 21.5 09:00 20.0 11:30 21.5 21:45 19.5 24:00 19.5 ##Den Türsensor habe ich extra nochmal geweckt, also warum changes pending? Warum das Programm vom Montag nicht am Dienstag funktioniert, werde ich jetzt mal ergründen...
Niels
Hallo,
also grundsätzlich - beim peeren mit Batteriegetriebenen Geräten (Deinem Türsensor und dem Thermostat) muss dort die Configtaste betätigt werden, damit die Register (peerId und ggf. andere) dort eingetragen werden (eventuell auch mehrmals). Im WebIf kann man sehen ob alle Komandos übertagen wurden. Es gibt ein paar Ausnahmen (lasy config) aber Du bist mit dem drücken immer auf der sicheren Seite. Bei den Netzbetriebenen Geräten (230V) werden die Register so geschrieben - die müssen eben keine Energie sparen und hören ständig zu.
Gruß Christoph
Unbedingt die Konfig-Taste (ist manchmal ja etwas schwer) oder reicht es ein Event auszulösen (sprich Tür auf&zu), Temperatur verstellen. Zumindest hatte ich danach keine cmd pendings mehr.
Niels
Hallo,
das mit dem Event auslösen ist die (lazy Config). Wenn Ihr in HMInfo "get models" macht, könnt Ihr sehen welche Geräte das unterstützen. Drücken geht bei jedem Gerät - lazyConf bei einigen.
Also peering noch einmal machen - wenn die schon vorhanden sind im Gerät passiert eben nichts, wenn noch nicht vorhanden werden die angelegt. Kaputtmachen kann man nichts. Danach Testen was geht und was nicht geht.
Gruß Christoph
Also sorry, wenn ich mich hier extrem dusslig anstelle und einen ganzen Bretterstapel vor dem Kopf habe, aber nachdem ich Daten bis zum Overload auf dem CUL gelesen habe bin ich einen Schritt weiter.
Nachdem ich nochmal auf dem winOpnrec-Channel ein get config gemacht habe, geht die desired-temp vom Wandthermostaten auf 6°C und eine Weile später auch am Ventil.
Ist der Pairing-Weg überhaupt sinnvoll, oder macht es mehr Sinn, das Pairing zwischen Türsensor und Ventil durchzuführen, damit dann das Ventil den Wandthermostaten darüber informiert. Die scheinen mir ja quasi parallel geschaltet...
Und trotzdem habe ich noch:configCheck done: Register changes pending HM_Hzg_T_WZ_WindowRec HM_Tuer_WZ_Terasse trigger sent to unpeered device
teilerfolgreiche Grüße
Niels
Hallo Nils,
da ist an den Geräten die Änderung immer moch nicht eingetragen "Register changes pending" sagt das zumindest aus. Wegen der Übertragung - da kannst Du mal hier im Forum suchen, das war letzten öfter ein Thema. Da muss ein Register gesetzt werden "peerNeedsBurst" damit die Information über das offene Fenster direkt an den Heizungsregler gesendet wird. Sonst wartet der Wandthermostat dis der Regler sich routinemäßig meldet und sagt es ihn dann erst (ca. 3 Min).
Gruß Christoph
So, jetzt habe ich noch einen 2. Regler für einen anderen Raum in Betrieb genommen. Ohne die hier erhaltene Hilfe wäre das nicht so schnell gegangen. Dafür schon mal Danke.
Auch hier blieben die CMDs in pending. Das konnte ich durch 'clear msgEvents' gefolgt von 'getConfig' und einem Auslösen des Pairing beheben.
Leider komme ich mit diesem Vorgehen im ursprünglichen Fall nicht weiter. Funktion ist gegeben, aber der Config-Check ist noch nicht zufrieden:configCheck done: Register changes pending HM_Hzg_T_WZ_WindowRec
HM_Tuer_WZ_Terasse trigger sent to unpeered device
triggerUnpeered: HM_Tuer_WZ_Terasse:237389 trigger sent to undefined device
triggerUndefined: HM_Kuehlschrank:237389
triggerUndefined: HM_Tuer_WZ_Terasse:237389Gut, der Kühlschrank hat kein Device, was er triggern soll, der wird ja nur durch ein DOIF überwacht. Habe ich nun aus dem langen Text die einzelnen Meldungen durch meine Zeilenumbrüche richtig herausgetrennt?
und nun?
Niels
Hallo,
das Register changes pending muss noch weg. Da ist das peering immer noch nicht an beiden Seiten angkommen - zumindest hat fhem keine Infos darüber bekommen.
Alles andere was unpeered oder undefined ist nicht relevant - hat mit AES zu tun. Kannst Du hier im Forum mal nach suchen.
Gruß Christoph
Hallo zusammen,
gemäß wiki kann man beim Öffnen des Fensters die Temperatur absenken:
set <tc_WindowRec> regSet winOpnTemp <Temp> <fensterSensor>
Das klappt auch wunderbar, nur kann man diese auch beim schliessen des Fensters anheben, bzw. zurück auf den Wert der Zeitsteuerung setzen?
Gruß!
Hallo,
es gibt zwei Informationen. Zum eine Fenster auf / zu und zum anderen die Temperatur die bei open eingestellt wird. Ich würde die Temperatur mit regSet direkt am Gerät (Heizkörperthermostat) einstellen.
Die von Dir beschriebene Variante setzt die Temperatur nur für diese eine Fenster.
Wenn Fenster zu vom Kontakt kommt, sollte das Thermostat automatich wieder auf den "alten" Wert und Modus (Auto/Manu/...) gehen.
Gruß Christoph
Hallo,
das mit dem Absenken der Temperatur klappt wunderbar, der Rest leider nicht ganz so.
Den Fenster-Drehgriffkontakt habe ich wie jedes andere HM Device angelernt. Das funktionierte relativ schnell und unkompliziert, die korrekten Stati (open, tilted und closed) werden auch gemäß Drehgriffposition übermittelt.
Das Wandthermostat (HM-TC-IT-WM-W-EU) ist mit dem Heizungsregler (HM-CC-RT-DN) gepeert, sowohl über den Weather- als auch über den Climate-Kanal. Im Grunde dient das Wandthermostat nur der zusätzlichen Messung der Luftfeuchte (da Kellerraum), ist aber auch ganz praktisch da etwas höher montiert nicht in Reichweite von Kinderhänden. Deshalb auch das Peering.
Da die Motivation das Kellerfenster auch in sehr kalten Winternächten zu schliessen nicht immer bei allen anwesenden gleich hoch ist, habe ich mir den Fenster-Drehgriffkontakt zugelegt und nach (zumindest aus meiner Sicht) erfolgreichen Inbetriebnahme gemäß Wiki Eintrag "HM-TC-IT-WM-W-EU Funk-Wandthermostat AP" über den WindowRec Kanal gepeert.
dabei habe ich folgende Anweisungen aus dem Wiki genutzt:
set <HM-Sec-SC> peerChan 0 <HM-TC-IT-WM-W-EU-Gerät>_WindowRec single set
set <tc_WindowRec> regSet winOpnTemp <Temp> <fensterSensor>
Beim Öffnen des Fensters wird die desired-temp auf 10 °C herunter geregelt, was dann auch schnell bis zum Heizungsregler durchgereicht wird. Es wird auch ein Fenster-Symbol im Display des Wandthermostates angezeigt. Ob dieses schon vorher da war kann ich jetzt nicht sagen, zumindest ist das Symbol im Display nach schliessen des Fensters immer noch da. Die desired-temp im Wandthermostat sowie im Heizungsregler sind beide immer noch auf 10 °C (winOpnTemp).
Hier der Fenster-Drehgriffkontakt:
Internals:
CFGFN
CUL1_MSGCNT 59
CUL1_RAWMSG A0C4EA641345322FAFAFA014D00::-66:CUL1
CUL1_RSSI -66
CUL1_TIME 2016-01-13 17:10:25
DEF 345322
IODev CUL1
LASTInputDev CUL1
MSGCNT 59
NAME window.sensor.Wohnkeller
NR 175
NTFY_ORDER 50-window.sensor.Wohnkeller
STATE closed
TYPE CUL_HM
lastMsg No:4E - t:41 s:345322 d:FAFAFA 014D00
protCmdDel 20
protLastRcv 2016-01-13 17:10:25
protResndFail 4 last_at:2016-01-13 16:48:13
protSnd 60 last_at:2016-01-13 17:10:25
protState CMDs_done
rssi_at_CUL1 avg:-69.99 min:-79 max:-63 lst:-66 cnt:59
CHANGETIME:
Helper:
Dblog:
Activity:
Dblog:
TIME 1452683328.86567
VALUE alive
Rawmsg:
Dblog:
TIME 1452701425.7996
VALUE A0C4EA641345322FAFAFA014D00::-66:CUL1
Rssi:
Dblog:
TIME 1452701425.7996
VALUE -66
Battery:
Dblog:
TIME 1452701425.7996
VALUE ok
Contact:
Dblog:
TIME 1452701425.7996
VALUE closed (to CUL1)
State:
Dblog:
TIME 1452712127.85017
VALUE closed
Trigdst_fafafa:
Dblog:
TIME 1452701425.7996
VALUE noConfig
Trigger_cnt:
Dblog:
TIME 1452701425.7996
VALUE 77
Readings:
2016-01-13 12:08:48 Activity alive
2016-01-13 11:05:48 CommandAccepted yes
2016-01-13 11:05:47 D-firmware 2.4
2016-01-13 11:05:47 D-serialNr LEQ1251278
2016-01-13 11:05:47 R-pairCentral set_0xFAFAFA
2016-01-13 11:57:23 R-wall.thermostat.Wohnkeller_WindowRec-expectAES set_off
2016-01-13 11:57:23 R-wall.thermostat.Wohnkeller_WindowRec-peerNeedsBurst set_on
2016-01-13 11:06:17 alive yes
2016-01-13 17:10:25 battery ok
2016-01-13 17:10:25 contact closed (to CUL1)
2016-01-13 11:06:17 cover closed
2016-01-13 11:06:17 recentStateType info
2016-01-13 17:10:25 state closed
2016-01-13 17:10:25 trigDst_FAFAFA noConfig
2016-01-13 17:10:25 trigger_cnt 77
Regl_00.:
VAL
Helper:
HM_CMDNR 78
cSnd 01FAFAFA345322010135B6D20300,01FAFAFA34532200040000000000
getCfgList all
getCfgListNo ,4
mId 0030
rxType 4
Expert:
def 1
det 1
raw 1
tpl 0
Io:
newChn +345322,00,00,00
nextSend 1452701425.78282
prefIO
rxt 0
vccu
p:
345322
00
00
00
Mrssi:
mNo 4E
Io:
CUL1 -64
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO CUL1
flg A
ts 1452701425.68734
ack:
HASH(0x2ba00f0)
4E8002FAFAFA34532200
Rssi:
At_cul1:
avg -70
cnt 59
lst -66
max -63
min -79
Shadowreg:
RegL_04.wall.thermostat.Wohnkeller_WindowRec 01:01
Attributes:
DbLogInclude CUL1_RSSI,state
IODev CUL1
actCycle 028:00
actStatus alive
alias Fenstersensor (rechts) - Wohnkeller
autoReadReg 4_reqStatus
devStateIcon open:fts_window_2w_open_r@red closed:fts_window_2w@green tilted:fts_window_2w_tilt_r@yellow
expert 3_allReg+raw
firmware 2.4
group Fenstersensor - Geräte
icon fts_window_2w
model HM-SEC-RHS
room Fenster/Türen
subType threeStateSensor
interessant könnten hier folgende Zeilen sein:
2016-01-13 11:57:23 R-wall.thermostat.Wohnkeller_WindowRec-expectAES set_off
2016-01-13 11:57:23 R-wall.thermostat.Wohnkeller_WindowRec-peerNeedsBurst set_on
Das Wandthermostat:
Internals:
CFGFN
DEF 35B6D203
NAME wall.thermostat.Wohnkeller_WindowRec
NR 39
NTFY_ORDER 50-wall.thermostat.Wohnkeller_WindowRec
STATE last:trigLast
TYPE CUL_HM
chanNo 03
device wall.thermostat.Wohnkeller
peerList window.sensor.Wohnkeller,
CHANGETIME:
Readings:
2015-10-07 22:32:48 R-sign off
2016-01-13 17:30:09 R-window.sensor.Wohnkeller_chn-01-shCtValLo 50
2016-01-13 17:30:09 R-window.sensor.Wohnkeller_chn-01-winOpnTemp 10 C
2016-01-13 17:30:07 RegL_01. 08:00 00:00
2016-01-13 17:30:09 RegL_03.window.sensor.Wohnkeller_chn-01 04:32 00:00
2016-01-13 17:30:09 RegL_07.window.sensor.Wohnkeller_chn-01 05:14 00:00
2016-01-13 17:30:07 peerList window.sensor.Wohnkeller,
2016-01-13 17:30:07 state unknown
Helper:
peerIDsRaw ,34532201,00000000
Expert:
def 1
det 1
raw 1
tpl 0
Role:
chn 1
Shadowreg:
Attributes:
DbLogExclude .*
event-on-change-reading .*
model HM-TC-IT-WM-W-EU
peerIDs 00000000,34532201,
room hidden
stateFormat last:trigLast
interessant sicherlich auch folgende Zeile:
2016-01-13 17:30:07 state unknown
dann noch das HMInfo:
configCheck done:
missing register list
window.sensor.Wohnkeller: RegL_00.,RegL_01.
Register changes pending
window.sensor.Wohnkeller
peer list incomplete. Use getConfig to read it.
incomplete: window.sensor.Wohnkeller:
peer not verified. Check that peer is set on both sides
wall.thermostat.Wohnkeller_WindowRec p:window.sensor.Wohnkeller
peering strange - likely not suitable
smokeDetector.Vorkeller not peered!! add SD to any team !!
trigger sent to undefined device
triggerUndefined: window.sensor.Wohnkeller:FAFAFA
wenn jetzt dann noch jemand eine Idee hätte...
Danke!
Zitat von: DerFrickler am 13 Januar 2016, 17:24:38
...nur kann man diese auch beim schliessen des Fensters anheben, bzw. zurück auf den Wert der Zeitsteuerung setzen?
Wenn die Absenkung funktioniert sollte der Rückweg eigentlich von alleine funktionieren.
automatische Grüße
Niels
Zitat von: Muschelpuster am 13 Januar 2016, 22:17:52
Wenn die Absenkung funktioniert sollte der Rückweg eigentlich von alleine funktionieren.
Der Auto-Modus bleibt erhalten, somit wird der abgesenkte Wert erst mit dem nächsten Schaltzyklus geändert und ist damit zurück auf dem Wert aus dem Temperaturprogramm.
Mittwoch: 06:00 16.0 12:00 19.0 14:00 16.0 22:00 19.0 24:00 16.0
1. Fenster auf, Temperatur von 19°C auf 10°C
2. 22:00 gemäß Programm Umschaltung der desired-temp auf 16°C
3. 22:36 die Frau öffnet (bz. kippt) das Fenster und die desired-temp geht zurück auf 10°C
4. 22:56 die Frau schliesst das Fenster und die desired-temp bleibt auf 10°C
ich gehe mal davon aus dass gemäß Programm um 24:00 die desired-temp auf 16°C umgestellt wird.
d.h., wenn ich hier nicht manuell eingreife wird das vor dem nächsten Schaltvorgang nichts
hast du die hminfo fehler mal abgearbeitet?
Also was ich in diesem ganzen Prozess schmerzhaft gelernt habe ist der Fakt, dass die HM-Geräte ja nicht unbedingt die Programmierung gefressen haben, nur weil ich die Programmierung vorgenommen habe. Es sollten auf jeden Fall in den Internals unter protCmdPend keine Befehle mehr auf ihre Ausführung warten und unter protState
sollte CMDs_done stehen. Das kann man z.T. durch set burstXmit erreichen und z.T. durch Auslösen der Konfig-Funktion am Gerät. Wenn das alles nichts hilft, dann kommt ein set clear msgEvents zum Einsatz - gefolgt von einem set getConfig. Wenn dann der Status CMDs_done ist, dann sieht man, was das Gerät wirklich gefressen hat und kann die fehlenden Settings erneut übermitteln. Aber nicht zu viel in einem Rutsch - immer schon häppchenweise und auf die Abarbeitung der Kommandos warten bzw. diese anstoßen.
gemächliche Grüße
Niels
Zitat von: frank am 14 Januar 2016, 00:52:36
hast du die hminfo fehler mal abgearbeitet?
Nein, dazu könnte ich etwas Hilfe gebrauchen. Es erscheint mir aber auch als ob die Problematik mit der Nicht-Abarbeitung der CMDs zusammen hängen könnte.
Zitat von: Muschelpuster am 14 Januar 2016, 10:05:00
Es sollten auf jeden Fall in den Internals unter protCmdPend keine Befehle mehr auf ihre Ausführung warten und unter protState
sollte CMDs_done stehen.
Das ist aktuell der Fall, nur muss ich zugeben dass es auch Time-Outs während der Programmierung gab. Nach einem grundsätzlichen Anlernen mache ich im allgemeinen die weitere Programmierung vom Arbeitszimmer aus. Dazwischen befinden sich dann 2 Etagen. Bisher hatte ich die Situation noch nicht dass ich zur Abarbeitung der CMDs ständig das Device bedienen musste.
Zitat von: Muschelpuster am 14 Januar 2016, 10:05:00
Das kann man z.T. durch set burstXmit erreichen und z.T. durch Auslösen der Konfig-Funktion am Gerät. Wenn das alles nichts hilft, dann kommt ein set clear msgEvents zum Einsatz - gefolgt von einem set getConfig. Wenn dann der Status CMDs_done ist, dann sieht man, was das Gerät wirklich gefressen hat und kann die fehlenden Settings erneut übermitteln. Aber nicht zu viel in einem Rutsch - immer schon häppchenweise und auf die Abarbeitung der Kommandos warten bzw. diese anstoßen.
Demnach würde ein "set window.sensor.Wohnkeller burstXmit" das Drehen am Fenstergriff ersetzen? Das muss dann nach jedem CMD der Programmierung gemacht werden?
Reicht es die Programmierung
1. Das peeren
set window.sensor.Wohnkeller peerChan 0 wall.thermostat.Wohnkeller_WindowRec single set
2. Das Absenken der Temperatur
set wall.thermostat.Wohnkeller_WindowRec regSet winOpnTemp 10 window.sensor.Wohnkeller
jeweils gefolgt von einem set window.sensor.Wohnkeller burstXmit bzw. set wall.thermostat.Wohnkeller burstXmit
zu überschreiben? Oder ist es besser die bestehende Programmierung vorher rückgängig zu machen?
Gruß und Danke!
-----------------------------------------------------------------
Edit:
dann sind da noch folgende Einträge beim Fenster Sensor:
2016-01-13 11:05:47 R-pairCentral set_0xFAFAFA
2016-01-13 11:57:23 R-wall.thermostat.Wohnkeller_WindowRec-expectAES set_off
2016-01-13 11:57:23 R-wall.thermostat.Wohnkeller_WindowRec-peerNeedsBurst set_on
Ich habe mal im Forum danach gesucht...
zu R-pairCentral:
fehlt hier noch ein "set <FensterkontaktName> regSet pairCentral <hmId>"? bevor ich das peering mit dem Wandthermostat durchführe?
ZitatBisher hatte ich die Situation noch nicht dass ich zur Abarbeitung der CMDs ständig das Device bedienen musste.
der rhs muss immer "bedient" werden. der kann nur configmode (taste drücken), auch kein burst. sonst schläft der halt.
regelmässig aufwachende batterie-devices können meist auch wakeupmode. mit geduld ist irgendwann alles abgearbeitet.
burst muss man, sofern es das überhaupt gibt, meistens erst im device freischalten.
mit get hminfo models sieht man, was jedes model kann.
laut Wiki ist das Pairing nicht korrekt abgeschlossen worden:
Pairing nicht abgeschlossen (bei den Readings "PairedTo" bzw. "R-pairCentral" steht der Wert set_0x1A2B3C). Das Pairing ist erst dann erfolgreich abgeschlossen, wenn das set_ fehlt, also nur noch (beispielhaft) "0x1A2B3C" steht. Siehe HomeMatic_Devices_pairen
Ich denke mal ich werde mich zuerst mal damit beschäftigen.
Edit:
Habe ich durch ein erneutes Pairing gelöst. Laut ConfigCheck verbleiben noch:
peer not verified. Check that peer is set on both sides
wall.thermostat.Wohnkeller_WindowRec p:window.sensor.Wohnkeller
peering strange - likely not suitable
smokeDetector.Vorkeller not peered!! add SD to any team !!
trigger sent to undefined device
triggerUndefined: window.sensor.Wohnkeller:FAFAFA
Edit2:
mit "set window.sensor.Wohnkeller peerChan 0 wall.thermostat.Wohnkeller_WindowRec single set" erscheint..
1. im Kanal wall.thermostat.Wohnkeller_WindowRec peerList mit window.sensor.Wohnkeller und peerIDs mit 00000000,34532201
2. im window.sensor.Wohnkeller peerChan überhaupt nicht und peerIDs mit 00000000
jetzt stelle ich mal eine Vermutung auf:
ConfigCheck ergibt:
Register changes pending
window.sensor.Wohnkeller
möglicherweise bezieht sich das auf:
2016-01-13 11:57:23 R-wall.thermostat.Wohnkeller_WindowRec-expectAES set_off
2016-01-13 11:57:23 R-wall.thermostat.Wohnkeller_WindowRec-peerNeedsBurst set_on
und diese Register changes müssen erst durchgeführt werden um die peering Problematik zu lösen?
Eine weitere Beobachtung die ich gemacht habe ist folgende:
mache ich für den Fenstersensor ein getConfig, verschwinden die Register RegL_00. und RegL_01.
Beide erscheinen erst wieder wenn ich ein erneutes Pairing durchführe.
missing register list
window.sensor.Wohnkeller: RegL_00.,RegL_01.
Hat jemand eine Idee wie hier am besten vorzugehen ist?
Danke!
Zitat1. im Kanal wall.thermostat.Wohnkeller_WindowRec peerList mit window.sensor.Wohnkeller und peerIDs mit 00000000,34532201
ok
Zitat2. im window.sensor.Wohnkeller peerChan überhaupt nicht und peerIDs mit 00000000
jetzt stelle ich mal eine Vermutung auf:
ConfigCheck ergibt:
Register changes pending
window.sensor.Wohnkeller
du musst natürlich weiterhin auf den taster am fk drücken, wie bereits gesagt, sonst kann er das peering nicht abarbeiten. bei jedem pending bis cmds_done. wenn done_error, dann befehl wiederholen.
ZitatEine weitere Beobachtung die ich gemacht habe ist folgende:
mache ich für den Fenstersensor ein getConfig, verschwinden die Register RegL_00. und RegL_01.
Beide erscheinen erst wieder wenn ich ein erneutes Pairing durchführe.
auch hier taster drücken, nicht neu pairen, wenn das pairing bereits ok war.
Zitat von: frank am 14 Januar 2016, 18:31:42
ok
du musst natürlich weiterhin auf den taster am fk drücken, wie bereits gesagt, sonst kann er das peering nicht abarbeiten. bei jedem pending bis cmds_done. wenn done_error, dann befehl wiederholen.
Ich denke mit Taster drücken meinst Du den Fenstergriff bewegen. Das habe ich gemacht, mit der linken Hand am Laptop und der rechten am Griff; sowohl das Wandthermostat als auch der Fenstersensor zeigen beide CMDs_done. Leider ohne Erfolg, im Fenstersensor fehlt immer noch das Wandthermostat in der Peer-Liste.
Gruß!
Das Kommando zum peeren absetzen und config drücken.
Config lesen und config drücken
ich will diese Frage nochmal in die Runde werfen:
Zitat von: Muschelpuster am 09 Dezember 2015, 23:44:38Ist der Pairing-Weg überhaupt sinnvoll, oder macht es mehr Sinn, das Pairing zwischen Türsensor und Ventil durchzuführen, damit dann das Ventil den Wandthermostaten darüber informiert.
Anders herum wäre es doch zügiger: Der Sensor informiert das Ventil, welches runter fährt und den Wandthermostat informiert? Zumindest wenn man nur ein Ventil hat...
Oder kann man auch beide Geräte pairen?
nachgehakte Grüße
Niels
Wieso sollte das ventil das wandthermostat informieren?
Peere einfach beide mit dem rhs
Zitat von: martinp876 am 14 Januar 2016, 19:44:06
Das Kommando zum peeren absetzen und config drücken.
Config lesen und config drücken
Was meinst Du mit Config drücken? Am Fenster-Drehgriffkontakt befindet sich lediglich eine Anlerntaste. Ansonsten ist da noch die Möglichkeit den Fenstergriff zu drehen um das Abarbeiten der CMDs zu handhaben. Das habe ich auch so gemacht.
Zu der Sache mit dem "R-wall.thermostat.Wohnkeller_WindowRec-peerNeedsBurst set_on" kann ich das beim HM-SEC-RHS genauso wie beim HM-SEC-SC bewerkstelligen=
set <HM-SEC-SC> regSet peerNeedsBurst on <RT_oder_TC>_WindowRec
Gruß!
Edit:
laut wiki Eintrag "HomeMatic Type ThreeState":
Bei HM-SEC-SC und HM-SEC-RHS z.B. kann man die Register nur beschreiben, indem der Anlernknopf im Batteriefach gedrückt wird.
Zitat von: martinp876 am 14 Januar 2016, 19:44:06
Das Kommando zum peeren absetzen und config drücken.
Config lesen und config drücken
wenn man config drücken durch "Anlerntaste mit spitzen Gegenstand drücken" ersetzt, dann passt es.
Vielen Dank!
Zitat von: frank am 14 Januar 2016, 13:33:02
der rhs muss immer "bedient" werden. der kann nur configmode (taste drücken), auch kein burst.
der rhs hat genau
eine taste. :)
Zitat von: martinp876 am 14 Januar 2016, 20:07:12Peere einfach beide mit dem rhs
Ah, ok, da habe ich die Systemfähigkeiten unterschätzt und nicht erwartet dass ein mehrfaches Pairing möglich ist.
unterbewertete Grüße
Niels