VPN/Proxy erkannt
Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.
Nach weiteren Experimenten habe ich einen naheliegenden und auf einfache Weise funktionierenden Weg gefunden, BLU Daten unmittelbar nach deren Eintreffen zu verarbeiten. Das folgende Skript sendet diese Daten als MQTT Nachricht weiter.
Ich bin beeindruckt, mir wie viel Energie du da ran gehst!
Eine Frage zum Script: müssen die BLU-Sensoren trotzdem als Components angelegt sein? Oder empfängst du einfach jeden Sensor, weil er "über Bluetooth mit dem Shelly verbunden" ist?
Das ist in node-red natürlich schön und übersichtlich und schlank 
Ich verfolge noch den Ansatz, die Shellies so dumm wie möglich zu lassen, um bei einem Tausch lediglich das topic richtig einstellen zu müssen. Bei einfachen Switches und Rollladen usw. geht das echt gut, bei BLU Devices muss ich dazu halt noch die ganzen Components eintragen...
Alles in allem noch kein wirklich schöner Weg für mich. Am besten fände ich es, wenn ich in einem BLU Sensor ein mqtt-topic angeben könnte und jeder Gen3 Shelly, der einen BLU empfängt, dann einfach dieses topic durchreicht. Aber ich kann schon verstehen, warum der Hersteller das nicht machen wird...
Kann man in Node-RED Bluetooth Node(s) installieren
Da habe ich mich leider unklar ausgedrückt.
Der Plan (weil ich gerne auf Script und Actions verzichten möchte): im Gen3 Shelly alle BLU Sensoren in Components anlegen.
Dann in node-red topic und ggf. offset einfügen
Und, weil nicht überall Empfang, eben auf mehreren Gen3 die gleichen Components einrichten.
Im node-red kann ich, falls zu viele Nachrichten ankommen, limitieren...
Vielen Dank eiche und erstmal gute Besserung!
Ich tendiere dazu, weder Script noch Action zu nutzen, und meine BLU Sensoren gleich in Node-red weiter zu verarbeiten. Da kann ich topics verwalten, ggf. offsets einstellen usw.
Weißt du (oder jemand anderes gerne auch), wie viele BLU Sensoren ich auf einem Shelly Gen3 über Components anlegen kann?
Ich habe derzeit 9-10 im Einsatz...
Vielleicht ist ein Mehrfachempfang unerheblich, da ja dann alle beteiligten Gen 3 Geräte die gleiche Nachricht senden täten.
Ich meine das eher andersrum. Ich habe die Erfahrung gemacht, dass bei uns im Haus oft nur ein Shelly von mehreren das BLU Device empfängt oder ich die BLUs auch rumtrage und der ursprüngliche Gen3 Empfänger agr nicht mehr in Recihweite ist...
Sehr beeindruckend, mit wie viel Elan du da tief eingestiegen bist eiche ! Top!
Wenn ich gleich mehrere Gen3 Geräte habe, die BLU Sensoren empfangen können/ sollen ohne Script: dann muss ich auf jedem Gen3 Components anlegen, richtig? In node-red muss ich dann mehrere Empfänger bündeln, weil ich ja nicht weiß, welcher Gen3 die Message vom BLU empfängt wenn ich es richtig verstehe.
VG, Martin
mein DimmerG3 wird über MQTT einwandfrei gesteuert.
hast du da mal ein konkretes Beispiel?
Hi Thomas,
hast du schon MQTT-Erfahrung mit Gen2/Gen3 Shellies? Da hat sich einiges geändert seit Gen1...
Einen Dimmer habe ich leider nicht. Aber grundsätzlich kenne ich zwei Wege zum steuern.
1. über shellies/topic/command/switch:0
dort ein on oder off schicken
2. über shellies/topic/rpc
dort ein JSON hinschicken z.B. { "method": "Cover.Open", "params": { "id": 0}}
Und mal wieder eine bitte an den Hersteller, z.B. Angel , die Doku ein bisschen Nutzerfreundlich zu gestalten.
Beim Dimmer und dann unter https://shelly-api-docs.shelly.cloud/gen2/Component…tt#mqtt-control
steht einfach nur
Von Dimmer ist da keine Rede.
Einfach pro Shelly drei MQTT-Beispiele, die man zum testen einfach in einen MQTT Explorer oder Kommandozeile mosquitto schreiben kann. Und schon hat man nicht ein Forum mit einigen solcher Anfragen und dazu noch weniger frustrierte User...
Schöne Grüße
Martin
Gibt es die möglichkeit, das der Taster Vorrang hat und erst der 5 Stunden Countdown abgewartet werden muss, bis das Shelly wieder auf node red hört?
Also wenn du das auf node-red Ebene lässt und dort mitbekommst, dass der Taster gedrückt wurde, dann kannst du in node-red über ein Gate oder auch die switch-node die mqtt-Kommunikation zum Shelly unterbrechen.
VG, Martin
hattest du die bereitgestellten Beta-Versionen der FW 1.5.0 getestet und konntest du diese Fehler dort auch schon feststellen?
Nein, die 1.5.0 habe ich noch gar nicht getestet.
Mein Anliegen ist ein viel globaleres. Ich hoffe, ich habe mich verständlich ausgedrückt...
Wenn die Zeitspanne für den Fix ungewiss ist, macht ein Rollback durchaus Sinn
Ich finde es total schade, dass so ein Rollback nur durch den Hersteller entschieden und ausgelöst werden kann!
Und ich verstehe einfach nicht den Grund, warum ich nicht Zugriff (auf von mir aus verschlüsselte und signierte) auf Firmware Files habe und selber testen und entscheiden darf!
Bei einer FritzBox geht das ja auch und ohne Bedenken vom Hersteller.
Von uns ambitionierten Usern mit Scripten oder vernetzten übergeordneten Systemen braucht ja jeder ein "Labor", um jede Firmware zu testen bevor man ausrollen kann ohne Rückweg...
Aus meiner Sicht sollte sich die Shelly Group gut überlegen, ob sie eine individuelle Smart Home Lösung anbieten möchte mit einer offenen Community oder ein iPhone (bei dem die alten Firmware Files wenigstens noch ein paar Tage signiert und somit Rollback fähig sind)!
Danke für eure Rückmeldungen.
LS-Leuchten gibt es keine bei uns. Der Kühlschrank hängt auf einer anderen Phase...
Ich mache es wie von Krauskopp empfohlen und ignoriere 
Guten Morgen,
ich habe vorgestern eine Mail aus der Shelly Cloud erhalten:
Shelly Cloud - Überspannung erkannt von Heizband Küche!
Heizband Küche hat eine Überspannung festgestellt!Change email notification preferences at: control.shelly.cloud
Auf dem Shelly, der eine 40W Last schaltet (ein Selbstregulierendes Heizband hinter einem Küchenschrank zur Schimmelvermeidung), wurde im Spannungsverlauf 600! Volt angegeben.
Kein anderer Schelly, weder an dieser noch einer anderen Phase oder sogar am gleichen LS hat jemals so etwas von sich gegeben.
Ich kann mir das nicht erklären...
Ich hatte heute das Gleiche mit einem 2pm Gen3 frisch aus der Schachtel.
Mit der App (iOS) eingebunden und auf Cover gestellt. Dann hatte ich zwei Cover, das zweite aber ohne IP und Cloud-Symbol.
Was geholfen hat: den Shelly aus der App löschen und dann wieder hinzufügen über das + Zeichen und „Netzwerk scannen“.
Der 2pm hatte noch alle Einstellungen und ist jetzt nur noch wie gewohnt 1x zu sehen…
Weiß eigentlich jemand, was so ein Gen3 Gateway ausmacht? Kann das einen anderen Funk-Standard als alle anderen?
Und ein Gen4 Shelly? Kann der dann Gateway für BLU TRVs?
Insgesamt wirkt das etwas inhomogen auf mich...
Ich habe leider keinen Plug.
Aber ein Plug Plus S sollte ein Gen2 Gerät sein und dieser Syntax folgen.
Ist MQTT grundsätzlich aktiv und kannst du den Shelly im Broker sehen? Ist MQTT Control auf der Website des Shelly aktiviert?
Hast du zB den MQTT-Explorer und kannst damit monitoren und testen?
Dein topic sollte
shellies/shellyplusplugs-e465b8b5c9ec/command/switch:0
oder halt
shellyplusplugs-e465b8b5c9ec/command/switch:0
sein.
Hallo Andrey,
das ist recht ähnlich wie gestern in diesem Thread hier:
Vielleicht hilft dir das dort ja!
Was mir auffällt: dein topic muss: shellies/Name/command/switch:0 heißen!
VG, Martin
und habe 'shellies' nun schon ein paar mal gelesen
Das kannst du in den MQTT Settings einstellen:
Broadcasst nutze ich nicht. Nur zur besseren Sortierung im MQTT Baum damit ich Shellies von anderen MQTT sprechenden Geräten unterscheiden kann.
Denkbar wäre hier natürlich eine größere STruktur wie /Haus/1.OG/Licht/Schalfzimmer/Flutlicht...
Hallo zusammen,
auch wenn ich kein HA Nutzer bin, hat dieser Beitrag für mich große MQTT-Erhellung gebracht!
Danke marco.gr ! Deine Aussage:
'MQTT Control' aktiviert hast
war ein Schlüssel! Diese Option ist für mich leider nur auf der (eigenen) Website der Shellies zu sehen. In der (iOS) App und unter https://control.shelly.cloud ist diese Option nicht zu sehen:
Nachdem ich mich in der Vergangenheit so wie Sprinterfreak sehr geärgert habe zB beim Wechsel auf eine andere Generation über die verschiedenen MQTT-Wege und die schlechte API-Doku, hat mich dieser Thread sehr weitergebracht!
Und es funktioniert wie angegeben: ein zB Mini1PMG3 lässt sich auf dem Topic shellies/Name/command/switch:0 mit einem Text on oder off schalten.
Super! Das hätte ich gerne vorher mal verstandden...
Hi Schnick,
bist du dir sicher, dass im Treppenhaus alles an derselben Phase hängt?
