NEWS
[Vorlage] Heizungsthermostatsteuerung 2.1 - Script
-
Hi,
Dieses Script dient zur Steuerung von Homematic und Nicht-Homematic Heizungsthermostaten inkl Fußbodenheizungen mit Ihren Besonderheiten bei der Steuerung.
Das Script liegt jetzt in der Version 2.1 vor.
Seit der ersten Version des Heizungsscripts im April 2017 hat sich viel getan. Vieles unter der Haube.
Das Script wird auch vielfach erfolgreich eingesetzt für nicht HM-Geräte, die über FHEM in ioBroker angesteuert werden oder auch direkt über ioBroker adapter wie ZWAVE, MAX etc. HM-IP Geräte funktionieren mitterweile ebenso gut wie native Homematic Geräte - wired oder Funk.
Ihr braucht nicht den gesamten Thread durchzulesen. Vielmehr versuche ich einigermassen up to date mit der Dokumentation zu sein.
Wichtige Dinge stehen also hier im post.
Die Version 2.1 wurde ausschliesslich mit Subscriptions getestet s ( was bedeutet, dass es nur noch läuft, wenn es eine Änderung in Bedingungen gibt oder der nächste Wochenplan-Slot ansteht.) Wenn also jemand noch CRON nutzt, dann bitte melden. Evt. Fehler schaue ich mir dann dediziert an.
Ab hier werde ich auch alternative Views anbieten. Der erste View enthält 3 Profile (Danke an Kugelkopf für die Vorlage ) (Wochenplanung zum Anpassen innerhalb des Views).
Da dieser View aber sehr groß ist und nicht jeder mit Profilen arbeiten möchte habe ich den gleichen View mit nur einem Profil hochgeladen. Dies bedeutet 160 Widgets weniger aber auch weniger Komfort im Umgang mit Profilen.
Generell könnt Ihr euch die Views gestalten wie ihr wollt. Es gibt keine Script oder CSS Codings.
Was gibt es also Neues ?
2 Views ( einer mit 3 Profilen und einer mit einem Profil)
Neu zur Version 2.1
- Manuelle Aenderungen sind überarbeitet.
-
Sporadisch auftauchende manuelle Temperaturen sollten jetzt gefixt sein
-
Manuelle Aenderungen bleiben erhalten nach Aenderung von Profil/schedule, SoftBoost etc. bis zum geplanten Ablauf
-
ICLA Aktivierung jetzt über die Views (nicht mehr ueber das Script
-
Profil Selektion über ICAL komplett überarbeitet
-
Globale und Raumprofile haben jetzt eine Subscription
-
Mehrere gleichzeitige Profile im Google Kalender:Jetzt wird immer die höchste Profilnummer gewählt (vorher war es immer 1)
-
ICAL Selektion läesst sich pro Raum ausschalten. Zwei Vorteile
-
Event Profil Nummer im View braucht es nicht mehr, da jetzt alles über das aktivie Profil gesteuert wird
-
Räume lassen sich von der global profil auswahl ausschliessen
-
Es wird nicht immer wieder auf die ICAL Selektion zurückgestellt. Pflege alternativer Profile ist somit möglich mit anschliessender neuer aktivierung des Profils
-
Ein neuer View (Herzlichen Dank an Kugelkopf für die Alternative ProfilSelektion innerhalb des Views) mit alternativer Profilselektion (max 3)
-
SoftBoost jetzt möglich um über eine einstellbare Zeit einen Raum aufzuheizen (Max Temp)
-
Neue Views
-
View jetzt mit zusätzlichen Feldern für ICAL Aktivierung und Softboost
-
View mit 3 Profilen zum umschalten
-
Alternativer View mit 1 Profil - dafür kleiner (weniger Widgets)
-
Die Installation der Views hat sich geändert und funktioniert jetzt über Widget Import (schneller)
-
Dokumentation
-
FAQs erweitert(z.B. wie ICAL aktiviert wird)
-
View Installation - Beschreibung wie der View erstellt wird - (jetzt Widget Import)
Hier ist nochmal der komplette Funktionsumfang (wie in der Doku dokumentiert
! ````
- Unterstützung von verschiedenen Thermostaten o Alte HM-Wandthermostate
! o Neue HM-Thermostate (Wandthermostate und Heizkörperthermostate) o Homematic IP (Wand- und Heizkörperthermostate)
! o Unterstützung von Nicht-Homematic Thermostaten
! - Absenkung der Heizungsthermostate auf die „Fenster-Offen“-Temperatur
! - eingebundene Thermostate reagieren wie bei native Homematic mit Gruppenbildung. Manuelle Anpassungen werden erkannt und synchronisiert
! - Wochenprogramm mit bis zu 6 Zeiten/Temperaturen je Tag (Montag – Sonntag) und ein separates Feiertags-Programm (somit 8 Zeilen je Woche mit je 6 Zeiten/Temperaturvorgaben)
! - Feiertagszeile kann auch für Urlaub bei Anwesenheit genutzt werden)
! - Einfacher Verweis auf den Vortag („wie Vortag“- Funktion)
! - Möglichkeit der Planung mit bis zu 9 Profilen
! Dient z.B. für Schichtplanung oder dem einfachen Umschalten bei Ferienhäusern, etc)
! o Wochenprogramm je Profil
! o Diverse Profilparameter wie (Grad Celsius Absenkung oder Anhebung von Temperaturen und Definition einer Mindesttemperatur)
! o Aktivierung / Deaktivierung von Profilen manuell oder über Google Kalender
! - Verwendung von Raumparameter für
! o die Eingaben einer manuellen Temperatur
! o die Vorhaltezeit der manuellen Temperatur in Minuten
! o die Anzeige der Gültigkeit bis für die manuelle Temperatur o Reset der manuellen Temperatur
! o das automatische Setzen des manuellen Modus! - Verwendung von globalen Parametern (manuell oder über Google Kalender), die für alle Räume und Profile gleich gültig sind für da
! o An/Abwesenheit, (Absenkung bei Abwesenheit)
! o Urlaub, (Absenkung bei Urlaub)
! o Party, (Absenkung bei Party)
! o Gäste (Anhebung bei Gäste)
! - Für die o.g. globalen Parameter können je Raum-Profil Temperaturanpassungen in Grad Celsius vorgenommen werden. Diese können negativ/positiv oder null sein.
! - Lieferung eines Views der rel. schnell für weitere Räume kopiert werden kann. Der View ist so aufgebaut, dass (fast) alle Eingaben per Touch bedient werden können. Der View beinhaltet für Raum und Profil das Wochenprogramm, die Profilparameter, die Raumparameter und die globalen Parameter
! - Automatisierungen
! o Findung eines Profils durch z.B. Google Kalender über ICAL
! z.B. für Schichtpläne durch Integration mit z.B. Google Kalender (ICAL)
! o Findung von Feiertagen über den Feiertagsadapter oder alternativ ICAL
! o Findung von Temperaturparameter (z.B. Gäste, Party, Urlaub Abwesend, Urlaub Anwesend etc.) durch Integration mit z.B. Google Kalender (ICAL)
! o Automatische Abwesenheitsabsenkung falls gewünscht (Integration mit einer An/Abwesenheitssteuerung)
! - Automatische Temperaturanpassungen können nicht unter eine je Raum/Profil bestimmbare Mindesttemperatur sinken
! - Automatische Einstellung des manuellen (MANU) Modus (für die neuen Thermostate)
! - Handling von manuellen Änderungen (z.B. am Thermostat oder über Alexa)
! o Erkennung von manuell eingestellten Temperaturen.
! o Einstellung der Vorhaltedauer von manuell eingestellten Temperaturen je Raum (in Minuten)
! o Darstellung der Zeit bis zu der die manuelle Temperatur gültig ist (Datum/Uhrzeit)
! o Sofortige Erkennung von Temperaturanpassung am Thermostat durch Subscription
! o Funktioniert auch ohne Direktverknüpfung
! - Verschlußsensoren
! o Temperaturabsenkung auch für nicht direkt verknüpfte Geräte
! o Sofortige Erkennung von „Verschluss offen" durch Subscription- 3-stufiges Logging
! o Stufe 1 – Speicherung der letzten Temperaturfindung in Datenpunkte und Anzeige im View
! o Stufe 2 – erweitertes online-Logging (einstellbar)
! o Stufe 3 – Externes Logging in Excel Format (einstellbar)
! - Steuerung von separaten Wohneinheiten (z.B. Einliegerwohnung und Hauptwohnung) mit unabhängigen Parametern. (durch Kopie des Programmes und weiteren Einstellungen zur Separierung )
! Neu ab 2.0
! - Programm Trigger: Das Programm kann jetzt automatisiert bei Bedarf gestartet werden. Die Trigger zum Start befinden sich auf globaler/Profil oder Raumebene. Wenn beispielsweise ein ICAL Event auf „true“ gesetzt wird“, dann werden für alle Räume Temperaturen neu gerechnet.
Somit wird nur bei Bedarf und auch nur für relevante Räume ein Programmlauf notwendig. Das spart Ressourcen und ist auch intuitiver im Vergleich zum Schedule, der z.B. alle 2 Minuten läuft. Es kann aber auch weiterhin mit Schedule gearbeitet werden.
! - Handling von manuellen Änderungen erweitert durch Zurücksetzen der manuellen Temperatur bei Schedule Wechsel. Die bisherige Funktionalität ist dabei erhalten geblieben (Wechsel nach einer einzugebenden Anzahl Minuten oder Verhinderung von manuellen Temperaturen )
! - Ausnahmeliste für Sensoren: Sensoren können durch eine Tabelle von der Steuerung ausgeschlossen werden. Somit ist eine Änderung der Gewerke bei zusätzlichen Sensoren im Raum nicht notwendig. (z.B. wenn ein Sensor zur Alarmsteuerung (Innenhaut) im Einsatz ist aber nicht zur Heizungssteuerung)
! - Neuer Datenpunkt „Source_Next_Temp“ : Durch diesen Datenpunkt wird die nächste anzusteuernde Temperatur vorausgesagt und gespeichert. Damit kann z.B. eine Fußbodenheizung, die bauartbedingt träge reagiert, im Vorfeld eingesteuert werden. Die Steuerung der Temperaturen erfolgt dabei über das Setzen einer manuellen Temperatur in Verbindung mit dem Rücksetzen „zum Wechsel des Schedules“. Scripte für diese Steuerung werden separat zur Verfügung gestellt. Siehe Link im Heizungsscript Thread.
! - Datenpunkt „Source_last_Program_Run“: Dieser Datenpunkt zeigt auf globaler Ebene den letzten Programmlauf an. Nun, da nur bei Bedarf ein Programmlauf stattfindet (Trigger basiert), wird der letzte Programmlauf auch auf Raumebene geführt.! - Neuer View: Es wird ein neuer View zur Verfügung gestellt. Der View zeigt wie gewohnt die verschiedenen Ebenen der Datenstruktur (Global/Raum/Profil) und biete auch die mehr Möglichkeiten für Geräte spezifische Informationen. (z.B. Voltage, Boost. etc.)
! - Mehr Gerätevoreinstellungen: In der Konfiguration werden mehr Beispielkonfigurationen gelistet für Homematic Geräte, IP-Geräte und nicht Homematic Geräten
! Neu ab 2.1
! - Manuelle Aenderungen sind überarbeitet.
+ Sporadisch auftauchende manuelle Temperaturen sollten jetzt gefixt sein
+ Manuelle Aenderungen bleiben erhalten nach Aenderung von Profil/schedule, SoftBoost etc. bis zum geplanten Ablauf- ICLA Aktivierung jetzt über die Views (nicht mehr ueber das Script
- Profil Selektion über ICAL komplett überarbeitet
- Globale und Raumprofile haben jetzt eine Subscription
- Mehrere gleichzeitige Profile im Google Kalender:Jetzt wird immer die höchste Profilnummer gewählt (vorher war es immer 1)
- ICAL Selektion läesst sich pro Raum ausschalten. Zwei Vorteile
- Event Profil Nummer im View braucht es nicht mehr, da jetzt alles über das aktivie Profil gesteuert wird
- Räume lassen sich von der global profil auswahl ausschliessen
- Es wird nicht immer wieder auf die ICAL Selektion zurückgestellt. Pflege alternativer Profile ist somit möglich mit anschliessender neuer aktivierung des Profils
- Ein neuer View (Herzlichen Dank an Kugelkopf für die Alternative ProfilSelektion innerhalb des Views) mit alternativer Profilselektion (max 3)
- SoftBoost jetzt möglich um über eine einstellbare Zeit einen Raum aufzuheizen (Max Temp)
- Neue Views
- View jetzt mit zusätzlichen Feldern für ICAL Aktivierung und Softboost
- View mit 3 Profilen zum umschalten
- Alternativer View mit 1 Profil - dafür kleiner (weniger Widgets)
- Die Installation der Views hat sich geändert und funktioniert jetzt über Widget Import (schneller)
- Dokumentation
- FAQs erweitert(z.B. wie ICAL aktiviert wird)
- View Installation - Beschreibung wie der View erstellt wird - (jetzt Widget Import)
! ````
Viel Spass mit dieser Lösung.
Looxer
Hinweis Subscriptions Funktion:
Die Aenderung eines globalen Parameters führt in vielen Fällen zu Anpassungen der SollTemperaturen und damit zu erhöhten Funkaktivitäten.
Ich selber arbeite mit 15 mit der CCU verbundenen Thermostaten (es sind mehr, viele sind aber mit Wandthermostaten verknüpft und belasten somit nicht den CCU Dutycycle) und komme bei -4 maligen Aenderungen auf einen um 15 % erhöhten Duty Cycle. Es gibt aber viele Abhängigkeiten. Ich möchte also darauf aufmerksam machen, die globalen Parameter nicht uebermaessig oft innerhalb von wenigen Minuten zu ändern. Das gibt es im Prinzip auch bei der Schedule Funktion. Allerdings bei einem update alle paar Minuten ist das eher unkritisch.
Hinweise, wenn das Programm Thermostate/Sensoren nicht erkennt:
Falls die Thermostate/Sensoren nicht eingelesen werden, dann gibt es vermutlich Ungereimtheiten beim SetUp der Räume/Gewerke. Es empfiehlt sich folgende Vorgehensweise:
1. Überprüfen, dass die Thermostate / Sensoren in der CCU wirklich den richtigen Gewerken und Räumen zugeordnet sind
2. Überprüfen, dass in den ioBroker Aufzählungen (rooms und functions) die Räume und Gewerke gelistet sind. Irgendwelche $functions oder $rooms sollten nicht auftauchen.
3. Bei Ungereimtheiten in den Aufzählungen könnt ihr versuchen manuell zu korrigieren. Wenn bei den Aufzählungen nur CCU Räume und Gewerke vorhanden sind, dann empfiehlt sich einmal die rooms und functions komplett zu loeschen.
4. nachdem geändert wurde muss der REGA adapter und auch die HM-rpc Adapter neu geladen werden ( bei den Instanzen). Bitte zuerst den REGA Adapter starten und mindestens 30 Sekunden warten. Dann erst die RPC Adapter starten. Falls das nicht klappt bitte ioBroker neu starten
Open Issues:
- Im Zusammenhang mit "View in Widget " widgets und auch container widgets gibt es drei Fehler im VIS, die ich hier und auch in Trello reportet habe. Ich hoffe auf einen Fix. Leider hat sich da aber noch nicht viel getan:
http://forum.iobroker.net/viewtopic.php … =60#p84526
-
Es gibt noch ein kleines Problem mit den manuellen Temperaturen: Hin und wieder wird eine manuelle Temperatur (im Widget) nicht angenommen und muss nochmal eingestellt werden. Dies passiert aber nicht immer. Ich schaue mir das noch an
-
Ich habe es noch nicht geschafft die Dokumention auf den Stand 2.1 zu heben. Aber dafür gibt es die FAQ die einen Abschnitt über ICAL beinhalten und es gibt auch die Installationshinweise der Views. In nächster Zeit werde ich auch die Doku auf 2.1 bringen
Und jetzt Script, View, Docu:
View1 mit 1 Profil
View2 mit 3 Profilen
Installationsanleitung Schritt für Schritt wie die Views erstellt werden
Docu:
FAQs (unbedingt lesen )
Das Script
-
Ich bin begeistert. Hut ab. Vielen Dank für eure Arbeit. Das neue Script und der neue View wird heute noch eingesetzt.
Gesendet von meinem Redmi Note 4 mit Tapatalk
-
Erstmal auch von mir vielen Dank für Eure Mühen. Ich selbst setze eine CCU2 mit einigen Heizkörperthermostaten ein und hätte eine Frage - bitte um Hinweis falls deplatziert:
Wenn ich das Script nutzen möchte, wie deaktiviere ich die Zeitplansteuerung in der CCU für die Thermostate komplett?
-
Ich habe bei mir einfach in den Settings alle Zeiten gelöscht womit nur eine 0:00-24:00 Einstellung übrig war und da habe ich meine Minimaltemperatur reingeschrieben.
Das Skript versucht das Thermostat immer auf "MANU"-Modus zu setzen und zu halten.
-
So, hier die versprochenen Zusatzdinge für Fussbodenheizungen:
1.) Ventilsteuerung mit PWM-Ansatz für Fussbodenheizungen/IR-Panele o.ä.
http://forum.iobroker.net/viewtopic.php?f=21&t=10111
Das Skript ist grundsätzlich erst einmal unabhängig vom Heizungsthermostatskript, aber basiert auf dem was von dem Skript im Thermostat als Zieltemperatur gesetzt wird
2.) Aufheiz-Zeiterfassung und Voraussteuerung für Heizungen
http://forum.iobroker.net/viewtopic.php?f=21&t=10112
Diese Skripte erledigen die messung der Ausfheizzeit und dann, unter Nutzung einiger States des Heizungsthermostatskripts, erledigt die Voraussteuerung.
Viel Spass und bin gespannt auf Euer Feedback.
-
Hi,
hat denn schon mal jemand getestet ?
Ich würde gerne wissen wie eure Erfahrung mit der Umstellung oder Neuinstallation ist und bin sehr dankbar für Feedback.
vG Looxer
-
Sobald ich einen freien Moment bekomme, hänge ich mich dran. Homematic CCU2 + Aktoren hier.
-
Wie versprochen gestern umgestellt und läuft ohne Probleme. Meine Frau hat sich heute früh auch schon beschwert das es im Bad kalt war (Zeiten vom neuen View im Bad nicht angepasst [emoji23])
Gesendet von meinem Redmi Note 4 mit Tapatalk
-
Habe es auch von einer v0.8x umgestellt (gestern), aber meine alten Views behalten (sind alle an mein Tablet angepasst).
Bisher hat alles sauber funktioniert. Die vorhandenen Daten (Profil, Zeiten und Temperaturen, usw.) haben alle überlebt und die Heizung tut bisher, was sie soll.
Scheint also alles gut zu funktionieren.
Gruß,
Eric
Von unterwegs getippert
-
super, danke euch.
Dann ist mal die erste Hürde genommen.
Ich nehme mal an, dass ihr mit CRON = 0 arbeitet. Das ist eine groessere Umstellung.
Meine Tests bezogen sich auch überwiegend darauf.
vG Looxer
-
Hallo, danke an looxer und apollon77 für die neue Version, enthält wirklich ein paar tolle Neuerungen, auch das neue Design der VIS find ich klasse.
Nur noch ne kurze Anmerkung zu den HMIP Geräten.Weiß jetzt nicht welche relevanz der Datenpunkt Check Manu-Mode im Script genau hat aber er ist hier nicht ganz korrekt.
Hier müßte der Datenpunkt Set_Point_Mode hinkommen,
// 0.RPC-Pfad 1.GeraeteType 2\. Beschreibung, 3\. Type 4.DP-SollTemp 5.nicht verwendet ID 6.DP MANU/AUTO Schaltung 7.Steuerung DV 8\. IstTemp 9-Check-MANU-Mode 10-Ventilstellung wenn nicht Heizperiode 11\. Delay nach Verschluss zu ThermostatTypeTab[0] = ['hm-rpc.0.', 'HM-TC-IT-WM-W-EU', 'Wandthermostat (neu)' ,'WT', '2.SET_TEMPERATURE' , false, '2.MANU_MODE', true, '1.TEMPERATURE', '2.CONTROL_MODE', 12, 0]; ThermostatTypeTab[1] = ['hm-rpc.0.', 'HM-CC-TC' , 'Wandthermostat (alt)' ,'WT', '2.SETPOINT' , false, false, false, '1.TEMPERATURE', false, 12, 0]; ThermostatTypeTab[2] = ['hm-rpc.0.', 'HM-CC-RT-DN' , 'Heizkoerperthermostat(neu)' ,'HT', '4.SET_TEMPERATURE' , false, '4.MANU_MODE', true, '4.ACTUAL_TEMPERATURE', '4.CONTROL_MODE', 12, 0]; ThermostatTypeTab[3] = ['hm-rpc.1.', 'HmIP-eTRV' , 'Heizkoerperthermostat(HMIP)','IPHT', '1.SET_POINT_TEMPERATURE', false, '1.CONTROL_MODE', false, '1.ACTUAL_TEMPERATURE', '1.SET_POINT_MODE', 12, 0]; ThermostatTypeTab[4] = ['hm-rpc.1.', 'HmIP-eTRV-2' , 'Heizkoerperthermostat(HMIP)','IPHT', '1.SET_POINT_TEMPERATURE', false, '1.CONTROL_MODE', false, '1.ACTUAL_TEMPERATURE', '1.SET_POINT_MODE', 12, 0]; ThermostatTypeTab[5] = ['hm-rpc.1.', 'HmIP-WTH' , 'Wandthermostat(HMIP)' ,'IPWT', '1.SET_POINT_TEMPERATURE', false, '1.CONTROL_MODE', true, '1.ACTUAL_TEMPERATURE', '1.SET_POINT_MODE', 12, 0]; ThermostatTypeTab[6] = ['hm-rpc.1.', 'HmIP-WTH-2' , 'Wandthermostat(HMIP)' ,'IPWT', '1.SET_POINT_TEMPERATURE', false, '1.CONTROL_MODE', true, '1.ACTUAL_TEMPERATURE', '1.SET_POINT_MODE', 12, 0]; ThermostatTypeTab[7] = ['hm-rpc.1.', 'HmIP-STH' , 'Wandthermostat(HMIP)' ,'IPWT', '1.SET_POINT_TEMPERATURE', false, '1.CONTROL_MODE', true, '1.ACTUAL_TEMPERATURE', '1.SET_POINT_MODE', 12, 0]; ThermostatTypeTab[8] = ['hm-rpc.1.', 'HmIP-STHD' , 'Wandthermostat(HMIP)' ,'IPWT', '1.SET_POINT_TEMPERATURE', false, '1.CONTROL_MODE', true, '1.ACTUAL_TEMPERATURE', '1.SET_POINT_MODE', 12, 0];
Und dann habe ich noch ein kleines Problem mit der Anwesenheitssteuerung. Die Abwesenheit wird anscheint korrekt erkannt und die Temperatur entsprechend abgesenkt. Allerdings gibts dann Probleme beim zurück kommen. Hier wird zwar in den Datenpunkten der Anwesenheitsteuerung und auch in den Globalparametern der Heizungsteuerung auf true umgestellt. Es zeigt auch dementsprechend in der VIS Anwesend an. Allerdings steht in den Source_Global_Parameter der Räume immer noch die Abwesenheit als Faktor an und die Temperatur bleibt weiterhin abgesenkt. Hast du eine Idee woher das kommen kann??
Gruss Phil
-
Hi Phil,
vielen Dank fürs Feedback. Habs mir angesehen.
1. Manu Mode HM-IP Geräte. Also ich habe das mit einem Wandthermostat getestet und gerade verifiziert.
Es geht NUR über ControlMode. Andere Geräte habe ich aber nicht getestet. Der Datenpunkt CHECK_MANU_MODE ist der Datenpunkt der ein update erhält um auf den MANU mode zu stellen. Ist also wichtig.
2. Anwesen-/Abwesenheit.
Konnte ich nachvollziehen. Da gibt es noch ein Problem bei den Subscriptions. Ich weiss schon was gemacht werden muss.
vG Looxer
-
Allerdings steht in den Source_Global_Parameter der Räume immer noch die Abwesenheit als Faktor an und die Temperatur bleibt weiterhin abgesenkt. Hast du eine Idee woher das kommen kann?? `
Hi Phil,
könntest du folgenden Fix testen ? Wäre super.
wie gesagt zum Thema ControlMode. Das kann ich nicht bestätigen. Hast du das entsprechend getestet ?
vG Looxer
// Anwesenheitsflag synchronisieren if (UseAnwesenheitserkennung) { if (getState(StateAnwesenheitFunction).val !== getState(StateAnwesenheit).val ) { // Feiertagsflag setzen // setOwnState(StateAnwesenheit, getState(StateAnwesenheitFunction).val); setState(StateAnwesenheit, getState(StateAnwesenheitFunction).val); globalChange = true; } }
-
Zu Punkt 1.
Ok dann habe ich den Datenpunkt falsch interpretiert. Ich dachte hier wird überprüft auf was für einem Modus (Auto/Manu) das Gerät gerade läuft.
Das zeigt er bei mir nämlich nur über den Set_Point_Mode an.
Das ist mir bei der Visu aufgefallen, als ich hier die Verknüpfung zum Anzeigen des aktuellen Modus auf Control_Mode gestellt habe hat er mir hier immer Auto angezeigt obwohl das Gerät im Manu war. Der Control_Mode ist wohl nur zum schreiben einer Änderung, zeigt aber nicht immer den aktuellen Status an.
Punkt 2
Hab die Änderung gerade getestet und sie funktioniert, danke für den schnellen Fix.
-
Interessanter Ansatz und eine schöne Lösung.
Da ich ein Freund von im Notfall autark laufenden Systemen bin: wäre es nicht in einer zukünftigen version ein Ansatz, die Daten, welche für den Thermostaten eingestellt sind, via putParamset direkt in den Thermostaten zu schreiben. bzw dann auch via getParamset aus dem Thermostaten auszulesen
gruss, Black
-
Hi,
muss ich mir mal ansehen.
Duty Cycle maessig kann man da nicht viele Uebertragungen machen.
Und würde auch nur bei HM gehen. Es gibt also ein paar "Aber" dabei
Hast du den JS Code zur Übertragung ?
vG Looxer
-
geht über das xmlrpc object, ersatzweise über tcl.
wobei wenn du mehrere paramater im mastersatz umschreiben willst nehm ich das tcl script.
ein einzelner wert im Master Satz mache ich so:
// Konstanten für CCU Push var http = require('http'); var path = "/blabla.exe"; function setCCUscript (sDevice,wochenprog) { var data = 'object o1= devices.Get("' + sDevice + '");'; data +='string s2="";'; data +='if (o1) {'; data += 'xmlrpc.PutParamset (o1.Interface(), o1.Address(), "MASTER", "WEEK_PROGRAM_POINTER", '+ wochenprog.toString () +'); s2="SET";'; data += '} else { s2 = "NO DEVICE"; }'; return data } function setPushVar (data) { var options = { host: getObject('system.adapter.hm-rpc.0').native.homematicAddress, port: 8181, path: path, method: 'POST', headers: { 'User-Agent' : 'Mozilla/5.0', 'Content-Type': 'text/plain', 'Content-Length': data.length, } }; return options; } function httpPost (options,data) { var req = http.request(options, function(res) { var body=''; res.on('data', function(d) { body += d.toString (); }); res.on('end', function() { }); }); req.on('error', function(e) { log('ERROR: ' + e.message,"warn"); }); (data ? req.write(data) : log("Daten: keine Daten angegeben")); req.end(); } // Bei Änderung von Wochenprogramm Küche Push senden an CCU2 on ({id: "javascript.0.WEEKPROG.KUECHE", change: 'ne'}, function(obj) { var script = setCCUscript ("AI_KUECHE_TH",obj.state.val); httpPost (setPushVar (script),script); log ("Ändern Küche Wochenprog auf Programm " + obj.state.val); });
mit mehren parametern zugleich kennich nur die möglichkeit über die tcl api. ich benutz da ein etwas modifiziertes script:
`#!/bin/tclsh # # Aufruf für ein putParamset # Abgewandelte Form: ein oder mehrere parameter Möglich # ===================================================== # Black in November 2016 # # tclsh setparam <addresse> <paramset> <struct parameter=""> # z.B. # tclsh setparam GEQ004711 MASTER "{MODE_TEMPERATUR_REGULATOR {int 2}}" # adresse IMMER die Device Addy angeben, nie ein Channel, sonst tuts nicht # Der Parameter MUSS in dieser version ein STRUCT sein # heist "{par1 {Datatyp1 value1}{par2 {Datatyp2 value2}"... par3 bis parn in logischer folge # Datatyp bool, int , float, string load tclrpc.so set cmd [lindex $argv 2] puts $cmd #set cmd "{BACKLIGHT_ON_TIME {int 10}} {ENDTIME_SATURDAY_1 {int 440}}" xmlrpc http://127.0.0.1:2001/ putParamset ] ] </struct></paramset></addresse>` gruss, Black
-
Zuerst einmal gibt es beim hm-rpc Adapter schon ein issue das grundsätzlich einzubauen, von daher würde ich da jetzt keine sonderlösungen bauen.
Weiterhin wäre das einige was vllt gibt wäre den grundplan zu übertragen. Ob hm aber so viele schaltzeiten kann weiß ich nicht. Und ja Duty Cycle könnte bei einer Änderungs-Session interessant werden. Und es macht auch nur Sinn wenn alle aktoren bzw stellventile direktverknüpft sind … hm ...
-
Da ich ein Freund von im Notfall autark laufenden Systemen bin: wäre es nicht in einer zukünftigen version ein Ansatz, die Daten, welche für den Thermostaten eingestellt sind, via putParamset direkt in den Thermostaten zu schreiben. bzw dann auch via getParamset aus dem Thermostaten auszulesen `
Hi,
ich habe mich zwischenzeitlich intensiver mit dem Thema befasst.
Deine vorgeschlagene Lösung der Anforderung passt meiner Meinung nach nicht zum Konzept des Scriptes. Das Script soll helfen zu automatisieren, z.B. durch Kalendereintragungen, Abwesenheit/Anwesenheit Temperaturen, automatisierte Profilumschaltungen (Schichtarbeit), Feiertage.
All dies wird nicht oder nur ansatzweise von den HM Profilen unterstützt. Wie schon in der ersten Antwort geschrieben würde auch eine ständige Anpassung der Profile der Thermostate zu Problemen mit dem DC führen.
Um es kurz zu sagen. Das Script ersetzt nicht die GUI der Homematic sondern folgt einer erweiterten Logik
ABER
es gibt einen Ansatzpunkt und der beruht darauf, die Thermostate im Automatik Modus laufen zu lassen. Demnach würden sie für den Fall eines Systemproblems ihr Programm abspulen.
Hierfür muss zunächst für die Räume wo es relevant ist "erzwinge manuell Mode" ausgeschaltet werden (Raumprofil).
1. Gültigkeit in Minuten
Wenn die Gültigkeit in Minuten auf einen negativen Wert gesetzt ist (z.B. -1), dann werden alle manuellen Aenderungen (inkl des Thermostates sofort zurückgesetzt) Mit anderen Worten: Das Thermostat schaltet im Auto modus zum definierten Schaltpunkt und wird dann sofort wieder auf die momentan geplante SollTemp des Scriptes zurückgesetzt.
Nachteile: keine Manuellen Aenderungen am Thermostat möglich. Das kann aber durch andere Elemente Wettgemacht werden.
Es gibt hierbei auch etwas erhöhten Funkverkehr, weil ja das Script auf jeden Schaltpunkt des Thermostates reagiert.
ACHTUNG: beim Testen dieser Lösung ist mir noch ein Fehler aufgefallen, den ich für die nächste Version gefixt haben.
Ich kann aber bei Bedarf eine Zwischenversion per PN senden.
2. Nur zwei Homematic Schaltpunkte pro Tag und synch mit Script Schaltpunkten
Beispiel:
-
Homematic Schaltpunkt Morgens 6:00 auf 20 Grad und Abends 22:00 auf 18 Grad
-
Script Schaltpunkt Morgens 06:01 erster Synch Schaltpunkt und Abends 22:01 letzter Synch Schaltpunkt
Wenn die Einstellungen so gemacht werden, kann zu allen anderen Zeit beliebig geplant oder manuell geändert werdn.
Im Falle eines SystemDowns würde Morgens auf Tagestemp und Nachts auf AbsenkTemp geschaltet werden
Nachteil: Wenn innerhalb des Zeitraumes ein systemDown passiert wird die letzte Temperatur bis zum nächsten Auto Schaltpunkt gehalten
Ich sehe die Anpassungen für den Fallback auf der Homematic Seite eher als manuellen Aufwand, weil das ja nur einmalig passieren muss.
vG Looxer
-
-
Bzgl. Ausfall ioBroker, usw. habe ich bei mir zwei zusätzliche Schienen eingebaut:
Alle Heizungsprogramme (Notbetrieb) liegen noch auf der CCU und sind deaktiviert.
Im Fall der Fälle kann ich die Programme (2 pro Raum) aktivieren und habe einen halbwegs brauchbaren Betrieb (ohne den Komfort des Scriptes).
Und ich habe ein abgespecktes Notprogramm in den Geräten selber liegen, welches ja dann greift, wenn der Modus auf "Auto" geändert wird.
Das wäre dann pro Raum auch nur noch ein kleiner Eingriff.
Beides sind Notvarianten, die einen Standard-Tagesablauf abdecken.
Gruß,
Eric