Weekdaytimer Verständnisproblem

Begonnen von persching, 21 Mai 2022, 21:59:47

Vorheriges Thema - Nächstes Thema

persching

Zitat von: MadMax-FHEM am 28 Mai 2022, 14:22:14
Hast du wirklich

set HKT_Climate controlMode night

eingegeben?

Naja, du musst schon DEIN Device nehmen!
EDIT: bzw. LESEN!!! Beim Heizkörperthermostat ist es der _Clima Kanal, beim Wandthermostaten ist es der _Climate Kanal!
EDIT: wenn man zum Device/Kanal auf der Weboberfläche geht, sieht man was man setzen kann... ;)

EDIT: habe es eben getestet, geht (bei mir) wunderbar...

Gruß, Joachim

Ich hab natürlich schon den Namen meines Devices genommen, aber ich hab den Fehler gefunden: du hast recht, ich muss das am Thermostat ausführen und nicht im _Climate Channel. Jetzt gehts. :)

Und kann man das jetzt in den weekprofiles verwenden?

MadMax-FHEM

Zitat von: persching am 28 Mai 2022, 15:30:08
Ich hab natürlich schon den Namen meines Devices genommen, aber ich hab den Fehler gefunden: du hast recht, ich muss das am Thermostat ausführen und nicht im _Climate Channel. Jetzt gehts. :)

Eigentlich nicht am Thermostat (Hauptdevice) sondern im _Clima Kanal...

Aber egal, wenn du es hinbekommen hast...

Zitat von: persching am 28 Mai 2022, 15:30:08
Und kann man das jetzt in den weekprofiles verwenden?

Keine Ahnung, da kenne ich mich nicht aus.

Ich nutze die Wochenprofile des HKT/WDT selbst (oder meinst du das? Das geht nicht, wie soll es auch, es müssen ja im hinterlegten Profil Temperaturwerte stehen / hat nihtc mit fhem zu tun, ist von Homematic/eq3 so vorgegeben).

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Per WDT_mapping. Z.B. 17 => controlMode+night, 22=> controlMode+day (für diese CUL_HM Ziel-Geräte). Alle anderen Temperaturen gehen dann nach desired-temp.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

persching

Zitat von: Beta-User am 28 Mai 2022, 20:25:48
Per WDT_mapping. Z.B. 17 => controlMode+night, 22=> controlMode+day (für diese CUL_HM Ziel-Geräte). Alle anderen Temperaturen gehen dann nach desired-temp.

Ich hab jetzt mal die Temperaturen 8.0 auf eco gemappt und 9.0 auf comfort (bei den MAX Thermostaten, weil das Temperaturen sind, die im Normalfall nie benutzt werden). Das funktioniert gut, allerdings wird das beim Nachvollziehen doch etwas unübersichtlich. Aber ich werde trotzdem mal so starten.

Beta-User

Hmmm, das mit der Nachvollziehbarkeit läßt sich wohl nicht komplett lösen.

Mir kommt es nicht optimal vor, das "mappen" durch "außergewöhnliche" Werte zu erzwingen. MAn. sollte man versuchen, die Zahl der "Echt-Profile" (mit Werten, keine Referenzen) eher gering zu halten, und das geht mit solchen "Sonderlocken" nicht so einfach. Wenn man 22.5 für "day" hat, kann ein "normaler" Thermostat (oder WDT ohne mapping) damit noch was anfangen und das Gesamtergebnis wird sich in der Realität auch in etwa so anfühlen wie erwartet.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files