Weihnachtsangebot 2025! 🎄

[mcm1957]

@haus-automatisierung sagte in Shelly BLU RC Button sendet mehrfach Signale:

Genau das wird ja abgefangen, da die alle die gleich PID haben. Die Daten werden nur neu in die Datenpunkte geschrieben, wenn die PID unterschiedlich der vorigen ist. Ansonsten wird die receivedBy Liste mit mehreren Geräten angereichert, welche das Signal alle bekommen haben.

Ich stell nur mal eine Hypothese (!) in den Raum:
Da der Taster zeitweise ZWEI Meldungen extrem kurz hintereinander sendet (128 und 1) kann es da ev sein, dass der erste Gateway das 128 Packerl weiterleitet und dann das 1er Packerl. Und dann erst vom zweiten Gateway das 128er und dann das 1er kommt?

In den Fall würde sich die PID mehrfach ändern bzw, die PID einmal zurückspringen. Unetrdrückt der Adpater derzeit ältere PIDs ? Wenn nicht wär das ev. sinnvoll oder nicht?

[Fabio]

@haus-automatisierung ich hab ne Frage, die pid kommt von wem? Von dem gedrückten Button oder vom dem Shelly wo das Script eingebunden ist? Wenn das so wäre wie du geschrieben hast das das abgefangen wird dürfte das Licht doch dann nur ein Mal geschaltet werden und nicht öfters. Es kann aber auch sein das ich es nicht richtig verstanden habe. 🙈
Grüße Fabio

[mcm1957]

Die Id kommt vom Device (BLE Device, nicht Gateway, n icht adapter)
https://shelly-api-docs.shelly.cloud/docs-ble/Devices/BLU/wall_us

Bitte daher um folgende Mithilfe:

• DEBUG Log erstellen
• Zeilen mit "Processing (decrypted) payload..." filtern
• Schaun wie es da mit dem PID Wert aussieht. Springt dieser zurück, sprich kommt ein kleinerer Wert als der Vorgänger?

Bitte ggF das Log posten.

[didag15]

@mcm1957
Der PID Wert springt immer Mal wieder zurück. Drücke ich den Schalter 1x gibt es am PID Wert ziemlich viele Zustände zu beobachten:

• PID wird um eins erhöht
• PID wird um 2 erhöht
• PID wird um 2 erhöhen und anschließend wieder um 1 reduziert
• ...

Dass der PID Wert direkt zurück springt habe ich noch nicht beobachtet.

Ich konnte bis jetzt keine Systematik erkennen, bei welchem der pid Zustände der Shelly an der Lampe 1x schaltet, mehrfach schaltet oder gar nicht schaltet.

Hier das Log gefiltert nach payloadlog.txt

[mcm1957]

Im attachten Log sehe ich nur den PID 154 in Verbindung mit dem Shelly Button. Ev. kannst du ja mal - wenn du Zeit hast - mehr loggen. Konkret wäre es interessant ob bzw. was der Button sendet wenn der PID des Buttons wechselt / zurückspringt. Ist aber nicht prior - im Moment hab izumidnest ich eh zu wenig Zeit :-)

[didag15]

@mcm1957
der Log liefert genau die Stelle, wo die Taste 1x gedrückt wird, der Shelly die Lampe aber an und sofort wieder aus schaltet, also genau der Fehlerfall.
Ich mache wie o.g. Mal ein Ticket bei Shelly. Wenn der Button über alle Gateways sendet die in Reichweite aber nicht ausgewählt sind, ist das die Hauptursache des Problems.

[mcm1957]

@didag15 sagte in Shelly BLU RC Button sendet mehrfach Signale:

@mcm1957
Der PID Wert springt immer Mal wieder zurück. Drücke ich den Schalter 1x gibt es am PID Wert ziemlich viele Zustände zu beobachten:

• PID wird um eins erhöht
• PID wird um 2 erhöht
• PID wird um 2 erhöhen und anschließend wieder um 1 reduziert
• ...

Dass der PID Wert direkt zurück springt habe ich noch nicht beobachtet.

Ich konnte bis jetzt keine Systematik erkennen, bei welchem der pid Zustände der Shelly an der Lampe 1x schaltet, mehrfach schaltet oder gar nicht schaltet.

Hier das Log gefiltert nach payloadlog.txt

Das Spingen der PID ist - wenn ich nicht blind bin - log NICHT zu sehen. Ich seh nicht mal irgendeine Änderung der PID (des Switches)

Ev poste mal das ungefilterte DEBUG LOG (durchaus auf den Shelly Adapeter eingegrenzt aber ohne auf paylod od. andere Texte zu filtern) damit man sieht wann dein Script da die Lampe schaltet.

Die Ursache seh zumindest ich nicht bei Shelly. Es ist durchaus OK wenn ein Tester über mehrere Gateways sendet. Dies durch Auswahl einzuschränken ist bei fix montierten Schaltern sinnvoll um die Last zu reduzieren. Und wenn das nicht funktioniert wär es ein Shelly Problem. Wahrscheinlich hast du den Button aber nur bei mehreren Shellies angelernt. Hast du bei den nicht erwünschten Gateways schon geprüft ob die den Button kennen und ihn ggF dort rausgelöscht ?

Aber wenn du z.B. einen Shelly Button verwendest wäre es ja explizit gewunschen dass der nicht nur an einer Stelle funktioniert.

[didag15]

@mcm1957
Stimmt, eigentlich ist es wünschenswert wenn ein BLE sich ein passendes Gateway sucht und sendet. Hier ist es aber so, dass über mehrere Gateways gesendet wird. Zumindest sehe ich das im Objekt unter receivedby, denn da erscheinen manchmal 2 Gateways.

Durch die 500ms Verzögerung läuft es seither einwandfrei. Das heißt, der erste Gateway gibt das Signal und alles was danach kommt wird Ausgeblender statt wie ohne Verzögerung ebenfalls noch mit verarbeitet - was dann immer wieder zu Doppel oder dreifach Schaltungen geführt hat.

Ich habe Shelly mal angefragt warum hier mehrfach gesendet wird.

Danke für eure Hilfe

[mcm1957]

Schön dass es für dich nun funktioniert. Allerdings würde ich noch immer gerne verstehen warum da eine Verzögerung notwendig ist. Es sollte definitiv ohne irgendwelche extrernen Kunstgriffe gehen auch wenn mehrere Gateways aktiv sind. Aber ja - kann das auch mal in eienr Testumgebung versuchen zu reproduzieren.

[haus-automatisierung]

@didag15 sagte in Shelly BLU RC Button sendet mehrfach Signale:

Stimmt, eigentlich ist es wünschenswert wenn ein BLE sich ein passendes Gateway sucht und sendet.

Es existiert ja kein "Pairing". Das heißt, es wird einfach nur eine Nachricht gesendet. Die kann jeder empfangen. Das Gerät selbst weiß nichtmal, ob die Nachricht jemand bekommen hat.

@didag15 sagte in Shelly BLU RC Button sendet mehrfach Signale:

Das heißt, der erste Gateway gibt das Signal und alles was danach kommt wird Ausgeblender

Genau so sollte es ja gerade funktionieren.

[simonf04]

@didag15
Weis nicht wie dein Skript gerade aussieht und verwend selber direkt TS und kein Blockly, aber so sollte es funktionieren:

Wichtig hier:
das direkte verwenden von "Wert" und nicht erneut aus dem Objekt holen (könnte sich in der Zwischenzeit bereits geändert haben). Vielleicht genau dein Timing Problem mit dem 128.
und der Trigger auf den button Zustant (nicht PID!).
und "wurde aktualisiert" verwenden. Nicht "wurde geändert", ansonstenten funktionierst klarerweise nur beim 1. mal (außer du machst mehrfachklick zwischendrin, was ja aber nicht der Sinn war).

[haus-automatisierung]

@simonf04 Genau so ist es richtig!