Beiträge von marco.gr

Zitat von Meza100

Bin jetzt zumindest glücklich! Dann kann ich bald mehr Shellys bestellen. Danke euch!

Gerne.

Ich bestelle ständig neue Shellys und mir machen gerade die individuellen Lösungen Spaß. Meiner Tochter gefällt der E-Ink Display vom H&T Gen3, weil er so gut zu lesen ist. Die Batterielaufzeit scheint echt gut zu sein. Allerdings würde ich diese Geräte nicht für Steuerungen empfehlen. Für eine einfache Raumüberwachung (Lüftungsverhalten, Tracking) sind sie durchaus OK und hübsch anzusehen.

Für Steuerungen (Heizung) haben sie zu große Update-Intervalle und sind nur über Umwege mit den Shelly BLU TRVs kompatibel.

Es würde mich nicht wundern, wenn Shelly bis zur nächsten Heizperiode ähnliche und kompaktere Geräte mit Bluetooth BTHome auf den Markt bringen würde.

Viele Grüße,

Marco

Zitat von Flutschi

Angel Na, so einfach scheint es nicht zu klappen.

Thema

2x Shelly BLU TRV mit BLU H&T als Sensor

Hallo,

ich habe wie oben geschrieben 2x BLU TRV mit einem BLU H&T als externen Senor über die App eingestellt. Alles ist an Gateways betrieben. Sowohl die TRVs als auch der H&T geben mir Temperaturen aus. Über die Unterschiede innerhalb von 2m reden wir hier (erstmal) nicht.

Jetzt habe ich das in der App so eingestellt das der externe Sensor die Steuerung komplett übernimmt (in der App heißt das Fußbodenheizung).

Kann ich davon aus gehen das die beiden TRVs dann die Temperatur des H&T übernehmen…

depty24

30. Dezember 2024 um 17:01

Ich kann in Anlehnung zu dem anderen Thread mittlerweile sagen, dass das Verhalten bei externen Temperatursensoren mit der aktuellen Firmware besser geworden ist.

Natürlich kann man einen Temperatursensor mit mehreren BLU TRV koppeln. Allerdings bleibe ich dabei, dass das Standardverhalten mehrerer BLU TRV in einem Raum nicht funktioniert.
Mir ist es aufgefallen, weil ich bei einer Solltemperatur von 21° tägliche Ausreiser auf 23,5° hatte und der Raum sehr oft und lange unter 20° war. Außerdem war der Raum einfach miserabel beheizt, da die TRVs nicht annährend synchron arbeiteten. Im Prinzip hat ein Heizkörper die arbeit übernommen und der andere nur ein bisschen "verirrt mitgeheizt". Hier waren z.B. Zigbee Aquara Thermostate viel besser.

Auf der anderen Seite kann ich verkünden, dass ich nach rund einer Woche mit meinem Shelly Script zur Gruppierung zweiter TRVs viel zufriedener bin. Wenn man jetzt noch die Hysterese der TRVs geringfügig herabsetzen könnte, wäre das ein Traum.

Viele Grüße,
Marco

Hallo Meza,

in diese Richtung hatte ich keine Probleme, nur mit der Shelly App selbst. Für HASS hatte ich den Setup Mode am H&T Gen3 aktiviert und das Device wurde schnell gefunden.
Ggf. musst du etwas Geduld haben, da das Gerät die CPU immer wieder in den Sleep Mode versetzt und dann nicht per WLAN erreichbar ist.


Hast du die Firmware 1.4.5 installiert?

Im Changelog steht: HT Gen3 Fix unresponsive devices.

Frag mich nicht was damit exakt gemeint ist, aber einen Versuch wäre es vielleicht wert?

Viele Grüße,
Marco

Interessant. Dann darfst du nur nicht 'shellies/announce' und 'shellies/command' als Präfix vergeben.

https://shelly-api-docs.shelly.cloud/gen2/Component…tt#mqtt-control

martner die Doku ist ein Mysterium. Wenn man anfängt sie zu verstehen, frägt man sich, weshalb man das nicht früher schon konnte .
Man muss immer gut aufpassen in welchem Kontext (Script, MQTT RPC, MQTT Control, ...) man gerade ist und welche Informationen von (völlig) anderen Seiten korrespondieren. Hier und da wurden Doppelungen vermieden ohne z.B. die entsprechenden Objekte Requests / Result zu verlinken.

Aber noch etwas anderes, was ich wiederrum noch nicht verstanden habe:

Zitat von martner

Und es funktioniert wie angegeben: ein zB Mini1PMG3 lässt sich auf dem Topic shellies/Name/command/switch:0 mit einem Text on oder off schalten.

Ich arbeite bisher bei den Topics immer nur mit '<shelly-mqtt-prefix>/command' und habe 'shellies' nun schon ein paar mal gelesen (auch in der Doku für eine Art Broadcast o.ä.).

Gab es hier einen Breaking Change oder existieren diese (seit einer neueren Firmware) parallel?

Zitat von apreick

Das verstehe ich nicht? Welche Probleme hast Du damit?

Bei mir läuft HA auf einem RasPi 5 (NVMe) im Docker seit 1 Jahr ohne einen Aussetzer

1. Er fährt ab und an nicht hoch

Muss ein Problem mit dem Booten von SSD sein. Möglicherweise lässt sich dies mit einer SD-Card und entsprechender Boot Datei beheben.

2. "Abgesicherter Modus"

Nach einem Stromausfall war HA mal in einer Art abgesichertem Modus. War kein großes Problem. Erforderte aber manuellen Eingriff.

3. Schwierigkeiten nach Updates

Beispiel: Die Cloudflare Erweiterung und Zigbee2MQTT haben sich in gewissen Versionen nicht vertragen, so dass diese nach einem Neustart manuell gestartet werden mussten. Und Stromschwankungen / Stromausfälle hatte ich genügend dieses Jahr.

Ein Teil der Probleme lässt sich natürlich lösen. Ist aber dennoch richtig ärgerlich, wenn deine Heizungsventile ohne Zigbee2Mqtt nicht lauffähig sind.

Die wichtigen Systeme sind bei mir mittlerweile alle autark. Benötigen entweder nur Bluetooth (Shelly BLU TRV) oder nur WLAN (Shelly Pro4 + Shelly H&T Gen3). Garagenlicht und Garagentor (Shelly + ESPHOME) und Dunstabzug (Fensterschaltung für Kaminofen) werden folgen.

Der Ansatz eines hochverfügbaren MQTT Broker von Sprinterfreak wäre da eine Möglichkeit. Allerdings wäre das in meinem aktuellen Konstrukt weitere Hardware und Software oder sogar zusätzlich WLAN wo Bluetooth im Einsatz ist. Somit fahre ich die Strategie, dass die Geräte ohne HA funktionsfähig sind. HA übernimmt dann nur die GUI oder unkritische Dienste.

Verstehe.

Ich versuche hier einen 'Keep it Simple' Ansatz rein aus Anwendersicht. Denn ich weiß ja nicht, wer das System später mal betreut und damit zurecht kommen muss.

Allerdings stelle ich immer weiter um, so dass mein Geräte auch ohne Home Assistant autark funktionsfähig sind. Denn Home Assistant auf dem RPI ist nicht hochverfügbar.

Sprinterfreak Der Firmware nach verwendest du dein Gen1 Gerät. Der unterstützt das 'MQTT Control' Feature nicht.

Zitat

Übrigens die Template-Expression in den Double-Curly-Brackets nennt sich Jinja2. Ansich sehr geil. Aber man sollte das halt nicht brauchen müssen um eine simple Aktion wie "Relais Ein" auszuführen.

Ich habe bisher nicht hinterfragt, weshalb du ein MQTT Gerät in der YAML konfigurierst. Gibt ja durchaus Anwendungsfälle dafür.

Für die simple Aktion "Relais Ein" verwende ich für meinen Shelly Gen 1 das Shelly AddOn und eine Automation mit einer Aktion:

Gibt es einen Grund, weshalb du MQTT verwenden möchtest?

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