Weekprofile: Unterschied zwischen den Versionen
(→Beispiel: Homematic Beispiel) |
K (EG_Bad_THERMOSTAT_Clima zu EG_Bad_THERMOSTAT_Climate) |
||
Zeile 45: | Zeile 45: | ||
:<code>define <name> weekprofile <device></code> | :<code>define <name> weekprofile <device></code> | ||
Beispiel: | Beispiel: | ||
:<code>define EG_Bad_WEEKPROFILE weekprofile | :<code>define EG_Bad_WEEKPROFILE weekprofile EG_Bad_THERMOSTAT_Climate</code> | ||
'''Hinweis:'''<br> | '''Hinweis:'''<br> | ||
Bei HomeMatic müssen die Kanäle "Clima" bzw. "_Climate" verwendet werden.<br><br> | Bei HomeMatic müssen die Kanäle "Clima" bzw. "_Climate" verwendet werden.<br><br> |
Version vom 17. Februar 2017, 21:33 Uhr
weekprofile | |
---|---|
Zweck / Funktion | |
Verwaltung von Wochenprofilen für Heizungssteuerung | |
Allgemein | |
Typ | Hilfsmodul |
Details | |
Dokumentation | EN / DE |
Support (Forum) | Frontends |
Modulname | 98_weekprofile.pm |
Ersteller | Risiko |
Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref! |
Das Modul weekprofile stellt Funktionen zur Verwaltung von Wochenprofilen\Wochenplänen für Heizkörperthermostate zur Verfügung. Aktuell werden folgenden Systeme unterstützt:
Es ist möglich, verschiedene Wochenprofile anzulegen, zu kopieren, zu ändern und zu löschen. Außerdem können die erstellten Profile den entsprechenden Devices zugewiesen werden.
Hinweis:
Bei HomeMatic müssen die Kanäle "Clima" bzw. "_Climate" verwendet werden.
Voraussetzung
Zum einwandfreien Betrieb des Moduls wird JSON benötigt. Dieses kann z.B. über folgendes installiert werden
sudo apt-get install libjson-pp-perl
FHEMWEB Widget
Zur Bedienung des Moduls existiert ein passendes widget für FHEMWEB.
Alle notwendigen Aufgaben wie bspw. Kopieren, Bearbeiten, Zuweisen, etc. können über die FHEMWEB Oberfläche erfolgen.
Ein direkte Verwendung der Befehle für get und set ist somit nicht zwingend erforderlich.
Betriebsarten
Das Modul besitzt 3 unterschiedliche Betriebsarten, die im Folgenden beschrieben werden. Obwohl auch Mischformen möglich sind, sollte man sich der Übersichtlichkeit halber für eine Betriebsart entscheiden.
Bei allen Änderungen sollte man immer bedenken, dass die Änderung an die entsprechenden Thermostaten übertragen werden müssen, was je nach Menge etwas Zeit in Anspruch nehmen kann.
Assoziiertes Master Gerät
Dieses ist der einfachste Betriebsmodus, bei dem jeder Definition genau ein Thermostat zugeordnet ist. D.h. entsprechend der Anzahl der Thermostaten, die man steuern möchte, benötigt man eine passende Anzahl von Weekprofile-Definitionen. Bei der Definition des Moduls wird das zu steuernde Thermostat direkt mit angegeben.
define <name> weekprofile <device>
Beispiel:
define EG_Bad_WEEKPROFILE weekprofile EG_Bad_THERMOSTAT_Climate
Hinweis:
Bei HomeMatic müssen die Kanäle "Clima" bzw. "_Climate" verwendet werden.
Bei der Definition wird automatisch ein Wochenplan mit dem Namen 'master' angelegt.
Der Wochenplan entspricht dem im Device hinterlegtem Profil.
Dieser spezielle Masterplan kann nicht gelöscht werden, da er immer dem aktuellen Profil im Device entspricht. Ändert man das Profil direkt über das Device, wird der Masterplan automatisch aktualisiert.
Wird der Masterplan über das Modul weekprofile geändert\gespeichert, wird das Profil automatisch zum assoziiertem Device übertragen.
Wird in dieser Betriebsart für einen Befehl kein spezielles Device angegeben, wird immer das assoziierte Device verwendet. So wird bspw. bei
set <name> send_to_device urlaub
das Profil 'urlaub' an das bei define angegebene Thermostat übertragen.
Funktionen des Wigets
Button | Funktion |
---|---|
Zahnräder | Beabeitungsmodus öffnen; Auf der dann angezeigten Seite kann über "-->" der Plan eines Tages auf einen anderen kopiert werden. |
'DropDown' | Profil für Ansicht/Bearbeitung auswählen |
'+' | Neues Profil durch Kopie erstellen |
'-' | Profil löschen |
'-->' | Profil an ein oder mehrere Thermostate übertragen, die nicht dem assoziierten Mastergerät entsprechen. Dabei bietet das Modul alle kompatiblen gefundenen Thermostaten automatisch zur Auswahl an. |
Standard Verwaltung
Diese Betriebsart ist für die einfache Verwaltung von Wochenplänen gedacht, welche dann an unterschiedliche Thermostate manuell übertragen werden können. Für diese Betriebsart sollte kein assoziiertes Master Gerät bei define angegeben werden.
define <name> weekprofile
In diesem Fall wird beim erstmaligen Anlegen ein Default-Profil mit dem Namen 'default' angelegt.
Dieses bildet die Grundlage zur Erstellung weiterer Pläne durch kopieren.
Existieren mindestens. 2 Profile, kann das Default-Profil gelöscht werden.
Die einzelnen Wochenpläne können mittels send_to_device
an ein oder mehrere Thermostate übertragen werden.
Funktionen des Wigets
Siehe Betriebsmodus assoziiertes Master Gerät.
Topics
Dieser Betriebsmodus erlaubt es mit Hilfe von Topics oder Kategorien wie bspw. (Urlaub, Sommer, Winter, Party, etc.) komplexeren Verwaltung von Wochenplänen zu realisieren.
Dieses Feature wird mittels dem Atribute useTopics
aktiviert.
Innerhalb eines Topics kann es mehrere Wochenpläne geben. Sinnvollerweise für jedes Thermostat ein Wochenplan.
Mit dem Befehl restore_topic
kann man dann zwischen unterschiedlichen Kategorien wechseln. Die Wochenpläne werden automatisch an die Thermostate übertragen. Dazu muss im Thermostat ein User-Attribut 'weekprofile' mit dem Namen des verbundenen Wochenplans hinterlegt sein.
Bei der Verwendung von Topics wird beim erstmaligen Anlegen automatisch die Topic 'default' mit den Default-Wochenprofil 'default' angelegt. In dieser Topic kann man beispielsweise Pläne ablegen, die bei mehreren Thermostaten oder anderen Kategorien verwendet werden sollen.
Wichtig:
Bei der Verwendung von Topics, besteht der Profilname immer aus Topicname:Planname
Wird kein Topicname angegeben, wird immer 'default' als Topicnamen verwendet.
Verwendung von Referenzen
Mittels Referenzierung kann man auf dieser Pläne verweisen und muss so nur einen Plan ändern, um gleich für eine Vielzahl von Thermostaten die Pläne zu ändern.
So könnte bspw. Sommer:Plan_WZ nur eine Referenz auf default:Fest_24h sein.
Existiert default:Fest_24h, wird der Verweis so angelegt:
set weekprf reference_profile default:Fest_24h Sommer:Plan_WZ
Referenzen können nicht bearbeitet werden. Im Beispiel wäre der Plan Sommer:Plan_WZ nicht bearbeitbar.
Für das Anlegen eines Wochenplans, der auf einen anderen referenziert, wählt man den Quellplan im Dropdown aus und erstellt dann einen neuen, indem man den entsprechenden Haken beim Erstellen aktiviert.
Funktionen des Wigets
Button | Funktion |
---|---|
Zahnräder | Beabeitungsmodus öffnen; Auf der dann angezeigten Seite kann über "-->" der Plan eines Tages auf einen anderen kopiert werden. |
'DropDown' | Profil für Ansicht/Bearbeitung/Referenzierung auswählen |
'+' | Neues Profil durch Kopie erstellen |
'-' | Profil löschen |
'T' | Topic aktiviert und die entsprechenden Wochenpläne an die Thermostaten übertragen. |
Beispiel
User-Attribut im Thermostat definieren:
MAX Thermostate:
define WT_Wohnzimmer MAX WallMountedThermostat 0d657f
attr WT_Wohnzimmer userattr weekprofile
attr WT_Wohnzimmer weekprofile Plan_WZ
HomeMatic Thermostate:
Fügen Sie ein HM-CC-RT-DN Funk-Heizkörperthermostat über hmPairForSec hinzu (Beispiel DeviceName HM_123456)
attr HM_123456_Clima userattr weekprofile
attr HM_123456_Clima weekprofile Plan_WZ
Weiter wird angenommen, dass es die Topics Winter und Sommer mit jeweils einem Wochenplan Namens 'Plan_WZ' im Modul 'weekprf' gibt.
define weekprf weekprofile
attr weekprf useTopics 1
Die Abfrage mittels get weekprf profile_names *
muss ergeben:
Winter:Plan_WZ,Sommer:Plan_WZ
Wechselt man nun mit set weekprf restore_topic Sommer
auf Sommer, wird der Plan Sommer:Plan_WZ an das Thermostat WT_Wohnzimmer übertragen.
Befehle und Attribute
Modul Befehle: set
Wochenprofile kopieren
Siehe Commandref
Wochenprofile löschen
Siehe Commandref
Wochenprofile an ein Device übertragen
Siehe Commandref
Wochenprofile per Datei konfigurieren
Die Wochenprofile werden mit dem Befehl
set <name> profile_data <profilename> <json data>
angelegt/geändert (überschrieben). Die eigentlichen Daten müssen dabei in einer JSON Datenstruktur angegeben werden.
Für jeden Tag müssen die Schaltzeiten und die Solltemperaturen in Form von Listen angegeben werden. Die Datenstruktur sieht bspw. wie folgt aus:
{ "Sun": { "time": ["06:00","22:00","24:00"], "temp": ["20.0","22.0","20.0"] }, "Sat": { "time": ["06:00","22:00","24:00"], "temp": ["20.0","22.0","20.0"] }, "Thu": { "time": ["06:00","22:00","24:00"], "temp": ["20.0","22.0","20.0"] }, "Fri": { "time": ["06:00","22:00","24:00"], "temp": ["20.0","22.0","20.0"] }, "Tue": { "time": ["06:00","22:00","24:00"], "temp": ["20.0","22.0","20.0"] }, "Wed": { "time": ["06:00","22:00","24:00"], "temp": ["20.0","22.0","20.0"] }, "Mon": { "time": ["06:00","22:00","24:00"], "temp": ["20.0","22.0","20.0"] } }
Es handelt sich dabei um eine unsortierte Liste von "Tages-Objekten", die wiederum eine unsortierte Liste von Schlüssel-Werte Paaren enthält. Die beiden verwendeten Schlüssel "time" und "temp" für Zeit und Temperatur verweisen jeweils auf eine sortierte Liste mit Werten.
Der Schlüssel "time" enthält die Liste der gewünschten Zeitpunkte, zu denen ein Temperaturwechsel stattfinden soll. Die Zeitangaben müssen im Format "hh:mm" angegeben werden. Falls für den ganzen Tag nur eine Temperatur verwendet werden soll, so ist als Zeitpunkt "24:00" anzugeben.
Der Schlüssel "temp" enthält die Temperaturen, die zu den in "time" hinterlegten Schaltzeitpunkten eingestellt werden sollen. Dabei entspricht die Reihenfolge der Temperaturen der Reihenfolge der Zeitpunkte in "time".
Zur Übergabe an FHEM sollte die JSON Struktur von sämtlichen Formatierungen (Zeilenumbrüche, Tabs, überflüssige Leerzeichen) bereinigt werden, so dass ein einzeiliger String entsteht. Für das oben angegebene Beispiel würde das dann so aussehen:
{"Sun":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Sat":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Thu":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Fri":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Tue":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Wed":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Mon":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]}}
Referenzprofil konfigurieren
Dieser Befehl kommt nur zum Tragen, wenn per Attribut useTopics die Verwendung von Topics aktiviert wurde.
Siehe Commandref.
Topic wiederherstellen
Dieser Befehl kommt nur zum Tragen, wenn per Attribut useTopics die Verwendung von Topics aktiviert wurde.
Siehe Commandref.
Modul Befehle: get
Wochenprofile exportieren
Siehe Commandref
Wochenprofilnamen exportieren
Siehe Commandref
Wochenprofil-Refrenzen exportieren
Siehe Commandref
Modul Attribute
Die meisten Attribute sind selbsterklärend. Daher wird an dieser Stelle zumeist auf die Informationen in der Commandref verwiesen.
Namen der Wochentage festlegen
widgetWeekdays: Siehe Commandref
Anzeigeart: Anzahl der Spalten
widgetEditDaysInRow: Siehe Commandref
Anzeigeart: editieren auf neuer Seite
widgetEditOnNewPage: Siehe Commandref
Pfad zur Konfigurationsdatei
configFile: Siehe Commandref
Verwendung von Topics
useTopics: Aktiviert den Betriebsmodus: Topics
bekannte Probleme
- Derzeit (Version: 10924) können keine Leerzeichen oder Umlaute verwendet werden. Leerzeichen werden bei der Eingabe abgefangen. Hat man versehentlich doch Umlaute verwendet, müssen in der Datei ./log/weekprofile-<name>.cfg die entsprechenden Zeilen manuell gelöscht/umbenennt werden und danach ein rereadcfg ausführt werden.
- Speichert man einen Wochenplan, wird die Änderung erst nach einem reload der Seite angezeigt.
Links
- Thread im FHEM-Forum
- JSON-Editor für eine einfache Bearbeitung der JSON Daten