Hallo zusammen,
ich habe letzte Woche ein HM Thermostat (HM-CC-RT-DN) in Betrieb genommen.
Habe mir einen Notify & Watchdog gebaut, welcher beim Fenster öffnen Temperatur senkt (auch bei Abwesenheit usw.).
Soweit so gut.
Doch nun sehe ich im Logfile, dass meine Temperatur sporadisch immer wieder einfach auf die 20°C zurück gestellt wird.
Auszug Logfile:
2017.09.17 22:17:08 2: ROOMMATE set Dominik gotosleep
2017.09.17 22:17:08 3: CUL_HM set Heizung_WZ_Links desired-temp 18.5
2017.09.17 22:17:08 3: CUL IT_set: Kaffee_Strom off
2017.09.17 22:17:09 3: CUL IT_set: sw_couch2 off
2017.09.17 22:17:10 3: CUL IT_set: LED_TV off
2017.09.17 22:17:10 3: CUL IT_set: Stehlampe on
2017.09.17 22:17:16 3: CUL IT_set: Nachttischlampe on
2017.09.17 22:17:21 3: CUL IT_set: Balkonbeleuchtung off
2017.09.17 22:22:17 3: CUL IT_set: Stehlampe off
2017.09.17 22:52:58 3: CUL_HM set Heizung_WZ_Links desired-temp 20.0
2017.09.17 22:52:58 3: CUL_HM set Heizung_WZ_Links burstXmit
2017.09.17 23:44:38 3: CUL_HM set Heizung_WZ_Links desired-temp 20.0
2017.09.17 23:44:38 3: CUL_HM set Heizung_WZ_Links burstXmit
2017.09.18 00:45:33 3: CUL_HM set Heizung_WZ_Links desired-temp 20.0
2017.09.18 00:45:33 3: CUL_HM set Heizung_WZ_Links burstXmit
2017.09.18 01:39:12 3: CUL_HM set Heizung_WZ_Links desired-temp 20.0
2017.09.18 01:39:12 3: CUL_HM set Heizung_WZ_Links burstXmit
2017.09.18 02:40:32 3: CUL_HM set Heizung_WZ_Links desired-temp 20.0
2017.09.18 02:40:32 3: CUL_HM set Heizung_WZ_Links burstXmit
2017.09.18 03:36:37 3: CUL_HM set Heizung_WZ_Links desired-temp 20.0
2017.09.18 03:36:37 3: CUL_HM set Heizung_WZ_Links burstXmit
2017.09.18 04:29:16 3: CUL_HM set Heizung_WZ_Links desired-temp 20.0
2017.09.18 04:29:16 3: CUL_HM set Heizung_WZ_Links burstXmit
2017.09.18 05:28:38 3: CUL_HM set Heizung_WZ_Links desired-temp 20.0
2017.09.18 05:28:38 3: CUL_HM set Heizung_WZ_Links burstXmit
Besonders wenn ich ins Bett gehe -> Temp wird auf 18.5 gesenkt.
Dann, während der ganzen Nacht steigt diese wieder auf 20°C an. Oder sinkt tagsüber auf 20°C, falls ich einmal 21°C eingestellt habe.
Die Frage ist warum? Das Thermostat läuft auf "manuell".
Es ist kein Notify vorhanden welcher ausgelöst wurde und die Temperatur von 20°C einspielt.
Wie könnte ich denn an die Ursache kommen?
Hallo,
Zitat von: d0m2011 am 18 September 2017, 10:37:53
Habe mir einen Notify & Watchdog gebaut, welcher beim Fenster öffnen Temperatur senkt (auch bei Abwesenheit usw.).
...
Es ist kein Notify vorhanden welcher ausgelöst wurde und die Temperatur von 20°C einspielt.
Wie könnte ich denn an die Ursache kommen?
Na irgendwas triggert schon. Wie sieht denn das Notify und der Watchdog aus?
Von alleine kommt das nicht ;)
Edit:
ZitatDie Frage ist warum? Das Thermostat läuft auf "manuell".
das ist egal. Wenn ein Notify oder ähnliches den Befehl gibt, die Temperatur anzupassen wird das auch im manuellen Modus gemacht.
hm da hast du wohl Recht, alleine wird das nicht passieren ;)
Watchdog Fenster offen:
Fenster_WZ_Links:open.* 00:00:05 Fenster_WZ_Links:closed.* { fhem("set Temperatur_WZ_Fenster " . ReadingsVal("Heizung_WZ_Links","desired-temp","") . "; set Heizung_WZ_Links desired-temp 14; set Heizung_WZ_Links burstXmit; setstate Fenster_WZ_Links_open defined")}
Ich schreibe die aktuelle Temperatur weg und hole sie dann wieder mit dem Notify Fenster geschlossen:
Fenster_WZ_Links:closed set Heizung_WZ_Links desired-temp [Temperatur_WZ_Fenster:state]; set Heizung_WZ_Links burstXmit
Falls ich jedoch ins Bett gehe oder Abwesend bin schreibe ich die Temperatur (zuletzt eingestellt) auch in einen Dummy:
Bewohner:gotosleep { fhem("set Temperatur_WZ " . ReadingsVal("Heizung_WZ_Links","desired-temp","") . "; set Heizung_WZ_Links desired-temp [Temperatur_WZ_abgesenkt:state];
Diese hole ich mir dann wieder sobald ich aufwache oder nach Hause komme:
Bewohner:home set Heizung_WZ_Links desired-temp [Temperatur_WZ:state];
Aber die Log zeigt ja, dass der Status der Bewohner über Nacht nicht geändert wurde.
Genau das macht mir stutzig... :-\
Hi,
geh in Edit Files, dann fhem.cfg, dann ctrl-f und "set Heizung_WZ_Links" eingeben und die Suche solange wiederholen bis Du die fragliche Routine gefunden hast.
Oder es kommt von "aussen"? Webschnittstelle FHEM2FHEM ...?
Gruß Otto
Ah sehr guter Tipp, danke.
Nichts gefunden, leider.
Es ist gerade schon wieder passiert. Liegt es vielleicht an der Config vom Thermostat?
Ich hab' im Event Monitor gesehen, dass FHEM vorher ein get config auf das Thermostat gemacht hat.
Nein, FHEM 2 FHEM wird nicht genutzt.
verschiebe den Thread besser nach Homematic ...
hi das Problem habe ich auch,
desired-temp-manu 6.0
das was dort eingestellt ist, stellt sich immer wieder ein, ich habe eine Kontrolle laufen die alle Stunde kontrolliert ob,
der wert wie gefordert ist, sonst wird er wieder auf den geforderten wert gestellt.
das ist aber nicht nur bei HM so, auch das FS20 stellt sich immer wieder auf den falschen wert ein (desired-temp-manu).
ich habe noch nicht herausgefunden warum sich der wert nicht einstellt. beim drehen am Rad wird der wert verändert, aber nur dann...
Guss
Ah okay aber den Wert desire-temp-manu habe ich gar nicht.
Siehe List, ich habe nur desired-temp
Internals:
.triggerUsed 1
DEF 568EAA04
NAME Heizung_WZ_Links
NOTIFYDEV global
NR 119
NTFY_ORDER 50-Heizung_WZ_Links
STATE T: 22.3 desired: 21.0 valve: 6
TYPE CUL_HM
chanNo 04
device HM_568EAA
Readings:
2017-09-13 15:30:49 .R-boostPeriod 5 min
2017-09-13 15:30:49 .R-decalcTime 11:00
2017-09-13 15:30:49 .R-decalcWeekday Sat
2017-09-13 15:30:49 .R-reguExtI 15
2017-09-13 15:30:49 .R-reguExtP 30
2017-09-13 15:30:49 .R-reguExtPstart 30
2017-09-13 15:30:49 .R-reguIntI 15
2017-09-13 15:30:49 .R-reguIntP 30
2017-09-13 15:30:49 .R-reguIntPstart 30
2017-09-13 15:30:49 .R-showWeekday off
2017-09-13 15:30:49 .R-tempMax 30.5 C
2017-09-13 15:30:49 .R-tempMin 4.5 C
2017-09-13 15:30:49 .R-valveErrPos 15 %
2017-09-13 15:30:49 .R-valveMaxPos 100 %
2017-09-13 15:30:49 .R-winOpnDetFall 1.4 K
2017-09-13 15:30:49 .R-winOpnMode off
2017-09-13 15:30:49 .R-winOpnPeriod 15 min
2017-09-13 15:30:49 .R-winOpnTemp 12 C
2017-09-18 11:43:09 .peerListRDate 2017-09-18 11:43:09
2017-09-18 11:03:56 CommandAccepted yes
2017-09-13 15:30:49 R-boostPos 80 %
2017-09-13 15:30:49 R-btnNoBckLight off
2017-09-13 15:30:49 R-dayTemp 21 C
2017-09-13 15:30:49 R-daylightSaveTime on
2017-09-13 15:30:49 R-modePrioManu all
2017-09-13 15:30:49 R-modePrioParty all
2017-09-13 15:30:49 R-nightTemp 17 C
2017-09-13 15:30:49 R-noMinMax4Manu off
2017-09-13 15:30:49 R-regAdaptive on
2017-09-13 15:30:49 R-showInfo time
2017-09-13 15:30:45 R-sign off
2017-09-13 15:30:49 R-tempOffset 0.0K
2017-09-13 15:30:49 R-valveOffsetRt 0 %
2017-09-13 15:30:49 R-winOpnBoost off
2017-09-18 11:43:13 R_0_tempListSat 06:00 17.0 22:00 21.0 24:00 17.0
2017-09-18 11:43:13 R_1_tempListSun 06:00 17.0 22:00 21.0 24:00 17.0
2017-09-18 11:43:13 R_2_tempListMon 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017-09-18 11:43:13 R_3_tempListTue 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017-09-18 11:43:13 R_4_tempListWed 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017-09-18 11:43:13 R_5_tempListThu 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017-09-18 11:43:13 R_6_tempListFri 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017-09-18 11:43:13 R_tempList_State verified
2017-09-18 11:43:09 RegL_01. 08:00 00:00
2017-09-18 11:43:13 RegL_07. 01:2A 02:22 03:09 04:3D 05:18 06:03 07:00 08:16 09:07 0A:30 0B:00 0C:64 0D:0F 0E:05 0F:00 10:00 11:00 12:09 13:0E 14:44 15:48 16:55 17:08 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:44 2F:48 30:55 31:08 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:44 49:48 4A:54 4B:6C 4C:44 4D:CC 4E:55 4F:08 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:44 63:48 64:54 65:6C 66:44 67:CC 68:55 69:08 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:44 7D:48 7E:54 7F:6C 80:44 81:CC 82:55 83:08 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:44 97:48 98:54 99:6C 9A:44 9B:CC 9C:55 9D:08 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:44 B1:48 B2:54 B3:6C B4:44 B5:CC B6:55 B7:08 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:0F CB:1E CC:1E CD:0F CE:1E CF:1E 00:00
2017-09-18 11:43:08 ValvePosition 6
2017-09-18 11:43:08 boostTime -
2017-09-18 11:43:08 controlMode manual
2017-09-18 11:43:08 desired-temp 21.0
2017-09-18 11:43:08 measured-temp 22.3
2017-09-18 11:43:08 partyEnd -
2017-09-18 11:43:08 partyStart -
2017-09-18 11:43:08 partyTemp -
2017-09-18 11:03:56 recentStateType ack
2017-09-18 11:43:08 state T: 22.3 desired: 21.0 valve: 6
Helper:
peerIDsRaw ,00000000
Expert:
def 1
det 0
raw 1
tpl 0
Prt:
brstWu 1
Role:
chn 1
Shregr:
07 00
Shadowreg:
Attributes:
icon max_heizungsthermostat
model HM-CC-RT-DN
peerIDs 00000000,
room Wohnzimmer
Beobachte Mal die Events vom Fensterkontakt. Sicherlich wirft der state ständig ein Event.
Abhilfe schafft event-on-change-reading
Hi CoolTux,
danke für den Tipp.
Wie mache ich das am besten?
die Zauberwaffe von FHEM -> https://wiki.fhem.de/wiki/Event_monitor
;D
Der wert ist bei HM Chanel 2
ich habe es auch grade noch mal getestet, die Fenster Kontakte habe damit nichts zutun,
wenn ich am Rad auf manuell off stelle, verstellt sich der wert und bleibt auch so.
Vor einiger Zeit habe ich es auch ohne Fenster Kontakte Probiert und der wert verstellt sich auch dan,
ich vermute wen der wert extern verstellt wird, wird er im HM nicht geändert, desired-temp-manu bleibt
so bestehen, (man kann ihn auch nicht über FHEM verändern)
Guss
Eben schon wieder passiert:
2017-09-18 11:57:09 CUL_HM HM_568EAA CMDs_pending
2017-09-18 11:57:09 CUL_HM HM_568EAA CMDs_pending
2017-09-18 11:57:09 CUL_HM Heizung_WZ_Links set_desired-temp 20.0
2017-09-18 11:57:09 CUL_HM Heizung_WZ_Links set_desired-temp 20.0
2017-09-18 11:57:09 CUL_HM Fenster_WZ_Links alive: yes
2017-09-18 11:57:09 CUL_HM Fenster_WZ_Links battery: ok
2017-09-18 11:57:09 CUL_HM Fenster_WZ_Links contact: closed (to broadcast)
2017-09-18 11:57:09 CUL_HM Fenster_WZ_Links sabotageError: off
2017-09-18 11:57:09 CUL_HM Fenster_WZ_Links closed
2017-09-18 11:57:10 CUL_HM HM_568EAA battery: ok
2017-09-18 11:57:10 CUL_HM HM_568EAA desired-temp: 20.0
2017-09-18 11:57:10 CUL_HM Heizung_WZ_Links boostTime: -
2017-09-18 11:57:10 CUL_HM Heizung_WZ_Links controlMode: manual
2017-09-18 11:57:10 CUL_HM Heizung_WZ_Links desired-temp: 20.0
2017-09-18 11:57:10 CUL_HM Heizung_WZ_Links partyEnd: -
2017-09-18 11:57:10 CUL_HM Heizung_WZ_Links partyStart: -
2017-09-18 11:57:10 CUL_HM Heizung_WZ_Links partyTemp: -
2017-09-18 11:57:10 CUL_HM Heizung_WZ_Links T: 22.3 desired: 20.0 valve: 6
2017-09-18 11:57:10 CUL_HM HM_568EAA battery: ok
2017-09-18 11:57:10 CUL_HM HM_568EAA desired-temp: 20.0
2017-09-18 11:57:10 CUL_HM HM_568EAA CMDs_done
Vom Fensterkontakt kommt leider nichts.
Zitat von: eisman am 18 September 2017, 11:58:28
Der wert ist bei HM Chanel 2
ich habe es auch grade noch mal getestet, die Fenster Kontakte habe damit nichts zutun,
wenn ich am Rad auf manuell off stelle, verstellt sich der wert und bleibt auch so.
Vor einiger Zeit habe ich es auch ohne Fenster Kontakte Probiert und der wert verstellt sich auch dan,
ich vermute wen der wert extern verstellt wird, wird er im HM nicht geändert, desired-temp-manu bleibt
so bestehen, (man kann ihn auch nicht über FHEM verändern)
Guss
Meine Aussage basiert auf die Daten welche d0m2011 mir zur Verfügung gestellt hat. Es kann sein das ich mich da irre, dennoch würde ich darum bitten nicht so voreilig Deine Beobachtungen von Deinem System auf andere zu übertragen und pauschal zu behaupten "der Fensterkontakt habe damit nichts zu tun"
Also er stellt wirklich immer wieder diesen Wert ein, der mal am Rad eingestellt war.
Habe auch 21 erhöht und jetzt stellt er immer wieder auf 21°C um.
2017-09-18 12:01:03 CUL_HM HM_568EAA actuator: 5
2017-09-18 12:01:03 CUL_HM HM_568EAA battery: ok
2017-09-18 12:01:03 CUL_HM HM_568EAA batteryLevel: 3.1
2017-09-18 12:01:03 CUL_HM HM_568EAA desired-temp: 21.0
2017-09-18 12:01:03 CUL_HM HM_568EAA measured-temp: 22.4
2017-09-18 12:01:03 CUL_HM HM_568EAA motorErr: ok
2017-09-18 12:01:03 CUL_HM HM_568EAA_Weather measured-temp: 22.4
2017-09-18 12:01:03 CUL_HM HM_568EAA_Weather 22.4
2017-09-18 12:01:03 CUL_HM Heizung_WZ_Links ValvePosition: 5
2017-09-18 12:01:03 CUL_HM Heizung_WZ_Links boostTime: -
2017-09-18 12:01:03 CUL_HM Heizung_WZ_Links controlMode: manual
2017-09-18 12:01:03 CUL_HM Heizung_WZ_Links desired-temp: 21.0
2017-09-18 12:01:03 CUL_HM Heizung_WZ_Links measured-temp: 22.4
2017-09-18 12:01:03 CUL_HM Heizung_WZ_Links partyEnd: -
2017-09-18 12:01:03 CUL_HM Heizung_WZ_Links partyStart: -
2017-09-18 12:01:03 CUL_HM Heizung_WZ_Links partyTemp: -
2017-09-18 12:01:03 CUL_HM Heizung_WZ_Links T: 22.4 desired: 21.0 valve: 5
Warum habe ich eigentlich zwei Devices welche eine desired-temp haben?
Das würde Dir ein list HM_568EAA verraten.
Internals:
CUL868_MSGCNT 105
CUL868_RAWMSG A0FD98610568EAA0000000AA0E1100040::-51.5:CUL868
CUL868_RSSI -51.5
CUL868_TIME 2017-09-18 12:06:03
DEF 568EAA
IODev CUL868
LASTInputDev CUL868
MSGCNT 105
NAME HM_568EAA
NOTIFYDEV global
NR 115
NTFY_ORDER 50-HM_568EAA
STATE CMDs_done
TYPE CUL_HM
channel_01 HM_568EAA_Weather
channel_02 HM_568EAA_Climate
channel_04 Heizung_WZ_Links
channel_05 HM_568EAA_ClimaTeam
channel_06 HM_568EAA_remote
lastMsg No:D9 - t:10 s:568EAA d:000000 0AA0E1100040
protLastRcv 2017-09-18 12:06:03
protSnd 68 last_at:2017-09-18 12:03:36
protState CMDs_done
rssi_CUL868 lst:-57 avg:-55.58 cnt:24 min:-59 max:-51
rssi_at_CUL868 lst:-51.5 cnt:105 max:-49 min:-62.5 avg:-54.8
Readings:
2017-09-13 15:29:46 .D-devInfo 00FFFF
2017-09-13 15:29:46 .D-stc 59
2017-09-13 15:30:43 .R-btnLock off
2017-09-13 15:30:43 .R-globalBtnLock off
2017-09-13 15:30:43 .R-localResDis off
2017-09-13 15:30:43 .R-lowBatLimitRT 2.1 V
2017-09-13 18:10:13 .R-modusBtnLock on
2017-09-18 12:06:03 .protLastRcv 2017-09-18 12:06:03
2017-09-18 10:33:36 Activity alive
2017-09-18 12:03:36 CommandAccepted yes
2017-09-13 15:29:46 D-firmware 1.4
2017-09-13 15:29:46 D-serialNr OEQ0246340
2017-09-13 18:10:13 PairedTo 0xF10000
2017-09-13 15:30:43 R-backOnTime 10 s
2017-09-13 15:30:43 R-burstRx on
2017-09-13 15:30:43 R-cyclicInfoMsg on
2017-09-13 15:30:43 R-cyclicInfoMsgDis 0
2017-09-13 15:30:43 R-pairCentral 0xF10000
2017-09-13 18:10:13 RegL_00. 01:01 02:01 09:01 0A:F1 0B:00 0C:00 0E:0A 0F:00 11:00 12:15 16:01 18:00 19:00 1A:C8 00:00
2017-09-18 12:06:03 actuator 0
2017-09-18 12:06:03 battery ok
2017-09-18 12:06:03 batteryLevel 3.1
2017-09-18 12:06:03 desired-temp 20.0
2017-09-18 12:06:03 measured-temp 22.5
2017-09-18 12:06:03 motorErr ok
2017-09-18 12:03:36 state CMDs_done
2017-09-18 09:11:56 time-request -
Regl_07.:
VAL
Helper:
HM_CMDNR 217
cSnd 11F10000568EAA860428,11F10000568EAA860428
mId 0095
rxType 140
supp_Pair_Rep 0
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +568EAA,00,00,00
nextSend 1505729163.95158
prefIO
rxt 2
vccu
p:
568EAA
00
00
00
Mrssi:
mNo D9
Io:
CUL868 -49.5
Prt:
awake 0
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
prs 1
Rssi:
Cul868:
avg -55.5833333333333
cnt 24
lst -57
max -51
min -59
At_cul868:
avg -54.8
cnt 105
lst -51.5
max -49
min -62.5
Shregw:
07 04
Attributes:
IODev CUL868
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
model HM-CC-RT-DN
room CUL_HM
serialNr OEQ0246340
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
Ich hab irgendwie die Vermutung zwei Devices zu haben?!?
Was ist mit dem Fensterkontakt?
Vom Fensterkontakt kommt irgendwie gar nichts...
List Fensterkontakt:
Internals:
CUL868_MSGCNT 2
CUL868_RAWMSG A0D0386105A164F00000006010000::-52.5:CUL868
CUL868_RSSI -52.5
CUL868_TIME 2017-09-18 11:57:09
DEF 5A164F
IODev CUL868
LASTInputDev CUL868
MSGCNT 2
NAME Fenster_WZ_Links
NOTIFYDEV global
NR 112
NTFY_ORDER 50-Fenster_WZ_Links
STATE closed
TYPE CUL_HM
lastMsg No:03 - t:10 s:5A164F d:000000 06010000
protCmdPend 3 CMDs pending
protLastRcv 2017-09-18 11:57:09
protResnd 2 last_at:2017-09-18 11:57:13
protSnd 2 last_at:2017-09-18 11:57:09
protState CMDs_pending
rssi_at_CUL868 lst:-52.5 cnt:2 min:-52.5 max:-52 avg:-52.25
Readings:
2017-09-13 15:33:50 .D-devInfo 810101
2017-09-13 15:33:50 .D-stc 80
2017-09-18 11:57:09 .protLastRcv 2017-09-18 11:57:09
2017-09-18 10:33:36 Activity alive
2017-09-13 15:33:50 D-firmware 1.0
2017-09-13 15:33:50 D-serialNr OEQ0429164
2017-09-13 15:33:50 R-pairCentral set_0xF10000
2017-09-13 15:33:50 aesKeyNbr 00
2017-09-18 11:57:09 alive yes
2017-09-18 11:57:09 battery ok
2017-09-18 11:57:09 contact closed (to broadcast)
2017-09-18 11:57:09 recentStateType info
2017-09-18 11:57:09 sabotageError off
2017-09-18 11:57:09 state closed
2017-09-18 07:30:36 trigDst_broadcast noConfig
2017-09-18 07:30:36 trigger_cnt 91
cmdStack:
++A001F100005A164F00040000000000
++A001F100005A164F01040000000001
++A001F100005A164F0103
Helper:
HM_CMDNR 4
getCfgList all
getCfgListNo ,4
mId 00C7
rxType 28
supp_Pair_Rep 0
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +5A164F,02,00,00
nextSend 1505728629.83297
prefIO
rxt 2
vccu
p:
5A164F
00
00
00
Mrssi:
mNo 03
Io:
CUL868 -50.5
Prt:
bErr 0
sProc 2
wuReSent 3
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_cul868:
avg -52.25
cnt 2
lst -52.5
max -52
min -52.5
Attributes:
IODev CUL868
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
icon fts_window_2w_open_l
model HM-SEC-SCo
room Wohnzimmer
serialNr OEQ0429164
subType threeStateSensor
Zitat von: d0m2011 am 18 September 2017, 12:14:26
List Fensterkontakt:
Internals:
protCmdPend 3 CMDs pending
...
2017-09-13 15:33:50 R-pairCentral set_0xF10000
...
Der ist auch noch nicht richtig mit FHEM gepaired.
Wichtig bei den HM-SEC-SCo ist auch, dass du die Befehle immer mit dem ConfigButton bestätigst/überträgst. Nicht einfach nur durch auslösen. Das kann zu Problemen führen glaube ich.
Das verstehe ich nicht. Dann muss irgendwo noch was stehen.
2017.09.17 22:52:58 3: CUL_HM set Heizung_WZ_Links desired-temp 20.0
2017.09.17 22:52:58 3: CUL_HM set Heizung_WZ_Links burstXmit
2017.09.17 23:44:38 3: CUL_HM set Heizung_WZ_Links desired-temp 20.0
2017.09.17 23:44:38 3: CUL_HM set Heizung_WZ_Links burstXmit
2017.09.18 00:45:33 3: CUL_HM set Heizung_WZ_Links desired-temp 20.0
2017.09.18 00:45:33 3: CUL_HM set Heizung_WZ_Links burstXmit
Das stand bei Dir im Log. Nach jedem setzen der desired-temp erfolgte sofort ien burstXmit. Genau das steht einmal in Deinem watchdog un einmal in Deinem Notify, beide triggern auf den Fensterkontakt.
Zitat von: d0m2011 am 18 September 2017, 11:59:27
Eben schon wieder passiert:
2017-09-18 11:57:09 CUL_HM HM_568EAA CMDs_pending
2017-09-18 11:57:09 CUL_HM HM_568EAA CMDs_pending
2017-09-18 11:57:09 CUL_HM Heizung_WZ_Links set_desired-temp 20.0
2017-09-18 11:57:09 CUL_HM Heizung_WZ_Links set_desired-temp 20.0
2017-09-18 11:57:09 CUL_HM Fenster_WZ_Links alive: yes
2017-09-18 11:57:09 CUL_HM Fenster_WZ_Links battery: ok
2017-09-18 11:57:09 CUL_HM Fenster_WZ_Links contact: closed (to broadcast)
2017-09-18 11:57:09 CUL_HM Fenster_WZ_Links sabotageError: off
2017-09-18 11:57:09 CUL_HM Fenster_WZ_Links closed
2017-09-18 11:57:10 CUL_HM HM_568EAA battery: ok
2017-09-18 11:57:10 CUL_HM HM_568EAA desired-temp: 20.0
2017-09-18 11:57:10 CUL_HM Heizung_WZ_Links boostTime: -
2017-09-18 11:57:10 CUL_HM Heizung_WZ_Links controlMode: manual
2017-09-18 11:57:10 CUL_HM Heizung_WZ_Links desired-temp: 20.0
2017-09-18 11:57:10 CUL_HM Heizung_WZ_Links partyEnd: -
2017-09-18 11:57:10 CUL_HM Heizung_WZ_Links partyStart: -
2017-09-18 11:57:10 CUL_HM Heizung_WZ_Links partyTemp: -
2017-09-18 11:57:10 CUL_HM Heizung_WZ_Links T: 22.3 desired: 20.0 valve: 6
2017-09-18 11:57:10 CUL_HM HM_568EAA battery: ok
2017-09-18 11:57:10 CUL_HM HM_568EAA desired-temp: 20.0
2017-09-18 11:57:10 CUL_HM HM_568EAA CMDs_done
Vom Fensterkontakt kommt leider nichts.
Ist in meinen Augen nicht gar nichts. Sehe hier genau das Fenster. Broadcast bedeutet das Du nicht gepaired bist
Hast Recht, habe ich übersehen.
Ok dann muss es vom Fenster kommen denn nur darin steht burstXmit (Recht hast du).
Der Fensterkontakt ist falsch gepaired?
Gar nicht gepaired. Zu mindest nicht abschließend.
2017-09-13 15:33:50 R-pairCentral set_0xF10000
2017-09-18 11:57:09 contact closed (to broadcast)
beim ersten sollte nur noch die 0xF10000 stehen und beim zweiten
contact closed (VCCU) oder was auch immer Du da als IODev verwendest
So ich habe ihn nun neu gepaired:
Internals:
.triggerUsed 0
CFGFN
CUL868_MSGCNT 5
CUL868_RAWMSG A0C0686415A164F000000010500::-54:CUL868
CUL868_RSSI -54
CUL868_TIME 2017-09-18 12:42:32
DEF 5A164F
IODev CUL868
LASTInputDev CUL868
MSGCNT 5
NAME Fenster_WZ_Links
NOTIFYDEV global
NR 3032
STATE closed
TYPE CUL_HM
lastMsg No:06 - t:41 s:5A164F d:000000 010500
protCmdPend 3 CMDs pending
protLastRcv 2017-09-18 12:42:32
protResnd 2 last_at:2017-09-18 12:42:37
protSnd 4 last_at:2017-09-18 12:42:32
protState CMDs_pending
rssi_at_CUL868 lst:-54 cnt:5 max:-53.5 min:-54.5 avg:-54.1
Readings:
2017-09-18 12:41:43 .D-devInfo 810101
2017-09-18 12:41:43 .D-stc 80
2017-09-18 12:42:32 .protLastRcv 2017-09-18 12:42:32
2017-09-18 12:41:48 Activity alive
2017-09-18 12:41:43 D-firmware 1.0
2017-09-18 12:41:43 D-serialNr OEQ0429164
2017-09-18 12:42:32 battery ok
2017-09-18 12:42:32 contact closed (to broadcast)
2017-09-18 12:42:32 state closed
2017-09-18 12:42:32 trigDst_broadcast noConfig
2017-09-18 12:42:32 trigger_cnt 5
cmdStack:
++A001F100005A164F00040000000000
++A001F100005A164F01040000000001
++A001F100005A164F0103
Helper:
HM_CMDNR 7
getCfgList all
getCfgListNo ,4
mId 00C7
rxType 28
supp_Pair_Rep 0
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +5A164F,02,00,00
nextSend 1505731352.69273
prefIO
rxt 2
vccu
p:
5A164F
00
00
00
Mrssi:
mNo 06
Io:
CUL868 -52
Prt:
bErr 0
sProc 2
wuReSent 3
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_cul868:
avg -54.1
cnt 5
lst -54
max -53.5
min -54.5
Attributes:
IODev CUL868
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SCo
room Wohnzimmer
serialNr OEQ0429164
subType threeStateSensor
IODev ist CUL868
Allerdings verschwindet der Zusatz (to broadcast) nicht.
Ist er nun richtig gepaired? Habe ihn nun über hmPairSerial verbunden.
Drücke mal beim Fensterkontakt auf den pairing Knopf. Kurz warten. Dann noch mal beim Fensterkontakt set getConfig und noch mal den pairing Knopf am Fensterkontakt drücken. Muss als letztes Grün leuchten die Lampe.
Erledigt.
Leuchtet auch grün!
Internals:
.triggerUsed 1
CFGFN
CUL868_MSGCNT 29
CUL868_RAWMSG A0EBAA0105A164FF100000100000000::-58.5:CUL868
CUL868_RSSI -58.5
CUL868_TIME 2017-09-18 12:53:39
DEF 5A164F
IODev CUL868
LASTInputDev CUL868
MSGCNT 29
NAME Fenster_WZ_Links
NOTIFYDEV global
NR 3032
STATE closed
TYPE CUL_HM
lastMsg No:BA - t:10 s:5A164F d:F10000 0100000000
protLastRcv 2017-09-18 12:53:38
protResnd 2 last_at:2017-09-18 12:42:37
protSnd 40 last_at:2017-09-18 12:53:39
protState CMDs_done
rssi_at_CUL868 cnt:29 max:-46 min:-61.5 avg:-55.74 lst:-58.5
Readings:
2017-09-18 12:53:38 .D-devInfo 810101
2017-09-18 12:53:38 .D-stc 80
2017-09-18 12:50:02 .R-msgScPosA open
2017-09-18 12:50:02 .R-msgScPosB closed
2017-09-18 12:50:02 .R-transmDevTryMax 6
2017-09-18 12:50:02 .R-transmitTryMax 6
2017-09-18 12:53:38 .peerListRDate 2017-09-18 12:53:38
2017-09-18 12:53:38 .protLastRcv 2017-09-18 12:53:38
2017-09-18 12:53:38 Activity alive
2017-09-18 12:53:38 D-firmware 1.0
2017-09-18 12:53:38 D-serialNr OEQ0429164
2017-09-18 12:53:38 PairedTo 0x000000
2017-09-18 12:50:02 R-cyclicInfoMsg on
2017-09-18 12:50:02 R-eventDlyTime 0 s
2017-09-18 12:50:02 R-pairCentral 0x000000
2017-09-18 12:50:02 R-sabotageMsg on
2017-09-18 12:50:02 R-sign on
2017-09-18 12:53:38 RegL_00. 02:00 09:01 0A:00 0B:00 0C:00 10:01 14:06 00:00
2017-09-18 12:53:38 RegL_01. 08:01 20:9C 21:00 30:06 00:00
2017-09-18 12:42:32 battery ok
2017-09-18 12:42:32 contact closed (to broadcast)
2017-09-18 12:42:32 state closed
2017-09-18 12:42:32 trigDst_broadcast noConfig
2017-09-18 12:42:32 trigger_cnt 5
Helper:
HM_CMDNR 186
cSnd 01F100005A164F01040000000001,01F100005A164F0103
mId 00C7
peerIDsRaw ,00000000
rxType 28
supp_Pair_Rep 0
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +5A164F,00,00,00
nextSend 1505732019.07163
prefIO
rxt 2
vccu
p:
5A164F
00
00
00
Mrssi:
mNo BA
Io:
CUL868 -56.5
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO CUL868
flg A
ts 1505732018.9759
ack:
HASH(0x22c13d0)
BA8002F100005A164F00
Rssi:
At_cul868:
avg -55.7413793103448
cnt 29
lst -58.5
max -46
min -61.5
Shadowreg:
Attributes:
IODev CUL868
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SCo
peerIDs 00000000,
room Wohnzimmer
serialNr OEQ0429164
subType threeStateSensor
Zitat von: d0m2011 am 18 September 2017, 12:55:16
Erledigt.
Leuchtet auch grün!
Internals:
2017-09-18 12:50:02 R-pairCentral 0x000000
Leider nein.
Der Kontakt ist nicht gepaired. Einfach nochmal das Pairing durchführen, dann den configknopf drücken. Danach nochmals GetConfig und den Configknopf.
Zitat von: d0m2011 am 18 September 2017, 12:08:24
Internals:
NAME HM_568EAA
....
channel_01 HM_568EAA_Weather
channel_02 HM_568EAA_Climate
channel_04 Heizung_WZ_Links
channel_05 HM_568EAA_ClimaTeam
channel_06 HM_568EAA_remote
Ich hab irgendwie die Vermutung zwei Devices zu haben?!?
Genau genommen 6
HM_568EAA ist das Hauptgerät an sich, die anderen sind die logischen Kanäle. Alle können Events senden.
Der Fensterkontakt lässt sich einfach nicht richtig pairen.
CMD's pending...
Habe ihn auch schon komplett zurück gesetzt und auch per Seriel gepaired.
Sogar ungepaired und komplett in FHEM gelöscht.
Ohne Erfolg!
Hat noch jemanden einen Tipp?
Solange er pending anzeigt, einfach den Configknopf drücken.
Ich gehe so vor.
1. VCCU hmpairforsec 120
2. Danach den Configbutton drücken, sollte er am Ende nicht grün leuchten, einfach nochmals drücken.
3. Ein get Config und wieder den Button drücken
4. Sollte jetzt gepaired sein.
Wichtig ist, dass du den Knopf drückst und zwischendurch nicht den Kontakt auslöst durch öffnen/schließen.
mag sein, das ich ein anderes system habe.....
das Problem ist aber jetzt schon seit 5 Jahren bei mir....... (und im Internet immer mal wieder gemeldet auch in anderen Foren und Systeme)
- HM-CC-TC---HM-CC-VD
|
--- 2x HM-SEC-RHS
leider geht bei diesen Device auch die Umschaltung von Auto auf MANU nicht.
somit stelle ich sie halt immer Manuel am grät um.
gruss
Zitat von: darkness am 18 September 2017, 13:48:19
Solange er pending anzeigt, einfach den Configknopf drücken.
Ich gehe so vor.
1. VCCU hmpairforsec 120
2. Danach den Configbutton drücken, sollte er am Ende nicht grün leuchten, einfach nochmals drücken.
3. Ein get Config und wieder den Button drücken
4. Sollte jetzt gepaired sein.
Wichtig ist, dass du den Knopf drückst und zwischendurch nicht den Kontakt auslöst durch öffnen/schließen.
Folgendes habe ich gemacht:
1. hmpairforsec 120
2. Knopf gedrückt -> Wechselt auf grün
3. Get Config
4. Knopf gedrückt -> bleib im Anlernmodus??
Nochmal probiert -> Nach get config nochmals hmpairforsec 120 und Knopf gedrückt ist aber immer noch nicht angelernt.
Ja und?
Er verwendet ein HM-CC-RT-DN und HM-SEC-SCo
Verstehe nicht, was du uns damit sagen möchtest.
Zitatmag sein, das ich ein anderes system habe.....
Richtig erkannt!
zwischen 3 und 4 etwas warten, keine Hektik beim anlernen! ruhig ruhig ....
ich vermute das es an der Firmware liegt,
das Problem ist ja nicht nur bei meinem TC
sondern auch beim FHT (FS20)
Getestet
TC-RAD auf manual off Ergebnis bei beiden system(auch FHT) es bleibt off
FHEM auf manual auf off TC stellt sich nach einiger zeit wieder auf 6.0
er sollte einfach mal versuchen mit dem rad am tc umzustellen und dann schauen ob es so bleibt...
gruss
PS anmeldern der fensterkontakte ging bei mir auch nicht.....
lösung war das immer hmPairForSec (VCC oder HM_LAN-Config) auch bei getconfig eingeschaltet sein muss, dann geht es sofort.
Vielleicht liegt es am alter, aber ich bin verwirrt.
Das Problem mit dem setzen der Temperatur liegt doch vermutlich an dem Fensterkontakt (fehlendes event-on-Change-reading)
Und von deinem abgekündigten Gerät auf die Firmware eines anderen Gerätetypen zu tippen halte ich für sehr gewagt...
Zitat von: eisman am 18 September 2017, 13:50:53
mag sein, das ich ein anderes system habe.....
das Problem ist aber jetzt schon seit 5 Jahren bei mir....... (und im Internet immer mal wieder gemeldet auch in anderen Foren und Systeme)
- HM-CC-TC---HM-CC-VD
|
--- 2x HM-SEC-RHS
leider geht bei diesen Device auch die Umschaltung von Auto auf MANU nicht.
somit stelle ich sie halt immer Manuel am grät um.
gruss
Das ist ja ein Uraltteil. Sicher das es schon Homematic ist und nicht noch FS20 oder so ein Zeug.
Der Fensterkontakt lässt sich einfach nicht pairen! Oder nicht mehr falls er es mal war.
Lasse ich mir Zeit zwischen get Config und dem Tastendruck verfällt er einfach wieder in den Anlernmodus nach dem Tastendruck...
Komplett zurück setzten hat auch nichts gebracht. Jedoch registriert FHEM die Statusänderung (open / closed).
Habt ihr noch einen Tipp für mich?
Zitat von: darkness am 18 September 2017, 14:13:45
Und von deinem abgekündigten Gerät auf die Firmware eines anderen Gerätetypen zu tippen halte ich für sehr gewagt...
Naja manchmal hält sich ein Bug/Feature in der Schublade eines Entwicklers hartnäckig ::)
Aber ich will den Gedankenansatz nicht teilen. ;)
@d0m2011 Jeder schritt erfordert Zeit. Auch die Nachrichten nach dem Anlernen / vor dem getConfig müssen verarbeitet werden. Also dort schauen ob CMDs done ohne Fehler erfolgte.
Wenn er getConfig gar nicht will, hilft auch ein clear msgEvents. Aber sparsam!
Gruß Otto
die DN hatte ich auch habe sie aber wegen verschiedener Probleme verkauft, und ja HM-TC ist Homematic und verrichtet seine arbeit sehr gut.
man kann aber auch das neumodische zeug nutzen und ewig die Fehler suchen... viel spass
das der fehler gleich ist
FHT
HM-TC
und auch vor 1,5 Jahren HM-DN
kann man schon darauf schliessen.....
War das Anfangsproblem gelöst?
ZitatDiese hole ich mir dann wieder sobald ich aufwache oder nach Hause komme:
Bewohner:home set Heizung_WZ_Links desired-temp [Temperatur_WZ:state];
Aber die Log zeigt ja, dass der Status der Bewohner über Nacht nicht geändert wurde.
Geändert haben muss er sich nicht. In der Regel reicht ja ein
Update des Readings, wenn man die Ereigniserzeugung nicht mit "attr Bewohner event-on-change-reading state" auf die
Änderung beschränkt. Anderenfalls würde ja jede Bestätigung des Bewohnerstatus wieder die desired-temp an den Thermostat senden. Und das würde dann in dem Rhytmus passieren, den die Bewohnerüberwachung vorgibt und hat mit allem anderen weniger zu tun.
Nein das Problem konnte ich leider noch nicht lösen.
Ich arbeite noch am Pairing des Fensterkontakts. Er will einfach nicht...!
Kannst Du mir deinen Ansatz genauer erklären?
Ein Update würde schon genügen?
Danke schonmal für die Hilfe.
Was mir gerade einfällt.
Prüf mal, ob bei dir libcrypt-rijndael-perl installiert ist (sofern Debian).
Bei dem HM-SEC-SCo ist standartmäßig AES aktiviert.
Dann normal pairen.
siehe: https://wiki.fhem.de/wiki/HM-Sec-SCo_T%C3%BCr-Fensterkontakt,_optisch
(https://wiki.fhem.de/wiki/HM-Sec-SCo_T%C3%BCr-Fensterkontakt,_optisch)
Gruß
Stimmt davon hatte ich was gelesen. Danke für den tollen Tipp. Bitte mal testen.
Zitat von: eisman am 18 September 2017, 13:50:53
mag sein, das ich ein anderes system habe.....
das Problem ist aber jetzt schon seit 5 Jahren bei mir....... (und im Internet immer mal wieder gemeldet auch in anderen Foren und Systeme)
- HM-CC-TC---HM-CC-VD
|
--- 2x HM-SEC-RHS
leider geht bei diesen Device auch die Umschaltung von Auto auf MANU nicht.
somit stelle ich sie halt immer Manuel am grät um.
gruss
die Uralt TC und VD s habe ich auch im Einsatz und funktionieren . auch die Umschalterei von Auto auf Manu.
Ich betreibe die aber nur im burst Modus!
Okay ich habe es installiert und alles neu gestartet, ohne Erfolg.
Nun leutet er rot beim pairen :-\
Frage am Rande: Ist mein Thermostat eigentlich richtig verbunden?
Internals:
CUL868_MSGCNT 6
CUL868_RAWMSG A0F908610568EAA0000000AA8E6100040::-47:CUL868
CUL868_RSSI -47
CUL868_TIME 2017-09-18 19:06:44
DEF 568EAA
IODev CUL868
LASTInputDev CUL868
MSGCNT 6
NAME HM_568EAA
NOTIFYDEV global
NR 119
NTFY_ORDER 50-HM_568EAA
STATE Nack
TYPE CUL_HM
channel_01 HM_568EAA_Weather
channel_02 HM_568EAA_Climate
channel_03 HM_568EAA_WindowRec
channel_04 Heizung_WZ_Links
channel_05 HM_568EAA_ClimaTeam
channel_06 HM_568EAA_remote
lastMsg No:90 - t:10 s:568EAA d:000000 0AA8E6100040
protLastRcv 2017-09-18 19:06:44
rssi_at_CUL868 avg:-47.75 lst:-47 max:-46 min:-52 cnt:6
Readings:
2017-09-18 18:27:53 .D-devInfo 00FFFF
2017-09-18 18:27:53 .D-stc 59
2017-09-18 13:27:50 .R-btnLock off
2017-09-18 13:27:50 .R-globalBtnLock off
2017-09-18 13:27:50 .R-localResDis off
2017-09-18 13:27:50 .R-lowBatLimitRT 2.1 V
2017-09-18 13:27:50 .R-modusBtnLock off
2017-09-18 19:06:44 .protLastRcv 2017-09-18 19:06:44
2017-09-18 18:58:24 Activity alive
2017-09-18 18:28:04 CommandAccepted no
2017-09-18 18:27:53 D-firmware 1.4
2017-09-18 18:27:53 D-serialNr OEQ0246340
2017-09-18 18:03:30 PairedTo 0xF10000
2017-09-18 13:27:50 R-backOnTime 10 s
2017-09-18 13:27:50 R-burstRx on
2017-09-18 13:27:50 R-cyclicInfoMsg on
2017-09-18 13:27:50 R-cyclicInfoMsgDis 0
2017-09-18 13:27:50 R-pairCentral 0xF10000
2017-09-18 18:03:30 RegL_00. 01:01 02:01 09:01 0A:F1 0B:00 0C:00 0E:0A 0F:00 11:00 12:15 16:01 18:00 19:00 1A:00 00:00
2017-09-18 18:13:01 RegL_07.
2017-09-18 19:06:44 actuator 0
2017-09-18 19:06:44 battery ok
2017-09-18 19:06:44 batteryLevel 3.1
2017-09-18 19:06:44 desired-temp 21.0
2017-09-18 19:06:44 measured-temp 23.0
2017-09-18 19:06:44 motorErr ok
2017-09-18 18:28:04 state Nack
2017-09-18 13:25:25 time-request -
Helper:
HM_CMDNR 144
mId 0095
rxType 140
supp_Pair_Rep 0
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +568EAA,00,00,00
nextSend 1505754404.56761
prefIO
rxt 2
vccu
p:
568EAA
00
00
00
Mrssi:
mNo 90
Io:
CUL868 -45
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
dev 1
prs 1
Rssi:
At_cul868:
avg -47.75
cnt 6
lst -47
max -46
min -52
Shregw:
07 04
Attributes:
IODev CUL868
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
model HM-CC-RT-DN
room CUL_HM
serialNr OEQ0246340
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
Der Fensterkontakt ist was spezielles, richtig?
Denn das Thermostat funktioniert ja ordentlich.
Der Fenstersensor ist in soweit speziell, dass AES dort aktiviert ist.
Vielleicht machst du noch mal einen Werksreset beim Kontakt und löscht ihn in FHEM. Dann neu pairen.
Bei dem muss man ganz genau sein. Aber dann laufen die ohne Probleme. Habe mehrere im Einsatz.
Bei deinem Thermostat ist das pairing ok. Nur das ein Befehl nicht aktzepiert wurde "NACK".
Prüfe mal deine VCCU ob dort alles ok ist. Nicht das diese durch zu viel Testen im Overload ist.
Wenn alles ok ist, dann wie oben beschrieben den Fenstersensor pairen.
@darkness
1.er hat keine VCCU
2. einen Cul
Ah, wer lesen kann ;) Danke für den Hinweis.
Dann bin ich jetzt raus. Mit CUL und AES kenne ich mich nicht aus. Sorry
Damit der CUL AES kann muss libcrypt-rijndael-perl installiert sein -> https://wiki.fhem.de/wiki/AES_Encryption#Zentrale_.E2.86.90.E2.86.92_I.2FO-Device
Gruß Otto
@Otto123
Wurde schon installiert: https://forum.fhem.de/index.php/topic,76819.msg687384.html#msg687384 (https://forum.fhem.de/index.php/topic,76819.msg687384.html#msg687384)
War mir nur nicht sicher, ob eine CUL auch mit AES läuft.
Gruß
hatte ich überlesen :-[
Naja speziell ist der CUL an sich. Der kann mit Homematic laufen, muss aber nicht. Würde ich nie jemandem für HM empfehlen.
Die Fensterkontakte sind an sich etwas zickig - in Kombination mit dem CUL muss das vielleicht auch gar nicht gehen.
Gruß Otto
Also ich habs installiert!
Zumindest nach Anleitung und dann alles mal neu gestartet.
Fensterschalter nochmal zurück gesetzt und auch in FHEM gelöscht und neu gepaired.
Leider immernoch vergebens.
So bin ich vorgegangen:
- set CUL868 hmPairForSec 120
- Batterie eingelegt und auf Knopf gedrückt
- Fensterkontakt blinkt schnell und leuchtet dann rot
- Ist nun in FHEM enthalten, aber nicht korrekt gepaired
--- Zweiter Versuch.
- set CUL868 hmPairForSec 120
- Fensterkontakt blinkt schnell und leuchtet dann rot
- Ist nun in FHEM enthalten, aber nicht korrekt gepaired
--- Dritter Versuch
- Fensterkontakt komplett reset
- set CUL868 hmPairForSec 120
- Nun leuchtet er kurz grün, schein gepaired zu sein.
Wiederhole ich den Vorgang klappt es manchmal -> Grün.
Machmal blinkt er und leuchtet nur rot am Ende.
gepairt ist wenn R-pairCentral 0xF10000 vorhanden ist ;)
und hminfo sagt es ist alles ok.
Genau, aktuell ist der Stand folgender:
R-pairCentral set_0xF10000
set_0xF10000 ist nicht gut
0xF10000 wäre gut.
Jepp, ich bekomme ihn nicht gepaired.
Ob es aber nun die Ursache für mein Problem ist weiß ich noch nicht.
Mal sehen, ob sie heute über Nacht die Temperatur wieder zurück stellt.
gepaired ist nicht gut, aber dein ursächliches Problem hat damit eventuell wenig zu tun.
Was war Dein Problem? ;D
Dein notify reagiert auf zu viele Events und nicht nur auf die es Deiner Meinung nach soll. Du musst die Events im Eventmonitor beobachten und entweder den trigger schärfer machen und/oder das attr <> event-on-change-reading an der Quelle setzen.
Gruß Otto
Ich glaube nichtmal, dass mein Notify reagiert.
Folgend nochmal die Zusammenfassung, vielleicht habe ich auch nur einen Denkfehler im Ganzen.
Problem über Nacht, Temperatur wird abgesenkt wenn ich ins Bett gehe:
Bewohner:gotosleep { fhem("set Temperatur_WZ " . ReadingsVal("Heizung_WZ_Links","desired-temp","") . "; set Heizung_WZ_Links desired-temp [Temperatur_WZ_abgesenkt:state]; set Kaffee_Strom off; set Tablet screen off")}
-> Die aktuell eingestellte Temperatur wird in den Dummy geschrieben und die "abgesenkte Temperatur" eingestellt (steht auch im Dummy).
Morgens wenn ich aufwache:
Bewohner:home set Heizung_WZ_Links desired-temp [Temperatur_WZ:state]; set Kaffee_Strom on; set Tablet screen on
Wird die gespeicherte Temperatur wieder zurück in das Thermostat geschrieben.
Aktuell habe ich am Heizkörper auf 20°C eingestellt.
Vor dem schlafen gehen stelle ich nachher auf 21°C per FHEM um und schaue was bis morgen passiert.
Das mit dem "event-on-change-reading" musst du mir erklären.
Zitat von: d0m2011 am 18 September 2017, 17:38:04
Nein das Problem konnte ich leider noch nicht lösen.
...Ein Update würde schon genügen?
Nein. Was ich meinte:
Das von Dir zitierte Notify triggert auf das Device "Bewohner", wenn es den Zustand "home" erhält, und setzt dann den Thermostaten auf die desired-temp (aus dem Zwischenspeicherdummy). Soweit so gut. Diese Aktion wird - so vermute ich - immer dann ausgeführt, wenn "Bewohner" auf den Zustand "home" gesetzt wird (
edit: und das weiß ich nicht wie das passiert, möglicherweise ein anderer Mechanismus, der Dein Vorhandensein entsprechend bemerkt?), und zwar unabhängig davon ob es bereits vorher auf "home" war - das wäre dann ein
update des Readings "state. Das ist bei den meisten Devices in FHEM der Standard, dass bei einer Aktualisierung eines Readings ein Event ausgelöst wird.
Wenn Du solche Aktionen nur ausgeführt haben möchtest, wenn sich der Zustand
ändert (was ich eher vermute), musst Du das in "Bewohner" extra einstellen. Das besorgt dort das besagte Attribut "event-on-change-reading", das dann um die Readings ergänzt werden soll, bei denen ein Event erzeugt werden soll, im einfachsten Fall ist das eben "state". Dann wird auch Dein Notify mit dem desired-temp-Senden an den Thermostaten nur ausgeführt, wenn sich der Status von "Bewohner" von irgendetwas anderem
auf den Zustand home ändert.
Jetzt besser?
Jetzt hab ich es verstanden, danke!
Okay, drum tauch in meinem Event-Monitor auch dauernd ein Eintrag der Bewohner auf.
Immer wieder der gleiche Status.
Verrätst du mir nun wie ich das einstelle?
attr <device> event-on-change-reading reading1[:threshold][,reading2[:threshold]...n]
im einfachsten Fall attr <> event-on-change-reading state damit wird ein event für state nur erzeugt wenn state sich ändert.
Okay super!
Ich teste es jetzt und werde berichten.
Ich empfehle eventonchangereading .* zu setzen. Fuer hm devices sollte dies immer reichen und senkt die prozessorlast da nicht fuer jede wiederholung eines bekannten events jede instanz gefragt werden muss ob sie es verarbeiten will.
Neuer Zwischenstand:
Über Nacht hat sich die Temperatur natürlich wieder zurück gestellt.
Auch am Morgen immer wieder nach wenigen Minuten.
Nun habe ich auf alle Devices, welche dauernd ohne Änderung im Event Monitor auftauchen, mit "attr <> event-on-change-reading state" versehen.
Unter anderem sind immer wieder die Bewohner aufgetaucht, aber auch meine Tablet Steuerung und Wettervorhersage (Proplanta).
Seitdem funktioniert es, warum auch immer.
-> Werde das Ganze jetzt beobachten und berichten.
Zusatz:
Vom Fensterkontakt kann es nicht gekommen sein. Das Thermostat hat sich immer wieder auf die Temperatur zurück gestellt, welche am Thermostat direkt eingestellt wurde. Einen Rückschluss auf den Fensterkontakt konnte ich bisher nicht nachstellen.
Zitat von: d0m2011 am 19 September 2017, 14:07:48
Unter anderem sind immer wieder die Bewohner aufgetaucht
...
Seitdem funktioniert es, warum auch immer.
-> Werde das Ganze jetzt beobachten und berichten.
Aber genau das hast du ja mit deinen Notifies gemacht. Und da Bewohner immer aufgetaucht ist, hat dieses auch entsprechend getriggert.
Du solltest aber schon schauen/verstehen was ein event-on-Change/event-on-update macht. (Nicht böse gemeint) Wenn du es einfach nur setzt ohne zu verstehen was da passiert, kann das zu "interessanten" Effekten führen ;)
Ja du hast Recht nur warum ist er dann auf die Temperatur zurück gesprungen, welche ich manuell am Thermostat eingestellt habe?
FHEM hat keine der anderen Temperaturen beispielsweise aus den Dummy's genommen.
Ich hab's denke ich fast verstanden.
Muss mir das Ganze jedoch nochmal durchlesen. Mögliche Nebeneffekte?
Zitat von: d0m2011 am 19 September 2017, 15:35:03
Mögliche Nebeneffekte?
Ich habe jetzt kein konkretes Beispiel. Nur sollte man wissen, was die event-on* attribute machen. Ansonsten passiert nichts oder zu viel. So meinte ich das.
Wenn es jetzt läuft, spricht es ja dafür das eines der Notify entsprechend getriggert hat.
P.S. Wenn alles gelöst ist, dann noch den Titel anpassen
Okay, danke.
Lass mich das Ganze noch bis morgen Beobachten dann würde ich eine Zusammenfassung schreiben und das Thema "abschließen".
was ja auch richtig ist.
wie Funktioniert der Thermostat
AUTO Der Thermostat regelt alle Funktionen (Wochenprogramm etc.), vorteil geht auch wenn die Zentrale nicht da ist
CENT Die Zentrale übernimmt alle Funktionen und Einstellungen, nachteil geht nur mit Zentrale (Wochenprogramm usw. )
MANU Alle Einstellungen werden nur vom Regler übernommen, werden also sporadisch wieder auf den aktuellen wert gestellt.
vielleicht war es eine Falsche aussage das es ein Fehler in der Firmware ist!
Hat aber nichts mit DinoHardware oder Neumodisch zu tun, sondern ist wohl Logisch.....
mfg
Ich bin jetzt mal zu bequem (muss in ein paar Minuten weg) alle 5 Seiten zu lesen.
- Ist das Heizungsthermostat mit einem Wandthermostat gepeert, und vom WT kommen die Trigger?
- Wie sehen die Watchdogs & Notifys aus? Triggern die wirklich nur das gewollte?
- Wie ist der Modus des HT? Auf MAnual oder ggf. auf Auto? Sind Heizprofile im HT hinterlegt, die im Auto-Modus triggern?
LG
PS: Ich hatte vor ein paar Wochen bei meinem Bad-HT auch das Problem, dass er 2 Mal am Tag auf 20 Grad hochspringt. Da lag es daran, dass er im Auto-Modus gewesen ist und im Heizprofil 2 Mal am Tag auf 20 Grad geheizt werden soll.
Hi,
folgender Stand:
- Nein nur mit FHEM gepaired
- Gibt verschiedene: Fenster offen / geschlossen; Bewohner anwesend / abwesend / schlafend
- Nur im manuellen Modus
Ich weiß aktuell nicht sicher woher die 20° immer kamen.
Doch siehe ein paar Posts bevor was ich geändert habe, seitdem funktioniert es.