Heizungssteuerung - Schichtplan

[hoschi]

Hallo zusammen,

ja, ich hab durch das Forum gestöbert und gegoogelt und ich bin mir bewusst, dass das nicht der erste Beitrag zu dem Thema ist. Mein Problem ist momentan eher weniger das Verständnis sondern die Art der Umsetzung, da es mehrere Ansätze gibt. Bevor ich mich da also blindlinks in eine Richtung Stürze würde ich gern ein wenig von eurer Erfahrung profitieren. Dazu muss ich wohl ein wenig ausholen.

Ich arbeite im Schichtbetrieb und habe dort einen alle 10 Wochen rotierenden Schichtplan. Woche 1 und 2 sind gleich, Woche 3 und 4 auch. Der Plan ist EIGENTLICH fix, aber aufgrund von Urlaub und Krankheit können hier immer wieder Änderungen auftreten.
Grundsätzlich gibts es 5 verschiedene Schichten: Früh, Tag, Spät, Nacht, Wochenende Tag, Wochenende Nacht
Diese Schichten verwalte ich in meiner iPhone App, welche entweder einen iPhone Kalender füllen, als csv direkt exportiert oder aber per Software als iCal aus dem iPhone Kalender exportiert werden kann. Das man einen öffentlichen iCloud-Kalender bereitstellen und einlesen kann ist mir bewusst, das möchte ich aber nicht. Ich würd den Kalender im Falle einer Änderung manuell auf FHEM übertragen, auf die ein oder andere Weise.

Ich benutze Homematic Thermostate mit derzeit integriertem Sensor, sowie das Raspi-Modul von ELV. Fenstersensoren sind derzeit nicht verbaut.
Diese Thermostate haben, wie ihr sicher wisst, die Möglichkeit manuell gesteuert zu werden oder automatisch Wochenprogramme abzuspulen.

Grundsätzlich wäre eine automatische Abarbeitung von Wochenplänen wohl das, was zuerst als Vorschlag käme? Vermutlich besteht die Möglichkeit aus einem eingelesenen Kalender z.B. Sonntag abends die nächsten 7 Schichten auszulesen und basierend auf den Werten den richtigen "Wochendummy" zu setzen?

Hier ergibt sich aber laut meinem Verständnis das Problem, das ich ja auch in meiner Freizeit nicht permanent zu Hause bin. Hier könnte man mit der schon für die Beleuchtung implementierten Abwesenheitserkennung arbeiten. Ist das Thermostat allerdings im AUTO Modus, dann, so habe ich gelesen, überschreibt das Wochenprogramm einen manuell gesetzten Wert, wobei ich gestehen muss, dass ich nicht weiss, ob das bei jedem Kontakt zum Thermostat der Fall ist oder zu den Triggerzeiten. Im ersten Falle würde ein "Anwesenheit off --> set desired-temp" überschrieben und meine Logik ist dahin. Im Falle letzteres ist anzunehmen, würde sich hier eine Möglichkeit ergeben, die dann allerdings wieder zum nächsten Problem führt, die Arbeitszeit. Wäre ich also ausser Haus würde ich die Automatik abschalten und erst bei der Rückkehr von der Arbeit mittels Anwesenheit auf AUTO stellen, somit ist die Bude und vor allem das Bad kalt.

Ziel ist, unabhängig von Schicht oder frei:
- "Kurz" vorm Aufstehen mindestens das Bad anheizen
- Beim Verlassen der Wohnung (evtl verlassen + 1 Stunde um kurze Abwesenheiten nicht zu berücksichtigen) Temperatur absenken
- VOR Ankunft die Wohnung wieder auf Temperatur bringen
(- beim eventuellen erneuten Verlassen >1 Stunde absenken)
- zur Schlafenszeit absenken

Weitere Punkte die mir in den Sinn kommen. Ich habe zwar FREIschichten, aber auch diese unterscheiden sich danach, ob sie nach einer Nachtschicht oder Früh/Spätschicht stattfinden. Hier würde es vermutlich eher Sinn machen die, so denn umsetzbar, Wochenpläne als templates entsprechend zu gestalten und über das "7 Tage pattern" (wenn möglich) zu prüfen und setzen, sprich eine Freischicht nach einer Nachtschicht bleibt eine (leicht abgewandelte) Nachtschicht, die in den ein oder 2 darauffolgenden Tagen in Richtung Muster der nächsten Schicht driftet.

Was ich bisher auch nicht rausfinden konnte ist, ob es eine Möglichkeit gibt die im iPhone gestellten Wecker oder die dort einstellbare "Schlafenszeit" evtl. als trigger zu nehmen ? Homekit ?

Wie oben beschrieben stellen sich mir beim automatischen abspulen vor Wochenprogrammen Fragen, eine manuelle Umsetzung kann ich mir unter den für mich bisher gesetzten Anforderungen nicht vorstellen, wie ich das umsetzen könnte.
Des weiteren bin ich mir nicht sicher, ob ich zu sehr ins Detail denke oder ob erfahrungsgemäss eine weniger granulare Abstimmung durchaus denkbar und praktikabel ist.

Anhand dieser zugegebenermassen umfangreichen Informationen, was wäre eurer Auffassung nach eine möglichst praktikable und zielführende Art der Umsetzung ?
Meine Denkansätze scheinen an mir selbst oder allgemein zu scheitern, ich dreh mich seit Tagen im Kreis und finde keinen Lösungsweg.

Vielen Dank im Voraus
Hoschi

[dkreutz]

Ich würde hier mit Profilen (Weekprofile) für die einzelnen Schicht-Arten anfangen. Soweit ich verstehe, geht es Dir hier um den Komfort (Bad ist zum richtigen Zeitpunkt geheizt).

Das Thema "Heizung bei Abwesenheit runterfahren" ist ein eigenes - warum möchtest Du das tun? Falls Heizkosten einsparen dahinter steckt: das ist stark abhängig von der Art der Beheizung - Fussbodenheizungen sind z.B. in der Regel so träge, dass eine Absenkung für ein, zwei Stunden sich überhaupt gar nicht auswirkt.

Nach meinem Verständnis kann die Schlafenszeit-Funktion von Apple über Homekit/Homebridge nicht abgefragt werden.

[Prof. Dr. Peter Henning]

Das Modul 95_YAAHM.pm bietet eine komfortable Möglichkeit zum Verwalten von Wochenplänen. Inklusive der Möglichkeit zu manuellen Änderungen.

LG

pah

[hoschi]

Vielen Dank fürs Feedback.

Richtig, mir geht es hier primär um den Komfort und meine Faulheit Das Bad soll zu den potentiellen "Duschzeiten" keine Kühlbox sein, die Wohnung soll die entsprechend gewüschte Temperatur haben, wenn ich nach Hause komme oder zu Hause bin und natürlich soll nicht sinnlos geheizt werden, wenn ich nicht da bin oder mich grillen, wenn ich schlafe. Es handelt sich um eine Mietwohnung mit normalen Wandheizkörpern.

@dkreutz
Wenn ich mit den Weekprofiles arbeite, wie würde man eine Intervention bei geänderter Schicht optimal angehen ? Zum Beispiel sollte ich laut Plan die ganze Woche Früh arbeiten, aber durch Änderungen habe ich nun 3 Tage Früh, 2 Tage Spät.
Wird ein Weekprofil mit "Tagesdummys" (Heizplan anhand Schichtart) erstellt, diese gegen den aktuellen Schichtplan geprüft und im Falle einer Änderung ein anderer Tagesdummy im Wochendummy gesetzt ?

Über Calendar kann ich next Event anzeigen lassen, aber auch die Events der nächsten 7 Tage

Code Auswählen Erweitern

get Schichtplan events format:custom="$T1 $S" limit:count=7,from=+1d
15.10.2018 21:30 Night
16.10.2018 08:00 Freischicht
17.10.2018 08:00 Freischicht
18.10.2018 21:30 Night
19.10.2018 21:30 Night
20.10.2018 18:00 Weekend Night
21.10.2018 18:00 Weekend Night

Es sollte doch hiermit denkbar sein die "Generierung" eines Wochenprofils zu erstellen, was z.B. Sonntag abends geschieht und auf die Thermostate übertragen wird ?
Wie ich lese sind hier aber textfiles manuell zu editieren, sprich ich würde wohl eher die "manuelle" Steuerung der Wochenplände vorziehen müssen?
Sprich anhand dem ausgelesenen erstelle / editiere ich einen Dummy, der mit prep die einzelnen Tage am Device vorbereitet und setzt ?
Sind natürlich kurzfristige Änderungen angesetzt gugg ich in die Röhre

@pah
Danke für den Hinweis auf das Modul. Ich schaue es mir grade an, habe ein specialDevice mit meinem Kalender erstellt, aber Events bekomme ich nicht angezeigt, weil vermutlich "Diese Kalenderdaten werden jeweils kurz nach Mitternacht eingelesen und in der Zusammenfassung angezeigt.". Kann man das testweise manuell triggern ?
Was ich grad nicht erkennen kann ist, ob und wie ich hier anhand von Kalenderdaten agieren kann.
Ist das Modul eher dazu zu benutzen "manuell" das aktuelle Wochenprofil auszuwählen, welches dann für den Zeitraum bis zur Änderung des Profils Aktionen für mich ausführt ?


FHEM letzte Woche aufgesetzt, begeistert und erschlagen vom Umfang
Es ist einfach "cool" das Haus zu verlassen und das Licht und Media gehen aus.. man kommt heim und stolpert nicht über liegengelassenes, weil man LICHT hat. Wie war das Leben früher nur mit diesen.. wie hiessen sie noch ? Achja, Lichtschaltern ?

Ich "spiele" derzeit einfach viel rum und sammle Infos, versuche Zusammenhänge (besser) zu verstehen. Das System wird mit Sicherheit irgendwann demnächst wieder platt gemacht und mit besserem Verstädnis frisch aufgesetzt.


Vielen Dank
Hoschi

[dkreutz]

Ich würde für jeden der fünf Schichttypen ein weekprofile anlegen, welches dann für alle Wochentage die Heizzeiten für den Schichttyp enthält.

Täglich um Mitternacht dann Prüfung anhand des Kalenders welcher Schichttyp für den Tag gilt und dementsprechend das Profil einstellen.

[hoschi]

Das dürfte so wie ich dich verstehe nicht gehen. Ich habe 10 Wochen, davon sind nur 1 und 2 , sowie 3 und 4 gleich, wenn keine Änderungen auftreten. Sprich ich müsste 8 komplette Wochenpläne anlegen und die dann "irgendwie" an bestimmten geänderten Tagen überstimmen.
Ich hab z.B. nächste Woche 3 x Nacht und 2 x Wochenende Nacht, da könnte ich täglich anlegen, aber weekly nicht anhand des nächsten Tages ?
Genau so wie ich z.B. 2 Tage Tagschicht und dann am WE Tagschichten hab, welche andere Zeiten erfordern.

[Prof. Dr. Peter Henning]

Das System wird mit Sicherheit irgendwann demnächst wieder platt gemacht und mit besserem Verstädnis frisch aufgesetzt.

Sorry, aber das ist typisches Verhalten von Windows-Usern. Vollkommen unnötig, weil man das "System" nicht in einen undefinierten Zustand versetzen kann.

LG

pah

[hoschi]

Das kam vielleicht falsch an. Ich probiere derzeit Module aus, lege mehrere Instanzen von was weiss ich nicht was an, spiele einfach herum. Am Ende suche ich mir heraus was ich will und gehe Schritt für Schritt vor, um meine eigene Doku im selben Zug zu erstellen.
Ich hab übrigens nur 2 Windows-Systeme für die ich verantwortlich bin, der Rest ist Solaris, RHEL, CentOS, Debian bare metal oder im ESXi Cluster

Vielleicht hab ichs überlesen, aber ich finde nichts, wo das specialDevice im YAAHM anzusprechen, zu triggern ist. Mein Kalender ist drin, aber in der Übersicht taucht der nächste Event nicht auf. Ich scheine da ein Verständnisproblem zu haben. Könntest du da bitte kurz drauf eingehen ?

Gruss Hoschi

[Tedious]

Ganz im Ernst - warum so kompliziert? Ich würde da mit nem Geofence arbeiten - wenn auf der Arbeit Heizung runter drehen, wenn auf dem Heimweg Heizung hoch fahren. Das Ganze mit nem GTag kombinieren damit er zusätzlich weiß wenn Du zuhause bist und an sich ist alles startklar... sind ja Heizkörper, denn sind die Räume ja schnell warn da nicht so träge wie bei FBH (wie bei mir)... oder übersehe ich was und denke zu einfach? Ich würde das so simpel wir möglich halten um etwaige Feherquellen zu minimieren. Wenn denn noch der Parameter "Bad immer kalt außer zum duschen auch wenn zuhause" hinzu kommt würde ich das über nen Trigger abfangen (z.B. Taster oder Wecker)...

[Prof. Dr. Peter Henning]

Wieso triggern ?

specialDevice, holidayDevice, vacationDevice sind einfach Kalender, die Daten bereitstellen. Ob dies korrekt geschieht, kann man außerhalb von YAAHM in den jeweiligen Calendar- oder holiday-Devices testen, z.B. mit get <calendar-device> text upcoming

Ich würde mir in YAAHM mehrere Wochenprofile anlegen. Und dann  mit einem externen Dummy und einem kleinen notify das Profil aktivieren, was gerade für die kommende Woche relevant ist.

LG

pah

[hoschi]

Vielen Dank fürs Feedback.

@tedious
Du hast natürlich recht - KISS würde ich auch gern bei der Automation weitestgehend umsetzen, mangels Erfahrung mit selbiger tue ich mich da derzeit n bisschen schwer.

bzgl Geofencing:
Die Geofency App auf dem iPhone habe ich schon ausprobiert, funktioniert auch ganz gut, jedoch nur unter der Prämisse, das ich meine Firewall zumindest für "world" oder limitiert auf die outgoing IP im Büro UND den/die Adressbereich/e meines Mobilfunkproviders öffne, um den Geolocation Status zu setzen. Das ist für meine Begriffe ein wenig zu offen.
OpenVPN mit Zertifikaten als Alternative funktioniert auch nur solang das iPhone nicht im Standby ist, da das VPN in dem Falle deaktiviert wird (auch wenn es sich bei Rückkehr in den normalen Modus instant wieder verbindet) Die kleinstmöglich einstellbare Auflösung für die GeoLocation sind 100m, sprich würde ich mich auf webhook = private FHEM IP beziehen, triggert die App meist schon bevor ich den Abdeckungsbereich meines WLAN erreiche. Im Falle einer dedizierte Location für Büro und der Freigabe der Büro-IP in der Firewall würde ich diesen WLAN-Bereich auch schon verlassen haben, bevor die App das Verlassen triggert.
Ein weiterer Punkt ist der kurze Arbeitsweg von irgendwas zwischen 5-10 Minuten, das würde m.E. keinen wahnsinnigen Vorteil gegenüber den Nachteilen bringen und ich könnte meine derzeitige Anwesenheitsschaltung über iPhone Bluetooth --> Raspi ebenfalls verwenden.

bzgl Anwesenheit:
Da ich unterschiedlich zu Hause bin, somit auch unterschiedliche Schlafenszeiten habe, müsste zusätzlich zur Anwesenheit auch eine Logik die Absenkung zur Schlafenszeit regeln.
Absenken beim Verlassen wäre jedoch eine Option.

Manuell vs Automatik:
Soweit ich gelesen habe ist eine manuelle Steuerung umfangreicher und erzeugt mehr Funkverkehr, was wiederum auch zu Lasten der Batterien geht. Sollte mich der erhöhte Funkverkehr stören ? Bzgl der Batterielaufzeit hab ich auch noch keine Erfahrungswerte, wenn Manuell 6 Monate und Automatik 18 Monate sind wäre das sicher auch zu bedenken.

Ich hab mal ein PDF angehangen, was die Anforderungen der Zeiten beschreibt, 0 = blau = Abgesenkt, 1 = rot = Heizphase.

Gehen wir davon aus der eigentlich fixe Plan hat keine Änderungen treten keine Wechsel von Früh auf Tag, Tag auf Spät, Spät auf Nacht usw. innerhalb einer Woche auf, es gibt allerdings Wochen in denen regulär normale Tagschichten und WE Tagschichten auftauchen. Es gibt Freischichten nach jeder Art von Schicht, wobei eine Freischicht nach einer NAchtschicht natürlich auch andere Anforderungen hat als eine Freischicht nach einer Tagschicht. Es wird in dem Falle also immer granularer und das machts mir derzeit schwierig eine für mich passende Lösung zu finden.


@pah

Ich hatte in meinem Kalender einen falschen Eintrag drin, welcher den Kalender in YAAHM nicht laden lies. Daher die Frage ob ein manuelles laden möglich wäre, um nicht bis zum automatischen laden um kurz nach Mitternacht zu warten.
Leider habe ich noch nicht die Zeit gefunden mich intensiv mit dem Modul zu beschäftigen, werde das aber die nächsten Tage mal angehen und versuchen umzusetzen. Danke für die Hinweise.


Gruss
Hoschi

[Tedious]

Hm... vielleicht eine Fernbedienung "missbrauchen"? Ich nutze alte Intertechno Fernbedienungen um Squeezeboxen zu steuern (von alten 433 MHz Funksteckdosen übrig, letztere sind ausgemustert). Haben 8 Tasten, in jedem Raum mit einer Squeezebox hängt eine an der Wand. FHEM empfängt die Tatstendrücke, und ein DOIF schaltet die Squeezebox an, aus, lauter, leiser, Play, Pause etc...

Man könnte natürlich jeder Taste einen Schichtplan (Schaltzeiten) früh/spät etc (oder frei) zuweisen und per DOIF das aktuelle Heizprogramm übergeben. Presence überwacht denn nur noch ob Du zuhause bist (wie jetzt schon, wenn ich das richtig verstanden habe), an der Haustür im Flur (oder sonst wo) könnte ne Fernbedienung hängen die bei Knopfdruck die Programme wechselt. Denn drückst du bspw. am Montag die 1 ("Frühschicht"), kommst am Dienstag heim und drückst die 2 ("Urlaub/Frei') und bräuchtest Dich um nix kümmern nur weil Du einen Tag frei hast. Donnerstag morgen denn eben wieder die 1. Vorteil: kurzfristige Planänderungen könnten direkt übergeben werden... nur als Idee.

[Toto1973]

Das Problem mit der Heizung im Bad habe ich über einen Wecker gelöst. Ich stelle in FHEM ein, wann ich an nächsten Tag geweckt werden will. Da ich nur 2 Schichten arbeite, ist das einmal um 4 Uhr und das andere Mal um 8:30 Uhr. Dazu gibt es entsprechende Dummys. Natürlich kann ich den Wecker auch manuell stellen, wenn ich in der Mittelschicht mal länger schlafen will oder frei habe.
Die Weckzeit - 20 Minuten ist dann die Zeit, zu der der Heizkörper im Bad auf 22 Grad geschallten wird.
Das alles habe ich über DOIF gelöst. Ich schalte die Heizkörper auch manuell, ohne Wochenprogramm.

[locodriver]

Ich habe ziemlich unregelmäßige Arbeitszeiten und entsprechend einige Szenarien angelegt, teils als Templates, teils als direkte fhem-Befehle (habe HM).

Dazu sind zwei Dummies definiert (BAjetzt, BAmorgen). Diese kann ich händisch beeinflussen, bestimmte Abläufe gehen automatisch. In der Nacht gegen 22:30 wird dann BAmorgen in BAjetzt kopiert und damit ein neuer Modus wirksam. Solange ich BAmorgen nicht ändere, wird das selbe Szenarium jede Nacht neu kopiert und damit aktiv. D.h. nur bei einem Wechsel des Szenariums ist eine entsprechende Änderung von BAmorgen nötig. So muss ich bei aufeinander folgenden Frühschichten nur am Tag vor der ersten den Dummy umstellen, dann wird er nächlich kopiert.
Ich fahre damit für meine Zwecke gut. Wie man die Dummies beeinflusst ist dann Geschmachssache...

[hoschi]

Vielen Dank für die zahlreichen Ideen und Denkanstösse.
Momentan nutze ich erstellte Wochenpläne und schreibe diese manuell, damit überhaupt erstmal was läuft. Ich denke nach und nach werden hier "Verbesserungen" einfliessen.

Derzeit suche ich nach einer für mich praktikablen "schlafen" setzen Methode. "Schlafen" wäre z.B. wenn ein ((Receiver und/oder PC aus wären) und jemand anwesend ist), andererseits kann man das auch nicht immer zu 100% als gegeben hinnehmen. Die möglichen Scenarien sind halt sehr komplex.

Vielleicht hilft es dem ein oder anderen mit änhlicher Problemstellung, daher poste ich mal meine config bzgl Calendar Readings. Ob das jetzt so "optimal" oder "richtig" ist, oder ob man das besser in dummys auslagert statt in das Calendar device weiss ich derzeit nicht. Evtl ist auch andere Syntax vorzuziehen. Ich hab keine Möglichkeit gefunden für "rückwärtige Suche", vorwärts mit "upcoming" lief auf Anhieb.

Code Auswählen Erweitern

defmod Schichtplan Calendar ical file /home/pi/Schicht.ics 3600
attr Schichtplan cutoffOlderThan 3d
attr Schichtplan hideLaterThan 10d
attr Schichtplan hideOlderThan 3d
attr Schichtplan room Kalender
attr Schichtplan userReadings shiftLast {fhem("get Schichtplan events limit:count=1,from=-1d ") },\
shiftLast2 {fhem("get Schichtplan events limit:count=1,from=-3d") },\
shiftActual {fhem("get Schichtplan events limit:count=1,from=0 ") },\
shiftNext {fhem("get Schichtplan text upcoming 1") },\
shiftNext7 {fhem("get Schichtplan full upcoming 7 ") }

Das führt dann zur Folgendem:

shiftActual
20.10.2018 18:00 12:45 Weekend Night
2018-10-20 23:10:25
shiftLast
19.10.2018 21:30 9:30 Night
2018-10-20 23:10:25
shiftLast2
17.10.2018 00:00 24h Freischicht
2018-10-20 23:10:25
shiftNext
21.10.18 18:00 Weekend Night
2018-10-20 23:10:25
shiftNext7
4435  upcoming                     21.10.2018 18:00-22.10.2018 06:45 Weekend Night Schicht
4466  upcoming                     22.10.2018 08:00-22.10.2018 16:00 Freischicht Schicht
4445  upcoming                     23.10.2018 21:30-24.10.2018 07:00 Night Schicht
4424  upcoming                     24.10.2018 21:30-25.10.2018 07:00 Night Schicht
4457  upcoming                     25.10.2018 21:30-26.10.2018 07:00 Night Schicht
4436  upcoming                     26.10.2018 08:00-26.10.2018 16:00 Freischicht Schicht
4467  upcoming                     27.10.2018 08:00-27.10.2018 16:00 Freischicht Schicht
2018-10-20 23:10:25
state
triggered
2018-10-20 23:10:25

Ob und was ich damit anstelle steht derzeit noch zur inneren Debatte.
Einen FHEM-Wecker stellen, der zeitX vor dem Schichtbeginn anheizt und (zeitY vor Schichtbeginn oder absent) absenkt wäre ein Ansatz.
ZeitX vor Schichtende anheizen wäre denkbar.
Das Problem sind derzeit tatsächlich eher die Freischichten, da eine Freischicht nach der Nachtschicht andere Anforderungen hat als eine Freischicht nach Tagschichten.
Es steht auch immer noch die Frage ob ich Wochenpläne im AUTO Modus nutzen möchte oder jeden Tag die nächsten Schlatzeiten und -stati  setze. Oder täglich die nächsten 7 beginnend bei "R_0_tempList$Wochentag".

Fakt ist, das "rumspielen" macht echt Spass, könnte ein neues Hobby werden

Gruss Hoschi