Beiträge von nicx*

Danke für die Erklärung, aber das hilft mir leider noch nicht bei meinem Knoten im Kopf. Daher noch ein Versuch:

Ich brauche/möchte doch gar nicht den Shelly für die korrekte Berechnung wenn ich Home Assistant nutzen kann. Die Summe der 3 Phasen (in deinem Beispiel 100+100-400) sind doch genau die -200W. Hierzu reicht ein ganz simpler Template Sensor in Home Assistant. Der Shelly reicht mir also als "doofer" Wertübermittler für jede Phase. Und das es eine Einspeisung ist erkenne ich am negativen Vorzeichen. Bei Bezug würde der Sensor positive Werte haben.

Den Gesamtverbrauch würde ich über einen Utility_Meter Sensor in HA abbilden, der dann eben wiederum den HA-Template-Sensor als Quelle nutzt.

Oder bin ich immer noch schief gewickelt und das funktioniert nicht?

Ich sehe das nicht anders, ich habe das Problem wohl schlicht noch nicht verstanden

Warum ist das nicht Sinn der Sache? Für mich schon, da ich Home Assistant einsetze und genau solch ein Dashboard nutzen möchte

Bevor ich mich Monate/Jahre über die fehlende Funktionalität des 3EM aufrege (was ich nicht tue) nehme ich einfach ein wenig Geld in die Hand (was in Relation zu den PV-Kosten nahezu vernachlässigbar ist) und kaufe 2 3EMs, Thema gelöst

Ok, dann anders gefragt: Wenn ich lediglich wissen will, wieviel Strom Richtung EVU ich insgesamt verbrauche, und dazu wieviel Strom ich insgesamt mit meiner PV produziere, dann benötige ich schlicht 2 Shelly3EM. Einen an der PV, einen vor dem Hauptzähler. Die Summenwerte der Phasen der einzelnen 3EM passen hier, die Differenz der beiden Summen ist das was ich an den EVU bezahlen muss. Ob saldierend oder nicht, kann mir egal sein.

Stimmt das so?

Kurze Frage: Hab ich das Thema richtig verstanden, das es nur ein "Problem" ist wenn man 1-phasig einspeist? Und im Umkehrschluss ist bei 3-phasigem Einspeisen das Problem nicht vorhanden?

hat sich zur rc5 aber nichts geändert so woe och das sehe. bin gespannt aufs changelog.

seit einsatz der 2.1.5-rc5 ist bei mir das calibration problem nicht mehr aufgetreten. falls bei euch das noch passiert könnt ihr die neue option "auto-calibration" aktivieren, dann sollte der trv sich selbst kalibrieren

auch das ist normal, es werden nur final versions als "new" erkannt, nicht rc-versionen.

die anzeige nach eingabe der url kannst du ignorieren, die hat noch nie gestimmt. schau direkt in der GUI des TRVs, da siehst du welche firmware installiert ist.

ok, nach ca 3-4 stunden hat sich die target temperature im raum eingefunden, dh es benötigt wohl schlicht mehr geduld und das regelverhalten ist recht träge, auch ohne AI. wundere mich zwar dass das ventil nicht 100% öffnet sondern um die 20% bleibt, aber nun gut:

ich sehe auf jeden fall eine erhebliche verbesserung des verhaltens bei deaktivierter AI. zudem ist der interne temperatur sensor endlich nutzbar.

nein, wenn das update durchlief wird auch die 2.1.5-rc5 in der GUI angezeigt.

erstes kurzes feedback zur rc5 ohne AI:

Das Deaktivieren der Temperatur-Correction funktioniert wie gewünscht, die gemessenen Temperaturen am internen Sensor sind in meinem Fall nun genauer und passen.

Allerdings, und das ist ja viel schlimmer: Das Regelverhalten ist nach wie vor falsch:

Rt = 12610.76; tC = 20.77; state.tC_sm = 20.77; state.tC= 20.77

1648885380.795 minutes_tick:    Target: 22C; Current: 20.77C; Correction: -0.28C; Pos: 0.00% -> 0.00%

Warum macht das Ventil hier nicht auf??? So langsam bin ich drauf und dran die TRVs abzuschreiben... so ein Mist hab ich nicht mal mit China-Thermostaten gehabt.

mit dem gestrigen release der 2.1.5-rc5 ist eine option hinzugekommen die AI-correction komplett zu deaktivieren. das würde das regelverhalten der shelly trvs dann meinem verständnis nach eher den konkurrenzprodukten wie zb homematic angleichen, also ohne "schlaue" AI, sondern simpel nach vorhandener gemessener temperatur am internen/externen sensor

das werde ich jetzt mal ausgiebig testen, ich hoffe damit ist zumindest das problem mit dem überheizen/unterheizen bei nutzung des internen tempsensors dann gelöst.

auch für alle nutzer mit einer witterungsgefphrten heizungsanlage schötze ich mal dass dies dann besser funktioniert, da hier ja je nach aussentemp unterschiedlichste wassertemperaturen am trv ankommen und daher die AI überfordert ist.

das ist ein bekannter bug mit der 2.1.4. es gibt seit gestern die rc5 für die 2.1.5 wo das behoben sein soll. update über zb http://192.168.1.65/ota?url=http:/…RV-01_build.gbl (ip adresse natürlich anpassen)

War mit Dimitri dazu im direkten Austausch in den letzten Tagen: Seine Sicht der Dinge ist eher dass die Software hier kein Problem hat, sondern die "integrierte AI" korrekt ihren Dienst tut. Es läge an meinen Räumlichkeiten in Verbindung mit meiner Heizanlage. Er empfiehlt grundsätzlich einen zusätzlichen externen Temperatursensor um das "Problem" zu mildern.

Ich persönlich sehe das natürlich anders, vor allem da die ach so tolle AI ja auch von Shelly als Grund für den hohen Preis angepriesen wurde. Und genau von einer AI erwarte ich eben auch, dass sie in verschiedensten Umgebungen korrekt und zuverlässig funktioniert, damit sie ihren Namen verdient.

Schlussendlich hat Dimitri allerdings in Aussicht gestellt, in einer kommenden Firmware Version die AI über die GUi deaktivieren zu können. Damit würden sich meiner Meinung nach die Shelly TRVs dann vergleichbar verhalten wie Konkurrenz-TRVs. Das werde ich noch testen sobald verfügbar. Wenn das funktioniert wie gewünscht kann ich damit leben, ansonsten verkaufe ich wohl eher alle meine 12 TRVs wieder.

Schade grundsätzlich ums Produkt und den bisher guten Ruf der Shellys (zumindest der Gen1 Shellys). Preis/Leistung finde ich nach wie vor grenzwertig. Aber positiv hervorzuheben ist auf jeden Fall der direkte Kontakt und Support, inkl. der Versuch pber zusätzliche funktionalitäten der Software alle zufrieden zu stellen. Den zahlt man halt auch mit. Ich bin mal sehr gespannt ob es klappt

hier nochmals ein ganz aktuelles beispiel:

thermostat zeigt 21 grad temperatur bei einer zieltemperatur von 22 grad an und ventil ist 100% offen. der raum selbst ist bereits 22.3 grad warm (gemessen mit einem aqara sensor und einem nicht smarten sensor). nach reboot des TRVs zeigt es 22.2 grad an, das ventil ist bei 0% geschlossen.

das sind 1.2 grad differenz! das ist krass. ohne reboot hätte sich der raum komplett überhitzt. so ein verhalten kann einfach nicht korrekt sein.

Vor Reboot:

Rt = 11651.31; tC = 22.20; state.tC_sm = 21.53; state.tC= 20.97

1648553220.152 minutes_tick:    Target: 22C; Current: 21.53C; Correction: -0.67C; Pos: 100.00% -> 100.00%

Nach Reboot:

Rt = 11647.79; tC = 22.20; state.tC_sm = 22.06; state.tC= 22.18

1648553760.793 minutes_tick:	Target: 22C; Current: 22.06C; Correction: -0.14C; Pos: 0.00% -> 0.00%

Vor Reboot:

Nach Reboot:

Ich möchte nicht für jeden Raum einen externen Sensor kaufen und nutzen, nur damit die Temperatur vom TRV richtig ausgegeben wird

Habe das Verhalten nun nochmals mit der RC4, einer RC5 (die ich von Dimitar Dimitrov via Facebook bekommen habe), und auch der Final 2.1.4 getestet:

Vor dem Reboot des TRVs zeigt der interne Temperatursensor 21.5 Grad.

Nach dem Reboot des TRV zeigt der interne Temperatursensor 20.9 Grad.

Die Spreizung von hier 0.6 Grad ist für mich nach wie vor schlicht zu groß, egal wieviel "Intelligenz" der TRV in Abhängigkeit zu Raumgrößen mitbringen mag. Und die Spreizung steigt ja mit der Zeit noch weiter an

Zusätzlicher neuer Bug mit der 2.1.4: Nach einem Reboot springt die Zieltemperatur auf "Hi" anstatt auf die Temperatur des eingestellten Schedules.

Man man man... die TRVs bzw. die Software scheint mir *sehr* ungetestet auf den Markt geschmissen. Den echt sehr guten GEN1 Devices scheint sehr wenig Qualität nachzukommen.

Anhand welcher Parameter wird aber denn die Correction ermittelt ohne externen Sensor?

Wie gesagt: Im Vergleich zu anderen Raumsensoren ist die tC ohne Correction viel näher am realen Raumwert als die korrigierte Temp. Das führt unweigerlich zu falschem Verhalten der Regelung in Bezug auf die richtige Raumtemperatur.

Das war direkt nach dem Reboot. Ich nutze keinen externen Sensor.

Ich frage mich nach wie vor wozu diese Correction gut sein soll, wenn man *keinen* externen Sensor benutzt. Die Abweichung die hier entsteht beeinflusst ja direkt das Regelverhalten, und nach meinen Tests würde das alles nicht problematisch sein wenn einfach grundsätzlich der "tC" Wert genutzt würde (wie gesagt nur bei der Konstellation ohne externen Sensor). Im Vergleich zu testweise im Raum platzierten anderen Sensoren (Aqara u.a.) ist der tC Wert immer recht genau im Bereich der anderen Vergleichssensoren.

Woher kommt diese vermaledeite überflüssige Correction?

Leider ist das Problem mit dem internen Temperatursensor auch nicht mit der neuen Firmware gelöst. Sehr schön eben nochmals nachgestellt und im Logfile ersichtlich:

Vor dem Reboot des TRVs:

Rt = 12152.28; tC = 21.43; state.tC_sm = 21.24; state.tC= 20.86

Nach dem Reboot des TRVs:

Rt = 12119.83; tC = 21.48; state.tC_sm = 21.48; state.tC= 21.41

"state.tC" ist wohl der Wert der nach aussen angeziegt/reported wird. "tC" hingegen ist der echte gemessene Wert. "tC" ist auch stets korrekt, das wäre der Wert den ich auch nach aussen erwarten würde.

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