Sonos2mqtt - vielleicht hat jemand Lust mitzumachen

Begonnen von Otto123, 31 Mai 2020, 18:30:55

Vorheriges Thema - Nächstes Thema

TomLee

ZitatIch finde es gut wenn alles über state kommt. Ich finde man muss hier nichts auslagern. Ich möchte ja die zwischen Stati von mqtt2sonos nutzen und brauche keine mit Rückinfo von FHEM. (wenn ich nicht verstehe wofür du es genau siehst, sag bitte warum....).

Sehe das genauso, es kommt doch über transportState zu jedem Befehl immer eine Rückmeldung.
Und nein da kommt nix extra zurück bei volumeup/down, immer der komplette Json vom Rincon-Pfad und dort dann in volume_Master +/-4 nicht 5.

Setze ich ein play ab steht zuerst der Befehl play in state, dann kommt solange über transportState TRANSITIONING zurück  bis das spielen wirklich beginnt was dann mit einem PLAYING zurückkommt. Darum zeig ich in meinem devstateIcon-Beispiel in jedem span den state an wenn er nicht PLAYING ist.

bei einem stop erst der Befehl stop dann kommt STOPPED zurück.

bei einem pause erst wieder der Befehl pause dann kommt STOPPED zurück

bei einem toggle, toggle dann solange TRANSITIONING bis Playing zurückkommt.

man hat doch immer eine Rückmeldung.

Ich würde ja auch gerne Beta-User verstehen und hab mir das mit der setstateList hier  wieder mal angeschaut, komm aber auch nicht mit auf was er aus ist, liegt einfach daran das er in dieser Beziehung blind ist und wir bisher wohl nicht fähig die richtigen Daten zu liefern, die zum Verständnis hätten beitragen können.

Beta-User

Vorab mal: Den Bilden nach ist das optisch schwer ok und auch die Funktionalität ist m.E. gut gelungen!
Vor allem, dass in dem Vorschlag jetzt schon je nach "Zustand" sehr unterschiedliche Icon-Listen erscheinen, ist super! (Wie immer gefällt mir nur das mit der Einfärberei nicht; das ist hier aber eher von untergeordneter Relevanz).

Bei setStateList geht es nicht nur um einen Bug-Finder, sondern z.B. auch darum, dass man on-for-timer usw. sauber visualisieren kann (vielleicht kann man zukünftig ja Sonos-Geräte darüber ja auch mal ausschalten?), und eben alles dahin "aufgeräumt wird", wo es m.E. nach hingehört. Und "volume"-Anweisungen gehören jedenfalls meiner Meinung nach einfach nicht in "state", that's all... Aber wenn ihr entscheidet, dass das (hier) nicht wichtig ist: auch ok, und jedenfalls kein Anlaß, irgendjemand zu verhauen ;D ...

Dass die Rückmeldungen ggf. nicht 1:1 zu den settern passen, ist unschön, aber letztlich kein Grund um aus dem Fenster zu springen, dann bliebe eben volumeUp ewig auf "set_volumeUp" und nur der Zeitstempel wird aktualisiert. Und "auskennen" muß man sich mit setStateList nicht wirklich, darüber wird nur entschieden, welche set-Commands im state landen und welche eben nicht (nämlich alle anderen). Ist nicht wirklich kompliziert, oder? (Aber nochmal: gelobt sei, was funktioniert und ordentlich aussieht ;) ).

Zitat von: 87insane am 18 Juni 2020, 17:11:30
Hab das den setList Eintrag angepasst. Bei mir ändert sich dann nur das Symbol wenn ich im Gerät auf set mute gehe. Dann steht da eben nicht true/false sondern ist dieses Icon.
Das war ja genau beabsichtigt. Die Frage ist nur, ob immer ein (passendes) Icon angezeigt wird, oder ob es Lücken gibt (dann macht das keinen Sinn, wenn wir keinen Weg fänden, das zu ändern; aber auch dazu brächte ich dann Futter/Infos/traffic).
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

87insane

#257
ZitatVorab mal: Den Bilden nach ist das optisch schwer ok und auch die Funktionalität ist m.E. gut gelungen!
Vor allem, dass in dem Vorschlag jetzt schon je nach "Zustand" sehr unterschiedliche Icon-Listen erscheinen, ist super! (Wie immer gefällt mir nur das mit der Einfärberei nicht; das ist hier aber eher von untergeordneter Relevanz).
Danke!
Einfärben hat hier folgende Prio (wobei gelb echt doof ist! [kontrast])...
gelb ist Info und verschwindet nach ca. 1er Sekunde wieder
grün ist wenn der Player aus ist
rot ist wenn der Player an ist
hinzu sind Aktueller und nächster Titel gefudelt unsichtbar
alle Icons sind nur da, wenn die auch sinn machen

Das war an sich so mein Wunsch. Wenn Speak jetzt noch ginge würde ich umstellen! Ein Cover wie im Sonos Modul wäre geil aber für mich kein muss. Ich ziele hier beabsichtigt auf Statusänderungen im ersten Symbol, denn wenn ich ein Handy nutze und ggf nicht treffe, sehe ich wenigstens was ich getroffen habe, weil der finger auf einem der nebenliegenden Icons liegt.

ZitatBei setStateList geht es..
Ggf. sagst du was du genau brauchst und baust das? Ich würde dir alles rauß suchen mit genauer Anleitung durch dich.. Von mir aus auch Teamviewer..

ZitatDass die Rückmeldungen ggf. nicht 1:1 zu den settern passen, ist unschön, aber letztlich kein Grund um aus dem Fenster zu springen, dann bliebe eben volumeUp ewig auf "set_volumeUp" und nur der Zeitstempel wird aktualisiert. Und "auskennen" muß man sich mit setStateList nicht wirklich, darüber wird nur entschieden, welche set-Commands im state landen und welche eben nicht (nämlich alle anderen). Ist nicht wirklich kompliziert, oder? (Aber nochmal: gelobt sei, was funktioniert und ordentlich aussieht ;) ).
Ja mit dem Stempel wollte ich auch erst arbeiten. Ist in meinem Fall sogar nur ein :t mehr. Aber ich bin noch nicht ganz dabei (vom Verstand her...). Ist in meinen Augen mehr Aufwand für das gleiche Ziel, ohne Vorteile.

ZitatDas war ja genau beabsichtigt. Die Frage ist nur, ob immer ein (passendes) Icon angezeigt wird, oder ob es Lücken gibt (dann macht das keinen Sinn, wenn wir keinen Weg fänden, das zu ändern; aber auch dazu brächte ich dann Futter/Infos/traffic).
Naja... ich frage mich wofür ich das überhaupt tun sollte. Über sie setter in dem menu geh ich so gut wie nie. Denke mit einem guten Design im Stateformat/devStateIcon, braucht man die nicht mehr. Alles andere geht eh über notify/doif oder sonst was. Aber dann lese ich lieber 1zu1 wie der Befehl heißt. Dafür müsste ich mit der Lösung auf dem Symbol bleiben mit der Maus und den Tooltip abwarten. Ist ne lustige Sache aber an der Stelle mMn. unnütz. (ich weiß das list oder sonst was auch gingen.. aber wieder Umwege?)
Antw auf deine Frage: Ja, wenn es so aussieht:
mute:iconSwitch,false,rc_MUTE,true,rc_VOLUP { my $value = $EVTPART1 eq "true" ? "mute" : "unmute";; qq(sonos/RINCON_7828CAF4289001400/control { "command": "$value" } ) }

Hat eigentlich jemand sowas wie aktuelle Zeit des gespielten Titels gesehen? Ich finde nur Insgesamtlänge aktuell/nächster.

87insane

#258
@beta-user: eine online/offline Verknüpfung zur Bridge...gibt es sowas bisher? Hätte gerne das wenn die bridge nicht da ist, auch nix schaltbar ist oder in allen Geräten angezeigt wird das die bridge off ist. Für gewöhnlich schiebt man die bridge(s) ja in hidden oder sonst was...

Sonst würde ich den connect zweig übernehmen. Aber das wäre sicher nicht das beste. Kann man bestimmt was in der bridge selber weiter geben ...oder wie genau würde das laufen?
Geht mir auch um Bug fixing. Eine Bridge läuft für normal immer. Aber wenn mal nicht guckt man danach als User vermutlich auch als letztes. Deswegen würde ich das auch generell ggf übernehmen, wenn nichts dagegen spricht.

PS: Das hier wollte ich mal erwähnen, wenn es jemand noch nicht kennen sollte. Ist ganz interessant für die, die hier Module bauen :)
https://github.com/hobbyquaker/xyz2mqtt-skeleton

Beta-User

Das min online/offline war das LWT-Thema. Afaik gibt es dazu bisher nichts, auch nicht an der Bridge, es sei denn, die "0" wäre das entsprechend dem (über die von dir verlinkte Seite zu erreichende Empfehlung von hier: https://github.com/mqtt-smarthome/mqtt-smarthome/blob/master/Architecture.md
ZitatIt should ensure that this is set to 0 using MQTT's Last Will and Testament functionality upon a disconnect.

(sonst könnte man diesen Topic einfach auch in allen Sub-Devices abonnieren).
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

87insane

#260
Schön wie du es drehst :-P
Also der lastwill vom Server kann weitervererbt werden. Okay. Mal sehen was da geht.

Hat jemand den Dienst schon dauerhaft am rennen?

Edit: so hab ich ja auch meine Bridge eingerichtet. Wie geht das weiterverwenden nach Schema " wie gewünscht?" einfach überall mit übernehmen?

87insane

#261
Ach ja und wir haben einen Zweig übersehen...

sonos2mqtt:sonos/RINCON_1A2B3EblaHex/error:.* { json2nameValue($EVENT) }

Was mich auch daran denken lässt, wenn man eine hinzu fügt. Für uns kein Thema aber die Bridge legt kein neues Gerät an via autocreate. Sonst hätte sie auch die neuen readings rüber geschuppst..

Beta-User

Zitat von: 87insane am 18 Juni 2020, 23:06:38
Ach ja und wir haben einen Zweig übersehen...
sonos2mqtt:sonos/RINCON_1A2B3EblaHex/error:.* { json2nameValue($EVENT) }
Kannst du mal schauen, ob das diese bridgeRegexp  beseitigt:
  BASE_TOPIC/(RINCON_[A-Z0-9]+)[:/].* "$1"


Zitat von: 87insane am 18 Juni 2020, 22:01:25
Also der lastwill vom Server kann weitervererbt werden. Okay. Mal sehen was da geht.
Einfach auch BASE_TOPIC/connected:.* connected\nutzen. Wobei wir hier ja nicht wissen, ob sich eine "2" auf den konkreten Speaker bezieht oder einen anderen. Von daher wäre es evtl. besser, hier eine andere Readingbenennung ("bridgeConnected" ?) zu verwenden und ggf. nur zwischen "disconnected" (=> 0) und "running" (=> 1 oder 2) zu unterscheiden?
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

87insane

ZitatKannst du mal schauen, ob das diese bridgeRegexp  beseitigt:
Code: [Auswählen]
  BASE_TOPIC/(RINCON_[A-Z0-9]+)[:/].* "$1"
Ergibt im korrektem Device:
error_Action  Next  2020-06-19 11:31:11
error_Fault  UPnPError  2020-06-19 11:31:11
error_FaultCode  s:Client  2020-06-19 11:31:11
error_UpnpErrorCode  701  2020-06-19 11:31:11
error_name  SonosError  2020-06-19 11:31:11

Diesen Fehler habe ich provoziert indem ich Radio gestreamt habe und auf next drückte. Kommt also an wo es soll.... Danke!


ZitatBASE_TOPIC/connected:.* connected\
Habe es hinzugefügt und muss noch nachdenken. An sich kann man das ja ruhig komplett auswerten.
0 = Dienst aus
1 = Dienst an aber keine Endgeräte gefunden
2 = Dienst läuft und Endgeräte gefunden. (normal Status)

Ich teste mal ein wenig...

87insane

#264
Hab nun alles soweit... Denke das finde ich gut so und auch noch ohne Perl...

attr List:
Attributes:
   IODev      sonosmqtt
   alias      Küche
   devStateIcon 0:10px-kreis-rot
1:10px-kreis-gelb
2:10px-kreis-gruen
(0|1).(STOPPED|PAUSED_PLAYBACK):rc_BLANK
2.(STOPPED|PAUSED_PLAYBACK):rc_PLAY@green:play
2.(pause|stop):rc_STOP@red:play
2.PLAYING:rc_STOP@red:stop
2.(TRANSITIONING|play):rc_PLAY@yellow:stop
2.mute:audio_volume_mute@yellow:stop
2.volume:audio_volume_mid@yellow:stop
2.volumeDown:audio_volume_low@yellow:stop
2.volumeUp:audio_volume_high@yellow:stop
2.next:rc_NEXT@yellow:stop
2.previous:rc_PREVIOUS@yellow:stop
(STOPPED|PAUSED_PLAYBACK).(false|previous|next|volumeDown|volumeUp|[0-9]+|CURRENT.*|NEXT.*|PAUSED_PLAYBACK):rc_BLANK
\b(?!(STOPPED|PAUSED_PLAYBACK)\b)\w+.previous:rc_PREVIOUS:previous
\b(?!(STOPPED|PAUSED_PLAYBACK)\b)\w+.next:rc_NEXT:next
\b(?!(STOPPED|PAUSED_PLAYBACK)\b)\w+.volumeDown:rc_VOLDOWN:volumeDown
\b(?!(STOPPED|PAUSED_PLAYBACK)\b)\w+.volumeUp:rc_VOLUP:volumeUp
\b(?!(STOPPED|PAUSED_PLAYBACK)\b)\w+.false:rc_VOLUP:mute+true
\b(?!(STOPPED|PAUSED_PLAYBACK)\b)\w+.true:rc_MUTE:mute+false
   icon       audio_volume_low
   jsonMap    volume_Master:volume mute_Master:mute transportState:state
   model      sonos2mqtt_speaker
   readingList sonos/status/küche/avtransport:.* { json2nameValue($EVENT,'AV_',$JSONMAP) }
  sonos/status/küche/renderingcontrol:.* { json2nameValue($EVENT,'REND_',$JSONMAP) }
  sonos/RINCON_7828CAF4289001400:.* { json2nameValue($EVENT,'',$JSONMAP) }
  sonos/connected:.* bridgeConnected
sonos/RINCON_7828CAF4289001400/error:.* { json2nameValue($EVENT) }
   room       Küche,MQTT2_DEVICE
   setList    stop:noArg sonos/RINCON_7828CAF4289001400/control { "command": "stop" }
  play:noArg sonos/RINCON_7828CAF4289001400/control { "command": "play" }
  pause:noArg sonos/RINCON_7828CAF4289001400/control { "command": "pause" }
  toggle:noArg sonos/RINCON_7828CAF4289001400/control { "command": "toggle" }
  volumeUp:noArg sonos/RINCON_7828CAF4289001400/control { "command": "volumeup" }
  volumeDown:noArg sonos/RINCON_7828CAF4289001400/control { "command": "volumedown" }
  switchToQueue:noArg sonos/RINCON_7828CAF4289001400/control { "command": "switchtoqueue" }
  switchToTv:noArg sonos/RINCON_7828CAF4289001400/control { "command": "switchtotv" }
  switchToLine:noArg sonos/RINCON_7828CAF4289001400/control { "command": "switchtoline" }
  volume:slider,0,1,100 sonos/RINCON_7828CAF4289001400/control { "command": "volume", "input": $EVTPART1 }
  mute:iconSwitch,false,rc_MUTE,true,rc_VOLUP { my $value = $EVTPART1 eq "true" ? "mute" : "unmute";; qq(sonos/RINCON_7828CAF4289001400/control { "command": "$value" } ) }
  next:noArg sonos/RINCON_7828CAF4289001400/control { "command": "next" }
  previous:noArg sonos/RINCON_7828CAF4289001400/control { "command": "previous" }
  x_raw_payload:textField { my $payload = $EVENT;$payload =~ s/$EVTPART0 //g; qq(sonos/RINCON_7828CAF4289001400/control $payload)}
  joinGroup:textField sonos/RINCON_7828CAF4289001400/control { "command": "joingroup",  "input": "$EVTPART1"}
  leaveGroup:noArg { my $value = ReadingsVal("RINCON_7828CAF4289001400","groupName","all"); qq(sonos/RINCON_7828CAF4289001400/control { "command": "leavegroup",  "input": "$value" } ) }
  setAVTUri:textField sonos/RINCON_7828CAF4289001400/control { "command": "setavtransporturi",  "input": "$EVTPART1"}
  notify:textField sonos/RINCON_7828CAF4289001400/control { "command":"notify","input":{"trackUri":"$EVTPART2","onlyWhenPlaying":false,"timeout":10,"volume":$EVTPART1,"delayMs":700}}
   stateFormat [$name:bridgeConnected]
[$name:bridgeConnected].[$name:state]
[$name:state].previous
[$name:state].next
[$name:state].volumeDown
[$name:state].volumeUp
   
[$name:state].[$name:mute]
<br>
[$name:state] CURRENT: [$name:AV_CurrentTrackMetaData_Artist] - [$name:AV_CurrentTrackMetaData_Title] - ([$name:currentTrack_Duration])
<br>
[$name:state] NEXT: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[$name:AV_NextTrackMetaData_Artist] - [$name:AV_NextTrackMetaData_Title] - ([$name:nextTrack_Duration])


Kürze Erklärung:
roter / gelber Punkt: Das Design habe ich untereinander komplett in Abhängigkeiten gesetzt. Wenn die Bride offline ist oder aber keine Geräte gefunden hat, gibt es auch keinen Play Button.
grüner Punkt: Bridge ist online und hat Geräte gefunden. Play Button erscheint.
Den Rest kennt ihr ja schon.... Anbei auch mal ein Bild.
Wenn die Bridge online ist und Geräte gefunden hat

Beta-User

Werd's mal im wesentlichen so einchecken.

Für mich noch offene Fragen:
- Geben wir den Geschwistern mit und ohne Cover-devStateIcon unterschiedliche Namen und bieten beides an?
- Was ist mit "input"?
Das ist doch eigentlich eine Auswahl von einem Element aus vielen? Dann sollte das mMn. in einen Setter mit etwas Perl, um den richtigen Command draus zu machen. Damit das nicht wieder wegen "Chinesisch" versandet, ungetestet in etwa:
input:Queue,TV,Line_In { my $value = $EVTPART1 eq "Queue" ? "queue" : $EVTPART1 eq "TV" ? "tv" : "line";; qq(sonos/RINCON_7828CAF4289001400/control { "command": "switchto$value" } ) }
Das könnte man dann in webCmd verarbeiten und entsprechende cmdIcon setzen?
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

87insane

Jetzt weiß ich wieder warum ich setStateList nie genutzt habe....

Hatte in dem Template mit dem Design einen Fehler gefunden. Es ist so, dass wenn der Player nichts spielt und man am Slider für Vol spielt, die Symbole kurz eingeblendet werden.
Nun dachte ich mir.. Beta-User wird schon wissen warum. Also setStateList genommen und "play pause stop next" rein gesteckt.
Das verhalten ist dann aber doof... zum testen next drin und previous nicht.

Nun ist es so das ich im erstem Symbol immer mitgeben will was geklickt wurde. Geht aber mit setStateList nicht, da diese den ganzen state überschreibt und dann ist stateFormat quasi unnütz. Somit wird dann alles ausgeblendet und nur noch das geklickte Symbol angezeigt. Wenn ich aber mehrstufige devSatetIcon nutzen will...wie? Was mache ich falsch?
Wenn ich auf next klicke,was mit in setStateList steht, bekomme ich es hin das dieses Symbol in gelb dargestellt wird aber alle anderen sind in dem Moment weg. Wenn ich z.B. previous klicke, was nicht in setStateList steht, bekomme ich nun nix mehr. Also wird das gelbe Symbol am Anfang nicht gezeigt aber er macht den Track weiter. So gesehen nicht schlimm. Aber dann behalte ich aus Design Gründen lieber den Bug und ohne setStateList.

Hoffe man versteht was ich meine.....
Bitte noch nicht einchecken! Will das Ding erst komplett haben.
Input kann ich nicht checken. Das kann nur Otto123. Ich habe nur Sonos Play 1 und Sonos Play One. Die können das nicht.

Beta-User

Ähm, also:
- next war nicht für setStateList vorgeschlagen; wenn man was reinnimmt (was ich für next nach wie vor nicht sehe), sollte man es "paarig" machen.
- Geschrieben wird das Reading "state" bzw. nach setzen des Attributs eben teilweise nicht. stateFormat greift potentiell auf alle Readings zu nach jedem Event. Es ist also eher eine Frage des Codes, und es ist mAn. logisch, dass der komplexer werden muß, wenn mehr Elemente als nur "state" im Spiel sind.
Das muß man nicht mögen, und vermutlich geht es nur mit "etwas mehr Perl"; das ist aber auch kein Beinbruch, nur eben teilweise für die user nicht mehr so gut nachvollzieh- und anpassbar. Da es hier aber "sowieso" tricky ist, werden das die wenigstens auch nur in Erwägung ziehen...

Was das input-Thema angeht, deutet das darauf hin, dass wir mehrere attrTemplate haben sollten, weil setter, die nichts bewirken suboptimal sind.
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

87insane

#268
Zitatnext war nicht für setStateList vorgeschlagen; wenn man was reinnimmt (was ich für next nach wie vor nicht sehe), sollte man es "paarig" machen.
War zum testen und verstehen. Deswegen previous auch nicht.

Ich sehe setStateList als Unterstützer für "nicht Perl" Code. Das macht auch hier und da Sinn. Aber zuerst hatte ich in PERL angefangen, sollte nicht... Jetzt drehe ich das alles um und versuche was schönes drauß zu machen, geht aber nicht komplett und man munkelt über PERL.
Klar geht alles irgendwie. Aber die setter sollten doch auch Sinn machen?!

Wenn ich setStateList nutze und es gibt mir am Ende ein relatives Ergebnis zu anderen Ereignissen, ist das doch nicht konsistent! Entweder überschreibe ich alles oder inkrementell oder oder oder... Mich macht das gerade eher traurig, dass man immer wieder bei sowas hängen bleibt, weil einfach nichts Standard ist.
Ich würde jetzt, wo ich mich eh über dieses attr aufrege, gerne mal die Inspiration dazu hören.
Was ich verstanden habe ist warum volume nicht dahin gehört. Wenn ich aber über dieses attr "zusatz"-Möglichkeiten bekommen soll, warum nimmt es mir auch welche? Ich glaube, eigentlich sollte setStateList in zwei Varianten aufgeteilt werden. Die eine so wie jetzt, die andere, das sie eben nicht alles überschreibt.

Wenn du Zeit und Lust hast, lass uns das mal durchgehen. Es ist für diesen Zweck teilweise gut aber auch eben kontra. Ich kann Dir / Euch auch einen Player geben mit setStateList und ohne Veränderung des ersten Icons. Aber das finde ich eben ka***.




Anbei noch eben das wie Beta-User es vermutlich haben und auch machen würde... Soll nicht negativ oder so gemeint sein aber ich bin nach wie vor über setStateList in der Form negativ begeistert und kann mich nicht so wirklich freuen. Die List anbei macht leider nicht die Symbole am Anfang im ersten Icon sondern einfach stupide was der Player machen soll. Das entspricht aber so ziemlich den standard Templates. Was geblieben ist, ist das Ausblenden und Einblenden von Icons die nicht notwendig sind.

Mein Problem ist:
Entweder lebe ich damit, das man ohne setStateList das erste icon als Feedback nutzen kann aber wenn der Player offline ist oder nicht läuft und man spielt am (webcmd) Slider für VOL, schreibt dieser auch volume in state und somit werden kurzzeitig die Symbole alle eingeblendet. Wenn die Bridge aber zudem noch offline ist oder es keinen Player gibt (Zustand 0 oder 1), gibt es auch kein Feedback und alle Symbole bleiben eingeblendet. Das ist nicht sooo mega tragisch aber in meinen Augen sehr unschön, wenn man das nicht im Kopf hat.
Oder ich mache es so wie jetzt gleich angefügt und ich habe das Problem mit den Symbolen nicht mehr. Dafür aber eben meinen heiß geliebten Feedback Button verloren. Damit verschwindet natürlich einiges aus devStateicon und es ist nicht mehr so "komplex" aber es geht auch vieles verloren was in FHEM sicher gern mal gesehen würde... :)
Zumindest habe ich mit der Übung gelernt, wie genau setStateList aktuell läuft. Warum du es so gerne nutzt, bleibt für mich noch immer ein offenes Geheimnis. Denn es hilft ein wenig was zu umgehen und ggf. auch Fehler zu finden. Aber es sollte dann noch ein setstateList geben... Denke das ist die Bessere Übersetzung, für den Versuch oben.

Genug gejammert...

attrList:
Attributes:
   IODev      sonosmqtt
   alias      Küche
   devStateIcon 0:10px-kreis-rot
1:10px-kreis-gelb
2:10px-kreis-gruen
(0|1).(STOPPED|PAUSED_PLAYBACK):rc_BLANK
2.(STOPPED|PAUSED_PLAYBACK):rc_PLAY@green:play
2.(TRANSITIONING|play):rc_PLAY@yellow
(2.set_play|set_play):rc_PLAY@yellow
(2.set_stop|set_stop):rc_STOP@yellow
2.(pause|stop):rc_STOP@red:play
2.PLAYING:rc_STOP@red:stop
(STOPPED|PAUSED_PLAYBACK|set_stop).(false|previous|next|volumeDown|volumeUp|CURRENT.*|NEXT.*|PAUSED_PLAYBACK):rc_BLANK
\b(?!(STOPPED|PAUSED_PLAYBACK)\b)\w+.previous:rc_PREVIOUS:previous
\b(?!(STOPPED|PAUSED_PLAYBACK)\b)\w+.next:rc_NEXT:next
\b(?!(STOPPED|PAUSED_PLAYBACK)\b)\w+.volumeDown:rc_VOLDOWN:volumeDown
\b(?!(STOPPED|PAUSED_PLAYBACK)\b)\w+.volumeUp:rc_VOLUP:volumeUp
\b(?!(STOPPED|PAUSED_PLAYBACK)\b)\w+.false:rc_VOLUP:mute+true
\b(?!(STOPPED|PAUSED_PLAYBACK)\b)\w+.true:rc_MUTE:mute+false
\b(?!(STOPPED|PAUSED_PLAYBACK)\b)\w+.set.false:rc_VOLUP:mute+true
\b(?!(STOPPED|PAUSED_PLAYBACK)\b)\w+.set.true:rc_MUTE:mute+false
   icon       audio_volume_low
   jsonMap    volume_Master:volume mute_Master:mute transportState:state
   model      sonos2mqtt_speaker
   readingList sonos/status/küche/avtransport:.* { json2nameValue($EVENT,'AV_',$JSONMAP) }
  sonos/status/küche/renderingcontrol:.* { json2nameValue($EVENT,'REND_',$JSONMAP) }
  sonos/RINCON_7828CAF4289001400:.* { json2nameValue($EVENT,'',$JSONMAP) }
  sonos/connected:.* bridgeConnected
sonos/RINCON_7828CAF4289001400/error:.* { json2nameValue($EVENT) }
   room       Küche,MQTT2_DEVICE
   setList    stop:noArg sonos/RINCON_7828CAF4289001400/control { "command": "stop" }
  play:noArg sonos/RINCON_7828CAF4289001400/control { "command": "play" }
  pause:noArg sonos/RINCON_7828CAF4289001400/control { "command": "pause" }
  toggle:noArg sonos/RINCON_7828CAF4289001400/control { "command": "toggle" }
  volumeUp:noArg sonos/RINCON_7828CAF4289001400/control { "command": "volumeup" }
  volumeDown:noArg sonos/RINCON_7828CAF4289001400/control { "command": "volumedown" }
  switchToQueue:noArg sonos/RINCON_7828CAF4289001400/control { "command": "switchtoqueue" }
  switchToTv:noArg sonos/RINCON_7828CAF4289001400/control { "command": "switchtotv" }
  switchToLine:noArg sonos/RINCON_7828CAF4289001400/control { "command": "switchtoline" }
  volume:slider,0,1,100 sonos/RINCON_7828CAF4289001400/control { "command": "volume", "input": $EVTPART1 }
  mute:iconSwitch,false,rc_MUTE,true,rc_VOLUP { my $value = $EVTPART1 eq "true" ? "mute" : "unmute";; qq(sonos/RINCON_7828CAF4289001400/control { "command": "$value" } ) }
  next:noArg sonos/RINCON_7828CAF4289001400/control { "command": "next" }
  previous:noArg sonos/RINCON_7828CAF4289001400/control { "command": "previous" }
  x_raw_payload:textField { my $payload = $EVENT;$payload =~ s/$EVTPART0 //g; qq(sonos/RINCON_7828CAF4289001400/control $payload)}
  joinGroup:textField sonos/RINCON_7828CAF4289001400/control { "command": "joingroup",  "input": "$EVTPART1"}
  leaveGroup:noArg { my $value = ReadingsVal("RINCON_7828CAF4289001400","groupName","all"); qq(sonos/RINCON_7828CAF4289001400/control { "command": "leavegroup",  "input": "$value" } ) }
  setAVTUri:textField sonos/RINCON_7828CAF4289001400/control { "command": "setavtransporturi",  "input": "$EVTPART1"}
  notify:textField sonos/RINCON_7828CAF4289001400/control { "command":"notify","input":{"trackUri":"$EVTPART2","onlyWhenPlaying":false,"timeout":10,"volume":$EVTPART1,"delayMs":700}}
   setStateList play pause stop
   stateFormat [$name:bridgeConnected]
[$name:bridgeConnected].[$name:state]
[$name:state].previous
[$name:state].next
[$name:state].volumeDown
[$name:state].volumeUp
&nbsp;&nbsp;&nbsp;
[$name:state].[$name:mute]
<br>
[$name:state] CURRENT: [$name:AV_CurrentTrackMetaData_Artist] - [$name:AV_CurrentTrackMetaData_Title] - ([$name:currentTrack_Duration])
<br>
[$name:state] NEXT: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[$name:AV_NextTrackMetaData_Artist] - [$name:AV_NextTrackMetaData_Title] - ([$name:nextTrack_Duration])


(Ach ja.. Ist mit S1 und S2 getestet... Deswegen auch verschiedene STOP Infos zb.)

Beta-User

Hmmm, also nur erst mal kurz:

Sinn und Zweck von setStateList ist mAn., bei Devices, die viele "Nebenreadings" haben, den "Hauptschalter" (=>state) und den "Rest" sauber auseinanderzuhalten.

Das ist eigentlich kein debugging-feature, sondern hat v.a. auch damit zu tun, dass ein "gutes" MQTT-Device auf eine "kleine" Anweisung auch nur eine "kleine" Rückmeldung geben sollte. Also für volume eine volume-Rückmeldung geben. Und spätestens dann steht "Unsinn" in "state", wenn das Senden state verändert, aber die Rückmeldung nur volume. Man sieht das hier scheinbar nur deswegen nicht, weil der Dienst immer eine "große" Rückmeldung gibt, die alle Infos enthält.
Das ist imo ein Designfehler, unter dem auch die Shellys leiden, und den wir Tasmota nur mühsam abgewöhnt haben. (Meine Meinung, Basta... Und bei Tasmota ist der "Vorwurf"  auch nicht ganz so pauschal gerechtfertigt...)

Daher versuche ich hier im FHEM-Kontext, IMMER setStateList zu verwenden, wenn es "Hauptschalter" und "Nebenreadings" gibt. Leider ist es mir in Teilen noch raus, aber grade bei Devices mit vielen Readings und settern ist das mMn. besonders wichtig.

Ergo das sollte mMn. der Standard sein, und genau deswegen, weil dieses "kleine" Detail das Gesamtdesign wesentlich beeinflußt, stelle ich die Frage auch hier immer wieder, WAS da rein soll. OB steht m.E. nicht wirklich zur Debatte bzw. eben nur gegen meinen hiermit nochmals erklärten Wunsch.

(Ich kann mich leider grade nicht so intensiv eindenken, dass ich zur Lösung des Problems mit der selektiven Anzeige der Icons was sagen könnte; ggf. leben wir halt hier mit der Lösung ohne setStateList oder nehmen "etwas Perl" (in devStateIcon?) - das ist auch nicht per se verwerflich, auch wenn es schön wäre, ein paar mehr multiline-stateFormat-Lösungen präsentieren zu können).
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