Beiträge von eiche

Ich habe derzeit keinen einsatzfähiges BLU Ding, weshalb ich nichts dergleichen testen kann.

Als ich mir die Skriptvorlage ansah, fand ich aber sehr viel Code, der ausschließlich für DAUs erforderlich ist. Deshalb sollte man das Skript erheblich verschlanken können.

Zitat von akreienbring

Ich hab dann den BLE Scanner ausgelagert. Dieser löst nun Events aus, die die entsprechenden Datenpaket der Devices enthalten.

Du meinst vermutlich Events, welche lokal auf demselben Gateway Shelly verarbeitet werden.

Zitat von akreienbring

Macht die Sache zwar schlanker, allerdings sind aber auch nur 3 aktive Scripte pro Gateway erlaubt.

Ein EventHandler kann leicht verschiedene Events unterscheiden. Dazu braucht es nicht mehrere Skripte.

Hast du mal daran gedacht, den Scanner "Script.Eval" Methoden nutzen zu lassen? Damit ließen sich statt verschiedener Events auszulösen verschiedene Skript-Funktionen aufrufen. Ich kann nicht einschätzen, ob dies Vorteile bringen kann.

Die Sache mit dem KVS habe ich noch nicht verstanden. Willst du damit KVS-Einträge auf anderen Shelly immer dann schreiben/ändern, wenn von einem BLU Ding eine Bluetooth Nachricht eintrifft? Dann müsste dem anderen Shelly dies ja zusätzlich irgendwie mitgeteilt werden. Und mit einer solchen Mitteilung ließen sich ja Parameter senden, deren Werte mit der Nachricht eines BLU Dings korrespondieren.

Btw, Es ist nicht abwegig, von einem "BLU Ding" zu sprechen. Schließlich gibt es auch den Begriff des Internet of Things (IoT).

Zitat von AlexAn

Noch irgendwelche Sachen die ich dir "schuldig" bin ?

Außer der LWT Info nichts.

Das Auslösen der beim Broker hinterlegten LWT Nachricht ist ja unstrittig. Diese hast du detailliert aufgeführt in #10.

Es geht aber um die LWT Nachricht selbst, Topic + Payload, die der Broker vom Client erhalten muss, damit er diese in seiner Datenbank hinterlegen kann und zwar nicht als übliche retained Nachricht.

Dies lässt sich relativ leicht testen.

Ich ließ den Shelly online und sendete von einem anderen Client eine Nachricht mit dem LWT Topic des Shelly und der Payload "aha".

Der Subscriber erhielt sofort die Nachricht "aha".

Dann trennte ich den Shelly von der Versorgung und wartete.

Nach der kleinen Ewigkeit von ca. 90s traf die LWT Nachricht des Shelly ein mit der Payload "false".

Somit ist klar, dass es LWT Nachrichten gibt, welche der Broker als solche speichert und nicht wie eine normale retained Nachricht behandelt.

Wäre dies nicht so, hätte der Subscriber nicht die LWT Nachricht des Shelly mit der Payload "false" erhalten können, da der Broker als letzte retained Nachricht mit demselben Topic ein "aha" gespeichert hat.

Also muss der Broker zwischen LWT Nachrichten und normalen retained Nachrichten unterscheiden.

Wann der Shelly diese spezifische LWT Nachricht an den Broker sendet, bleibt noch offen. Er kann dies dann tun, wenn diese im Shelly geändert wurde, wofür ich nur das Ändern des MQTT Prefix kenne. Er kann die LWT Nachricht aber auch nach jedem Booten an den Broker senden. Dies ist tatsächlich unerheblich, da die LWT Nachricht eh vom Broker gespeichert wird. Ich vermute, dass der Shelly mit jedem Booten seine LWT Nachricht sendet, da man ja auch den Broker wechseln kann.

Auch dir und allen Mitlesern Frohe Ostern!

Ich habe es getestet und es ist auch selbstverständlich.

Man kann mit dem LWT Topic eine Nachricht beliebigen Inhalts senden, die der Broker sofort weiterreicht, bspw. "aha". Das wird aber vom Broker nicht als LWT gewertet.

Wenn ich dann den Shelly temporär von der Versorgung trenne, sendet der Broker dessen LWT Nachricht "false", aber um ca. 90s später.

Nach dem Power On Reset erhält der Subscriber 2 bis 3 Sekunden später eine Nachricht mit dem LWT Topic und der Payload "true" und nach einem erneuten Power Off die Nachricht "false", nur um ca. 90s später.

Alles klar und verständlich.

Du bleibst mir aber die Antwort auf meine Frage schuldig, woher der Broker die LWT Nachricht des Shelly (oder eines anderen Client) kennt, wenn diese nicht vom Client übermittelt wurde.

Dies muss der Client immer dann tun, wenn er eine Verbindung zum Broker aufgebaut hat. Damit der Broker nach dem Verbindungsaufbau die Nachricht "true" sendet, muss ihm dies vom Client zugesandt worden sein. Dem Broker sind die Inhalte von MQTT Nachrichten völlig wurscht, er muss nur "wissen", wann er eine LWT Nachricht an Subscriber senden soll/muss.

Zitat von AlexAn

Weil das vorher "vereinbart" wurde. Wird im Broker gespeichert sobald du die Einstellungen in der Shelly gespeichert hast.

Das könnte zutreffen. Dann müsste ich per anderem Client und normaler Nachricht die LWT Nachricht des Shelly ändern können. Das werde ich testen.

Zitat von AlexAn

Der Client kann dem Broker auch gar nichts mitteilen wenn er offline ist oder einen Protokoll Fehler hat.

Genau deshalb trifft die "false" Nachricht erst viel später beim Subscriber ein, nachdem der Shelly "gestorben" ist - wegen Power off.

Wie erklärst du, dass beide Nachrichten, zuerst "false", danach "true" im Abstand von 2 bis 3 Sekunden beim Subscriber eintreffen, wenn der Shelly rebootet wird?

Bei Power off hingegen trifft die "false" Nachricht erst erheblich später ein, bspw. ca. 90s.

Ich kenne die Doku auf hivemq.com.

Deine Aussage ist aber unlogisch.

Grund:

Woher soll der Broker die LWT Nachricht des jeweiligen Client kennen, wenn der Client ihm diese nicht mitteilte? Eine Standard LWT Nachricht gibt es nicht.

Zitat von AlexAn

Ein "false" wird nie vom Device gesendet (hat ja wenig Sinn wenn er offline ist)

Selbstverständlich sendet der Client die LWT Nachricht, wenn er online ist.

Es kann aber auch sein, dass die Shelly Firmware tatsächlich alle x Sekunden die LWT Nachricht <MQTT Prefix>/online mit "false" sendet. Eine solche gibt der Broker ohnehin erst weiter, wenn er keine Verbindung zum Client mehr feststellt. Hier ist aber zwischen normaler Nachricht und LWT Nachricht zu unterscheiden. Ich kann ja nur die im Subscriber eintreffenden Nachrichten untersuchen. Solche treffen aber ausschließlich ein, wenn sich der Online Status des Shelly ändert.

Wenn die Payload "true" eintrifft, erfolgt dies praktisch unmittelbar nachdem der Shelly diese als übliche Nachricht gesendet hat.

Die Payload "false" trifft aber immer um eine erhebliche Zeitverschiebung von grob 90s ein, nachdem der Shelly von der Versorgung getrennt wurde.

Wenn sich der Shelly per Firmware, andere MQTT Nachrichten habe ich nicht senden lassen, alle x Sekunden per Nachricht mit dem Topic <MQTT Prefix>/online melden täte, müsste der Broker diese Nachricht auch alle x Sekunden an die Subscriber senden. Das tut er aber nicht. Das lässt sich leicht an einem Subscriber feststellen, der die Historie protokolliert, wie bspw. der MQTT Explorer oder ein Node-RED Flow mit mqtt in node und angeschlossenem debug node. Man kann so etwas selbstverständlich auch per MQTT.subscribe() callback Funktion in einem Shelly Skript untersuchen.

Somit kann deine Vermutung über ein periodisches Senden von Nachrichten mit diesem Topic nicht zutreffen.

Edit:

Täte ein MQTT Broker solche Nachrichten nicht an Subscriber weiterreichen, wäre er kein MQTT Broker.

Ich sah hier einige Unklarheiten in Bezug auf das Verhalten der Shelly Firmware mit MQTT. Ich wollte es also selbst genauer wissen und habe Versuche angestellt.

Meine Erkenntnisse aus diesen Versuchen habe ich an anderer Stelle dokumentiert.

Kurze Zusammenfassung:

Die Shelly Firmware der zweiten Generation veröffentlich nach dem Verbindungsaufbau zum MQTT Broker zwei Nachrichten.
Vermutlich arbeitet die Firmware der ersten Generation ebenso.

1. Die LWT Nachricht mit dem Topic "<MQTT Prefix>/online" und der Payload "false".
   LWT = Last Will (and) Testament
2. Eine reguläre retained Nachricht mit demselben Topic und der Payload "true".

Somit ist per Subscriber (fast) jederzeit erkennbar, ob der betreffende Shelly eine MQTT Verbindung hat, also online ist.

Bei schwacher Verbindung zum Broker, vielleicht wegen schwachem WLAN, wechselt die im Subscriber erhaltene Payload unregelmäßig zwischen "false" und "true".

Jedenfalls sendet der Broker offensichtlich verlässlich mit dem LWT Topic eine Nachricht "true" oder "false".

Zitat von meres gr

but is is specific about actions, not the whole Cloud connection.

Afaik it affects the whole cloud connection but not the actions (=webhooks).

Zitat von meres gr

Is this the expected behavior?

Yes, that is the documented behavior. You can only use either the cloud or MQTT in Shelly Generation 1.

When the Shelly boots, it logs in to the broker as a client and sends its LWT.

topic: <shellytype-macaddress>/online

payload: "false" as LWT

At the same time, it sends the payload “true” with the same topic as a normal retained MQTT message (afaik).

This shows that Shelly is online. If it goes offline, it may log out with the payload "false". If it doesn't do this because it lost power, the broker will report this a while later. My tests showed about 90 seconds later.

When a client logs in to the broker that subscribes to the above topic, it receives the payload "true" or "false" from the broker.

"false" if the Shelly currently has no connection to the broker.

Both messages, LWT and "true", are retained afaik. That definitely makes sense.

Conclusion:

It makes no sense to send an additional LWT or payload “true” with this topic via a script.

But you can use a MQTT subscriber in a script to determine whether another Shelly is online or not.

And you can use both handlers, connect or disconnect, to determine the own MQTT online status.

Also you can use these handlers or MQTT.isConnected() to check whether, for example, measurement data needs to be temporarily saved locally because it cannot currently reached the destination.

If you changed the MQTT prefix to e.g. “this/is/my/topic”, you must use this prefix instead of <shellytype-macaddress> in a subscriber topic!

I don't know if it's professional to call an LWT retained, but that makes it understandable.

Nutzt du einen Plug S (1. Generation) oder einen Plus Plug S (2. Generation)?

Ok, dann für beide.

Plug S: 'http://<IP Adresse>/relay/0?turn=on' zum einschalten, turn=off zum ausschalten, turn=toggle zum umschalten.
Dokumentation

Plus Plug S: 'http://<IP Adresse>/rpc/switch.set?id=0&on=true' zum einschalten, on=false zum ausschalten, .../rpc/switch.toggle?id=0 zum umschalten

Dokumentation

Tippe mal auf die linke Hälfte in der jeweiligen Gerätezeile!

So finde ich jedenfalls den Öffnungsgrad, allerdings in keiner Übersicht.

Doch, auch in der Übersicht, allerdings erst nachdem der Rollladen angehalten wurde.

Zu keinem meiner Rollladen-Shelly fehlt die Anzeige (kleines Symbol unten links) des Öffnungsgrades ...

Kannst du denn die Rollläden per App/Cloud steuern, bei denen der Öffnungsgrad nicht angezeigt wird?

Ich spielte ein wenig herum und habe "Aus dem globalen Aktivitätsprotokoll ausschließen" aktiviert.

Merkwürdigerweise kann ich nun den Rollladen per App/Cloud steuern, es wird mir aber weder das Pausensymbol zur Verfügung gestellt, noch der Öffnungsgrad angezeigt (nur 0%).

Wenn ich "Aus dem globalen Aktivitätsprotokoll ausschließen" aufsuche, wird mir dies als inaktiv angezeigt.

Da steckt irgendwie der Wurm drin.

Ich bin froh, dass ich die App nicht wirklich brauche.

Nach einem erneuten Starten der App (Einloggen) ist der Zustand wieder wie vor meiner Änderung und die Bedienung sowie die Anzeige funktionieren wieder.

Das sollte per HTTP Nachrichten gelingen.

Jedenfalls liefert der folgende URL die MQTT Konfiguration, allerdings ausschließlich auf Geräten der Generation 2+.

'http://<IP Adresse>/rpc/mqtt.getconfig'

Demzufolge sollte folgender URL funktionieren, ohne diesen getestet zu haben.

'http://<IP Adresse>/rpc/mqtt.setconfig?config={"server":"<neue IP Adresse:Portnummer"}'

Die IP Adressen aller betroffenen Shelly können in ein Datenfeld geschrieben werden, welches Eintrag für Eintrag per Schleife abgearbeitet wird.

Das kann sogar ein Shelly Generation 2+ per Skript erledigen.

Ich täte solches wohl per kleinem Node-RED Flow erledigen.

Für Geräte der Generation 1 bin ich momentan noch überfragt.

Habe nachgeschaut. Die Dokumentation gibt darüber Auskunft.

Ach nee, das ist ja nur ein Thread in der Kategorie "OFFTOPIC".

Ich muss das noch üben.

Jetzt blicke ich bei den Pfaden durch.

... und ich sehe, dass es eine Kategorie "OFFTOPIC" gibt.

thgoebel Hast du die soeben angelegt, oder gibt es die schon länger?

Do.ofe Frage. Gäbe es die schon länger, sollte sie doch ziemlich gefüllt sein.

Oder es gibt noch viele Teilnehmer, die sich entweder verirren oder off topics nicht als solche einstufen.

Äh, und danke für den trostreichen Gruß!

Ich hoffe, dass dieser Osterhase rechtzeitig für einen Nachfolger gesorgt hat ...

Aah, etwas dazugelernt.

Dann gibt es den folgenden Pfad?

Forum -> Shelly BLE -> Was sind Shelly BLE Geräte? -> Shelly Blu Door Window

Ich erkannte nicht, dass es in diesen nebeneinander stehenden Aufzählungen eine Verbindung gibt.

Ich bin halt daran gewöhnt, solche Verbindungen zu kennzeichnen.

NorbertM

Ich staune über deine hellseherischen Fähigkeiten.

Oder ich bedauere meine Unfähigkeit zu finden, um welche Geräte es sich bei pixeljunky handelt.

Zitat von Krauskopp

Ich beziehe mich jetzt mal auf den 900W Heizstab

Kraftwerkbetreiber schrieb von 900W, Metzgerjo bisher nicht. Die Leistung seines Verbrauchers hat er bisher nicht genannt. Nur mal so.

Diese Fragen kann ich aus folgenden Gründen nicht beantworten.

1. Ich nutze derzeit keine Blu Shelly.
2. Ich nutze insbesondere die App extrem selten, wie auch die Cloud.
3. Ich kenne das Skript nicht.

Prinzipiell halte ich einen Skriptfehler als Ursache für möglich, wenn auch in deiner Konstellation als wenig wahrscheinlich.