NEWS
Shelly BLU RC Button sendet mehrfach Signale
-
@Fabio sagte in Shelly BLU RC Button sendet mehrfach Signale:
@didag15 die Frage lautet wie oft hast du das Script vom Shelly Adapter in Shellys eingfügt.
Beispiel von mir: Ich habe ein Shelly Blue Gateway, darin ist das Script vom @haus-automatisierung drin und darüber laufen meine Bluetooth Verbindungen. Ich habe alle und hatte alle Buttons von Shelly darüber in ioBroker und habe darüber meine Lichter geschaltet ohne Probleme.
Wenn zum Beispiel der Button über mehrere Shelly Verbindungen hat ist es auch logisch das wenn du ein Mal klickst auch so oft geschaltet wird wie Skripte es von unterschiedlichen Shellys melden.Na gut, dann ist das wohl genau das Problem. Alle Shellys (ca.8 Stück, Rolläden usw) haben das Script am Laufen. Ich dachte dadurch, dass ich in der Shelly App einstelle, mit welchem Shelly Gateway der Schalter kommunizieren soll, redet er auch nur mit diesem einen und nicht mit allen die in Reichweite sind.
Ungünstig wäre auch, dass man ja nie sicher sagen kann, ob sich nicht 2 Gateways in einem Haus überlappen an der Stelle wo ein Schalter ist.
Leuchtet mir nicht ganz ein wie das mit mehreren Gateways zB auf unterschiedlichen Etagen im Haus gehen soll wenn nur ein einziger Gateway das Script aktiv haben darf, aber dessen Reichweite nicht fürs ganze Haus reicht.
Aber immerhin kenne ich jetzt Mal die Ursache fûr mein Problem.
Danke!@didag15 sagte in Shelly BLU RC Button sendet mehrfach Signale:
nur ein einziger Gateway das Script aktiv haben darf
... das habe ich nicht gesagt.
Ich finde es sowieso sehr komisch da Bluetooth eigentlich immer nur eine Verbindung zulässt. Also ich kann dir sagen, so wie ich es gemacht habe, hatte ich nicht ein einziges mal Probleme damit. Aber du verstehst das, so wie es jetzt bei dir ist zu Problemen führen kann.
Grüße
Fabio -
Mit dem Hinweis von dir dass offenbar alle Gateways in Reichweite die Signale senden macht es für mich Sinn, dass da je nach Laufzeit wie sie am ioBroker eintrudeln kurz hintereinander Schaltvorgänge auslösen können.
Daher habe ich jetzt mal eine Verzögerung beim Schalten des Shelly von 500ms eingestellt. Und siehe da, es läuft wie geschmiert. Scheinbar reicht die Zeit (vllt. geht auch noch kürzer, ich taste mich mal nach unten), damit die über die Gateways leicht zeitverzögert gesendeten Schaltersignale bei ioBroker eintreffen und nicht weiter beachtet werden. Das erste Signal zählt, alle anderen laufen in den 500ms ins Leere.Aus meiner Sicht ein Fehler in der Shelly Umgebung, denn ich gebe beim Einrichten der Schalter explizit an, mit welchen Gateways geredet werden darf. Wenn der Schalter dann trotzdem über alles sendet, was gerade in der Umgebung ist, dann muss Shelly hier nachbessern. Ich sehe das auch im iobroker unter den objekten bei "receivedby". Dort tauchen bei einem einzigen Tastendruck immer wieder mehrfach verschiedene Shellys hintereinander auf.
Ich mache mal ein Ticket bei Shelly auf. Vllt können sie ja was dazu sagen.Danke dir nochmals für deine Hilfe!
-
Mit dem Hinweis von dir dass offenbar alle Gateways in Reichweite die Signale senden macht es für mich Sinn, dass da je nach Laufzeit wie sie am ioBroker eintrudeln kurz hintereinander Schaltvorgänge auslösen können.
Daher habe ich jetzt mal eine Verzögerung beim Schalten des Shelly von 500ms eingestellt. Und siehe da, es läuft wie geschmiert. Scheinbar reicht die Zeit (vllt. geht auch noch kürzer, ich taste mich mal nach unten), damit die über die Gateways leicht zeitverzögert gesendeten Schaltersignale bei ioBroker eintreffen und nicht weiter beachtet werden. Das erste Signal zählt, alle anderen laufen in den 500ms ins Leere.Aus meiner Sicht ein Fehler in der Shelly Umgebung, denn ich gebe beim Einrichten der Schalter explizit an, mit welchen Gateways geredet werden darf. Wenn der Schalter dann trotzdem über alles sendet, was gerade in der Umgebung ist, dann muss Shelly hier nachbessern. Ich sehe das auch im iobroker unter den objekten bei "receivedby". Dort tauchen bei einem einzigen Tastendruck immer wieder mehrfach verschiedene Shellys hintereinander auf.
Ich mache mal ein Ticket bei Shelly auf. Vllt können sie ja was dazu sagen.Danke dir nochmals für deine Hilfe!
@didag15 sagte in Shelly BLU RC Button sendet mehrfach Signale:
Ich sehe das auch im iobroker unter den objekten bei "receivedby". Dort tauchen bei einem einzigen Tastendruck immer wieder mehrfach verschiedene Shellys hintereinander auf.
Das ist ja auch komplett richtig. Die haben das Signal ja alle empfangen. Zeigt aber, dass alles die gleiche PID ist. Oder taucht das gleiche Gerät öfter in der Liste auf?!
-
du sollst echt nicht auf den pid triggern, sonden auf die Datenpunkte der Buttoms selber die gedrückt werden. Du musst natürlich auch das Blokly anpassen und ich würde auch nicht umschalten dafür nehmen. Und mach die Updates vom Shelly Adapter und dem Script es sollte nur auf einen Gateway/Shelly drin sein.
@Fabio sagte in Shelly BLU RC Button sendet mehrfach Signale:
Mach mal folgendes setze den Datenpunkt auf 0 nach jedem schalten
Bitte keine "fremdem" Datenpunkte selbst schreiben (nur wenn diese auch schreibbar/writeable sind - und dann nur unbestätigt).
In diesem Fall ist es so, dass man nicht auf "wurde geändert" triggern sollte, sondern auf "wurde aktualisiert", da der gleiche Wert (z.B. einfacher Tastendruck) auch 2x hintereinander kommen kann.
@Fabio sagte in Shelly BLU RC Button sendet mehrfach Signale:
Und mach die Updates vom Shelly Adapter und dem Script es sollte nur auf einen Gateway/Shelly drin sein.
Das Script darf natürlich auf beliebig vielen Shellies laufen. Das ist ja Sinn der Sache.
-
@didag15 die Frage lautet wie oft hast du das Script vom Shelly Adapter in Shellys eingfügt.
Beispiel von mir: Ich habe ein Shelly Blue Gateway, darin ist das Script vom @haus-automatisierung drin und darüber laufen meine Bluetooth Verbindungen. Ich habe alle und hatte alle Buttons von Shelly darüber in ioBroker und habe darüber meine Lichter geschaltet ohne Probleme.
Wenn zum Beispiel der Button über mehrere Shelly Verbindungen hat ist es auch logisch das wenn du ein Mal klickst auch so oft geschaltet wird wie Skripte es von unterschiedlichen Shellys melden.@Fabio sagte in Shelly BLU RC Button sendet mehrfach Signale:
Wenn zum Beispiel der Button über mehrere Shelly Verbindungen hat ist es auch logisch das wenn du ein Mal klickst auch so oft geschaltet wird wie Skripte es von unterschiedlichen Shellys melden.
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
receivedByListe mit mehreren Geräten angereichert, welche das Signal alle bekommen haben. -
@Fabio sagte in Shelly BLU RC Button sendet mehrfach Signale:
Wenn zum Beispiel der Button über mehrere Shelly Verbindungen hat ist es auch logisch das wenn du ein Mal klickst auch so oft geschaltet wird wie Skripte es von unterschiedlichen Shellys melden.
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
receivedByListe mit mehreren Geräten angereichert, welche das Signal alle bekommen haben.@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
receivedByListe 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?
-
@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 -
Die Id kommt vom Device (BLE Device, nicht Gateway, n icht adapter)
https://shelly-api-docs.shelly.cloud/docs-ble/Devices/BLU/wall_usBitte 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.
-
Die Id kommt vom Device (BLE Device, nicht Gateway, n icht adapter)
https://shelly-api-docs.shelly.cloud/docs-ble/Devices/BLU/wall_usBitte 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.
@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
-
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 :-)
-
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 :-)
@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
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
@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 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.
@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
-
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.
-
@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
@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.
-
@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). -
@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).@simonf04 Genau so ist es richtig!