Hallo zusammen!
Ich habe eine Verständnisfrage.
Gemäß der commandref DOIF zur Nachbildung eines on-for-timers möchte ich versuchen, dies analog für die Steuerung eines E-Heizkörpers über ein Wandthermostaten umzusetzen.
Im Moment stehe ich aber auf dem Schlauch bzw. verstehe nicht ganz das "Schaltverhalten" meines DOIFs.
Ausgangssituation:
- HM-TC-IT-WM-W-EU (zur Temperaturabfrage)
- HM-LC-SW1-FM (zum Ein-/Ausschalten des Heizkörpers)
Ziel:
Wochentags soll der Heizkörper zwischen 05:00 und 06:30 laufen, wenn die Ist-Temperatur kleiner als die Soll-Temperatur ist. In diesem Zeitfenster soll der Heizkörper dann auch wieder ausgehen, wenn die Solltemperatur erreicht ist und auch wieder angehen, falls die Ist-Temperatur wieder unter die Soll-Temperatur fällt.
Das Gleiche am Wochenende zwischen 07:00 und 08:30.
Ich nutze dazu den Kanal 02 (XXX_Climate) des Thormostaten mit der Bezeichnung bz_202_klima, da dieser etwa alle 2-3 Minuten die Ist-Temperatur aktualisiert.
Hier mein code für das DOIF:
([?05:00-06:30|8] or [?07:00-08:30|7]
and [bz_202_klima:measured-temp] < [bz_202_klima:desired-temp])
(set bz_202_heizung on)
(set bz_202_heizung off)
Die gesetzten Attribute:
do resetwait
wait 0,240
Nun war es so, dass der Heizkörper heute Morgen von 05:00 bis 06:30 kontinuierlich durchlief, obwohl zwischenzeitlich die Soll-Temperatur bereits erreicht wurde. Als der Heizkörper um 06:30 ausging, lag die Ist-Temperatur ca. 1 °C über der Soll-Temperatur...
Kann mich mal jemand in die richtige Richtung schubsen oder mir einen Tipp geben, wie ich das richtigerweise umsetzen kann?
Oder wird bei diesem DOIF auch nur zur Anfangs- und Endzeit getriggert?
Wie kann ich das dann mit dem Zeitintervall lösen?
In einem Test ohne Zeitangaben funktionierte die "Schaltung" einwandfrei...
Bin für jede Hilfe dankbar!
Gruß
Andreas
Hmm, gerade nochmal aktuell mit angepasster Zeit getestet (12:00 - 13:00 Uhr)...
Desired-temp steht auf 20.0 .
Die Heizung schaltet beim Erreichen der Soll-Temperatur wieder nicht ab und der Timer wird "weitergeschoben"...
Ein kleiner Auszug vom EventMonitor:
2016-02-02 12:35:33 DOIF di_bad_heizung_an wait_timer: no timer
2016-02-02 12:35:33 DOIF di_bad_heizung_an wait_timer: 02.02.2016 12:39:33 cmd_1_2 bz_202_klima
2016-02-02 12:35:33 CUL_HM bz_202_klima measured-temp: 20.1
2016-02-02 12:37:34 DOIF di_bad_heizung_an wait_timer: no timer
2016-02-02 12:37:34 DOIF di_bad_heizung_an wait_timer: 02.02.2016 12:41:34 cmd_1_2 bz_202_klima
2016-02-02 12:37:34 CUL_HM bz_202_klima measured-temp: 20.2
2016-02-02 12:37:34 CUL_HM bz_202_klima T: 20.2 desired: 20.0
2016-02-02 12:37:44 DOIF di_bad_heizung_an wait_timer: no timer
2016-02-02 12:37:44 DOIF di_bad_heizung_an wait_timer: 02.02.2016 12:41:44 cmd_1_2 bz_202_klima
2016-02-02 12:37:44 CUL_HM bz_202_klima measured-temp: 20.2
2016-02-02 12:37:44 CUL_HM bz_202_thermostat battery: ok
2016-02-02 12:37:44 CUL_HM bz_202_thermostat batteryLevel: 3.1
2016-02-02 12:37:44 CUL_HM bz_202_thermostat desired-temp: 20.0
2016-02-02 12:37:44 CUL_HM bz_202_thermostat measured-temp: 20.2
Gruß
Andreas
Wenn die Heizung auch ausgehen soll, dann brauchst du auch einen DOELSE-Fall mit off. Ich verstehe aber nicht warum du einen on-for-timer hier nachbilden willst. Es sollte damit funktionieren (die beiden Zeitintervalle müssen geklammert sein):
(([?05:00-06:30|8] or [?07:00-08:30|7])
and [bz_202_klima:measured-temp] < [bz_202_klima:desired-temp])
(set bz_202_heizung on)
DOELSE
(set bz_202_heizung off)
ohne die beiden Attribute.
Gruß
Damian
Ich verstehe nicht, warum man solche Sachen überhaupt FHEM überlässt. Wenn es sich nur um HM Komponenten handelt, macht ein direktes Peering und die entsprechenden Einstellungen deutlich mehr Sinn und es funktioniert auch noch, wenn FHEM mal nicht läuft.
Hallo Damian und marvin78,
danke für eure Antworten.
@Damian
Tja, wahrscheinlich habe ich einfach zu kompliziert gedacht, keine Ahnung. On-for-timer hatte ich gemäß commandref schon erfolgreich mit einem Bewegungsmelder umgesetzt, und da dachte ich mir, versuch es mal bei der Heizung genauso...
Werde deinen Vorschlag heute Abend mal testen.
@marvin78
Aus zwei Gründen...
1. je mehr man probiert, umso mehr lernt man auch...
2. Mit dem Peering hab ich mich noch überhaupt nicht beschäftigt bzw. noch nicht herangetraut...
Gruß
Andreas
Zitat von: Vize am 02 Februar 2016, 14:18:32
2. Mit dem Peering hab ich mich noch überhaupt nicht beschäftigt bzw. noch nicht herangetraut...
Das solltest du aber in dem Fall tun, denn das ist die einzige sinnvolle Möglichkeit, so etwas abzubilden. FHEM sollte bei Heizungsteuerung und anderen wichtigen Dingen eher eine administrative und Überwachungsfunktion einnehmen.
OK, ich denke, ich werd mich mal mit dem Thema Peering befassen...
Danke nochmal für deine Hinweise.
PS Eine Detailfrage noch, die mir gerade einfällt...wenn ich die Steuerung des E-Heizkörpers per Peering umsetze, dann kann ich die Heizprogramme doch "nur noch" direkt am Thermostat beeinflussen/einstellen und nicht mehr über FHEM, oder?
Es wird nämlich wohl so sein, dass ich nicht jeden Tag zur programmierten Zeit heizen werde. Und da finde ich es (bis jetzt) einfacher, dafür z.B. ein DOIF in FHEM übers Smartphone ein- und auszuschalten, als immer ins Bad zu gehen, um die Soll-Temperatur runter zu regeln.
Korrekt oder DEnkfehler meinerseits?
So, jetzt nerv ich auch erstmal nicht mehr...
Gruß
Andreas
Denkfehler. Beschäftige dich damit. FHEM kann natürlich immer (auch) steuern.
Zitat von: Vize am 02 Februar 2016, 14:44:44
...wenn ich die Steuerung des E-Heizkörpers per Peering umsetze, dann kann ich die Heizprogramme doch "nur noch" direkt am Thermostat beeinflussen/einstellen und nicht mehr über FHEM, oder?
Es wird nämlich wohl so sein, dass ich nicht jeden Tag zur programmierten Zeit heizen werde. Und da finde ich es (bis jetzt) einfacher, dafür z.B. ein DOIF in FHEM übers Smartphone ein- und auszuschalten, als immer ins Bad zu gehen, um die Soll-Temperatur runter zu regeln.
Eine ähnliche Problematik hatte ich bei mir auch. Die von mir gesteuerte E-Heizung (Nachtspeicher) steht in einer Ferienwohnung und soll natürlich nur dann aktiv geregelt sein, wenn entweder jemand anwesend ist oder eben vorgeheizt werden soll. Ich habe mich nach langem Überlegen zum direkten Peering von Thermostat und Lüfter des Speicherofens entschieden. Das läuft dann wirklich zu 99,9% ohne Mucken. Wenn keiner anwesend ist/ nicht vorgeheizt wird, dann setz ich desired-temp einfach auf 5 und schon bleibt der Lüfter stumm.
Zudem gibt es noch einen separaten Heizlüfter, der bei Bedarf (A-Temp < -12°) aushelfen soll und ebenfalls über den Thermostaten geregelt werden soll.
Den Zusatzlüfter hab ich dann ganz simpel per THRESHOLD gelöst, welcher mit einem dummy manuell de-/aktiviert wird.
Die Temperaturprogramme habe ich in eine separate Datei tempList.cfg eingetragen. Damit kann man die recht leicht in FHEM editieren und dann per set [Device] tempListTmpl [Name] ganz einfach auf das Thermostat "aufspielen". Steht aber sicher alles im Wiki.
Meine Empfehlung:
1. HM Sensor mit HM-Aktor direkt peeren (geht allerdings nicht in jeder Konstellation - ist meine leidvolle Erfahrung)
2. Entweder Temperaturprogramme jeweils über listen laden oder weil es meiner Meinung nach komfortabler ist z. B. per DOIF Wochenprogramme mit Setzen der Desire-Temp definieren.
3. Durch einfaches Setzen der Desired-Temp kann man jederzeit eine aktuelle Vorgabe bis zum nächsten Zeitpunkt übersteuern.
Gruß
Damian
Hallo tomster,
hallo Damian,
danke euch für die weiteren Hinweise.
Ich werde mich mal näher mit der Thematik befassen.
Gruß
Andreas
Zitat von: Damian am 02 Februar 2016, 13:08:15
Wenn die Heizung auch ausgehen soll, dann brauchst du auch einen DOELSE-Fall mit off.
(([?05:00-06:30|8] or [?07:00-08:30|7])
and [bz_202_klima:measured-temp] < [bz_202_klima:desired-temp])
(set bz_202_heizung on)
DOELSE
(set bz_202_heizung off)
Hallo Damian,
ich hab gerade mal probeweise diese von dir vorgeschlagene Variante getestet.
Für bz_202_klima measured-temp hatte ich noch das Attribut event-on-update-reading gesetzt.
Wenn ich den EventMonitor verfolge, sehe ich nun alle 2-3 Minuten den set on Befehl für die Heizung, welcher an den HM-CFG-USB kommuniziert wird.
Durch meine on-for-timer-Nachbildung wollte ich das - wie in der commandref beschrieben - vermeiden...so dachte ich jedenfalls...
Gruß
Andreas
Zitat von: Vize am 02 Februar 2016, 18:16:57
Hallo Damian,
ich hab gerade mal probeweise diese von dir vorgeschlagene Variante getestet.
Für bz_202_klima measured-temp hatte ich noch das Attribut event-on-update-reading gesetzt.
Wenn ich den EventMonitor verfolge, sehe ich nun alle 2-3 Minuten den set on Befehl für die Heizung, welcher an den HM-CFG-USB kommuniziert wird.
Durch meine on-for-timer-Nachbildung wollte ich das - wie in der commandref beschrieben - vermeiden...so dachte ich jedenfalls...
Gruß
Andreas
Dann hast du wohl nicht beide Attribute, wie ich geschrieben habe, gelöscht.
Das do-Attribut sollte nicht gesetzt sein.
Schande über mich...du hast Recht...hatte ich vergessen zu löschen...Sorry!
Gruß
Andreas
Guten Morgen,
ich habe mir nun in diesem Zusammenhang erstmal ein Test-DOIF gebastelt, um Morgens in einem Zeitfenster den E-Heizkörper temperaturgesteuert ein- und auszuschalten.
(([05:00-07:00|8] or [06:30-08:30|7])
and [bz_202_klima:measured-temp] < ([bz_202_klima:desired-temp]-1))
(set bz_202_heizung on)
DOELSEIF ([bz_202_klima:measured-temp] >= [bz_202_klima:desired-temp])
(set bz_202_heizung off)
DOELSE
()
Das Ergebnis war, dass der Heizkörper heute Morgen bei Erreichen der Solltemperatur (desired-temp) zwar abschaltete, jedoch erst außerhalb des Zeitfensters um 07:17 Uhr.
Wie kann ich hier erreichen, dass der Heizkörper unter der Woche spätestens um 07:00 Uhr abschaltet, auch wenn die Soll-Temperatur noch nicht erreicht ist? Die weitere Abschaltung bei Erreichen der Soll-Temperatur innerhalb des Zeitfenster soll dabei erhalten bleiben.
Muss ich die Zeitangaben dafür auch in den DOELSEIF-Fall packen und/oder noch ein set bz_202_heizung in den DOELSE-Fall?
Ich krieg es irgendwie nicht logisch zu Ende gedacht...
Ich würde gerne erstmal versuchen, das in einem solchen DOIF-Konstrukt zu realisieren.
Die von Damian vorgeschlagene Variante mit den Temperaturprogrammen würde ich danach mal testen...
Danke schonmal!
Gruß
Andreas
Die Zeitangaben gehören auch in den DOELSEIF-Fall. Du musst das so verstehen, dass jedes "Pärchen" von IF->THEN's separat für sich steht. Es werden keine Bedingungen "vererbt". DOIF arbeitet die Angaben der Reihe nach ab, und springt zum nächsten "Pärchen" wenn die Bedigungen nicht zutreffen.
In Deinem Beispiel wird die Heizung in dem angegebenen Zeitfenster UND nach dem Verhältnis SOL<->IST Temperatur zwar angeschaltet. Das Abschalten erfolgt aber nur in Abhängigkeit des Verhältnisses der Temperatur von SOLL<->IST; also ohne Zeitangabe. Wird die Beduingung erst z.B. nach 07:00 Uhr erreicht, schaltet sie auch erst dann ab. Allerdings nicht mehr an, bis zum nächsten Zeitfenster.
Zudem könnte es aber auch sein sein, dass die Soll-Temperatur innerhalb des Zeitfensters gar nicht erreicht wird. Um die Heizung dann aber ausserhalb der Zeitfenster sicher abzuschalten brauchst Du noch einen DOELSE-Fall. Probier Mal:
(([05:00-07:00|8] or [06:30-08:30|7])
and [bz_202_klima:measured-temp] < ([bz_202_klima:desired-temp]-1))
(set bz_202_heizung on)
DOELSEIF (([05:00-07:00|8] or [06:30-08:30|7]) and [bz_202_klima:measured-temp] >= [bz_202_klima:desired-temp])
(set bz_202_heizung off)
DOELSE
(set bz_202_heizung off)
Hallo tomster,
danke dir für die Ausführungen und Erläuterungen...letztendlich ist es ja schon logisch, aber das Brett vorm Kopf manchmal zu hart...
Ich werd das heute Abend mal testen.
Dankeschön!
Gruß
Andreas
Och, noch keine Vorschuß-Lorbeeren, bitte.
Ich wurschtel mich auch erst grad so ein bissl in das Thema hinein und habe das einfach Mal so hingeschrieben, wie ich DOIF verstanden habe.
Und wenn ich ganz ehrlich bin - Damian liest ja eh mit hier - bekomme ich im "schlimmsten" Fall eine Privatlehrer-Stunde zum Thema DOIF von ihm ;-)
Ich meld mich, wenn es nicht klappt... 8) ;D
Gruß
Andreas
Guten Abend,
so, ich hab dann mal den Thermostaten HM-TC-IT-WM-W-EU (bz_202_thermostat) mit dem HM-LC-SW1-FM (bz_202_heizung) gepeert.
Dazu noch eine Verständnisfrage:
Gepeert wird ja mit dem Kanal 07, den ich in bz_202_thermostat_switch umbenannt habe.
In den Internals des HM-LC-SW1-FM taucht nun folgendes unter peerList auf:
bz_202_thermostat_switch,bz_202_thermostat_chn:08
Ebenso in den Attributen unter peerIDs
00000000,24EE2107,24EE2108
Ist das korrekt so?
Ich frage deshalb, weil ich zunächst nur set bz_202_thermostat_switch peerChan 0 bz_202_heizung abgesetzt habe...das single set hatte ich dabei - warum auch immer - vergessen....
Danach hab ich den Befehl dann nochmal inkl. single set abgesetzt.
Funktionieren tut es auf jeden Fall so wie es soll. Der HM-LC-SW1-FM schaltet brav, wenn man die Soll-Temperatur am Thermostaten ändert.
Die leichte Verzögerung des Schaltvorganges (einige Sekunden) ist dabei in Ordnung, oder?
Danke nochmals!
Gruß
Andreas
Zitat von: Vize am 06 Februar 2016, 20:52:26
so, ich hab dann mal den Thermostaten HM-TC-IT-WM-W-EU (bz_202_thermostat) mit dem HM-LC-SW1-FM (bz_202_heizung) gepeert.
Dazu noch eine Verständnisfrage:
Gepeert wird ja mit dem Kanal 07, den ich in bz_202_thermostat_switch umbenannt habe.
In den Internals des HM-LC-SW1-FM taucht nun folgendes unter peerList auf:
bz_202_thermostat_switch,bz_202_thermostat_chn:08
Ebenso in den Attributen unter peerIDs
00000000,24EE2107,24EE2108
Ist das korrekt so?
Ich frage deshalb, weil ich zunächst nur set bz_202_thermostat_switch peerChan 0 bz_202_heizung abgesetzt habe...das single set hatte ich dabei - warum auch immer - vergessen....
Danach hab ich den Befehl dann nochmal inkl. single set abgesetzt.
Funktionieren tut es auf jeden Fall so wie es soll.
Guten Morgen,
ich möchte hier nochmal kurz anknüpfen.
Ich habe nun einen weiteren Thermostaten mit einem Zwischenstecker (HM-LC-Sw1-Pl-DN-R1) gepeert.
Dort tauch nun in den Internals und den Attributen "nur" folgendes auf
peerList bu_214_thermostat_switch
peerIDs 00000000,3C764007 Hier habe ich nicht den o.g. Fehler gemacht und den peer-Befehl sofort mit
single set abgesetzt.
Kann und/oder sollte ich daher nun bei dem o.g. Switch (HM-LC-SW1-FM ) das
bz_202_thermostat_chn:08 und
24EE2108 wieder entfernen?
Wenn ja, wie?
Das peereing komplett aufheben und nochmal neu peeren, oder was wäre zu tun?
Wie gesagt, der switch funktioniert ja, ist daher eher ne Verständnisfrage bzw. eine "Lernfrage"...
Danke schonmal für eure Hilfe!
Gruß
Andreas
ich würde solche "falschen" einträge entfernen.
normalerweise entpeerst du zb mit
set bz_202_thermostat_switch peerBulk 24EE2108 unset
anschliessend, wie immer mit getconf prüfen.
wahrscheinlich wird es nicht funktionieren, da sich der tc wohl ziehmlich zickig beim entpeeren verhält. dann hilft nur ein werksreset. danach natürlich wieder peeren und konfigurieren des tc.
Hallo frank,
danke für deine Hinweise.
Kann ich hier auch
set bz_202_thermostat_switch peerChan 0 bz_202_heizung single unset
nutzen, um das peering zu lösen, bzw. wo wäre der Unterschied zu deinem Vorschlag mit peerBulk?
Aus dem Wiki diesbezüglich werde ich ehrlich gesagt nicht ganz schlau...
Gruß
Andreas
mit deinem vorschlag wirst du wohl nur das "normale" peering auf beiden seiten entfernen können.
peerchan ist für normales/userfreundliches peeren/entpeeren mit device-paaren (sensor und aktor) gemacht.
peerbulk ist eher für direktes setzen auch mehrerer peers eines devices gemacht. ein komplettes peering besteht aber immer aus 2 devices.
Hallo frank,
danke nochmal für deine Ausführungen...aber komplett hab ich es immer noch nicht verstanden...sorry :-[
Was genau meinst du mit "normalem" peering?
Egal, ich werd es heute - oder morgen - Abend mal testen...
Gruß
Andreas