Beiträge von borsti0

Anschlussdiagramme hier im Forum helfen auch öfters weiter:

Zitat von Dangermou5e

Wenn ich den Shelly dagegen in den Relay-Modus umstelle, funktionieren beide Relais und die Integration in HomeKit sofort einwandfrei – allerdings ohne Positionsanzeige oder Slider.

Der Relay-Modus ist an sich auch keine Lösung, denn dann hast du einfach ein Modul mit 2 unabhängigen Relay-Ausgängen - und so präsentiert es sich dann auch in Homekit, Matter & Co. Das hat dann mit Cover gar nichts mehr zu tun.
Darüber hinaus hast du dann (grundsätzlich) noch das Problem dass NICHT verhindert wird dass du auch beide Relays GLEICHZEITIG aktivierst, was bei einem meiner "Dummen" Motoren schon mal zu "lustigen Tönen" geführt hat und ihm sicherlich auch nicht sonderlich gut getan hat. => Dein "intelligenter Motor" wird das aber sicherlich nochmals separat verriegeln.

Im Wesentlichen glaub ich kann man für eine "gescheite" Einbindung in Homekit/Matter wohl nur 2/(3) Wege gehen:
1) einen Dummen Motor verbauen und den Shelly kalibrieren
2) Für deine Motoren incl. dem verwendeten Funksystem ein Matter-Fähiges Gateway kaufen (habe ich für mein Velux-System gemacht). Shelly wird dann gar nicht mehr benötigt.
(3) "Adapter" über Home Assistant & Co realisieren => das benötigt aber eine zusätzliche Steuerebene)

Du kannst z.b.: auch den bestehenden Up/Down-Taster/Schalter (Taster bevorzugt!!!) von einem der Shelly 2PM Gen4 auswerten lassen.
Per Software hast du dann u.a. auch die Option mehrere unterschiedliche Events der Tasten auszuwerten.

z.b.:
short push => fahre alle Rollos rauf/runter
long push => fahre nur Rollo 1 rauf/runter
double push => fahre nur Rollo 2 rauf/runter
tripple push => fahre nur Rollo 3 rauf/runter

Ich persönlich habe bei allen meinen Raffstores incl. Shelly 2PM Gen4 einen Taster verbaut und nutze folgende Parametrierung:
short push => Kippe lokales Raffstore um +-20% (lokal per default-funktion)
long push => fahre lokales Raffstore rauf/runter (lokal per default-funktion)
double push => fahre ALLE Raffstore in dem Stockwerk/Raum rauf/runter (remote über Home Assistant)

Als fast-Laie der Elektrotechnik sehe ich da aber einige "Probleme":
1) der 2te "verkehrte" Draht in der Schaltung in deinem Posting aus #24 startet und endet an der gleichen Stelle => da läuft dann GAR KEIN Strom durch.
2) Du baust darauf dass der unterschied der Leitungswiederstände auf diese Kurze Distanz relativ genau 1:X ist (ich verstehe deine Berechnung immer noch nicht wie du auf 20% kommst).
=> Da tragen dann natürlich bei weitem nicht nur die Leitungsquerschnitte, sondern auch beide Kabellängen, die Verbindungen an beiden Seiten oder möglicherweise sogar Lötungen zur Veränderung dieses Verhältnisses bei. U.u. sind sogar thermische Effekte und Qualität der Kabel ausschlaggebend.

Das erinnert mich an die neuen NVIDIA-Grafikkarten, wo 600W über "6 parallel geführte gleiche Leitungspaare" geführt werden => da brennen immer wieder mal Stecker ab, da diese
1) grenzwertig betrieben werden (ok, das Problem haben wir hier wohl nicht)
2) der ohmsche Wiederstand dieser "eigentlich gleichen Leitungen" niemals so gut beherrschbar ist.
=> Es fließen dort bei Tests oft mal anstatt 6*8.3A auch gerne mal 10A auf manchen Adernpaaren und 6A auf den anderen.

tinub : Da du mit der 1.4 wirklich bei offenem Eingang 53.7% rausbekommst und nicht 0% (oder sogar 100%) ist es mir wirklich sogar lieber "null" zu erhalten um nicht fälschlicherweise bei einem Drahtbruch zu glauben dass noch immer ~50% Spannung anliegen. Dies ist wohl in vielen Fällen in einem "gültigen Wertebereich" und fällt somit nicht gleich auf.

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.

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