Mit Shelly DW2 und Fritz DECT 301 Heizung steuern

Begonnen von Albi, 27 Dezember 2020, 00:38:41

Vorheriges Thema - Nächstes Thema

Albi

Hallo,

Grundsätzlich, sollte ich das falsche Forum erwischt haben dürfen gerne die MODs das Thema verschieben.

Ich habe heute mit folgenen Komponenten meine Heizung optimiert.

- Fritz DECT 301 oder Comet DECT am Heizkörper
- Shelly Door/Window2 am Fenster mit MQTT
- FHEM als Sever mit MQTT

Als erstes habe ich nach bekannten aus dem WIKI die Fritz DECT oder Comet DECT an die Fritz box angelernt. Nach Anleitung
Hierzu habe ich das Fritz Modul FBAHATTP eingerichtet um mit der Fritz Box zu "reden". Das sollte bekannt sein. Wiki hilft.

Dann habe ich die einzelnen DECT Devices entsprechend angelegt. Hier mein Beispiel aus meinem BAD

defmod hz_Bad FBDECT FrtizDect:13357_0300120 actuator,tempSensor
attr hz_Bad IODev FrtizDect
attr hz_Bad event-min-interval power:60
attr hz_Bad room FHT
attr hz_Bad stateFormat temperature Eingestellt: desired-temp


Dann habe ich über "MQTT2" den Shelly Fensterkontakt eingerichtet. Das sollte auch bekannt sein
Hier mein defmod zum Fensterkontakt. In Mqtt2 device habe ich das template shellydw gewählt
defmod DW2_Bad MQTT2_DEVICE shellydw2_483FDA8252AD
attr DW2_Bad IODev MQTTBroker
attr DW2_Bad alexaName Fenster Kontakt Bad
attr DW2_Bad devStateIcon open:fts_window_1w_open@red tilted:fts_window_1w_tilt@yellow closed:fts_window_1w@green
attr DW2_Bad genericDeviceType security
attr DW2_Bad icon fts_window_1w_open
attr DW2_Bad model shellydw
attr DW2_Bad readingList shellies/shellydw2-483FDA8252AD/online:.* online\
  shellies/shellydw2-483FDA8252AD/sensor/state:.* doorWindow\
  shellies/shellydw2-483FDA8252AD/sensor/tilt:.* tilt\
  shellies/shellydw2-483FDA8252AD/sensor/vibration:.* vibration\
  shellies/shellydw2-483FDA8252AD/sensor/lux:.* lux\
  shellies/shellydw2-483FDA8252AD/sensor/battery:.* batteryPercent\
  shellies/shellydw2-483FDA8252AD/announce:.* { json2nameValue($EVENT) }\
shellydw2_483FDA8252AD:shellies/shellydw2-483FDA8252AD/sensor/temperature:.* temperature\
shellydw2_483FDA8252AD:shellies/shellydw2-483FDA8252AD/sensor/illumination:.* illumination\
shellydw2_483FDA8252AD:shellies/shellydw2-483FDA8252AD/sensor/error:.* error\
shellydw2_483FDA8252AD:shellies/shellydw2-483FDA8252AD/sensor/act_reasons:.* { json2nameValue($EVENT) }
attr DW2_Bad room FHT
attr DW2_Bad setList x_update:noArg shellies/shellydw2-483FDA8252AD/command update_fw\
  x_mqttcom shellies/shellydw2-483FDA8252AD/command $EVTPART1
attr DW2_Bad userReadings state:(doorWindow|tilt).* { ReadingsVal($name,"doorWindow","") eq "close" ? 'closed' : ReadingsNum($name,"tilt",1) > 0 ? 'tilted' :'open' }


dann habe ich mir das Weekdaytimer Modul eingerichtet
defmod wd_hz_bad WeekdayTimer hz_Bad de \
mo-fr|05:00|23 \
mo-fr|07:30|16 \
mo-fr|16:00|23 \
sa-so|08:00|23 \
sa-so|10:30|16 \
sa-so|17:00|23 \
21:00|16 \
00:05|16 \


Dann habe ich mir ein DOIF geschrieben mit dem ich halt das Fenster überwache und bei gekippten oder offenem Fenster die Temparatur runter fahren lasse und den Weekdaytime auf disable setze. Bei Fenster zu wird weekdaytime auf enable gesetzt und die eigentliche Temparatur gesetzt.
defmod hz_FK_Bad DOIF (([DW2_Bad] eq "open") or ([DW2_Bad] eq "tilted")) (set hz_Bad desired-temp 12.0,set wd_hz_bad disable) \
DOELSE \
([DW2_Bad] eq "closed") (set wd_hz_bad enable)
attr hz_FK_Bad do always
attr hz_FK_Bad room DOIF,FHT



So nun funktioniert es folgend.

Ist das Fenster zu, greift der Weekdaytime und stellt die Temp ein

Wird das Fenster gekippt oder aufgemacht, wird auf Absenkung gestellt in meinem Fall 12 Grad. Und der Weekdaytimer auf disable gestetzt.
Macht man das Fenster zu, wird der Weekdaytime auf enable gesetzt. Bei Enable wird von FHEM ein "Check" durchgeführt und stellt den Termostat auf die gewünscht Temp die eigentlich der Weekdaytime haben sollte.


So Klappt es bei mir

Fenster zu, arbeitet das Termostat normal mit dem Weekdaytime
Fenster auf oder gekippt, wird auf 12 Grad gefahren und der Weekdaytime deaktiveirt
Fenster zu, wird weekdaytime wieder aktiv und der Termostat auf die vom Weekdaytime gewüscchte Temp eingestellt


Viel Spaß

Gruß Albi

PS. mit einem "Wait" im DOIF könnte mann den Fensterkontakt Träger machen.
also ein
attr hz_FK_Bad wait 60:60
Könnte man erreichen, wenn das Fenster weniger als eine Minute offen oder zu ist, wird ken Befehl an das Thermostat geschickt. Sprich mache ich nur kurz das Fenster auf und wieder zu entlaste ich die Schaltung unf FHEM macht erst mal nichts.

Fhem Raspberry3+

TabletUI mit Abfallkalender, der auch per Telegramm sendet - Verkehrsmeldung über Google, das per DOIF an Telegramm bei Störung meldet - Sonnoff mit Tasmota (mqtt) und Shelly (mqtt und mqtt2) - Alexa Verknüpfung - Benzinpreis auf Tablet UI über HTTPMOD - Wetter + Pollen

amenomade

Das Problem wird aber immer das gleiche sein: der Thermostat weckst sich nur ab und zu (alle 15 Minuten?). D.h., erst dann wird die Heizung möglicherweise runtergedreht.

Oder?
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

alealdata

Aus meiner Sicht kann ich die DW/DW2 für derartige Steuerungen nicht empfehlen und wäre mir persönlich zu riskant an der Heizung. Das Teil ist einfach unzuverlässig und fällt dir schneller aus als dir lieb ist.

Beta-User

Na ja, es geht "nur" darum, dass man nicht zum Fenster rausheizt, von daher ist diese Lösung - unabhängig von allen Einwänden gegen die Hardware - zumindest etwas energiesparender als eine herkümmliche...

Aus anderen Gründed halte ich das hier aber trotzdem nicht für eine "Musterlösung":

- den WeekdayTimer muss man nicht auf disable setzen, es würde reichen, den Kontakt via Perl sauber als delayedExecutionCond einzubinden. Könnte so klappen:
attr wd_hz_bad delayedExecutionCond { ReadingsVal("DW2_Bad",'state','closed') ne 'closed' ? 1 : 0 }
Dann braucht man den Eventhandler nur, um die neue Zieltemperatur einzustellen, den Rest macht der WDT dann alleine (ggf. mit einer Verzögerung von 60 Sek.; mit set ... WDT_Params kann man die notfalls auch noch verkürzen).
Für die Fenster-offen-Umstellungen (bei etwas anderen Voraussetzungen) ist bei mir nur ein einziger Eventhandler im Einsatz:
defmod n_FK_TK_notify notify Dachfenster_..*:.*e[nd]|Fenster_..*:.*.*e[nd]|[...] { myWinContactNotify ($NAME, $EVENT, 30)}

Die myUtils checkt dann, ob überhaupt die Heizperiode "an" ist, bevor irgendwas in Richtung Heizung gemacht wird, wertet dann aus, zu welchem "Heizkörper" der Kontakt eigentlich gehört (steht in einem userattr) und stellt den dann auf "Fenster offen".

- "de" steht vermutlich nur da, weil "global" nicht auf DE steht.

- Und sobald man mehrere Profile in einem Raum verwenden willst und/oder mehrere WDT mit demselben Profil fahren, fährst man vermutlich mit  weekprofile-gesteuertem WeekdayTimer eleganter...

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Albi

Zitat von: alealdata am 27 Dezember 2020, 07:21:13
Aus meiner Sicht kann ich die DW/DW2 für derartige Steuerungen nicht empfehlen und wäre mir persönlich zu riskant an der Heizung. Das Teil ist einfach unzuverlässig und fällt dir schneller aus als dir lieb ist.

Ja klar die reagieren recht träge. Normal so 6 Minuten im schlimmsten Fall 15 Minuten. Aber es geht wie hier schon erwähnt nur darum um ein dauerhaftes aus dem Fenster heizen zu unterbinden.

Und eben wenn das Fenster wieder zu ist, soll die Heizung wieder normal laufen.
Fhem Raspberry3+

TabletUI mit Abfallkalender, der auch per Telegramm sendet - Verkehrsmeldung über Google, das per DOIF an Telegramm bei Störung meldet - Sonnoff mit Tasmota (mqtt) und Shelly (mqtt und mqtt2) - Alexa Verknüpfung - Benzinpreis auf Tablet UI über HTTPMOD - Wetter + Pollen