Beiträge von borsti0

Da wir beruflich auch Leistungselektronik bauen (mehr im 10-200kW-Berewich) kann ich nur sagen:
Das Gerät muss u.a. in einem Klimaschrank thermisch getestet worden sein sodass es unter Vollast nicht zu Übertemperaturen kommen kann.
Solange "der Kunde" die absolute maximum ratings für die enviroment temperature einhält und das System die Ströme+Spannungen+Schaltungen überwacht, KANN es eigentlich nicht zu einem thermischen Problem kommen.

Darüber hinaus ist die Frage:
was/wem bringt es eigentlich was eine konkrete Temperatur zu wissen? Es kommen dann höchstens laufend Übertemperatur-Warnungen von Kunden die das Gerät "falsch" anwenden (=> auch ich war mal so einer ). Dabei funktioniert das Gerät dann trotzdem noch, womit man sich die Diskussionen sparen hätte können, oder es wird eben kaputt => dann kommt es eh wieder zurück zur Rep und der Kunde bekommt (hoffentlich) die Rückmeldung dass er das Gerät richtig einsetzen sollte!
Alle Bauteile die verbaut werden können darüber hinaus selber zu einem Problem werden (Defekt, Verfügbarkeit, Störungen) oder im schlimmsten Fall einfach kaputt gehen was das gesamte Gerät ruiniert.

Bei uns wird das im Wesentlichen so gelöst:
1) Das Gerät ist im Wesentlichen so ausgelegt dass es, wenn es innerhalb der Spezifikation betrieben wird, NICHT MÖGLICH ist eine Übertemperatur zu haben
2) Für kritische Komponenten wird ein "Referenztemperatursensor" verbaut (z.b.: 1x pro Gerät) von dem aus für jede Komponente ein Temperaturmodell (mittels Ströme, Spannungen, ... und thermischen Temperaturmodellen) berechnet wird. Das spart in Serie Kosten und ist darüber hinaus noch viel dynamischer für die Fehlererkennung, was somit auch noch einen besseren Schutz der Hardware bietet (<1 ms anstatt 1-3 sek)

Zitat von horkatz

Küche ist bei mir kein Thema, die liegt unmittelbar über dem Heizungskeller und hat und braucht keine Zirkulation. Die Aktionen funktionieren ohne Cloud, aber nicht ohne WLAN. Aber ehrlich, wann fällt das schon mal aus? Die Zeitpläne laufen auch ohne WLAN weiter, da der Shelly seine Uhr dann aber nicht synchronisieren kann, wird die Zeit langsam von der realen Zeit wegdriften. Nach Stromausfall ist sie ganz weg.

Mein persönlicher Ansatz bei all meinen "smarten" Systemen ist: wenn ALLES "smarte" ausfällt: funktioniert das System "grundsätzlich" noch?
=> Wenn bei der Zirkulationspumpe eine/mehrere Shelly's, WLAN oder die Pumpe ausfallen, dann kommst immer noch an dein Warmwasser, musst hald übergangsmäßig etwas warten bis es heiß aus der Leitung kommt. Dann muss man hald für ein paar Tage das Wasser "etwas laufen" lassen bevor man unter die Dusche geht bis der Shelly, das WLAN oder die Pumpe wieder "repariert" wurde.

...und in die "Automatismen" dieser Geräte einzugreifen ist meistens nicht empfehlenswert.

Nicht unbedingt, du gehst davon aus dass da mind. die CPU-Temperatur oder sogar 4 Relay-Temperaturen "analog" gemessen werden und somit als ADC-Werte vorliegen.

Die noch immer billigste Lösung ist einfach einen NTC zu verbauen und per Komparator einen "Temperatur ist zu Heiß"-Status and die CPU zu liefern. Man kann über die Komparatoren auch viele Sensoren in Hardware "verodern" und somit viiiele Punkte parallel auf Übertemperatur überwachen ohne mehr CPU-Pins/ADC's zu benötigen.

Obwohl ich auch in HA ein "Fan" davon bin zu "sehen" wie heiß sachen werden ist es für die Funktion nicht relevant ob die Sensoren, wo auch immer sie verbaut sind, nun 30°C oder 50°C anzeigen, solange sie innerhalb der Spezifikation sind.

Ich weiß ja nicht was du mit Sommer/Winterzeit umstellen willst: aber bei allen meinen "Jahreszeitenabhängigen" Automatisierungen (z.b.: Raffstores) habe ich nach ~2 Jahren die "4 Jahreszeiten-Modi" wieder eliminiert da ein Jahr nicht gleich läuft wie das Andere und sich auch unsere Gewohnheiten änderten. Auch bei der Heizungen sehe ich das AKTUELLE Klima relevanter als die Jahreszeit.
Ich habe nun quasi 1 Button pro Komponente (Heizung, Raffstore, ...) eingeführt der "händisch" gedrückt wird und sagt: "OK, ab jetzt will ich den 'Sommer/Winter-Modus' verwenden" - der Wird gedrückt wenn wir uns entschließen in diesem Jahr umzustellen.

Zirkulationspumpen-Laienfrage:
Ich stell mir bei solch kleinen Leistungen die Frage: WARUM braucht man da überhaupt eine Zeitschaltung? Geht es da um die 5W oder um andere Verluste/Effekte die man reduzieren will?

Rein preislich gesehen:
Der Shelly Plug S Gen3 hat selber auch 1W Verlustleistung.
Darüber hinaus kosten dich dich die 5W im "Dauerbetrieb" 5W*24h*365 = ~44kWh/Jahr, also ~10€/Jahr
=> Finanziell zahlt sich da der Aufwand erst nach vielen Jahren aus, und das mit erhöhter Komplexität und verringertem Komfort.

ich bin da über ein PDF gestolpert das u.a. einen Stecker zeigt der auch bei dir passen könnte. Obwohl sie dort auch vom WS90reden schaut das Kabel etwas anders aus.

Interessant war aber darin dass eine Versorgung mit einem "standard 12V-Netzteil" anscheinend etwas kritisch zu sein scheint.
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Wie heiß ist denn das Harz beim Vergießen? Hat sich vielleicht das Gehäuse verzogen oder sogar intern das Relay-Gehäuse?

Frage tvbshelly : Also dieses Tool kann einen "Shelly Pro 3EM" emulieren wenn man z.b. einen "Shelly 3EM" oder "Fronius smart meter" besitzt? Sollte/Könnte das nicht VIELEN Usern hier im Forum helfen einen "nicht kompatibles Smartmeter" in ein "kompatibles" zu adaptieren? Oder lese ich da was falsch?

Zum Thema "kombinieren von 2 Sensoren" bin ich auf dieser Seite auch über das supportete Input device "Home Assistant sensors" (und andere) gestoßen: Mit SO einem Zwischenstück kann man natürlich alles "kombinieren" was man will, da man es dann ja nur mehr als virtuellen Sensor freigeben muss und durch das "uni-meter" wieder als "Shelly Pro 3EM" darstellen kann.
=> Es gibt auch eine "fertige" Integration für Home Assistant.
Aber, natürlich: man braucht dann schon 2 Adapter (z.b.: HA + uni-meter) auf einem separaten Gerät, das wiederum Fehleranfällig ist, aber es scheint "grunsätzlich" hier einen Weg zu geben.

Hat das schon jemand hier im Shelly-Forum erprobt? Eine "Template-Lösung" für alle unzufriedenen User die das falsche Smartmeter haben währe sicher interessant.

ok,
1st: you are using an Addon - this will shourly impact the temperature because the temperature dissipation will be worse.
2nd: It seems that activating the Access Point basically implicitly disables the ECO Mode - at least this behavior happened when activating the Home Assistant Bluetooth Gateway-Script.
I don't know what the thermal impact is when activating the AP, but using a Shelly as WLAN-Repeater will almost certain increase the AP hardware Tx power consumption and increase the CPU utilization => that could cause to "disable" the ECO mode completely.

A few °C temperature increase with the last 2-3 major firmware releases in ECO mode is unfortunately "normal", so a temperature increase from 38.9°C=>41.7°C (all off, ECO mode On) is not of concern.
As you see the temperature at the Test with ECO mode Off did not increase at all (~61°C)

Despite this findings: do YOU need the AP "Gateway" functionality?
I think this option should be disabled to avoid unnecessary traffic at the WLAN channel.

Da bin ich leider kein Spezialist, aber ist es denn überhaupt möglich die BLU-Geräte bei "Plus"-Geräten (Gen 2) mittels "BTHome" einzubinden? Ich dachte das geht nur ab Gen3?
Es ist aber möglich diese als Bluetooth-Gateway zu verwenden.

Nun die Frage:
Wie "kommunizieren" das BLU-Gerät und der Shelly Plus 1 eigentlich bei dir?

Sehe ich das richtig dass du den Shelly Pro 3EM NICHT direkt bei deiner "Einspeisung" anbringen kannst sondern nur 2 getrennte Geräte in der Wohnung selbst (wo auch "mit Growatt" verbaut ist) und im Keller.

Dein Problem scheint also zu sein dass du nun 2 Messpunkte hast die du jedoch gesamt verrechnen willst wie wenn es nur 1 Shelly Pro 3EM währen.

Natürlich die blöde Frage: Du hast nicht die Möglichkeit den Shelly Pro 3EM direkt am "Verteilpunkt" zu installieren. Hast du dafür schon mit dem Hausbesitzer gesprochen?

Soweit ich weiß funktioniert das nicht 2 Shelly's so transparent zu "kombinieren" dass sie sich wie 1 Shelly verhalten. Das wirst du wohl nur mit einer überlagerten Regelung schaffen.

ich eben auch nicht , "out of my comfort zone".

Ich nehme mal an du musst ZUMINDEST die Rollläden vorher kalibrieren damit sie als "Rollläden" dargestellt werden.

ok, und nun hast du mich komplett aus der Deckung geholt: dies scheint mit Actions anscheinend nicht abbildbar zu sein (k.a. obs da noch "Workarounds" gibt), somit muss man dann wohl auf lokale Scripte umsteigen, und auch die verwende ich nicht.

Biiiiiiiiittte lass dir von einem anderen Kollegen helfen ein Script "richtig" zu schreiben bzw. lese dich in grundsätzliche Implementierungs "Do's and Don'ts" ein.

Ich kann dir hier nur eine kurze KI-Antwort geben die lt. meinen C/C++/VHDL-Kenntnissen konzeptionell nicht so schlecht aussieht.
=> Diese ist natürlich komplett ungetestet!!!

Mit der Vorgabe:

Generiere ein script für einen Shelly 1PM mit folgenden Bedingungen:
1) kurzer Tastendruck schaltet Ausgang für 20 sekunden
2) langer Tastendruck schaltet Ausgang für 3600 sekunden
ACHTUNG: erneutes kurzes Drücken des Tasters darf die Zeit aus Bedingung 2) nicht wieder auf 20 Sekdunden reduzieren

bekam ich folgendes script raus:

let SHORT_PRESS_DURATION = 20;     // Sekunden
let LONG_PRESS_DURATION = 3600;    // Sekunden
let LONG_PRESS_THRESHOLD = 2000;   // Millisekunden (2 Sekunden)

let relay_id = 0;
let input_id = 0;

let press_start = 0;
let long_timer_active = false;
let timer_id = null;

function activateRelay(duration) {
 Shelly.call("Switch.Set", { id: relay_id, on: true });
 if (timer_id) Timer.clear(timer_id);
 timer_id = Timer.set(duration * 1000, false, function () {
   Shelly.call("Switch.Set", { id: relay_id, on: false });
   long_timer_active = false;
   timer_id = null;
 });
}

Shelly.addEventHandler(function (event) {
 if (event.name === "input:" + input_id) {
   if (event.info.state) {
     // Taster gedrückt
     press_start = event.info.ts;
   } else {
     // Taster losgelassen
     let press_duration = event.info.ts - press_start;
     if (press_duration >= LONG_PRESS_THRESHOLD) {
       // Langer Tastendruck
       long_timer_active = true;
       activateRelay(LONG_PRESS_DURATION);
     } else {
       // Kurzer Tastendruck
       if (!long_timer_active) {
         activateRelay(SHORT_PRESS_DURATION);
       }
     }
   }
 }
});

Die Grundidee ist dabei: Das Flag "long_timer_active" verhindert dass wenn der "lange Timer" aktiv ist ein "kurzes Timer"-Event erkannt wird

Auweia, dachte das sind (trotzdem) 230V-Antriebe.
Und ich nehm mal an der Shelly 2PM Gen4 kann bei 24V den Ausgang nicht kalibrieren weil die Spannungs-/Strommessungen dann nicht funktionieren.

OK: dann "muss" man wohl ohne Kalibrierung fahren und kann im Wesentlichen nur mit "komplett auf" und "komplett zu" arbeiten. Ein teilweises Öffnen ist dann nur mehr sehr begrenzt/kompliziert möglich.
Ein Shelly 2PM ist trotzdem noch vorteilhaft da er die gegenseitige Phasen-Verriegelung (Up <=> Down) "automatisch" inkludiert hat.

Auch hier ein "nicht DS1000-User":
Frage: Warum kannst du die Fenster nicht kalibrieren? => Dies sollte immer zuerst "bevorzugt" werden um einen guten Betrieb mit Shelly zu haben.

Danach meine Gedanken:
Wenn du einen z.b.: Shelly 2PM Gen3 oder Shelly Shutter einsetzt hast du natürlich dann lokal keinen "Regensensoreingang".
=> Somit solltest du dann an "zentraler Stelle" die 5V (oder doch 24V?) des Regensensors einlesen (Shelly I4, Shelly Plus Uni, ...) und dies als zentrales "Fahre Zu"-Signal an alle relevanten Rollo-Shelly's über WLAN weiterleiten.

=> Du baust somit ein 2tes System auf welches das Potential hat langsam das "bestehende" System zu ersetzen. Du brauchst auch nur 1x den Regensensor einlesen.

Vielleicht verstehe ich das noch falsch => kannst du da eine Konzeptschaltung machen damit ich/wir verstehen was du genau zu machen versuchst?

Zitat von apreick

Hier der Beitrag von hier

Ich glaube meine Meinung/Auffassung zu dem Thema wurde bereits in jenem Beitrag genug breitgetreten, sry, kein weiteres Kommentar von mir mehr dazu....

Bist du dir sicher dass dir da deine "eingestellten Zeitgrenzen" nicht deine Beobachtungen verfälschen? Du hast ja Zeiten eingestellt (die wahrscheinlich halbwegs einer Fahrzeit entsprechen), ich bin mir nicht sicher ob diese beim Kalibrieren berücksichtigt werden.
=> Stell diese mal wieder auf "Default" zurück (bei mir sind 60sek voreingestellt) bzw. auf einen Sehr großen Wert (z.b.: 2xkomplette Fahrzeit)

Und bitte lyncht mich nun nicht: ich habe die KI befragt und es kam zumindest eine "vielleicht" plausible Antwort raus. Leider gibt er mir hier keine Sourcen sondern nur Links auf diverse Foren wo andere User wieder "empirisch" Tests gemacht haben.
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Dies korreliert aber zumindest mit meinen eigenen Beobachtungen: Damit die "Rain Rate" >0.0mm/h anzeigt muss es schon "relativ viel" regnen - anscheinend haben sie diese "Minimalgrenze" beim "Rain State" deutlich runter gesetzt oder entfernt. Ich habe auch schon gesehen dass der "Rain State" auch nur wenige Sekunden aktiv ist bzw. sehr oft mal zwischen Wet/Dry innerhalb 1 Minute toggelt.