Neues Modul - Heating_Control, WeekdayTimer

[Dietmar63]

Ich werde deinen Wunsch heute prüfen.
Auf dem ersten Blick, scheint es mir aber möglich zu sein, so eitwas umzusetzen.

Es muss dann wahrscheinlich etwas mehr umgebaut werden.
Kann ich dich dann als Tester einsetzen - ich habe kein MAX?

[Michael N.]

Ja klar, ich teste das gerne.

[Damian]

Hallo,

es wurde hier mehrfach der Erweiterungswunsch für eine Wochenzeitschaltuhr geäußert.
Nun wollte ich nicht mehr länger auf eine Umsetzung warten und habe für mich gerade das Modul erweitert.

(siehe Anhang / see attachement)

Bei Interesse kann ich hier die paar Änderungen für die Entwickler posten.

Gruß

Damian

[Dietmar63]

schick mir bitte deine Version des Moduls per PM, dann arbeite ich sie ein und stelle das Modul online.

[Dietmar63]

Ich habe Deine Änderungen 1:1 übernommen und inzwischen eingecheckt.

[John]

Ich nutze das Heating-Control gerne und finde es sehr gelungen.

Ein zeitlicher Offset als zusätzliches Attribut wäre hilfreich.

Meine Zielvorstellung:
  Der Schaltzeitpunkt des Heating_Controls bedeutet nicht mehr wie bisher:


    "Setze den Sollwert des Thermostats xy"

  sondern

      " zu diesem Zeitpunkt soll der Raum die Solltemperatur erreicht haben"


Wenn ich etwa weiss, dass es ca. 1,5 Std. dauert, bis der Raum von 16 auf 19 Grad geheizt ist,
wäre das neue Attribut wie folgt zu realisieren.

Code Auswählen Erweitern

attr myHeatingControl time_offset 01:30
 
Vielleicht findet der Vorschlag ja Anhänger


John

[Dietmar63]

Ich habe es bisher immer so gehalten, dass ich bei der Definition der Schaltzeitpunkte selbst das offset immer so gut es ging eingerechnet habe.

Also wenn ich morgens um 6:30 in der Küche frühstücken will muss ich um 5:45 die Heizung anschalten.

Machbar wäre es sicherlich eine solche Erweiterung einzubauen.
Ich habe allerdings noch keine Vorstellung wie ich es machen könnte, es dürfte aber in jedem Fall einiges an Aufwand bedeuten und auch nicht ganz unkompliziert sein.

In den Sommermonaten werde ich bestimmt nicht dazu kommen.
Ich hoffe, der Sommer noch kommt!

[Dietmar63]

Probleme mit der Sommerzeitumstellung:

Link

[Dietmar63]

Ich glaube ich habe einen Weg gefunden HC gegen Sommerzeitumstellungen immun zum machen.
War gar nicht so schwer!

Ich werde es einbauen testen und bei Gelegenheit in SVN einchecken.

[Gunther]

Wenn du wie im Beispiel beschrieben HC so

Code Auswählen Erweitern

define HCW Heating_Control WZ_Heizung Sa-So,Mi|08:00|21 (ReadingsVal("WeAreThere", "state", "no") eq "yes")
definierst, erfolgt keine weitere Schaltung seitens HC, wenn WeAreThere nicht auf yes steht.

Ein notify erledigt den Rest: Ich habe mit

Code Auswählen Erweitern

define Befehl5a               notify WeAreThere:no        {fhem ("set HeizungKueche desired-temp 18;; set HeizungWohnen desired-temp 18") }
erreicht, dass beim Setzen des Dummys die Temperaturen korrigiert werden. So bleiben sie bis ich WeAreThere wieder auf yes setze.

Zur Zeit gibt es keine Möglichkeit automatisch die Pläne zu ändern. Ich habe mir so geholfen, dass ich zwei HC angelegt habe. Über die Bedingungvariable kannst du steuern wann welcher HC schalten soll.

Ich hatte vor einiger Zeit nach der Umsetzung von HC mit dem Homestatus gefragt.

Bei mir kann der Dummy "HomeStatus" die Werte 1-4 übernehmen (http://www.fhemwiki.de/wiki/Zuhause-Status)
Nun habe ich folgendes geschrieben:

Code Auswählen Erweitern

define eg_bz_Heizung_Heizungsplan_zuhause Heating_Control eg_bz_Heizung Mo,Di,Mi,Do|03:08|23 Mo,Di,Mi,Do|23:00|18 Fr,Sa,So|06:00|23 Fr,Sa,So|12:00|21 Fr,Sa,So|23:00|18 (ReadingsVal("HomeStatus" < 3 )
define eg_bz_Heizung_Heizungsplan_weg Heating_Control eg_bz_Heizung Mo,Di,Mi,Do,Fr,Sa,So|03:08|10 Mo,Di,Mi,Do,Fr,Sa,So|17:00|10 Mo,Di,Mi,Do,Fr,Sa,So|01:00|10 (ReadingsVal(Value("HomeStatus") > 2 )

Leider bekomme ich dabei eine Fehlermeldung:

Code Auswählen Erweitern

2013.04.01 03:07:58 3: Not enough arguments for main::ReadingsVal at (eval 130) line 1, near "2 )"
syntax error at (eval 130) line 1, at EOF

2013.04.01 03:08:00 3: Not enough arguments for main::ReadingsVal at (eval 131) line 1, near "2 )"
syntax error at (eval 131) line 1, at EOF

2013.04.01 03:08:01 3: Not enough arguments for main::ReadingsVal at (eval 132) line 1, near "3 )"
syntax error at (eval 132) line 1, at EOF

2013.04.01 03:08:01 3: Not enough arguments for main::ReadingsVal at (eval 133) line 1, near "2 )"
syntax error at (eval 133) line 1, at EOF

Fehlt mir etwas?
Die Bedingung aus dem Zitat oben verstehe ich leider nicht voillständig: (ReadingsVal("WeAreThere", "state", "no") eq "yes")
Was bedeutet das "state"?

[Dietmar63]

Die Bedingungen sind syntaktisch noch nicht korrekt. Versuch es mal mit folgende Änderungen:

Code Auswählen Erweitern


define HCW  Heating_Control WZ_Heizung    Sa-So,Mi|08:00|21    (ReadingsVal("WeAreThere", "state", "no") eq "yes")

define eg_1 Heating_Control eg_bz_Heizung Sa-So,Mi|08:00|21    (ReadingsVal("HomeStatus", "state",    1)  <  3)
define eg_2 Heating_Control eg_bz_Heizung Sa-So,Mi|08:00|21    (ReadingsVal("HomeStatus", "state",    1)  >  2)


bei "state" handelt es sich um ein Reading eines dummys. Geräte haben oft viele verschiedene Readings - man könnte auch Statusvariable dazu sagen. Einfach mal in der Oberfläche von fhem auf ein Gerät clicken - dann kann man sich Details ansehen.

Ich habe die Texte deiner beiden Zeilen ein wenig gekürzt, damit Du erkennst wie die Readings ausgelesen werden können.
Unterhalb von "no" habe ich "1" angegeben. Das mußt Du deinen Verhältnissen anpassen. Es handelt sich um den Wert, der "ausgelesen" wird, wenn das Reading "state" nicht gefunden wird.

Also den hinteren Teil der beiden letzen Zeilen ins cfg dann solltest du weiterkommen. Ich habe nicht getestet, sollte aber trotzdem funktionieren.

[Gunther]

Lieben Dank für die schnelle Antwort!

Ich habe nun das Coding angepasst, bekomme aber leider gar nichts mehr im Log. Habe um 15:03 versucht mit zwei Heizungs-Controll-Devices entsprechend des Komestatus zu schalten:

Code Auswählen Erweitern

define eg_bz_Heizung_Heizungsplan_zuhause Heating_Control eg_bz_Heizung Mo,Di,Mi,Do|15:03|23 Mo,Di,Mi,Do|23:00|18 Fr,Sa,So|06:00|23 Fr,Sa,So|12:00|21 Fr,Sa,So|23:00|18 (ReadingsVal("HomeStatus", "state",    1)  <  3)

define eg_bz_Heizung_Heizungsplan_weg Heating_Control eg_bz_Heizung Mo,Di,Mi,Do,Fr,Sa,So|15:03|10 Mo,Di,Mi,Do,Fr,Sa,So|17:00|10 Mo,Di,Mi,Do,Fr,Sa,So|01:00|10 (ReadingsVal ("HomeStatus", "state",    1)  >  2)


Habe ich einen Denkfehler? Wenigstens bekomme ich keine Error-Meldung mehr.

EDIT: scheint nun zu gehen. Hatte wohl keine Änderung im Log, da ich keinen Temperaturwechsel hatte.

Ein Fehler noch:
Im Log erscheint nun (HomeStatus = 4) statt einmal mehrmals:
2013.04.01 15:19:46 2: FHT set eg_bz_Heizung desired-temp 10.0
2013.04.01 15:20:00 2: FHT set eg_bz_Heizung desired-temp 10.0
2013.04.01 15:20:00 2: FHT set eg_bz_Heizung desired-temp 10.0
2013.04.01 15:20:00 2: FHT set eg_bz_Heizung desired-temp 10.0
2013.04.01 15:20:00 2: FHT set eg_bz_Heizung desired-temp 10.0
2013.04.01 15:20:00 2: FHT set eg_bz_Heizung desired-temp 10.0
2013.04.01 15:20:01 2: FHT set eg_bz_Heizung desired-temp 10.0

Woand liegt das?

[Dietmar63]

Code Auswählen Erweitern

{Log 3, ReadingsVal ("HomeStatus", "state",    1) }
Gib mal obigen Code in die Kommandozeile von fhem ein und kontrolliere das Log.

Dort müsstest du den aktuellen HomeStatus finden.

Achtung HC verändert die Temperatur nur wenn es etwas zu Ändern gibt.

[Dietmar63]

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

[LudgerR]

Hallo,

eine Verständnisfrage / Anmerkung:

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?

Für die wenigen Räume, in denen mehr als zwei Perioden benötigt werden, lässt sich das einfach mit Bordmitteln (sprich Party-Funktion) der FHT realisieren. Pro zusätzliche Tageszeitintervall per ,,at" ein Aufruf der FHT Partyfunktion z.B. als Subroutine in der Form  
         

Code Auswählen Erweitern


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


Die gesamten Parameter (für den impliziten holiday-short Befehl, der von fht_party erzeugt werden muss) werden in einem Funkbefehl an das FHT Gerät übertragen. Ein weiteres (Funk-)Kommando am Ende des zusätzlichen Tagestemperaturintervalls ist nicht erforderlich.  Auch bei einer großen Anzahl von FHT-Geräten  wird somit  allein konzeptionsbedingt , die häufig auftretenen Kommunikationsprobleme bei einer  großen Anzahl von FHT Geräten weitestgehend verhindert.      
           
Insbesondere wenn man (später) weitere Komfortfunktionen realisieren möchte, wie z.B. das temporäre ad hoc Aufheizen eines Fitnessraumes, Bügelzimmers oder Hobbyraumes per Mausklick oder per (IR-) Fernbedienung ist es von Vorteil, wenn die entsprechende FHTs im auto mode der FHT Geräte laufen .  Per Party-Funktion, diesmal per Mausklick getriggert, wird  der Schaltplan für die angegeben Zeit im FHT Gerät außer Kraft gesetzt (und lässt sich ggf. per Mausklick bzw. durch einfaches Drücken der ,,FUNKTION" Taste am FHT Gerät vorzeitig wieder aufheben).  

Wegen den Kommunikationproblemen bei einer großen Anzahl von FHT Geräten bin ich  von einen ,,zentralistischen" Ansatz bei der Steuerung der FHTs völlig abgekommen und nutze die dezentrale Funktionen der FHTs, wo immer möglich. Mit dieser Lösung bin ich sehr zufrieden und plane nun sogar meine letzten Räume (13. und 14.) mit FHT auszurüsten (ursprünglich hatte ich hierfür schon HM im Visier) .


Viele Grüße,
Ludger

  P.s.   Wechsel auf Sommerzeit wird von den FHTs automatisch durchgeführt. Lediglich wenn man, wie ich, um Mitternacht  die Aufstehzeit noch ad hoc variiert und den Schaltzeitpunkt für den Wechsel von Nacht auf Tag für alle FHT Geräte  per Party-Funktion am Wochenende individuell anpasst und dies ausgerechnet zwischen 1:30 und 3:00 Uhr scheduled  erzielt man nicht bei allen Geräten das gewünschte Ergebnis :).