Ich hatte mir eine Automation erstellt, bei der der Kalibrierungswert meiner Sonoff-TRVs nachgeregelt wird, je nachdem, wie die Abweichung zwichen Temperatur am Ventil und im Raum ist. An einigen TRVs funktioniert das, an anderen nicht. Nun habe ich mich mal intensiver damit auseinandergesetzt und gesehen, dass man über Zigbee2Mqtt die Kalibrierungstemperatur nur zwischen -2.5 und +2.5 einstellen kann, obwohl die Oberfläche von -12.5 bis +12.5 zuläst. Werte außerhalb -2.5 und +2.5 werden einfach nicht per MQTT gesendet. Das erklärt, warum es an manchen TRVs nicht geht. Kommt die Beschränkung von den TRVs oder von Zigbee2MQTT?
Nach lesen hier im Forum dachte ich mal VersatileThermostat zu verwenden. Das erschien mir am besten geeignet zu sein, zumal es ja sogar die Ventilstellungen steuern können soll. Leider gelingt es mir nicht, ein VT anzulegen. Wenn ich in “Create” eines anlege, dann sind mir manche notwendigen Angaben unverständlich. Irgendwie muss ich an zwei Stellen den externen Temperatursensor angeben (warum) und ohne Auißenthermometer komme ich auch im Dialog nicht weiter. Eigentlich möchte ich ohne Außentemperatur arbeiten. Das generelle Problem ist aber, dass immer “Konfiguration unvollständig” angezeigt wird, ohne einen Hinweis, was fehlt. Ich habe eigentlich nur alle Entitäten (Raumtemperatursensor, TRV, Fensterkontakt und zentralen Heizungsschalter) angegeben. Alles andere war standard. Was könnte man übersehen haben?
In dem Thread VTs wird eigentlich erklärt, was zu machen ist. Dort steht “Bei der Einrichtung von VT wählt man “over_climate” und dann den “Direct Valve Control’ type.” “over_climate” gibt es bei mir nicht, ich vermute, das ist “Thermostat an einem TRV” bei deutscher Übersetzung, richtig. “und dann den Dircect Volve Control type” verstehe ich nicht, so etwas wird mur gar nicht angezeigt.
Kann mir bei VT irgend jemand weiter helfen? Gerne auch per PM mit screendumps.
We introduced Zigbee specification limitations in 2.7.2 to avoid issues like devices changing the underlying value without the user’s knowledge (e.g. automatically clamped to the specification range), which can of course be dangerous (or at the very least annoying). Here’s the specification paragraph on this attribute in particular:
Der Thread bezieht sich auf eine alte Benutzerführung. VTherm wird ständig Weitereintwickelt, da ändert sich ab und an auch etwas in der Benutzerschnittstelle.
Eigentlich gibt man den externen Temperatursensor nur einmal an. (wenn man eine zentrale Konfiguration anlegt) Ansonsten bei jedem neuen VTherm. Der externe Sensor ist bei VTherm Pflicht. Du musst keinen eigenen haben, da du auch einen von einer anderen (DWD-) Wetterstation einsetzen kannst.
Das ist wirklich ein Problem, das liegt aber möglicherweise an der von HA vorgegebenen Benutzerführung.
Die Zigbee2Mqtt-Änderung, die zur Abweisung des Kalibrierungswertes führt, wäre für mich erst einmnal eine Option auf die ältere Version zurückzugehen. Leider geht das wohl auch nicht mehr, außer ein altes Backup. Damit wären dann aber andere Einstellungen hinfällig. Oder weiß jemand, wie ich die Version zurücksetzen kann. Über die UI bekomme ich nichtzs angezeigt.
VT werde ich mir mal näher ansehen, wird dann wohl aber auch nicht funktionieren mit dem Zigbee2Mqtt-Problem. Zumindest nicht bei bestimmten Konfigurationen.
Ich würde jetzt mal ein paar Tage abwarten und nicht gleich wieder am Produktiv-Z2M basteln.
Evtl. eine Möglichkeit wäre, parallel das Z2M-Edge-Addon installieren und die Konfiguration doppeln. Wie’s geht steht gleich unten in der Doku des Addons beschrieben.
oder hier hassio-zigbee2mqtt/zigbee2mqtt-edge at master · zigbee2mqtt/hassio-zigbee2mqtt · GitHub
Die Konfiguration beschränkt sich darauf, einmal den yaml-Code vom “einen ins andere Fenster” zu kopieren.
Nach Installation/Konfiguration stoppt man das Standard-(Release)Z2M-Addon und startet stattdessen die Z2M-Edge Version. Falls alles klappt, fährt man bis zum nächsten Ersten. die Edge-Version und switcht dann wieder zurück zum Release.
Natürlich muss der Fehler dazu erstmal behoben und in Dev.(= Edge) landen (dauert i.d.R. wenige Stunden)
Zumindest bei der Versatile/VTherm-Integration führt der Fehler jetzt auch nicht dazu, dass die Heizungs-Regelung nicht mehr funktionieren täte.
Nachtrag zur VT-Integration, vlt hat jemand anderes ja auch ein ähnliches Problem.
Ich habe jetzt ein VTherm einrichten können. Mein Fehler in allen vorherigen Versuchen war, dass ich die TPI übersprungen habe, da ich momentan noch nichts damit anfangen kann, in der Annahme dort ah die Defaultwerte zu nehmen. Erst wenn man den Schritt einmal geht und alle Werte belässt, dann funktioniert es. Die Screendumps haben mir insofern geholfen, als dass ich sehen konnte, dass ich vorher nichts falsch gemacht hatte.
Und der Hinweis mit Zgbee3Mqtt Edge hat auch erst einmal geholfen. Danke.
Eine Frage hätte ich jetzt noch, es geht jetzt um Versatile Thermostat.
Nachdem ich die ganzen Features gelesen habe und ich es ja auch einrichten konnte, habe ich jetzt alle Sonoff TRVs umgestellt. Die Steuerung erfolgt ja jetzt über climate.VTherms, nicht mehr über die Sonoff-climate-Entitäten, richtig? Mir ist jetzt aufgefallen oder habe ich da nur etwas übersehen, wenn ich am TRV die Temperatur ändere, dann wird das vom VTherm nicht übernommen. Nur andersherumg, wenn ich in der UI die Solltemperatur ändere, werden auch die zugehörigen TRVs umgestellt. Kann man das irgenwie bewerkstelligen?
Und dann habe ich einen Raum mit zwei TRVs. VTherm ändert die Solltemperatur immer in beiden TRVs. Wenn ich nun an einer TRV die Solltenperatur ändere (vorausgesetzt obiges funktioniert), wird dann der andere TRV nachgezogen?
Und was die Regelung betrifft, verstehe ich es eventuell auch nicht richtig. Die TRVs sind unterschiedlich Weit vom Temperatursensor. Ich würde erwarten, dass dann das Offset und auch das Regelverhalten unterschiedlich ist. Das scheint mir aber nicht so. Muss ich hier auch noch etwas berücksichtigen?
Ansonsten scheint VT doch einen ganz guten Job zu machen.
Wenn du nun an einem Thermostat direkt die Temperatur änderst, sollte das dann eigentlich auch auf VTherm sich auswirken und auf auf die anderen Thermostate, welche dem VTherm zugeordnet sind.
Zu deiner anderen Frage: bei mir ist es zumindest so, das er alle Thermostate gleich regelt, aber die Offsets haben sich über die Zeit etwas unterschiedlich eingestellt, war aber tatsächlich auch ein längerer Zeitraum, was das gebraucht hat.
Heute gab es ein Update für VT. Dort war die Rede davon, dass jetzt Auto TPI fast fertig ist. U.A. war davon aber auch von einer Auto TPI Card die Rede. Ich finde dazu aber nichts im Netz (Google). Hat jemand einen Hinweis?
Auto-TPI luft eigentlich im Hintergrund. In der Konfiguration der einzelnen VTherms kannst du es aktivieren. Das ist keine zentrale Einstellung, denn jeder Raum ist anders und wird komplett eigenständig berechnet. Du kannst also erst einmal mit einem VTherm beginnen, ob das bei dir vernünftig funktioniert. Lies dir bitte vorher die Dokumentation zu Auto-TPI durch.
Mich hat “Auto TPI card” angesprungen und danach hatte ich gesucht in der Annahme, mit diese Card die einzelnen Koeffizienten oder was auch immer sehen zu können.
Es gibt keine spezielle Auto-TPI-Card. Wie bereits geschrieben, wird das in der Konfiguration des VTherms eingestellt. In der aktuellen VTherm-UI-Card gibt es dann die Anzeige des Status von Auto-TPI. Jedenfalls habe ich das so verstanden. Sollte ich da falsch liegen, bitte ich um Korrektur.
Zu Auto-TPI am besten die englischsprachigen Seiten lesen, die sind aktueller als die deutsche Übersetzung. Technik ausführlich und Anleitung. Zur Auto-TPI-Learning-Card gehts hier.
Man sollte beachten:
Diese Funktion ist in erster Linie für Heizsysteme mit Ein-/Aus-Schalter konzipiert, wie z. B. elektrische Heizkörper, Boiler, Fußbodenheizungen oder Pelletöfen. Die Anpassung an thermostatische Heizkörperventile (TRV) bleibt aufgrund ihrer Nichtlinearität problematisch.
