Wie soll man des verhindern?
Weiter auseinander kämen sie, wenn sie nicht im Verteiler, sondern in der Nähe des jeweiligen Verbrauchers sitzen würden.
Die Info's für den konkreten Fall fehlen hier allerdings (Was da wie geschaltet werden soll/muss).
Würde Shelly mal anfragen, was sie zu dieser"Packdichte" sagen. Meiner Meinung nach müssen sich die auf einer Hutschiene gegenseitig behindern, sowohl was die WiFi Ausbreitung (Platine neben Platine) als auch das genannte Protokoll angeht.
15 (incl. 3EM) dicht beieinander, vermutlich auf demselben 2.4HGhz Kanal ?
CSMA/CA fällt mir dazu ein:
OK, danke. ich habe das beschriebene Verhalten auch beobachtet.
Ich nutze die MQTT - Schnittstelle und sende dem TRV alle 5 Minuten einen (externen) Istwert von HomeAssistant aus.
Wenn die Regelung "eingeschwungen" ist, dann führt bei mir erst eine Ist - Soll Differenz von mindestens -1.0 Grad dazu, dass der TRV wieder "aufmacht". Soll bei mir = 21 Grad, Ist = 20.3. Also Differenz = -0.7 Grad, über fast 30 Minuten.
Valve Position wie bei Dir = 0%. , also Regler zu. Ist-Wert 20.0 Grad geschickt (Istwert vom externen Sensor entsprechend mit Offset manipuliert) und siehe da, er reagiert (nicht sofort, es dauert es 2-3- Minuten) und macht "auf", Valve Pos. geht von 0% auf z.B. 10-16% auf.
Wäre interessant, ob das bei Dir auch so ist,
Finde es vor allem deshalb merkwürdig, weil ich sogar den Schalter
"Accelerated heating (reduce time to reach the target temperature)
gesetzt habe. Kann aber sein, das sich das eben nur auf das Hochheizen beim Wechsel von Absenk- zu Heizphase auswirkt. Werde "accelerated" mal rausnehmen, ob das was ändert (also ggfs. noch schlechter wird).
Hallo, wird der Istwert von einem externen Sensor geliefert?
@apreik:
Hallo Andreas, danke!
Ist denn HACS erforderlich/sinnvoll, um Shelly TRV richtig einzubinden?
Derzeit habe ich HACS nicht im Einsatz (schlechte Erfahrungen mit einer älteren Version, länger her).
Die Integration ist auch , wie gesagt, jetzt nicht so das Problem, irgendwann werde ich auch die produktive HA-A auf den aktuellen Core bringen.
Mich wundert ein bisschen das Regelverhalten, das ich jetzt innerhalb einer Woche beobachtet habe.
Werde mal einen neuen Thread aufmachen, denn mit der Hardware Revision hat es wahrscheinlich nichts zu tun.
Übrigens:
die Integration unter HA-C gibt unter "Gerät Information" aus: Hardware: gen1 (SHTRV-01)
bei MQTT - wie berichtet - "dev-prototype" , d.h. "dev-prototype" = "gen1" Generation 1 , schon besser 
Moin,
ich habe derzeit 3 Instanzen von HomeAssistant (HA) in Betrieb:
HA-A = produktiv, die wichtigste, mit Fritzbox-, NabuCasa Cloud-, Alexa-Anbindung etc. Core Version: 2021.11.5
HA-B = produktiv, regelt "weniger wichtige" Dinge (aus historischen Gründen) Core Version: 2021.11.5
HA-C = nicht produktiv, Testversion, Core: 2022.3.3 (aktuell)
Zur Frage ("Hat HomeAssistant den TVR automatisch erkannt?"):
JA,, allerdings mit unterschiedlichen Ergebnissen (wegen der Core-Version, denke ich):
HA-A und -B : erkennen jeweils 1 Gerät und 1 Entität (sensor.shellytrv01_battery)
HA-C erkennt 1 Gerät , und 4 Entitäten:
climate.shellytrv_60a423dcb592
sensor.shellytrv_60a423dcb592_battery
sensor.shellytrv_60a423dcb592_temperature
number.shellytrv_60a423dcb592_valve_position
Die Integration (als Climate-Entity), die also nur bei HA-C gegeben ist, ist momentan für mich jedoch zweitrangig, denn:
Ich werde den produktiven HA-A, der derzeit 7 FritzDect 301 integriert hat und steuert, erst auf die neueste Core-Version bringen können,
wenn ich alle "Breaking Changes" von den 2022er HA-Versionen analysiert und im Griff habe.;) ("never change a running systen").
Was MQTT angeht, gibt es ja keine Unterschiede, da die beiden TRV beide mit der FW 2.1.3 ausgestattet sind.
Daher schaue ich mir das Verhalten auf dieser Ebene an, z.B. per externem Temp-Sensor (ESP32 mit DHT22 z.B.) .
Woher kommt eigentlich diese Info?:
"Dank @chemelli74 können Sie jetzt die Ventile dieser brandneuen Shelly TRVs steuern!"
Hallo, heute habe ich einen 2. TRV in Betrieb genommen.
Das ging diesmal ziemlich reibungslos.
Denn nach Betätigen des Reset-Knopfes kam wie in der Anleitung beschrieben "CL" und die erste Calibrierung lief.
Dann erschien kurz ein Punkt "." im Display. Danach Ruhe.
Diesmal habe ich am Notebook mal geschaut ... und siehe da: Der TRV hat seinen AP aufgemachtr, ohne es am Display mit "AP" anzuzeigen (wie es in der Anleitung steht).
Ich konnte mich damit verbinden und WiFi Credentials , statische IP, DNS eintragen und nach dem Reboot tauchte auch ein Hinweis auf die aktuelle Firmware auf. 2.1.3
Nach Update kann jetzt die Testphase mit dem 2. beginnen.
Grundsätzliche Frage: Ist es eigentlich sinnvoll/gewünscht seine Erfahrungen hier kund zu tun? Und erreicht das ggfs. auch Shelly?
Frage deshalb, weil auf den Hinweis mit der HW-Revision Null Resonanz kam.
Ich war einfach etwas erschrocken, ich habe mehrere Geräte, die bei HW-Revision eine konkrete Version anzeigen. Davon kann es ja abhängen, ob eine (neue) Firmware überhaupt (sinnvoll) laufen kann.
Mir wäre auch sehr daran gelegen, dass die TRV noch besser werden, denn die Vorteile, die sie mit der MQTT-API gegenüber anderen Thermostaten haben wären neben dem Akku-Betrieb ein Grund für mich Fritz DECT 30x nach und nach abzulösen.
Die nicht-smarten für 15€ haben das schon länger .
Bei den "smarten" kenne ich nur einen: den neuen AVM Fritz DECT 302: (~69€)
Die Boost-Funktion ist ja noch neu. Vermutlich/Hoffentlich kommt da noch was (FW-Update) bzgl. Button-Steuerung.
Ich hoffe, dass es dahingehend auch eine Erweiterung bei MQTT Command topics gibt.
Was auch (noch) fehlt ist, dass man die Valve Position per MQTT setzen kann, oder habe ich was übersehen?
Wenn man z.B. die automatische Regelung ausschaltet, kann man nur über die Tasten oder WebUI (pos=x %) verstellen App habe ich nicht im Einsatz, weiss nicht ob es da geht,
Hallo, ich bin seit einer Woche Besitzer eines Shelly TRV, den ich mit HomeAssistant (HA) einsetzen möchte.
Der Start war - sagen wir mal - "spannend". Es waren noch nie so viele Versuche meinerseits nötig,
ein Shelly-Device zum Laufen zu bringen, wie mit dem TRV
Irgendwann war es dann soweit, es gelang ihn auf FW 2.1.3 v. 2.2.2022 upzudaten und in Betrieb zu nehmen
Habe als erstes mal MQTT eingerichtet.
Dabei fällt folgende Information in den "Settings" auf: (bei Nutzung des MQTT-Explorers zum Auslesen),
die der TRV regelmäßig ausgibt:
Topic: shellies/shellytrv-mr01/settings
Payload: (Auszug)
..
"hwinfo":{
"hw_revision":"dev-prototype",
"batch_id":0
},
..
Heißt das, meine Hardware ist ein "Prototyp (in) der Entwicklung"
Klingt irgendwie nicht gut.
Die Firmware (vor Update) war nebenbei auch seltsam:
20211130-135936/silabs_freertos@810aaa39+
Das Gerät scheint wohl schon eine Weile auf Lager gelegen zu haben.
Hallo, habe heute meinen 1. TRV in Betrieb genommen.
Nach ein paar Hürden (u.a. 01-Mode) hat es geklappt.
Da ich ihn mit HomeAssistant betreiben will, gleich MQTT enabled.
Dort zeigt sich das oben beschriebene Verhalten auch: Setzen der Target-Temperature per MQTT:
shellies/shellytrv-mr01/thermostat/0/command/target_t mit payload 22.3 wird abgeschnitten auf 22.0 (so angezeigt in MQTT Status und WebUI).
Es wird auch nicht aufgerundet, d.h. target_t = 22.8 wird ebenfalls zu 22.0.
Versuchsweise mit Komma gesandt (22,8), wird ebenfalls zu 22.0
Meine Vermutung ist, dass Allterco das so macht, da man mit dem 2-stelligen 7-Segment-Display ja auch keine Dezimalstellen anzeigen kann, sollte man da den Sollwert einstellen (wollen).
Vielleicht kommt ja irgendwann eine Firmware, die per horizontalem Scrolling sowas möglich macht und bewirkt, dass dann auch Dezimalstellen bei MQTT etc. akzeptiert werden.
Für mich ist es auch ein Rückschritt, denn meine Fritz DECT 301 konnten immerhin 0.5 Grad Schritte. Feinere Abstufungen als 0.5 halte ich auch nicht wirklich für sinnvoll.
Ach ja: Firmware des TRV ist 2.1.3 vom 2.2.2022
