Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[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!

[didag15]

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

@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).

Es kommen sofort wieder Fehlauslösungen, also man drückt und nichts passiert oder man drückt und der verbundene Shelly geht an und sofort wieder aus.
Damit bleibe ich lieber bei meiner Verzögerung, da klappt es seit 2 Wochen :-D
Danke für deine Hilfe!!!

[cntzr]

Bin erst über die Weihnachtstage auf den Thread gestoßen. Ich kann das Problem mit den Fehlauslösungen aus meiner Umgebung bestätigen. Und ich bin dankbar für den Workaround, der da gefunden wurde!

Ich setze sowohl den Shelly BLU Wall Switch 4 als auch den Shelly BLU RC Button 4 ein. Die Fehlauslösungen als auch die wilde Schaltung einer Lampe über verschiedene Tasten traten bei beiden Geräten auf.

Meine Lösung sieht im Moment so aus ...

Die UserVar's für den Status und die Helligkeit brauche ich, da ich die Lampen auch über VIS2 und teilweise auch über Hue und die dortigen Dimmer schalte.

[simonf04]

@cntzr naja du brichst ja nicht ab im 1. falls.
Somit löst natürlich nacher direkt das 2. und schaltet wieder aus.

Also z.b. im 1. Falls ein "return" (keine Ahnung wie der blockly block dafür heist und kommt grad nicht in mein admin)

Oder statt dem "und wert von objekt = ..."
Nur =1 und darin geschachtelt nochmal ein falls mit dem steuere wahr und "else" teil steuere mit falsch

[didag15]

@cntzr
Danke für deine Antwort. Sehr schön, dass du auch das Problem hast :-) Also natürlich eigentlich nicht schön, aber schön zu hören, dass ich nicht der Einzige bin, habe schon Stunden und Tage damit zugebracht, hier jeden Stein in meinem System umzudrehen um den Fehler zu finden.

Meine Erkenntnis zur Fehlerabfolge:

• Der Schalter sendet den Tastendruck zu sämtlichen Gateways in der Umgebung.
• Die Gateways, die den Befehl empfangen, senden ihn an den den ioBroker weiter.
• Der Shelly Adapter des ioBrokers verarbeitet diesen ankommenden Befehlen nun alle der Reihe nach.
• Wenn sie nahezu zeitgleich ankommen, sieht man nur den PID 2 oder mehr Zähler hochspringen und das script wird einmalig verarbeitet.
• Wenn sie zeitlich versetzt ankommen, lösen sie dann mehrfacht das script aus und dann haben wir das Problem des Mehrfachschaltens
• Deshalb schafft die Verzögerung Abhilfe, da die eintreffenden, zeitlich leicht versetzten Befehle nicht verarbeitet werden sondern innerhalb der Verzögerung ins Leere laufen.

Wer jetzt hier in der Kette die Lösung liefern könnte (Schalter, Gateway, Shelly Adapter) ist mir nicht ganz klar. Vermutlich müsste aber der Befehl vom Schalter mit einer Auslösenummer versehen werden, damit der Shelly Adapter unterscheiden kann, ob ein und die selbe Auslösung mehrfach kommt oder es sich um mehrfache Auslösungen handelt, die dann natürlich alle ausgeführt werden müssen.

Was tun? Ich weiß es nicht. Dafür reichen meine Kenntisse nicht aus.

Der Workaround mit der Verzögerung läuft jetzt bei mir seit 3 Wochen ohne jegliches Problem.

[mcm1957]

Was tun?
Ein DEBUG Log mot genauer Doku wann drr Taster gedrückt wurde sollte helfen. Ev auchvein Log mit level silly.

Man muss als etstes mal festhalten was genau von Shelly gesendet wird.

Und die Sequencenummer in jeder BLE Nachricht gibt es. Die vergibt Shelly. Und der Adapter ignoriert idente Meldungen mit selber Sequence Nummer = PID.

Hab mir vor Weihnachten mal nen BLE 4 bestellt und werd nen Testaufbauch machen SOBALD ICH DAZU KOMME. Derzeit gibts aber noch einige andere Shelly Dinge und auch noch anderes zu tun.