mqtt2.template: bugs, Fragen, Anregungen

Begonnen von Beta-User, 15 Dezember 2018, 11:44:43

Vorheriges Thema - Nächstes Thema

Beta-User

Diese "doppelten" Geräte kommen daher, dass die tastmoat-templates "autocreate" am MQTT2_DEVICE-Gerät jeweils ausschalten. Kommt dann was neues rein, wird es eben woanders hin zugeordnet. Könnte man m.E. überdenken.

Das betrifft zum einen "stat" - das sollte jetzt in den neuen Tasmota-Templates so sein, dass das in der readingList erscheint (das Thema hatten wir grade) und daher dieser Teil des "Problems" nach einem update (+Anwenden der aktuellen Fassung der templates) nicht mehr in der Form existent ist.

Weiter betrifft es "cmnd". Das kommt dann, wenn man mit einer anderen Software schaltet (MQTTfx, mosquitto_pub etc.). Da uns die Schaltanweisung aber eigentlich gar nicht interessiert, sondern nur das Ergebnis, das wir aber sowieso direkt im Anschluß bekommen, wenn die Anweisung ausgeführt worden ist, wäre es hier eigentlich am besten, diese ganzen Topics auf ein weiteres MQTT2_DEVICE umzuleiten. Das könnte eine Art "Blinddeckel" für alle tasmotas darstellen, wenn man die readingList da so wählt, dass alle "cmnd"-Anweisungen abboniert werden...?
(Oder wir ergänzen die readingList am Hauptkanal jeweils so, dass nichts passiert. Das gefällt mir jetzt spontan am besten).

Für das "Lernen" im Umgang mit jsonMap (und Tasmota) habe ich zwei mit Tuya-Convert "vertasmotate" Maxcio-xy verwendet (https://templates.blakadder.com/maxcio-YX-DE04.html).

Das mit dem Dummy habe ich nicht verstanden und bitte ich ggf. in einen separaten Thread zu verlagern. Auf den ersten Blick ist es "von hinten durch die Brust ins Auge" und der Dummy entweder überflüssig oder er sollte durch einen ReadingsProxy ersetzt werden, das ist extra dafür gemacht und daher in der Regel besser als eine dummy+Eventhandler-Kombination.
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

Zu MQTT Readings und autocreate: So erklärt macht es Sinn! Danke

Zum erlernen von JSON.-/Map: Ja gut.. klar kann ich x Stunden rum klicken und Geräte mal testen. So ne Art mini Verständnis sollte aber davor schon da sein. Würde mich selber nach erlangen des Wissens auch als Doku Schreiber anmelden ;)

Bezüglich der Dummy Geschichte) Hatte eh keine Antwort erwartet. Die einzigen Beispiele die ich zur Heizungssteuerung im Netz fand, bestanden immer aus:
1. Gerät/Aktor/Schalter (tatsächliche Hardware)
2. dummy für die Temperaturen und für den threshold
3. threshold zur Überwachung

Hatte lediglich gedacht, das man aus "Schönheits-Gründen" die unwichtigen Geräte in den Hintergrund stellt und das wichtige Gerät alle Daten beinhaltet. In dem Fall würde ich den Dummy als wichtig bezeichnen. Warum? Weil er die Einstellungen der Temperatur beherbergt und weil er in state alle Infos wiedergeben könnte. So ne Art Übersichtsgerät eben. Naja... anderes Thema und sollte ich mein Problem finden, werde ich das anpassen und hier bzw. in einem eigenen Thread teilen...

Beta-User

[OT]
Zitat von: 87insane am 19 Februar 2020, 10:56:55
1. Gerät/Aktor/Schalter (tatsächliche Hardware)
2. dummy für die Temperaturen und für den threshold
3. threshold zur Überwachung
Was spricht dagegen, das in einer ReadingsGroup zusammenzufassen, statt den dummy mühevoll zu füttern?
(Bitte hier keine Antwort mehr dazu)
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

Otto123

Hi,

- ich nehme ne frische tasmota Dose (Gosund SP1)
- habe noch kein MQTT2 Device
- starte die Dose neu
und bekomme:
defmod MQTT2_DVES_A52F4C MQTT2_DEVICE DVES_A52F4C
attr MQTT2_DVES_A52F4C IODev mqtt2s
attr MQTT2_DVES_A52F4C readingList DVES_A52F4C:tele/tasmota_A52F4C/STATE:.* { json2nameValue($EVENT) }\
DVES_A52F4C:tele/tasmota_A52F4C/SENSOR:.* { json2nameValue($EVENT) }\
DVES_A52F4C:tele/tasmota_A52F4C/LWT:.* LWT\
DVES_A52F4C:cmnd/tasmota_A52F4C/POWER:.* POWER\
DVES_A52F4C:tele/tasmota_A52F4C/INFO1:.* { json2nameValue($EVENT) }\
DVES_A52F4C:tele/tasmota_A52F4C/INFO2:.* { json2nameValue($EVENT) }\
DVES_A52F4C:tele/tasmota_A52F4C/INFO3:.* { json2nameValue($EVENT) }\
DVES_A52F4C:stat/tasmota_A52F4C/RESULT:.* { json2nameValue($EVENT) }\
DVES_A52F4C:stat/tasmota_A52F4C/POWER1:.* POWER1
attr MQTT2_DVES_A52F4C room MQTT2_DEVICE


Dann wende ich tasmota_basic an (oder auch das Nächste state_Power1, das Ergebnis ist gleich)

defmod MQTT2_DVES_A52F4C MQTT2_DEVICE DVES_A52F4C
attr MQTT2_DVES_A52F4C IODev mqtt2s
attr MQTT2_DVES_A52F4C autocreate 0
attr MQTT2_DVES_A52F4C comment NOTE: For on-for-timer SetExtensions are used. You may add on-for-timer option running on the device. The following is limited to 1h max duration, but will not affect future simple "on" commands:<br>on-for-timer {my $duration = $EVTPART1*10;; 'cmnd/cmnd/tasmota_A52F4C/Backlog POWER1 1;; delay '.$duration.';; POWER1 0'}<br>See the "Praxisbeispiele" in the wiki for "pulseTime1" alternative option and it's restrictions.
attr MQTT2_DVES_A52F4C icon hue_filled_outlet
attr MQTT2_DVES_A52F4C jsonMap POWER1:0 POWER2:0 POWER3:0 POWER4:0 Dimmer:0 Channel_0:0 Channel_1:0 Channel_2:0 Channel_3:0 Channel_4:0 HSBColor:0 Color:0
attr MQTT2_DVES_A52F4C model tasmota_basic_state_power1
attr MQTT2_DVES_A52F4C readingList tele/tasmota_A52F4C/LWT:.* LWT\
  tele/tasmota_A52F4C/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/tasmota_A52F4C/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/tasmota_A52F4C/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/tasmota_A52F4C/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/tasmota_A52F4C/POWER1:.* state\
  stat/tasmota_A52F4C/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr MQTT2_DVES_A52F4C room MQTT2_DEVICE
attr MQTT2_DVES_A52F4C setList off:noArg    cmnd/tasmota_A52F4C/POWER1 0\
  on:noArg     cmnd/tasmota_A52F4C/POWER1 1\
  toggle:noArg cmnd/tasmota_A52F4C/POWER1 2\
  setOtaUrl:textField cmnd/tasmota_A52F4C/OtaUrl $EVTPART1\
  upgrade:noArg   cmnd/tasmota_A52F4C/upgrade 1
attr MQTT2_DVES_A52F4C setStateList on off toggle


Jetzt habe ich bloß die durchgestrichene Birne. Da stimmt doch was nicht? wenn ich #180 richtig verstehe, sollte da doch stehen
jsonMap POWER1:state

Wenn ich es so setze ist dann auch alles schick!?
attr MQTT2_DVES_A52F4C jsonMap POWER1:state

Ist der Bug bei mir oder im Template? Kann ich noch was testen?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Ich schaue mir das nochmal an, aber hast du mal geschaltet nach der attrTemplate-Anweisung?
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

Otto123

ja klar. Im state immer nur set_on oder set_off

ich habe null Ahnung was das jsonMap tut und wie das vom Template gedacht war? Ich habe einfach nur probiert (Beitrag #180)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Otto123

Ich habe jetzt mal mit etwas Unverstand (also Lesen Versuch Irrtum) jsonMap so gesetzt:
POWER1:state POWER2:0 POWER3:0 POWER4:0 Dimmer:0 Channel_0:0 Channel_1:0 Channel_2:0 Channel_3:0 Channel_4:0 HSBColor:0 Color:0
Da wäre glaub ich meine Welt auch in Ordnung :)
Symbol bzw. state passt und state wird nicht ständig mit aktualisiert :)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

joelinux

Zitat von: Otto123 am 04 März 2020, 01:11:08
POWER1:state POWER2:0 POWER3:0 POWER4:0 Dimmer:0 Channel_0:0 Channel_1:0 Channel_2:0 Channel_3:0 Channel_4:0 HSBColor:0 Color:0
Da wäre glaub ich meine Welt auch in Ordnung :)
Das möchte ich bestätigen.
Der state wird von set_on oder set_off dann auch nach on oder off gewechselt.

Tasmota  liefert Ergebnisse im STATTOPIC/RESULT json Array und in einer einzelnen STATTOPIC/POWER1 Nachricht.
Kann es sein das die Unterdrückung aus dem jsonmap (die eigentlich nur die Antwort im RESULT Array bearbeiten soll) beide Antworten erfasst? Race Condition?  :o
FHem on RPi2 Buster, Duofern Rollladen, ZWave Rolllade + Steckdosen, ZigBee (Philips, Tradfri), Tasmota (diverse Steckdosen, GU10 und E14 LSC Leds von Action, Sonoff RF Bridge), InterTechno Dimmer Steckdose ITLR-200

Beta-User

Irgendwas ist schräg...

Also: Habe eben eines meiner Tasmota-Testgeräte (eine Maxcio mit farbiger LED-Leuchte als 2. Kanal) angesehen. Das ist geflasht mit "Version 8.1.0 from http://thehackbox.org/tasmota/release/tasmota-DE.bin" und hat folgende Konfiguration in FHEM:

defmod USB_Plug MQTT2_DEVICE DVES_EFFB7F
attr USB_Plug IODev MQTT2_FHEM_Server
attr USB_Plug autocreate 0
attr USB_Plug comment Mains channel for MQTT2_DVES_EFFB7F, see also MQTT2_DVES_EFFB7F_CH2 for rgb LED
attr USB_Plug devStateIcon {my $onl = ReadingsVal($name,"LWT","false") eq "Online"?"10px-kreis-gruen":"10px-kreis-rot";;;; my $light = ReadingsVal($name,"state","off");;;;"<a href=\"http://".ReadingsVal($name,"IPAddress","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a> uptime: ".ReadingsVal($name,"Uptime",undef)}
attr USB_Plug event-on-change-reading .*
attr USB_Plug group Licht
attr USB_Plug icon hue_filled_outlet
attr USB_Plug jsonMap POWER1:0 POWER2:0 POWER3:0 POWER4:0 Dimmer:0 Channel_0:0 Channel_1:0 Channel_2:0 Channel_3:0 Channel_4:0 HSBColor:0 Color:0
attr USB_Plug model tasmota_plug_with_rgbw_split
attr USB_Plug readingList tele/DVES_EFFB7F/LWT:.* LWT\
  tele/DVES_EFFB7F/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/DVES_EFFB7F/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/DVES_EFFB7F/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/DVES_EFFB7F/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  stat/DVES_EFFB7F/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  stat/DVES_EFFB7F/POWER1:.* state
attr USB_Plug room Wohnzimmer
attr USB_Plug setList off:noArg    cmnd/DVES_EFFB7F/POWER1 0\
  on:noArg     cmnd/DVES_EFFB7F/POWER1 1\
  toggle:noArg cmnd/DVES_EFFB7F/POWER1 2
attr USB_Plug setStateList on off toggle
attr USB_Plug webCmd :
.
Über backlog hat die nie was anderes gesehen als das, was schon lange im "basic-attrTemplate" drin ist, und die Einstellung scheint mir in den relevanten Punkten identisch zu dem zu sein, was das aktuelle attrTemplate tut.

Es gibt keine race-Kondition und ich erhalte über den "stat-POWER1"-Zweig Rückmeldung von dem Teil. Die Änderung der jsonMap weg von dem, was Otto vorschlägt hatte genau den Hintergrund, dass ich ständig updates von state via JSON erhalten hatte.

Ok, mein FHEM war nicht ganz tagesaktuell, also habe ich noch ein update gemacht (Stand heute 08:07 Uhr: "nothing to do"): Weiter "normales Schaltverhalten", also kurz das "rote Aufrufezeichen", dann sofort on bzw. off.

Dann habe ich mir die Tasmota-Konsole angesehen. Über "tele" gehen immer alle Zustände raus => mMn. untauglich, da das die Zeitstempel verhaut...
Via "stat" gibt es den Klartext und einen reduzierten JSON, könnte man als nutzen, aber dann würde man tele und stat unterscheiden müssen, also einen Präfix für einen der Zweige verwenden (vermutlich "stat", das wäre der kleinere Eingriff). Aber dann wird das attrTemplate noch komplexer...

Könnt ihr mal checken, welche Tasmota-Version ihr habt bzw. ob das Verhalten in der DE-Version anders ist als bei EN? Und ggf.: Wo kann man am einfachsten rausfinden, welche Einstellungen das Teil hat bzgl. teleperiod etc.? Irgendwo muss der Unterschied ja herkommen...

Bin etwas ratlos...
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

Eins kann ich schon sagen. Das hatte ich aus anderem Grund getestet.

DE und EN sind identisch vom Verhalten. Auch aktuelle 8.1

Gesendet von meinem LM-G810 mit Tapatalk


Otto123

#220
Das ist meine Version:
Tasmota Version 8.1.0(tasmota)
Build-Datum & -Uhrzeit 2019.12.25 12:47:07
Core-/SDK-Version 2_6_1/2.2.2-dev(38a443e)

Also Du hast den
stat/DVES_EFFB7F/POWER1:.* state
und ich den
  tele/tasmota_A52F4C/POWER1:.* state

Wenn ich das so setze ist die Welt auch in Ordnung:
defmod MQTT2_DVES_A52F4C MQTT2_DEVICE DVES_A52F4C
attr MQTT2_DVES_A52F4C IODev mqtt2s
attr MQTT2_DVES_A52F4C autocreate 0
attr MQTT2_DVES_A52F4C comment NOTE: For on-for-timer SetExtensions are used. You may add on-for-timer option running on the device. The following is limited to 1h max duration, but will not affect future simple "on" commands:<br>on-for-timer {my $duration = $EVTPART1*10;; 'cmnd/cmnd/tasmota_A52F4C/Backlog POWER1 1;; delay '.$duration.';; POWER1 0'}<br>See the "Praxisbeispiele" in the wiki for "pulseTime1" alternative option and it's restrictions.
attr MQTT2_DVES_A52F4C icon hue_filled_outlet
attr MQTT2_DVES_A52F4C jsonMap POWER1:0 POWER2:0 POWER3:0 POWER4:0 Dimmer:0 Channel_0:0 Channel_1:0 Channel_2:0 Channel_3:0 Channel_4:0 HSBColor:0 Color:0
attr MQTT2_DVES_A52F4C model tasmota_basic_state_power1
attr MQTT2_DVES_A52F4C readingList tele/tasmota_A52F4C/LWT:.* LWT\
  tele/tasmota_A52F4C/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/tasmota_A52F4C/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/tasmota_A52F4C/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/tasmota_A52F4C/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  stat/tasmota_A52F4C/POWER1:.* state\
  stat/tasmota_A52F4C/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr MQTT2_DVES_A52F4C room MQTT2_DEVICE
attr MQTT2_DVES_A52F4C setList off:noArg    cmnd/tasmota_A52F4C/POWER1 0\
  on:noArg     cmnd/tasmota_A52F4C/POWER1 1\
  toggle:noArg cmnd/tasmota_A52F4C/POWER1 2\
  setOtaUrl:textField cmnd/tasmota_A52F4C/OtaUrl $EVTPART1\
  upgrade:noArg   cmnd/tasmota_A52F4C/upgrade 1
attr MQTT2_DVES_A52F4C setStateList on off toggle


Dein gerät ist mit dem alten Template (Weihnachten) angelegt, im neuen Template (Update gestern) steht das drin
  TELETOPIC/POWER1:.* state\
  STATTOPIC/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }


Edit:
Wenn ich den TELETAPPI gegen STATTOPIC austausche funktioniert es auch.

Wie kann ich FHEM eigentlich sagen, er soll den im Hintergrund korrigierten mqtt2.template nehmen? Gibt es sowas wie reload oder geht nur Neustart? ???
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

TomLee

ZitatWie kann ich FHEM eigentlich sagen, er soll den im Hintergrund korrigierten mqtt2.template nehmen? Gibt es sowas wie reload oder geht nur Neustart? ???

{ AttrTemplate_Initialize() }

Beta-User

Argh, die Diskussion über jsonMap hatte also den Fokus auf das falsche Thema gelenkt...

Update ist im svn, bei der Gelegenheit habe ich dann auch gleich noch
- stat-RESULT dahingehend geändert, dass "nichts" gemacht wird (wenn das bitte jemand testen könnte?)
- bei zigbee2mqtt_hueMotionSensor eine Testimplementierung für Spracherkennung reingenommen. Auch hier wäre es super, wenn das jemand testen würde, ich muß/will das als reine Trockenübung vollziehen (evtl. sind die Readingswerte falsch, dannn bitte erst mit der Wirklichkeit abgleichen und das korrekte mapping hier einstellen!)...




Überhaupt Spracherkennung:
Vielleicht habt ihr das noch nicht gemerkt, aber seit einiger Zeit werden die betreffenden genericDeviceType-Attribute bei einem Teil der Templates (v.a. light/switch-Devices) bereits automatisch gesetzt, sofern jemand eine Spracherkennungslösung definiert hat. Vor ein paar Tagen habe ich das in eine separate file ausgelagert, man kann diese "Sub-Templates" jetzt also (hoffentlich) bei allen Geräten (auch solo) anwenden, die attrTemplate (bzw. SetExtensions) anbieten.
Wenn die obige Testimplementierung reibungslos durchläuft, sollte es kein großes Thema sein, das allgemein auszurollen und auch in die weiteren attrTemplate-files zu übernehmen. Vorschläge nehme ich dann gerne entgegen (würde vermutlich Sinn machen, das in einen separaten Thread im Sprachsteuerungsbereich auszulagern, da das vermutlich ohne größere Anpassung auch für die anderen Maintainer relevant wäre, und so hätte man "alles beeinander")...
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

Otto123

#223
Danke TomLee
Da ich das ja in ein paar Wochen wieder suchen muss :) hier ein "Knopf" der die Templates neu lädt:
defmod Befehle weblink cmdList Restart:AttrTemplateInit:{AttrTemplate_Initialize();;;;"AttrTemplateInit"}
attr Befehle room MQTT2_DEVICE


@Beta-User Kannst Du erklären was Du meinst? Was soll passieren / getestet werden?
Zitat- stat-RESULT dahingehend geändert, dass "nichts" gemacht wird (wenn das bitte jemand testen könnte?)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Eisix

#224
Hallo,

hatte diese Woche auch das Problem das die Templates immer zu dieser durchgestrichenen Birne führten. Vor ca. 10 Tagen war dieses Problem nicht.
Die Attribute

jsonMap
setList
getList

(Server ist der MQTT Name in der Tasmota Konfiguration)

   jsonMap    POWER1:state
   model      tasmota_basic_state_power1
   readingList tele/Server/LWT:.* LWT
  tele/Server/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }
  tele/Server/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }
  tele/Server/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }
  tele/Server/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }
  stat/Server/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
   room       MQTT2_DEVICE
   setList    off:noArg    cmnd/Server/POWER1 0
  on:noArg     cmnd/Server/POWER1 1
  toggle:noArg cmnd/Server/POWER1 2
  setOtaUrl:textField cmnd/Server/OtaUrl $EVTPART1
  upgrade:noArg   cmnd/Server/upgrade 1


Musste ich korrigieren dann ging es wieder.

Gruß
Eisix