Strukturierung Heizkörpersteuerung aus FHEM

[kroemmel]

Hallo,

nach dem ich jetzt seit rund 3 Monaten mit FHEM spiele, ausprobiere und durchweg zufrieden bin, möchte ich die Heizkörpersteuerung nun aus FHEM realisieren.

Aktuelle Situation:
Bisher habe ich FHEM lediglich dazu verwendet, die Temperaturlisten an die jeweiligen HM-CC-RT-DN zu senden. Von da an haben diese autark agiert und mich mit Statistiken zum Heizungsverlauf versorgt.

Wenn ich mal einen Tag zu Hause bin (oder das Hause für den Rest des Tages verlassen werde), habe ich mir einen Notifier, Dummy und ein kurzes Script in Anlehnung an den ZuHause Status gebastelt, welche bei Aktivierung über einen Notifier die Temperatur in den Wohnräumen entsprechend regelt. Jeden Abend um 20:55 (kurz vor der Nachtabsenkung) setzt FHEM den Status wieder auf Automatik (das dient aber eher der Optik, damit die richtige Lampe leuchtet )
(http://kroemmel.de/img_tmp/HausStatus.jpg)(http://kroemmel.de/img_tmp/HausStatusNotifier.jpg)

Das klappt - Forum und Wiki sei dank - auch schon recht zufriedenstellend. Problem dabei ist, sobald nach den Temperaturlisten auf den Heizkörperthermostaten eine neue Temperatur gesetzt wird, ignorieren die Thermostate natürlich den HausStatus in FHEM, da sie diesen ja nicht kennen.

Was wäre nun ein gutes vorgehen, bzw. wie macht ihr das?

Mir schwebt folgender Lösungsansatz vor:
Die Heizkörper von Auto- auf Manual-Modus umstellen.
Im Anschluss pro gewünschtem Schaltzeitpunkt und Heizkörper (oder Heizkörper-Gruppe?) wird ein AT (Wochentagsabhängig) erstellt, welches einen if/elsif gespickten Notify auslöst (je nach Haustatus).

Allerdings erscheint mir mein vorgehen da sehr kompliziert und aufwendig in der Pflege (bspw. wenn ich die generelle "Tag-Temperatur" von einem Heizkörper ändern möchte, oder ein HausStatus dazu kommt). Gibt es da einen eleganteren Weg? Vielleicht stehe ich auch nur grad auf dem Schlauch...

Wie gesagt: Nicht das Scripten macht mir sorgen (da ist die Doku hervorragend!), sondern eher die allgemeine Herangehensweise, wie Dinge sauber zu strukturieren und zu lösen sind. Bezüglich genau dieser Strukturierung der Logik in FHEM habe ich bisher noch nichts generelles oder allgemeine Lösungsansätze gefunden.

Vielleicht könnt ihr mir hier ja mit ein paar Best-Practice beispielen helfen...

Grüße,
Florian

[martinp876]

weist du, wann du wieder kommst? Du könntest den Partymode verwenden. Du wählst eine temperatur, rerechnest eine Zeitspanne und sendest 'party' Nach Ablauf der "Party" schaltet der RT zurück in den normal-mode.

[kroemmel]

Moin!

Danke für den Tipp - ich hab's mir gleich durchgeschaut.

Für einen "Urlaub außer Haus" - also durchweg konstante Temperatur klingt das nach einem praktikablen Ansatz. Einzig nach der Integration eines DateTime-Pickers muss ich noch schauen, um das Ehefrauen-Kompatibel zu bekommen

Den "Urlaub zu Hause" löse ich über einen Umweg (Dummy Status + Party-Modus + 2 ATs).

Perfekt! Das klingt deutlich weniger umständlich als mein Ansatz.

Grüße,
Florian

[kroemmel]

Hallo, ich noch mal

Um nach dem Partymodus wieder zurück zur Automatik zu finden, habe ich mir überlegt, den Status per on-for-timer zu setzen und mittels follow-on-for-timer eine Aktion beim Ende-Datum auszulösen. Das klappt schon mal prima und tut auch exakt was ich mir vorstelle.

Code (Macro für Urlaub außer Haus) Auswählen Erweitern

#####################################################################################
# Macro: Urlaub außer Haus
# setzen von XX.X Grad in der ganzen Hütte. Aufruf per "{Set_Urlaub_Weg ("GRAD", "Start DD.MM.YYYY", "HH:MM", "End DD.MM.YYYY" ,"HH:MM")}"
# Bspw.: {Set_Urlaub_Weg ("16", "27.02.2014", "13:00", "27.02.2014" ,"15:00")}
#####################################################################################
sub
Set_Urlaub_Weg($$$$$)
{
#lokale Variablendeklaration
    my ($temp,$startDate,$startTime,$endDate,$endTime) = @_;

# HM-CC-RT-DN akzeptiert nur Zeiten, die auf Minute 00 oder 30 enden.
    # Daher $startTime und $endTime abrunden
    $startTime =~ s/\:[0-2].$/:00/;
    $startTime =~ s/\:[3-5].$/:30/;
    $endTime =~ s/\:[0-2].$/:00/;
    $endTime =~ s/\:[3-5].$/:30/;

# Datum holen für on-for-timer (Sekunden, berechnet von Unix 0)
my $dateNow = DateTime->now();

# Erzeugen Ende-Datum ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)
my $dateEnd = DateTime->new(
year       => substr($endDate,6,4),
month      => substr($endDate,3,2),
day        => substr($endDate,0,2),
hour       => substr($endTime,0,2),
minute     => substr($endTime,3,2),
second     => 0,
);

# Berechnung der Laufzeit vom Urlaubsmodus in Sekunden
my $dateDiff = $dateEnd->epoch() - $dateNow->epoch();

        # Testausgabe der Daten im Log zur Validierung
{ fhem (Log 0, $dateNow)}
{ fhem (Log 0, $dateEnd)}
{ fhem (Log 0, $dateDiff)}

    #Sendebefehl für die HM-CC-RT-DN
{ fhem ("set whg_HausStatus6 on-for-timer $dateDiff")}
# { fhem ("set OG_az_Heizung_Clima controlParty $temp $startDate $startTime $endDate $endTime")}
}
# End Set_Urlaub_Weg

Also habe ich den Vormittag mit Datumskonvertierungen und co für die Berechnung vom Ende-Zeitpunkt zum Jetzt-Zeitpunkt verbracht, um festzustellen, dass ein on-for-timer maximal 15.360 Sekunden (4 Stunden, 15 Minuten) schluckt und ein AT nur bis zu 23:59:59h in der Zukunft ermöglicht. 
Auch der dann flugs zusammengesuchte Watchdog mag nur mit einem <timespec> von HH:MM[:SS] arbeiten. Also gleiches verhalten wie beim AT.

Gibt es eine Möglichkeit, ein AT an einen bestimmten Datum auszulösen? Oder den on-for-timer auf mehr als die genannten 4,25 Stunden zu verlängern? Die Logs auf eine Meldung vom HM-CC-RT-DN zu parsen, dass er wieder im Auto-Modus läuft, ist mir zu unsicher. Vor allem, wenn nicht alle RTs in den Party-Mode gesendet werden sollen wird das arg unübersichtlich.

Danke erneut!

Grüße,
Florian

[martinp876]

Hi,

was schaltest du mit on-for-timer? follow-on-for-timer sehe ich nur bei FS20.
hm ontime ist begrenzt auf 85825945.6sec begrenzt, also nicht mehr als 2,7 Jahre.

Mir ist nicht klar, was whg_HausStatus6 ist.

diff koennte man auch so berechnen

Code Auswählen Erweitern

    my ($ed,$em, $ey) = split /\./, $endDate;
    my ($eh,$emin) = split /\:/, $endTime;
    $emin = ($emin < 30):0?30;
    $eTime=timelocal(0,$eh,$emin,$ed,$em,$ey-1900);

    # Berechnung der Laufzeit vom Urlaubsmodus in Sekunden
    my $dateDiff = $eTime - time();

Gruss Martin

[kroemmel]

Hi Martin,

der on-for-timer schaltet meinen HausStatus (also ob wir da sind oder irgendwo in der Welt herumschwirren - siehe auch im ersten Post, erstes Bild). Das Ding ist in Vorbereitung für alle weiteren Schaltungen und Automatismen gedacht und verrichtet auch grundsätzlich gute Arbeit.
Hintergrund ist, dass meine Frau einfach zu bedienende Buttons im System haben möchte, über die sie bspw. "heute zu Hause" auf ihrem Smartphone setzen kann. Damit wird bspw. die Heizung dann auch tagsüber warm.

Zum basteln hab ich da damals ein virtuelles FS20 Modul (Funkfernbedienung mit 6 Kanälen) genommen, da ich da am wenigsten Interferenzen mit meinen restlichen HM Komponenten erwartet habe. Das FS20 an dieser Stelle zum limitierenden Faktor wird... Goddogottt... Da hab ich mir wohl selbst ein Bein gestellt. 
Die obige Lösung erschien mir bis vor kurzem noch praktikabel, habe ich doch genau diese virtuelle Fernbedienung in ein Dashboard gelegt und ihr ein Shortcut auf genau diese Seite auf dem Smartphone erzeugt.

Code (Damals verwendet zum anlegen der virtuellen Fernbedienung) Auswählen Erweitern

define whg_HausStatus1 FS20 696c 00
define whg_HausStatus2 FS20 696c 01
define whg_HausStatus3 FS20 696c 02
define whg_HausStatus4 FS20 696c 03
define whg_HausStatus5 FS20 696c 04
define whg_HausStatus6 FS20 696c 05


Wenn ich jetzt also eine virtuelle HM Funkfernbedienung erzeuge, könnte ich den hm ontime verwenden? Ich würde also analog zu dem FS20 virtuellen Device wie folgt ein HM virtuelles Device erzeugen (vorrausgesetzt, den HEX gibt es bei mir noch nicht):

Code Auswählen Erweitern

define neuer_HausStatus_HM CUL_HM 123456
define neuer_HausStatus_Automatik CUL_HM 12345601
define neuer_HausStatus_zuHause CUL_HM 12345602
define neuer_HausStatus_kurzMalWeg CUL_HM 12345603
...

Dann müsste das ja passen. Famos!

Was passiert denn jetzt, wenn ich mich dazu entscheide, tatsächlich eine Fernbedienung ins Haus zu legen? Kann ich den HEX Wert meines virtuellen Devices auf die reale Fernbedienung "umbiegen"?

Danke für den Tipp mit der diff-Berechnung: deutlich knackiger!

Grüße,
Florian

[martinp876]

Hallo Florian.

da sind viele Details.
Einen virtuellen Aktor baust du normal mit
define neuer_HausStatus_HM CUL_HM 123456
set neuer_HausStatus_HM virtual 3

danach kannst du renamen wie du willst.
Jetzt ist die Frage, was deine virtuelle Remote können soll.
Du kannst virtuelle buttons mit realen aktoren peeren.
Wenn du eine reale FB kaufst musst du neu peeren - die Adresse (HMId) aendert sich aber eine FB kann nicht viel

Die Schlüsselfrage ist, warum du eine virtuelle Remote willst und nicht einfach Kommandos sendest - das ist eigentlich first-selection

Gruss Martin

[kroemmel]

Hi Martin,

Die Schlüsselfrage ist, warum du eine virtuelle Remote willst und nicht einfach Kommandos sendest - das ist eigentlich first-selection

Genau darauf wollte ich mit meiner initialen Frage hinaus - was eigentlich bei FHEM best practice ist. 
Die virtuelle Fernbedienung dient für uns dazu, das gesamte System (= Haus) in einen bestimmten Zustand zu setzen (Wochentag zu Hause, Urlaub, ...) um damit bspw. die Heizkörper auf Anwesenheitstemperatur zu stellen. Das ganze soll - zumindest aktuell - noch ohne Präsenzerkennung laufen.

Was genau meinst du mit "einfach Kommandos senden" - per Eingabefeld im FHEM? Das würde ich gerne vermeiden, denn dann ist es nicht mehr Ehefrauen-Kompatibel. Und der Akzeptanz-Faktor ist doch recht wichtig, da ich nach und nach alle möglichen Themen hier zu Hause an FHEM anbinden möchte (Jalousie, Lichtsteuerung, Gartenbewässerung, Ambientebeleuchte drinnen und draußen usw....).
Mir erscheint es daher einfach und logisch, eine virtuelle Fernbedienung zu erzeugen, die ich / wir per Smartphone bedienen können. Handy liegt ja eh immer neben einem und vor allem kann ich dank VPN auch von einem beliebigen Urlaubsziel auf diesem Planeten kurz schauen, wie warm es in der Küche ist 

Die bisher zum Thema FHEM gefundenen Apps für Android haben mich noch nicht ganz überzeugt, daher per Dashboard / virtueller FB.

Vielleicht bin ich mit meinem Ansatz aber auch auf dem Holzweg...?

Danke für die Info mit dem virtuellen Device! Das wird gleich spannend

Grüße,
Florian

[martinp876]

Hallo Florian,

die FHEM zentrale ist eigentlich in sich eine virtuelle Fernbedienung.

denn dann ist es nicht mehr Ehefrauen-Kompatibel

klar - und abgesehen von "Ehefrau" - auch ich will min 90% des operationellen Bertiebs mit "einem Click" erledigen. Einschalten, auschalten, dimmen, scenarien. Um das zu erreichen bietet die normale Oberflaeche bereits einiges - den Rest sollte der Admin anpassen koennen.
Meine Strategie ist:
- entities durch das Attribut room zu gruppieren. Entscheidend ist hierbei, dass man eine entity in mehreren raeumen gleichzeitig unterbringen kann. So habe ich admin (actor,device) raeumliche (wohnzimmer,Kueche) und funktionale (licht,heizung,common,graph,notify,log) usw. Ein SW2 acktor mit 3 Entities hat dann
attr SW2Dev room device,Wohn,Licht
attr SW2_a1 room actor,Wohn,Licht
attr SW2_a2 room actor,Wohn,Licht
=> somit habe ich links eine liste aller "gruppen" die ich mit einem klick erreichen kann. Das kann man dann noch sortieren, so dass die wichtigen weiter oben liegen...
- in der room Ansicht werden die Komponenten mit dem primary-state angezeigt. Das reicht fuer die meisten (licht an/aus, heizung aktuelle temperatur,...) und man kann den state einfach anpassen, falls man etwas anderes hier sehen will.
- die Kommandos kann man dann eigentich auch recht simpel erstellen - per webCmd. Da hat man dann seine Aktions-buttons.

Noch habe ich das nicht auf einem Android probiert - aber das Prinzip sollte gleich sein. Das werde ich demnaechst einmal testen - steht noch aus.

Wichtig fuer den "Ehefrauen-akzeptanz-faktor" ist dann in erster Linie, sich eine eingaengige Struktur zu ueberlegen - zumindest fuer die "non-admin" Raeume (da schaut meine auch nie rein, kar). Und die sollte zukunftsicher sein, den haeufige Umstellung kann den nicht zu unterschaetzenden Groll der User nach sich ziehen

virtuelle FBs sind nur in Ausnahmen sinnvoll.

Gruss Martin

[kroemmel]

Hi Martin,

die individuelle Raumsteuerung (Licht, Heizung, Rolladen) habe ich in der Tat bereits in Räume integriert, schön sortiert nach Erdgeschoss, Obergeschoss und Garten. Da gibt es jeweils Einstellmöglichkeiten für die Heizkörper (pro HK ein setting) sowie teilw. Licht und Rolläden. Auch ein paar administrative Räume (Logs, Systeminfos, etc) habe ich erzeugt.
Mit dem Thema WebCmd muss ich mich noch eingehender beschäftigen. Aktuell nutze ich die per default von den jeweiligen Devices angebotenen Kommandos (Bei den HM-CC-RT-DN bspw. funktioniert das prima!).

Mein Ansatz mit dem HausStatus geht in die Richtung, vieles gleichzeitig zu schalten bzw. FHEM in verschiedene Modi zu versetzen. Ein Beispiel:
Modus "Automatik":
- Morgens Bad und Küche aufheizen
- Tagsüber auf der Arbeit, also Heizung im gesamten Haus absenken, Rolläden schauen nach dem Sonnenstand, Licht ist nirgends nötig.
- passend zum Feierabend ist Haus bereits aufgeheizt und empfängt mich mit offenen Rollos und Licht vor der Haustür.
- Nachts fahren die Heizkörper in die Nachtabsenkung
- Am Wochenende ist es ganztags warm...
- usw

Modus "zu Hause":
- Auch unter der Woche wird es tagsüber warm, Rolläden bleiben oben und in der Dämmerung geht das Flurlicht und Außenbeleuchtung an
- Nachts findet die normale Absenkung statt

Modus "Urlaub":
- gesamtes Haus geht in "den Kälteschlaf"
- Rolläden steuern sich abends
- verschiedene Random-Lights im Haus gehen an / aus
- Außenbeleuchtung findet in der Dämmerung statt

usw.

Dafür ist die beschriebene virtuelle FB gedacht. Ich glaube, dann bin ich grundsätzlich auf dem richtigen Weg mit FHEM, was meinst du?

Vielen Dank für deine Zeit & Mühe!

Grüße,
Florian

PS: Erste Kopplung virtuelle FB hat bereits geklappt. Cool!