ich gebe ja zu, dass ich mit den Zusammenhängen readingList - userReading - devStateIcon etwas überfordert zu sein scheine.....
ich habe es jetzt endlich geschafft das die Anzeige in FHEM endlich den richtigen Status anzeigt (sowohl wenn über FHEM oder über die Steckdose selbst geschalten wird), aber jetzt geht die gwünschte devStateIcon nicht mehr, sondern es wir eine Glühlampe angezeigt......
Wie bekomme ich wieder das gewünschte state-Icon her? Es geht sobald ich "userReading state" entferne, dann geht aber die Anzeige in FHEM (bei manuell geschaltener Steckdose) nicht mehr.....
define mqtt_Dose4 MQTT2_DEVICE DVES_7366C5
attr mqtt_Dose4 IODev MQTTbroker
attr mqtt_Dose4 event-on-change-reading .*
attr mqtt_Dose4 icon message_socket
attr mqtt_Dose4 readingList DVES_7366C5:tele/DVES_7366C5/LWT:.* LWT\
DVES_7366C5:cmnd/DVES_7366C5/POWER:.* POWER\
DVES_7366C5:tele/DVES_7366C5/STATE:.* { json2nameValue($EVENT) }\
DVES_7366C5:stat/DVES_7366C5/RESULT:.* { json2nameValue($EVENT, 'RESULT_', $JSONMAP) }\
DVES_7366C5:stat/DVES_7366C5/POWER:.* POWER\
DVES_7366C5:tele/DVES_7366C5/INFO1:.* { json2nameValue($EVENT, 'INFO1_', $JSONMAP) }\
DVES_7366C5:tele/DVES_7366C5/INFO2:.* { json2nameValue($EVENT, 'INFO2_', $JSONMAP) }\
DVES_7366C5:tele/DVES_7366C5/INFO3:.* { json2nameValue($EVENT, 'INFO3_', $JSONMAP) }
attr mqtt_Dose4 room MQTT2_DEVICE
attr mqtt_Dose4 setList on cmnd/DVES_7366C5/POWER on\
off cmnd/DVES_7366C5/POWER off
attr mqtt_Dose4 webCmd on:off
#attr mqtt_Dose4 subscribeReading_state DVES_7366C5:stat/DVES_7366C5/POWER
attr mqtt_Dose4 userReadings state {ReadingsVal($name,"POWER","")}
attr mqtt_Dose4 devStateIcon on:rc_GREEN:off off:rc_RED:on offline:rc_BLUE:off
Mach lieber ein "list" des Devices. Hier sieht man kein Reading.
Ein userReadings "state" zu definieren, finde ich komisch. Geht stateFormat nicht?
Nur so eine Idee ...
Es sieht so aus, dass du 2 verschiedene topics dem reading POWER zugeordnet hast.
MAn sollte das "Ergebnis Topic (stat/...)" in state angezeigt werden.
attr mqtt_Dose4 readingList ...
DVES_7366C5:cmnd/DVES_7366C5/POWER:.* POWERCMND\
...
DVES_7366C5:stat/DVES_7366C5/POWER:.* POWER\
DVES_7366C5:stat/DVES_7366C5/POWER:.* state\
...
Das userreading "state" kannst du dann entfernen.
lg
Gernot
...man könnte hier noch einiges anmerken, aber vorerst sollte der Hinweis auf Klein- und Großschreibung des Readingwerts reichen: "on" ne "ON". Die "Schmalspurlösung" wäre also, devStateIcon z.B. mit dem hier zu erweitern:
ON:rc_GREEN:off
Hallo,
ich habe mein "Gebastel" am device etwas aufgeräumt.
Untenstehend das "list" meines Delock 11826 Devices.... geht soweit alles wie gewünscht, nur: sobald ich direkt am Gerät schalte bekommt das der status im FHEM-device mqqt_Dose4 dies nicht mit!
Interessant ist, dass (siehe das "list" für das Gerät im "on" Zustand - geschalten direkt an der Steckdose!) der state "off" ist...... somit ist es wohl richtiger den POWER als Status zu verwenden, was dann wiederum den State verhackstückt.....??????
Internals:
CFGFN fhem_MQTT.cfg
CID DVES_7366C5
DEF DVES_7366C5
DEVICETOPIC mqtt_Dose4
IODev MQTTbroker
LASTInputDev MQTTbroker
MQTTbroker_MSGCNT 10
MQTTbroker_TIME 2020-07-03 16:09:30
MSGCNT 10
NAME mqtt_Dose4
NR 134
STATE off
TYPE MQTT2_DEVICE
.attraggr:
.attreocr:
.*
.attrminint:
READINGS:
2020-07-03 08:57:05 INFO1_FallbackTopic cmnd/DVES_7366C5_fb/
2020-07-03 08:57:05 INFO1_GroupTopic donoffs
2020-07-03 08:57:05 INFO1_Module Delock 11826
2020-07-03 08:57:05 INFO1_Version 6.5.0(classic)
2020-07-03 08:57:05 INFO2_Hostname DVES_xxxxxxxxxxxx
2020-07-03 08:57:05 INFO2_IPAddress 192.168.178.146
2020-07-03 08:57:05 INFO2_WebServerMode Admin
2020-07-03 08:57:05 INFO3_RestartReason Power on
2020-07-03 16:08:32 LWT Online
2020-07-03 16:06:26 LoadAvg 19
2020-07-03 16:09:30 POWER ON
2020-07-03 16:09:30 RESULT_POWER ON
2020-07-03 16:06:26 Sleep 50
2020-07-03 16:06:26 SleepMode Dynamic
2020-07-03 16:06:26 Time 2020-07-03T16:06:26
2020-07-03 15:02:00 UPTIME_Time 2020-07-03T15:02:00
2020-07-03 15:02:00 UPTIME_Uptime 0T06:05:02
2020-07-03 16:06:26 Uptime 0T07:09:28
2020-07-03 16:06:26 Vcc 3.152
2020-07-03 16:06:26 Wifi_AP 1
2020-07-03 16:06:26 Wifi_BSSId xxxxxxxxxxxxxx
2020-07-03 16:06:26 Wifi_Channel 1
2020-07-03 16:06:26 Wifi_Downtime 0T00:00:06
2020-07-03 16:06:26 Wifi_LinkCount 1
2020-07-03 16:06:26 Wifi_RSSI 66
2020-07-03 16:06:26 Wifi_SSId xxxxxxxxxxx
2020-07-03 16:08:34 state off
Attributes:
DbLogExclude .*
IODev MQTTbroker
devStateIcon on:rc_GREEN:off off:rc_RED:on offline:rc_BLUE:off
event-on-change-reading .*
icon message_socket
readingList DVES_7366C5:tele/DVES_7366C5/LWT:.* LWT
DVES_7366C5:cmnd/DVES_7366C5/POWER:.* POWER
DVES_7366C5:tele/DVES_7366C5/STATE:.* { json2nameValue($EVENT) }
DVES_7366C5:stat/DVES_7366C5/RESULT:.* { json2nameValue($EVENT, 'RESULT_', $JSONMAP) }
DVES_7366C5:stat/DVES_7366C5/POWER:.* POWER
DVES_7366C5:tele/DVES_7366C5/INFO1:.* { json2nameValue($EVENT, 'INFO1_', $JSONMAP) }
DVES_7366C5:tele/DVES_7366C5/INFO2:.* { json2nameValue($EVENT, 'INFO2_', $JSONMAP) }
DVES_7366C5:tele/DVES_7366C5/INFO3:.* { json2nameValue($EVENT, 'INFO3_', $JSONMAP) }
room MQTT2_DEVICE
setList on cmnd/DVES_7366C5/POWER on
off cmnd/DVES_7366C5/POWER off
webCmd on:off
hier nochmal eine Visualisierung der Inkonsistenz......
...ich sehe keine "Inkonsitenz", was da passiert, ist genau das Ergebnis deiner Konfiguration (bzw. jetzt in dem Fall: des Entfernens des userReadings)...
Wie gesagt: es gäbe viel anzumerken, was da nicht so ganz optimal ist, (und das userReading war in der Tat überflüssig, wenn man an einer anderen hier schon genannten Stelle was dreht...) aber evtl. schaust du mal im Wiki nach "Praxisbeispielen zu MQTT2_DEVICE" und versuchst zu verstehen, was es mit dem setter "attrTemplate" auf sich hat, vielleicht erledigt sich die eine oder andere weitere Frage dazu dann ja ;) ...
Danke Beta-User,
ich hatte das "on:rc_GREEN:off " durch "ON:rc_GREEN:off" ersetzt/erweitert, hatte aber keinen Effekt.
Danke für den Hinweis zu den PraxisBeispielen und ja, ich werde versuchen ob ich das "attrTempate" verstehe...
Ich hatte versucht (was wohl zum "nicht ganz optimal" geführt hat) mich an Beispielen zu orientieren und mich mittels "autocreate" voranzubringen, aber naja hat wohl nicht geholfen. Also: ich probiere es nochmal über das Wochenende :-)
VG
Bernd
Hi Bernd,
es schadet nicht, sich da selbst durchzuwursteln, da ist der Lerneffekt am größten ;) .
Das "Problem" bei den Tasmotas ist, dass man da - jedenfalls bei "Nur-FHEM"-Ansteuerung - optimalerweise was in der firmware/den settings auf dem ESP ändert, nämlich die Klein- und Großschreibung. Bei den meisten Beispielen, die man heutzutage dazu findet, werden die attrTemplate im Hintergrund genutzt, die das umkonfigurieren.
Ansonsten kommt eben manches doppelt rein und auf - aus FHEM-Sicht gesprochen - "falschen" Readings. Auch hier ist es nicht ganz trivial zu unterscheiden, was man wie "umbiegen" kann bzw. sollte, dass es an der richtigen bzw. nicht an der falschen Stelle landet.
Wobei auf die Frage, was "richtig" und "falsch" ist, nicht jeder hier dieselbe Ansicht hat (ich empfinde z.B. die jetztige "Ampel"-devStateIcon-Variante in den attrTemplates auch nicht unbedingt als die "beste" Lösung und eventuell macht da ja jemand auch mal eine einfachere Variante, mal sehen...).
Viel Freude jedenfalls beim Durchwursteln ;) .