eigenartiges icon-problem

[pula]

Hi,

ich habe hier ein eigenartiges problem, dem ich irgendwie nicht auf die spur komme.
habe zwei (meiner meinung nach fast identische) devices:

Code Auswählen Erweitern

Internals:
   FUUID      5c675cbb-f33f-b796-6d2c-1d50f3c979d313ed
   IODev      mqtt
   NAME       keller_schreibtisch
   NR         628
   STATE      on
   TYPE       MQTT_DEVICE
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1572448923.74745
           VALUE      1
   READINGS:
     2019-10-30 16:22:03   Power           ON
     2019-10-30 16:22:03   state           1
     2019-10-30 18:04:18   transmission-state subscription acknowledged
   message_ids:
   publishSets:
     :
       topic      keller_schreibtisch/cmnd/POWER
       values:
         ON
         OFF
   sets:
     OFF       
     ON         
   subscribe:
     keller_schreibtisch/POWER
   subscribeExpr:
     ^keller_schreibtisch\/POWER$
   subscribeQos:
     keller_schreibtisch/POWER 0
   subscribeReadings:
     keller_schreibtisch/POWER:
       cmd       
       name       Power
Attributes:
   IODev      mqtt
   alexaName  Keller Schreibtisch
   devStateIcon state:ON:FS20.on state:*:FS20.off
   eventMap   1:on 0:off
   publishSet ON OFF keller_schreibtisch/cmnd/POWER
   room       Keller,MQTT
   stateFormat state
   subscribeReading_Power keller_schreibtisch/POWER
   webCmd     ON:OFF

und

Code Auswählen Erweitern

Internals:
   FUUID      5d7cf866-f33f-b796-4802-1e925d88adc8e6ef
   IODev      mqtt
   NAME       uhura_strom
   NR         685
   STATE      ON
   TYPE       MQTT_DEVICE
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1572459305.3307
           VALUE      ON
   READINGS:
     2019-10-30 19:15:05   Power           ON
     2019-10-30 19:15:05   state           ON
     2019-10-30 19:15:05   transmission-state incoming publish received
   message_ids:
   publishSets:
     :
       topic      uhura_strom/cmnd/POWER
       values:
         ON
         OFF
   sets:
     OFF       
     ON         
   subscribe:
     uhura_strom/POWER
   subscribeExpr:
     ^uhura_strom\/POWER$
   subscribeQos:
     uhura_strom/POWER 0
   subscribeReadings:
     uhura_strom/POWER:
       cmd       
       name       Power
Attributes:
   IODev      mqtt
   alexaName  uhura strom
   devStateIcon state:ON:FS20.on state:*:FS20.off
   eventMap   1:on 0:off
   publishSet ON OFF uhura_strom/cmnd/POWER
   room       Keller,MQTT
   stateFormat state
   subscribeReading_Power uhura_strom/POWER
   webCmd     ON:OFF

trotzdem ist bei dem ersten device das icon bei on gelb und beim zweiten weiss (sollte der übersichtlichkeit halber auch gelb sein).
kennt jemand das problem?
was übersehe ich?
danke und cheers,
Pula

[rudolfkoenig]

Hat vmtl. mit on vs. ON zu tun.
Ich war der Ansicht, dass FHEMWEB on/ON und off/OFF inzwischen gleich behandelt, scheint aber nicht der Fall zu sein.

[pula]

interessant - sind eigentlich beides tasmota-devices mit gleicher versions-nummer?!

[Beta-User]

Na ja, da spielen noch ein paar andere Sachen mit rein...

"stateFormat state" macht nicht soo den Sinn (das ist default), und auch der devStateIcon-Code funktioniert mit dem "state"-"Präfix" wohl anders, als du das denkst ...

Jedenfalls hat der eine im Reading "state" grade "1" stehen, der andere "ON". Will wohl heißen: der "1"-er hat den Befehl nicht erhalten oder die Auswertung der Rückmeldung ist anders. Ist aber MQTT_DEVICE, bitte selbst nachsehen, wie da die jeweiligen Einstellungen sind, daß Sende- und Empfangsinfo zueinander passen. Und dann kann man auf dem ESP auch noch manches einstellen, vielleicht ist auch da was anders...

[pula]

ist ja alles klar - was mich aber trotzdem wundert ist, dass das zwei "nackte" tasmota devices mit der gleichen version sind, aber trotzdem unterschiedlich agieren. schräg....

[Beta-User]

...war da vorher was drauf? Die settings auf dem ESP gehen afaik nicht verloren...

Und nochmal: Der eine scheint den Befehl "on" nicht bestätigt zu haben, vermute Netzwerkstress.

[pula]

naja - das waren zwei nackte china-sonoffs gleichen typs....
hmm... kann verstehen, was du meinst.
aber das verhalten ist IMMER so.... oder verstehe ich da was falsch?

[Beta-User]

Weiß nicht genau, was du mit "immer so" meinst, ich habe nur grob über die lists gesehen, aber nicht 1:1 alle Einstellungen verglichen.

Wenn das (bis auf die Topic-Angaben) identisch ist, sollte das Verhalten identisch sein. Da der eine aber auf ON steht, der andere auf "1" (heißt wohl: "mach an", aber ohne Rückmeldung, dass geschaltet wurde), ist vermutlich das anders, dass der eine eben entweder den Befehl nicht erhalten hat oder der Server dessen Antwort nicht.

[pula]

mit "immer so" habe ich gemeint, daß das verhalten zu jederzeit so war - wegen deiner bemerkung wegen netzwerk-stress.
es hat sich aber jetzt eh herausgestellt, daß ich ein voll-honk bin (kommt davon, wenn man zu viele dinge gleichzeitig macht) - und beide beispiele die weisse lampe als icon gezeigt haben.
ich hatte nämlich das incoming topic für den state falsch subscribed
habe jetzt ein subscribeReading auf das richtige topic (in meinem fall zb keller_schreibtisch/RESULT) gemacht.
dann erschien wie von zauberhand ein reading "Power" - und schon gibts auch die richtigen icons.
DANKE auf jeden fall - mit deinen (von mir zuerst nicht beachteten) hinweisen auf die fehlende antwort hast du mich in richtung lösung gelenkt!!!

[Beta-User]

  you're welcome!

Btw.: diese Art von Stress hättest du dir mit MQTT2_DEVICE+attrTemplate übrigens ziemlich sicher sparen können, das "kennt" den Rückweg bzw. ordnet (v.a. mit MQTT2_SERVER) eingehende Infos (hier die Rückmeldung) auch dem richtigen Device zu.

[pula]

ich wollte mir das MQTT2 eh schon länger mal ansehen, bisher waren aber immer andere dinge wichtiger...
zu basteln gibts ja immer mehr als genug
aber vielleicht nehme ich das zum anlass, um mich mal einzuarbeiten...
DANKE auf jeden fall!

[Beta-User]

"Einarbeiten" kann man da kaum sagen .

Einfach einen MQTT2_SERVER definieren (anderer Port, global) und dann mal _einen_ Tasmota mit anderem Port versehen und staunen, passendes attrTemplate drüberlegen, fertig...

[pula]

was mich immer davon abgehalten hat, war die tatsache dass ich ja einen laufenden mosquitto habe und irgendwie das gefühl habe, damit flexibler zu sein...

[Beta-User]

Ich hatte auch mal eine mosquitto-Installation und muß zugeben, dass ich vermutlich auch nicht so schnell und bereitwillig davon verabschiedet hätte, wenn mich das nicht wg. meiner (besch...) MiLight-Geräte interessiert hätte; das war unter MQTT-"alt" ein Riesen-Mist (wg. der speziellen JSON-Behandlung, die man da braucht), und mit Rudi's Lösung (und super support!) war's dann super-easy...

Und wegen der paar Geräte, die ich habe/hatte, "brauche" ich schlicht keinen weiteren externen Dienst, das bißchen macht Rudi's Lösung locker nebenbei.

Man kann ja auch weiter den mosquitto nutzen, was m.E. aber nur dann Sinn macht, wenn man größere Teile auch außerhalb FHEM benötigt, und mit MQTT2_CLIENT hat man auch die Option, den mosquitto weiter laufen zu lassen. Das ist nur nicht ganz so einfach, daher der Vorschlag, da schlicht mal mit einem Gerät+anderem Port "reinzuschnuppern".
Der Wechsel von SERVER zu CLIENT ist dann auch kein Hexenwerk, sollte der mosquitto am Ende (wegen der Flexibilität oder warum auch immer) weiter im Einsatz bleiben.

[pula]

hm. ich denke, ich werde mir das nochmal überlegen....
da ich aber auch einige selbstgebastelte arduinos und esps im einsatz habe, die per mqtt kommunizieren, würde ich auf jeden fall mosquitto deaktivieren und den MQTT2-Server auf dem gleichen port laufen lassen (hab damals glücklicherweise den mosquitto auf der fhem-maschine installiert )
hab keine lust, alle arduinos und esps neu zu flashen 

[Beta-User]

Hmmm, vermutlich ist das kein größeres Problem, ich würde dann aber anders vorgehen:

Erst mal "familiarizing" mit MQTT2_DEVICE (über einige wenige Test-Devices@MQTT2_SERVER).

Dann (optimalerweise auf einem Testsystem ) Anlage von MQTT2_CLIENT, hörend auf den Mosquitto. Wenn du (auf diesem (Test-) System) keine MQTT_GENERAL_BRIDGE im Einsatz hast: autocreate "simple" einschalten, das "General_Bridge"-template auf das erste Device anwenden; das sollte dann alle eingehenden Messages sortieren; da ggf. die bridgeRegexp anpassen/ergänzen.
(Beim Schreiben eingefallen: Du kannst auch das bestehende MQTT-IO (TYPE=MQTT) auf den MQTT2_SERVER hören lassen, sollte auch gehen, und der MQTT2_SERVER sollte alle eingehenden Messages gleich passen sortieren. Ist evtl. sogar einfacher...)

Bevor du richtig umstellst, solltest du jedenfalls erst mal alle Devices auch als MQTT2_DEVICE's in deinem FHEM haben (kann aber einen Reconnect auf den Mosquitto oder dessen Neustart erfordern, damit neue messages kommen bzw. alles nochmal gesendet wird). Die kannst du dann "step by step" nehmen, um die vorhandenen zu ersetzen.

Den radikalen Wechsel von MQTT_DEVICE nach MQTT2_DEVICE kannst du zwar auch machen, aber da ist das Risiko, dass Eventhandler anzupassen sind usw.. Z.B. stellen die Tasmota-templates auch Kleinschreibung für on/off (Senden wie Empfangen) ein, das sollte man dann entsprechend vorab berücksichtigen, sonst wird's evtl. unübersichtlich, wenn du da je übergangsweise auch rückwärtskompatibel sein willst/mußt.

Es gibt auch einen längeren Thread zu den ganzen Umzugsfragen im MQTT-Bereich, vielleicht macht es Sinn, wenn du den erst mal grob durchsiehst?

[pula]

Hmm... danke für die sehr ausführliche und hilfreiche Antwort (die ich noch nicht voll verstehe).
Momentan hab ich noch etliche andere, dringendere Dinge auf dem Tisch (zb neu-Implementierung meines doorpi, weil mir die alte abgeraucht ist - und es ist peinlich, wenn Besuch kommt und die Glocke nicht geht gg).

[Beta-User]

Dann mal viel Spaß bei den wichtigen Dingen .

Der "Umzugs-Thread" ist übrigens der hier: https://forum.fhem.de/index.php/topic,103762.msg975021.html#msg975021

[pula]

Danke!
Und danke für den hilfreichen link!