[Gelöst] MQTT für WLED, rgb reading mit # klappt nicht

Begonnen von stefanru, 22 März 2019, 21:16:26

Vorheriges Thema - Nächstes Thema

sinus61

Danke, die Api Befehle könnte aber alle angepasst werden, hab das hier mal gemacht und auch noch dimup und dimdown Befehle hinzugefügt.


#source post: https://forum.fhem.de/index.php/topic,98880.msg995308.html#msg995308
name:wled_controller
filter:TYPE=MQTT2_DEVICE
desc:To control a WLED device, see https://github.com/Aircoookie/WLED/wiki for details).
order:W_01
par:BASE_ID;BASE_ID typically is wled;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/][^/]+[/][^/]+:, ? $1 : undef }
par:DEVNAME;Device name as configured;{ AttrVal("DEVICE","readingList","") =~ m,[^:]+[/]([^/]+)[/][^/]+:, ? $1 : undef }
par:ICON;ICON as set, defaults to hue_filled_iris;{ AttrVal("DEVICE","icon","hue_filled_iris") }
attr DEVICE icon ICON
attr DEVICE setList\
  on:noArg BASE_ID/DEVNAME on\
  off:noArg BASE_ID/DEVNAME off\
  toggle:noArg BASE_ID/DEVNAME t\
  rgb:colorpicker,RGB BASE_ID/DEVNAME/col #$EVTPART1\
  brightness:colorpicker,BRI,0,1,255 BASE_ID/DEVNAME\
  speed:colorpicker,BRI,0,1,255 BASE_ID/DEVNAME/api SX=$EVTPART1\
  intensity:colorpicker,BRI,0,1,255 BASE_ID/DEVNAME/api IX=$EVTPART1\
  palette:selectnumbers,0,1,46,0,lin BASE_ID/DEVNAME/api FP=$EVTPART1\
  effect:selectnumbers,0,1,101,0,lin BASE_ID/DEVNAME/api FX=$EVTPART1\
  loadPreset:selectnumbers,0,1,3,0,lin BASE_ID/DEVNAME/api PL=$EVTPART1\
  dimup:noArg BASE_ID/DEVNAME/api A=~10\
  dimdown:noArg BASE_ID/DEVNAME/api A=~-10 
attr DEVICE readingList \
  BASE_ID/DEVNAME/status:.* LWT\
  BASE_ID/DEVNAME/g:.* brightness\
  BASE_ID/DEVNAME/g:.* { $EVENT ? {"state"=>"on"} : {"state"=>"off"} }\
  BASE_ID/DEVNAME/c:.* { {"rgb"=>substr("$EVENT",1,6)} }\
  BASE_ID/DEVNAME/v:.* api\
  BASE_ID/DEVNAME/v:.* { $EVENT =~ m,(?<=<sx>)([\d]+)(?=<\/sx>), ? $1 eq ReadingsVal($NAME,"speed","unknown") ? return : {"speed"=>$1} : return; }\
  BASE_ID/DEVNAME/v:.* {$EVENT =~ m,(?<=<ix>)([\d]+)(?=<\/ix>), ? $1 eq ReadingsVal($NAME,"intensity","unknown") ? return : {"intensity"=>$1} : return }\
  BASE_ID/DEVNAME/v:.* {$EVENT =~ m,(?<=<fp>)([\d]+)(?=<\/fp>), ? $1 eq ReadingsVal($NAME,"palette","unknown") ? return : {"palette"=>$1} : return }\
  BASE_ID/DEVNAME/v:.* {$EVENT =~ m,(?<=<fx>)([\d]+)(?=<\/fx>), ? $1 eq ReadingsVal($NAME,"effect","unknown") ? return :{"effect"=>"$1"} : return }
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE devStateIcon {Color::devStateIcon( $name, "rgb", "rgb", "brightness", "state" )}
attr DEVICE eventMap /effect 0:Solid/effect 2:Breathe/effect 63:Pride/effect 48:Police/
attr DEVICE webCmd rgb:brightness:Solid:Breathe:Pride:Police
attr DEVICE setStateList on off toggle
attr DEVICE comment For questions about the use of different widgets for color selection see discussion at https://forum.fhem.de/index.php/topic,98880.msg995308.html
set DEVICE attrTemplate speechcontrol_type_light_255
farewell:template has been applied successfully. <br>Note: webCmd and eventMap are just examples; adopt this to your needs.
attr DEVICE model wled_controller

Beta-User

THX, hatte sowas schon vermutet ::) ...

Ist seit eben im svn!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

andre07

wie ich sehe gibs wieder neue Funktionen wie effects gleich mal testen nur schade das die Änderungen erst aktiv werden nachdem man das template neu gesetzt hat so muss man halt immer am Ball
bleiben

Beta-User

Zitat von: andre07 am 22 Mai 2020, 01:08:24
[...] nur schade das die Änderungen erst aktiv werden nachdem man das template neu gesetzt hat so muss man halt immer am Ball
bleiben
Na ja, die (gedankliche) Alternative wäre, jeweils "automatisch" das attrTemplate anzuwenden. Mal abgesehen davon, dass das im Moment nicht vorgesehen ist, halte ich das auch nicht für wünschenswert:
- Es ist nicht ausgeschlossen, dass Fehler passieren (ich habe z.B. die wenigsten der Gadgets, für die ich die attrTemplate pflege, und alles immer (theoretisch) auszutesten, geht auch kaum).
- Was attrTemplate liefert, ist für manche auch "nur" ein Startpunkt, um dann weiter zu konfigurieren. Das ist völlig ok, aber es wäre nicht ok, die User-Settings dann jedes Mal zu überschreiben...

Ergo: Wenn es um "neue" Dinge geht, sollte man eben tatsächlich hin und wieder schauen, was es neues gibt oder aktiv mitwirken (wie hier gibt es meistens entsprechende Threads, die auch in den Beschreibungen (?) verlinkt sind...). Dann kommt das ganze "schneller in Form", und danach besteht meistens dann kein Anlaß mehr, irgendwas zu ändern.
(Es sei denn, die API oä. ändert sich, aber dann merkt man ja auch, wenn manches nicht mehr so funktioniert wie vorher).

Just my2ct.

(Aber Danke für das implizite Lob, dass es ganz brauchbar ist, was via attrTemplate so im allg. kommt 8) ).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Zitat... nur schade das die Änderungen erst aktiv werden nachdem man das template neu gesetzt hat so muss man halt immer am Ball
bleiben
Man kann bestimmt etwas basteln was auf global:UPDATE reagiert, und anhand das model Attribut "set device attrTemplate model" absetzt.
Bin nur nicht sicher, ob die Templates immer alle Parameter bestimmen koennen, damit kein Dialog geoeffnet werden muss.

Nicht falsch verstehen: das ist keine Empfehlung, weil sinnvoll, nur eine Ueberlegung, ob es technisch machbar ist.

Beta-User

Na ja, aber das wäre dann auch eher sehr global und würde potentiell "alles" erfassen, selbst wenn die attrTemplate-file gar nicht geändert wäre - ganz abgesehen davon, dass es dann immer noch schwierig wäre rauszufinden, ob denn nun gerade ein bestimmtes template geändert wurde...

Ich könnte ja ggf. die "Meldekultur" noch verbessern, aber bisher war mir das zu aufwändig.

Das "Problem" der User kann ich aber nachvollziehen: Man sieht nirgends, wann ein einzelnes Template das letzte Mal angefaßt wurde. Man müßte also entweder "auf Verdacht" anwenden oder manuell Checken, ob und was sich ggf. geändert hat.

Dazu mal in den Raum geworfen: Es wäre kein Ding der Unmöglichkeit, (nach und nach bzw. eben bei allen künftigen updates) ggf. Infos zur letzten Änderung (z.B. als "lastupdate:", "date:" oder "version:") einzupflegen. Die Frage wäre dann nur, wie der User an die Info kommt. Das könnte man über einen/mehrere setter ("?lastupdate" bzw. "?lastupdates") erledigen: ?lastupdate gäbe das update-Datum des Model des aktuellen Devices aus, ?lastupdates das aller "model" des aktuellen Device-TYPE? Immer vorausgesetzt, die Info ist überhaupt vorhanden?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Vorschlag: Man baut im Befehlsabschnitt des Templates "setreading DEVICE attrTemplateVersion X.YY" ein.
Da der Benutzer diese Befehle nach Template-Auswahl in FHEMWEB sieht, kann er feststellen, ob er die letzte Version hat.
Man sieht auch, wann das Template angewendet wurde.

Das reicht zwar fuer eine automatische Pruefung noch nicht, ich kann aber was einbauen, wenn jemand das haben will.

Beta-User

Klingt nach einem Weg :) .

Wie bereits geschrieben, _glaube_ ich, dass ein Automatismus _in der Anwendung_ keine wirklich gute Lösung ist und sowas am Ende eher Frust erzeugen könnte. Aber das mit der Anzeige des update-Datums auf diesem Weg dürften einige User hilfreich finden, und uns Helfern dürfte das auch weiterhelfen. (Hast du auf die Schnelle eine Idee, wie wir das in den aktuellen files direkt und automatisiert reinlasen könnten? Also immer vor attr DEVICE[^\b]* model bla eine Zeile rein mit "set $1 attrTemplateVersion 20200522 or prior" (mit $1 = DEVICE[^\b]*)?)

(Es gab in letzter Zeit allerdings gar nicht mehr so viel Bewegung, eigentlich kommen wir mit dem feature etwas zu spät, um das gleich ins Bewußtsein der User zu bringen...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatHast du auf die Schnelle eine Idee, wie wir das in den aktuellen files direkt und automatisiert reinlasen könnten? Also immer vor attr DEVICE[^\b]* model bla eine Zeile rein mit "set $1 attrTemplateVersion 20200522 or prior" (mit $1 = DEVICE[^\b]*)?)

In vim:
:%s/attr \(.*\) model \(.*\)/attr \1 model \2^Msetreading \1 attrTemplateVersion 20200522 or prior<return>
(wobei ^M mit CTRL-V <return> zu erzeugen ist).

Zitat... eigentlich kommen wir mit dem feature etwas zu spät...
Lieber zu spaet als nie :)

Beta-User

Zitat von: rudolfkoenig am 22 Mai 2020, 13:27:04
In vim:
Danke (auch wenn ich vim schon immer "komisch" fand, aber man lernt ja nie aus...).

War revision 22000 :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

heikoh81

Hallo Stefan,

Zitat von: stefanru am 02 März 2020, 21:30:41
Hab das jetzt mal für mein Schranklicht eingebaut.
Ist echt super. Funktioniert 1A.

ich habe mir auch mal WLED 0.1 auf einen Wemos D1 Mini gepackt, funktioniert soweit.
Nun soll das ganze natürlich aus FHEM heraus über MQTT2_Server angesprochen werden (funktioniert bei mir schon mit zahlreichen tasmota-Aktoren).

Ich habe mir deine Code-Beispiele genommen, allerdings reagiert WLED gar nicht auf diese Kommandos.
Ist denn mein MQTT-Topic so korrekt?

WLED01/Statusdisplay/
(d.h. ich ersetze wled/schranklicht/ durch WLED01/Statusdisplay/)

In WLED habe ich unter Config -> Sync Interfaces folgendes eingetragen:

  • Client ID: WLED01
  • Device Topic: Statuslicht
  • Group Topic: wled/all
Oder muss das Topic so heißen?
wled/WLED01/Statusdisplay/

Wenn ich mit mqtt.fx mitlausche und im WebIF von WLED z.B. Ein/Ausschalte, erscheint dort nur "Statuslicht":

2020-06-22 23:20:05,736  INFO --- MqttFX ClientModel             : messageArrived() with topic: Statuslicht/g
2020-06-22 23:20:05,737  INFO --- MqttFX ClientModel             : messageArrived() added: message #300 to topic 'Statuslicht/g'
2020-06-22 23:20:05,804  INFO --- MqttFX ClientModel             : messageArrived() with topic: Statuslicht/c
2020-06-22 23:20:05,805  INFO --- MqttFX ClientModel             : messageArrived() added: message #301 to topic 'Statuslicht/c'
2020-06-22 23:20:05,805  INFO --- MqttFX ClientModel             : messageArrived() with topic: Statuslicht/Statuslicht
2020-06-22 23:20:05,805  INFO --- MqttFX ClientModel             : messageArrived() added: message #302 to topic 'Statuslicht/Statuslicht'
2020-06-22 23:20:05,806  INFO --- MqttFX ClientModel             : messageArrived() with topic: Statuslicht/v
2020-06-22 23:20:05,807  INFO --- MqttFX ClientModel             : messageArrived() added: message #303 to topic 'Statuslicht/v'


Viele Grüße,
Heiko

fabse

Hallo, gibt es eine Möglichkeit die Segmente zu steuern?

Wenn ja, wie ist da der befehl?

stefanru

@heikoh81:
Sorry habe das jetzt erst gesehen. Ich hoffe du hast dein Problem gelöst.
Wenn nicht versuch doch das Template das hier für Wled Steuerung erzeugt wurde.
Also du legst ein MQTT2_DEVICE an:
define test mqtt2_device
Dann wählst du im Device bei set  test attrTemplate wled_controller
Dann füllst du alles aus und es sollte gehen.

@fabse:
Du meinst Segmente per MQTT?
Das geht indem du HTTP API sendest.
Also per MQTT dieses:

[mqttDeviceTopic]/api
-> Send an API call (using the HTTP API syntax).

Und für Segmente dann einen der HTTP API Befehle nehmen:
Parameter   Value Range   Description   Since Version
&SM=   0 to 9   Set the main segment (values are reported to XML)   0.9.0
&SS=   0 to 9   Select segment to apply THIS api call to   0.9.0
&SV=   0, 1 or 2   Set segment selected (2 unselects others)   0.9.0
&S=   0 to ledcount-1   Set segment start   0.9.0
&S2=   0 to ledcount   Set segment stop   0.9.0
&GP=   1 to 255   Set segment grouping   0.9.1
&SP=   0 to 255   Set segment spacing   0.9.1
&RV=   0 or 1   Reverse/Flip Segment direction   0.9.1
&SB=   0 to 255   Segment brightness   0.10.0

Steht alles auch im WLED Wiki.
https://github.com/Aircoookie/WLED/wiki

Gruß,
Stefan

mbrak

Hallo in die Runde

Mal ne Frage.. Hat das auch schon einer mit einem normalen Mosquitto Server in FHEM eingebunden und nicht mit dem FHEM internen MQTT2-Server?

Beta-User

Zitat von: mbrak am 16 September 2020, 19:37:37
Mal ne Frage.. Hat das auch schon einer mit einem normalen Mosquitto Server in FHEM eingebunden und nicht mit dem FHEM internen MQTT2-Server?
Gegenfrage: Ziel ist
- MQTT_DEVICE? (=> bitte separaten Thread aufmachen, ist eine ganz andere Baustelle, aber prinzipiell _kann_ man das auch passend konfigurieren.)
- Hilfestellung beim Einsatz von MQTT2_CLIENT? (Um das vorhandene attrTemplate einfach nutzen zu können). Dann bitte nach Lektüre der commandref und des Wiki-Artikels zu diesem IO-Modul ggf. auch einen eigenen Thread aufmachen, auch das ist eine ganz andere Baustelle.

Darfst gerne von hier in den betreffenden neuen Thread verlinken ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files