Neues Modul - Heating_Control, WeekdayTimer

[stromer-12]

Die FHTs bieten nur eine Heiz- und eine Absenktemperatur für den gesamten Tag.

[Michael N.]

Hallo,

Was ist die eigentliche Intention die gesamte Steuerung der Schaltzeitpunkte (incl. Wochenplan) der einzelnen Temperaturreglern (FHTs) durch die Zentrale (sprich Fhem) zu machen, wo doch die einzelnen FHTs Wochenschaltpläne mit bis zu zwei Tageszeitperioden pro Tag erlauben und somit autark die Regelung für die einzelnen Räume vornehmen können?

Persönlich bin ich von dem Heating_Control-Modul begeistert, weil es für meine MAX! Ventile in FHEM keine Möglichkeit gibt, Wochenpläne zu erstellen, die auf das Ventil übertragen werden. (Wenn es das für FHTs gibt, habe ich es in FHEM nicht gefunden.) Natürlich hätten "autonome" Wochenpläne auch etwas (werden grundsätzlich auch von MAX! unterstützt).

Unabhängig davon sehe ich aber einen Vorteil von Heating_Control darin, in den Plänen Bedingungen unterzubringen. Ich benutzte das zwar nicht in allen Räumen, aber in einigen ist es ganz sinnvoll in den Schulferien anders zu regeln.

Gruß

    Michael

[Gunther]

Könnte daran liegen, dass du nicht die neueste Version hast. Update ausfuhren und alles ist gut.

Danke für Deine Hilfe, Dietmar!
Das Update habe ich durchgeführt. Nun kann ich auch Mo-Fr nutzen.

Ich möchte nun in Abhängigkeit von genau einem Status die Temperaturen setzen, bekomme aber bei folgendem Coding:

Code Auswählen Erweitern

define eg_bz_Heizung_Heizungsplan_weg Heating_Control eg_bz_Heizung Mo-So|08:30|16 Mo-So|16:30|20 Mo-So|22:00|16 (ReadingsVal ("HomeStatus", "state", 1) = 3)
attr eg_bz_Heizung_Heizungsplan_weg room Badezimmer


diese Fehlermeldung:
2013.04.01 22:42:11 3: Can't modify non-lvalue subroutine call in scalar assignment at (eval 376) line 1, near "3)"

Hast Du dazu eine Idee.

Eine weitere Frage: Ich bekomme leider manchmal ein volles Log mit 20-30 folgender Meldungen:
2013.04.01 22:39:50 2: CUL_0: unknown message LOVF
2013.04.01 22:39:51 2: CUL_0: unknown message LOVF
2013.04.01 22:39:51 2: CUL_0: unknown message LOVF
2013.04.01 22:39:51 2: CUL_0: unknown message LOVF
...
...

Nachdem ich FHEM neu starte, den Cul resette oder etwas anderes (?) mache, setzt mir irgendwas im Log verschiedene FHTs:
2013.04.01 22:53:44 2: FHT set eg_bz_Heizung desired-temp 18.0
2013.04.01 22:53:44 2: FHT set eg_az_Heizung desired-temp 15.0
2013.04.01 22:53:45 2: FHT set eg_ku_Heizung desired-temp 19.0
2013.04.01 22:53:45 2: FHT set eg_ki_Heizung desired-temp 15.0
2013.04.01 22:53:45 2: FHT set og_sz_Heizung desired-temp 15.0

Warum passiert das? Können dadurch die Funktprobleme und die LOVF-Meldungen auftreten?

[Dietmar63]

Code Auswählen Erweitern

define eg_bz_Heizung_Heizungsplan_weg Heating_Control eg_bz_Heizung Mo-So|08:30|16 Mo-So|16:30|20 Mo-So|22:00|16 (ReadingsVal ("HomeStatus", "state", 1) == 3)
attr eg_bz_Heizung_Heizungsplan_weg room Badezimmer

Kleiner Fehler bei =. Verwende ==

LOVF bekommst du wenn du zu viele Kommandos in fhem versendet. Ein Google und du bekommst viele Tipps dazu .

Beim Start jedes HC wird die Temperatur auf den passenden aktuellen Wert gesetzt

[LudgerR]

Hallo Dietmar,

warum nicht die Anzahl der Parameter von 1 (desired-temp)  auf (zumindest) 2 erweitern ?

Damit würde aus deinem ursprünglichen Heating-Control Modul ein ziemlich flexibles  ,,Wochenschaltplan" Modul, das auch für andere Zwecke verwendet werden könnte.

In meinem Fall  als intensiver Nutzer der Party/Urlaubs Funktion der FHT Geräte könnte ich die Funktion


{fht_party("<FHT-dev-name>","<Zeit-Interval>","<desired-temp>")}

 
 als Komando  

{fht_party("@","$","%")}
 
in Heating-Control  spezifizieren, vorausgesetzt ein zusätzlicher (optionaler) Parameter (zu desired-temp) ließe sich vorgeben und würde im command ausgewertet.

 Anstelle von  

define HCW1  Heating_Control heizung.01     15:00|19.1 Mo-Fr|17:30|21

sehe die Defintion möglicherweise so

define HCW1  Heating_Control heizung.01     15:00|19.1_120 Mo-Fr|17:30|21_300

bzw. folgendermaßen aus

define HCW1  Heating_Control heizung.01     15:00|19.1:120 Mo-Fr|17:30|21:300

Gruß,

Ludger

[LudgerR]

In meinem Haushalt spielen feste Wochenschaltpläne nur eine untergeordnete Rolle, feste Ferienzeiten mit planbarer Anwesenheit von Familienmitgliedern gibt es nicht. Das kurzeitige Aufheizen von Räumen auf Komfort-Temperatur außerhalb der Regelzeiten steht im Vordergrund.
Ich finde  es halt praktisch,  wenn der Sohnemann sein Studierzimmer per Fernbedienung (oder Smartphone) in einen oder mehrstündigen Partymodus setzen kann und spätestens beim Verlassen des Hauses durch kurze Betätigung der FUNKTION sTaste auf dem FHT Gerät bequem wieder in den Absenkmodus wechseln kann.

Abgesehen von wenigen Ausnahmen, wo ich mehr als zwei Komforttemperaturintervalle benötige, hinterlege ich keine Schaltzeiten für FHT Geräte in Fhem.  Ich habe auch kein Problem damit bei umfangreichen Änderung des Schaltprogrammes dies am FHT Gerät selbst zu tun. Die Schaltzeiten der einzelnen FHTs sehe ich ja in den Readings bzw. im zugehörigen Plot der Geräte, wenn ich ,,desired-temp" zusätzlich zu ,,measured-temp" und Actuator % auswerte.

Der Ansatz komplette Wochenschaltprogramme für alle FHT Geräte kompakt zentral in Fhem zu haben und flexibel zu verwalten ist halt sehr verführerisch. Bei einer großen Anzahl von FHT Geräten stößt man jedoch schnell an die (Funk-) Grenzen.

Mir ging es primär darum aufzuzeigen (um anderen leidvolle Erfahrungen zu ersparen), dass man mit den Grundfunktionen der FHT Geräte einiges flexibel realisieren kann und man nicht für jedes FHT Gerät die Steuerung
komplett über die  Zentrale (Fhem) realisieren muss.    

Gruß,
Ludger

[Dietmar63]

Ich habe im Moment nur zwei FHT im Einsatz.
Mehr ist bei mir im Moment auch nicht geplant, da ich noch Standalone-thermostate habe, die auch ganz gut funktionieren.

Der Ansatz komplette Wochenschaltprogramme für alle FHT Geräte kompakt zentral in Fhem zu haben und flexibel zu verwalten ist halt sehr verführerisch. Bei einer großen Anzahl von FHT Geräten stößt man jedoch schnell an die (Funk-) Grenzen.

Warum sollte das so sein? Pro FHT wird vielleict 6-10 mal am Tag geschaltet. In Räumen, in denen nicht viele verschiedene Schaltzeiten notwendig sind entsprechend seltener. Bisher habe ich noch kein Problem mit den (Funk-) Grenzen gehabt - habe aber auch nur zwei FHT an der Zentrale angeschlossen.

Praktisch ist es jedenfalls in der Lage zu sein aus der Ferne die Heizung einschalten zu können.

[Dietmar63]

@Ludger:
Dieser Wunsch ist heute schon realisert. Der Parameter hinter der Zeit ist einfach nur Text, der anstelle von % weitergegeben wird:

Versuch mal folgendes:

Code Auswählen Erweitern

define HCW1 Heating_Control heizung.01 15:00|19.1:120 Mo-Fr|17:30|21:300 {fht_party("@","%")}

Als zweiten Parameter bekommst Du dann in fht_party 19.1:120 bzw. 21:300 geliefert.
Du musst den Parameter nur selbst auseinander nehmen und verwerten.  

[LudgerR]

Hallo Dietmar,

wenn die Schaltbefehle für die einzelnen FHT Geräte insgesamt schön über die Zeitachse verteilt sind, funktioniert das ganz gut. Wenn aber für 6 bis 10 Thermostate gleichzeitig für 6:30 der Wechsel auf die Tagestemperatur über ein CUL/CUNO device geschickt wird, kann dies schnell zu Kommunikationsproblemen führen, abgesehen davon, dass es erhebliche Zeitverzögerungen gibt, bis endlich die neuen Temperaturwünsche an allen Geräten angekommen sind. Das ist der Grund, warum ich morgens und abends die Steuerung per FHT Wochenschaltplan mache (--> alle Geräte im auto modus) und während des Tages zusätzliche Zeitintervalle mit (z.T. erhöhter) Komforttemperatur per Party-Funktion steuere, entweder geplant per "at" oder ad hoc per IR-FB bzw. Handy. Zusätzlich schalte ich hin- und wieder für einige Räume, die an diesem Tag nicht mehr benutzt werden, die "desired-temp" vor Erreichen des Schaltpunktes am Abend per IR-FB vorzeitig auf Absenktemperatur. Seitdem ich so verfahre ist LOVL trotz 12 FHTs glücklicherweise ein Fremdwort geworden.

Mit diesem Verfahren ist auch sichergestellt, das ein Raum nicht den ganzen Tag bis zur Nachtabschaltung der Heizung wegen eines nicht empfangenen Absenktemperatur unnötigerweise aufgeheizt bleibt.

Die Steuerung per Party-Funktion hat m.E.ein schönes Goodie. Die geplanten Schaltzeitpunkte lassen sich mit dieser Funktion sehr schön aus dem Stehgreif "temporär überschreiben". Der letzte Party-/Urlaubs-Befehl zählt für die gesamt angegebene Dauer, ganz gleich, ob er per Mausklick/touch oder am FHT Gerät selbst ausgeführt wurde.  
 
Das der Wochenschaltplan der FHTs nicht zentral in einer schönen Übersicht vorliegt, mag zwar ein Manko sein. Zumindestens die Readings der FHT Geräte halte ich aktuell indem ich jede Nacht ab 22:30 die Schaltzeitpunkte für den kommenden Tag plus Tages- und Absenktemperatur per "report1/2" von den FHTs anfordere und somit auf den aktuellen Stand halte. Übrigens, alle routinemäßigen Funk-Kommandos an die FHTs schedule ich (automatisch generiert) mit einem Zeitintervall von rund 15 Minuten. Nur so konnte ich bei mehr als 10 FHTs die Limitierung im Funkbereich aufgrund der 1% Regel und durch Befehlswiederholung in den Griff bekommen. Da der meiste Funkverkehr in der Nacht läuft (Update der Schaltpunkte ab 22:30 Uhr, ad hoc Überschreibung des morgendlichen "Tagesbeginns" einzelner bzw. aller FHTs ab 1:30 Uhr (am), habe ich bis auf die zuätzlichen Komforttemperatur-Intervalle im Tagesverlauf kaum Funkbelastung durch Steuerung der FHT Geräte.

Bei wenigen FHT Geräten sehe ich wenig Probleme dies auschließlich von der Zentralen per Heating-Control zu machen und die FHTs u.U. sogar im "manu" Betrieb zu fahren. Wer jedoch plant mit 10 oder mehr FHT Geräten die Temeratur komfortabel (und mit wenig Fehlern zu steuern), sollte das zeitgleiche Schalten von mehreren FHTs per Funk möglichst (konzeptionell) vermeiden / minimieren. In dem Fall kann Heating-Control sicherlich die Steuerung während des Tages erleichtern und insbesondere Bedingungen wie Anwesenheit während der Ferienzeiten etc. gut abbilden.    

Gruß,
Ludger

[Gunther]

Ich verfolge die Diskussion hier gespannt, da mich leider die Thematik mit den Funktüberschreitungen auch trifft. Ich habe 8 FHTs im Einsatz. Dazu noch 3 von den Hygrostaten.

Hier mal das aktuelle Log nachdem ich per Heizungsplan nur 3 FHTs umgestellt habe :-( :

Code Auswählen Erweitern

2013.04.02 17:42:16 2: FHT set eg_bz_Heizung desired-temp 18.0
2013.04.02 17:42:17 2: FHT set eg_ki_Heizung desired-temp 20.0
2013.04.02 17:42:17 2: FHT set eg_ku_Heizung desired-temp 19.0
2013.04.02 17:42:52 2: CUL_0: unknown message LOVF
2013.04.02 17:42:52 2: CUL_0: unknown message LOVF
2013.04.02 17:42:52 2: CUL_0: unknown message LOVF
2013.04.02 17:42:52 2: CUL_0: unknown message LOVF
2013.04.02 17:42:53 2: CUL_0: unknown message LOVF
2013.04.02 17:42:53 2: CUL_0: unknown message LOVF
2013.04.02 17:43:28 2: CUL_0: unknown message LOVF
2013.04.02 17:43:28 2: CUL_0: unknown message LOVF
2013.04.02 17:43:29 2: CUL_0: unknown message LOVF
2013.04.02 17:43:29 2: CUL_0: unknown message LOVF
2013.04.02 17:43:56 2: CUL_0: unknown message LOVF
2013.04.02 17:44:49 2: CUL_0: unknown message LOVF
2013.04.02 17:44:50 2: CUL_0: unknown message LOVF
2013.04.02 17:44:50 2: CUL_0: unknown message LOVF
2013.04.02 17:45:24 2: CUL_0: unknown message LOVF
2013.04.02 17:45:24 2: CUL_0: unknown message LOVF
2013.04.02 17:45:24 2: CUL_0: unknown message LOVF
2013.04.02 17:45:25 2: CUL_0: unknown message LOVF
2013.04.02 17:46:47 2: CUL_0: unknown message F2A2CE2
2013.04.02 17:49:03 2: CUL_0: unknown message LOVF
2013.04.02 17:49:03 2: CUL_0: unknown message LOVF
2013.04.02 17:49:04 2: CUL_0: unknown message LOVF
2013.04.02 17:49:04 2: CUL_0: unknown message LOVF
2013.04.02 17:49:16 2: CUL_0: unknown message LOVF
2013.04.02 17:49:18 2: CUL_0: unknown message LOVF
2013.04.02 17:49:18 2: CUL_0: unknown message LOVF
2013.04.02 17:49:19 2: CUL_0: unknown message LOVF
2013.04.02 17:49:19 2: CUL_0: unknown message LOVF
2013.04.02 17:50:52 2: CUL_0: unknown message LOVF
2013.04.02 17:50:52 2: CUL_0: unknown message LOVF
2013.04.02 17:50:52 2: CUL_0: unknown message LOVF
2013.04.02 17:50:52 2: CUL_0: unknown message LOVF
2013.04.02 17:51:14 2: CUL_0: unknown message LOVF
2013.04.02 17:51:14 2: CUL_0: unknown message LOVF
2013.04.02 17:52:40 2: CUL_0: unknown message LOVF
2013.04.02 17:52:57 2: CUL_0: unknown message LOVF
2013.04.02 17:52:57 2: CUL_0: unknown message LOVF
2013.04.02 17:52:57 2: CUL_0: unknown message LOVF
2013.04.02 17:53:12 2: CUL_0: unknown message LOVF
2013.04.02 17:53:12 2: CUL_0: unknown message LOVF
2013.04.02 17:54:08 2: CUL_0: unknown message LOVF
2013.04.02 17:54:08 2: CUL_0: unknown message LOVF
2013.04.02 17:54:09 2: CUL_0: unknown message LOVF
2013.04.02 17:54:09 2: CUL_0: unknown message LOVF
2013.04.02 17:54:35 2: CUL_0: unknown message LOVF
2013.04.02 17:54:35 2: CUL_0: unknown message LOVF
2013.04.02 17:54:35 2: CUL_0: unknown message LOVF
2013.04.02 17:54:36 2: CUL_0: unknown message LOVF
2013.04.02 17:55:14 2: CUL_0: unknown message LOVF
2013.04.02 17:55:14 2: CUL_0: unknown message LOVF
2013.04.02 17:57:06 2: CUL_0: unknown message LOVF
2013.04.02 17:58:38 2: CUL_0: unknown message LOVF
2013.04.02 17:58:38 2: CUL_0: unknown message LOVF
2013.04.02 17:58:38 2: CUL_0: unknown message LOVF
2013.04.02 17:58:39 2: CUL_0: unknown message LOVF
2013.04.02 17:59:04 2: CUL_0: unknown message LOVF
2013.04.02 17:59:05 2: CUL_0: unknown message LOVF
2013.04.02 18:00:37 2: CUL_0: unknown message LOVF
2013.04.02 18:00:37 2: CUL_0: unknown message LOVF
2013.04.02 18:00:37 2: CUL_0: unknown message LOVF
2013.04.02 18:00:38 2: CUL_0: unknown message LOVF
2013.04.02 18:01:02 2: CUL_0: unknown message LOVF
2013.04.02 18:01:03 2: CUL_0: unknown message LOVF
2013.04.02 18:01:19 2: CUL_0: unknown message LOVF
2013.04.02 18:01:20 2: CUL_0: unknown message LOVF
2013.04.02 18:01:20 2: CUL_0: unknown message LOVF
2013.04.02 18:01:20 2: CUL_0: unknown message LOVF
2013.04.02 18:02:43 2: CUL_0: unknown message LOVF
2013.04.02 18:02:44 2: CUL_0: unknown message LOVF
2013.04.02 18:02:44 2: CUL_0: unknown message LOVF
2013.04.02 18:02:59 2: CUL_0: unknown message LOVF
2013.04.02 18:03:00 2: CUL_0: unknown message LOVF
2013.04.02 18:03:16 2: CUL_0: unknown message LOVF
2013.04.02 18:03:16 2: CUL_0: unknown message LOVF
2013.04.02 18:03:16 2: CUL_0: unknown message LOVF
2013.04.02 18:05:12 2: CUL_0: unknown message LOVF
2013.04.02 18:05:12 2: CUL_0: unknown message LOVF
2013.04.02 18:05:12 2: CUL_0: unknown message LOVF
2013.04.02 18:05:45 2: CUL_0: unknown message LOVF
2013.04.02 18:05:45 2: CUL_0: unknown message LOVF
2013.04.02 18:05:45 2: CUL_0: unknown message LOVF
2013.04.02 18:05:46 2: CUL_0: unknown message LOVF
2013.04.02 18:05:47 2: CUL_0: unknown message LOVF
2013.04.02 18:05:47 2: CUL_0: unknown message LOVF
2013.04.02 18:05:47 2: CUL_0: unknown message LOVF
2013.04.02 18:05:48 2: CUL_0: unknown message LOVF
2013.04.02 18:06:55 2: CUL_0: unknown message LOVF
2013.04.02 18:06:55 2: CUL_0: unknown message LOVF
2013.04.02 18:07:44 2: CUL_0: unknown message LOVF
2013.04.02 18:07:44 2: CUL_0: unknown message LOVF
2013.04.02 18:07:45 2: CUL_0: unknown message LOVF
2013.04.02 18:08:14 2: CUL_0: unknown message LOVF
2013.04.02 18:08:14 2: CUL_0: unknown message LOVF
2013.04.02 18:09:03 2: CUL_0: unknown message LOVF
2013.04.02 18:09:03 2: CUL_0: unknown message LOVF
2013.04.02 18:09:03 2: CUL_0: unknown message LOVF
2013.04.02 18:09:04 2: CUL_0: unknown message LOVF
2013.04.02 18:09:04 2: CUL_0: unknown message LOVF
2013.04.02 18:09:04 2: CUL_0: unknown message LOVF
2013.04.02 18:09:05 2: CUL_0: unknown message LOVF
2013.04.02 18:09:42 2: CUL_0: unknown message LOVF
2013.04.02 18:09:42 2: CUL_0: unknown message LOVF
2013.04.02 18:09:42 2: CUL_0: unknown message LOVF
2013.04.02 18:09:43 2: CUL_0: unknown message LOVF
2013.04.02 18:10:30 2: CUL_0: unknown message LOVF
2013.04.02 18:10:30 2: CUL_0: unknown message LOVF
2013.04.02 18:10:49 2: CUL_0: unknown message LOVF
2013.04.02 18:10:50 2: CUL_0: unknown message LOVF
2013.04.02 18:11:02 2: CUL_0: unknown message LOVF
2013.04.02 18:11:02 2: CUL_0: unknown message LOVF
2013.04.02 18:11:03 2: CUL_0: unknown message LOVF
2013.04.02 18:11:03 2: CUL_0: unknown message LOVF
2013.04.02 18:25:18 2: CUL_0: unknown message LOVF
2013.04.02 18:25:18 2: CUL_0: unknown message LOVF
2013.04.02 18:26:29 2: CUL_0: unknown message LOVF
2013.04.02 18:26:30 2: CUL_0: unknown message LOVF
2013.04.02 18:26:30 2: CUL_0: unknown message LOVF

[Michael N.]

Der Autor des CULMAX-Moduls hat genialer Weise irgendwann ein Queuing beim Senden der Befehle implementiert. Seitdem habe ich keine Probleme mehr mit LOVF. Vielleicht braucht FHT das auch.

[Dietmar63]

@gunter, Ludger

Die LOVF scheinen tatsächlich das zu bestätigen, was du, Ludger vorher gesagt hast.

Dass das Problem aber schon nach 3 fht auftritt, könnte an zusätzlichen Funkproblemen liegen - kann ich aber nicht genau sagen.

Wie gesagt, beim Start bekommen alle fht ihre Start temp, deshalb die drei desired-temp.

Ehrlich gesagt bin ich ratlos - in der Dokumentation liest man, daß Probleme ab so ca. 10 fht zu erwarten sind. Bei zwei fht habe ich noch kein Problem.

Kannst du Tests durchführen, ob bei dir zusätzliche Probleme vorliegen?
gib mal folgende in der Oberfläche oder dem fhem.cfg ein:

Code Auswählen Erweitern

define yy at *+00:01:00 get CUL_0 raw T02
dann bekommst du infos über deinen fht-Puffer und kannst prüfen ob sich etwas tut:
http://www.fhemwiki.de/wiki/Kommunikationsprobleme_mit_FHT

mit

Code Auswählen Erweitern

get CUL raw X
bekommst die freien Zeiten des cul angezeigt. Mal sehen, ob wir es für dich nutzbar machen können.
FS20 und FHT scheit bei vielen FHT wirklich ein Problem zu sein.

[John]

Matthias Gehre hat wie unter folgenden Link nachzulesen ist

Link

für 14_CUL_MAX.pm Queueing eingeführt.

Es merkt sich die Kommandos und sendet erst dann wieder, wenn genug "Credit" vorhanden ist.

Aus meiner Sicht eine absolute Notwendigkeit für einen sicheren Betrieb, wenn zu einem bestimmten
Zeitpunkt gehäuft Sende-Kommandos auftauchen.

Wenn kein Acknowledge kommt wird bis zu 3x ein erneuter Sendeversuch gestartet.
Damit ist die Zustellung SEHR sicher.

Die MAX-User haben seit dieser Zeit mit dem Heating_control kein Problem mehr.

Als Workaround bietet sich folgendes an:
Die Sende-Befehle nicht alle zum gleichen Zeitpunkt senden, sondern z.B. um 5 Minuten versetzt. (Damit wird Credit gesammelt)
So hab ich das Problem vor der Einführung des Queueings gelöst.


John

[Dietmar63]

Die MAX-User haben seit dieser Zeit mit dem Heating_control kein Problem mehr.

Hatten sie denn ein Problem?

[Michael N.]

Vorher ja. Allerdings trat das Problem unabhängig von Heating_Control bei mir auf, weil ich zu viele "at" Kommandos zur gleichen Zeit hatte. Jetzt ist alles gut.