Test Adapter HeatingControl v2.12.x

Rene_HM

@xADDRx nichts! Der o.g. Wert ist die Absenkung, wenn ein Fenster offen ist. Es gibt ein 'WindowIsOpen' nicht (jedenfalls nicht als Datenpunkt). Einfach den Adapter im debug Mode starten und bei Öffnen und Schliessen des Fensters das log beobachten. Anhand des logs sollte dann erkennbar sein, dass die Zieltemperatur um den eingegebenen Wert reduziert wird. Ich baue noch ein Status-Datenpunkt ein, an dem man sieht, welche Absenkungen verwendet werden. Das ist aber noch nicht fertig...

xADDRx

@Rene_HM Verstanden,danke.

CKMartens

@Rene_HM sagte in Adapter: HeatingControl:

setState('heatingcontrol.0.Present',true);

Eben leider nicht Rene. Im Log erscheint dann:

javascript.0	2019-09-20 06:21:02.493	warn	at script.js.Test.Skript_1:1:1
javascript.0	2019-09-20 06:21:02.492	warn	at setState (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:1276:20)
javascript.0	2019-09-20 06:21:02.478	warn	You are assigning a boolean to the state "heatingcontrol.0.Present" which expects a bool. Please fix your code to use a bool or change the state type to boolean. This warning might become an error in

ChrisXY

Gibt es schon ein VIS was etwas mehr angepasst ist ? Oder wie passt ihr die Pläne "relativ einfach" an ?

paul53

@CKMartens sagte:

You are assigning a boolean to the state "heatingcontrol.0.Present" which expects a bool.

Offenbar hat der Datenpunkt "heatingcontrol.0.Present" den Typ "bool", den es in Javascript nicht gibt. Korrigieren in "boolean".

Rene_HM

@paul53 habe ich mit V02.3 geändert. Datenpunkt muss aber im Objecttree gelöscht werden und Adapter neu gestartet, damit die Änderung wirkt.

paul53

@Rene_HM sagte:

Datenpunkt muss aber im Objecttree gelöscht werden und Adapter neu gestartet, damit die Änderung wirkt.

Oder man ändert den Typ manuell.

Rene_HM

@Rene_HM sagte in Adapter: HeatingControl:

Achtung: In der aktuellen Version gibt es noch ein Problem, wenn Räume oder Gewerke als enum manuell im iobroker admin angelegt werden.

In der eben veröffentlichten Version 0.2.3 (auf github und NPM) ist dieses Problem gelöst.
Die 0.2.3 enthält weitere bug fixes:

die Reihenfolge der Uhrzeiten in den periods wird geprüft. Falls eine spätere Periode eine frühere Uhrzeit enthält, wird dieser Eintrag ignoriert
wenn Perioden geändert werden, wird nicht nur die Zeittabelle für cron neu berechnet, sondern es wird auch geprüft, ob sich Temperaturen geändert haben. Diese werden dann auch direkt auf's Thermostat geschrieben
die Auswahl der object ID für "aktuell" und "Ziel" bei der Konfiguration der Thermostate wurde überarbeitet
der Type der bool-Datenpunkte wurde auf boolean geändert

Nächste Version wird 0.3.0 mit weiteren Features aus der Liste:
https://github.com/rg-engineering/ioBroker.heatingcontrol/issues

pix

Hallo,
ich habe den Adapter auch mal testweise zum Beginn der Heizperiode aktiviert. Super, danke für die Arbeit!

@Michael-Sauer sagte in Adapter: HeatingControl:

Nach Aktivierung der "HeatingPeriodActive" wird die falsche Periode genommen. Bei mir springt er am Montag immer wieder auf die Sa/So Einstellung. Fehlermeldung gibt es hier keine.

Habe den Fehler gefunden. Es liegt nicht daran das er den falschen Tag nimmt sondern daran das er nicht durch die Perioden schaltet wenn die letzte Zeit kleiner ist als die vorherigen.

Wenn jetzt Periods[4] kleiner ist z.B. 3 Uhr dann bleibt er da hängen.

Michael hat einen Fehler gefunden, den ich so oder ähnlich auch bestätigen kann.

Vor allem, wenn man nachts noch die Heizung verstellen will, muss man darauf achtern, dass die Perioden chronologisch korrekt sortiert sind. Wenn die erste Umstellung des neuen Tages zB um 00:30Uhr ist, muss das auch in der ersten Periode stehen. Sonst funktioniert es nicht.

Ich hatte auch anfangs den Tag im Kopf von morgens bis abends durchgespielt und entsprechend eingetragen und dann nicht die gewünschte Steuerung bekommen.

Wer also nach Mitternacht die Heizung stellen will muss daran denken.

@Rene_HM Bitte die Namen (also nicht Objektnamen, sondern Namen in der zweiten Admin Spalte) anpassen. Dort sind Leerzeichen und korrekte Groß/Kleinschreibung erlaubt.
Vorschläge:

period from -> Startzeit oder start period
HolidayAbsentDecrease -> Absenkung Urlaub abwesend oder holiday absent decrease
HolidayPresent -> Urlaub anwesend oder holiday present
VacationAbsent -> Urlaub abwesend oder holiday absent

Ausserdem fände ich gut den CurrentTimePeriod-Datenpunkt aufzusplitten. Kann man sich selbst in VIS wieder zusammensetzen

CurrentPeriod -> 2
CurrentPeriodStarted -> 06:00
CurrentPeriodSetTemperatur -> 23 °C
CurrentSetTemperature -> 21 °C (zB weil "Abwesenheit ein" 2 °C weniger)

Gruß
Pix

PS. Kleiner Hinweis und ich mache gern Issues auf Git

Rene_HM

@pix sagte in Adapter: HeatingControl:

Vor allem, wenn man nachts noch die Heizung verstellen will, muss man darauf achtern, dass die Perioden chronologisch korrekt sortiert sind. Wenn die erste Umstellung des neuen Tages zB um 00:30Uhr ist, muss das auch in der ersten Periode stehen. Sonst funktioniert es nicht.

In der 0.2.3 habe ich dazu einen zusätzlichen check eingebaut.

Chaot

Ich habe auf Verdacht mal den Adapter installiert, weil meine DECT Thermostate mit dem alten Script ja auch gelaufen sind.
Und das ist das derzeitige Resultat:

fritzdect.0	2019-09-25 21:20:19.023	info	Comet ID: 119600101272 identified for command (mode) : 0
fritzdect.0	2019-09-25 21:20:19.018	info	Comet ID: 119600101272 identified for command (targettemp) : 21
heatingcontrol.0	2019-09-25 21:20:19.016	info	room Martin Thermostat Target Temp set to 21
fritzdect.0	2019-09-25 21:20:19.009	info	Comet ID: 119610273248 identified for command (mode) : 0
fritzdect.0	2019-09-25 21:20:19.003	info	Comet ID: 119610273248 identified for command (targettemp) : 21
heatingcontrol.0	2019-09-25 21:20:19.001	info	room Toilette Thermostat Target Temp set to 21
fritzdect.0	2019-09-25 21:20:18.990	info	Comet ID: 119600122088 identified for command (mode) : 0
fritzdect.0	2019-09-25 21:20:18.971	info	Comet ID: 119600122088 identified for command (targettemp) : 21
heatingcontrol.0	2019-09-25 21:20:18.968	info	room Schlafzimmer Thermostat Target Temp set to 21
fritzdect.0	2019-09-25 21:20:18.965	info	HGROUP ID: 92:40:6E-900 identified for command (mode) : 0
fritzdect.0	2019-09-25 21:20:18.959	info	HGROUP ID: 92:40:6E-900 identified for command (targettemp) : 21
heatingcontrol.0	2019-09-25 21:20:18.957	info	room Wohnzimmer Thermostat Target Temp set to 21
heatingcontrol.0	2019-09-25 21:20:18.928	info	calculating new target temperatures
heatingcontrol.0	2019-09-25 21:20:17.759	info	starting. Version 0.3.0 in /opt/iobroker/node_modules/iobroker.heatingcontrol, node: v10.16.3
heatingcontrol.0	2019-09-25 21:20:17.728	info	States connected to redis: 127.0.0.1:6379

Es scheint das die Thermostate direkt richtig erkannt werden.
zur zusätzlichen Erklärung: Command Mode 0 ist AUTO

Jetzt muss ich nur noch an einer VIS basteln.
Oder hat hier jemand was einfaches?

Und eine Funktion hätte ich gerne noch.
Lässt sich der Datenpunkt "Mode" auch direkt ansteuern über die Datenpunkte oder nur aus dem Adapter heraus?

Dann könnte ich den bei "Fenster offen" direkt auf OFF Steuern anstatt nur auf Absenkung zu gehen.

Kugelkopf

@Chaot Oh, dass klingt interessant! Ich habe mich bisher noch gescheut weil ich nichts davon gelesen hatte, dass die FritzDECT Thermostate auch funktionieren.

Wie genau hast du sie eingebunden? Was bei was? Hab auch noch Xiaomi Fenster Kontakte via Zigbee > Deconz die ich auch gerne verwenden würde.

Chaot

@Kugelkopf Ich habe sie ganz normal manuell eingebunden und nach einem Neustart des Adapters waren dann alle Datenpunkte da.
Warum ich den Adapter neu starten musste verstehe ich zwar nicht ganz, ist aber egal.
Unter Thermostate und Aktoren die DECT eingetragen. Unter Sensoren habe ich dann auch noch die Sonoff eingebunden. Auch das scheint zu funktionieren.
Deshalb denke ich mal das du deine Xiaomi auch einbinden kannst sofern sie im ioBroker auftauchen.

Chaot

Gibt es eigentlich die Möglichkeit ein bestimmtes Programm zu hinterlegen?

Mir ist klar das das jetzt etwas Jammern auf hohem Niveau ist, aber ich denke da an bestimmte Szenarien die bei mir vorkommen die ich dadurch automatisieren könnte.
Beispielsweise:
Sohn kommt heim (Telefon aktiv) - Zimmer Sohn wird hochgefahren auf Urlaubstemp.
Tochter kommt heim - Zimmer Tochter und Wohnzimmer wird hochgefahren
Frau kommt heim - Wohnzimmer wird auf Komfortwert hochgefahren
Eltern Krank - WZ und SZ warm (speziell bei Männergrippe)
Tochter krank - WZ und Kinderzimmer warm
Die restlichen Thermostate sollen dann normal weiterlaufen wie eingestellt.

Ich habe aber keine Ahnung ob sowas überhaupt umsetzbar ist.
In der Fritzbox gibt es für sowas Szenen die man da programmieren hann. Aber ich möchte das eigentlich lieber über den ioBroker machen.

Ach noch vergessen:
Hund bellt - Heizung geht aus (der traut sich nur zu bellen wenn keiner da ist)

BlackJAck

Moin,

bin gerade auch am tüfteln mit dem Adapter.
Ich habe Zwave Thermostate die zwar nicht erkannt werden, aber man kann Sie(danke RENE_HM) auch manuell einfügen.
Bei allen habe ich den OID-Aktueller und Zielwert auf den SetPoint des Thermostat gelegt.

Scheinbar funktioniert das bei mir mit den Zeiten nicht ganz korrekt.
Bsp.
Raum Bad habe ich festweise mit ein Thermostat mit 5 Perioden angelegt.
Periode 0: 23°C @ 07:00 Uhr
Periode 1: 18°C @ 08:35 Uhr
Periode 2: 18°C @ 08:45 Uhr
Periode 3: 18°C @ 12:00 Uhr
Periode 4: 18°C @ 21:00 Uhr

Der Present und der Heatingpresent stehen jeweils auf true.

Mein Problem ist das der Adapter nicht zur gewünschten Zeit die Thermostate stellt. Log Eintrag um diese Uhrzeit ist eine Fehlanzeige. Es gibt kein Log.
Stelle ich aber manuell an der Zieltemperatur in den Perioden was um wird sofort aktualisiert.
Was läuft bei mir falsch?

Sonst erstmal danke an Rene_HM für die Arbeit

Rene_HM

@BlackJAck sagte in Adapter: HeatingControl:

Bei allen habe ich den OID-Aktueller und Zielwert auf den SetPoint des Thermostat gelegt.

Zunächst erst mal bitte nur die Ziel-OID verwenden. Die OID für Aktuell kann frei bleiben, wenn man das nicht benötigt. Aber bitte nicht in beide OID den gleichen Wert eintragen...
Bzgl. der Zeiten:
Bitte mal irgendeine Zeit ändern (oder den Adapter neu starten) und dann das debug-Log anschauen (und evtl. hier posten). Im log sollte etwas in der Art erscheinen:

[INFO] status = true next event: 29 Sep 2019 21:00:00
[INFO] status = true next event: 29 Sep 2019 13:00:00
[INFO] status = true next event: 29 Sep 2019 12:00:00
[INFO] status = true next event: 30 Sep 2019 08:00:00
[INFO] status = true next event: 30 Sep 2019 04:42:00
[INFO] status = true next event: 31 Mar 2020 23:55:00
[INFO] status = true next event: 1 Oct 2019 00:05:00
cron jobs

Rene_HM

@Chaot sagte in Adapter: HeatingControl:

Gibt es eigentlich die Möglichkeit ein bestimmtes Programm zu hinterlegen?

Hier ist der Plan, dass man eine manuelle Ziel-Temperatur vorgeben kann, die für eine gewisse Zeit eingestellt bleibt. Das könnte man dann per script entsprechend steuern.

Chaot

@Rene_HM Das wäre genau das Richtige.
Danke.

BlackJAck

Danke schon mal für die Info mit dem Zielwert. Hatte es irgendwo in einem Screen gesehen das die gleichen Datenpunkte gesetzt waren. Was heißt eigentlich OID? Object ID?
Übrigens hatte ich noch das Problem, das ich den Aktueller Wert OID nicht so einfach löschen konnte.
Ich habe den Wert per Entfernen Taste entfernt und OK gedrückt und zur Kontrolle nochmal rein, da Stand er wieder drin.
Erst nach dem ich das Thermostat gelöscht und neu angelegt habe war es weg.

Hier mal der Log fürs Bad:

heatingcontrol.0	2019-09-29 10:37:50.899	debug	system.adapter.admin.0: logging true
admin.0	2019-09-29 10:37:45.194	info	successful connection to socket.io from ::ffff:192.168.2.23
heatingcontrol.0	2019-09-29 10:37:20.983	debug	### all StateChange handled
heatingcontrol.0	2019-09-29 10:37:20.982	debug	### already done 10:38 / 10:38 /// heatingcontrol.0.Profiles.0.Bad.Su-So.Periods.3.time / heatingcontrol.0.Profiles.0.Bad.Su-So.Periods.3.time
heatingcontrol.0	2019-09-29 10:37:20.982	debug	### handle state change heatingcontrol.0.Profiles.0.Bad.Su-So.Periods.3.time {"val":"10:38","ack":true,"ts":1569746240979,"q":0,"from":"system.adapter.heatingcontrol.0","user":"system.user.admin","lc
heatingcontrol.0	2019-09-29 10:37:20.977	debug	### 111 handled
heatingcontrol.0	2019-09-29 10:37:20.977	debug	[INFO] status = true next event: 5 Oct 2019 21:00:00
heatingcontrol.0	2019-09-29 10:37:20.973	debug	[INFO] status = true next event: 5 Oct 2019 10:38:00
heatingcontrol.0	2019-09-29 10:37:20.967	debug	[INFO] status = true next event: 5 Oct 2019 08:45:00
heatingcontrol.0	2019-09-29 10:37:20.961	debug	[INFO] status = true next event: 5 Oct 2019 08:35:00
heatingcontrol.0	2019-09-29 10:37:20.955	debug	[INFO] status = true next event: 5 Oct 2019 07:00:00
heatingcontrol.0	2019-09-29 10:37:20.953	debug	[INFO] status = true next event: 30 Sep 2019 21:00:00
heatingcontrol.0	2019-09-29 10:37:20.949	debug	[INFO] status = true next event: 30 Sep 2019 16:00:00
heatingcontrol.0	2019-09-29 10:37:20.947	debug	[INFO] status = true next event: 30 Sep 2019 12:00:00
heatingcontrol.0	2019-09-29 10:37:20.945	debug	[INFO] status = true next event: 30 Sep 2019 06:30:00
heatingcontrol.0	2019-09-29 10:37:20.940	debug	[INFO] status = true next event: 30 Sep 2019 05:00:00
heatingcontrol.0	2019-09-29 10:37:20.938	debug	cron jobs

Was mich wunder ist der Eintrag:

heatingcontrol.0	2019-09-29 10:37:20.982	debug	### already done 10:38 / 10:38 /// heatingcontrol.0.Profiles.0.Bad.Su-So.Periods.3.time / heatingcontrol.0.Profiles.0.Bad.Su-So.Periods.3.time

bzw. warum die Events für Samstag bis Sonntag auf das nächste WE zeigen

mrMuppet

Ich plane gerade meine Heizung vom Heizungsscript auf diesen Adapter umzustellen. Leider werden mir Geräte immer nur beim Anlegen angezeigt, danach sind sie verschwunden. Woran kann das liegen?

NEWS

Test Adapter HeatingControl v2.12.x

Support us

695

32.4k

81.4k

1.3m