Heizungssteuerung -Vorstellung-

Begonnen von Mitch, 20 Mai 2014, 09:27:15

Vorheriges Thema - Nächstes Thema

Mitch

Du musst die "Heizschaltungen" mit Bedingungen verknüpfen.
Hier z.B. Mit meinem Schalter:

DEF   
HZ_Bad_Clima 12345|06:00|22 12345|07:00|20 67|08:30|21.5 67|10:00|20 12347|19:30|21 12347|20:00|20 56|20:30|21 22:00|16 (ReadingsVal("HCAutomatik", "state", "") eq "on")
FHEM im Proxmox Container

Ascos

Zitat von: Mitch am 08 Februar 2015, 21:15:25
Du musst die "Heizschaltungen" mit Bedingungen verknüpfen.
Hier z.B. Mit meinem Schalter:

DEF   
HZ_Bad_Clima 12345|06:00|22 12345|07:00|20 67|08:30|21.5 67|10:00|20 12347|19:30|21 12347|20:00|20 56|20:30|21 22:00|16 (ReadingsVal("HCAutomatik", "state", "") eq "on")

Hey,

danke für die schnelle Antwort.
Das habe ich getan. Nur ist die Sache ja so, das wenn ich abwesend bin, die Heizautomatik ja trotzdem an ist. Somit wird zwar die aktuelle Temperatur abgesenkt, die nächst eingestellte, aber nicht, sondern ab dann normal weiter geheizt.

Zudem habe ich bemerkt, das wenn ich das Heizprogramm komplett ausschalten will, weg gehe und wieder zurück komme, es dann automatisch durch den Watchdog wieder aktiviert wird.

Ich weiß, das deine Vorlage nur ein Beispiel ist und auf die Wünsche angepasst werden muss, leider bin ich, wie gesagt, noch sehr neu in der Materie.
Wenn du einen Tip hättest, wie ich das umsetzen kann, wäre ich dir sehr dankbar.

Viele Grüße
Ascos
1x RaspberryPi 3, HMUART, HMLAN
4x HM-CC-RT-DN, 4x HM-Sec-SCo, 4x HM-TC-IT-WM-W-EU, 1 Jeelink, 4 Lacrosse Fühler, 2 LD382A
1x ZBox mit Kodibuntu, mehrere schaltbare Steckdosen

Mitch

Wie gesagt, mit Bedingungen verknüpfen!

Wie mein Beispeil mit dem Schalter, einfach die Abwesenheit rein, dann sollte der Schaltvorgang auf disable gehen, bis Bedingung erfüllt.

Genaus so könnte man es auch mit dem Fenster machen, wobei bei mir immer wieder auf Fenstertemp zurück geschalten, wird.
FHEM im Proxmox Container

Ascos

Zitat von: Mitch am 08 Februar 2015, 22:41:36
Wie gesagt, mit Bedingungen verknüpfen!

Wie mein Beispeil mit dem Schalter, einfach die Abwesenheit rein, dann sollte der Schaltvorgang auf disable gehen, bis Bedingung erfüllt.

Genaus so könnte man es auch mit dem Fenster machen, wobei bei mir immer wieder auf Fenstertemp zurück geschalten, wird.

Ja, das war es. Nun behält er die letzte abgesenkte Temperatur. Werde in die Notifys noch ein paar IF einbauen, hoffe dann klappt das alles. :)
1x RaspberryPi 3, HMUART, HMLAN
4x HM-CC-RT-DN, 4x HM-Sec-SCo, 4x HM-TC-IT-WM-W-EU, 1 Jeelink, 4 Lacrosse Fühler, 2 LD382A
1x ZBox mit Kodibuntu, mehrere schaltbare Steckdosen

Mitch

Aber wozu?
Ich will ja auch, dass die Heizung geschalten wird, wenn niemand Zuhause ist.

z.B. am Freitag kommt erst jemand ab 14 Uhr nach Huase, die Heizung soll aber schon ab 12 Uhr angehen, damit es dann warm ist.
Wenn ich das von der Anwesenheit abhängig mache, würde ja nicht geschalten werden.

BTW: Wenn Du dann "zurück" schalten willst, einfach die Temoeraturen neu einlesen.
Heating_Control_SetAllTemps()
FHEM im Proxmox Container

Mitch

Kleiner Update, habe jetzt ein bischen umgebaut.

Nutze jetzt DOIF und myUtils:

define ECOmode DOIF ([Anwesenheit] eq "Unterwegs") ({ecomode},{ecomodeHM}) DOELSEIF ([HZ.Absenkung] eq "on" or [Sonnenindikator] eq "on") ({ecomode},{ecomodeHM}) DOELSE ({Heating_Control_SetAllTemps()})
attr ECOmode do always
attr ECOmode wait 3600


In der 99_myUtils.pm:
sub ecomode {
my @FHT=devspec2array("TYPE=FHT");
foreach(@FHT)
{
  my $tp = ReadingsVal("$_", "desired-temp", "")-2;
  fhem("set $_ desired-temp ".$tp)
}
}

sub ecomodeHM {
my @HM_HT=devspec2array("HZ_.*._Clima");
foreach(@HM_HT)
{
  my $tpHM = ReadingsVal("$_", "desired-temp", "")-2;
  fhem("set $_ desired-temp ".$tpHM)
}
}
FHEM im Proxmox Container

Ascos

Zitat von: Mitch am 09 Februar 2015, 08:27:08
Aber wozu?
Ich will ja auch, dass die Heizung geschalten wird, wenn niemand Zuhause ist.

z.B. am Freitag kommt erst jemand ab 14 Uhr nach Huase, die Heizung soll aber schon ab 12 Uhr angehen, damit es dann warm ist.
Wenn ich das von der Anwesenheit abhängig mache, würde ja nicht geschalten werden.

BTW: Wenn Du dann "zurück" schalten willst, einfach die Temoeraturen neu einlesen.
Heating_Control_SetAllTemps()

Hey,

sorry, das ich erst heute antworte, war die letzten 3 Tage nur noch arbeiten.
Du hast natürlich Recht. Allerdings ist es bei mir so, das ich sehr unregelmäßige Arbeitszeiten habe. Somit habe ich meinen Heizplan so gestaltet, das die Wunschtemperaturen da drin sind, die ich gern hätte, wenn ich zu Hause bin.
Wenn ich nun aber arbeiten bin, muss ja nicht so hoch geheizt werden. Manchmal bin ich dann schon am Nachmittag zu Hause, manchmal komme ich erst nachts zurück. In diesem Fall muss ja nicht den ganzen Nachmittag geheizt werden, wenn ich eh nicht da bin.
Aber das ist halt ein spezieller Fall von mir, der sicherlich nicht so die Regel ist. Auf jeden Fall funktioniert es bisher so einwandfrei, das ich den Heizplan nur aufrufe, wenn ich auch zu Hause bin und ansonsten die Temperaturen absenke.

Zudem möchte ich hier nur noch kurz teilen, wie ich es gelöst habe, das die Absenkung nicht aktiviert wird, wenn ich das Heizprogramm ab abgeschaltet habe.
Ich habe in dem notify, welches die Heizungsautomatik ausschaltet noch einen Codeschnipsel hinzugefügt:
fhem("setstate ECOMode triggered");

Damit setze ich den Watchdog auf triggered und er ist somit inaktiv, solange das Heizprogramm aus ist.
Ebenso setze ich ihn wieder auf "defined", wenn ich es aktiviere.

@ Mitch:
Auf jeden Fall vielen Dank für deine Hilfe.

VG
Ascos
1x RaspberryPi 3, HMUART, HMLAN
4x HM-CC-RT-DN, 4x HM-Sec-SCo, 4x HM-TC-IT-WM-W-EU, 1 Jeelink, 4 Lacrosse Fühler, 2 LD382A
1x ZBox mit Kodibuntu, mehrere schaltbare Steckdosen

Mitch

Zitat von: Ascos am 12 Februar 2015, 13:08:53
Zudem möchte ich hier nur noch kurz teilen, wie ich es gelöst habe, das die Absenkung nicht aktiviert wird, wenn ich das Heizprogramm ab abgeschaltet habe.
Ich habe in dem notify, welches die Heizungsautomatik ausschaltet noch einen Codeschnipsel hinzugefügt:
fhem("setstate ECOMode triggered");

Damit setze ich den Watchdog auf triggered und er ist somit inaktiv, solange das Heizprogramm aus ist.
Ebenso setze ich ihn wieder auf "defined", wenn ich es aktiviere.

@ Mitch:
Auf jeden Fall vielen Dank für deine Hilfe.

VG
Ascos

Dafür kannst Du wunderbar den Code aus meiner my_Utils nutzen, den habe ich auch nochmal umbegaut:

sub ecomode {
my @FHT=devspec2array("TYPE=FHT");
foreach(@FHT)
{
  my $tp = ReadingsVal("$_", "desired-temp", "")-2;
  if (ReadingsVal("$_", "desired-temp", "") > "16") {
   fhem("set $_ desired-temp ".$tp)
  }
}
}

sub ecomodeHM {
my @HM_HT=devspec2array("HZ_.*._Clima");
foreach(@HM_HT)
{
  my $tpHM = ReadingsVal("$_", "desired-temp", "")-2;
  if (ReadingsVal("$_", "desired-temp", "") > "16") {
   fhem("set $_ desired-temp ".$tpHM)
  }
}
}


Sobald aufgrund manuel oder Abwesenheit der ECOmode aktiviert wird, wird geschaut, ob schon die Absenktemperatur (bei mir 16 Grad) eingestellt ist. Wenn nicht, wird alles um 2 Grad gesenkt.
Bei Rückkehr, oder deaktivierung wird wieder alles auf Heizplan gebracht.

Du kannst den Code dann noch soweit nötig an Deine Gegebenheiten anpassen.
FHEM im Proxmox Container

Mitch

Nachdem ich gerade Stück für Stück von FHT nach HM migriere, haben sich da auch ein paar "Herausforderungen" ergeben, die ein Anpassung erfordern.

Gerade das Fensterthema hat mich etwas "genervt", da fhem beim setzten der Temeratur das Thermostat übersteuert.
Somit kann es z.B. vorkommen, dass ein Fenster noch offen ist, wenn fhem eine neue Temperatur schickt und die Heizung hoch heizt, obwohl das fenster noch offen ist.

Um das zu umgehen, habe ich eine einfach Abfrage eingebaut:
define Fenster.Status.Bad DOIF ([Fenster_Bad] eq "open") (set HCB disbale) DOELSE (set HCB enable)

Wobei HCB die Steuerung von Bad über das HCS Modul ist.

Was passiert? Wenn das Fenster aufgeht, wird das HCS Modul für den entsprechenden Raum deaktiviert und die winOpnTemp bleibt eingestellt.
Sobald das Fenster zu gemacht wird, wird HCS wieder aktiviert und die zu dieser zeit gültige Temperatur eingestellt.
FHEM im Proxmox Container

Ascos

Zitat von: Mitch am 16 Februar 2015, 12:36:08
Nachdem ich gerade Stück für Stück von FHT nach HM migriere, haben sich da auch ein paar "Herausforderungen" ergeben, die ein Anpassung erfordern.

Gerade das Fensterthema hat mich etwas "genervt", da fhem beim setzten der Temeratur das Thermostat übersteuert.
Somit kann es z.B. vorkommen, dass ein Fenster noch offen ist, wenn fhem eine neue Temperatur schickt und die Heizung hoch heizt, obwohl das fenster noch offen ist.

Um das zu umgehen, habe ich eine einfach Abfrage eingebaut:
define Fenster.Status.Bad DOIF ([Fenster_Bad] eq "open") (set HCB disbale) DOELSE (set HCB enable)

Wobei HCB die Steuerung von Bad über das HCS Modul ist.

Was passiert? Wenn das Fenster aufgeht, wird das HCS Modul für den entsprechenden Raum deaktiviert und die winOpnTemp bleibt eingestellt.
Sobald das Fenster zu gemacht wird, wird HCS wieder aktiviert und die zu dieser zeit gültige Temperatur eingestellt.

Super Sache, da hab ich mir letztes Wochenende auch die Zähne ausgebissen. Vielen Dank
1x RaspberryPi 3, HMUART, HMLAN
4x HM-CC-RT-DN, 4x HM-Sec-SCo, 4x HM-TC-IT-WM-W-EU, 1 Jeelink, 4 Lacrosse Fühler, 2 LD382A
1x ZBox mit Kodibuntu, mehrere schaltbare Steckdosen

Ascos

Hey,

ich habe heute versucht deine DOIF beim Übersteuern der Fenster einzubauen.
Leider wird weiterhin mein Thermostat überschrieben.

Im Log wird es richtig protokolliert:
2015.02.22 19:11:58 3: [HCWZ] set HCWZ disbale
2015.02.22 19:13:00 3: CUL_HM set WZ.Wandthermostat_Climate desired-temp 19.0
2015.02.22 19:13:30 3: [HCWZ] set HCWZ enable


In meiner DEF des DOIF hab ich es auch so übernommen, wie bei dir:
([WZ.Fenster] eq "open") (set HCWZ disbale) DOELSE (set HCWZ enable)

Wenn ich in die Readings der Herting Control gucke, wird disable nicht auf 1 gesetzt. Es aktualisiert sich nichts, erst wenn ich das Fenster wieder schließe, wird disable auf 0 gesetzt, wobei es ja schon so stand, somit wird der Status da nur überschrieben.

Hast du einen Tip, was ich falsch gemacht habe?

VG
Ascos
1x RaspberryPi 3, HMUART, HMLAN
4x HM-CC-RT-DN, 4x HM-Sec-SCo, 4x HM-TC-IT-WM-W-EU, 1 Jeelink, 4 Lacrosse Fühler, 2 LD382A
1x ZBox mit Kodibuntu, mehrere schaltbare Steckdosen

Mitch

Du hast auch meinen Rechtschreibfehler übernommen ;-)

Es heisst: disable im DOIF
FHEM im Proxmox Container

Ascos

Zitat von: Mitch am 22 Februar 2015, 19:35:16
Du hast auch meinen Rechtschreibfehler übernommen ;-)

Es heisst: disable im DOIF

Hihi, manchmal ist es so einfach.
Das Abschalten geht nun, es wird nichts überschrieben. Allerdings wird nun nach dem Fenster schließen nicht mehr die neue Temperatur eingestellt, sondern die Alte wieder aufgerufen, auch wenn in der Heating Control nun die neue steht. Ich müsste so etwas, wie ein Update machen. So etwas, wie "Heating_Control_SetAllTemps()", nur jetzt für nur einen Heizplan.
1x RaspberryPi 3, HMUART, HMLAN
4x HM-CC-RT-DN, 4x HM-Sec-SCo, 4x HM-TC-IT-WM-W-EU, 1 Jeelink, 4 Lacrosse Fühler, 2 LD382A
1x ZBox mit Kodibuntu, mehrere schaltbare Steckdosen

Mitch

Hm, bin mir jetzt nichts sicher, ob dies bei mir funktioniert.
Muss ich heute Abend mal testen, aber eigentlich sollte bei einem Enable der zu dieser Zeit richtige Wert wieder eingestellt werden.

Ansonsten kannst Du ja einfach nach dem Enable ein Heating_Control_SetAllTemps() machen.
Werden dann halt alle Temps neu eingelesen.
FHEM im Proxmox Container

Ascos

Hey Mitch,

hast du es zufällig getestet?
Ich bin leider eben erst wieder nach Hause gekommen, habe aber mal kurz probiert, ob Heating_Control_SetAllTemps() auch für Heizprogramme mit disable gillt. Das tut es nicht, die werden also nicht beachtet.
Das ist gut, hatte nämlich bedenken, das ich somit Thermostate aus anderen Räumen überschreibe, wo das Fenster womöglich noch geöffnet ist.
Hieße das für den Code der DOIFs dann einfach Folgendes?

DOIF ([WZ.Fenster] eq "open") (set HCWZ disable) DOELSE (set HCWZ enable, Heating_Control_SetAllTemps())
1x RaspberryPi 3, HMUART, HMLAN
4x HM-CC-RT-DN, 4x HM-Sec-SCo, 4x HM-TC-IT-WM-W-EU, 1 Jeelink, 4 Lacrosse Fühler, 2 LD382A
1x ZBox mit Kodibuntu, mehrere schaltbare Steckdosen