Beiträge von borsti0

Soweit ich hier im Forum mitbekommen habe verhält sich ein Shelly der 2ten Generation (so wie mein Shelly Plus 2PM) anders mit BT-Geräten als ein Shelly der 3ten und 4ten Generation.

Bei mir läuft nach aktivierung des passiven scan-modus im HA direkt am Shelly ein HA-Script das für HA den "Scan" ausführt und die Daten der BT-geräte zur Verfügung stellt. Ist das bei Gen3/4-Geräten auch so?

Auf meinem Shelly Plus 2PM:

Ich nutze bei mir auch nur ein paar Shelly Plus 2PM als passive BT-Scanner.

Ich habe mal testweise eine entity disabled, das siehst du dann gleich in der "Übersicht":

Aber du solltest auch in der BTHome-Übersicht sehen dass du bei dem Gerät mehrere Entities (7Stk für einen Shelly BLU Door/Window) hast:


Beim Klick auf die "7 entities" rechts kommst du zur Entity-Übersicht für das jeweilige Device:

Da hast du dann nur die "Diagnostic"-Gruppe und nicht die "Sensors" bzw. "Events"-Gruppe aktiv.

Hast du schon mal alle Entities des Gerätes angeschaut ob da per Default was deaktiviert wurde?

Welche Firmware hast du den auf deinem Shelly BLU Door/Window drauf?

PS: Die Illumination ist quasi sinnlos wenn du nicht im Beakon-Modus bist, da ich nur alle 7h, wenn ich ein "I'm Alive"-Packet bekomme oder wenn wer die Tür/Fenster öffnet ein Update des Lichtsensors bekomme.

Im wesentlichen hast du, wenn die "normale" Kalibrierung nicht funktioniert kaum eine Option dem Shelly das zu "Faken".
Leider würden dann auch andere Komfortfeatures fallen, z.b. geht dann das direkte Positionieren auf z.b.: 65% nicht mehr, sondern nur mehr "fahre rauf" und "fahre runter" bis zum Endpunkt. Und ich glaub die Winkelstellung der Raffstores ist auch nicht möglich.

Hast du nicht die Option 1nen dieser Motoren zu besorgen und dir das mal vorab anzuschauen? Vielleicht kann auch der Support helfen.

Das Thema hatten wir auch schon öfters, u.a. folgendes führt zu ner Temperaturerhöhung:
- ECO-Modus DEaktiviert
- Relay aktiviert
- Bluetooth + Home Assistant (=> erhöhte CPU-Auslastung)
- allgemein hohe CPU-Auslastung durch z.b.: viele Scripte

Hast du ein Handbuch zu dem Gumax Sonnenschutzrollo?
Du hast ja nur wenige Optionen:
- Rollo kann direkt elektrisch lokal am Motor mittels Shelly 2PM Gen4 bedient werden
- du "opferst" eine Fernbedienung und lötest dir nen Shelly Plus Uni auf die Up/Down-Tasten drauf
- es gibt ein Gateway von Gumax das du verwenden kannst.
- Gumax verwendet ein "offenes" Funkprotokoll für das es einen Adapter gibt
- ...

Zum Thema "Winkelsteuerung":
Ich habe bei mir auch (unbekannte) Raffstores mit den "alten" Shelly Plus 2PM verbaut. Ich nehme aber an dass der Shelly 2PM Gen4 sich diesbezüglich genau gleich verhält.

Die "Slat position" wird im Webinterface (auch in der App?) aktiviert. Man muss dazu in "Open" und "Close"-Richtung jeweils die ZEIT angeben wie lange ein Öffnen/Schließen von 0° auf 90° dauert - bei mir ist das ~1sek. Das muss man selber für jedes Fenster/Fenstertyp vermessen.
=> Das ist leider "Handarbeit" und in Realität auch nicht recht genau. Vor allem bei voll geschlossenen Raffstores ist die Winkelsteuerung ganz anders als bei z.b.: 50% offenen Raffstores, da das "Seil" ganz unten nicht bereits vorgespannt ist.

Parametrierung:

Steuerung über Webinterface (Raffstores sind UNTEN, Slats sind ganz OFFEN):


Steuerung über HA (Anderes Raffstore):



"Interessant" ist dabei, dass beim Öffnen der Slat's die angezeigte Position auch um 1-2 Inkremente nach oben geht - das scheint wohl noch ein internes "Berechnungsproblem" im Shelly zu sein.

Meine Schlussfolgerung:
- Winkelsteuerung funktioniert zuverlässig
- Winkelsteuerung relativ ungenau (50% Slat Position sind keine 45°) - ist aber meiner Meinung nach auch nicht viel besser umsetzbar
- Wiederholbarkeit ist sehr gut, d.h.: wenn man eine passende Position + Slat-Position gefunden hat kann man diese automatisiert jedes mal gut anfahren

Zitat von wotan2005

Nur leider wird die Leistung 0 Watt nicht zuverlässig per MQTT weitergeleitet.

Eben das meinte ich ja:
Entweder sendet der Shelly an sich beim Ausschalten nichts mehr (=> MQTT-Verhalten) und der Frame wird bei mir durch die Shelly-Integration im HA "emuliert" oder es verhält sich mein altes Gen2-Gerät an diesem Punkt anders und sendet dieses Event aktiv über das WLAN - das kann wohl nur ein Entwickler so wirklich beantworten.

schau mal bei den Anschlussdiagrammen für den Shelly 1 Gen3 nach, da findest diverse Varianten. Für deine Lampe ist wohl folgende Schaltung die Richtige:


Da du aber keine 2 Ausgänge hast brauchst du einen 2ten Shelly den du mit dem Input-Signal über WLAN bediehnst.
=> Das hat Krauskopp gemeint als er oben geschrieben hat du könntest das mit einem Shelly 2PM Gen4 lösen, da dieser 2 unabhängige Relays in 1 Gerät hat.

Schaut also nach nem interessanten Jahr aus mit all diesen neuen 1st-Party auch auch "externen" Produkten.

...könnte natürlich sein, und vor allem ist das ja auch noch ein Gen2-Gerät, vielleicht haben sie bei den Gen3/Gen4 auch was in SW oder HW diesbezüglich geändert.

Wie "Robust" sind denn die Shelly's, die kann man doch nicht so einfach im Außenbereich einsetzen, oder?
Ich nehme mal an dass direkte Feuchtigkeit (alias "Regen") mit Unterputzdosen gehändelt wird, aber Kondensation, Hitze und Kälte sind doch sicher problematisch, oder?

Ich finde es aber trotzdem lustig/interessant dass zumindest bei mir in HA+Shelly-Integration+NodeRED aktive events auch mit 0.0W geschickt werden, also irgendwo auf dieser Strecke "faked" dann offensichtlich doch wer die 0.0W (oder bei mir tun die Shelly's anders?).

Ich habe meinen Shelly Plus 2PM mit dem Raffstore auch nochmals "händisch" verfahren, da ich beim Vorherigen Test das Raffstore nur in die Endposition fahren ließ => da schaltet ja dann der externe Hardwareendschalter ab bevor das Relay ausschaltet und man sieht "schön" mit mehreren Events wie die Leistung abfällt.
Wenn ich jedoch eine aktive Fahrt händisch stoppe, dann sehe ich keinen "Leistungsabfall", es wird aber sofort 1 Event mit 0.0W empfangen => IRGENDWAS sendet dieses Event!!!

Vielleicht ist das auch der Grund warum ich beim 1sten Test 2 Events mit 0.0W erhalten habe:
- 1stes Event wenn Raffstore in Endlage fährt und Strom/Leistung physikalisch abfällt
- 2tes Event wenn Shelly Relay ausschaltet und "irgendwie" ein 0A bzw. 0W-Event verschickt.

Zitat von tvbshelly

Wie kann man bei einem offenen Stromkreis (Relais off) Stromfluss messen? Ich verstehe es so, dass man hier maximal per Software "behaupten" könnte, es fließt 0A und das macht Shelly eben nicht.

Naja, was zeigt denn dein Ampermeter an wenn du die Strippen nicht anhängst: die REALEN "0.0A" +- Rauschen.
Der ADC sollte ja unabhängig sein vom Relayzustand, somit sollte ja auch nichts dagegensprechen auch be geöffnetem Relay den Stromfluss zu messen und die ~0.0A zu übermitteln. Da man aber auch weiß dass kein Strom fließt kann man diesen Wert natürlich auch faken, aber trotzdem gehört er übermittelt!

ist es nun eigentlich ein Problem dass bei ausgeschaltetem Relay keine 0W angezeigt werden oder werden im Allgemeinen keine 0W angezeigt?
Mich wundert auch bei ausgeschaltetem Relay warum der integrierte ADC nicht "das Fehlen des Stroms" sauber messen sollte, dies kann dann doch maximal eine Energiesparmaßnahme sein.

ein kurzer Test bei mir mit HA + Shelly-Integration + Node-RED + Debug zeigt dass zumindest an diesem Punkt 2x (warum 2x?) aktiv die 0W als event reinkommen:

ich nutze was auch immer im HA "default" im Hintergrund läuft, d.h.: Shelly-Integration und die default-Anzeige

Es scheint so als ob du Home Assistant verwendest: bei mir wird zumindest bei einem Shelly Plus 2PM in Kombination mit HA+Shelly-Integration sehr wohl der 0W-Wert übertragen/angezeigt.

Du kannst (zumindest im Cover-Modus) die physikalischen Inputs sperren. Wie du das lokal/remote "triggerst" weiß ich aber leider nicht.

Zahlt es sich da aus die Energie in Hitze umzuwandeln oder währe es sinnvoller diese Energie besser mit einem Akku zu einem anderen Zeitpunkt zu nutzen?

Zitat von trick17

Prüft mal sowas eher mit Ping und zwar nicht 3 Pakete, sondern lasst es dauerhaft laufen. Wenn man den Output beobachtet, sieht man gerne mal Hicks, wo einzelne Pakete (sogar doppelt) beantwortet werden oder gar nicht beantwortet werden. Hinzukommt noch die Laufzeit. Wenn ein Ping mehr als 100ms braucht, dann ist jeder HTTP Verbindungsaufbau einfach unglaublich zäh und kann in Summe sogar Connect-Timeouts verursachen.

Ist sicher ein guter Punkt: bei IoT sind es wohl sicher mehr "kleine" Packete die ZEITNAH verschickt werden sollen. Dafür ist natürlich sowohl Powerline als auch WLAN nicht gerade ideal. Ich habe aber bisweilen noch keinen brauchbaren "Vergleich" gelesen wie gut/schlecht die Latency von LAN/WLAN/PowerLine nun ist.