NEWS
[Vorlage] Heizungsthermostatsteuerung 2.1 - Script
-
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
-
Hi,
@eric2905:Im Fall der Fälle kann ich die Programme (2 pro Raum) aktivieren `
Ich glaube Black ging es um den den Betrieb nach Ausfall ohne manuellen Eingriff.
(oder ich habe zu viel interpretiert)
Daher ist der beschriebene Ansatz so gewählt. Thermostate sind dann IMMER auf Auto-Modus womit der Fallback greift sobald die Situation eintrifft.
Habe ich auch getestet ….funktionierte (mit den Einschränkungen)
EDIT: damit ist auch ein Ausfall der CCU abgedeckt.
vG Looxer
-
Ist mir schon klar.
Habe mir nur ein 3-stufiges System aufgebaut:
1. Alles ok = Steuerung hat ioBroker
2. ioBroker fällt aus = Steuerung übernimmt die CCU (Scripte aktivieren)
3. CCU fällt auch aus = Im Gerät hinterlegte Steuerung zieht (Auto-Modus aktiv)
Gruß,
Eric
-
Ich hätte da noch eine andere Frage. Ich Komme aus dem MSR Bereich und arbeite sehr gern mit Komfort und Eco Betrieb. Komfort ist ja schön für jeden Raum einstellbar, wäre es ein großer Aufwand die Absenkung auf einen einheitlichen wert zu bringen? Also nicht Absenkung um 2 Grad sonder zb auf 18 Grad?
Gruß Robert
Gesendet von meinem Redmi Note 4 mit Tapatalk