Fragen zur MQTT2-Device Template Zuweisung

Begonnen von oehi86, 01 August 2019, 17:35:42

Vorheriges Thema - Nächstes Thema

oehi86

Guten Abend,

ich versuche meinen sonoff-Basic in FHEM einzubinden, FHEM funktioniert so weit auch als "Server" aber der Basic hat ein Problem.
Ich möchte dem Device ein Template zuweisen, weiß aber nicht, was ich dann bei CMNDTOPIC, TELETOPIC, STATTOPIC eintragen muss.

Ich gebe euch gern weitere Infos, damit ihr mir helfen könnt.

Würde mich freuen. Vielen Dank und einen schönen Abend

Beta-User

Wenn du ein list (oder noch besser, einen RAW-Definition-Auszug) lieferst, wird es evtl. klarer (und ich kann nachschauen, warum es ggf. schief geht).

Grundsätzlich gehört da hin, was als Topic-Pfad jeweils konkret paßt (und es sollte automatisch - also ohne Dialogfeld - erkannt werden, wenn eine LWT-Message eingegangen war). Wenn das template "kaputt" ist, sollte ich noch wissen, welches.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

oehi86

wie kann ich die RAW-Daten oder das list ausführen, im set steht nur attrTemplate und dann halt die Auswahl, dieses auszuwählen.
get habe ich gar nicht

Beta-User

Ich gehe davon aus, dass du den angepinnten Beitrag zu "Was beachten vor Fragen?" kennst? Da steht was zu list...

Zu RAW: https://wiki.fhem.de/wiki/Raw_definition

Ich bräuchte das Device, auf das du das template anwenden willst...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

oehi86

#4
defmod MQTT2_LampeSchlafzimmer MQTT2_DEVICE LampeSchlafzimmer
attr MQTT2_LampeSchlafzimmer IODev MQTT2_FHEM_Server
attr MQTT2_LampeSchlafzimmer autocreate 0
attr MQTT2_LampeSchlafzimmer model A_01a_tasmota_basic_state_power1
attr MQTT2_LampeSchlafzimmer readingList TELETOPIC/LWT:.* LWT\
  TELETOPIC/STATE:.* { json2nameValue($EVENT) }\
  TELETOPIC/SENSOR:.* { json2nameValue($EVENT) }\
  TELETOPIC/INFO.:.* { json2nameValue($EVENT) }\
  STATTOPIC/RESULT:.* { json2nameValue($EVENT) }
attr MQTT2_LampeSchlafzimmer room MQTT2_DEVICE
attr MQTT2_LampeSchlafzimmer setStateList on off toggle
attr MQTT2_LampeSchlafzimmer stateFormat POWER1
attr MQTT2_LampeSchlafzimmer webCmd ON:OFF

setstate MQTT2_LampeSchlafzimmer off


Beta-User

Hmmm, kannst du die readingList nochmal löschen und den tasmota zum Neustart überreden?

Ich benötige bitte das RAW nochmal mit der automatisch erstellten readingList vor dem Anwenden des templates (es sollte ein LWT-Reading da sein, sonst klappt das nicht mit der Analyse des Topic-Pfades...).

Und bitte künftig Code-Tags verwenden (der "#"-Button oberhalb der smileys).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

oehi86

Danke schon mal für die Mühen, habe es direkt in Code-Tag geändert, und hier der neue Auszug:

defmod MQTT2_LampeSchlafzimmer MQTT2_DEVICE LampeSchlafzimmer
attr MQTT2_LampeSchlafzimmer IODev MQTT2_FHEM_Server
attr MQTT2_LampeSchlafzimmer readingList LampeSchlafzimmer:tele/LampeSchlafzimmer/LWT:.* LWT\
LampeSchlafzimmer:cmnd/LampeSchlafzimmer/POWER:.* POWER\
LampeSchlafzimmer:tele/LampeSchlafzimmer/INFO1:.* { json2nameValue($EVENT) }\
LampeSchlafzimmer:tele/LampeSchlafzimmer/INFO2:.* { json2nameValue($EVENT) }\
LampeSchlafzimmer:tele/LampeSchlafzimmer/INFO3:.* { json2nameValue($EVENT) }\
LampeSchlafzimmer:stat/LampeSchlafzimmer/RESULT:.* { json2nameValue($EVENT) }\
LampeSchlafzimmer:stat/LampeSchlafzimmer/POWER1:.* POWER1\
LampeSchlafzimmer:tele/LampeSchlafzimmer/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_LampeSchlafzimmer room MQTT2_DEVICE

defmod FileLog_MQTT2_LampeSchlafzimmer FileLog ./log/MQTT2_LampeSchlafzimmer-%Y-%m-%d.log MQTT2_LampeSchlafzimmer
attr FileLog_MQTT2_LampeSchlafzimmer logtype text
attr FileLog_MQTT2_LampeSchlafzimmer room MQTT2_DEVICE

setstate FileLog_MQTT2_LampeSchlafzimmer active
setstate FileLog_MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 linesInTheFile 26

setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 FallbackTopic cmnd/LampeSchlafzimmer_fb/
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 GroupTopic sonoffs
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Heap 15
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 Hostname LampeSchlafzimmer-1307
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 IPAddress 192.168.24.2
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:35 LWT Online
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 LoadAvg 19
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 Module Sonoff Basic
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 POWER
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 POWER1 off
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 RestartReason Software/System restart
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Sleep 50
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 SleepMode Dynamic
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Time 2019-08-02T14:00:43
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Uptime 0T00:00:16
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 Version 6.6.0(release-sonoff)
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 WebServerMode Admin
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Wifi_AP 1
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Wifi_BSSId 7C:FF:4D:7F:3C:F9
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Wifi_Channel 10
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Wifi_Downtime 0T00:00:06
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Wifi_LinkCount 1
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Wifi_RSSI 56
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Wifi_SSId XXXXXX


Beta-User

 :)
Versuch's jetzt nochmal mit dem template. Jedenfalls mit der aktuellen Version aus dem regulären update konnte ich keine Probleme feststellen, und die ist eigentlich seit längerem unverändert.

Kann sein, dass das LWT-Reading bei dem ersten Versuch noch nicht da war. Dann hätte eigentich in die Dialogfelder der entsprechende Input reingehört, statt einfach das vorhandene zu bestätigen (die Dialogfelder fragen Variablen ab, wenn sie sie selbst nicht bestimmen können...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

oehi86

PERFEKT! Ich danke von Herzen :-) vielleicht werde ich mir nun doch ein paar Tasmota zulegen  ;)

Bester Support ever!! Schönes Wochenende

Beta-User

Danke für die nette Rückmeldung.
Zitat von: oehi86 am 02 August 2019, 15:53:52
vielleicht werde ich mir nun doch ein paar Tasmota zulegen  ;)
Das würde ich mir nochmal überlegen... Ich supporte das mit den atttrTemplates für MQTT2_DEVICE zwar, aber das vertreibt nicht meie grundsätzliche Skepsis gegenüber dem "WLAN-Gedöns".

(Ich habe z.B. selbst neulich lieber einige ZWave-Aktoren verbaut statt Shelly oder Tasmota-Zeug, und wenn ich löte, nehme ich typischerweise MySensors (am liebsten @RS485), und keine ESP's.)

Ansonsten: Bitte als [gelöst] markieren... (Siehe angepinnten Thread im Anfängerbereich, wie das geht).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

flummy1978

Auch wenn ich damit vollkommen OT bin und dieser Beitrag bereits als gelöst klingt und ich bei der Suche nach meinem Fehler hier drüber gestolpert bin, habe ich doch eine sehr dringende Frage:

Zitat von: Beta-User am 02 August 2019, 16:08:58
Danke für die nette Rückmeldung.Das würde ich mir nochmal überlegen... Ich supporte das mit den atttrTemplates für MQTT2_DEVICE zwar, aber das vertreibt nicht meie grundsätzliche Skepsis gegenüber dem "WLAN-Gedöns".

Du bist ja nun schon "ein wenig" erfahrener, was die ganze Geschichte angeht.... Woher kommt Deine Skepsis, bzw. warum bist Du dem "Wlan Gedöns" so abgeneigt ?
(Falls zu sehr OT auch sehr gern per PN)

Viele neugierige Grüße
Andreas

Beta-User

...lange Geschichte:

Also:
- Den ersten ESP8266 hatte ich in der Hand, als das framework noch nicht ausgereift war und sämtliche Mängel im Hardwaredesign noch besser sichtbar waren. Ich habe daraus für mich den Schluß gezogen, dass das allg. ein verräterisches Stück Hardware ist, und das Versprechen einer "eierlegenden Wollmilchsau" nicht zu halten. (Das ist besser geworden, aber das Mißtrauen gegen die Hardware ist weiter da...).

- Es ist WLAN. Damit das funktioniert mit der Datenübertragung, braucht man ziemlich viel Infrastruktur, die läuft (AP, Router, Switches...). Es kann Konflikte mit Nachbarn geben (Kanalwahl, Bandbreite) usw. Das ist mit einem USB-Dongle am Server was anderes. Da braucht - von Ausnahmen abgesehen - im Prinzip nur der Server Strom und der entfernte Aktor/Sensor, dann läuft das. Und ich muß nicht x Devices mit neuen Zugangsdaten versehen, wenn ich mal was am WLAN drehe...

- Es gibt zwischenzeitlich auch alle 2-3 Wochen einen neuen Thread mit - in etwa - dieser Fragestellung: "Hilfe, ich erhalte plötzlich keine  Rückmeldung mehr von meinen Sensoren / meine Aktoren lassen sich nicht mehr schalten / was ist hier los...?"
Hintergrund ist in der Regel: es sind zu viele WLAN-Geräte für den vorhandenen Router (FritzBox) vorhanden.

(- für Funk-/Gesundheitsskeptiker: Das WLAN-Gedöns ist meistens "immer auf Sendung" und nicht nur dann, wenn wirklich Information übertragen werden soll. Wer also sowas wichtig findet, hat ein weiteres Argument.)

Ansonsten: Es geht nichts über Kabel ;D . Das ist nur immer zu kurz, wenn man es einmal abgeschnitten hat, aber ansonsten der dauerhafteste und zuverlässigste Weg, Daten zu übertragen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

flummy1978

Hallo Beta,

vielen lieben Dank für die ausführliche Antwort... Wenn es ok ist, würde ich gern drauf eingehen.

- Skepsis gegenüber der Hardware: Kann ich voll und ganz nachvollziehen. Da ich Elektriker bin, hab ich da auch so meine Bedenken gehabt und wenn ich überlege dass Leute da ihre Elektroheizung, Klima und ähnliches drüber laufen lassen, graut es mir. Da finde ich sparsame Kühlschränke oder Spülmaschinen die nur kurzfristig mal mehr als 4-5 A ziehen, schon grenzwertig.

- Eine gute Wlan Struktur ist natürlich unabdingbar, wenn man sowas vorhat. Da ist es in der Tat mir einer FritzBox nicht getan, da muss man schon etwas mehr für tun. (wäre das nicht vielleicht ein wichtiger Hinwes in der Wiki ?) Tatsächlich wird es ja so sein, dass die Leute immer mehr davon dazu nehmen (weil es ja so einfach ist und man eben keine andere Hardware braucht) und (so wie ich) skeptischer dem "normalen" Funk gegenüber sind.

- Natürlich sind die Funkwellen ein sehr sehr wichtiges Thema. Ich weiss das sprengt jetzt hier das Thema, aber wenn das Wlan für Handys und Mobile Geräte an ist, sendet es doch eh permanent. D.h. wenn ich aus Gesundheitsgründen auf Wlan Geräte in der Steuerung verzichten wollte, muss ich auch zwingend auf Wlan generell verzichten  :o

Damit das ganze nochmal onTopic wird:


Ich hatte mal zwei Shellys für kleine Lampen in Betrieb genommen. Dort hat es gut funktioniert, dass ich nur den "Topic" namen genommen habe. Damit habe ich dann die beiden Templates: "A_01z_tasmota_set_lowercase_texts_and_state1" und "A_01z_tasmota_set_power1_state_to_power" zusätzlich dann das entsprechende Produkt ausgewählt.
Damit hatte ich den Vorteil, dass der state Zustand IMMER von POWER1 kommt und alles klein geschrieben ist also on statt ON und off statt OFF.

Jetzt habe ich das heute mal mit einem neuen Teil probiert und komme da richtig ins Schwitzen. Wenn ich ein anderes Device kopiere, die MQTT Adressen anpasse dann funktioniert es perfekt. Nehme ich aber ein nacktes Device und versuche dort die o.g. Einstellungen zu machen, scheitert es an den Angaben CMNDTOPIC, TELETOPIC, STATTOPIC. bzw irgendwas davon übernimmt er dann nicht.

Könntest Du so nett sein und ein Beispiel anhand des "RohDevices" unten geben, was man entsprechend eintragen muss wenn man nach den o.g. Sachen gefragt wird? 

Internals:
   CFGFN     
   CID        Shelly9_SZ_E2059C
   DEF        Shelly9_SZ_E2059C
   DEVICETOPIC MQTT2_Shelly9_SZ_E2059C
   FUUID      5d8b3e02-f33f-8d79-502b-88b456be46e74678
   IODev      brok_MQTT2
   LASTInputDev brok_MQTT2
   MSGCNT     7
   NAME       MQTT2_Shelly9_SZ_E2059C
   NR         24462
   STATE      ???
   TYPE       MQTT2_DEVICE
   brok_MQTT2_MSGCNT 7
   brok_MQTT2_TIME 2019-09-25 12:14:34
   READINGS:
     2019-09-25 12:14:33   FallbackTopic   cmnd/Shelly9-SZ_E2059C_fb/
     2019-09-25 12:14:33   GroupTopic      sonoffs
     2019-09-25 12:14:42   Heap            15
     2019-09-25 12:14:33   Hostname        Shelly9-SZ
     2019-09-25 12:14:33   IPAddress       192.168.0.138
     2019-09-25 12:14:33   LWT             Online
     2019-09-25 12:14:42   LoadAvg         19
     2019-09-25 12:14:33   Module          Shelly 1
     2019-09-25 12:14:42   POWER           OFF
     2019-09-25 12:14:33   RestartReason   Software/System restart
     2019-09-25 12:14:42   Sleep           50
     2019-09-25 12:14:42   SleepMode       Dynamic
     2019-09-25 12:14:42   Switch1         OFF
     2019-09-25 12:14:42   Time            2019-09-25T12:14:42
     2019-09-25 12:14:42   Uptime          0T00:00:13
     2019-09-25 12:14:33   Version         6.6.0(release-sonoff)
     2019-09-25 12:14:33   WebServerMode   Admin
     2019-09-25 12:14:42   Wifi_AP         1
     2019-09-25 12:14:42   Wifi_BSSId      B6:FB:E4:DA:35:78
     2019-09-25 12:14:42   Wifi_Channel    6
     2019-09-25 12:14:42   Wifi_Downtime   0T00:00:03
     2019-09-25 12:14:42   Wifi_LinkCount  1
     2019-09-25 12:14:42   Wifi_RSSI       98
     2019-09-25 12:14:42   Wifi_SSId       FlummyDevice
Attributes:
   DbLogExclude .*
   IODev      brok_MQTT2
   readingList Shelly9_SZ_E2059C:tele/Shelly9-SZ/LWT:.* LWT
Shelly9_SZ_E2059C:cmnd/Shelly9-SZ/POWER:.* POWER
Shelly9_SZ_E2059C:tele/Shelly9-SZ/INFO1:.* { json2nameValue($EVENT) }
Shelly9_SZ_E2059C:tele/Shelly9-SZ/INFO2:.* { json2nameValue($EVENT) }
Shelly9_SZ_E2059C:tele/Shelly9-SZ/INFO3:.* { json2nameValue($EVENT) }
Shelly9_SZ_E2059C:stat/Shelly9-SZ/RESULT:.* { json2nameValue($EVENT) }
Shelly9_SZ_E2059C:stat/Shelly9-SZ/POWER:.* POWER
Shelly9_SZ_E2059C:tele/Shelly9-SZ/STATE:.* { json2nameValue($EVENT) }
Shelly9_SZ_E2059C:tele/Shelly9-SZ/SENSOR:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE


Habs mal so probiert, wie ich es "kannte". Dann hat er zwar alles in Kleinbuchstaben gewandelt, aber ich kann vom MQTT Device nicht schalten, POWER1 reading gibt es nicht und toggle wird auch nicht angeboten. Also läuft da noch was falsch ;(

List vom "angepassten" Device
Internals:
   CFGFN     
   CID        Shelly9_SZ_E2059C
   DEF        Shelly9_SZ_E2059C
   DEVICETOPIC MQTT2_Shelly9_SZ_E2059C
   FUUID      5d8b3e02-f33f-8d79-502b-88b456be46e74678
   IODev      brok_MQTT2
   LASTInputDev brok_MQTT2
   MSGCNT     24
   NAME       MQTT2_Shelly9_SZ_E2059C
   NR         24462
   STATE      off
   TYPE       MQTT2_DEVICE
   brok_MQTT2_MSGCNT 24
   brok_MQTT2_TIME 2019-09-25 12:20:10
   OLDREADINGS:
   READINGS:
     2019-09-25 12:19:42   Heap            15
     2019-09-25 12:19:42   LoadAvg         19
     2019-09-25 12:20:10   POWER           on
     2019-09-25 12:19:42   Sleep           50
     2019-09-25 12:19:42   SleepMode       Dynamic
     2019-09-25 12:19:42   Switch1         off
     2019-09-25 12:19:42   Time            2019-09-25T12:19:42
     2019-09-25 12:19:42   Uptime          0T00:05:13
     2019-09-25 12:19:42   Wifi_AP         1
     2019-09-25 12:19:42   Wifi_BSSId      B6:FB:E4:DA:35:78
     2019-09-25 12:19:42   Wifi_Channel    6
     2019-09-25 12:19:42   Wifi_Downtime   0T00:00:03
     2019-09-25 12:19:42   Wifi_LinkCount  1
     2019-09-25 12:19:42   Wifi_RSSI       90
     2019-09-25 12:19:42   Wifi_SSId       FlummyDevice
     2019-09-25 12:20:28   state           off
Attributes:
   DbLogExclude .*
   IODev      brok_MQTT2
   model      A_10_shelly1
   readingList shellies/Shelly9-SZ/relay/0:.* state
  shellies/Shelly9-SZ/relay/0:.* relay0
  shellies/Shelly9-SZ/input/0:.* input0
  shellies/Shelly9-SZ/online:.* online
  shellies/Shelly9-SZ/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...Shelly9-SZ...mac.*, ? json2nameValue($EVENT) : undef }
Shelly9_SZ_E2059C:tele/Shelly9-SZ/STATE:.* { json2nameValue($EVENT) }
Shelly9_SZ_E2059C:tele/Shelly9-SZ/SENSOR:.* { json2nameValue($EVENT) }
Shelly9_SZ_E2059C:stat/Shelly9-SZ/RESULT:.* { json2nameValue($EVENT) }
Shelly9_SZ_E2059C:stat/Shelly9-SZ/POWER:.* POWER
   room       MQTT2_DEVICE
   setList    off:noArg shellies/Shelly9-SZ/relay/0/command off
  on:noArg shellies/Shelly9-SZ/relay/0/command on
  x_update:noArg shellies/Shelly9-SZ/command update_fw
  x_mqttcom shellies/Shelly9-SZ/command $EVTPART1
   userReadings state:POWER:.* { lc(ReadingsVal($name,"POWER","")) }


Vielen Dank und viele Grüße
Andreas

Beta-User

Kein Ding, und vielleicht schreibt jemand auch irgendwann in's Wiki, dass WLAN so seine Haken hat ;D . Ich nutze das (fast) nicht und bin daher befangen/ahnungslos :P .

Was die Hardwareskepsis angeht: Gemeint war nicht nur das "drumrum" (auch wichtig, aber das kenne ich nicht), sondern vorrangig eigentlich den Espressif-IC. Schon der ist suboptimal, ich hatte damals erst mal nur ein paar mit 6 oder 8 nach außen geführten PINs (und das als Noob in dem ganzen Thema IC-Programmierung ::) )...

Was die shelly's angeht:

1. braucht man eigentlich für _Tasmota_-geflashte ESP's nicht die "Basistemplates" separat anwenden, das macht eigentlich das 1. in der Liste intern schon automatisch ;) .

2. Wie sind die geflasht? Noch original-firmware? Dann ist sowieso alles anders...
toggle sollten da die SetExtensions machen (könnte man in den templates ergänzen, wenn die das verstehen), und eigentlich dachte ich, die Dinger senden Kleinschreibung zurück, und das ist eigentlich auch das, was dein list hier aussagt...?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

flummy1978

Da ich in einer Wiki noch nie was gemacht habe, bin ich da wohl leider der falsche Ansprechpartner  :-\
Das OT schließen wir mal aus dem Thema ab, hatte mich einfach nur sehr gewundert.... Aber danke für die aufschlussreichen Antworten....

1. hmm verwirrt mich jetzt komplett wegen Antwort in 2.

2. Also sie sind mit Tasmota 6.6.0 geflasht. Das erste List in dem Posting davor zeigt ein Device nach direktem autocreate durch MQTT. D.h. so sah das Ding mehr oder weniger nackt aus, nach wenigen Minuten. Dort sieht man eben auch
     2019-09-25 12:14:42   POWER           OFF
     2019-09-25 12:14:42   Switch1         OFF
also senden sie am Anfang erstmal Großbuchstaben. Das zweite List das ich geschickt habe, ist nach der Auswahl der Templates: "A_01z_tasmota_set_lowercase_texts_and_state1" und "A_01z_tasmota_set_power1_state_to_power" und am Ende "A10_Shelly" nacheinander. So habe ich das ursprünglich immer gemacht und es hat soweit super funktioniert, dass quasi die o.g. Vorraussetzungen erfüllt werden und alle Geräte immer die gleichen STATE und readings hatten ;)

p.s. Momentan kann ich das damit umgehen, dass ich ConfigBackup vom alten Device einspiele und die SetList und ReadingsList anpasse. Damit funktioniert es immernoch perfekt. Ist aber nicht im Sinne des Erfinders, weil ich ja auf Fortschritte, Ergänzungen und mögliche Bugfixes in der Modul / Templates etc  verzichte.