Beiträge von dewaldo

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

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,

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

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.

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.

Zitat

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.

Ist zwar schon älter der Thread, aber dennoch kurz die Anmerkung, falls nicht inzwischen eh schon klar. DTU-Lite und OpenDTU sind 2 vollkommen unterschiedliche Dinge. Die offizielle Lite-DTU von hoymiles lässt sich nicht über ioBroker auslesen, sondern kommuniziert ihrerseits mit dem Wechselrichter und über Internet mit der hoymiles-Cloud. Hier kann evtl. ein Weg über Cloud und Token und das Abfragen der Werte von den hoymiles Servern funktionieren, aber das würde ich nicht verfolgen...

Am besten du verkaufst die Lite-DTU und besorgst dir entsprechend eine OpenDTU für den hoymiles Typ hm mit NRF24L01 Funkmodul und hier am besten eine, die auf dem ESP32 basiert, nicht 8266. Anleitungen, wie man das dann mit dem ioBroker kombiniert, gibt es inzwischen genügend. Offenbar gibt es inzwischen dann ja sogar einen OpenDTU - Adapter, habe ich aber selbst noch nicht genutzt.

Ich beschäftige mich aktuell auch sehr mit dieser Thematik und habe im "Nachbar-Thread" auch Erfahrungen gepostet im Vergleich mit einem ESP32 NodeMCU Modul mit OMG.
Eine Frage hätte ich, vielleicht kennt ihr da mehr Infos. Und zwar, wie verhält sich das mit den Paramtern "interval_ms" und "window_ms" ?

---> Woher bekommt man die Infos zu den Methoden ? Wo findet man die Infos, welche Werte die Parameter haben dürfen ?
---> Augenscheinlich denkt man ja, hey, warum alle 200ms für 50ms lauschen, warum nicht alle 100ms für 90ms ? Klar, irgendwann packt das die CPU, Speicherverwaltung usw. nicht mehr, aber wo bewegt man sich hier und welche Werte sind seitens der Methode erlaubt ?

LG, dewaldo

Dann melde ich mich auch mal mit Erfahrungswerten zu hoymiles.

Der hm-1500 hat 4 Anschlüsse für Module, aber hat nur 2 Tracker. Input 1+2 sowie 3+4 gehören jeweils zusammen auf 1 Tracker. Daher ist es wichtig, wenn man unterschiedlich ausgerichtete Module hat, oder noch schlimmer unterschiedliche Module, dass pro Eingangspaar immer identische Modulkennlinie + Ausrichtung eingehalten werden, sonst klappt das Regeln nicht.

Und ja, es stimmt, ein Drosseln auf 800W bewirkt nicht einfach nur eine AC-Drosselung, sondern alle 4 Inputs werden um den Reduktionsfaktor begrenzt. Hat man dann z.B. OST-WEST je 2 Module und 800W Begrenzung, hat man selbst an einem schönen Sonnentag nur im Ausnahmefall 800W, obwohl die Module das bringen würden von der Einstrahlung her, aber es werden dann statt 400W pro Kanal halt nur 200W zugelassen, und dann wird das halt nix mehr mit 800W.

Drosselung auf Wechselrichter-Seite macht nach meiner Erfahrung nur dann Sinn, wenn alle Module gleichartig sind und identisch ausgerichtet sind. Das Ganze aus einem Akku zu speisen und auf Wechselrichter-Seite zu regeln wird auch nicht funktionieren, weil ein Akku eine Spannungsquelle ist und damit kann ein MPPT nicht umgehen.

Und ein Wort zur Nullspeiseregelung. Habe ich auch lange dran optimiert, und kann als Fazit sagen, ja, man kann nachregeln, aber die erreichbare Dynamik liegt in Größenordnungen von 10s, funktioniert also nur bei konstanten Leistungsabnehmern im Haus wie z.B. Staubsauger, Föhn... Ganz schlecht sind z.B. Herdplatten, da diese takten zur Temperaturregulierung, da macht man dann quasi auf Wechselrichterseite ständig genau das Falsche

Meine Aussage bezieht sich beim Beacon Modus nicht in erster Linie auf die Zuverlässigkeit der Telegramme, da habe ich ja geschrieben, mit OMG ist das schon deutlich besser. Mein Problem und NoGo ist, dass die Beacon Telegramme dazu führen, dass der PIR Sensor im BluMotion getriggert wird. Sowas ähnliches hatte ich vor 3 Jahren im Flur. Dort ist Standard Einbau-PIR in der Zwischendecke und in unmittelbarer Nähe war ein Dimmer2 montiert. Und dessen WLAN hat sporadisch den PIR Sensor getriggert, sodass nachts immer mal wieder von Geisterhand das Licht anging. Nach einer räumlichen Trennung > 1m war dann Ruhe. Beim BluMotion kann ich natürlich nicht PIR Elektornik und Bluetooth räumlich trennen. Der Effekt tritt zwar nur auf, wenn die Sensiblität des BluMotion auf MAX steht, aber ich brauche auch die maximale Empflndlichkeit.

Hi zusammen, ich teile hier mal meine aktuellen Erfahrungen zu dem Thema, vielleicht nutzt es jemandem.
Ich habe gestern mal die ganze Scripte fertiggestellt, um meine BluMotion Geräte auf das OpenMQTTGateway umzustellen. Hierbei habe ich dann auch 2 BluMotion in den Beacon Modus versetzt und dabei in einem Zeitraum von ca. 4 Stunden folgende Erkenntnisse gewonnen:

- Das OpenMQTTGateway, kurz OMG, hat bei den Beacons tatsächlich auch nicht nahtlos alle Telegramme registriert. Auch hier gab es so ca. jedes 10. Telegramm, bei dem dann keine MQTT Botschaft generiert wurde. Interessanterweise waren es dann meist die im gleichen Raster, heißt, z.B. um 20:00:00 Uhr wurde eines empfangen, dann um 20:00:30, dann 20:01:00 usw. und wenn eines ausgeblieben ist, waren es meistens die in dem 30s Raster, die bei den vollen Minuten nicht. Aber kann auch Zufall gewesen sein, es war jedenfalls auffällig.

- Hin und wieder wurden Telegramme vom OMG zwar empfangen, aber der Nutzinhalt war nicht vollständig, sodas die Werte wie "motion", "lux", "battery" usw. nicht als gültig gesendet wurden, das kam aber sehr selten vor.

- Dann habe ich etwas festgestellt, was leider für den BluMotion bedeutet, dass doŕt der Beacon Modus nicht verwendet werden kann (um z.B. Helligkeit oder Temperaturverlauf kontinuierlich zu erfassen). Und zwar ist es so, dass der Sendeimpuls des Blutooth Telegramms selbst das PIR Modul zum triggern bringt. Heißt, der BluMotion triggert bei sich selbst eine Bewegungserkennung durch das Senden per Blutooth, sodass der BluMotion gestern ständig ohne echte Bewegung immer mal wieder auf "motion=true" gesprungen ist. Das war dann auch so, dass trotz blind time von 30s manchmal 3 Minuten der Status nicht mehr auf false gewechselt ist, weil auch bei aktiver Erkennung weiterhin Beacon gesendet werden (war glaube ich bei älteren Firmwares noch nicht so). Abhilfe hat nur gebracht, die "sensitivity" des BluMotion auf medium zu stellen.

- Weiter scheint es so zu sein, wenn der Beacon Modus NICHT aktiv ist, scheint die Shelly BluMotion Firmware die PIR Erkennung für den Moment zu pausieren, wenn per Bluetooth gesendet wird, um hier keine Fehlauslösung zu bekommen. Wenn der Beacon Modus EIN ist, dann habe ich sehr oft beobachtet, dass wenn der BluMotion von motion=true zu false gewechselt hat, er dann sofort kurz beblinkt hat und der Status unmittelbar wieder zurück auf true gesprungen ist.

- Noch eine Erkenntnis: Ich hatte bei den Tests zeitweise 2 BluMotion direkt nebeneinander stehen, um verschiedene Einstellungen im Direktvergleich zu testen. Da war es dann ganz extrem. Jedes Senden eines Beacons oder Statustelegramms eines der beiden BluMotion hat sofort beim jeweils anderen den PIR Sensor getriggert, sodass die 2 sich ständig gegenseitig getriggert haben.

- So, und zu guter Letzt dann noch eine Beobachtung im Zusammenspiel mit dem Shelly 1 mini Gen3 als Gateway mit Script. Hier hatte ich nie Probleme, dass der BluiMotion im betrefffenden Raum mal nicht korrekt das Licht ein und ausgeschaltet hätte. Es wurden immer sauber alle Telegramme vom 1mini Gen3 emfpangen. Aber als gestern die beiden BluiMotion im Beacon Modus aktiv waren, hat das auch dazu geführt, dass die 3. BluMotion, der fest im Raum verbaut ist, vom Shelly 1 mini Gen3 nicht mehr verlässlich empfangen wurde. Hier haben die permanenten Beacons der 2 anderen offenbar schon ausgereicht, dass die Signale des 3. BluMotion nicht mehr verlässlich verarbeitet werden.

FAZIT für mich:

--> Beacon Modus bei den BluMotion ist nicht verwendbar, hat mehr Nebeneffekte als Nutzen
--> OMG statt Shelly Gateway hat Vorteile in Sachen Auslösezeit und Zuverlässlichkeit im Beacon-Modus, bringt aber in der Normalanwendung keinen großen Mehrwert, außer der im Mittel um ca. 200-300ms schnelleren "Auslösezeit".
--> Im Gegenzug ist das OMG kein fertiges Produkt, was man z.B. in eine Gerätedose setzen könnte, dazu braucht es eine 5VDC Versorgung + Gehäuse, was halt einen gewissen Aufwand mit sich bringt, sowas vernünftig zu installieren.
--> Ein weiterer, großer Vorteil des OMG ist aber natürlich, dass man damit quasi alle unverschlüsselten BLE Geräte empfangen und verarbeiten kann. Übrigens ist es hierbei dann zwingend erforderlich, im OMG eine Whitelist anzulegen mit MAC-Adressen der BLE Geräte, die per MQTT übermittelt werden sollen. Macht man das nicht, hat man nach 1 Tag gerne mal schon über 100 neue Datenpunkte im ioBroker, weil jedes iPhone, Airtag, Kopfhörer usw. dann hier aufschlagen. Da genügt es, wenn ein paar Leute am Haus vorbei gehen, jeder hat sein Handy, Smartwatch dabei und schon kommen 10 neue Geräte hinzu.