Beiträge von marco.gr

Ich glaube ich habe deinen Texte beim ersten mal nicht richtig verstanden und habe mich von deinem verständlichem Frust ablenken lassen.
Bei dir funktioniert bereits alles, aber der Weg dorthin war sehr steinig?

Ich lass meinen Post dennoch im Original stehen.

Zitat

Übrigens was in der Developer-Doku steht, funktioniert auch nicht.

Den Punkt konnte ich meiner Ansicht nach mit meinem Post widerlegen. Mit dem Mosquitto Befehl geht es, wie in der Dokumentation beschrieben.

Zitat

Hat von euch das jemand hinbekommen, die neuen Shellies per mqtt anzusprechen ohne davor jedes Mal googlen zu müssen? Dieses JSON-Zeug in mqtt ist echt Krebs.

Ja, die Shellys schon. Ich verstehe die Doku mittlerweile relativ gut, auch wenn nicht immer einfach zu Lesen.

Bei Home Assistant und YAML ist das schon deutlich schwieriger für mich gewesen. Und dort ist diese JSON Transformation naturgemäß schwer zu Lesen.
Dies macht man so, weil man sehr universell und Leistungsfähig sein möchte. Anders bekommt man es so generisch und konfigurierbar nicht sinnvoll hin.
Hier wären eher Wrapper in Form von Addons schön, so dass man sich das gefrickel sparen kann und einfach nur ein Addon konfiguriert.

Viele Grüße,
Marco

Hallo Sprinterfreak ,

jetzt hast du mich neugierig gemacht

Nach meiner Einschätzung sind verschiedene Design Ansätze für MQTT völlig in Ordnung. Mir persönlich ist da ein kleines JSON viel lieber als ein komplexes XML .

Ich hab mir kurz die Doku angesehen und kann dich beruhigen. Die von dir gewählte Variante 'MQTT Control' verwendet kein JSON. Dieses hättest du nur bei "RPC over MQTT" oder allen anderen RPC Calls.

Bei mir funktioniert dieser Part wie du ihn erwartest, aber dazu komme ich gleich.

Ich fange mal bei null an, um den Fehler einzugrenzen

Ich gehe davon aus, dass du 'MQTT Control' aktiviert hast und dein Prefix stimmt und MQTT aktiv verbunden ist.

Zum Debuggen von MQTT kannst du folgendes machen:

Installiere dir die Mosquitto-Tools oder etwas vergleichbares um den MQTT Traffic mitzulesen. Es gibt sogar einen Error Pfad auf den du subscriben kannst.

# Alles mitlesen
mosquitto_sub -h 192.168.xxx.xxx -t "shelly-hoehle/#" -u "user" -P "password"

# Nur den Error Pfad mitlesen
mosquitto_sub -h 192.168.xxx.xxx -t "shelly-hoehle/error/switch:0" -u "user" -P "password"

# weitere Pfade siehe Doku

Somit kannst du sicherstellen, dass Home Assistant die richtigen Werte übermittelt.

Dieser Befehl funktioniert zum Einschalten:

mosquitto_pub -h 192.168.xxx.xxx -t "shelly-hoehle/command/switch:0" -u "user" -P "password" -m "on"

Valide Werte für dich wären "on", "off", "toogle". Siehe hier: https://shelly-api-docs.shelly.cloud/gen2/Component…ch#mqtt-control

Wenn das alles funktioniert, kannst du die Fehlersuche auf HA eingrenzen.

Home Assistant MQTT

Hier fehlt mir im Augenblick etwas Zeit mich reinzudenken. Deshalb nur meine Gedanken, was ich kontrollieren würde.

  state_value_template: "{{ iif(value_json['output'], 'true', 'false') }}"

Versuche doch erstmal nur on, off oder toggle - zum herantasten:

state_value_template: "toggle"

• Passt hier überhaupt 'iif' oder müsste es 'if' heißen? Ich weiß es nicht auswendig.
• Schicke doch mal "{{ value_json['output'] }} ab und beobachte, was du z.B. mit o.g. Tool auf der Konsole sehen kannst. Was wird hier geschickt?

Ich weiß aus eigener Erfahrung, dass diese Variablen Berechnung in dieser Double Mustache Syntax (wie heißt die eigentlich genau?) im YAML extrem frickelig ist. Da gehen einem komplett die Augen über, vor allem wenn du auch noch URL Encodierung für REST Commands dazu nimmst.

Hier an der Stelle verstehe und Teile ich dann auch deinen Frust.

Schreibe mal wie weit du gekommen bist, vielleicht kommst du ja nun schon bis zum Ziel.

Viele Grüße,
Marco

Krauskopp ja, wir schreiben Nachts in zwei Threads. In diesen habe ich dir den Link zum Thermostat Shelly Script reingepackt.

Da sprichst du ein interessantes und wichtiges Thema an.
Es juckt mich manchmal in den Fingern ein Deployment & Config Tool für Shelly zu entwickeln.

Ein größerer KVS um Code und Config zu Trennen wäre ja schon ein Segen. Aber dazu vielleicht an anderes mal mehr.

Krauskopp voila

Hallo liebe interessierte,

ich arbeite an einem Thermostat zur Ventilsteuerung meiner Fußbodenheizung. Aktuell nutze ich dazu einen Shelly Pro 4 und 4x Shelly H&T Gen3. Später sollen auch Shelly BLU H&T unterstützen werden.

Wichtig war mir, dass das Script möglichst autark läuft. Ich möchte im Notfall die Shelly App nutzen und standardmäßig Home Assistant verwenden. Ich hoffe und vermute, dass auch IO Broker und weitere verwendet werden können.

Für die dynamischen Werte 'aktuelle Temperatur' und 'Zieltemperatur' verwende ich die Virtual Components. Diese können von extern gesteuert werden und ich habe direkt eine rudimentäre Oberfläche zur Steuerung über die Shelly App.

Die Ist-Temperatur wird per HTTP RPC von einem Shelly H&T Gen3 an meinen Shelly Pro 4 gepusht. Hierzu verwende ich eine Aktion mit Variable:

http://192.168.xxx.xxx/rpc/Number.Set?id=200&value=$temperature

An dieser Stelle könnte natürlich jeder externe Temperatursensor stehen, der einen HTTP GET Request senden kann.

Um mein Script mit der Außenwelt zu verbinden, nutze ich MQTT. Ich habe alles direkt auf Home Assistant zugeschnitten um in meiner gewohnten Umgebung zu bleiben.

Das Script findet ihr auf Github:

https://github.com/mgrie/shelly-s…/smart-havac.js

Die heutige Version und die kleinen Aufräumarbeiten habe ich noch nicht getestet. Das Script ist 'Work in Progress' und bei mir seit ein paar Tagen im produktiven Einsatz.

Viele Grüße,
Marco

Krauskopp ich nehme mir mal noch die Zeit das Script zu dokumentieren, dann packe ich es in einen eigenen Thread.

Hallo Krauskopp,
vielen dank für deinen Hinweis in diese Richtung hatte ich den TE wirklich nicht verstanden.
Allerdings tun sich mir dann noch viele neue Fragen auf. Ich frage mich ob der Ansatz vom TE in dieser Form praktikabel ist oder ob ich ihn immer noch nicht verstanden habe.

Lieber LeGreatMaxiking,
ich kann dir gerne den Prototypen meines Scripts zur Verfügung stellen. Du könntest es auf deine Bedürfnisse hin Anpassen.
Ich würde dir auch weiterhin meinen Ansatz, die Temperatur über eine virtuelle Komponente zu steuern, empfehlen. Denn somit ersparst du dir eine Scriptanpassung, wenn die Temperatur spontan geändert werden soll.

Viele Grüße,
Marco

Aber halt! Wieso habe ich den eingangs erwähnt, das ich gerade ein einem Script arbeite?

Die o.g. Lösung mit dem Generic Thermostat hat für mich noch einen Nachteil. Sollte Home Assistant mal nicht hochfahren oder ausfallen, funktioniert meine Heizung nicht mehr. Ich bevorzuge hier eine autarke robuste Lösung. Und hier kommt ein Shelly Script ins Spiel.

Ein Shelly Script hat nur wenige Möglichkeiten mit der Außenwelt zu kommunizieren. Als erstes gibt es hier die virtuellen Komponenten, welche den Charme haben, dass sie funktional in der Shelly Welt zur Verfügung stehen. Allerdings ohne jeglichen Komfort.

Eine Möglichkeit die hier sehr gut funktioniert ist MQTT. Hier wäre es sogar denkbar eine eigene App drüber zu stülpen, so dass man nur einen MQTT Server als Vermittler benötigt. Einfacher ist es eine Software zu finden, welche MQTT mit einer generischen Oberfläche verbindet. Und wer kann das bereits im benötigten Kontext? Home Assistant!

Anmerkung: Der Shelly H&T Gen3 pusht leider nur Differenzen von 0,5° Kelvin. Mit einem Shelly BLU H&T hätten wir hier eine viel schönere Treppe und eine Hysterese von 0,2° Kelvin.

Wie weit ist mein Script?

Prinzipiell funktioniert es bei mir Zuhause bereits sehr gut. Dennoch gibt es Potential für Verbesserungen:

• Aktuell ist es auf einen Shelly H&T Gen3 oder einen externen HTTP RPC Trigger ausgelegt und unterstützt den Shelly Blu H&T nicht. Wenn mir hier jemand eine kleine Hand voll Shelly Blu H&T spendiert, würde es der Weiterentwicklung sehr helfen
• Fenster Sensoren und Außentemperatur werden auch noch nicht unterstützt. Weiß aber auch nicht, ob das bei Fußbodenheizung viel hilft.
• Es fehlen noch Dinge wie ein ECO Modus, was auch etwas schwierig wird, da zumindest beim Shelly Pro 4 die Anzahl der verfügbaren virtuellen Komponenten nicht ausreicht. Es ist aber nicht gänzlich unmöglich.
• Zeitsteuerungen. Diese sind zwar in Home Assistant bezüglich HAVAC auch nicht gerade hübsch abzubilden, sind dort jedoch ausreichend Verfügbar.

Hallo,

zu deinem Glück arbeite ich gerade an einem solchen Script. Allerdings wird dir das erstmal nichts nützen.

Du kennst ja schon den internen Thermostatmodus. Diesen würde ich absolut nicht empfehlen, denn dieser läuft allem Anschein nach nur mit Internetverbindung in der Cloud. Deshalb solltest du eine andere Lösung suchen.

Ein Shelly Script löst zwar genau diese Probleme und Abhängigkeiten, hat jedoch keine Oberfläche. Was ja dein größtes Anliegen ist.

Um eine geeignete Oberfläche zu haben, empfehle ich dir Home Assistant (mit anderen Produkten wie io Broker habe ich persönlich keine Erfahrungen).
Dort kannst du ein Generic Thermostat anlegen und dein Cloud basiertes Thermostat ersetzen.

P.S.: Wenn du wenig gebastel haben möchtest und entsprechende Kabel verlegt sind würde ich dir ohnehin zu einem Shelly Wall Display raten.

Wie oben beschrieben ist mir eine Synchronisation bei 2 TRVs in einem Raum sehr wichtig. Ich bin der Meinung sie funktionieren so überhaupt erst vernünftig um einen Raum gleichmäßig zu heizen.

Lösung: Shelly Script zur Synchronisierung mehrerer BLU TRVs

Mein Ansatz verwendet einen BLU TRV als master um den Algorithmus von Shelly zu verwenden. Die anderen fungieren als slaves und ziehen mit einer kurzen Verzögerung die Ventilposition nach.

Zusätzlich wird die Zieltemperatur synchronisiert, sobald diese an einem BLU TRV verändert wird. Dieser Prozess kann bis zu einer Minute dauern.

Sollte das Script abgebrochen werden, so verharren die Slaves im aktuellen Zustand!

Zum Installieren müsst Ihr ein paar IDs ermitteln und im Script konfigurieren. Aktuell ist es nur mit 2 BLU TRV getestet.

Zusätzlich müsst Ihr beim slave die Thermostatfunktion deaktivieren, indem Ihr einmal 'Trv.SetConfig' aufruft.

Dem Script ist es egal, ob ihr einen externen Temperatursensor am master verwendet.

Die Window Sensoren habe ich bei beiden BLU TRV konfiguriert, so schaltet auch der Slave optisch auf die niedrigere Temperatur. Für die Ventilposition spielt das keine Rolle.
Der Boost wird nicht synchronisiert. Ihr könnt ihn entweder an einem Slave einzeln nutzen oder am Master für alle Ventile.

Beispielaufruf zum Deaktivieren des TRVs mit der ID 202:
http://192.168.xxx.xxx/rpc/BluTrv.Call?id=202&method=TRV.SetConfig&params={id:0,config:{enable:false}}

Das Script findet Ihr auf Github:

https://github.com/mgrie/shelly-s…lu_trv_group.js

Für eine ausführlichere Anleitung fehlt mir aktuell die zeit. Ich hoffe die obige reicht für versierte Anwender aus.
Das ich für das Script keine Garantie übernehmen kann, versteht sich von selbst.

Viel Spaß und Erfolg damit!

Hallo Gerhard,

hattest du kurz vorher mal den Boost aktiviert?

In meinen heutigen Beobachtungen schaltete der Boost mit der aktuellen Firmware nicht mehr ab. Möchte meinen, dies hat er mit der alten Firmware noch getan. Wenn ich kurz die Fenster öffne wird das Ventil geschlossen. Wenn ich nur die Temperatur zurückdrehe nicht.

Eine Liste mit bekannten Fehlern wäre wirklich interessant. Und vermutlich lange.

Wo hast du die Info zur Firmware 1.5 beta her?

Viele Grüße,

Marco

Ich denke nicht, dass es nur Verzögerungen sind.

Extern: 20.7°C
Intern: 20.8°C
2. TRV: 22.8°C

Ohne den externen Sensor lieferte TRV 1 nahezu identische Werte wie der TRV 2.
Zwischenzeitlich hatte der interne exakt den Wert vom externen Sensor. Er hatte aber auch schon 19.2°C bei ähnlichen Bedingungen.
Zusätzlich hinkt die Shelly Cloud den Werten oft hinterher und zeigt nochmal was anderes an.

Meine Theorie: Der 'interne' Wert ist bei Vorhandensein eines externen Sensors immer ein berechneter Wert.

Hallo Peter,

ich teste die TRVs gerade sehr intensiv, da ich an zwei Scripten arbeite, welche meine Wünsche erfüllen sollen.
Die Plausibilität der Temperaturwerte bereitet mir schon länger Kopfzerbrechen. Auch die aktuellste Firmware erscheint mir da nicht plausibel.

Wie kommst du darauf, dass die Methode 'Trv.SetTarget' Einfluss auf den verwendeten Temperaturwert hat?
Wenn du die BLU TRV per MQTT in HA eingebunden hast, so hast du vielleicht den falschen Ist-Temperaturwert als Quelle und lässt dich dadurch zusätzlich irritieren?

Welchen Temperaturwert der Shelly nun wirklich nimmt ist dennoch eine sehr gute Frage, da der BLU TRV definitiv fragwürdige Werte anzeigt.
(Ich habe im selben Raum zwei TRVs verbaut. Da passt teilweise gar nichts.)

So kannst du das Verhalten vom Temperatursensor konfigurieren:

• Hast du keinen externen Sensor verbunden, so wird der interne verwendet.
• Hast du einen externen Sensor verbunden, so kommt es darauf an, ob du den Behavior / TRV Verhalten für Floor Heating / Fußbodenheizung aktiv hast:
  • FBH aktiv: Es wird nur der externe Sensor verwendet
  • inaktiv: Es wird ein Temperaturwert aus internem und externem Sensor errechnet.

Alternativ gäbe es einen RPC Befehl 'Trv.SetExternalTemperature', dieser funktioniert dann genau so, wie ein direkt verbundener Shelly BLU H&T. Allerdings wird dieser nicht in der Oberfläche angezeigt.

Hat der BLU TRV einen externen Sensor, so zeigt er per RPC (z.B. via MQTT) 3 statt 2 Temperaturwerte an.

Wichtig: Sobald du einen externen Sensor verwendest, zeigt der interne keine plausiblen Werte mehr an. Das Thema ist eines eigenen Threads würdig. Oder ist das dein Hauptproblem für das du eine Lösung suchst?

Alternativ: Manuelle Steuerung

Ja, das geht. Ich experimentiere damit.
Aber bist du wirklich schon so verzweifelt

Zum einen würdest du damit den internen Algorithmus aushebeln, der bei konventionellen Heizkörpern bestimmt nicht völlig falsch ist. (Bei Fußbodenheizungen bezweifle ich das).
Zweitens erhöhst du damit die Fehlerquote. Die TRVs verlieren gerne mal temporär die Verbindung zum Shelly BLU Gateway. D.h. selbst wenn deine Software auf diesem Gerät läuft, hast du schon eine neue Fehlerquelle. Bei allen anderen Varianten (MQTT, HTTP RPC, WS RPC) müsstest du alle Fehlerszenarien kennen um diese zu berücksichtigen.

Viele Grüße,
Marco

Zitat von audiwilli2010

Also angeschlossener Sensor zeigt z.B. 20.7 und am TRV unter aktueller Temp. Steht 20.4. Ist das bei euch auch so?

Ja.

Wenn du zwei TRVs mit einem Gateway und einem BLU H&T verbindest, kann es sogar sein, dass nur ein TRV hinterherhinkt.

Ich habe die Temperaturwerte noch nicht wirklich verstanden. Teilweise errechnet das Thermoastat sogar Werte, die größer als die zwei gemessenen Werte sind. Der Temperaturverlauf scheint da auch eine Rolle zu spielen. Ich werde in spätestens zwei Wochen nochmal eine Versuchsreihe dazu starten.

Viele Grüße,

Marco

Zitat von krameger

Kann man die Steuerung irgendwie anders einstellen, dass anstatt Ventilstellung 0 die Tempertur kontinuierlicher geregelt wird?

Ich habe da noch etwas für dich gefunden:

http://192.168.xxx.xxx/rpc/BluTrv.Call?id=200&method=TRV.SetConfig&params={id:0,config:{min_valve_position:10}}

Mit dieser RPC Methode sagst du dem TRV mit der ID 200, dass es das Ventil nur zu 10% schließen darf. Dauert ein paar Minuten bis die Änderung Auswirkungen zeigt. Die aktuelle Einstellung kannst du dann mit der Methode "Trv.GetConfig" abrufen. Der Default-Wert ist 0.

Das entspricht doch dem was du gesucht hast?

Ich selbst würde diese Einstellung nur verwenden, wenn ich ein altes Handventil mit existierendem Raumthermostat ersetzen möchte, denn in dieser Konstellation steuert das Raumthermostat die Vorlauftemperatur und die Pumpe des Heizkreises.

Viele Grüße,
Marco

Hallo,

prinzipiell lässt es sich Einrichten, dass zwei TRVs den selben BLU H&T verwenden. In der Praxis funktioniert es noch nicht.

Die Temperaturwerte vom TRV mit externem Sensor kommen mir insgesamt noch sehr Buggy vor. Seit 23.12. gibt es eine neue Firmware für die TRVs, diese dürfte jedoch noch nicht alle Probleme lösen.

Wenn ich stimmige Temperaturwerte habe, so laufen die TRVs nicht annähernd synchron. Ich nehme an, die TRVs haben einen lernenden Algorithmus, der das Heizverhalten optimieren soll. D.h. die TRVs beeinflussen sich gegenseitig. In der Shelly App konnte ich beobachten, das ein TRV immer dominanter ist als der andere.

In meinen Augen müssen folgende Dinge von Shelly behoben werden, wenn man zwei TRVs in einem Raum betreiben möchte:

• Reduzierung der Bugs bei den Temperatur Sensorwerten. Mit steigender Anzahl an TRVs in einem Raum steigt auch die Chance, dass ein TRV z.B. den Raum überhitzt.
• Echte Gruppierung der TRVs in Form einer Synchronisierung.
• Konfigurierbare Hysterese: Eine Stärke von Shelly ist es, dass man im Vergleich zu anderen Herstellern etwas mehr Freiheit hat. Leider fehlt dies bei den Shelly BLU TRV. Mir ist klar, dass man bei Heizkörpern keine so krassen Werte wie bei einer FBH fährt. Allerdings würden die TRVs in dieser Form nicht mit meiner FBH funktionieren.

Ich habe nun einen TRV abgeschaltet und versuche erstmal mit einem klar zu kommen bis sich eine Lösung auftut.

Viele Grüße,
Marco

Mein jüngstes Fehlerszenario war, dass die Temperatur vom externen Sensor nicht mehr übernommen wurde. Somit hat der Heizkörper nicht mehr geheizt, weil er dachte, die Temperatur ist ausreichend.

Da ich zwei TRVs am selben Gateway mit dem selben Sensor betreibe (also zwei Heizkörper im selben Raum), kann ich mit Sicherheit sagen, dass es nicht an der Bluetooth Verbindung vom Sensor zum Gateway lag.

Meine Lösung war hier ein Neustart des Gateways.

Mich würde interessieren, ob du einen externen Sensor verwendest und ggf. den selben Fehler hast.

Hallo,

im Prinzip ist das grundlegende Verhalten normal. Auch ein klassischer Thermostatkopf schließt das Ventil zu 100%.
Früher hatte man deshalb bei alten Heizanlagen einen Bypass installiert, allerdings in der Praxis meist nur um Pfeifgeräusche bei der Umwälzpumpe zu vermeiden.
Moderne Umwälzpumpen können je nach Betriebsmodus (z.B. Auto-Adapt bei Grundfoss) erkennen ob die Ventile warmes Heizungswasser anfordern und steuern so die Drehzahl der Umwälzpumpe.

Den Algorithmus der Ventilstellungen habe ich noch nicht ganz verstanden. Hier beobachte ich gerade noch sehr viel.

Das Verhalten mit einer gemessenen Hysterese von 5 Kelvin (21,5 - 16,5) ist zu viel. Nach meiner Einschätzung ist die Hysterese der Shelly Blu TRV fest auf 1 Kelvin eingestellt. Und zwar egal ob du die TRV mit internen Sensor, externen Sensor + interner Sensor oder nur externer Sensor (als Behavior "Fußbodenheizung" einstellbar) betreibst.

Die von dir genannte Schwankung kann viele Ursachen bzw. eine Kombination mehrerer Ursachen sein.

Ich würde dir die gleiche Lösungsstrategie empfehlen, welche ich gerade selbst bei mir durchführe:

• Update auf die neueste Firmware. Stand heute: TRV v1.1.3, Gateway v1.4.99
• Aufzeichnen aller Sensoren über eine Software, die eine schönere Ansicht als die der Shelly App bietet. In der kumulierten Ansicht mit min/max Kurve erkennt man zu wenig.
  • In meinem Fall ist dies HomeAssistant mit BTHome Erweiterung.
  • Außerdem kann die Vorlauftemperatur der Heizung und ob die Pumpe läuft interessant sein, denn während der Warmwasser-Vorrangschaltung läuft dein Heizkreis ggf. für ~30 Minuten nicht.

Ich habe das aktuellste TRV Update selbst erst jetzt eingespielt und muss die Situation weiterhin beobachten.

Ich habe meinen Shelly Wall Display erst seit einem Tag montiert. Das Display ist dauerhaft aus. Energiesparen aus. Meine Beobachtungen:

1. So bald ich den Display verwende geht die Temperatur (je nach Raumtemperatur) um bis zu 2 Grad hoch.
2. Der Shelly hat permanent Temperaturschwankungen im vergleich zu anderen Sensoren

Mein Eindruck:

Der Sensor ist zu Nahe an der restlichen Hardware verbaut. Je kälter der Raum, desto mehr fällt die Abweichung durch Abwärme auf.


Für mich ärgerlich, denn ich habe nun mehr Schaltzyklen als vorher und ungenauere Temperaturaufzeichnungen. Dafür endlich ein Bedienelement für alle Familienmitglieder.

Dem Thermostat fehlt in meinen Augen eine Mindestzeit (z.B. 10 Minuten) für "Ventil ein", und eine kleine Nachlaufzeit bei Temperatur erreicht.
Des weiteren wäre eine Glättung der gemessenen Temperaturkurve durch Anpassung der Empfindlichkeit des Sensors ein Gewinn für den Normalbetrieb.
Der Fehler, dass der Sensor anschlägt, wenn das Display an geht wird sich damit jedoch noch nicht Lösen lassen.