Beiträge von eiche

    Hm, ich weiß nicht, ob ich hinreichend im Bilde bin. Trotzdem ...

    MQTT retain ist seeehr vorsichtig einzusetzen, insbesondere, wenn es um Steuerungen oder Regelungen geht.

    Zumindest sollte an das Löschen einer solchen retained Nachricht per selbem Topic und leerer Payload (Nachricht) gedacht werden.

    Das kann der Shelly nicht eigenständig übernehmen, weil die retained Nachricht nicht von ihm selbst kommt. Oder doch?

    Also müsste der Shelly periodisch die Verfügbarkeit des HA prüfen, da er der letzte sein muss, der ausfällt - siehe Martins Einwände.

    Sobald der Shelly, aus welchem Grund auch immer, HA nicht erreicht, muss er die zu löschende retained Nachricht kennen und diese im Broker löschen lassen.

    Ob solches stattdessen per Last Will And Testament seitens HA gelingen kann, weiß ich derzeit nicht.

    Dass die Prioritäten wie folgt sind, habe ich wohl verstanden.

    1. Zwangsführung
    2. Sperre
    3. Ausgang wie Eingang

    Martins Einwände stehen, sind für henfri aber wohl nicht hinreichend gewichtig. Ok

    dass beim HA-Exitus die normale Steuerung wieder übernimmt

    Ist die "normale" Steuerung "Ausgang wie Eingang"? Wenn nicht, was ist sie dann?

    Ok, ok, Ich stelle hiermit fest, dass meine Wortwahl "Niedrigspannung" missverstanden werden könnte und somit dieses verfehlte Wort bitte eigenständig durch "niedrige Spannung unter 30V" zu ersetzen sei. :S

    Btw, ich lese nicht nur hier oft von "hohen Strömen" und weißt nicht , was bspw. eine "kleine Spannung" sein soll.

    Warum?

    Es gibt den physikalischen Begriff der Stromstärke, nicht aber der Stromhöhe. X/

    Auch gibt es hohe Spannungen oder niedrige Spannungen, als Potentialdifferenz. Nochmal X/

    Nur mal so. Die Leute, welche so etwas lehren, leeren mitunter auch Wortbedeutungen. Und die Fachleute nutzen allzu oft einen merkwürdigen Jargon.

    Trotz alledem finde ich die Ergänzung seitens Schubbie angemessen. :beer:

    Ich habe in meiner obigen, letzten Nachricht einige Male Änderungen vorgenommen, um die Beschreibung zu verbessern.

    Wenn dir diese Art der MQTT Kommunikation zu aufwändig erscheinen sollte, kannst du diese per Skriptnutzung vereinfachen.

    Wie? Das erläutere ich erst bei Bedarf, vielleicht in Teil x meiner Skripteinführung. ;)

    Btw, ein Plus Plug S bietet folgende Methoden:

    Dazu ein vermutlich hilfreicher Link: RPC channels - MQTT

    Dort entnehme ich folgendes.

    Als Beispiel-Topic: shellyplus1-c4dd57877294/rpc

    Als Beispiel-Payload: {"id":123, "src":"user_1", "method":"Switch.Set", "params":{"id":0,"on":true}}

    Das zu deinem Shelly passende Topic kannst du ableiten, indem du dir dessen MAC-Adresse kopierst und statt der Beispiel MAC-Adresse einbaust. Das für dich geeignete Topic sollte somit wie folgt lauten: "shellyplusplugs-<MAC-Adresse>/rpc"

    Nun zur Payload.

    Die Komponenten id und src dienen ausschließlich der Peer to Peer Kommunikation per in der Firmware verankerten MQTT Kommunikation. Damit kannst du experimentieren.

    Beide erscheinen in der Antwort-Payload, womit selektiert werden kann. In der Antwort erscheint aber src unter dst (destination), weil der Shelly die Antwort an die Quelle des Auftrags zurücksenden will. Dafür verwendet die Firmware den empfangenen src Wert (in der Antwort als dst Wert) im Topic: <src Wert>/rpc. Selbstverständlich kann ein anderer Subscriber eine solche Nachricht trotzdem empfangen. In der Shelly-Antwort ist der src Wert der eindeutige Name des Shelly mit dessen MAC-Adresse und das Topic enthält den Namen der auslösenden Quelle.

    Auf diese Weise sind die Quelle der Nachricht an den Shelly und die Quelle der Antwort bekannt. Damit lässt sich eine Peer to Peer Kommunikation nachbilden, ähnlich einer HTTP Request mit einer darauf folgenden HTTP Response. Vermutlich ist die HTTP Kommunikation das "Vorbild" für diese Art der MQTT Kommunikation.

    Die Komponenten method und params sollten eindeutig und leicht zu verstehen sein. Ich erläutere trotzdem für den Fall, dass du mit dem JSON Format nicht sehr vertraut sein solltest.

    Der method Wert muss ein Methodenname sein, welcher dem Shelly zur Verfügung steht, hier "Switch.Set". Diese Methode setzt einen Ausgang auf einen Zustand, welcher per params Wert definiert ist.

    Der params Wert ist ein kleines Objekt mit den Komponenten id und on. {"id":0, "on":true} definiert, dass der Ausgang 0 eingeschaltet werden soll.

    Alle Methoden, die in einem Shelly der Generation 2+ zur Verfügung stehen, kannst du abfragen mit 'http://<IP Adresse>/rpc/shelly.listmethods' .

    Die Methodennamen sind case insensitiv, d.h. Groß-/Kleinschreibung spielt keine Rolle.

    Wichtig: Sowohl die Struktur des params Objekts als auch dessen Komponentennamen hängen von der genutzten Methode ab.

    Mit diesen Informationen solltest du nun in der Lage sein, dich eigenständig durchzuärgern. ;)

    Ich kann dich gerne bei Gelegenheit ein wenig unterstützen, falls du bei einem konkreten Vorhaben nicht weiterkommen solltest.

    ShellyName/command/switch:0

    Dies nehme ich zum Anlass, kurz konkret darauf einzugehen.

    Topic: shellyplusplugs-<MAC-Adresse>/rpc

    Payload: {"id":<von dir gewählt>, "src":<Name für deine Quelle>,"method":"Switch.Set", "params":{"id":0, "on":true}} zum einschalten des Ausgangs 0 - die Component Id muss auch dann angegeben werden, wenn es nur eine solche Component gibt. Auf Grund dieser MQTT Nachricht an den Shelly, wird der Shelly

    1. seinen Ausgang einschalten
    2. eine MQTT Antwort senden mit dem Topic <Name für deine Quelle>/rpc

    Somit solltest du einen MQTT Subscriber mit diesem Topic nutzen können, um die Antwort des Shelly zu analysieren, bspw. im MQTT Explorer. Ich nutze dafür am liebsten Node-RED Flows.

    Noch ein wenig konkreter:

    Du lässt eine MQTT Nachricht senden mit dem Topic 'shellyplusplugs-xxxxxxxxxxxx/rpc' und der Payload '{"id":"schalte_ein","src":"smartcenter","method":"Switch.Set","params":{"id":0,"on":true}}'
    Dann antwortet der Shelly mit dem Topic 'smartcenter/rpc' und der Payload: '{"id":"schalte_ein","src":"shellyplusplugs-xxxxxxxxxxxx","dst":"smartcenter","result":{"was_on":false}}', wenn der Ausgang vorher ausgeschaltet war. War dieser bereits eingeschaltet, lautet der letzte Teil "result":{"was_on":true}.

    Ich bevorzuge selbst gewählte Topics, will an dieser Stelle aber nicht noch mehr notieren. Da ich nicht der ersten Shelly Generation nachtrauere, weiß ich derzeit nicht, ob hier deren Topics und Payloads nutzbar sind. Ich empfehle die Verwendung einer solchen, nur teilweise vorhandenen Rückwärtskompatibilität eindeutig nicht.

    Noch'n Hinweis:

    Ich täte nun die Betriebsspannung des Türöffners (an der Dose) messen.

    Wenn diese bspw. ca. 15V sein sollte, würde ich dafür eine dünne zweiadrige Leitung in der Ecke zur Fußleiste Richtung Tür, per Bohrlöchlein durch die Wand zur Steckdose führen.

    Eine Nähe Steckdose, vielleicht auch dort Nähe Fußleiste, montierte Aufputzdose kann den Shelly aufnehmen ... ;)

    Da aber die niedrige Versorgungsspannung ähnlich verlegt werden kann, ist, nach deinem Foto zu vermuten, die umgekehrte Montage vielleicht noch einfacher bzw. "schöner".

    ^^ Und ich kam hier herein, weil ich dachte, es ginge um Sommer.

    Lucas Lucas

    Vermutlich möchtest du gerne alles in der Leerdose unterbringen.

    Wenn du solches "erzwingen" willst, solltest du eine Fachkraft zu Rate ziehen, die

    1. überprüft, ob in naher Umgebung neben der N-Leitung auch eine Dauer L-Leitung (Phase) zur Verfügung steht.
      Am sichersten wäre ein Handwerker, der sein Tun justiziabel verantwortet.
    2. wenn vertretbar, die 230V L-Leitung zur Leerdose führt.

    Vermutlich wird der Türöffner, ähnlich einer Klingel, mit Niedrigspannung betrieben. Ich weiß nicht, ob es zulässig ist, 230V mit Niedrigspannung in einer Dose zu führen. Technisch wäre es aber möglich.

    SvenT

    Mehr Clouds sind schlechter als weniger Clouds, am besten keine Cloud. 8o

    Nur als Ergänzung und für den Blick über den Tellerrand:

    Die beste Lösung ist ein eigenes zentrales System, welches die Daten aufzeichnet und verarbeitet.

    Dieses sollte zu Hause werkeln. Zur Datenübertragung können folgende Verfahren genutzt werden.

    1. VPN von Wohnung und Garten
    2. Autarke Aufzeichnung im Garten per Skript, s.a. meine Lösung für einen Freund
      Die Daten können auf dort erläuterten Wegen übertragen werden:
      1. per öffentlichem MQTT Broker,
      2. per Copy & Paste,
      3. Transport des remote Shelly, wird für dich weniger in Frage kommen.
        Dafür ließe sich aber ein zusätzlicher Shelly ab 2. Generation nutzen, welcher als Daten-Packesel dient.

    Der Garten Pro 3EM kann per Skript die Rohdaten bereits verarbeiten, das kann aber auch auf dem zentralen System erfolgen.

    Ich betone noch einmal: Das ist zunächst nur zum aufzeigen von besseren Lösungen gedacht und kein Vorschlag für dich, da ich weder deine Kenntnisse noch deine Ambitionen kenne. Solange du aber nicht weißt, was möglich ist, kannst du solches ja nicht in's Auge fassen. Viel Erfolg bei deinen Zielen! :)

    I am using a Shelly Plus 1 for self-sufficient heating control on a radiator for about a quarter of a year. This regulation is based on a script, which also provides a web server suitable for the application. So far I haven't noticed any failure.

    I store the control data in an Influx database and let it display via Grafana.

    Wenn du einen Shelly Plus 1 (oder auch Plus 2PM) mit Plus AddOn verwendest und die Pegelmessung dem AddOn analog zuführst, geht so etwas.

    Solche Sensoren liefern ein digitales Signal, weshalb diese nicht parallel zu deinem analogen Sensor angeschlossen werden. Dafür besitzt das AddOn digitale Eingänge.

    Ob dies mit einem Plus Uni auch ähnlich gelingen kann, weiß ich derzeit nicht. Ich werde mir gelegentlich zwei davon zulegen müssen.

    Per Skript wurde solches oder ähnliches bereits implementiert.

    Wenn du skripten nicht abgeneigt bist, kannst du darin einen eigenen Subscriber mit selbst gewählten Topic registrieren und alles, was du möchtest in dessen callback Funktion implementieren - grenzenlos. ;)

    Btw, "switch:0" ist reserviert für das Schalten des Ausgangsrelais. Ich würde mich wundern, wenn diese Component auch für die farbigen LED gelten täte.

    So übersichtlich kann die Antwort auf die HTTP Request dargestellt werden. ;)

    Ich brauche so etwas nicht, vermute aber, dass ein config Parameter erforderlich ist, dessen Wert ein Objekt (JSON Format) sein muss.

    In diesem Objekt können dann alle Teile, ich nenne solche "Komponenten" - nicht mit Component verwechseln, aufgeführt werden, die eingestellt werden sollen.

    Was du in der MQTT message/payload unterbringen kannst, hängt von deinem Frontend ab.

    Edit:

    Nach meiner bisherigen Erfahrung ist die Firmware eigene MQTT Kommunikation gewöhnungsbedürftig, weil sie, anders als im MQTT Standard, eine Peer to Peer Kommuniktion über den Broker nachbildet. Ich nutze solches per Node-RED, es bleibt trotzdem wenig vertraut.