[Vorlage] Heizungsthermostatsteuerung 2.1 - Script

looxer01

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;
        }
    }

Sylabil

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.

Blackmike

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

looxer01

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

Blackmike

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

apollon77

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 ...

looxer01

~~@Blackmike:~~

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

eric2905

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

looxer01

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

eric2905

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

contex22

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

looxer01

~~@contex22:~~

Habe mir nur ein 3-stufiges System aufgebaut: `

Jap, dann ist es eine dritte Variante.

Nachteil: manueller Eingriff (bei Situationen, die einen Fallback erfordern) notwendig

Vorteil: Script ist vollumfänglich nutzbar

und ich halte fest, dass es zahrleiche Möglichkeien gibt, einen oder mehrere Fallbacks einzubauen.

Blackmike

yap, das war meine intension, bei ausfall das ganze system trotzdem lebensfähig zu halten.

aber wenn sich etwas mit dem rpc adapter in der richtung tut, das er bei hm und hmip auch die mastersätze beherrscht, ist das glaub ich nicht nötig, in einem script nachzubilden.

Gruss, Black

looxer01

~~@contex22:~~

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? `

Im Grunde kannst du es so einstellen, Die Minimaltemperatur ist dann die ECO Temperatur.

beispiel:

Eco Temp = Miniltemp 18 Grad

geplante Raumtemp = 21 Grad

Absenkung bei Abwesenheit 5 Grad

Absenkung bei Urlaub 5 Grad

jetzt zieht immer die Minimaltemp von 18 Grad.

oder spricht da was dagegen ?

vG Looxer

contex22

Nein, von der Seite nicht. Kenn nur meine Frau, die friert so leicht und bei eingestellten 24 greift dann die 18 nicht mehr. Aber dann Stelle ich die Absenkung größer den die Absenkung geht ja nicht tiefer als die mindest Temperatur, oder?

Gesendet von meinem Redmi Note 4 mit Tapatalk

looxer01

~~@contex22:~~

ber dann Stelle ich die Absenkung größer den die Absenkung geht ja nicht tiefer als die mindest Temperatur, oder? `
Ja, ganz genau so war es gemeint. Wenn die Absenkung nur gross genug gewählt ist, dann entspricht die Mindesttemperatur der ECO Temp.

Die Temperatur geht nicht unter Mindesttemp.

vG Looxer

Dutchman

Hi,

Super script und die erneuerungen in 2.0 sind merkbar danke !

Ich habe nur 1 problem mit de view was mich zum verzweifelen bringt :lol: :mrgreen: :lol:

Da ich so einige Zimer habe moechte ich die komplette heizungs steuerung in ein seperates VIS project verschieben.

Jedoch verhaut es mir dabei irgendwie die layouts der buttons.

Import im Main sieht so aus :

Genau die gleiche view (export/import) sieht in meinen 2ten project so aus :

Jemand eine ahnung warum und was ich daran machen kan ?

looxer01

Hi,

das Problem ist leider schon sehr alt. siehe hier: http://forum.iobroker.net/viewtopic.php … =60#p84526

Habs auch seit dem schon im Trello. Ich muss aber auch sagen, dass ich nicht sicher war, ob das nur bei mir in der Form wie du es beschreibst auftritt.

Bei mir ist es so, dass sobald ich in einer anderen View den View mit den JQUI Widgets hinzfüge zerhaut es das Format inklusive aller anderen JQUIs aller Heizungsviews.

Kannst du das so bestätigen ? Dann können wir vielleicht den Aufbau besser beschreiben. Ich denke nur BF kann es am Ende fixen.

vG Looxer

looxer01

Hi Dutch,

Wenn ich mir das jetzt so im Trello ansehe, dann sieht es so aus, dass dort mehrere Probleme beschrieben sind.

So funktioniert das wahrscheinlich nicht. Wir sollten ein neues Ticket aufmachen, dass exakt die Situation beschreibt bei dem die Widgets Ihre Groesse/Position ändern.

Bei mir ist es so.

1. 5 Heizungsviews gepackt in View in Widget (5 x View in Widget) in einer View (Obergeschoss)

2. Wenn ich dann eine neue Heizungsview in eine andere View (Untergeschoss) (importiere oder kopiere - das ist egal ) wieder in view in Widget, dann verschieben sich die Widgets. ABer nicht nur im neu erzeugten View sondern in allen Heizungsviews inklusive der 5 Views im Obergeschoss.

3. Die verschobenen Views lassen sich nicht mehr korrekt anzeigen, auch wenn die neue View gelöscht wird. Nichts geht mehr

4. Im VIS Editor erscheint alles korrekt.

Bei dem beschriebenen Aufbau musst du vorsichtig sein, denn ich habe noch keinen Weg gefunden die Views wieder vernünftig anzuzeigen. Da half nur Restore.

vG Looxer

Dutchman

hmm ok also ein algemeines problem mit vis wen ich richtig verstehe ?

Wurde dafuer auch ein bug report gemacht in Git ? Trello sehe ich meist mehr fuer features und git als issue reporter/tracker.

NEWS

[Vorlage] Heizungsthermostatsteuerung 2.1 - Script

Support us

1.3k
Online

30.6k
Users

77.2k
Topics

1.2m
Posts

NEWS

[Vorlage] Heizungsthermostatsteuerung 2.1 - Script

Support us

1.3kOnline

30.6kUsers

77.2kTopics

1.2mPosts

1.3k
Online

30.6k
Users

77.2k
Topics

1.2m
Posts