Anwesendheitserkennung mit Heizungssteuerung Logik Denkanstoß

[timtom]

Hallo zusammen,

ich hab ein dickes Brett vor dem Kopf. Es geht auch nicht direkt um die Umsetzung in FHEM, sondern um die Logik an sich. Daher möchte ich mal nachfragen, wie ihr das so macht?

Zum "Problem". Ich nutze diverse HM-CC-RT-DN in denen ich bisher Temperaturlisten hinterlegt habe und somit Werktags/Wochenend gesteuert die Temperaturen zwischen 15-und 20 Grad automatisch geregelt habe (unabhängig von FHEM). Zusätzlich hatte ich noch einen "Lange-Weg"-Schalter, mit dem ich im Urlaub alle RT auf 14 Grad runtergeregelt habe.

Jetzt habe ich einen HM-PB-2-WM55 2fach-Funk-Wandtaster (4 Status) für die Haustüre gekauft, um zuverlässig die Anwesenheit zu erfassen. Ich hatte mir eigentlich vorgestellt, dass man damit auch die RT-Nutzung verbessern etwas kann. Bisher hatte ich mir folgende Fälle ausgedacht.
1) Zuhause jedoch nicht Schlafen => Temperatur auf Heizen (analog zu Heiztemperatur laut Temperaturlisten)
2) LageWeg (mehrere Tage) => Temperatur konstant 14 Grad
3) KurzWeg (z.B. Einkaufen, Kino, Essen gehen) => Temperatur auf Absenkung (analog zu Nachtabsenkung laut Temperaturlisten, z.B. Reduktion um 5 Grad)
4) Schlafen => Könnte identisch zu KurzWeg sein

Damit habe ich aber quasi die Temperaturlisten abgeschafft und mich von Automatisierung wieder weiter entfernt. Außerdem müsste ich zusätzlich noch eine Funktion bauen, die morgens z.B. das Bad wieder aufheizt.

Ich hab schon diverse Strukturen, LightScenes, DOIF, PRESENCE etc. angelegt/genutzt und bin irgendwie mit keiner Lösung zufrieden. Daher interessiert mich, welche Logik und Abhängigkeiten ihr für die Heizungssteuerung nutzt?

PS: Selbstverständlich hängen auch noch andere Geräte am Anwesendheitsstatus. Diese habe ich zur Vereinfachung jedoch ignoriert.

[DeeSPe]

Hab was Ähnliches am Laufen, allerdings mit Anwesenheitserkennung per Bluetooth.
Du solltest Dir sowas wie einen HouseMode bauen, der sich dann entsprechend der Anwesenheit ändert.

Habe vorhin für jemand Anderes einen Vorschlag gepostet.
Los geht es hier.
Und der Rest kommt dann ab hier.

Vielleicht nutzt Dir das etwas. Es macht jedenfalls (für mich) genau das was es soll.

Gruß
Dan

[Mitch]

Ich mache das mit den Modulen Heating_Control und HCS.

Hier habe ich es damals im Wiki beschrieben: http://www.fhemwiki.de/wiki/Heating_Control

Hab zwar mittlerweile etwas "umgebaut", aber grundsätzlich läuft es immer noch so.

[timtom]

Hey Danke für Eure Antworten. Ich versuche mal zusammenzufassen

@Mitch:
M1. Für jedes RT ein Heizplan. Analog wären das bei meinen HM die Templisten
M2. Alle RT lassen sich manuell auf 14 runterregeln. Das wäre dann wahrscheinlich eine längere Abwesenheit (z.B. Winter-Urlaub)
M3. ECO-Schalter regelt alle RT um 2 Grad runter (falls aktuelle benötigte Temperatur >16 Grad). Enteder manuell oder bei >30min Abwesenheit (und abhängig von der Außenteperaturschwellenwert 22 Grad)
=> Solange jemand zu Hause ist, nutzt du automatische Temperaturlisten. Bei Abwesenheit werden die über den ECO-mode overruled?

@DeeSpe:
Sehr cooles HomeStatus Programm. Vielleicht klaue ich mir davon mal was Bzgl. Heizung:
D1. Primär automatisch nach Templisten im Winter. Im Sommer alle RT aus.
D2. Im Winter wird bei Nacht oder Abwesenheit in den Nachtmodus gestellt. Zum nächsten Schaltzeitpunkt der Templisten dann wieder in den automatischen Modus.
=> Es werden Primät Templisten genutzt. Diese können bei Abwesenheit bis zum nächsten Schaltzeitpunkt overruled werde.

Genau da beisst sich nach meinem Gefühl die Katze in den Schwanz. Ich gehe mal von einem 2 Personenhaushalt aus, bei dem beide Berufstätig sind (Annahme: 9-17 Uhr).
- Bei Mitchs Lösung wernutzen die Templisten dann kaum genutzt und die Heizung primär durch einen Anwesenheitsstatus "manuell" gesteuert. Da Heizung geht eigentlich nur an und steuert sich, wenn auch jeand da ist. Dafür kommt man im Winter in die kalte Bude
- DeeSpe geht den Weg genau anders herum. Die Heizung steuert sich primär automatisch. Wenn man mal nicht da ist, versucht man zumindestens bis zum nächsten Schaltpunkt herunterzuregeln.

Ich glaube einen Verbesserung durch ein Zwischendring ist gar nicht möglich. Sie denn man hat einen extrem geregelten Tagesablauf oder man kombiniert Mitchs Lösung mit einer Remote-App Nutzung, bevor man nach Hause kommt Oder hat jemand noch etwas "besseres" zu bieten?

[CoolTux]

Ich verwende Roommate und Residents.
Es gibt in den Geräten feste Temperaturlisten, welche ich aber durch setzen von einer neuen Temperatur überschreiben kann. Hält bis zum nächsten Schaltzeitpunkt.

Zum Beispiel wird in der Woche ab 8 Uhr alles auf 17 Grad gestellt. Oft ist aber schon vor 8 Uhr niemand mehr zu Hause, als wird sofern alle Bewohner raus sind automatisch nach einer halben Stundedie Heizung  auf 17 Grad gestellt.

Andersrum wird ab 15 Uhr auf 19 Grad gestellt. Kommt meine Tochter aber mal vorher nach Hause so wird schon vorher auf 19 Grad gestellt.

Bad vorheizen mache ich für unseren Junior nach Bedarf. Und für die Großen wird eine Stunde vor dem Wecken (an Hand des Residents Wecker) die Heizung in der Wohnung an gemacht. Ansonsten spätestens ab 5 Uhr automatisch.

[Mitch]

Von unterwegs, drum nur kurz:
Meine Heizung steuet sich automatisch, aber nur durch fhem, alle Ventile sind auf manuell.
ECOmodus wird schon beim "näher kommen" über Geofence deaktiviert, damit man im Winter nicht in eine kalte Bude kommt.
d.h. jemand geht für 45 min Einkaufen, wäre eigentlich ECO an, da aber die Entfernung zu gering, gehe ich (und die Heizung) davin aus, dass bald jedman zurück kommt, ergo kein ECO.

Ich kann morgen gerne ausführlicher schreiben, wenn du noch was wissen willst.

[timtom]

So, vielen Dank für Eure Anregungen. Ich hab mir mal Gedanken gemacht und habe mit folgendem angefangen.

Heizungsmodus
Sommer: set .*_Clima controlManu off
Winter: set .*_Clima controlMode auto

LightScenes
Vorbereitung:
Die Templisten sowie die Readings R-nightTemp (Absenktemperatur) und R-dayTemp (Heiztemperatur) wurden für alle RT individuell gesetzt

Folgende Light Scenes wurden erstellt:
SummerAbsent, SummerGone, SummerHome: Thermostate werden nicht geschaltet => Sollte auch Funkverkehr sparen
WinterAbsent: *_Clima set controlMode night => Bei "kurzer" Abwesenheit wird die Temperatur abgesenkt. Ab dem nächsten Schaltzeitpunkt der Templisten übernimmt wieder die Automatik. Hoffe ich.
WinterGone: *_Clima set controlManu 15.0 => Bei "längerer" Abwesenheit/Urlaub wird die Temperatur auf 15 Grad abgesenkt.
WinterHome: *_Clima set controlMode day => Bei Anwesenheit wird die geheizt. Ab dem nächsten Schaltzeitpunkt der Templisten übernimmt wieder die Automatik.

Über ein eventMap wird jeweils der verkürzte Status zurückgegeben (absent/gone/home)

Wandtaster
Hier steckt die zentrale Schaltlogik. Mit acht DOIF werden abhängig vom Heizungsmodus (Sommer/Winter) die LightScenes geschaltet.

Weitere Ideen
Bisher ist der Wandtaster das zentrale HomeStatus Element, da ich von der bisherigen Smartphone Erkennung nicht überzeugt bzw. zu fehleranfällig war. Ggf. ergänze ich das alles noch um PRESENCE und ROOMMATE. Aber erst mal teste ich das so

[timtom]

Hmmm heute ist mir etwas komisches aufgefallen.

Ich habe "Heizungswerte" readingsGroup aus dem Wiki nachgebaut, die mir bestimmte Werte alle Thermostate zusammenfasst. Keine Ahung, ob das etwas mit folgendem zu tun hat oder Zufall ist.

Sobald ich über "set az_Heizung_Clima controlMode day" in fhem ein Thermostst in den Day-Modus versetzten möchte, ändert sich der Status des Thermostats in "set_day". Kurze Zeit später wechselt der Modus wieder in "auto".

Dabei ist mit aufgefallen, dass dieses Statusänderung auf die Sekunde genau dann auftritt, sobald im "Event monitor" diverse Readings zu dem Thermostst zu sehen sind zu sehen und die Readingsgroup angepasst wird.

Code Auswählen Erweitern

2016-11-11 18:41:06 readingsGroup Heizungswerte az_Heizung.batteryLevel: image/svg+xml                                  (2.7 V)
2016-11-11 18:41:06 CUL_HM az_Heizung actuator: 31
2016-11-11 18:41:06 CUL_HM az_Heizung battery: ok
2016-11-11 18:41:06 CUL_HM az_Heizung batteryLevel: 2.7
2016-11-11 18:41:06 CUL_HM az_Heizung desired-temp: 19.0
2016-11-11 18:41:06 CUL_HM az_Heizung measured-temp: 19.4
2016-11-11 18:41:06 CUL_HM az_Heizung motorErr: ok
2016-11-11 18:41:07 readingsGroup Heizungswerte az_Heizung_Clima.measured-temp: 19.4 °C
2016-11-11 18:41:07 readingsGroup Heizungswerte az_Heizung_Clima.ValvePosition: 31 %
2016-11-11 18:41:07 readingsGroup Heizungswerte az_Heizung_Clima.desired-temp: 19.0 °C
2016-11-11 18:41:07 readingsGroup Heizungswerte az_Heizung_Clima.controlMode: auto
2016-11-11 18:41:07 CUL_HM az_Heizung_Clima ValvePosition: 31
2016-11-11 18:41:07 CUL_HM az_Heizung_Clima boostTime: -
2016-11-11 18:41:07 CUL_HM az_Heizung_Clima controlMode: auto
2016-11-11 18:41:07 CUL_HM az_Heizung_Clima desired-temp: 19.0
2016-11-11 18:41:07 CUL_HM az_Heizung_Clima measured-temp: 19.4
2016-11-11 18:41:07 CUL_HM az_Heizung_Clima partyEnd: -
2016-11-11 18:41:07 CUL_HM az_Heizung_Clima partyStart: -
2016-11-11 18:41:07 CUL_HM az_Heizung_Clima partyTemp: -
2016-11-11 18:41:07 CUL_HM az_Heizung_Clima T: 19.4 desired: 19.0 valve: 31
2016-11-11 18:41:07 CUL_HM az_Heizung_Weather measured-temp: 19.4
2016-11-11 18:41:07 CUL_HM az_Heizung_Weather 19.4

Im Thermostat sind Templisten hinterlegt. Kann das damit was zu tun haben? Ich war jedoch davon ausgegangen, dass der "day" Modus bis zum nächsten Schaltzeitpunkt der Listen beibehalten wird.

Ich hab echt keine Ahnung was hier triggert. Ich hab schon alle DOIF und LightScene durchgeschaut. Nichts.

[DeeSPe]

Das Verhalten ist normal und bei mir auch so.
Nach set_day kommt wieder auto.
Ich denke das ist zum Signalisieren dass am nächsten Schaltzeitpunkt der Temp-Liste wieder der Auto-Modus greift.
Die Temperatur bleibt doch auf Tagestemperatur oder?

Gruß
Dan

P.S. Bei controlMode manual sollte nach set_manual auch manual im Reading stehen.

[timtom]

Das Verhalten ist normal und bei mir auch so.
Nach set_day kommt wieder auto.
Ich denke das ist zum Signalisieren dass am nächsten Schaltzeitpunkt der Temp-Liste wieder der Auto-Modus greift.
Die Temperatur bleibt doch auf Tagestemperatur oder?

Gruß
Dan

P.S. Bei controlMode manual sollte nach set_manual auch manual im Reading stehen.

Danke. Ich Doof. Ich hatte mir doch tatsächlich genau das RT angeschaut, wo die Templiste fehlerhaft war. Sorry. Stimmt natürlich alles, so wie du es beschrieben hast.

[timtom]

Ich benötige noch mal eure Hilfe.

Ich habe einen Dummy, der den Anwesenheitsstatus speichert

Code Auswählen Erweitern

define ZuhauseStatus dummy
attr ZuhauseStatus setList state:Auto,KurzWeg,LangeWeg,Zuhause

Dieser wird direkt per App und per DOIF Wandtaster gesteuert

Code Auswählen Erweitern

define di_WandtasterAktion DOIF
([fl_Wandtaster:state] eq "fl_WandtasterRunter Short") (set ZuhauseStatus KurzWeg) DOELSEIF
([fl_Wandtaster:state] eq "fl_WandtasterRunter Long") (set ZuhauseStatus LangeWeg) DOELSEIF
([fl_Wandtaster:state] eq "fl_WandtasterHoch Short") (set ZuhauseStatus Zuhause) DOELSEIF
([fl_Wandtaster:state] eq "fl_WandtasterHoch Long") (set ZuhauseStatus Auto)
Brauche ich noch ein <do always>, damit der Status auch über den Wandtaster gesetzt wird, wenn dieser zwischenzeitig per App umgestellt wurde (und der Taster noch den "alten" Status hat)? Oder wäre es besser, den ZuhauseStatus in das DOIF einzubauen?

Weiterhin möchte ich etwas tun, wenn niemand zu Hause ist und die Tür geöffnet wird

Code Auswählen Erweitern

define di_info DOIF ([ZuhauseStatus] ne "Zuhause" and [fl_Haustuer] eq "open") (set xyz abc)

Dann hab ich noch ein DOIF am ZuhauseStatus, um weitere Aktivitäten durchzuführen.

Code Auswählen Erweitern

define di_ZuhauseStatusAktivitaeten DOIF ([ZuhauseStatus:state] eq "KurzWeg") (set Heizung ...

Folgende Anpassungen möchte ich gerne einbauen bzw. Fragen klären:

Fall 1 (ich gehe weg):
drücke den Wandtaster -> öffne die Türe -> schließe die Türe
Damit nicht sofort <set ayz abc> durchgeführt wird, setzte ich den Anwesenheitsstatus für das Verlassen mit 60Sek Verzögerung. Dadurch wird das <di_info> 60 Sek später "scharf"geschaltet.

Code Auswählen Erweitern

attr di_WandtasterAktion wait 60:60:0:0

Fall 2 (ich komme wieder):
öffne die Türe -> (ggf.) schließe die Türe -> drücke den Wandtaster
<di_WandtasterAktion> wurde wie oben angepasst. Damit würde das <di_info> aber immer noch sofort sofort getriggert werden. Also könnte ich dies mit <wait> verzögern und mit <do always> sicherstellen, dass <set ayz abc> auch durchgeführt wird, wenn die Türe inzwischen wieder zu ist. Richtig?

Code Auswählen Erweitern

attr di_info wait 30
attr di_info do always

Fall 3:
Da ich einige der Aktivitäten von <di_ZuhauseStatusAktivitaeten> durch erneutes Drücken des Wandtasters erneut durchführen möchte, benötige ich dort auch noch ein

Code Auswählen Erweitern

attr di_ZuhauseStatusAktivitaeten do always

Fehler abfangen 1:
Jetzt ist es ja so, dass durch die vielen <do always> möglicher Weise viel (unnötiger) Funkverkehr erzeugt wird. Wenn ich mich z.B. auf dem 'Wandtaster "Verdrücke" und nach oben drücke (Zuhause) gehen alle Heizkörper an. Da ich mich ja vertan hab, drücke ich sofort wieder runter (KurzWeg) schalte ich direkt wieder alle aus. Es müsste also das DOIF des Wandtasters erst verarbeitet werden, wenn z.B. n Sekunden keine Status-Änderung mehr erkannt wurde. Zusätzlich sollte die o.g. Funktionalität, die ich durch "do always" eingeführt habe, weiterhin gegeben sein. Da stehe ich etwas auf dem Schlauch.