Beiträge von eiche

Zitat

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

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

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.

Ich möchte noch einen Hinweis hinzufügen.

Das Umkonfigurieren schreibt in den nichtflüchtigen Speicher (nvs), welcher weniger Schreibzugriffe verträgt als der flüchtige Speicher (RAM).

Ein Skript an dieser Stelle braucht kein Schreiben in den nvs. Das könnte dann geringfügig bedeutsam sein, wenn die Firmware beim Konfigurieren in immer dieselben Zellen des nvs schreibt, was ich vermute.

Dies muss allerdings nicht als entscheidendes Kriterium für eine Entscheidung zum Skript angesehen werden.

Zitat von Pajda

Also ab Shelly plus benutzen die Shelly adapter mit mqtt

Mit "die" meinst du vermutlich "die, welche den ioBroker pflegen".

Die Bedeutung von "benutzen die Shelly adapter mit mqtt" kann auch sein, dass die Shelly Geräte Adapter für MQTT nutzen.

Letzteres ist vermutlich schon deshalb nicht gemeint, weil auch Shelly der ersten Generation MQTT können.

Dann bleibt zu hoffen, dass die kleinen Umkonfigurationen rechtzeitig vor den Schaltaufträgen wirken.

horkatz

Hast du dies hinreichend getestet?

Willst du also ausschließlich mit dem Shelly Plus 1 auskommen?

Dann wirst du wissen, wie du die Leitungen legen willst.