Beiträge von dewaldo

Zitat von horkatz

Es gibt auch noch den 3fach Push

Das wusste ich tatsächlich gar nicht. In den offiziellen Produktbeschreibungen liest man immer nur von 1xS, 2xS, 1xL. Aber stimmt, gerade in der API Beschreibung nachgeschaut, gibt auch noch 3xS. Von daher würde es rein von der Anzahl Ereignisse ausreichen, die 3 Gerätschaften mit 2 Tastern vollumfänglich zu bedienen. Allerdings wird es dann ein Mix aus Tastenzuordnung und Geräten, was nicht einprägsam sein wird. Die Idee mit einer 2. Gerätedose finde ich auch gut.

Im Prinzip kann man alle deine Fragen mit "JA" beantworten. Du kannst jedem Tasterereignis mehrere URLs zuweisen. D.h. kurzer Tastendruck Input 0 -> schickt ein oder mehrere Kommandos an 1 oder mehrere andere Shellys. Und das kannst du für alle Tasten-Ereignisse halt sehr weit ausreizen.

Jede Taste kann jeweils maximal 3 verschiedene Ereignisse erkennen, "1x kurz", "2x kurz", "langer Druck". Und jedem dieser 3 möglichen Ereignisse kannst du dann eine Aktion zuweisen, wobei jede Aktion wie schon geschrieben auch mehrere Kommandos senden kann.

Hier liegt es dann an dir, dass du dir überlegst, welche Bedienlogik ist für dich / euch eingängig und leicht anzuwenden und dann machst du dir am besten eine Tabelle mit Tastenereignisse und gewünschter Funktion und den nötigen URLs dazu und setzt das entsprechend im i4 dann so um.

Zu 1.) Bad:
Ich würde das z.B. so machen, dass ich die 3 Lichter nach der Entfernung zum Wandtaster logisch durchnummeriere, um es sich besser merken zu können. Und dann würde ich:

AKTION 1 = Taster0_1xkurz -> Toggle Befehl an Licht 1
AKTION 2 = Taster0_2xkurz -> Toggle Befehl an Licht 2
AKTION 3 = Taster0_lang -> Toggle Befehl an Licht 3

AKTION 4 = Taster1_kurz -> Open Befehl an Rollladen
AKTION 5 = Taster1_2xkurz -> Close Befehl an Rollladen
AKTION 6 = Taster1_lang -> Stop Befehl an Rollladen

Zu 2.) Schrankraum:
Hier merkst du ja selbst, dass man dazu pro Rollladen eigentlich 3 Aktionen braucht und fürs Licht 1 Aktion, also in Summe 7 Aktionen. Mit 2 Tastern sind aber nur maximal 6 Aktionen abbildbar, von daher musst du dich da für einen Kompromiss entscheiden.

Was ginge wäre hier eine Script-Lösung mit folgender Logik:
- TASTE 0 dient zur Auswahl des zu steuernden Aktors. Hier könnte man im Script z.B. so umsetzen, dass das Script zählt, wie oft man in kurzer Folge die Taste 0 drückt, z.B. 1x, 2x oder 3x und das merkt man sich im Script und die Anzahl legt dann das Gerät fest, das man bedienen will, also 1x = Licht, 2x = Rollladen1, 3x = Rollladen2.
Und mit der TASTE 1 kann man dann die Steuerlogik einbauen, also auch 1xkurz, 2xkurz, 1xlang, und darüber das gewählte Gerät steuern.

Ich würde aber, wenn ich hier unbedingt eine getrennte Steuerung der Rollläden wollte, schauen, dass ich dann einen 4-fach Tastereinsatz verbaue, da der i4 ja eh schon da ist und mit 4 Tastern hat man dann 12 mögliche Aktionen und kann wirklich jeder Taste fix ein Gerät zuweisen, das würde ich so machen.

Ändere Mal den Wert von "Active scan" in TRUE in Zeile 26 des Scripts und versuche es dann nochmal. Wenn das Script "passiv" verwendet, dann MUSS Gateway aktiv sein, weil sonst keine Scans durchgeführt würden. Vielleicht ist der Shelly da so intelligent, dass der das merkt und deshalb implizit die Gateway Funktionalität wieder aktivieren möchte

Wenn alle Geräte in der App und Shelly Cloud entsprechend vollumfänglich eingerichtet sind, Räume zugeteilt sind usw., dann kann man es auch über App machen wie horkatz geschrieben hat. Das Ergebnis ist dasselbe, die App trägt letztlich im Shelly dieselben URLs ein, nur dass es bei der Einrichtung evtl. komfortabler ist. Ich nutze die App nicht, von daher...

Ich weiß nicht, jemanden bezahlen, der das supportet, da wirst du langfristig nicht froh mit glaube ich. Das ist so vielschichtig mit allen Unterpunkten, das wird sehr kostenintensiv werden ... Klar, wenn Geld gar keine Rolle spielt, dann meinetwegen ...

Vielleicht habe ich hier auch ein falsches Gefühl, aber die Leute, die sich eine Synology NAS ins Haus holen, haben zumindest meist eine Affinität zu solchen Teilen, kennen sich einigermaßen mit PC, Netzwerktechnik usw. aus. Du schreibst ja, du nutzt schon allerhand Dienste bei deiner aktuellen DS, von daher würde ich das an deiner Stelle auch selbst angehen und lieber im Forum Support suchen, wenn du irgendwo hängst.

-> Migration der bestehenden NAS zwecks neuer leistungsstärkerer Hardware habe ich bislang 2x gemacht und hat wirklich ohne große Probleme funktioniert. Sofern du nicht alles grundlegend neu strukturieren willst, ist das der einfachste Weg.
-> Die alte 713+ kann ggfs. dann als Remote Backup Server dienen, der dann in der Garage steht.
-> Microsoft 365 sehe ich losgelöst von NAS und Infrastruktur, Backup seitens der NAS sollte dann mit Active Backup kein Hexenwerk sein.
-> Synchronisation Outlook mit Handy etc. sehe ich gar keinen Handlungsbedarf seitens NAS, wenn auf Microsoft 365 umgestiegen würde.
-> Surveillance Station, da höchstens mal prüfen, ob die Lizenzen übertragbar sind, falls mehr als 2 Kameras genutzt werden.

Du müsstest einen Dienstleister vollständig instruieren, welche Struktur du brauchst, welche Konten, das musst du ja alles im Vorfeld selbst planen. Und diese Planung der Struktur ist schon der halbe Weg, das kann dir auch keiner groß abnehmen. Dann würde ich den Rest vom Weg auch noch selbst gehen, zumal mit Vorerfahrung.

Ansonsten, wie agent47 schon geschrieben hat, NAS in dem Preissegment unter 1000 EUR mit dem Gedanken als Virtualisierungsserver zu planen halte ich auch nicht für sinnvoll. Klar, eine kleine Home Assistant oder ioBroker Linux VM, das läuft da schon gut drauf, nutze ich auch und ist v.a. dann aus Energiesicht auch sparsam.
Aber auch hier muss ich sagen, wenn du HA nutzen willst, allein die Zeit, die du dann investieren wirst, HA mit allen Belangen fürs Haus einzurichten, dann kannst du den Rest auch in Eigenregie angehen...

Ich habe leider keinen i4, um es dir daran ganz konkret zu erläutern. Aber es ist wirklich einfach. Es müsste beim i4 im Hauptmenü des Webinterfaces den Punkt "Actions" geben.
Den entsprechend anwählen. Dann siehst du die Übersicht konfigurierter Actions, in deinem Fall erstmal keine.

- Dann musst du auf "Create Action" tippen und dann wirst du mehr oder weniger durch den Prozess geführt. Zuerst musst du die Quelle wählen, die die Aktion auslösen soll, also vermutlich Input (1) laut deiner Beschreibung oben
- Danach musst du deiner Action einen Namen geben, z.B. Rollladen Auf. Die Eingaben für "Active time" lässt du leer. Da könntest du Zeiträume festlegen, falls z.B. nachts keiner die Rollläden bedienen können soll und die Kids nicht heimlich aus dem Fenster klettern können
- Als nächstes wählst du die Ereignisart, z.B. Input toggeld on. Bedeutet, sobald du den Taster betätigst und den Stromkreis schließt. Beim i4 kann es sein, dass du hier andere Ereignisse auswählen kannst wie Single, double, tripple push, long push etc. Da wählst du dann das aus, was den Rollladen öffnen soll, wie du oben beschrieben hast.
- Am Ende der Seite gibt es dann den Bereich "Then do..." Hier musst du dann "+ Add URL" auswählen.
- Im Eingabefeld musst du dann die passende URL eintragen, die an den entsprechenden 2PM im gleichen Raum das Kommando sendet, den Rollladen zu öffnen, schließen, stoppen, je nachdem was du brauchst.
- Anschließend "SAVE" und fertig.

Das musst du entsprechend dann 3 Mal machen, bis du 3 Actions hast für Öffnen, Schließen und Stopp.

Die URLs wären z.B. die folgenden: Statt "ipShelly" musst du natürlich dann jeweils die IP des Shelly eintragen, den du steuern willst.

ÖFFNEN:

http://ipshelly/roller/0?go=open

SCHLIEßEN:

http://ipshelly/roller/0?go=close

STOPP:

http://ipshelly/roller/0?go=stop

Alternativ könntest du auch die RPC-Schnittstelle des 2PM nutzen, dann sind die URLs etwas anders. Hier noch das Beispiel für ÖFFNEN als RPC Aufruf:

http://ipshelly/rpc/cover.open?id=0

Was für eine Lampe hängt denn dran ? Also Typbezeichnung ?

Vor allem bei per Phasenabschnitt dimmbaren LEDs (also oftmals Retrofit, die in Standard-Sockel (E14, E27, GU10) eingesetzt werden, ist das oft so, dass die LEDs vor allem in der ersten Hälfte gut in der Helligkeit variierbar sind, darüber tut sich nicht mehr so viel. Das liegt einfach daran, dass diese LEDs ein integriertes Netzteil haben, welches die LED versorgen muss. Die LED selbst kann nix mit dem zerhackten AC anfangen. Das Netzteil muss aus dieser "ungünstigen" Versorgung eine saubere Stromversorgung für die LED erzeugen und dabei den Strom zur LED in Abhängigkeit der Phasenabschnittstärke steuern. Dann kommt noch das Thema hinzu, dass der Dimmer2 sich kalibrieren muss, und da der Erfolg auch davon abhängt, wie sich so ein integriertes Netzteil dabei verhält, damit der Dimmer hier eine vernünftige Leistungs- / Helligkeitskurve einstellen kann.

Konkretes Beispiel: Ich habe in 1 Flur noch 2 Philips WarmGlow LEDs E27. Diese lassen sich wunderbar dimmen von fast komplett dunkel bis richtig hell. ABER: Es gelingt mir z.B. nicht, den Dimmer2 mit diesen 2 LEDs im Verbund direkt gut zu kalibrieren. Es endet dann damit, dass die LEDs oberhalb 80% anfangen zu flackern oder besser blitzen und nach unten hin nicht weit genug herunterdimmen und bei 1% noch immer recht hell sind. Geholfen hat hier, dass ich zur Kalibrierung 1 der 2 LEDs durch eine dimmbare IKEA LED ersetzt habe. Diese hat ein deutlich anderes Verhalten, zündet früher im Verlauf des Phasenabschnitts und der Dimmer2 ermittelt dadurch eine andere Leistungskurve. Wenn ich damit die Kalibrierung durchlaufen lasse und danach wieder die Warmglow einsetze, habe ich ein perfektes Ergebnis ohne Flackern oder Blitzen.

Ich will damit nur sagen, das Dimm-Verhalten hängt maßgeblich mit der Lampe zusammen und hier und da hat man noch Möglichkeiten zu tricksen. Z.B. hilft es auch, den Wert für "Anti Flickering Debounce" anzupassen. Meine Erfahrung ist die, dass es sinnvoll ist, VOR der Kalibrierung den Wert auf 150us zu stellen und nach der Kalibrierung dann auf 50us. Damit erhält man ebenfalls einen etwas weiteren Dimm-Bereich.

Noch eine Anmerkung, die aber jetzt zweitrangig ist, wenn du nur manuell steuerst. Die 2PM sind noch nicht kalibriert, zumindest der im Bild nicht, deshalb kennt er die aktuelle Position der Rollladenöffnung noch nicht. Das solltest du dann noch machen. Ansonsten, horkatz hat es ja schon geschrieben, in den Einstellungen des 2PM kannst du auswählen, dass die Zuordnung der Ausgänge gedreht wird, wenn rauf / runter vertauscht ist. Findest du, wenn du auf dem "Home" Bereich" unter Reverse direction, sieht man ja auf dem Bild schon, was du angehangen hast.

Und was ganz wichtiges, der 2PM im Screenshot hat die Software-Version 1.07. Inzwischen ist Version 1.4.4 aktuell. Von daher bitte bei allen 2PM mal ein Firmwareupdate machen.

Hi Kandel,

es fällt mir ein bisschen schwer, deinem Fortschritt so ganz zu folgen, was du jetzt wie bereits umgesetzt hast oder noch nicht.
Was meinst du mit "Schalter 0 für runter, Schalter 1 für hoch ? Was für Schalter ?

Bitte schreib mal ein bisschen ausführlicher, welche Schritte du jetzt schon gemacht hast, also:

- Welche Shellys sind wo installiert ?
- Wo sind welche physikalischen Schalter / Taster angeschlossen ?
-> Aktuelle Annahme: 4-Fach Tasterfeld an einem i4DC, keine Tasten oder Schalter an den Rollladen-Shellys ?
- Sind die Shellys der Rollläden inzwischen alle als Roller/Shutter konfiguriert, kalibriert und kannst du die Rollläden z.B. per App oder WebInterface korrekt bedienen, also rauf / runter und ganz wichtig auch über Positionsvorgabe ?
- Wie hast du die einzelnen Shellys in dein WLAN eingebunden ? DHCP oder feste IP ? Wenn DHCP, dann im Router zumindest eingestellt, dass die Shellys immer dieselbe IP zugewiesen bekommen sollen ?
- Kennst du alle IP-Adressen?

Da du oben schreibst, bisher könntest du nur die Rollläden per App bedienen über Schalter 0 und 1, vermute ich wirklich, dass du die 2PM noch nicht als Rollladenschalter konfiguriert hast.
Hier mal 2 Screenshots. Der 1. Screenshot zeigt das Webinterface eines 2PM, der als Rollladenschalter konfiguriert ist. Da gibt es nicht mehr Schalter 0 und 1, sondern nur rauf, runter, Pause (Stopp) + eine Schiebeleiste für eine Soll / Ist-Position

image.png

Und der 2. Screenshot zeigt einen 2PM, der NICHT als Rollladenschalter konfiguriert ist. Hier sind Kanal 0 und 1 unabhängig voneinander schaltbar, daher gibt es dann Output 0 und 1. Das wäre dann aber FALSCH. So besteht die Gefahr, dass man z.B. Ausgang 0 und 1 gleichzeitig einschaltet, was sowohl Shelly als auch Rollladenmotor beschädigen kann. Außerdem würde mit der Konfiguration die Scriptsteuerung vom i4DC aus nicht funktionieren,

image.png

Deshalb, bitte mal ausführlich beschreiben, wo du jetzt stehst und dann geht's hier gemeinsam weiter

Ich muss mich nun doch noch mal melden, weniger im Sinne von "Optimierung", sondern was ich auch schon mal angedeutet habe.
Gestern, beflügelt von der guten Scan-Ausbeute mit den den 120/40 Parametern, war ich mutig und habe zusätzlich mal einen BluButton in den Beacon Modus versetzt und auch den BluMotion weiterhin im Beacon-Modus belassen.
Dieser Blu-Motion wird genutzt, um über ioBroker das Licht im Bad zu schalten. Im Bad sitzt auch der Shelly 1 Mini Gen3, der als Gateway fungiert.

-> Nachdem ich den BluButton dann m Beacon Modus hatte und den zu Testzwecken mit im Bad deponiert habe, war es dann so, dass ich wenig später ins Bad ging, das Licht sich nicht einschaltete. Den gleichen Effekt hatte ich bereits die Tage zuvor, als ich 2 BluMotions im Beacon-Modus hatte.
-> Dass die Scan-Fenster im Shelly 1 Mini Gen3 das Signal "verpassen" kann man ausschließen nach den ganzen Tests und es geschieht auch sonst NIE, dass das Licht nicht sauber einschaltet. Von daher werfe ich erneut die Theorie in den Raum, dass die ganze Gateway Thematik offenbar Probleme damit hat, wenn mehrere zeitlich nahe aufeinander folgende Blutooth-Telegramme kommen.

Jetzt kann es halt sein, dass entweder der Shelly 1 Mini Gen3 die Ursache ist, wenn ein Telegramm empfangen wird und er dieses verarbeitet, formatiert, per MQTT übermittelt werden muss, dass dabei eine recht große Zeitspanne vergeht, während der andere Signale überhört werden können ?
Zweite Möglichkeit wäre evtl. beim Shelly Adapter im ioBroker zu suchen, welcher die MQTT BLE Botschaften entsprechend vorbehandelt, um die Inhalte den entsprechenden Datenpunkten zuzuweisen und dass hier evtl. auch Timing Effekte auftreten, die dazu führen, dass nicht 2 zeitlich nahe liegende Signale sauber aufgeschlüsselt werden.

Ich habe nach diesem Effekt bei allen Blu-Geräten erstmal den Beacon-Modus wieder deaktiviert, weil kein Licht im Bad, da ist dann nix mehr mit "Happy wife, happy life" ...

Zitat von Lapu-Lapu

vielleicht magst Du das bei Dir mal verifizieren.

Ich habe mal die Werte 120/40 im Shelly 1 Mini Gen3 gesetzt und kann hiermit eine ganz klare, positive Rückmeldung auch von meiner Seite geben.
Mit den Standard Scanparametern 200 / 50 habe ich beim BluMotion im Beacon Modus nur etwa jedes 4. bis 5. Telegramm mitbekommen, sprich alle 2-3 Minuten.
Mit 120/40 sieht das deutlich besser aus. Hier hatte ich jetzt über den Zeitraum von genau 1 Stunde genau 5 verlorene Telegramme. Der BluMotion sendet alle 30s. Ich zeichne die PID auf und habe im folgenden Screenshot mal die Differenzen der PIDs aufgetragen. Geht kein Telegramm verloren, dann ist die Differenz immer 1, außer im Moment des Überlaufs, wenn der PID Wert von 255 wieder auf 0 springt, wie im Graph bei 12:12 Uhr zu sehen.

So lasse ich das jetzt auch mal, vielen Dank für den Hinweis generell, dass man das Timing über das Script beeinflussen kann.

image.png

Da habe ich mich versehen, korrekt. Also ich fasse nochmal zusammen:

Über das Webinterface des Shelly lautet die korrekte Einstellung dann:

- Input mode: Switch
- Output type: Edge - Changes state on every change of the switch state

Die Shelly App verwende ich nicht, daher kenne ich die Bezeichnungen dort nicht, aber wenn das im Deutschen so formuliert ist, müsste die App entsprechend genau diese Kombination dann auch im Shelly konfigurieren.

Korrekt. Das ist bei mir absolut die entscheidende Maßgabe. Es muss so funktionieren, dass es zuverlässig klappt bei intuitiver Bedienung.

OT:
Ganz konkretes Beispiel. Ich habe im Sommer einen Shelly Uni an die Hausklingel angebunden, zwecks besserer Benachrichtigung, Austausch Klingeltaster, Stummschaltung bei Bedarf, Erweiterung mit Codeschloss usw.

Und als ich quasi fertig war, kam mir die Idee für eine kleine Erweiterung, die sehr praktisch ist. Wir haben eine Tiefgarage, durch die man auch ins Haus gelangt. Den Weg nutzen wir meist, wenn die Kids von draußen rein kommen und nicht "wohnzimmertauglich" sauber sind. Und da kam es schon vor, dass das Handy leer war und die Garage nicht von außen zu öffnen war. Also durch die Haustür rein, durchs halbe Haus rennen in den Keller und in die Garage... Und weil die Garage auch mit Shelly steuerbar ist, habe ich dann im Uni einfach so gelöst, dass die Dauer des Drückens des Klingelknopfs benutzt wird, um zu entscheiden, ob nach Eingabe des Zugangscodes der Öffner der Haustür oder ob stattdessen die Garage öffnen soll.

Ich hatte dann erst die Standard 800ms LongPush-Schwelle belassen und ich fand das perfekt und hat 1A funktioniert. Damit im Haus dann nicht der Hund amok läuft, weil man den Klingelknopf dabei drückt, leitet der Uni das Klingelknopfsignal nur dann zur eigentlichen Klingel durch, wenn das Drücken ein Short-Push war, als kürzer als 800ms gedrückt wurde.

Tja, das Ganze lief einwandfrei, bis 1 Woche später die Schwiegermutter zu Besuch kam und es plötzlich laut an der Tür klopfte. Beim Öffnen und auf meine Frage, ob sie denn nicht geklingelt hätte, kam dann ein DOCH, mindestens 3 Mal.
Also habe ich auf die Klingel gedrückt, sofort ertönte die Klingel. Mmh, dann habe ich meine Schwiegermutter gebeten, nochmal zu klingeln, um dann zu sehen, dass sie tatsächlich aus eigener Gewohnheit den Klingelknopf fast 2 Sekunden gedrückt gehalten hat und deshalb hat der Uni das Signal nicht zur Klingel durchgeschaltet.

Also habe ich die LongPush Zeit jetzt auf 2500ms gestellt. Garage öffnen klappt nun immer noch, man muss halt etwas länger gedrückt halten, dafür geht die Klingel jetzt immer !

Ich bin mir nicht sicher, ob das wirklich die korrekte Lösung war / ist. Ein Wechselschalter ist kein momentary Schalter, also kein Taster. Die richtige Einstellung wäre hier "SWITCH" und dann "Toggle".

Mit der Angabe ist nur gemeint, dass der Shelly grundsätzlich mit 230V AC, als auch mit DC versorgt werden kann und in dem Fall eben AC oder DC auch schaltet, wobei hier die Lastgrenzen bei AC und DC unterschiedlich hoch spezifiziert sind.
Hier ein Screenshot aus der offiziellen Bedienungsanleitung des 1Mini Gen3.

image.png

Zitat von HighFive

Somit kannst du zwar am L/N 230Volt anliegen aber beispielhaft zwischen i & O aber 24 Volt schalten, OHNE irgendeine elektrisch leitende Verbindung dazwischen

Hier noch der Hinweis, zumindest soweit ich das weiß, die "MINI" Varianten der aktuellen Shellys haben alle keine SELV Zulassung, von daher wäre diese Anwendung hier zwar technisch möglich, aber nicht erlaubt, also 230V Versorgung und Schutzkleinspannung über den potentialfreien Kontakt schalten. Da müsste man dann auf die großen Shelly zurückgreifen.

Danke für die Rückmeldung zu dem Thema der unterschiedlichen Timings. Ich werde da sicher mal noch bisschen testen, aber im Moment fehlt mir dazu auch die Zeit und ohne aktiven Beacon-Modus läuft es bei uns soweit auch zuverlässlich. Die Struktur drumherum muss halt auch passen, also gute WLAN Abdeckung, gutes Bluetooth Signal, da ist halt alles voneinander abhängig und man muss aufpassen, wo man die Schuld sucht, wenn was nicht richtig läuft.

Ich sehe das Thema mit dem "Spielzeug-Image" nicht ganz so drastisch. Ich bin beruflich Elektroingenieur / Software-Entwickler und ich bin eigentlich recht begeistert, was Shelly hier aus der günstigen Hardware macht und da finde ich Preis / Leistung ganz gut. Ich habe von der Grundeinstellung dann nicht die gleiche Erwartungshaltung, als wenn ich jetzt alles z.B. auf KNX aufbauen würde.
Gäbe es hier jetzt von Shelly dedizierte Blu-Gateways, und die würden dann 150 Euro kosten, dann hätte ich ganz klar andere Erwartungen und Ansprüche und dann wäre das auch nicht akzeptabel für mich.

Aber es ist schwierig, da jedem gerecht zu werden. Als "Spielzeug für den Mann" kann man das tatsächlch manchmal sehen, eine Mischung aus "Bastellösung" und "vernünftiger Installation". Die Kunst ist, dass es zumindest so gut funktionieren muss, dass man nicht die Chefin im Haus verärgert. Und in der Region sind wir nach meinen Erfahrungen zum Glück bei Shelly nicht oder sehr selten.

Ich sammle gerade viel Erfahrungen in diesem Thema und kann dir als kleines Feedback sagen, dass du mit solch einer Lösung nicht glücklich würdest, aus 2 Gründen:

1.) Im Beacon Modus sendet der Button nur alle 8s ein Telegramm, heißt je nach Weg zum Garagentor mit Vergleich der Signalstärke kann man schon mal länger vorm Tor stehen, bis es dann auf geht.
2.) Die Beacon Telegramme sind aus Stromspargründen deutlich kürzer als die "echten" Telegramme eines Tastendrucks. Dies führt dazu, dass ein Shelly Plus als Bluetooth Gateway die Beacon-Signale oftmals überhört, da der Plus-Shelly hier nicht lückenlos lauschen kann aus technischer Sicht. Und die Beacon-Telegramme sind einfach zu kurz, um sie sicher zu detektieren. Das kann dann ebenfalls dazu führen, dass man nochmals weitere 8s oder äänger wartet, bis ein Telegramm zur Auswertung empfangen wurde.

Technisch an sich würdest du das über ein Script im Plus-Shelly machen, was auch relativ gut machbar wäre. Als Anwesenheitskontrolle, z.B. Heizung im Haus steuern, da eignet sich sowas, aber nicht für kurzzeitige Anwendungen wie das Öffnen einer Tür oder Garage. Da macht es dann mehr Sinn, den Button des BluButtons auch zu verwenden und das Tor halt per Tastendruck zu öffnen, wenn man das will.
Ein weiterer Aspekt beim Garagentor mittels Annäherung im Beacon-Mode ist noch, dass der Plus-Shelly auch wissen müsste, ob das Tor gerade auf oder zu ist. Dazu müsste das Script also den Status der Garage auslesen. Falls du da einen REED Kontakt hast, geht das, aber da hätte ich persönlich z.B. zu viel Bammel, dass keine Ahnung, mal das WLAN streikt, der Remote-Status falsch gewertet wird und das Script den Impuls zum Schalten schickt, während man gerade mit dem Auto drunter durchfährt...

Heinzmann:
Ich fasse es mal kurz zusammen, am Anfang ist es da bisschen schwierig, den Überblick zu behalten:

Es gibt 2 Schwesterprojekte, die sich dem Thema Hoymiles DTU witmen, "OpenDTU" und "AhoyDTU". Beide sind vom Umfang her sehr ähnlich und unterscheiden sich nach meiner Einschätzung vor allem in der Optik des WebInterfaces, also Geschmackssache.

- Die Software "AhoyDTU" kann sowohl auf einem ESP8266, als auch auf einem ESP32 laufen, die Software OpenDTU läuft ausschließlich auf ESP32
---> Aber auch, wenn man sich für die AhoyDTU Software entscheidet, sollte man Hardware mit einem ESP32 verwenden, der ESP8266 ist einfach etwas zu schwach für die zuverlässige Anwendung.

- Hoymiles Wechselrichter vom Typ hm-xxxx. Diese arbeiten im 2,4GHz Band und benötigen zusätzlich zum ESP32 dann das Funkmodul nRF24L01 für die Kommunikation mit dem Wechselrichter.
- Hoymiles Wechselrichter vom Typ hms / hmt-xxxx arbeiten im 900 MHz Band und dafür braucht man dann zusätzlich zum ESP32 das Funkmodul CMT2300A anstelle des nRF24.
- Hoymiles Wechselrichter mit einem "W" hinter der Bezeichnung, z.B. hms-800W haben ein integriertes WLAN Modul und keine 900 MHz Schnittstelle und KÖNNEN NICHT mit AhoyDTU oder OpenDTU genutzt werden !

Bezüglich Einbindung im ioBroker kann ich sagen, beide Projekte bieten eine konfigurierbare MQTT Schnittstelle, als auch eine REST API, wobei man letztere nicht für eigenen Datenaustausch nutzen sollte, besser ist MQTT.
Hierbei unterscheiden sich dann die MQTT Topics doch sehr, weshalb z.B. die AhoyDTU NICHT zusammen mit dem ioBroker OpenDTU Adapter arbeiten wird, da passt die Struktur dann einfach nicht.
Verwendet man aber den OpenDTU Adapter nicht, sondern nutzt direkt die MQTT Schnittstelle, dann bieten beide Projekte ähnliche Möglichkeiten, z.B. Auslesen aller aktuellen Werte, Setzen von Limits, Ein/Ausschalten des Wechselrichters usw.

Ein letzter Hinweis:
- Es gibt bei diesen DTUs auch sogenannte Hybrid-Versionen, welche aus einem ESP32 Board + nRF24L01 + CMT2300A bestehen, mit denen man beide Wechselrichter-Generationen von hoymiles ansprechen kann, aber kosten auch teils das Doppelte...

Ansonsten preislich für fertig gebaute DTUs (falls man sie nicht selbst zusammenbauen möchte):
. Ca. 30 Euro für eine gute OpenDTU/AhyDTU für die hm-Serie (also nRF24 Modul)
- Ca. 35-40 Euro für die Varianten mit dem CMT2300A.

Danke für die Rückmeldung.
Ich habe gestern Abend auch nochmal mit den Werten etwas herumgespielt an einem Shelly 1 mini GEN3.
Dieses 1 zu 3 Verhältnis kann ich vom Gefühl her bestätigen. Ich muss dann aber auch leider sagen, dass die Werte 200 / 50 für den Beacon-Modus der BluMotion nicht gut funktionieren. Hier wird nur etwa jedes 3. bis 4. Telegramm registriert.

Bei einem Thema bin ich mir noch nicht sicher. Und zwar, was passiert, wenn kurz hintereinander 2 verschiedene Blu Geräte senden. Es kommt mir so vor, dass wenn das Gateway in seinem Scan-Intervall ein Bluetooth Telegramm empfangen hat, dieses ja dann auch verarbeitet werden muss und als ich 2 BluMotions im Beacon-Modus laufen hatte, wurde ein 3. BluMotion nicht mehr empfangen und das Licht im Raum ging nicht an. Das kommt nicht vor, wenn kein Blu im Beacon-Modus vorhanden ist. So, als ob das Gateway dann für eine kurze Zeit keine weiteren Geräte verarbeiten könnte.

Das wäre dann natürlich richtig übel, wenn man alle seine Blu-Geräte mit aktiviertem Beacon-Modus betreibt. Aber das ist nur eine Vermutung aufgrund der Beobachtung des Verhaltens.