Beiträge von eiche

ToLa62

Ich glaube, dass die Funktion dieses Dings dokumentiert ist.

Ich nutze in diesem Zusammenhang kein Bluetooth Gerät.

Zitat von Weesee

Kann ich damit z.B. ein Script schreiben, mit dem ich den Shelly schalte, wenn ein bestimmtes Bluetooth-Gerät (z.B. Smartphone) in Reichweite kommt?

Vermutlich geht auch solches. Aber zunächst wird ein Skript benötigt, welches ein Bluetooth Gerät erkennen kann und dessen Nachrichten in das WLAN überträgt.

Es gibt auf github ein bereits dafür geeignetes Skript, in welchem man für eigene Zwecke nur den Konfigurationsteil ändern bzw. anpassen muss.

Dieses Skript macht den Shelly Plus 1 zu Gateway Bluetooth --> WLAN, aber afaik nur für ein Bluetooth Gerät. Für bspw. 3 solcher Geräte kann man das Skript dreimal speichern, anpassen und starten. Ob dies auch in einem einzigen Skript gelingt, weiß ich mangels Erfahrung nicht.

Das Skript: https://github.com/ALLTERCO/shell…ther-devices.js

Zitat von Weesee

Was bedeutet RPC in diesem Fall genau?

RPC = Remote Procedure Call ist in der Dokumentation recht ausführlich beschrieben. Wenn man das Prinzip einmal verstanden hat, ist es relativ leicht anzuwenden.

Afaik muss man zum konfigurieren eines Shelly Blu Gerätes die App verwenden. Vermutlich kann man damit auf dem Blu Gerät die gewünschten RPC eintragen.

I've read the documentation again. Then I tested LWT with a Shelly Plus Plug S. As broker I used test.mosquitto.org:1883.

When I plugged in the Shelly, after a short time of 2 or 3 seconds I received the online message with the payload "true".

When I unplugged the Shelly, after about 90 seconds I received the online message with the payload “false”.

I suspect that this will work reliably if the supply is lost.

Occasionally the value "false" was displayed when trying with an unreliable connection.

I suspect that the cause of this behavior is due to a better or worse connection and cannot be eliminated.

Btw, on my Shelly Plus Plug S the topic looks like “shellytype-MACaddress/online” without the word “status”. It should be the same in your Shelly.

Ich schaute mir die MQTT Kommunikation per Firmware noch genauer an.

Wenn man in der MQTT-Konfiguration das Prefix ändert, dann gelingt die MQTT-Kommunikation unter Verwendung dieses Prefix.

Bsp.: Prefix = "mein/prefix"

Damit lautet das Topic, mit welchem man einen RPC Kanal des Shelly nutzen kann "mein/prefix/rpc"

Die Antwort des Shelly beinhaltet in der Payload als "src"-Wert trotzdem den von der Firmware vorgegebenen Prefix, welcher mit der MQTT Client Id übereinstimmt.

Dies tut er auch dann noch, wenn man diese Client Id ändert. Man kann somit den "src"-Wert in einer MQTT-Antwort nicht ändern. Dies erscheint mir als nicht konsequent.

Das muss dich nicht weiter stören, es kann aber verwirren, wenn man mit diesen Konfigurationseinträgen experimentiert.

Zitat von Jay DM

Heißt, wenn ein Durchgang da ist, ist der Reed okay?

Nein. Der Reed-Schalter ist dann ok, wenn er mal aus und mal ein ist. Wenn er also mal Durchgang hat und mal nicht.

Für einen Test kannst du mal Wasser fließen lassen.

Deine teilweise eingekreiste grün hinterlegte Anzeige sagt vermutlich nur etwas über einen von dir zu konfigurierenden mathematischen Ausdruck aus.

Dieser Ausdruck steht ja darunter.

Da ich (mal wieder) so etwas nicht habe, kann ich leider nicht mehr dazu sagen.

Honkoponko123

Willst du IP Adressen sparen?

Hast du so viele Geräte, dass dein Vorrat an IP Adressen knapp wird?

Es ist selbstverständlich deine Sache, wenn du unbedingt Bluetooth verwenden willst. Ich verstehe aber nicht warum?

Ich habe keine solche Ausstattung, mit welcher ich dies alles testen könnte, daher meine leicht kritische Frage:

Gelingt so etwas nicht per Actions?

Actions hätten den Vorteil, dass sie lokal verarbeitet werden, also das ganze Cloud-Gedöns nicht brauchen. Und was lokal arbeitet, arbeitet i.d.R. zuverlässiger.

Zusatzbemerkung:

Ich täte so etwas mit einem Shelly Pro 3EM und einem lokal arbeitenden Skript lösen. Das ist allen anderen Lösungen an Funktionssicherheit überlegen. Ok, die meisten mögen keine Skripte. Das ändert aber nichts an deren Überlegenheit.

Und ein eigenes Smart Center kann alles besser und zuverlässiger als diese Cloud. UnfluxDB, Grafana, ...

Do you know the script method MQTT.isConnected() or the using of a MQTT got connection handler - registration via MQTT.setConnectHandler(...)?

Perhaps those can fix the issue.

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

Zitat von henfri

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.

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.

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

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.

Das wäre dann eine zu eng sitzende Schutzkleidung. Spannend

Da staunt der Laie und der Fachmann wundert sich. Frauen selbstverständlich auch ... und noch andere Wesen.

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:

{
    "methods": [
        "PLUGS_UI.SetConfig",
        "PLUGS_UI.GetConfig",
        "PLUGS_UI.GetStatus",
        "Switch.ResetCounters",
        "Switch.SetConfig",
        "Switch.GetConfig",
        "Switch.GetStatus",
        "Switch.Toggle",
        "Switch.Set",
        "Schedule.List",
        "Schedule.DeleteAll",
        "Schedule.Delete",
        "Schedule.Update",
        "Schedule.Create",
        "Webhook.ListSupported",
        "Webhook.List",
        "Webhook.DeleteAll",
        "Webhook.Delete",
        "Webhook.Update",
        "Webhook.Create",
        "FFS.GetToken",
        "FFS.GetStatus",
        "Script.Stop",
        "Script.Start",
        "Script.Eval",
        "Script.GetCode",
        "Script.PutCode",
        "Script.SetConfig",
        "Script.GetConfig",
        "Script.GetStatus",
        "Script.List",
        "Script.Delete",
        "Script.Create",
        "WS.SetConfig",
        "WS.GetConfig",
        "WS.GetStatus",
        "Mqtt.SetConfig",
        "Mqtt.GetConfig",
        "Mqtt.GetStatus",
        "Cloud.SetConfig",
        "Cloud.GetConfig",
        "Cloud.GetStatus",
        "BLE.CloudRelay.List",
        "BLE.SetConfig",
        "BLE.GetConfig",
        "BLE.GetStatus",
        "Wifi.Scan",
        "Wifi.ListAPClients",
        "Wifi.SetConfig",
        "Wifi.GetConfig",
        "Wifi.GetStatus",
        "Sys.SetConfig",
        "Sys.GetConfig",
        "Sys.GetStatus",
        "KVS.Delete",
        "KVS.Set",
        "KVS.GetMany",
        "KVS.Get",
        "KVS.List",
        "HTTP.Request",
        "HTTP.POST",
        "HTTP.GET",
        "Shelly.ListMethods",
        "Shelly.PutTLSClientKey",
        "Shelly.PutTLSClientCert",
        "Shelly.PutUserCA",
        "Shelly.Reboot",
        "Shelly.SetAuth",
        "Shelly.Update",
        "Shelly.CheckForUpdate",
        "Shelly.DetectLocation",
        "Shelly.ListTimezones",
        "Shelly.GetComponents",
        "Shelly.GetStatus",
        "Shelly.FactoryReset",
        "Shelly.ResetWiFiConfig",
        "Shelly.GetConfig",
        "Shelly.GetDeviceInfo",
        "OTA.Abort",
        "OTA.Write",
        "OTA.Data",
        "OTA.Start",
        "OTA.Revert",
        "OTA.Commit",
        "OTA.Update",
        "Sys.SetDebug"
    ]
}

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.

Zitat von CLohn

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".

Ja Thomas, das hast du doch bereits hinreichend beantwortet.

Das Netzteil muss aber irgendwo untergebracht werden. Deshalb habe ich ergänzend die andere Perspektive verwendet.

Ok, dann schreibe ich noch:

Lucas Lucas

Mit einer Batterie einen Shelly zu betreiben, ist afaik uninteressant, weil diese i.d.R. zu schnell leer wäre.

Gut so?

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.

und

Zitat von Schubbie

Leider hat Allterco ab Gen2 einiges geändert

Ich finde, dass Alterco daran sehr gut getan hat. Die API per RPC, Components, ... ist erheblich besser, weil deutlich flexibler nutzbar.

Und, mal nebenbei, Fortschritt ist oft nicht bequem.

To the documentation: Shelly Button 1 - MQTT

1. Create a Flow!
2. Use the MQTT subscriber node (mqtt in)!
3. Entry a sufficient topic like shellies/shellybutton1-<deviceid>/# !
4. Analyze the incoming messages!

Good luck!