Beiträge von maxrw377

Zitat von nicx*

Welche "doofe" Intelligenz des TRVs sorgt für das krass abweichende "state.tC"??

Wie lange lag der Reboot zurück?

Direkt nach Update/Reboot sind sogar alle 3 Werte genau gleich, s.u.

(der Wert des internen Sensors).

D.h. er muss sich wieder herantasten, weil er alte korrekturwerte wohl nicht speichert, ganz einfach.

Kriegt dein TRV Ist-Werte von einem externen Sensor ?

Wenn ja, regelt sich das relativ schnell ein (je nach Frequenz der zulierferung.)

11:41:42 Reboot

11:41:43 sntp_client_task: TZINFO DONE

Rt = 11401.01; tC = 22.59; state.tC_sm = 22.59; state.tC= 22.59

11:41:42 943608719.456 ext_temperature_set: External t received: 20.20

943608719.461 ext_temperature_set: External t correction: -2.41

11:42:00 : Rt = 11335.75; tC = 22.70; state.tC_sm = 22.46; state.tC= 20.26

11:44:00: Rt = 11336.44; tC = 22.69; state.tC_sm = 22.33; state.tC= 20.26

Bei mir kommen externe Werte alle 10 Minuten, bei Änderung sogar spätestens nach 5 Minuten.

Damit kriegt sich der TRV wieder sehr schnell ein. Ohne externen Sensor ist das schon nicht so leicht.

Zitat

Thanks for all reports. Next week we will speed up to release a new version which will fix reported issues.

That sounds good. I will watch it. I like the Shellies (because of their features concerning API, MQTT esspecially) otherwise I wouldn't put so much effort into troubleshooting, believe me

Zitat von nicx*

.. Der externe Sensor setzt zwar einen korrekten Wert zu dem Zeitpunkt der Übertragung, aber direkt danach beginnt die Abweichung wieder "anzusteigen".

Das habe ich auch beobachtet. Bei mir bekommt der TRV regelmäßig (alle 10min) ODER bei Änderung den externen Temperaturwert per MQTT. Daraus berechnet er jedesmal einen Offset, der zu Änderungen bei der Valve Position führt (sieht man im debug-Log).

Zwischen zwei externen Werten (die er intern zur Offsetberechung, also nicht absolut und direkt verwendet) schnappt er sich aber in unregelmäßigen Abständen , ca. 1-3 Stunden) den selbst (intern) gemesenen Wert, der beim Hochheizen schon mal 2-3 Grad höher liegt. Daraus folgt, dass er einen viel zu grossen Offset berechnet und das Ventil erstmal brutal zu macht (0%, wenn kein anderes minimum definiert ist).

Ich habe das mal mit einem weiteren Sensor direkt neben dem TRV verifiziert: Die Werte dieses Sensors und der Wert des internen Sensors des TRV (aus debug/log) stimmen weitgehend überein, beide sind bei Hochheizen 2-3 Grad höher als der Wert des ext. Sensors, der 3 m entfernt neben unserer Sitzgruppe misst.

Für mich ist das ein Softwarebug. Zwischen diesen "Fehlinterpretationen" regelt er eigentlich ganz gut. Allerdings wirft ihn so ein

falscher Wert ziemlich lange aus der Bahn, denn dann wechselt er lange zeit zwischen 0% und 10% bei der "Valve position", bis er

irgendwann wieder "Gas" gibt.

Zitat von marcuskl

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:

https://resources.saylor.org/wwwresources/a…ONAVOIDANCE.pdf

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).

Lilinator81 :

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€)

Boost an- und ausschalten

1. Drücken Sie am Heizkörperregler die Taste

1. (Boost-Funktion). Der Heizkörperregler heizt nun über den angezeigten Zeitraum auf höchster Stufe.
2. Falls Sie den Boost vor Ablauf des Zeitraums beenden möchten, drücken Sie erneut die Taste

1. (Boost-Funktion).

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