Beiträge von maxrw377

Moin,

ja ist blöd, dass der defekte 1PM nicht mehr da ist. Aber da sich Reparatur kaum lohnt (war auch schon 2,5 Jahre alt) habe ich da nicht lange drüber nachgedacht.

Das Denken kam erst als ich ihn durch einen anderen ersetzen wollte, und überlegte, durch

Leistungsauswertung in HA den Ausgang zusätzlich gegen den jeweiligen Schaltzustand zu prüfen, mittels der

MQTT-Values, die er sendet.

Da fiel dann auf, dass im Sollzustand AUS gar keine Leistung gemessen, bzw. reportet wird (UI und MQTT).

Die Fw-Version beim getesteten ist wie gesagt 1.11.8.

Dort gibt es eine "Max Power Protection" (muss irgendwann dazu gekommen sein).

Gut, da du schon mal Max heisst, probierst du das besser auch mal aus

Habe also eine LED-Lampe (6W) und - manuell zuschaltbar - eine Glühlampe (60W) angeschlossen.

beide Lampen an: power: 68.03 W

LED-Lampe allein: power: 6.04 W

Unter "Max Power Protection" habe ich 30 (W) eingetragen.

Zuerst war nur die LED-Lampe aktiv, es wurden die 6 W gemessen.

a) "Normal"-Zustand (Relaisausgang auf Platine NICHT gebrückt)

Bei Zuschalten der Glühlampe passiert folgendes:

Nach ca. 1sec schaltet der Shelly ab, gibt Blitzsymbol und "Overpower 68W" in der UI aus.

MQTT:

b) "Fehler"-Zustand (Relais gebrückt)

Die Überlast wird gar nicht bemerkt, da im OFF Zustand eben nicht gemessen wird!

Das ist aus meiner Sicht ein fataler Fehler und verbietet eigentlich einen Einsatz des Shelly (auf jeden Fall im Heizkeller).

MQTT:

HA/MQTT-User relevant:

Der "erweiterte" MQTT-Relay Status "overpower"

-> shellies/shelly1pm-burner/relay/0 = on / off / overpower

führt dazu, dass overpower so nicht erkannt werden kann, da derzeit die payload nur on oder off sein darf.

Da muss ich wahrscheinlich in HA ein Template benutzen, wenn ich denn mit Shelly weitermache.

Der overpower_value wird zudem nicht zurückgesetzt, wenn die Überlastung nicht mehr vorliegt.

@thgoebel: Wäre es denkbar, das obige mit der "Max Power Protection" auch mal mit dem 1PM Plus zu testen? Könnte relevant sein.

Ich meine gelesen zu haben dass Mitglieder sogar Ausgänge ihrer Solar-Wechselrichter über 1PM und 1PM Plus betreiben (wollen), was ich jetzt definitiv nicht mehr tun würde.

Das Ticket habe ich (in Deutsch) erstellt, muss es noch übersetzen, dann geht es raus.

Die hier geschilderte weitere Erkenntnis mit (nicht-) Overloaderkennung kommt natürlich auch rein.

Frage: Darf/Soll ich das Forum erwähnen, denn die Diskussion mit Euch war sehr hilfreich und ohne die Empfehlung ein Ticket zu eröffnen, würde ich es vielleicht nicht tun.

Zitat von Loetauge

Ja bitte erstell dieses Ticket, dein vorliegendes Problem ist ein gerechtfertigter Ansatz die Firmware dahingehend anzupassen, das trotz deaktivierten Ausgang eine Fehlermeldung generiert wird wenn ein Verbrauch ermittelt wird. Was ein geiler Bug, Glückwunsch.

Danke

Ja, werde Ticket erstellen. Halte es schon für sicherheitsrelevant, weil es lange unbemerkt blieb.

Wollte aber erst mal in die Runde hier fragen. Tolles Forum!

Die Fritzbox meldet übrigens doch was als Push-Email, wenn alles, was möglich ist, eingeschaltet ist:

"Stecker Samsung Verbindungsverlust" , obwohl die Verbindung noch da ist

Aber besser als nix, so schaut man vielleicht gleich in die UI wo der konkrete Fehler steht.

AVM kriegt also auch noch ein Ticket;

Schönes Wochenende!

Moin!

Ich hoffe, die Bratwürste haben geschmeckt;)

Die Last die der Shelly schaltete, war eine Pumpe im Heizkeller, also induktive Last.

Der defekte Shelly ist bereits in die Tonne gewandert und durch einen anderen ersetzt worden.

Für mich ist die Ursache auch erstmal zweitrangig, denn die Dauereinschaltung

der Last kann (auch ohne Kenntnis der konkreten Schaltung) m.E. mehrere Ursachen gehabt haben:

a) "Kleben", also verschmelzen der Relais-Kontake im Lastkreis oder

b) defekte Reails-Ansteuerung Transistor/ MOSFET oder sogar

c) defekter Output-Port des Prozessors.

Für Fall a) mag es ggfs. Schutzvorrichtungen geben können, für b) und c) sicher nicht (von Seiten des Anwenders).

Der Fehler wurde zufällig entdeckt, denn aus Sicht Shelly (und HomeAssistant als "Auswerter") war ja

scheinbar alles ok: Schalter = OFF, Leistung = 0.

Den Thread habe ich eröffnet, weil mich irritiert hat, dass die Leistung ("Power") offenbar nur dann wirklich gemessen und angezeigt wird, wenn der Sollstatus = ON ist,

andernfalls jedoch = 0 ausgegeben wird.

Der "Energy" Messwert als Verbrauch per Zeiteinheit ist dann logischerweise auch falsch.

Die Messeinheit muss ja grundsätzlich noch in Ordnung gewesen sein, da Wert bei ON-Zustand beim defekten Shelly im plausiblen Bereich war.

Das ist für mich also "des Pudels Kern";)

Den Shelly1 PM habe ich u.a. deshalb eingesetzt, weil er neben der Schaltfunktion (ausschließlich per MQTT)

sowohl die Leistung messen kann als auch per detached-Input den Schaltzustand eines ganz anderen Verbrauchers melden kann.

Das ist schon ziemlich cool bei den Shelly-Switches.

btw.: Bei HomeAssistant habe ich ein Issue wegen des Fehlers bei der FB Smarthome-Integration eingestellt.

Der Entwickler hat bereits einen Fix vorbereitet, der demnächst in den Core einfließt, so daß das (simulierte) Problem bei

defekten Fritz Dect 20x erkannt wird (und nicht die ganze Integration auf die Nase fällt;)

Jetzt fehlt nur noch eine Reaktion von Allterco

Wenn das Verhalten per Firmware-Anpassung gelöst werden könnte,wäre das sehr zu begrüßen!.

Es scheint ja sowohl bei 1PM als auch 1PM Plus vorzuliegen (letzteren habe ich ´noch nicht im Einsatz).

Weil es mich interessiert hat, was die Konkurrenz in so einem Fall macht, habe ich mal einen meiner FritzDect 200
modifiziert:

Solange die Dose ausgeschaltet ist UND keine Last eingesteckt ist, ist alles OK.

Wenn bei gebrückten Relais-Kontakten eine Last angeschlossen wird ohne einzuschalten, wird

a) die Leistung weiterhin gemessen und in der UI angezeigt

b) obiger Fehler ("Relais oder Messeinheit defekt") in der Fritzbox UI ausgegeben.

Was bei AVM leider fehlt ist, dass eine Push-Nachricht zu diesem Fehler geschickt wird.

Wäre kein Problem, da ich mit HomeAssistant (mit Fritz Smarthome Integration) ja den Messwert

mit dem Sollzustand vergleichen könnte um den Fehler zu melden.

Könnte....

Leider hat die HA Integration genau hier einen Bug. Sie erwartet bei Switches offenbar die Stati "0" oder "1", der als

Integer interpretiert werden soll.

Offenbar kommt aber (lt. Debug-Log) der state = '' (leer).

Das führt nach kurzer Zeit dazu, dass ALLE Entities der Fritzbox in HomeAssistant "unavailable" werden, also auch kein Leistungswert und kein Schaltzustand mehr kommen, die man auswerten könnte.

Sorry für den Ausflug zu HomeAssistant und AVM. Aber vielleicht ist es doch für den einen oder anderen interessant.

Ich denke, dass Shelly das per Firmware lösen können sollte. Es kann eigentlich nicht sein, dass ein Verbraucher (z.B. Pumpe im Heizungskeller) unbemerkt ständig läuft, weil das Relais klebt (oder die Treiberstufe Transistor/MOSFET) defekt ist.

Sehe es auch nicht direkt als Fehler.

Mag sein, dass es aktuell "works as designed", aber wenn ich z.B. länger außer Haus bin und

es nicht bemerkbar ist, daß eine größere Last nicht wie programmiert ausgeschaltet wurde

sondern unbemerkt weiterläuft, dann ist dass m.E. schon nicht sehr "smart".

Wäre schön, wenn sich das per Firmware-Patch ändern ließe..

Zitat von thgoebel

.. Es kommt noch schlimmer: Schaltet man nach dem Ausschalten das Relais wieder an, verharrt der Shelly auf der 0W- Anzeige! Nur ein Reboot hilft aus dieser Klemme!

Das wiederum ist bei meinem 1PM nicht der Fall,: Wenn er wieder eingeschaltet wird, erscheint nach ein paar Sekunden auch wieder der Messwert in der Anzeige.

Hallo zusammen,

habe folgenden Fall:

"Klebt" das Relais des PM , d.h. der Verbraucher kriegt Strom, obwohl (softwareseitig) ausgeschaltet wurde, ist die angezeigte Leistung 0W.

Ist das so gewollt?

Ein Defekt des Relais ist so m.E. nicht erkennbar. (Strom trotz OFF-Zustand = Leistung > 0W = Fehler) .

Fw: 1.11.8

Ich sehe in den Settings der Version 2.1.5-rc4 zwei Unterschiede zu 2.1.4:

Die untere scheint der Schalter unter Device Calibration zu sein.

Was ist denn "t_auto" und wie/wo ist es änderbar?

Ist es das (unter "Device Calibration")?

Checkbox "Enable automatic correction"
If enabled, device will automatically correct calibration if needed

per Default nicht gesetzt (nach update auf 2.1.5-rc4)

Werde - ehrlich gesagt - nicht ganz schlau daraus. Was soll/kann das denn bewirken?

Unter "Calibration" habe ich bisher das Ausmessen des erforderlichen Ventil-Hubs/Drehmoments verstanden.

Zitat von Lilinator81

Generell sieht es jetzt schon viel besser aus.....wenn jetzt nur noch die HIGH-Stellung nach dem Reboot behoben wäre, könnt ich damit leben-macht doch wenigstens LOW draus-das is billiger

Das hatte ich heute als ich (testweise) den externen Sensor ausgeschaltet habe (mehr nicht, kein manueller Reboot!):

Ablauf: extern aus, es folgt Kalibirierungslauf (oder impliziter Reboot?) , dann HI als Sollwert.

Dass per Schedule für den Zeitraum ein Sollwert von 17° eingetragen ist, interessiert ihn nicht.

Erst beim nächsten Schaltpunkt übernimmt er wieder, was dort als Soll eingetragen ist.

Zitat von Lilinator81

b und c scheinen sich zu wiedersprechen sid aber beide auf "alte" Heizkörper ausgerichtet. b für Ventile, welche ganz eingedrückt wieder etwas Heizwasser durchlassen und c) für schwergängige, festgesetzte

Wo kann man das denn nachlesen, dass das die Anforderungen für die Optionen sind?

Interessiert mich, will es nur verstehen.

Ein Heizkörper mit Heimeier-Ventilkopf bei mir braucht "Force", damit er sicher "zumacht". Wenn Minimum auf 5% ist, bleibt das Ventil aber leicht offen, d.h. der Heizkörper bleibt immer leicht warm, auch wenn IST> SOLL.

Also für mich nicht nur scheinbar ein Widerspruch.

Wieviel "Force" also Kraft er braucht, um den Stift zu bewegen, sollte der TRV doch beim Kalibrieren ermitteln können?

Wie gesagt, der AVM braucht diese "Optionen" nicht, um zu funktionieren.

Zitat von svenni

Meine sind jetzt auf 2.1.4

Danke, meine derzeit auch.

Ich habe bisher nur 2 TRV im Einsatz, weil ich sie erstmal testen will.

Bisher bin ich mit AVM FritzDect 301 sehr gut gefahren.

An denen stört mich nur, dass

- man nur AVM-Produkte als externe Temperaturgeber/Sensoren nutzen kann

- die Zeitverzögerung zwischen Setzen eines neuen Sollwertes bis zu 15 Minuten betragen kann.

Letzeres ändert sich wohl bei den neuen FritzDect 302, da sollen es nur noch 5 Minuten sein.

Die liegen preislich (noch) auf dem Niveau wie TRV.

Bei den Shelly TRV ist auch für mich z.Zt. einiges sehr fragwürdig.

Einerseits ist von AI die Rede, andererseits gibt es solche Options-"Krücken" (sorry, so sehe ich das;) )

in der Konfiguration wie

a) "Accelerated heating" (bei Automatic temperature Control)

b) "Minimal valve position Limit"

c) "Force close"

zu a) Genau jetzt habe ich bei einem TRV eine Differenz zwischen Soll und Ist von 2.9 Grad.(Soll: 21, Ist 18.1)

Die Valve Position sitzt trotz dieser Differenz UND gesetztem "accelerated heating=on" auf 32,7%

Wo da die "beschleunigende" Wirkung sein soll, ist mir schleierhaft.

b) und c) widersprechen sich eigentlich:.

Wenn man zusätzliche "Force" braucht, um ein Ventil zu schließen,

dann dürfte doch eine "minimale" Valve Position (> 0) das wieder komplett verhindern?

Ist aber beides gleichzeitig setzbar

Die genannten Optionen sehen aus wie Schnellschüsse, die eingebaut wurden,

um einfach irgendeine Reaktion auf gemeldete Probleme zu bringen.

Bei den AVM-Reglern gab/gibt es solche Fummeleien jedenfalls nicht.

(andere smarte hatte ich noch nicht im Einsatz).

Positiv an Shelly ist, das durch die APIs und Logs es für Home-Automatisierer

sehr transparent ist, was passiert.

Aber irgendwann muss die Firmware auch einfach mal das tun, was sie soll:

Ein Thermostat so einzustellen, so dass es warm wird, dann - und nur dann - wenn es der Benutzer will

Zitat von svenni

Das update

Welche Version ist gemeint? (Scheint ja inzwischen eine 2.1.5 rc zu geben)

Zitat

Ist bekannt... wird behoben

Bin gespannt, wie das umgesetzt wird. Der TRV kann ja nur ganze Zahlen am Display ausgeben.

Zitat von PitchControl

Geht nicht

Bei mir hat die URI funktioniert:

http://<trvIP>/ota?url=http://repo.shelly.cloud/firmware/test/SHTRV-01_build.gbl

Zitat von nicx*

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

Wie das genau geht, kann nur Allterco beantworten. Es heißt ja, daß es mindestems 2-3 Tage dauert, bis der TRV sich u.a. an Raumgröße und Temperatur-Änderungsverhalten angepasst hat.

Z.B. könnte er 30 min das Ventil ganz aufmachen - dann zu - und messen wie sich sich die Temperatur am internen Sensor verändert.
Also eine Art "Impulsantwort" die ausgewertet wird.
Geht das schnell ist es ein kleiner Raum, dauert es lang ist er groß. Nur so als Beispiel, wie man sich der Optimalen Einstellung nähern könnte.

Ohne externen Sensor ist es halt schwierig.

Ich finde es gut, dass mit den TRV jeder externe Sensor, ob gekauft oder mit ESP32/8266 und DHT selbst gebaut, einsetzbar ist, indem man die API oder MQTT nutzt. Meiner Beobachtung nach ist es auch sinnvoll regelmäßig Updates der externen Temperatur zu liefern. Andernfalls läuft der Korrekturwert des TRV wieder weg. ZigBee-oder WiFi-Sensoren, die wegen Batterielebensdauer nur bei größeren Änderungen mal was senden, sind da schon nicht zu empfehlen.

Bei FritzDect muss man teure AVM-Produkte als externen Sensor nehmen. Wobei die Steckdosen den Messwert obendrein selbst verfälschen, wenn sie sich bei ihrer eigentlichen Aufgabe (Lasten schalten) selbst aufheizen, zumindestens bei größeren Lasten.

Die "überflüssige Correction" ist bei fehlendem externen Sensor notwendig.

Diekt am Heizkörper erreicht die Temperatur locker 3-4 Grad mehr beim Hochheizen, während man bei der Sitzgruppe noch friert.

Der Wert des internen Sensors entspricht erst nach Einregelung ungefähr der tatsächlichen Temperatur im Raum, also wenn das Ventil kaum noch auf ist, also nicht mehr "nachschiebt".

Andere Hersteller haben das gleiche Problem, sind aber nicht so transparent, wie Shelly, mit seiner API.

Habe 7 Fritzdect derzeit, die auch nur mit externen Sensoren (Dectsteckdosen , Schalter ) richtig regeln.

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.