Beiträge von maxrw377

Nachdem ich nach obiger Rückmeldung gefragt habe, ob das Problem vielleicht nicht verstanden wurde,

kam heute noch dieses:

This is not a problem with our device, but rather how the device is made.

It cannot be changed.

Thank you for your time!

Wird jemand schlau aus der Antwort? Ich nicht so ganz. (also außer, dass sie NICHTS machen werden)

Aber ich denke, genug Zeit verschwendet. Ich werde noch vorhandene Shelly Schalter nur noch für Weihnachtsbeleuchtung bis ca. 20W einsetzen.

Alles andere ist mir zu riskant mit dem heutigen Wissensstand.

Ticket habe ich abgesetzt. Die - weniger befriedigende - Antwort:

"The devices is measure the consumption of the output when it's relay is ON. There is logically no consumption ot be displayed when the relay is OFF. "

Klingt stark nach Christian Morgenstern, oder?

"Und er kommt zu dem Ergebnis:
Nur ein Traum war das Erlebnis.
Weil, so schließt er messerscharf,
dass nicht sein kann, was nicht sein darf."

Zitat von thgoebel

Im übrigen ist ein Shelly kein sicherheitsrelevantes Bauteil.

Dann sollte Shelly den Menuepunkt Punkt vielleicht auch nicht "Safety" nennen.

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.