[Beantwortet] [V4.1.1] Shelly Plus RGBW PM per MQTT ansteuern

Wissen, Planung & Diskussion zur MQTT Unterstützung im Timberwolf Server.
Stellt uns hier Eure MQTT Projekte und Ideen vor.
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
Antworten

Ersteller
fsl
Reactions:
Beiträge: 139
Registriert: Do Nov 01, 2018 12:23 pm
Hat sich bedankt: 64 Mal
Danksagung erhalten: 67 Mal

[V4.1.1] Shelly Plus RGBW PM per MQTT ansteuern

#1

Beitrag von fsl »

Moderation: Abgespalten als neuer Thread (stammte ursprünglich als Folgepost von hier viewtopic.php?f=81&t=5526#p58995)

ms20de hat geschrieben: Do Nov 14, 2024 2:27 pm Kann man einfach über eine Logik (String format (int)) zusammenbauen.
Bin auf diesen Thread gestoßen, weil ich ein Shelly Plus RGBW PM benutzen will, um auf drei Kanälen einen KNX-Dimmer für LED-Strips nachzubauen (leider liegt da kein KNX-Kabel). Bin auch auf der V4.1.1.

Was man per MQTT steuern kann ist laut der Doku hier ziemlich beschränkt. Ein- und Ausschalten per MQTT-Explorer mit einem "set,true" und "set,false" in Format "raw" funktioniert. Auch den Dimmwert in Prozent kann ich setzen per "set,true,50" usw., wobei sich Ein/Aus und Dimmwert nicht beeinflussen. Es ist also auch "set,false,100" möglich und wird auf dem Status-Topic entsprechend gemeldet.

Ich will nun also eine Logik bauen, die mir aus den KNX-GA Ein/Aus (x) und Dimmen absolut (y) ein String im Format "set,x,y" baut, was mir genau das hier diskutierte Problem scheint. Leider ist mir nicht klar, wie ich das "einfach" machen kann. Vielleicht könnte jemand dies hier kurz mit einem Screenshot von der Logik erklären, so dass dieser Thread auch in dieser Hinsicht vollständig wäre?
Zuletzt geändert von blaubaerli am Fr Jul 25, 2025 11:18 am, insgesamt 3-mal geändert.
TWS 950Q ID:310 + PBM ID:10072, VPN offen, Reboot erlaubt
TWS 3500L ID:1030, VPN offen, Reboot erlaubt

chtonian
Reactions:
Beiträge: 30
Registriert: Mi Mai 25, 2022 2:43 pm
Danksagung erhalten: 14 Mal

#2

Beitrag von chtonian »

Shelly unterstützt doch inzwischen nativ KNX
Beste Grüße
Sebastian
TWS 3500 ID:645, VPN - Werkszustand, Reboot - nach Rücksprache

gbglace
Reactions:
Beiträge: 4104
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1434 Mal
Danksagung erhalten: 1923 Mal

#3

Beitrag von gbglace »

Aber nicht alles in der Detailtiefe wie z.B. per MQTT und nicht jeder hat einen KNX-IP-Router in der Anlage.

Ein Button z.B. kann Multitastbefehle, am KNX gibt es aber nur KO für das simple AN/AUS usw.
Grüße Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU

Ersteller
fsl
Reactions:
Beiträge: 139
Registriert: Do Nov 01, 2018 12:23 pm
Hat sich bedankt: 64 Mal
Danksagung erhalten: 67 Mal

#4

Beitrag von fsl »

Das bei mir fragliche Gerät aus der "Plus"-Reihe kann kein KNX und ich habe tatsächlich keinen Router.

Darum soll es jetzt aber nicht gehen, es wurde hier eine Lösung aufgezeigt, die ich bis zu der Sache mit der Konkatenierung nachvollziehen konnte. Könnte das jemand kurz noch hier erklären?
TWS 950Q ID:310 + PBM ID:10072, VPN offen, Reboot erlaubt
TWS 3500L ID:1030, VPN offen, Reboot erlaubt

blaubaerli
Reactions:
Beiträge: 2695
Registriert: Sa Sep 15, 2018 10:26 am
Wohnort: Kerpen
Hat sich bedankt: 1016 Mal
Danksagung erhalten: 808 Mal

#5

Beitrag von blaubaerli »

Hallo @fsl

bitte kapere keinen als bereits beantwortet markierten Thread mit Bezug zu einem Device A mit einer anderen Frage zu einem Device B? Das kann hier für die Ordnung nicht zielführend sein.

Ich werde den Teil hier in einen neuen Thread abspalten.


Verrätst du uns deinen Vornamen, wie spreche uns hier genren persönlich an.

Danke. :handgestures-salute:

Beste Grüße
Jens
Zuletzt geändert von blaubaerli am Do Jul 24, 2025 10:44 pm, insgesamt 1-mal geändert.
timberwolf168(2600er)VPN offenReboot nach Vereinbarung
timberwolf1699(3500XL)VPN offenReboot jederzeit
wiregate1250
Bitte WIKI lesen.

Ersteller
fsl
Reactions:
Beiträge: 139
Registriert: Do Nov 01, 2018 12:23 pm
Hat sich bedankt: 64 Mal
Danksagung erhalten: 67 Mal

#6

Beitrag von fsl »

Gut, es ging eigentlich um die konkrete Umsetzung des Zusammenbauens des Strings, insoweit ist es genau dasselbe Problem, wie im anderen Thread.

Ich habe es jetzt mit zwei Logiken probiert, eine die von KNX das Ein/Aus nimmt und in die strings "true" bzw. "false" umwandelt. Das funktioniert, wie man im Doktormodus sehen kann.

Das Resultat kommt dann in eine zweite Logik, wo ein Parameter "set," eingegeben wird und dann an das entsprechende MQTT-Topic verknüpft ist. Der Doktormodus zeigt mir nun aber nicht das erwartete Resultat, also entweder "set,true" oder "set,false" als string. Was mache ich da falsch?

Bild
TWS 950Q ID:310 + PBM ID:10072, VPN offen, Reboot erlaubt
TWS 3500L ID:1030, VPN offen, Reboot erlaubt

gbglace
Reactions:
Beiträge: 4104
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1434 Mal
Danksagung erhalten: 1923 Mal

#7

Beitrag von gbglace »

Hast Du es einmal mit einem ganz einfachen ODER Baustein versucht?

links den binären booleschen Eingang rein und am Ausgang Ausgangsfunktion: "Mapping zu Text" (letzte Zeile der Dropliste), da dann für true set,true und für false set,false eingeben fertig.

Für so eher statische Umwandlungen sicher ausreichend.

Verketten usw. braucht es ja eigentlich erst wenn da dynamische Textelemente verbunden werden müssen.

Diese Lösung funktioniert hier bei mir auf der aktuellen IP 7 zur V4.5. (sowas ist ein Grund keine alten Threads zu übernehmen, da heutige Lösungen anders sein können als damalige)
Grüße Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU

ms20de
Elaborated Networks
Elaborated Networks
Reactions:
Beiträge: 1285
Registriert: Sa Aug 11, 2018 9:14 pm
Hat sich bedankt: 365 Mal
Danksagung erhalten: 742 Mal

#8

Beitrag von ms20de »

fsl hat geschrieben: Do Jul 24, 2025 11:22 pm Das Resultat kommt dann in eine zweite Logik, wo ein Parameter "set," eingegeben wird und dann an das entsprechende MQTT-Topic verknüpft ist. Der Doktormodus zeigt mir nun aber nicht das erwartete Resultat, also entweder "set,true" oder "set,false" als string. Was mache ich da falsch?
Das Problem ist die Tigger Einstellung am Eingang. Bei U wird der Wert nur hinterlegt, aber führt nicht dazu dass die Logik etwas aussendet.
In der Insider Version haben wir die Darstellung verbessert, dass bei den Ein- und Ausgängen mehr Beschreibungen und ein Filtersymbol sichtbar sind.

Bild

Viele Grüße,
Matthias
[ Timberwolf Entwicklung ]

TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage
TWS 3500 ID:695 VPN offen, Bitte kein Reboot ohne Absprache

blaubaerli
Reactions:
Beiträge: 2695
Registriert: Sa Sep 15, 2018 10:26 am
Wohnort: Kerpen
Hat sich bedankt: 1016 Mal
Danksagung erhalten: 808 Mal

#9

Beitrag von blaubaerli »

Hallo zusammen,

das hier:
fsl hat geschrieben: Mi Jul 23, 2025 8:34 am Was man per MQTT steuern kann ist laut der Doku hier ziemlich beschränkt.
mag zwar im Bezug auf diesen konkreten Link so korrekt sein, aber es gib ein an anderer Stelle dokumentiertes Verfahren, mit dem die vollständige Steuerung über MQTT gelingt.

Ich war da zu Beginn auch frustriert :angry-banghead: , habe aber dann die relevante Doku hier gefunden. :whistle:

Die zusammengebauten JSONs gehen dabei dann an "shellyplusrgbwpm-xxxxxxx/rpc"

Um das zu ermöglichen, muss im Shelly-Device in den Settings "Enable RPC over MQTT" und ggf. für das Auswertten des Status dann auch "RPC status notifications over MQTT" aktiviert werden. Das bezieht sich bei mir auf die Firmware "1.4.4" für das "Shelly Plus RGBW PM". Die jetzt dort gerade aktuell verfügbare "1.6.2" habe ich noch nicht getestet.

Beste Grüße
Jens
PS: Ich habe den Eindruck, dass Shelly seit meiner damaligen Einrichtung da die Doku gehörig gepimpt hat....
Zuletzt geändert von blaubaerli am Sa Jul 26, 2025 12:10 pm, insgesamt 1-mal geändert.
timberwolf168(2600er)VPN offenReboot nach Vereinbarung
timberwolf1699(3500XL)VPN offenReboot jederzeit
wiregate1250
Bitte WIKI lesen.
Antworten

Zurück zu „MQTT“