Beiträge von dewaldo

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.

Das Script sieht soweit ganz gut aus und du brauchst das dann auch nur auf dem i4. Auf dem 2PM muss kein Script installiert werden. Aber wichtig ist, dass der betreffende 2PM vollständig als Rollladenshelly eingerichtet, kalibriert und auch mindestens 1 Mal z.B. per App oder Webinterface verfahren wurde.

Das Script im i4 ruft bei Tastendruck, z.B. Taste 0 von 4, das ist dann die Zahl, die man im Script bei "input" angeben muss, direkt unterhalb der ip-Adresse des 2PM, den man steuern will. die URL auf mit http://ip des 2PM/roller/0. Dieser Aufruf liefert den kurzen JSON Info-String zurück, der enthält, ob der 2PM gestoppt ist und wie die letzte Bewegungsrichtung war, um dann zu entscheiden, ob beim Tastendruck am i4 jetzt der 2PM RAUF oder RUNTER kommandiert wird.

Trifft keiner der beiden Fälle zu, dann wird als Kommando STOP gesendet. So kann man den Rollladen auch stückweise fahren. ABER: Wenn der 2PM z.B. seine Position verloren hat (Stromausfall, falsche Kalibrierung usw) kann es sein, dass die Last direction Info ungülstig ist und dann sendet das i4 Script immer STOP. Von daher würde ich beim Test vorher manuell den 2PM Rollladen manuell einmal komplett nach offen fahren und natürlich muss die Kalibrierung korrekt sein.

Zitat von Whity

bin mir nicht sicher ob die url bei einem 2PM mit aktueller FW noch funktioniert

Ich habe gerade händisch den URL Aufruf an einen meiner 2PM gesendet, das klappt, der JSON String kommt wie erwartet und passt zur Script-Struktur. Firmware des 2PM ist 1.4.4.

D.h. dein "Sende-Shelly" wird mit Gleichspannung betrieben ?
Allgemein zum Plus 1: Wenn der nur als Webhook-Sender agieren soll, dann wäre die beste Konfiguration für den Button doch "Detached", da der Taster ja nicht das interne Relais steuern soll, oder habe ich das falsch verstanden ?

Hast du den Taster am Shelly Input angeschlossen oder parallel zum potentialfreien Relais des Shelly ?
Wenn am SW Input, dann könnte man sich noch vorstellen, dass vom Antrieb irgengdwelche Störungen über die Tasterleitung an den SW Input kommen, der dadurch evtl. ausgelöst wird.

Leider hilft hier nicht der bewährte Tipp, den Status des Shelly auszulesen (http://ipdesshelly/rpc/shelly.getstatus), um zu schauen, welche Quelle Auslöser der letzten Aktion war, weil das im Falle eines AUTO-OFF von unter 1s halt dann immer als "source": "timer" haben wird.

Zitat von horkatz

Im Hauptbild der Scripte noch den Schiebeschalter des neuen Scripts einschalten (dann startet das Script automatisch, wenn der Shelly neu bootet, z.B. nach Srtomausfall).

Wobei ich das nicht direkt beim 1. Versuch machen würde. Lieber den Schalter noch aus lassen. Man kann sich in einem Script schnell Schleifen usw. bauen, die die CPU des ESP32 komplett auslasten und dann geht nichts mehr.
Ich glaube zwar, es gibt inzwischen einen kleinen Workaround durch einen Firmwareupdate in letzter Zeit, dass man die Chance hat, unmittelbar nach Shelly Neustart einzugreifen, um das Ausführen des Scripts zu verhindern, aber es kann halt auch sein, dass das nicht klappt und dann ist der Shelly fakto hinüber, weil man ihn nicht mehr verwenden kann.

Deshalb lieber erstmal das Script ausführlich testen und wenn man merkt, es passt alles, dann den Schalter aktivieren für den automatischen Neustart

Zitat von DIYROLLY

Bei dem Dimmer gibt es nur den kl. Unterschied 0/1 wegen von 0V oder von 1V an dimmen

Die Technik beider Dimmervarianten ist komplett unterschiedlich

Da habe ich dann leider nicht die richtige Shelly Bezeichnung hier verwendet. Ich habe bei meinem Vorschlag den 2. seiner Art gemeint, der tatsächlich aktiv ein 0-10V Signal ausgeben kann und nicht den 1. Typ, der PWM, quasi Passiv moduliert, ähnlich wie der RGBW2.

Der TRIAC Dimmer sollte aber beides können, so verstehe ich zumindest die Produktbeschreibung und der hat auch diverse Konfigurationsmöglichkeiten, sodass ich schon vermute, dass man mit beiden Shelly 0/1-10V Dimmerfamilien das Licht von aus bis Max steuern könnte. Aber wie geschrieben, ich stimme hier thgoebel zu und das war auch die Variante, die ich gemeint habe.

Ich muss sagen, es fällt mir immer schwerer, die richtigen Shelly Typbezeichnungen zu formulieren, die sind irgendwie ziemlich unübersichtlich geworden mit Einführung der GEN3 Varianten.

Eine mögliche Variante wäre ggfs. noch, nicht den Dimmer2 zu verwenden, sondern z.B. den Shelly Plus 0-10V Dimmer in Kombination mit einem TRIAC Dimmer, der einen 0/1-10V Steuereingang hat.
Auf die Schnelle gefunden habe ich dort einen mit dem Namen "ISOLED Phase Dimmer Sys-Pro Radio/Push/1-10V Input Triac Dimmer 230V". Dieser TRIAC Dimmer unterstützt aktive und passive Steuersignale, sollte also mit dem Shelly Plus 0-10V zusammen funktionieren.

Klar, man hätte dann 2 Geräte, um 1 Lampengruppe zu steuern, aber es wäre zumindest dann smart steuerbar.

Danke für die Rückmeldung

Ich würde horkatz hier absolut zustimmen. Was mich hier sehr verwirrt ist die Aufteilung. Z.B. der Lampenstromkreis 23, da wird bei dem Taster, den du uns als Bild 2 zeigst, die geschaltete Phase gleich auf 4 Leiter aufgesplittet.

Ich verstehe die Verdrahtung jetzt so, dass dort 4 Leiter in der Dose ankommen. Davon werden 3 Stück die 3 Drähte sein, die jeweils zu 1 der 3 Wandlampen führt.
Der 4. Draht wird die Zuführung der geschalteten Phase aus dem nächsten Schaltpunkt sein. D.h. in DIESER DOSE, die in Bild 2 gezeigt ist, wäre der korrekte Platz für den Dimmer2, der die 3 Wandlampen schalten soll.
Es gilt dann nur herauszufinden, welche 3 Drähte zu den 3 Lampen gehen und welcher der Einzeldraht ist, der vom nächsten Taster kommt.

Dauerphase und N hast du auch, dann sollte das passen.

Der Schaltpunkt aus Bild 3 scheint für mich von der Logik her der mittlere Schaltpunkt zu sein. Man sieht sowohl für 23 als auch 24 je 2 Abgänge am Tasterausgang, sodass das nahelegt, dass 1 Draht davon jeweils vom vorherigen Taster kommend ist und der 2. Draht dann der wäre, der zur Dose aus Bild 2 verzweigt.

Wie es konkret bei Lampenkreis 24 ist, erschließt sich mir noch nicht ganz von den Bildern, aber da wird es ähnlich sein, nur muss man eben herausfinden, welche dort die letzte Schaltstelle ist, wo dann auch der Lampendraht liegt.

Standardmäßig stellt der Dimmer2 aber glaube ich dann auch wieder die automatische Erkennung der Last ein. Hier weiß ich nicht, woran das die Elektronik des Dimmer2 konkret fest macht, welche Dimm-Art die richtige ist. Vielleicht ist es dadurch dennoch falsch nach einem Reset.

Im Datenblatt der Beneito Faure COMPAC R ist angegeben, dass sie mit der Dimmart "TRIAC" zu dimmen sind.

D.h. im Shelly Dimmer2 ist entsprechend die Dimmart auf Phasenanschnitt einstellen !
Und soweit ich weiß, kann der Dimmer Pro das nicht, der beherrscht ausschließlich den Phasenabschnitt

Ich glaube tatsächlich inzwischen auch an die "Theorie", die Lapu-Lapu im Beitrag #55 verlinkt hat.
Ich habe jetzt mal am Wochenende ein NodeMCU-ESP32 Board genommen und da die Open Source Software "OpenMQTTGateway, kurz OMG" in der BLE Variante installiert. Die Einrichtung ist ein bisschen gewöhnungsbedürftig, aber letztlich super simpel.
Und was ich nach 2 Tagen sagen kann, scheint die Variante auch sehr performant zu sein.

Ich habe bei allen bis auf 1 Shelly 1 Mini Gen3 die BluToMQTT Scripte deaktiviert. Der 1 Mini Gen3 ist im WLAN mit einer Signalstärke von ca. -60 dBm verbunden, also ein sehr gutes Signal. Der Shelly war bislang auch der, der fast immer am schnellsten das Bluetooth Telegramm zum ioBroker geschaufelt hat. Ein BluMotion ist in 1 Meter Abstand dazu montiert.

Im ioBroker habe ich den Shelly Adapter per MQTT, sowie einen 2. separaten MQTT Broker aufgesetzt.
Den OMG habe ich entsprechend mit dem 2. MQTT Broker verbunden. Und dann habe ich mir dann die Zeitstempel der beiden Datenobjekte angeschaut und hier war es so, dass die Zeitstempel über die Shelly Gateway Scriptvariante immer zwischen 400 ms und 900 ms später aktualisiert wurden als die über das OMG.
Die Tage werde ich das mal komplett umstellen und schauen, wie sich die OMG Lösung auf längere Zeit schlägt, aber bisher bin ich begeistert.

Und was ich auch gesehen habe, das OMG bietet eine Konsolenausgabe und in dieser werden beim BluMotion und einer auftretenden Bewerungserkennung tatsächlich 2 - 3 Frames hintereinander als Empfangen angezeigt. Das passt zu der Theorie, dass die "echten Events" mit einer längeren Signaldauer und Wiederholungsanzahl gesendet werden als die Beacon - Telegramme.

Ich werde den BluMotion dann auch nochmal in den Beacon Modus schalten und die Telegramme im ioBroker protokollieren und kann dann gerne nochmal berichten.

Klar, keine Shelly Lösung per se, aber eine sehr viel günstigere Variante als z.B: mittels Raspberry Pi etc.

Zitat von ro.tz

Was wäre der Vorteil, an beiden Eingängen je einen Taster anzuschließen?

Weiß nicht, ob das eine Frage war, auf die du wirklich eine Antwort wolltest. Aber ich bin mal so frei.
--> Vorteil ist schlicht und einfach der, dass man sofort beim Drücken der entsprechende Taste weiß, dass die Helligkeit beim Gedrückt halten rauf oder eben runter geht. Bei 1 Taster-Bedienung weiß man das meistens nicht und muss erstmal schauen, wie das Licht reagiert, ggfs. loslassen und erneut gedrückt halten, wenn es die falsche Richtung war.

--> Ein grundsätzlich weiterer Vorteil des Dimmer2, überhaupt 2 Inputs zu haben, ist auch noch der, dass man z.B. 1 Taster an Input1 anschließen kann und an Input 2 bspw. den Ausgang eines Bewegungsmelders, um so auch über diesen das Licht zusätzlich zum Wandtaster steuern zu lassen. Hier dann per local action, bei der man z.B. auch mit angeben kann, wenn PIR an, dann Licht an mit z.B. 30%.

Eine weitere, denkbare Anwendung ist, einen 2-fach Taster, davon aber 1 an Input 1 als Eintaster-Bedienung, also ein/aus/dimmen über diesen 1. Taster. Und einen 2. Taster an Input 2 per local action und bei Drücken dieses Tasters geht das Licht IMMER, egal ob Tag ob Nachtmodus, auf eine frei wählbare, feste Helligkeit usw...

Wo Grundlagen für smarte Technik nicht vorhanden sind, kann man auch keine solche einsetzen. Shelly ist hier aus meiner Sicht das falsche Produktfeld.
Fazit ist, ohne regelmäßige Zeitsynchronisierung führt der Shelly auch die schedules nicht mehr aus.

Ich würde eine simple Variante aus einem kleinen 5V Solarmodul + 5V Subminiaturrelais nehmen und dann halt den Klingeldraht über den Schließer des Relaus führen. Hell = Klingel scharf, dunkel = Klingel aus.

Solche Subminiaturrelais mit 5V gibt es für unter 2 EUR, z.B. "HF41F-5-ZS", Solarmodul z.B. "Sygonix Solar-Panel SY-4603118" für 18 EUR inkl. Halterung für Outdoor.
Das Relais begnügt sich schon mit unter 150 mW Versorgungsleistung, sodass auch bei Schlechtwetter tagsüber das Relais sicher geschaltet würde. Dann noch ein kleines outdoor verteilergehäuse unter der Solarzelle, fertig. Und Gesamtkosten unter 30 EUR ist man fast soweit wie einen Shelly, aber ohne Standby-Verbrauch im Betrieb

WD kenne ich nur als Western Digital, wofür steht WD hier ?