Hi,
erst Mal ein gute Neues Jahr an alle Leser!
Wollte ein paar unklare Sprünge im desired Temperatur Verlauf in den Logs untersuchen, die nicht im Wochenprogramm enthalten sind.
Mein Setup sieht so aus:
- Cube ohne CUL,
- Wandthermostat,
- 2 HT und
- 2 FK,
- FHEM auf RSP-2.
Die MAX-Software ist auch installiert und benutzbar (wenn fhem service gestoppt).
FHEM hat noch die Version "8320 2015-03-29 10:49:31Z", muß erst wieder einen update versuchen. Beim letzten Mal hagelte es Fehlermeldungen und ich bin wieder auf die Alte zurückgegangen und hatte dann keine Zeit mehr.
Ich wollte wissen, ob die Sprünge evtl. von einem abweichenden Wochenprogramm im jeweiligen HT herrühren.
Testverlauf daher:
- Das Wochenprogramm hat 21.5°zum Testzeitpunkt
- File Heizung_rechts.cfg editiert (19° zur Testzeit definiert) und mit
- {MAX_Restore("Heizung_rechts")} eingespielt
- Mit list Heizung_rechts.cfg verifiziert, hat gstimmt
- Fenster rechts geöffnet
- 12° am WT
- 12° am HT angezeigt
- Fenster geschlossen
- 21.5 am WT
- 19° am HT
[/li]
Aha, das ist falsch!
Ich habe mich ja schon immer gefragt, was das Wochenprogramm der HTs für eine Bedeutung hat, wenn man ein WT verwendet. Jetzt weiß ich es ( ;D):
WT, HTs und FK sind miteinander in beiden Richtungen assoziert. Das wirkt immer sofort, wie ich getestet habe. Also, wenn das HT nicht mit dem passenden FK ass. ist, reagiert es auch nicht auf den FK, obwohl die Assoziation mit dem WT weiterhin bestanden hat.
Eigentlich sollte eine Assoziation von HT und FK ja überflüssig sein, weil es ja eine von FK und WT gibt und das WT die Temperaturen vorgeben sollte.
Wäre super, wenn mir dieses merkwürdige Verhalten jemand erklären könnte.
Um erst mal wieder alles ins Lot zu bringen, habe ich FHEM gestoppt und mit der MAX-Software das Wochenprogramm für das gesamte Wohnzimmer neu gesetzt imd dann FHEM wieder gestartet. In FHEM wird per list HT und WT jetzt beide male das korrekte Wochenprogramm angezeigt. Beim Fensterschließen stimmt die Temp. jetzt auch wieder.
Scheinbar muß das Wochenprogramm von WT und allen assoz. HTs doch gleich sein. Vielleicht gibt es ja die Regel und ich kenne sie nur nicht.
Gruß, Onurbi
Das "Problem" hatte ich auch. In einem Raum waren 2 HT mit einem WT assoziert und der WT mit einem Fensterkontakt (alles über MAX-CUBE). Einer der beiden HT hat das Wochenprogramm vom WT nicht übernommen und kann das bis heute nicht. Die Wochenpeofile der beiden HT waren in FHEM daher auch unterschiedlich. Die Regelung der Solltemperatur übernimmt der WT, d.h. zu den Schaltzeitpunkten sendert er die zu setzende Tempertur an die HT. Der eine HT mit dem abweichenden Profil wurde zu seinen internen Schaltpunkten auch immer aktiv, jedoch werden diese Aktionern vom WT beim nächsten Reading ausgeregelt. Es hat also praktisch keine Folgen.
Um den HT ruhig zu stellen, habe ich über FHEM das Wochenprofil des WT direkt an den HT gesendet und jetzt verhält er sich wie der andere HT.
Wenn der Fensterkontakt geöffnet ist, nimmt der WT keine Befehle entgegen, d.h. mann kann dann den Raum nicht steuern, bis der Kontakt wieder geschlossen ist.
Die HT stellen in diesem Fall die "Fenster offen"-Temperatur ein und die kann bei jedem ja auch anders sein.
Eine weitere Bestätitigung: Die "Glitches" der Desired Temperatur bei den HTs sind weg, seit die Wochenprogramme der HTs gleich dem des WTs sind.
Heißt: Wenn ein HT z.B. um 7:45 einschalten soll, das WT aber erst um 8:30 einschalten möchte, geht im Log die Desired Temperature um 7:45 hoch und eine Minute später wieder runter (das meine ich mit Glitch). Je nach HT geht dann das Ventil unerwünscht auf oder nicht. Sicher auch bald wieder zu, aber eben ungeplant.
Das Hauptthema ist ja eigenltlich der Urlaub zu Hause und die Notwendigkeit für diese Zeit das Wochenprogramm umstellen zu wollen.
Die Lösung mit dem {MAX_Restore("<Gerätename>")} Aufruf und der Modulergänzung in 99_myUtils.pm^(http://forum.fhem.de/index.php/topic,35157.msg275615.html#msg275615) ist dabei schon eine große Hilfe, aber das Konzept des Cubes ist da doch leider etwas beschränkt.
Um einen Wochenprogrammwechsel durchzuführen, müßte ich mit meiner Konfiguration:
- 3 Files editieren für das jeweilige Wochenprogramm und evtl. die anderen Parameter zum Gerät: Heizung_links.cfg, Heizung_rechts.cfg und Wandthermostat.cfg
- 3 x Kommandos ausführen (MAX_Restore("<Gerätename>"))
Ich würde es gerne verifizieren, aber es klappt nicht. Grund ist vielleicht, dass diese Daten in den Geräten gespeichert werden und per Funk dort hingelangen müssen und damit die Sache mit den Credits, die ich mir noch anlesen muß. Ich habe bisher nur verstanden, dass man nicht zu viele Daten über Funk in kurzer Zeit verschicken kann und gerade das Wochenprogramm sind wahrscheinlich viele.
Nachdem alle Files editiert waren, habe ich das WT neu beschrieben. Mit List sehe ich die neuen Daten auch. Im fhemlog tauchen die Restorezeilen auf.
Restore ich das gleich danach für eines der beiden HTs, ist im Log nur "MAX_Restore: Heizung_links ecoTemperature -> 20.0" zu sehen und nicht die anderen Zeilen der Wochenprogrammänderung. Dabei habe ich den Parameter für die ecoTemperature im File nicht geändert. "List" für das HT bringt nur die alten Werte.
Also entweder muß ich warten, um die anderen Restores durchzuführen, oder das Modul hat einen Fehler.
Hat noch jemand mit Backup und Restore Erfahrung?
Gruß, Onurbi
Ich habe es so gelöst.
Dummy zum Schalten für profile angelegt, Schalter mit Profil Normal und Urlaub.
Profile im Fhem-Schema für Urlaub und Normal in einem Notify hinterlegt, diese werden dann auf den HT übertragen, wenn der Dummy geschaltet wird.
Schaltanweisung im Notify
Profil Woche: set MAX_Name weekProfile Mon 12.0,02:00,11.5,02:05,12.0,07:10,18.0,08:30,12.0,12:00,11.5,12:05,12.0,15:35,11.5,17:20,19.0,20:00,15.0,23:00,12.0
set MAX_Name weekProfile Tue 12.0,02:00,11.5,02:05,12.0,07:10,18.0,08:30,12.0,12:00,11.5,12:05,12.0,15:35,11.5,17:20,19.0,20:00,15.0,23:00,12.0
...
Die Anlage der Profile ist zwar etwas fummelig, macht man ja aber auch nicht ständig. Umschalten und auch ein Restore sind dafür natürlich komfortabel über den Dummy möglich.
Hallo west2107,
bin beim Lesen schon öfter über Lösungen mit dummy gefallen, habe aber noch kein konkretes Beispiel gefunden. Klingt auf jeden Fall interessant!
Kann ich damit mehrere Geräte unter einem Namen zusammenfassen? Könntest Du bitte als Beispiel eine Konfiguraton im fhem.cfg mal posten?
Ist der Ansatz für den Montag im fhem .cfg so richtig?
define All_Wohnzimmer_devices dummy
set Wandthermostat weekProfile Mon 12.0,02:00,11.5,02:05,12.0,07:10,18.0,08:30,12.0,12:00,11.5,12:05,12.0,15:35,11.5,17:20,19.0,20:00,15.0,23:00,12.0
set Heizung_rechts weekProfile Mon 12.0,02:00,11.5,02:05,12.0,07:10,18.0,08:30,12.0,12:00,11.5,12:05,12.0,15:35,11.5,17:20,19.0,20:00,15.0,23:00,12.0
set Heizung_links weekProfile Mon 12.0,02:00,11.5,02:05,12.0,07:10,18.0,08:30,12.0,12:00,11.5,12:05,12.0,15:35,11.5,17:20,19.0,20:00,15.0,23:00,12.0
Ich kann dann praktisch mit {MAX_Restore("All_Wohnzimmer_devices")} alle drei Geräte auf einmal setzen?
Gerade habe ich festgestellt, dass das Definieren des Wochenprogramms selbst nach einigen Stunden in den HTs nach wie vor nicht funktioniert. Im Log tauchen die entsprechenden Zeilen nicht auf, list bringt dann natürlich auch nur die alte Definition. Es werden bei Restore ja nur die Änderungen ins Log geschrieben, was Sinn macht. Wenn ich im Heizung_rechts.cfg die Zeiten leicht verändern würde, würden die Änderung wahrscheinlich geloggt werden. Aber dann ist das HT-Rechts ja wieder unterschiedlich.
Aber vielleicht klappt es ja mit dem Dummy.
Gruß, Onurbi
Hier ein Beispiel
Der Schalter läd das Wochenprofil für die Tage Mo-Fr auf den Max-HT oder WT. An den Wochenenden ändert sich ja grundsetzlich nichts. Ausserdem wird ein Logeintrag erzeugt.
Das Beispiel ist exemplarisch für einen HT. Für ein WT muss "setstate" anstelle von "set" verwendet werden.
Im Noralfalle reicht die Übergabe an den WT, es sei denn, mann hat so einen wiederbosrtigen HT wie ich, den muss man dann halt separat bedienen.
---------------------------------------------------------------------------------------------------------------------
define Profilschalter dummy
attr Profilschalter alias Hauptschalter Alarm
attr Profilschalter setList state:NORMAL,URLAUB
attr Profilschalter webCmd state
define act_Profilschalter_ac notify Profilschalter {\
if (Value("Profilschalter") eq "NORMAL" ) {\
fhem("set MAX_NAME weekProfile Mon 12.0,07:10,18.0,08:30,12.0,12:00,11.5,12:05,12.0,15:35,11.5,17:20,19.0,23:00,12.0 ;; set MAX_NAME weekProfile Tue 12.0,07:10,18.0,08:30,12.0,12:00,11.5,12:05,12.0,15:35,11.5,17:20,19.0,23:00,12.0 ;; set MAX_NAME weekProfile Wed 12.0,07:10,18.0,08:30,12.0,12:00,11.5,12:05,12.0,15:35,11.5,17:20,19.0,23:00,12.0 ;; set MAX_NAME weekProfile Thu 12.0,07:10,18.0,08:30,12.0,12:00,11.5,12:05,12.0,15:35,11.5,17:20,19.0,23:00,12.0 ;; set MAX_NAME weekProfile Fri 12.0,07:10,18.0,08:30,12.0,12:00,11.5,12:05,12.0,15:35,11.5,17:20,19.0,23:00,12.0 ;;") ;; Log 3, "WP Normal aktiviert" ;;}\
else {\
fhem("set MAX_NAME weekProfile Mon 12.0,08:30,12.0,12:00,11.5,12:05,12.0,15:35,11.5,17:20,19.0,23:00,12.0 ;; set MAX_NAME weekProfile Tue 12.0,08:30,12.0,12:00,11.5,12:05,12.0,15:35,11.5,17:20,19.0,23:00,12.0 ;; set MAX_NAME weekProfile Wed 12.0,08:30,12.0,12:00,11.5,12:05,12.0,15:35,11.5,17:20,19.0,23:00,12.0 ;; set MAX_NAME weekProfile Thu 12.0,08:30,12.0,12:00,11.5,12:05,12.0,15:35,11.5,17:20,19.0,23:00,12.0 ;; set MAX_NAME weekProfile Fri 12.0,08:30,12.0,12:00,11.5,12:05,12.0,15:35,11.5,17:20,19.0,23:00,12.0 ;;") ;; Log 3, "WP Urlaub aktiviert" ;;}\
}
-----------------------------------------------------------------------------------------------------------------
Danke west2107!
Das sieht ja interessant aus! Da wäre ich nicht so leicht draufgekommen.
Bringt mich wieder ein Stück mehr in FHEM rein. Werde ich mir sehr bald anschauen!
Gruß, Onurbi