Beiträge von marco.gr

Interessanter Anwendungsfall. Ich wäre da eher auf die Idee gekommen, nach einem smarteren TV zu suchen.

In eine ähnliche Richtung habe ich einen Prototypen geschrieben, der zwischen Standby und Betrieb unterscheiden kann und die Betriebszeit zusätzlich (grob) aufzeichnet. Allerdings liegt das gerade aus Zeitgründen auf Eis.
Wie schon erwähnt, ist dein Projekt mit Shelly Script umsetzbar.

Alternativ sollte es auch in Home Assistant oder Node Red (und weiteren externen) umsetzbar sein.

Schreib doch einfach mal, in welche Richtung du denkst und welche Vorkenntnisse du dazu hast.

Ich habe dich so verstanden, dass dir ein einfacher Timer für 1h nicht ausreicht und dir die verbrauchte Energie anstelle eines Zeitwertes wichtig ist?
Sobald ab 18:00 Uhr 30Wh verbraucht sind, soll der Shelly das Relais öffnen und die Steckdose deaktivieren?

Ja, das ist auch per Script möglich.

Welchen Shelly verwendest du denn?

Zitat von pinnbert

Ich arbeite aktuell noch daran, dass ich ein Script baue, mit dem ich mehrere Displays mit mehreren TRVs so steuern kann. Hat jemand schon solch ein Script erstellt?

Wenn du Inspiration für mehrere Geräte brauchst:
Das folgende Script synchronisiert die Zieltemperatur mehrerer BLU TRV und die Ventilposition auf einem Gateway.
Es ist nur noch nicht mit mehr als 2 TRVs getestet. Möglicherweise müssen ein paar Requests aufgrund von Beschränkungen sequentiell statt asyncrhon ausgeführt werden.

Für mehrere Geräte würde ich spontan MQTT empfehlen und einen eventbasierten Ansatz wählen.

Beitrag

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

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…

marco.gr

5. Januar 2025 um 12:12

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

Hardwareseitig dürfte es keine Besonderheiten in der Schnittmenge zu anderen Gen3 Devices geben. Alles was das BLU Gateway Gen3 braucht, befindet sich auf dem Chip (Bluetooth, WLAN).

Es würde mich nicht wundern, wenn dieses Dilemma irgendwann per Software-Update aufgelöst wird.

Talkabout ja genau so funktioniert es, wenn ihr Werte setzen wollt.

Wichtig ist dabei, dass das Feature "RCP over MQTT" in den MQTT Einstellungen aktiviert ist.

Wenn man allerdings die aktuellen Werte auslesen möchte, so geht dies mit nur über die invervallmäßigen Status Meldungen.

Eine Anmerkung zu "Trv.SetPosition": Damit setzt man die Ventilposition. Das funktioniert nur, wenn das BLU TRV vorher über "Trv.SetConfig" disabled wurde. Diese Variante wählt man, wenn man auf den TRV internen PID-Regler verzichten möchte.

Hier überschneiden sich die Begrifflichkeiten.

Wenn du das Gateway unter Bluetooth aktivierst, so erweiterst du lediglich die Reichweite deiner BLU Geräte, welche du in der Cloud nutzen möchtest.
Für andere Anwendungsfälle nützt dieser Modus nichts.

Klar, mit einem ESP32 und ESPHome oder auch isp-idf als Ausgangsbasis hast du generell mehr Möglichkeiten. Dafür jedoch kein fertiges Gehäuse.

Wenn du eine Lösung dazwischen suchst, könntest du den Shelly auch flashen. Allerdings greife ich an an diesem Punkt auf eigene Schaltungen zurück, weil ich dann mehr Ports vom Chip nutzen kann und mir keine Gedanken über das Flashen machen muss.

Hallo michl73 ,

nein, über ein Script kannst du keine Mails direkt versenden. Mir ist da weder etwas bekannt, noch habe ich in der Dokumentation etwas dazu gefunden.

Es gibt verschiedenste Mail-Relay Server von Cloud Anbietern, welche dir Schnittstellen bieten. Da gibt es auch kostenfreie Varianten. Somit könntest du per HTTP POST (möglicherweise auch GET) Mails per externem Dienstleister verschicken.

Dokumentation: https://shelly-api-docs.shelly.cloud/gen2/Component…s/HTTP#httppost

Ich kann dir nur auf die Schnelle keine Empfehlung aussprechen, welcher Anbieter dafür gut geeignet wäre. Wenn das in die richtige Richtung geht, kann ich für dich bei Gelegenheit mal schauen.


Sollte es einen Anbieter geben, dem HTTP GET reicht, so könntest du auf ein Script verzichten und dir würde sogar eine Aktion reichen.


Nur ein Gedanke zur Inspiration:
Zusätzlich könnten Webhooks für z.B. MS Teams oder ein SMS Gateway auch eine Lösung sein, wenn du einen direkteren Alarm benötigst.

Bei mir laufen die TRVs mittlerweile viel besser. Die aktuelle Firmware läuft definitiv besser als die vorherige. Eine neue Position des externen Temperatursensors hat eine weitere, spürbare Verbesserung gebracht und zusätzlich der Faktor Zeit und Geduld.

Vielleicht mal zur Veranschaulichung meine Messwerte bei geschlossener Tür. Die orangene Linie ist direkt am Schreibtisch. Dort schwankt die Temperatur um 0,7 bis 0,8 Grad. Das ist OK, auch wenn mir 0,5..0,6 lieber wäre.
Blau ist der externe BLU H&T, türkis direkt am Heizkörper. Dieser steht etwas erhöht auf einem Sideboard

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Ab 6:45 stand die Tür eine Zeit lang offen. Das erklärt den Ausreiser, der danach folgt.

Zitat von DarkSoul

Und Nein, es wird nirgendwo beschrieben, dass das WD die Cloud braucht für den vollen Funktionsumfang. Auch nicht in den hunderten Foren oder Youtube Beiträgen.

Da stimme ich dir auch zu. Es fehlt an einer Übersicht, was mit und ohne Cloud machbar ist. Über alle Produkte hinweg.

Zitat von DarkSoul

Ja den Punkt habe ich im Menü, nur schlecht wenn man den ioBroker nutzt anstatt HA

Ich habe noch nicht verstanden, weshalb sich dieses Feature auf HA beschränkt.

Hallo DarkSoul,

die Funktion für welche ich meinen Wall Display anschaffte (Thermostat) funktioniert auch wenn die Cloud nicht erreichbar ist. Sogar der Zeitplan funktioniert, was mich ehrlich gesagt überraschte.

Die Shelly Produktlinie ist doch darauf ausgelegt, dass die Geräte entweder Autark ohne Bridge oder im Verbund mit der Cloud funktionieren.
Lediglich die BLE/BTHome Geräte kann man so Kombinieren, dass sie Selbständig funktionieren (z.B. BLU TRV mit Door/Window und Temperatursensor).

Wenn du z.B. Szenen ohne Cloud schalten möchtest, so benötigst du einen Broker wie z.B. Home Assistant.

Das zieht sich durch die gesamte Produktpalette hindurch, deshalb ist es aus meinem technischen Blickwinkel logisch, dass man ohne Cloud keine Geräte über den Shelly Wall Display fernsteuern kann.

Deinen Frust kann ich nachvollziehen, denn ich richte mein Zuhause auch so ein, dass es ohne Internet funktionsfähig und bedienbar bleibt.

Mit der neuen Firmware gibt es eine Lösung am Horizont: Man kann Home Assistant einbinden um z.B. einen Shelly BLU TRV zu Steuern (wenn er über MQTT eingebunden ist).

Viele Grüße,
Marco

Zur Scripterstellung:

Ich wollte sie nie verwenden, um mein Haus perspektivisch "wartbar und nachvollziehbar für die Nachwelt" zu hinterlassen.

In der Praxis habe ich dann ein paar Scripte geschrieben mit denen ich noch ein paar Prozent mehr heraushole, wo mir Funktionalitäten fehlten.
Eher ist es hier so, dass ich mir wünschen würde, dass Normalanwender Scripte per App als AddOn nachinstallieren könnten um ebenfalls davon zu profitieren. Um auch dort Versionierung und Updates zu ermöglichen.

Viele Grüße,
Marco

Zitat von Admin Dach

Wenn ich darf, würde ich gerne eine Gegenfrage stellen. Obwohl es eine große Nachfrage nach Matter und KNX gibt und die Entwicklung bereits im Gange ist, würde mich interessieren, was diese Protokolle aus deiner Sicht so wertvoll macht? Warum, gibt es eine so hohe Nachfrage nach diesen Protokollen?

Bei Matter gehe ich von dem Wunsch nach viel Interoperabilität mit anderen Komponenten und Zukunftsfähigkeit aus. Auch wenn das andererseits immer neue Kompromisse mit sich bringt. Ich persönlich bin da einfach nur neugierig und gespannt was kommen wird. Denn ich beschäftige mich mit diesem Thema erst, wenn ich es in der Praxis austesten kann.
Vielleicht ist es auch nur Selbstbestätigung mit Shelly auf das richtige Pferd gesetzt zu haben.

Ich kenne Personen, die Ihr komplettes aus saniert und mit KNX ausgestattet haben. Für diese wird Shelly durchaus immer interessanter. Auch das LoRa AddOn könnte da für den ein oder anderen interessant sein - sofern es sich sinnvoll kombinieren lässt.
Bei einem Gebäude komplett ohne bestehenden KNX Bus fühle ich es persönlich nicht.

Viele Grüße,
Marco

Zitat von Flutschi

Dachte du hast es im Einsatz. SW-nstallation super einfach auch bei mehreren HK im Raum.

Sprichst du gerade von dem Sync Script von mir, oder von einer anderen Sache?

Falls ja, so würde mich interessieren wie schnell die einzelnen Ventile bei mehr als einem Slave reagieren.

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.