Test Adapter HeatingControl v2.12.x
-
Anzeigefehler:
Ich nutze ebenfalls Chrome.
In Edge sehen die Reiter des Admins identisch aus.Zeiten:
Die MAX! Thermostate stehen auf AUTO und auf durchgehend 5 Grad.
Laut default-Wert sollte ab 05:00 Uhr die Temperatur auf 19 Grad gestellt werden, dies hat jedoch nicht funktioniert.im Log steht zu diese Zeitpunkt:
2019-07-13 05:00:00.005 - [34mdebug[39m: heatingcontrol.0 CheckTemperatureChange is called
2019-07-13 05:00:00.006 - [34mdebug[39m: heatingcontrol.0 cron jobs
2019-07-13 05:00:00.010 - [34mdebug[39m: heatingcontrol.0 [INFO] status = true next event: 14 Jul 2019 05:00:00
2019-07-13 05:00:00.013 - [34mdebug[39m: heatingcontrol.0 [INFO] status = true next event: 13 Jul 2019 08:00:00
2019-07-13 05:00:00.015 - [34mdebug[39m: heatingcontrol.0 [INFO] status = true next event: 13 Jul 2019 12:00:00
2019-07-13 05:00:00.016 - [34mdebug[39m: heatingcontrol.0 [INFO] status = true next event: 13 Jul 2019 16:00:00
2019-07-13 05:00:00.017 - [34mdebug[39m: heatingcontrol.0 [INFO] status = true next event: 13 Jul 2019 21:00:00 -
Ich muss meine Homematic-Thermostate auf "manuell" stellen. Im Auto-Mode funktioniert das setzen bei Homamatic nicht. Wahrscheinlich ist das bei max! genauso. Eine Fehlermeldung, dass ein Wert nicht gesetzt werden kann, hast du nicht im log? Das o.g. log sieht gut aus, da passt alles...
-
Hallo
@Rene_HMim Log sind keine weiteren Einträge gewesen.
ich habe mal einen Zeitpunkt von 18:40 uhr definiert und den Adapter neu gestartet, ebenfalls ohne erfolg und auch hier keine Fehlermeldungen:2019-07-13 18:40:00.010 - [34mdebug[39m: heatingcontrol.0 CheckTemperatureChange is called
2019-07-13 18:40:00.012 - [34mdebug[39m: heatingcontrol.0 cron jobs
2019-07-13 18:40:00.013 - [34mdebug[39m: heatingcontrol.0 [INFO] status = true next event: 14 Jul 2019 05:00:00
2019-07-13 18:40:00.016 - [34mdebug[39m: heatingcontrol.0 [INFO] status = true next event: 14 Jul 2019 08:00:00
2019-07-13 18:40:00.018 - [34mdebug[39m: heatingcontrol.0 [INFO] status = true next event: 14 Jul 2019 12:00:00
2019-07-13 18:40:00.019 - [34mdebug[39m: heatingcontrol.0 [INFO] status = true next event: 14 Jul 2019 16:00:00
2019-07-13 18:40:00.032 - [34mdebug[39m: heatingcontrol.0 [INFO] status = true next event: 14 Jul 2019 18:40:00 -
@Muchul sagte in Adapter: HeatingControl:
CheckTemperatureChange is called
ist "HeatingPeriodActive" gesetzt?
-
@CKMartens Ich habe mal den ersten Versuch mit den tado Thermostaten in github hochgeladen. In dem Schritt sollten die Thermostate im admin des HeatingControl-Adapters unter "Geräte" gelistet werden.
-
@Rene_HM
Nö, es war gar nichts gesetzt.
Habe jetzt mal alles so gesetzt wie in deinem Beispielbild, tut sich leider auch nichts.Was mich wundert;
Setze ich den Setpoint von Hand, wird es wieder auf den ursprünglichen Wert zurückgesetzt.Ändere ich es vom Thermostat wird der Wert korrekt übernommen.
-
@Muchul Mit "HeatingPeriodActive" = true sollte sich wenigstens etwas im log tun. Siehst du da neue Einträge?
-
@Rene_HM
Hallo,
ich habe von Github installiert und die Thermostate sind im Adapter erschienen.
Die Thermostate sind wie schon gesagt in Homebride-Adapter angelegt.
Und hier noch das Debug-Log
heatingcontrol_20190714_1609.txtDankeschön schon einmal für Deine Arbeit
-
-
Danke, dass du diesen Adapter schreibst!
Ich biete hier auch gerne meine Hilfe an und kann Tests für MAX! Radiatoren und Zigbee Fensterkontakte durchführen.Im unterschied zu @muchul nutze ich nicht den Adapter Max! Cube Version 0.1.2. sondern den Adapter maxcul. Im Log kommt deshalb der Hinweis:
heatingcontrol.0 2019-07-18 13:58:10.139 warn not supported type {"_id":"maxcul.0.IHA0042492.desiredTemperature","common":{"name":"Thermostat IHA0042492 set temperature","type":"number","read":true,"write":true,"min":4.5,"max":30.5,"role":"level heatingcontrol.0 2019-07-18 13:58:10.139 warn unknown path to actors zigbee.0. heatingcontrol.0 2019-07-18 13:58:10.139 warn unknown path to thermostats maxcul.0.Kannst du den Pfad maxcul.0. für Thermostate und zigbee.0. für Aktoren auch "erlauben"?
Soweit ich sehe ist die Struktur gleich oder ähnlich wie bei @Muchul :
-
Die maxcul Thermostate kann ich einbauen. Fensterkontakte werden derzeit noch gar nicht unterstützt. Der Pfad zu den Aktoren ist für digitale Outputs, die die Heizung oder Heizungsventile ein/ausschalten... Idealerweise machst du im github für beide je ein issue
Danke. -
@Muchul irgendwie sehe ich den Fehler nicht
Ich habe mal eine neue Version in's github hochgeladen. Die enthält nur noch ein paar logs mehr zu dem Zeitpunkt, wenn ein neuer Wert auf ein Thermostat geschrieben werden soll. Villeicht kannst du den Test mit dieser Version nochmal wiederholen. In den Einstellungen sehe ich, dass einige Temperaturanpassungen (party usw.) nicht gesetzt sind. Setze die bitte mal auf 0. -
gibt es eine möglichkeit auch HM Thermostate welche per fhem iobroker Adapter eingefügt sind damit zu steuern ? befinden sich unter fhem.0
-
Ich bin dabei, den Adapter komplett zu überarbeiten. Dann wird es möglich sein, die OID's manuell für Thermostate, Aktoren und Sensoren zu konfigurieren, wenn die Geräte nicht automatisch gefunden werden. Damit kann man praktisch alle Thermostate mit dem Adapter steuern. Manche werden automatisch konfiguriert andere muss man dann manuell konfigurieren.
-
Ja sehr geil. Kann dann gerne tester spielen im Zusammenhang mit homematic welche über den fhem Adapter kommen
-
Guten Abend,
würde auch gerne beim testen behilflich sein.Nutze aktuell das Heizungsthermostatsteuerung Skript, welches allerdings nie richtig lief und nach Umstieg auf redis überhaupt nicht mehr funktioniert.
Setze folgend Komponenten ein.
- HM Thermostate
- HM Raumthermostate
- HM Fensterkontakte
- Xiaomi Fensterkontakte
- Xiaomi Temperatursensoren
Ganz großes Kino wäre es, wenn dieser Adapter die Logik des Fußbodenheizungs Skript implementiert. Und ich auch dieses Skript ersetzen könnte.
-
okay, jetzt ist es soweit, ich habe die Version 0.1.0 im github und NPM veröffentlicht.
Wichtigste Änderung vorweg: Der Adapter wurde intern komplett überarbeitet. Damit musste ich leider auch die Datenpunkte zur Profileinstellung pro Raum verschieben. Damit ist es notwendig, die Einstellungen im Vis o.ä. anzupassen
Nun zu den Neuerungen:- Man kann nun eine nicht limitierte Anzahl von Thermostate, Aktoren und Sensoren pro Raum konfigurieren. Die alte Grenze von einem Thermostat pro Raum gibt es nicht mehr.
- die drei verschiedenen Profiltypen
** Montag bis Sonntag
** Montag bis Freitag und Samstag / Sonntag
** jeden Tag einzeln
funktionieren nun - es gibt auch die Möglichkeit, Fenstersensoren einzubinden. Damit kann man die Raum-Zieltemperatur absenken, wenn Fenster offen sind
- es gibt ein Interface zum Feiertag-Adapter. Damit kann man erkennen, ob heute ein Feiertag ist. Ein Feiertag wird dann entweder als normaler Tag oder wie ein Sonntag behandelt. das ist im admin einstellbar
- es wird weiterhin versucht, die Geräte pro Raum automatisch zu erkennen. Da das aber oft nicht so einfach ist (insbesondere bei nicht-Homematic-Geräten) gibt es jetzt die Möglichkeit, die Geräte auch manuell zu konfigurieren. Man fügt einfach ein neues Gerät im neuen Raum ein, setzt ein oder zwei Pfade (zu Zieltemperatur, aktueller Temperatur für Thermostate bzw. state zu Aktoren und Sensoren) und aktiviert das Gerät.
Hier noch ein screenshoots vom neuen Adapter-admin:
ein Teil der Hauptkonfiguration:
die Profil-Konfiguration
zunächst die Räume
und dann die Konfiguration des Raumes, nachdem man den rot markierten Edit-Knopf gedrückt hat:
-
@Rene_HM
schade, dass es sich eingebürgert hat, alles nur noch englisch zu bezeichnen ...
-
@BBTown Die Übersetzungen sind für alle unterstützten Sprachen vorhanden. Die screenshots sind von meinem Test-System, welches in englisch läuft...
-
@Rene_HM
danke dir für den Hinweis
