Robustheit Heizungssteuerung

Begonnen von guhu, 05 Oktober 2020, 10:00:05

Vorheriges Thema - Nächstes Thema

guhu

Hallo zusammen,

mein fhem-System möchte ich so einrichten, dass es robust ist, d.h., dass bei Ausfall von fhem alles so gut wie es geht weiterläuft. Das ist soweit in Ordnung bis auf die Heizungssteuerung. Dazu habe ich auch noch keine "best practise" gefuden, daher hier mal die allgemeine Anfrage. Wenn bei mir fhem ausfällt, ist die Heizungssteuerung am A***.

Folgende sicher gängige Konfiguration:

100% HM-Thermostate und -Fensterkontakte an der Heizung.

Regelungsbedarf bis heute:

1) Wochenprogramme für die einzelnen Räume.
2) Reaktion auf Fensterkontakte
3) Feiertagsprogramm
3) bei einigen Räumen Temperatur auf Defaultwert, sofern eine bestimmte Person nicht im Haus ist
4) allgemeine Absenkung, wenn keiner im Haus ist, um 2 ° C
5) "Homeoffice"-Programm auf Knopfdruck.

Im Einsatz habe ich derzeit:
- CUL-HM
- WDT in Verbindung mit weekprofile
- Homemode
- zusätzlich noch einige DOIFs

Die inhärenten Möglichkeiten der HM-Geräte nutze ich nicht. Das klappt alles soweit m. E. sehr gut, allerdings werden die HM-Thermostate natürlich jedesmal angesteuert, wenn die Temperatur wechseln soll. Wenn dann kein Signal kommt, weil fhem nicht liefert, dann bleibt die Temperatur ebenso. Wünschenswert wäre dann ein "Notprofil" in den HM-Thermostaten.

Wie geht ihr damit um?


FHEM 5.9 auf Synology DS918+ (in Docker), HM-CFG-USB2 mit hmlan, HM-CC-RT-DN, HM-SEC-SC-2, nanoCUL,a-culfw,deCONZ,Brennenstuhl-Steckdosen,-FB
Module:ENIGMA2,SONOS,FRITZBOX,FB_CALLLIST,WDT_TIMER,VCONTROL300,WITHINGS

MadMax-FHEM

Wenn du mit inhärenten Funktionen z.B. Wochenprogramme in den WT/HKT, Peering zwischen den Komponenten etc. meinst: genau das nutze ich und das wäre dann "Fallback"...

D.h. Heizung (aber auch andere Dinge: Licht etc.) läuft autark (mindestens pro Raum, daher auch bei Licht innerhalb eines Raums ein System mit direkten Verbindunden).
Fhem "kuckt zu" (Logs, Graphen) und übernimmt Komfortfunktionen...

Gruß, Joachim

P.S.: diese Antwort wirst du an vielen Stellen im Forum wo ähnliche Fragen gestellt werden/wurden finden...

P.P.S.: hast du CUL_HM nur als Modul oder auch einen CUL!? Wenn es gut läuft: ok. Wenn nicht: Original-HM-Funkmodul...

P.P.P.S.: zu empfehlen: vccu! Und hminfo!
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)

guhu

#2
Hallo,

ja, als Fallback schwebt mir vor, auf die Komfortfunktionaltät zu verzichten und dass das interne Profil der HM-Thermostate das Standard-Wochenprogramm beinhaltet. Am besten wäre es, wenn man per Funktion ein gespeichertes Weekprofil in die HM-Thermostate mit einer Funktion übertragen könnte. Wie hälst Du die Profile up to date?

Ich habe derzeit die internen HM-Temperaturprofile nicht in Betrieb, da die dann mit den Plänen aus Weekdaytimer kollidieren können.

PS: habe ein Original HM-Funkmodul als USB-Stick, der über hmland gesteuert wird. Läuft unproblematisch. HMInfo hatte ich, aber das hilft mir doch nicht bei meinem Problem, oder?
PS: genau, bei den HM-Thermostaten und meinen "Anforderungen" weiß ich eben nicht, wie man das am besten mit dem "Zugucken von FHEM" hinbekommen soll.
FHEM 5.9 auf Synology DS918+ (in Docker), HM-CFG-USB2 mit hmlan, HM-CC-RT-DN, HM-SEC-SC-2, nanoCUL,a-culfw,deCONZ,Brennenstuhl-Steckdosen,-FB
Module:ENIGMA2,SONOS,FRITZBOX,FB_CALLLIST,WDT_TIMER,VCONTROL300,WITHINGS

MadMax-FHEM

Doch mit hminfo kannst du templates erstellen, bearbeiten und wieder auf die Thermostate/WTs laden...

So mache ich das.

Was meinst du mit "synchron halten"!?

Ich habe ein Profil, das läuft durch.
Zusätzlich eines für Winter/sehr kalte Tage.
Das wird autom. geladen, wenn es eben 3 Tage am Stück (oder so) sehr kalt ist.
Und wenn es wieder länger warm ist andersrum...

Ich lade da nicht so viel rum...
...wozu!?

Ansonsten kannst du ja weiterhin auf Mode manu lassen und steuern wie du willst...

Im auto-Modus fahren sie dann ihr internes Programm...

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)

guhu

ok, die Umstellung manu/auto ist der Schlüssel. Das macht Sinn. Danke.
Ich stelle schon öfters um, siehe oben.
FHEM 5.9 auf Synology DS918+ (in Docker), HM-CFG-USB2 mit hmlan, HM-CC-RT-DN, HM-SEC-SC-2, nanoCUL,a-culfw,deCONZ,Brennenstuhl-Steckdosen,-FB
Module:ENIGMA2,SONOS,FRITZBOX,FB_CALLLIST,WDT_TIMER,VCONTROL300,WITHINGS

guhu

So, habe noch das hier gefunden: https://forum.fhem.de/index.php/topic,70494.0.html
Damit kann ich beizeiten meine definierten Weekprofile in Dateien für HMInfo schreiben und damit die HM-Theromstate updaten. Im Havariefall dann auf Auto stellen und gut ist.
FHEM 5.9 auf Synology DS918+ (in Docker), HM-CFG-USB2 mit hmlan, HM-CC-RT-DN, HM-SEC-SC-2, nanoCUL,a-culfw,deCONZ,Brennenstuhl-Steckdosen,-FB
Module:ENIGMA2,SONOS,FRITZBOX,FB_CALLLIST,WDT_TIMER,VCONTROL300,WITHINGS