mqtt2.template: bugs, Fragen, Anregungen

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

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

Bitte nutzt möglichst diesen Thread, wenn ihr Fragen zur Nutzung von mqtt2.template habt.

Was gehört nicht hierher?
- Allgemeine Fragen die Nutzung des features attrTemplate an sich (also nicht speziell auf mqtt2 bezogen)
- Vorschläge für neue, (weitgehend) ausentwickelte templates für mqtt2. Dafür nutzt ihr bitte diesen Thread und beachtet die Hinweise.

Sinnvoll ist es, zuerst die Hinweise zu einzelnen mqtt2.templates zu lesen. Diese erhält man mit
set <device> attrTemplate ?

Viel Spaß mit dem neuen Feature!

Beta-User

Nachtrag:
Für den Support bzgl. neuer Templates ist es hilfreich, wenn ihr gleich ein paar Infos bereitstellt. Dazu gehört
- vorrangig eine RAW-Definition von dem, was "autocreate" so liefert, damit man das in einem Testsystem zumindest mal einen Eindruck von dem Gerät bekommt.
- sollten komplexe JSON-Strukturen als payload verwendet werden, dann bitte möglichst auch Infos, was das Gerät wie sendet. Wer das nicht mitschneiden kann/will, kann autocreate am IO auf "complex" stellen, dann kann ich besser raten...
- links auf die Projekthomepage, optiomalerweise (auch) dahin, wo der MQTT-spezifische Teil zu finden ist (topic-Pfade und payload-Beschreibungen).

Wer schon ein MQTT_DEVICE hat, kann auch gerne dieses als RAW liefern.

Nachtrag 2:
- am vollständigen "copy for forum" kann man (wenn MQTT2_SERVER im Einsatz ist)  in der Regel die "subscriptions" sehen. Dann ist uU. besser zu verstehen, wie eine evtl. vorhandene Doku zu lesen ist.
- Falls  "homeassistant"-(autodiscovery)-Topics auftauchen (ähnlich für Tasmota): das sollte man m.E. per ignoreRegexp ins Nirvana befördern (da steht was zu im Wiki bei MQTT2_CLIENT). Diese Topics generieren nur Readings, die für Verwirrung sorgen, also weg damit und dann das Device nochmal ohne diese Zusatzinfos anlegen lassen...
- Topics sollten möglichst so belassen werden, wie es aus der firmware etc. kommt. V.a. sollte man alles unterlassen, was mit Umlauten (oder Leerzeichen) zu tun hat, das schafft nur Probleme!
- im Wiki gibt es auch einen Artikel "Schritt für Schritt" zu MQTT2_DEVICE, da stehen diese Tipps auch drin, dazu Anmerkungen dazu, was ggf. in "on/off"-Settern landen sollte etc..
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

Beta-User

@Moderator

Wäre es möglich, den genannten und hier nochmal verlinkten Beitrag https://forum.fhem.de/index.php/topic,94495.0.html im MQTT-Bereich anzupinnen?

Danke vorab!
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

sinus61

Kleine Anregung zu den Templates, ich füge meinen Devices noch folgendes Userreading hinzu:


IPAddress:POWER.*:.* {my $ip=ReadingsVal($NAME,"IPAddress",""); $ip =~ s/<[^>]*>//gs; return("<html><a href='http://".$ip."/'>".$ip."</a></html>")}


Das macht das Reading IPAddress klickbar, so kommt man schnell auf das Webinterface des Gerätes. Weiß nicht ob sich das noch einfacher lösen lässt, aber vielleicht könnte man das auch in den Templates haben.

OdfFhem

@sinus61
Ist die folgende Anweisung im Userreading notwendig?

$ip =~ s/<[^>]*>//gs;


Denn eigentlich steht ja in IPAddress nur die IP-Adresse drin ...

Beta-User

Hmmm,
also das mit den userReadings gefällt mir allgemein nicht, und da besteht auch die Gefahr, dass irgendwas überschrieben wird, was schon da ist (oder ich muß lernen, wie man vernünftig grept, um nur den Teil zu schreiben/tauschen.

Alternativvorschlag: Ein echtes Reading setzen. Da die IP sich ja (hoffentlich) nie ändert, macht man das halt einmalig, indem man das entsprechende Template anwendet. (Eine Variante wäre, ein userAttr zu erlauben).

Vielleicht mag jemand das mal testen bzw. verbessern:
name:A_01x_tasmota_create_weblink_reading
filter:TYPE=MQTT2_DEVICE
desc:Applies to all tasmota devices <br>NOTE: This template will add or renew a reading Webinterface for direct access to the device's web interface
par:DEV_IP;Current IP of the device;{ AttrVal("DEVICE","IPAddress","")}
setreading DEVICE Webinterface <html><a href=http://DEV_IP/>Webinterface</a></html>
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

sinus61

Zitat von: OdfFhem am 06 Januar 2019, 17:47:43
Denn eigentlich steht ja in IPAddress nur die IP-Adresse drin ...

Aber nur am Anfang. Wenn sich das Reading mal aktualisiert steht da der HTML Kram mit drin und vermehrt sich dann jedesmal.

sinus61

Zitat von: Beta-User am 06 Januar 2019, 18:03:04
also das mit den userReadings gefällt mir allgemein nicht, und da besteht auch die Gefahr, dass irgendwas überschrieben wird, was schon da ist (oder ich muß lernen, wie man vernünftig grept, um nur den Teil zu schreiben/tauschen.

Genaugenommen wird ja nur das echte Reading IPAddress mit einem Link versehen, kein zusätzliches Userreading angelegt. Könnte man vielleicht auch über ein Template lösen, ich wollte aber kein zusätzliches Reading haben, sondern das vorhandene nutzen.

OdfFhem

#7
@sinus61
Verstehe und beim genauen Hinsehen sehe ich auch, dass gar kein "echtes" Userreading angelegt wird, sondern das originäre Reading überschrieben wird.
Ist das erstrebenswert, da ja der ursprüngliche Wert quasi verlorengeht ?


@Beta-User
Im Template A_01x_tasmota_create_weblink_reading dürfte noch die Bereitstellung vom Parameter DEVICE fehlen ...

sinus61

Zitat von: OdfFhem am 06 Januar 2019, 18:17:28
Ist das erstrebenswert, da ja der ursprüngliche Wert quasi verlorengeht ?

Ist vielleicht Geschmackssache, die IP Adresse bleibt aber ja genauso sichtbar wie vorher, ist jetzt nur mit einem Link versehen, ähnlich wie es z.B. bei IODev ist.

Beta-User

Hm, nur als Idee: könnte man die eventMap noch so umbasteln, dass man das userReadings-Dingens dafür nicht braucht?

Sonst müßte ich vermutlich die Struktur der Tasmota-templates nochmal umbasteln, dass es eines gibt ohne die userReadings (muß mir das aber in Ruhe mal ansehen, das mit der eventMap wäre ggf. generischer und mehr im Hintergrund).
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

santalaus

Hallo,

ist es möglich in A_01b_tasmota_1ch+motion+SI7021
Das ganze "flexibel" für SI7020/7021 zu gestallten?

Ich habe einen GY-21 aka SHT21,SI7021,HUT21 der sich als SI7020 meldet.

Nico

Beta-User

Zitat von: santalaus am 12 Januar 2019, 12:22:50
ist es möglich in A_01b_tasmota_1ch+motion+SI7021
Das ganze "flexibel" für SI7020/7021 zu gestallten?
Hmm, in dem aktuellen template ist keine readingList drin, es geht aber davon aus, dass die Werte an ein bestimmtes Reading geschickt werden. Wenn das anders ist, funktioniert es natürlich nicht...
Kann jemand sagen, wo der konkrete Pfad herkommt, an den der Tasmota publisht? Wenn man das vereinheitlichen könnte (ggf. durch eine Anweisung via MQTT) ginge das vielleicht. Am besten wäre, wenn das Reading dann jeweils generisch wäre (temperature und humidity?).

Aber dazu sollte sich das erst mal jemand ansehen, der ein oder mehrere solcher Geräte hat. Beispiele, wie das mit dem Umkonfigurieren ginge, sind in der aktuellen template-file zu finden.
Ansonsten kannst du ja die Readings, auf die zugegriffen wird im devStateIcon auch manuell ändern; die templates sollen/müssen m.E. nicht jeden konkreten Fall abdecken, sondern ggf. auch als "Steinbruch" genutzt werden können für eigene Ideen ;) .

Zitat von: sinus61 am 06 Januar 2019, 18:15:31
Genaugenommen wird ja nur das echte Reading IPAddress mit einem Link versehen, kein zusätzliches Userreading angelegt. Könnte man vielleicht auch über ein Template lösen, ich wollte aber kein zusätzliches Reading haben, sondern das vorhandene nutzen.
Ok, das habe ich jetzt verstanden, finde es aber nach wie vor suboptimal (weil andere andere userReadings haben können und ich das Attribut möglichst nicht unbesehen überschreiben will).
In den aktuellen templates ist ein auskommentierter Vorschlag für eine eventMap drin. Sowas müßte eigentlich mit demselben Effekt funktionieren ohne Nebenwirkungen, könnt ihr euch das mal ansehen?
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

TomLee

Hallo,

wollte mal fragen weshalb du in der mqtt2.template  bei jedem Template das readingList und setList verwendet die zwei Leerzeichen vor jedem Listen-Kommando vornimmst ?

Dadurch wird ab dem zweiten Listeneintrag jedes Kommando in Fhemweb um zwei Leerzeichen eingerückt zum ersten Listeneintrag dargestellt. siehe Anhang

Ich hab ein wenig gespielt. Beide Beispiele sind möglich das die Kommandos nicht eingerückt werden. Der erste Listeneintrag kann mit oder ohne Leerzeichen angegeben werden.


attr DEVICE setList \
off:noArg    cmnd/DEVNAME/POWER 0\
on:noArg     cmnd/DEVNAME/POWER 1\
toggle:noArg cmnd/DEVNAME/POWER 2



attr DEVICE setList \
  off:noArg    cmnd/DEVNAME/POWER 0\
on:noArg     cmnd/DEVNAME/POWER 1\
toggle:noArg cmnd/DEVNAME/POWER 2

Beta-User

Hmmm,

das mit den Leerzeichen hatte ich so (allerdings offensichtlich nicht ganz konsitent) aus den ersten Versionen übernommen.

Für mich hat es den Vorteil, dass es in der template-File jeweils übersichtlicher ist: Durch die Einrückung ist reicht leicht erkennbar, was zusammengehört ;) . Dass das bei langen Topics zu unschönen Darstellungen führt, ist nicht so toll. Mal schauen, ob ich das bei Gelegenheit ändere oder wenigstens vereinheitliche (erster Listeneintrag).

Danke für den Hinweis jedenfalls!
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

torte

Hi Beta-User,

shelly2 im RollerMode

sorry, habe gerade erst die Änderungen ausprobieren können.
Leider bekomme ich dann die Meldung

Global symbol "$JSONMAP" requires explicit package name (did you forget to declare "my $JSONMAP"?) at (eval 69161) line 1.


Muss ich noch was machen?

Habe bei meinem aber auch noch ein bissel Hand angelegt.

attr DEVICE setList \
  open:noArg shellies/DEVNAME/roller/0/command open\
  close:noArg shellies/DEVNAME/roller/0/command close\
  stop:noArg shellies/DEVNAME/roller/0/command stop\
  state:slider,0,1,100 shellies/DEVNAME/roller/0/command/pos $EVTPART1
attr DEVICE readingList shellies/DEVNAME/roller/0/pos:.* state


Habe das Reading pos rausgeschmissen war ja dasselbe wie das state.
Autoshuter habe ich (noch) nicht  :-\ braucht der die Position auf pct?

Grüße
Torte