MQTT Device Template Einstellungen

Begonnen von rhoffm34, 09 Oktober 2021, 01:38:06

Vorheriges Thema - Nächstes Thema

rhoffm34

Hallo zusammen,

ich mochte folgendes MQTT Device implementieren:

"LC Technology ESP8266 5V Relay Board" (Einfaches, Batterie betriebenes Relais)

Das Gerät wurde in FHEM erkannt und jetzt möchte ich das Template einstellen.

In Wiki.fhem steht folgendes:
Exisitert (noch) kein passendes attrTemplate, ist zu empfehlen, zunächst das "tasmota_basic" anzuwenden.

Wenn ich
set <device> attrTemplate tasmota_basic eingebe kommt ein Fenster wo ich nicht weiß was ich eintragen soll...

Specify the unknown parameters for tasmota_basic_state_power1:

Command topic prefix, without trailing /   
info topic prefix, without trailing /   
ack topic prefix, without trailing /

Was muss ich hier eintragen oder was muss ich anders machen um das Device richtig anzulegen?

Gruß,
Rhoffm34



Otto123

Hi,

also falls Du:
- einen MQTT2_SERVER definiert hast
- der autocreate aktiv hat
- auf deinem ESP Tasmota läuft
Dann sollte ein Gerät erzeugt werden, eventuell dazu den ESP neu starten, in dem Gerät sollten grundlegenden Readings existieren ( Du könntest ein list posten) und dann sollten die Templates zur Auswahl stehen und eigentlich keine Abfrage kommen.

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

JudgeDredd

Hallo Zusammen,

Zitat von: Otto123 am 09 Oktober 2021, 12:57:17
also falls Du:
- einen MQTT2_SERVER definiert hast
- der autocreate aktiv hat

Mein Shellys laufen alle mit dem "normalen" MQTT Modul und es funktioniert auch alles bestens.
Vor kurzem habe ich ich mir überlegt, mir das MQTT2 mal testweise anzusehen, habe aber die Template Geschichte auch nicht so ganz verstanden.

Da ich einen Broker bereits habe, hatte ich den MQTT2_CLIENT als Server Connect genommen und danach den Shelly mit MQTT2_DEVICE installiert.
Im manuell angelegten MQTT_DEVICE gibt es ja ebenfalls ein
SET <name> attrTemplate <template>
Dort finde ich aber nur den Shelly1. (Welcher auch bestens funktioniert hat in meiner Testumgebung)

Sehe ich das richtig, das ich die Templates aus dem File "mqtt2.template" nur dann nutzen kann, wenn ich den MQTT2_SERVER mit Autocreate betreibe ?

Wenn dem so wäre, dann verstehe ich nicht den Vorteil von der MQTT2_CLIENT/MQTT2_DEVICE ggü. dem MQTT_DEVICE Modul ?

Kannst Du da evtl. etwas mehr Licht für mich in die Angelegenheit bringen, Otto ?

Gruß,
JudgeDredd
Router: Eigenbau (pfSense)
FHEM: Proxmox (DELL R720) | Debian 12 (VM)

Otto123

Die Templates funktionieren mit dem MQTT2_DEVICE - egal an welchem IODev die hängen (SERVER oder CLIENT).
Nur beim CLIENT ist per default autocreate nicht aktiv.
Und MQTT2_DEVICEs erzeugen beim Anlegen (oder wenn bei ihnen autocreate nicht deaktiviert wird) readings entsprechend der MQTT Nachrichten. Diese setzen normal Werte, die im Template abgefragt werden (können)

rhoffm34 hatte aber soviele Infos geliefert  :'(, dass ich nur angefangen habe zu spekulieren wie es sein könnte. Ich wollte damit nicht sagen wie es sein muss :)
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

rhoffm34

Hallo Ihr beiden, danke für die Infos...

Hier das list

Internals:
   CFGFN     
   CID        SWbat_HalloweenFog
   DEF        SWbat_HalloweenFog
   DEVICETOPIC MQTT2_SWbat_HalloweenFog
   FUUID      6160d08d-f33f-a99d-f077-3df4db1bf5480ef6
   IODev      mqtt2server
   LASTInputDev mqtt2server
   MSGCNT     6
   NAME       MQTT2_SWbat_HalloweenFog
   NR         2292
   STATE      ???
   TYPE       MQTT2_DEVICE
   mqtt2server_MSGCNT 6
   mqtt2server_TIME 2021-10-09 19:50:08
   READINGS:
     2021-10-09 01:13:17   IODev           mqtt2server
     2021-10-09 19:50:08   POWER           OFF
     2021-10-09 01:13:17   subscriptions   cmnd/SWbat_HalloweenFog_fb/# cmnd/tasmotaSwitch1/# cmnd/tasmotas/#
Attributes:
   readingList SWbat_HalloweenFog:stat/tasmotaSwitch1/RESULT:.* { json2nameValue($EVENT) }
SWbat_HalloweenFog:stat/tasmotaSwitch1/POWER:.* POWER
   room       MQTT2_DEVICE

rhoffm34

Templates stehen zur Verfügung, gefühlte 50 Stück... aber welches ist das richtige??

Otto123

Da sind ziemlich wenig Readings.
Hast Du das tasmota Gerät mal neu gestartet?

tasmota_basic ist erstmal nicht verkehrt.
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

rhoffm34

Ich denke da gibt es auch nicht viel für Readings... Ist ja nur ein einfaches Relais.

Ja, ich hab das schon öfter neu gestartet.

Ok, wenn ich tasmota_basic nehme dann kommen die Fragen nach :

Specify the unknown parameters for tasmota_basic_state_power1:

Command topic prefix, without trailing /   
info topic prefix, without trailing /   
ack topic prefix, without trailing /

Otto123

gibt es weitere MQTT2 Devices die die Topics abfangen? Wie ist Tasmota konfiguriert? EInstellungen / MQTT EInstellungen?
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

rhoffm34

Ich habe das Device jetzt mal als Module type : Generic (18) und D3 GPIO0 : Relay 1 konfiguriert.

Es funktioniert!

Danke für die Mühe.


Beta-User

Vielleicht noch ein paar Anmerkugen, weil hier doch manches exemplarisch angeklungen ist:

a) Man muss deutlichst unterscheiden zwischen den "tasmota-internen" templates (zu finden in https://templates.blakadder.com/), die die Konfiguration der PINs usw. betreffen und überhaupt erst dafür sorgen, dass die Hardware an sich funktioniert. Das ist nicht das Thema bei FHEM-attrTemplate.

b) FHEM-attrTemplate ändert zwar bei Tasmota auch etwas an der Einstellung der firmware, aber das betrifft nur die Frage, wie Zustände geschrieben und übermittelt werden: on statt ON usw..

c) Was man sieht und direkt einstellen kann, wird über "prereq" und "filter" eingestellt. Siehe dazu https://wiki.fhem.de/wiki/AttrTemplate#Warum_finde_ich_das_Template_xyz_nicht.3F

Daraus resultierte die Anforderung von Otto123, den ESP neu zu starten. Dann wird nämlich in der Regel der "LWT"-Topic neu übermittelt - warum der hier nicht in der readingList gelandet ist, wäre eine spannende Frage, denn:

Ist er drin, muss man auch erst mal keine Fragen beantworten - ausgenommen ggf. die nach dem gewünschten Namen im Rahmen einer eventuell installierten Firmware.

Daher ist zu dem hier noch anzumerken:
Zitat von: JudgeDredd am 09 Oktober 2021, 17:25:42
Im manuell angelegten MQTT_DEVICE gibt es ja ebenfalls ein
SET <name> attrTemplate <template>
Dort finde ich aber nur den Shelly1. (Welcher auch bestens funktioniert hat in meiner Testumgebung)

Sehe ich das richtig, das ich die Templates aus dem File "mqtt2.template" nur dann nutzen kann, wenn ich den MQTT2_SERVER mit Autocreate betreibe ?
shelly1 wird nicht gefilter, damit man sehen kann, dass es dafür prinzipiell auch was gibt. Sobald man im manuell angelegten Device den passenden (auch bei shelly, soweit ich das im Kopf habe: LWT) Topic in der readingList eingetragen hat, wird dann sehr viel mehr sichtbar und auswählbar - und man muss dann in der Regel auch keine Fragen mehr beantworten, weil das attrTemplate dann die speziellen Parameter des Zieldevices selbst ermitteln kann...

Der Vorteil liegt dann darin, dass man sich nicht allzusehr den Kopf über optimale Einstellungen zerbrechen muss, weil man sowas wie "allgemein aktueptierte Standards" frei Haus geliefert bekommt und die Einstellungen im Detail dann jeweils zueinander passen sollten. Siehe z.B. auch https://forum.fhem.de/index.php/topic,123254.msg1178548.html#msg1178548 für eine ZWave betreffende Fragestellung.

Hoffe, damit etwas Klarheit in das ganze gebracht zu haben.
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

JudgeDredd

Zitat von: Otto123 am 09 Oktober 2021, 19:21:36Nur beim CLIENT ist per default autocreate nicht aktiv.
Zitat von: Beta-User am 10 Oktober 2021, 09:29:29
shelly1 wird nicht gefilter, damit man sehen kann, dass es dafür prinzipiell auch was gibt.
Der Vorteil liegt dann darin, dass man sich nicht allzusehr den Kopf über optimale Einstellungen zerbrechen muss, weil man sowas wie "allgemein aktueptierte Standards" frei Haus geliefert bekommt und die Einstellungen im Detail dann jeweils zueinander passen sollten.
Hoffe, damit etwas Klarheit in das ganze gebracht zu haben.
Vielen Dank für die Klarstellung.
Ich habe mal beim MQTT2_CLIENT das Autocreate aktiviert und schon gings los ...

Da ich aber nicht so der Fan von Autocreate bin und lieber selbst Devices im Minimaldesign anlege, bleibe ich wohl bei der MQTT / MQTT-DEVICE Kombination.
Aber ich weiß ja nun, was theortisch möglich wäre.

Gruß,
JudgeDredd
Router: Eigenbau (pfSense)
FHEM: Proxmox (DELL R720) | Debian 12 (VM)

Beta-User

Zitat von: JudgeDredd am 10 Oktober 2021, 10:45:59
Ich habe mal beim MQTT2_CLIENT das Autocreate aktiviert und schon gings los ...
...je nachdem, was da über den Server läuft, ist das nicht unbedingt spaßig...

Zitat
Da ich aber nicht so der Fan von Autocreate bin und lieber selbst Devices im Minimaldesign anlege, bleibe ich wohl bei der MQTT / MQTT-DEVICE Kombination.
Aber ich weiß ja nun, was theortisch möglich wäre.
Nur zur Klarstellung: Man _kann_ MQTT2_DEVICE (via MQTT2_CLIENT) genauso minimalistisch Nutzen wie MQTT+MQTT_DEVICE.

Man _kann_ attrTemplate bei MQTT2_DEVICE auch ohne autocreate nutzen, in der Regel reicht es, dafür eine "passende" Zeile in readingList zu schreiben (die man auch für MQTT_DEVICE kennen muss...).

autocreate (und attrTemplate) sind als Hilfestellung für die gedacht, die nicht sowieso wissen, was sie tun; wer es weiß, kommt auch ohne aus. MQTT2_SEVICE ist halt gegenüber MQTT_DEVICE im Vorteil, was die direkte Verarbeitung der eingehenden Daten angeht, weil man (ähnlich wie bei MQTT_GENERIC_BRIDGE) direkt Perl-Code anflanschen kann und die Daten im Prinzip beliebig vorverarbeiten, bevor sie zu Readings werden (was insbesondere dann ein Vorteil ist, wenn JSON-encoded Daten ankommen). Außerdem ist das Versenden von JSON-Blobs deutlich einfacher wie bei MQTT_DEVICE (falls es da überhaupt sinnvoll 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

Scherheinz

Hallo zusammen,

Ich hol diesen Thread wieder raus da ich das gleiche Problem habe und es nicht verstehe. Ich will zwei Nous A1T mit Tasmota einbinden und bekomme dieses Eingabefeld jedesmal egal was ich in Tasmota konfiguriere. Auch die Lösung von rhoffm34 funktioniert bei mir nicht. Mit den älteren Gosund und Sonoff hatte ich diese Probleme nie. Auch das aktualisieren der Tasmota Firmware hat keine Änderung gebracht.

Hat jemand noch eine Idee?

Gruß



Otto123

Zitat von: Scherheinz am 25 Dezember 2023, 13:36:28Hat jemand noch eine Idee?
Ja, zeige ein list vom device.

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