Beiträge von eiche

VPN/Proxy erkannt

Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.

    Ein Skript, welches auf Änderungen beider Eingänge wie folgt reagiert. Für beide Endlagenschalter gleich.

    1. Bei Änderung dieselbe, also welcher Eingang, feststellen.
    2. Eingang und dessen Status speichern.
    3. Danach bspw. 50ms warten und denselben Eingang abfragen. Ist der neue Status gleich dem gespeicherten Status, Aktionen auslösen und Nachrichten senden.

    Ich weiß allerdings derzeit nicht, wie man aus einem Skript eine Push Nachricht sendet. Vermutlich nutzt du dafür die Cloud. Das kannst du ja auch weiterhin tun und auf eine der Aktionen reagieren lassen.

    Es mag andere Wege geben ...

    Bspw. eine Hardwarelösung per RC Integrierglied. Ich täte die Skriptlösung bevorzugen.

    Fritzneu

    Mein Eindruck: Du bist viel zu hektisch.

    komme leider trotzdem nicht voran

    Womit kommst du nicht voran? Wer nicht präzise schreiben kann, kann wahrscheinlich auch nicht präzise lesen.

    Also:

    1. einen Tee trinken oder bei Vorliebe einen Schnaps ;)
    2. entspannen - zu neudeutsch relaxen
    3. Bedienungsanleitung sorgfältig lesen, ggf. eigene Notizen machen.
    4. App erstmal beiseite lassen, mit dem Access Point des Shelly verbinden und einen Web-Browser verwenden : http://192.168.33.1 ...
    5. Die Navigation auf der WebUI kennenlernen und nutzen.

    Später kannst du dich dann mit der Cloud versuchen. Direkt per App alles zu erledigen mag schneller gelingen können, kann aber auch dazu neigen, den Nutzer ein Stück zu verblöden. In aller Freundschaft.;)

    Ich hatte noch nie Probleme beim einbinden eines Shelly in ein WLAN via WebUI des Shelly. Warum immer wieder eine App dazu gebraucht wird, ist mir ein Rätsel. Etwas anderes liegt vor, wenn der Shelly in die Cloud eingebunden werden soll. Davon schreibt der TE aber bisher nichts.

    Wenn der Shelly ausfällt, durch Defekt oder weil kein WLAN verfügbar kann ich die Markise nicht bewegen.

    Da sind schonmal 3 mögliche Ausfallursachen zu unterscheiden.

    1. Kein Strom - nicht relevant, weil dann auch kein Markisenantrieb an Netzspannung arbeiten kann.
    2. Shelly defekt -> Austausch des Shelly oder für zügige Reparatur Shelly raus, Taster/Schalter wieder einbauen bzw. rückverdrahten.
    3. WLAN ausgefallen -> dazu die Frage: Hast du ggf. vorhandene Taster/Schalter weiter genutzt und mit den Shelly Eingängen verbunden? Wenn ja, ist der Markisenantrieb immer per Taster/Schalter zu steuern.

    Zu 2. und 3. Solltest du solche Fälle berücksichtigen wollen, dann ist zunächst immer der Einbau von Tastern oder Schaltern zielführend. Was du dabei bevorzugst, hängt von deiner Vorliebe bzgl. Bedienung ab. Eine Steuerung am betreffenden Shelly vorbei halte ich für wenig wahrscheinlich möglich, bin dbzgl. allerdings unbeleckt. ;)

    Braun/Blau (Ausgang "M3") geht hoch zum Motor.
    Rot/Schwarz (Eingang "PV1") kommt anscheinend von den Solarzellen.

    Für jemand Uneingeweihtes wie mich.

    Soweit ich dich verstand willst du die PV Versorgung komplett abtrennen und durch eine Netzspannungsversorgung + Netzteil (12V DC) ersetzen. Wenn ich richtig verstand, täte ich folgendes.

    Probelauf eines Rollos bei gleichzeitigem Messen der Spannung zwischen den M3 Klemmen, Hoch und Runterlauf. Es ist zu erwarten, dass diese Spannung eine Gleichspannung ist und sich in der Polarität umkehrt.

    Die Höhe der Spannung ist von Belang!

    Falls diese 12V beträgt und du konsequent auf smart umrüsten willst, brauchst du die Steuereinheit nicht mehr.

    Voraussetzung: Du willst die Rollos nur zum öffnen und zum schließen fahren, ohne Anweisung auf x% Öffnungsgrad, was ein Kalibrieren voraussetzt. Ggf. zwischendurch anhalten ist möglich.

    Da du auch Sprachsteuerung vorsehen möchtest, bleiben in der Shelly Familie ausschließlich die Rollladen Shelly 2.5 (alt) und 2PM (neu) - im Zweifelsfall die neueste Generation. Dann ist die bereits von thgoebel beschriebene Umrüstung auf 12V zu basteln, wobei deren Garantie verloren geht.

    Es gibt zumindest eine Alternative, mit welcher die Garantie nicht verloren geht und auch gebastelt werden muss. Hinzu käme noch wenigstens die Konfiguration in einem übergeordneten System (Home Assistant, ioBroker, openHAB, ...). Mehr Freiheiten hat man mit Node-RED (einfache Programmierumgebung) und ggf. zusätzlicher Skript-Programmierung, was ich nur der Vollständigkeit wegen erwähne. Bei all diesen Alternativen wirst du vermutlich die Sprachsteuerung verlieren, auch wenn dies bei unbedingtem Willen per Node-RED gelingen könnte. Auch eine Kalibrierung via Zeitmessungen kann prinzipiell mit Programmierung nachgebildet werden, was jedoch nicht ganz an die Shelly eigene Kalibrierung heranreichen wird.

    Fazit: Wenn du eine einfache und schnelle Lösung suchst, vergiss dein Vorhaben! Ansonsten gibt es (fast) nichts, was nicht geht.;)

    Afaik können die Rollladen Shelly mit 24V Gleichspannung, nicht aber mit 12V betrieben werden und schalten nicht potentialfrei.

    Wenn deine Rollo mit 12V betrieben werden, kann vielleicht thgoebel weiterhelfen, ggf. mit Gleichrichtung und Shelly Modifikation. Kalibrierbar sind sie dann aber keinesfalls mehr.

    Fazit: Mit geringem, Aufwand wird es vermutlich nicht gelingen.

    Sorry, ich landete auf Seite 1 und sah nicht, das der Thread bereits sehr viel weiter ist.

    martner

    Dann verweise ich auf #11, ergänzt durch bei Bedarf folgendes Verfahren.

    Beispiel mit 3 gekoppelten Shelly Generation 3.

    (Bin gegenwärtig im Krankenhaus und kann nicht testen. Vielleicht geht das auch mit Actions. Szenen täte ich nicht einsetzen.)

    In den Skripten der 3 Gen 3 Shelly werden kurze Verzögerungen eingebaut. Das ist skalierbar, sollen heißen auf mehr Shelly Gen 3 ausdehnbar.

    ShellyA: keine Verzögerung, ShellyB 2ms Verzögerung, ShellyC 4ms Verzöherung.

    Alternativ können diese Verzögerungen auch zufällig generiert werden, wobei dann aber auch 2 der Gen 3 Shelly mal zeitgleich senden könnten. Auf diese Weise kommen die Nachrichten am master nicht gleichzeitig an und er hat Zeit, seine Queue zu bearbeiten. Vermutlich genügt auch ein Verzögerungsabstand von 1ms. Die Gen 3 kommunizieren ja per WLAN.

    Dazu muss man halt etwas planen und evtl. auch dokumentieren, damit der Überblick nicht verloren geht - bei bspw. 8 solcher Gen 3 Shelly.

    Das ist von mir nur eine Idee, die ich schon mangels derzeitiger Ausstattung nicht testen kann. Das Skript in #6 bildet bereits die Basis für die Slaves. Ob man für die Kommunikation MQTT oder HTTP nutzt, bleibt dem Anwender/Entwickler überlassen. MQTT bietet den Vorteil, dass dafür keine IP Adresse gebraucht wird, bei Austausch eines Kommunikations Shelly nur das Topic wiederverwendet werden muss und der dafür erforderliche Skriptteil leichter zu codieren ist.

    Aus meiner Erinnerung, als ich zu Hause damit experimentierte, konnte ich zwei Shelly Gen 3 Geräte mit einem BLU H&T koppeln. Deshalb bin ich zuversichtlich, dass dieses angedachte Verfahren gelingt.

    Per Skripte verfolge ich folgende Idee.

    Ein "master" Shelly, Gen 2 genügt bereits, empfängt von "slave" Shelly, Gen 3+, die Nachrichten per http.

    Der master speichert eine solche Nachricht für bspw. 10s in einer Queue. Danach wird sie gelöscht.

    Der/die slave arbeiten wie im obigen Skript und senden statt per MQTT per http - so müssen diese nicht zwingend MQTT nutzen.

    Der master prüft bei Empfang, ob bereits die gleiche Nachricht in seiner Queue steckt. Wenn ja, lässt er diese unverarbeitet. Wenn nein, speichert er sie und sendet sie als MQTT Nachricht.

    martner

    Tja, das muss ich noch testen.

    Vielleicht ist ein Mehrfachempfang unerheblich, da ja dann alle beteiligten Gen 3 Geräte die gleiche Nachricht senden täten. Der Subscriber hätte halt zusätzliche Arbeit. Ansonsten muss ich noch genau herausfinden, wie die Pakete identifiziert werden (können). Ich arbeite (morgen vielleicht) wieder daran.

    Zunächst ließe sich bei gleicher Id und gleichem timestamp herausfinden, dass die Nachricht bereits empfangen wurde und nicht noch einmal zu verarbeiten sei. Soweit ich mich erinnere sendet die Firmware so etwas wie eine Paket Id, an welcher erkennbar sein soll, ob die Nachricht bereits empfangen wurde. Mal sehen ...

    Danke thgoebel.

    Das wäre unter Verwendung eines zusätzlichen Shelly, welcher den Sicherheitsschalter realisiert und bspw. zwei BLU Motion für die Terrassentür sehr nützlich. Leider kriege ich in ihrer Wohnung diesen zusätzlichen Shelly nicht unter. ;)

    Zitat

    Zweiter Nachteil: Für das Steuern des Rollladens ist Ein-Knopfbedienung erforderlich.

    Das könnte ich ggf. per Skript anders lösen.

    Noch einige Hinweise zu obigem Skript.

    Es ist leicht möglich, die vom Anwender in der Component Konfiguration vergebenen Namen in das Topic der MQTT Nachrichten einzubauen.

    Beispiel:

    Component Name = "Wohnzimmertemperatur:°C"

    Daraus ergäbe sich das Topic: "experiment/bthome/Wohnzimmertemperatur"

    Bei Bedarf ließe sich der Component Name auch in drei Teile gliedern, wie "Wohnzimmertemperatur:living/temp:°C". Dies kann vom angepassten Skript wie folgt umgesetzt werden.

    • Sensorgrößenname: Wohnzimmertemperatur
    • Einheit: °C
    • Topic: "experiment/bthome/living/temp"

    Um dies als Option zu nutzen, kann der Component Name auch ohne Topic Teil zusammengesetzt werden, z.B. "Wohnzimmertemperatur::°C".
    Oder ohne Einheit, was bereits obiges Skript toleriert, z.B. "Wohnzimmertemperatur:living/temp".

    Hier ist einige Gestaltungsarbeit möglich, wobei der Anwender aber auch Fehler machen kann, indem er in seinem ganzen smart home System Uneindeutigkeiten konfiguriert. Dieses Konzept ist also nicht DAU sicher.

    Das in der System MQTT Konfiguration vergebene Pre-Topic wirkt hier übrigens nicht. Dieses gilt ausschließlich in MQTT Nachrichten, welche per System gesendet werden.

    Wenn dafür Bedarf besteht, reiche ich ein entsprechend angepasstes kleines Skript gerne nach.

    Auch denke ich daran, solche Component Konfigurationen per MQTT auf andere Shelly Generation 3 Geräte verteilen zu können. Hierzu können zwei weitere Skripte genutzt werden - eines zum Senden der lokalen Konfiguration, das andere zum empfangen und automatisiertem Konfigurieren der eigenen Komponenten. Dazu habe ich zwar Ideen, aber noch keine Tests durchgeführt. Die RPC stellen jedenfalls hierfür genügend Methoden bereit.

    Weitere Optionen sind umsetzbar.

    Nach vielen Experimenten habe ich ein sehr kleines Skript erstellt, welches auf einem Shelly der Generation 3 (oder vermutlich höher) dazu genutzt werden kann, MQTT Nachrichten mit BTHome Sensordaten zu senden, also solche die von Shelly BLU Geräten kommen. Hierfür müssen alle zu beteiligenden Sensoren auf dem Shelly der Generation 3 ... eingerichtet werden - unter Components.

    Dort sind anschließend die Sensor Identifier zu sehen - Struktur: "bthomesensor:<id>". Zu jedem per MQTT zu erfassenden Sensor bzw. physikalische Sensorgröße muss eine Action angelegt werden.

    Code
    http://127.0.0.1/rpc/script.eval?id=<script id>&code="bths(<sensor id>)"

    Beispiel:

    Code
    http://127.0.0.1/rpc/script.eval?id=1&code="bths(202)"

    bths() ist die einzige Funktion des kleinen Skripts. Sie holt unter Verwendung der Sensor Id die aktuellen Daten und den in deiner Konfiguration eingetragenen Namen mit optionaler Einheit, stellt diese für die MQTT Payload zusammen und sendet die MQTT Nachricht.

    Die Component Namen brauchen mit dem von mir gewählten Separator (Konfigurationsvariable Sep im Skript) die folgende Struktur.

    Code
    <Sensorname>:<Einheit>

    Beispiel:

    Code
    Wohnzimmertemperatur:°C

    Damit wird die Payload der MQTT Nachricht folgende Komponenten haben.

    • Sensor Id
    • Sensor Wert
    • Timestamp der letzten Aktualisierung
    • Sensorname
    • Einheit

    Selbstverständlich muss der Abonnent nicht alle diese Daten nutzen, sie stellen aber imho alle relevant nutzbaren Informationen bereit.

    Das Skript

    Dies alles ist mit etwas Konzentration leicht zu konfigurieren. Das Skript kann bei Bedarf so erweitert werden, dass Sensor spezifische Aktionen ausgeführt werden, bspw. MQTT Nachricht versenden oder HTTP Get URL nutzen oder bei Bedarf auch beides. Die flexibelste Variante einer solchen Erweiterung beinhaltet ein Datenfeld aus jeweils der Sensor Id und einer Referenz auf die zu nutzende Funktion zwecks senden der Daten bzw. auslösen einer Aktion.

    Die Funktionsnamen sind nur formal so gewählt und können selbstverständlich nach Belieben lauten. Alle diese Funktionen müssen ein Objekt als Parameter importieren, welches alle Sensordaten enthält.

    Das Datenfeld Action ist nach der aktuell vorliegenden Sensor Id abzusuchen und, wenn gefunden, die zugeordnete Funktion (hier eine Referenz) mit dem aktuellen Sensordaten Objekt als Parameter aufzurufen. Die Funktionsreferenzen haben den Vorteil, dass eine Funktion auch im mehreren Action Einträgen genutzt werden kann.

    Bei Fragen gebe ich gerne Auskunft, wenn der Frager wenigstens grundlegendste Kenntnisse hat. ;)

    Vermutlich gelingt das nicht ohne Skript und mittlerem Aufwand der Umstellung.

    Gründe

    1. Ein Sperren des Rolladenfahrens ist nicht vorgesehen.
    2. Man kann zwar die Wirkung von Signalen an den Eingängen sperren, nicht aber die Steuerung der Ausgänge per Nachrichten.

    Geeignetes Verfahren

    1. Das Steuern der Rollläden oder zumindest des betreffenden Rollladens muss geändert werden. Dies verhindert nicht ein Fahren über die ggf. gegebene Cloud Nutzung oder die Web UI des Shelly.
    2. Per Skript mit zumindest einem sog. HTTP Endpoint muss alle erforderlichen Kommandos (URL) entgegennehmen und verarbeiten, auch solche, die zum Rollladensteuern verwendet werden. Tatsächlich muss das Skript speziell dafür vom Benutzer festgelegte Kommandos in die API Kommandos transformieren.
    3. Zwei zusätzliche Kommandos sind erforderlich - eines zum sperren der obigen Kommandoverarbeitung und eines zum freigeben derselben.
      Das kann auch eine simple Skriptfunktion tun.
    4. Per zweier Schedule Jobs sind dann diese zusätzlichen Kommandos zu nutzen.

    Dies lässt sich alles implementieren, wenn man will und kann. (Ich könnte solches, brauche es aber nicht.) Solange Standard mittel so etwas nicht vorsehen, sehe ich keinen anderen Weg. Es sollte auch ohne HTTP Endpoints gelingen, was allerdings von weniger eingeweihten Nutzern noch schwieriger einsetzbar wäre.

    Die Nutzung eines Shelly Gen 3 zur Weiterleitung von BLU H&T Nachrichten gelingt vorzüglich und relativ leicht.

    Alternativ zu den MQTT Nachrichten durch das System kann man Actions nutzen. Inzwischen gelingt es mir auf unterschiedliche Weise, per Actions und sehr einfaches Skript Nachrichten frei zu gestalten. Hiermit kann ich auch den doofen Schlüssel "bthomesensor:<id>" vermeiden und "leicht verdauliche" Schlüssel in der JSON Payload selbst kreieren.

    Sind die 18V Gleich- oder Wechselspannung?

    18V DC zur Versorgung eines Shelly Plus 1 habe ich nie versucht. Dazu kann sicher thgoebel etwas mitteilen. Ich kann dir aber dafür einen Shelly Plus Uni empfehlen. Der arbeitet sehr gut mit 18V, hat u.a. zwei binäre Eingänge und zwei per Optokoppler potentialfrei schaltende Ausgänge. Dies habe ich afaik bereits weiter oben angemerkt.

    Alternativ kannst du sicherheitshalber zur Shelly Plus 1 Versorgung einen (einstellbaren) Gleichspannungswandler 18V DC -> 12V DC nutzen.

    und den freien SW für den Magnetschalter verwende

    Das geht dann jedenfalls, wenn der Magnetschalter funktioniert. Letzteres stelle ich auf Grund deiner dbzgl. Probleme an Analog In in Frage.