FHEM Forum

FHEM - Hausautomations-Systeme => MQTT => Thema gestartet von: Beta-User am 15 Dezember 2018, 11:44:43

Titel: mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 15 Dezember 2018, 11:44:43
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 (https://forum.fhem.de/index.php/topic,94495.msg872201.html#msg872201).

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.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 18 Dezember 2018, 10:37:42
@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!
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: sinus61 am 06 Januar 2019, 16:34:21
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.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: OdfFhem am 06 Januar 2019, 17:47:43
@sinus61
Ist die folgende Anweisung im Userreading notwendig?
$ip =~ s/<[^>]*>//gs;

Denn eigentlich steht ja in IPAddress nur die IP-Adresse drin ...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 06 Januar 2019, 18:03:04
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>
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: sinus61 am 06 Januar 2019, 18:08:17
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.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: sinus61 am 06 Januar 2019, 18:15:31
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.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: OdfFhem am 06 Januar 2019, 18:17:28
@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 ...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: sinus61 am 06 Januar 2019, 18:32:53
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.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 06 Januar 2019, 19:34:30
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).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: santalaus am 12 Januar 2019, 12:22:50
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
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 12 Januar 2019, 17:43:51
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 ;) .

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?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 17 Januar 2019, 13:12:31
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
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 17 Januar 2019, 13:23:33
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!
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: torte am 17 Januar 2019, 14:21:24
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
 

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 17 Januar 2019, 14:31:41
Ist das die letzte Version, mit der du getestet hattest? (Das $JSONMAP sollte eigentlich raus sein; ist also an sich ok, wenn du das gelöscht hast, der Rest (oder alles?) ist dann aber auch nicht durchgelaufen).
Die letzte Fassung mappt auch wieder was anderes auf state (Diskussion/Anregung war in dem shelly-mqtt2-Thread).

Für ASC hatte ich da nachgefragt, wie es am "geschicktesten" ist, habe aber selbst "nur" CUL_HM's => Testen geht nicht. Vermutlich ginge auch pos, aber dann muß man händisch was an den Attributen für ASC drehen; daher der Weg, das (weitgehend?) direkt "ASC-konform" zu machen; pct scheint bei FHEM allg. verbreiteter zu sein, auch ROLLO hat das übernommen, und in MQTT kann man es ja auch bequem umbiegen :) .
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: torte am 17 Januar 2019, 14:44:35
hi,

jo läuft jetzt, kaum macht man es richtig....

gerade nochmal update gezogen. Template passt so  :D
ob "state" oder "pct" ist mir wuppe  8)

Gruß
Torte
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Intruder1956 am 20 Januar 2019, 14:35:54
Hallo,
kann es sein, das das Template L_01_zigbee2mqtt_bridge einen Fehler hat ?
z.b. folgende Zeile

zigbee2mqtt/bridge/log:.*\"type\".\"devices\".\"message\".* devices\
Ich frage deshalb, weil nach dem


Zigbee2mqtt/bridge/log:.*\im Editor  fhem.cfg  oder beim editieren von attr readinglist, alles in grün angezeigt wird.

Was fehlt oder ist zu viel ??

Danke
Gruß Werner
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 20 Januar 2019, 15:07:16
Wie OdfFhem hier schon (https://forum.fhem.de/index.php/topic,94495.msg891651.html#msg891651) geschrieben hat:
Das scheint ein Interpretationsproblem des Editors zu sein.

Da ich fhem.cfg nicht nutze (configDB), kann ich den optischen Effekt zwar in der Editieransicht des Attributs sehen, aber sonst keine Seiteneffekte feststellen. Hast du ein über den optischen Effekt hinausgehendes Problem?

Bitte ggf. einen separaten Thread im zu codemirror (=Editor) passenden Forenbereich aufmachen, gerne dazu hierher verweisen.

(Allg. würde ich eh' davon abraten, die cfg direkt zu editieren, ob jetzt über den integrierten Editor oder extern. Ich verwende für die entsprechenden Aufgaben den RAW-Editor).

Im anderen Thread brauchst du nichts zu löschen (vielleicht die betreffende Frage), ich wollte die Diskussion nur nicht dort weiterführen, und ohne deine Frage müßte man dann wieder die Antworten auch löschen... So dramatisch ist es nun auch nicht, dass da was steht, was ausweisliche der Einleitung da nicht hingehört ;) .
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Intruder1956 am 20 Januar 2019, 15:38:04
Hast du ein über den optischen Effekt hinausgehendes Problem?

Entschuldige bitte, das ich überhaupt gefragt habe, Ich habe kein Problem mit irgend welchen Effekten.
Bin nur gerade dabei mir ein neues Fhem in einer VM mit DBLog aufzubauen und evtl. Fehler gleich auszuschliessen.

Ich bin davon ausgegangen, wenn der "codemirror" es so darstellt, dass evtl. ein z.b. Hochkomma, Klammer, Punkt oder Semikolon fehlt oder sogar über ist und ich es woanders verwerten könnte  ;)
Aber wenn die Zeile so OK ist, kann auch ich damit umgehen und belasse es wie es ist

Vielen Dank
Gruß Werner
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: deimos84 am 26 Januar 2019, 20:51:29
Hallo zusammen,

ich nutze nun seit ein paar Wochen shellybulbs und habe sie bisher als dummy iVm einem Notify eingerichtet, da ich nur so den kompletten Funktionsumfang realisieren konnte. Heute habe ich ein MQTT2_DEVICE mit dem entsprechenden Template erstellt, da ich einerseits auf die Notifies verzichten und andererseits von den MQTT-Subscriptions profitieren möchte.

Die im Template enthaltenen Funktionen (on/off, rgb, brightness und temp) funktionieren zwar. Ich nutze aber auch die eingebauten Effekte (effect) und den Moduswechsel (mode)

Nun stehe ich vor folgender Problemstellung:

Ich habe die Setlist mit den entsprechenden Befehlen erweitert

   mode:white,color shellies/shellybulb-123456/color/0/set {"ison":"true","mode":"$EVTPART1","brightness":"100","gain":"100"}
  effect:0,1,2,3,4,5 shellies/shellybulb-123456/color/0/set {"ison":"true","mode":"white","effect":"$EVTPART1"}

Das funktioniert an sich auch. Ich muss aber beim Wechsel des mode mindestens auch einen Wert für brightness übergeben, damit die bulb den json string annimmt. Ebenso muss ich beim effect auch den mode mit angeben.

Leider habe ich bisher nicht hinbekommen, die Zusatzwerte dynamisch zu gestalten bzw die Werte aus den vorhandenen Readings zu beziehen. Wenn ich nun also den mode wechsle, wird die brightness immer auf 100% gestellt. Und beim Wechsel des effect wird der mode immer auf white gestellt. Wenn er vorher auf color war, wird nach Beendigung des Effekts das Licht weiß.

Gibts es eine Möglichkeit dieses Problem im MQTT2_DEVICE zu lösen oder muss ich auch weiterhin auf Notifies setzen?

Vielen Dank im Voraus!

deimos84
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 27 Januar 2019, 08:32:05
Gibts es eine Möglichkeit dieses Problem im MQTT2_DEVICE zu lösen oder muss ich auch weiterhin auf Notifies setzen?
Das sollte gehen, indem du die Perl-Variante in der setList nimmst:
the perl expression must return a string containing the topic and the message separated by a space.Leider habe ich grade kein Beispiel zur Hand (es könnte was in den ersten Varianten mit MQTT2 in dem Sidoh-Bridge stehen)
effect:0,1,2,3,4,5 {my $brightness = readingsNum(...); return "shellies/shellybulb-123456/color/0/set {\"ison\":\"true\",\"brightness\":$brightness... $EVTPART1\"}"}Oder hinten mit toJSON (damit sollte der betr. Teil des Sidoh-Brige Threads es zu finden sein).

Wäre klasse, wenn du da ggf. Ergänzungen für's Wiki liefern könntest, die cref ist an der Stelle m.E. noch etwas arg kurz.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: deimos84 am 27 Januar 2019, 10:21:42
Vielen Danke für die echt schnelle Antwort!


effect:0,1,2,3,4,5 {my $brightness = readingsNum(...); return "shellies/shellybulb-123456/color/0/set {\"ison\":\"true\",\"brightness\":$brightness... $EVTPART1\"}"}

Auf die Art habe ich es bereits versucht. Das resultiert aber immer in Fehlermeldungen. Vielleicht habe ich auch nur etwas übersehen.

mode:white,color {my $brightness = readingsNum($NAME,"brightness",99); return "shellies/shellybulb-123456/color/0/set {\"ison\":true,\"mode\":".$EVTPART1.",\"brightness\":".$brightness .",\"gain\":".$brightness }
==> Global symbol "$NAME" requires explicit package name (did you forget to declare "my $NAME"?) at (eval 24134) line 1.

mode:white,color {my $brightness = readingsNum(shelly_bulb_WoZ,"brightness",99); return "shellies/shellybulb-123456/color/0/set {\"ison\":true,\"mode\":".$EVTPART1.",\"brightness\":".$brightness .",\"gain\":".$brightness }
==> Bareword "shelly_bulb_WoZ" not allowed while "strict subs" in use at (eval 23725) line 1.

Bezüglich der Sidoh-Bridge habe ich bisher nichts passendes gefunden.

EDIT:
Wenn ich $NAME zuvor noch definiere

mode:white,color {my $NAME= "shelly_bulb_WoZ"; my $brightness=readingsVal($NAME,"brightness",99); "shellies/shellybulb-123456/color/0/set {\"ison\":true,\"mode\":".$EVTPART1.",\"brightness\":".$brightness.",\"gain\":".$brightness }
erscheint im Log die Fehlermeldung "Undefined subroutine &main::readingsVal called at (eval 24637) line 1"
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 27 Januar 2019, 10:35:47
Also entweder auch den Device-Namen in Anführungszeichen packen in ReadingsNum (=>bareword etc.; das sind aber (Perl-) Grundlagen...), oder evtl. mal $name (kleingeschrieben) versuchen (wäre mein Favorit).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: deimos84 am 27 Januar 2019, 10:42:27
Also entweder auch den Device-Namen in Anführungszeichen packen in ReadingsNum (=>bareword etc.; das sind aber (Perl-) Grundlagen...), ...

Die habe ich tatsächlich vergessen. Ich bin aber auch ein Depp. Hilft aber letztendlich auch nichts. Dann erkennt er readingsVal nicht.

..., oder evtl. mal $name (kleingeschrieben) versuchen (wäre mein Favorit).

Beide Schreibweisen (groß und klein) ergeben die gleiche Fehlermeldung.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 27 Januar 2019, 11:02:58
Sorry, habe bei der Schreibweise einen Fehler reingebaut: ReadingsVal() schreibt sich groß...

Nimm aber besser ReadingsNum().
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: deimos84 am 27 Januar 2019, 11:29:26
mode:white,color {my $brightness=ReadingsNum("shelly_bulb_WoZ","brightness",99); "shellies/shellybulb-123456/color/0/set {\"ison\":true,\"mode\":\"".$EVTPART1."\",\"brightness\":".$brightness.",\"gain\":".$brightness."}" }
Damit funktioniert es. Vielen Dank. Also alles wieder mal nur Schusselfehler meinerseits. Na sauber... Ist ja nicht so, als hätte ich das schon alles funktional im Notify gehabt.

anbei die bisherige SetList:

off:noArg shellies/shellybulb-123456/color/0/command off
  on:noArg shellies/shellybulb-123456/color/0/command on
  brightness:colorpicker,BRI,0,1,100 shellies/shellybulb-3CC394/color/0/set {"ison":"true","$EVTPART0":"$EVTPART1","gain":"$EVTPART1"}
  temp:colorpicker,CT,3000,10,6500 shellies/shellybulb-3CC394/color/0/set {"ison":"true","mode":"white","$EVTPART0":"$EVTPART1"}
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/; "shellies/shellybulb-123456/color/0/set {\"ison\":true,\"mode\":\"color\",\"red\":".hex($1).",\"green\":".hex($2)."\"blue\":".hex($3) }
  mode:white,color {my $brightness=ReadingsNum("shelly_bulb_WoZ","brightness",99); "shellies/shellybulb-123456/color/0/set {\"ison\":true,\"mode\":\"".$EVTPART1."\",\"brightness\":".$brightness.",\"gain\":".$brightness."}" }
  effect:0,1,2,3,4,5,6 {my $mode=ReadingsVal("shelly_bulb_WoZ","mode","white"); "shellies/shellybulb-123456/color/0/set {\"ison\":true,\"mode\":\"".$mode."\",\"effect\":".$EVTPART1."}" }


Danke nochmal für die unkomplizierte Hilfe!
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Christian Uhlmann am 07 Februar 2019, 11:48:25
Hallo zusammen,

gibt es schon ein Template, welches für den Sonoff POW genutzt werden kann?
Wenn nein, was wird benötigt, damit eins erstellt werden kann? Welches Template passt am besten, wenn man erst mal nur schalten möchte und den Schaltzustand anzeigen lassen möchte?


Danke und Grüße

Christian
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 07 Februar 2019, 11:57:11
Schalten und Zustand sollte mit A_01_tasmota_basic möglich sein.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Christian Uhlmann am 07 Februar 2019, 12:45:00
Hi,

ja, vielen Dank. Hat nun geklappt. Ein . (Punkt) im Topic mag das System nicht.
Aber damit kann ich leben


LG Christian
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: DasQ am 07 Februar 2019, 12:48:26
was in der art?

defmod sonoff_Waeschetrockner MQTT2_DEVICE sonoffPow1
attr sonoff_Waeschetrockner IODev MQTT2_Broker
attr sonoff_Waeschetrockner group Trockner
attr sonoff_Waeschetrockner readingList sonoffPow1:tele/sonoffPOW1/STATE:.* { json2nameValue($EVENT) }\
sonoffPow1:tele/sonoffPOW1/SENSOR:.* { json2nameValue($EVENT) }\
sonoffPow1:tele/sonoffPOW1/LWT:.* LWT\
sonoffPow1:cmnd/sonoffPOW1/POWER:.* POWER\
sonoffPow1:tele/sonoffPOW1/INFO1:.* { json2nameValue($EVENT) }\
sonoffPow1:tele/sonoffPOW1/INFO2:.* { json2nameValue($EVENT) }\
sonoffPow1:tele/sonoffPOW1/INFO3:.* { json2nameValue($EVENT) }\
sonoffPow1:stat/sonoffPOW1/RESULT:.* { json2nameValue($EVENT) }\
sonoffPow1:stat/sonoffPOW1/POWER1:.* POWER1\
sonoffPow1:tele/sonoffPOW1/UPTIME:.* { json2nameValue($EVENT) }
attr sonoff_Waeschetrockner room Waschkueche
attr sonoff_Waeschetrockner setList off:noArg    cmnd/sonoffPOW1/POWER1 0\
on:noArg     cmnd/sonoffPOW1/POWER1 1
attr sonoff_Waeschetrockner stateFormat {sprintf("aktuell: %.1f W Tag: %.2f Kw/h Gestern: %.3f Kw/h Gesamt: %.4f Kw/h", ReadingsVal($name,"ENERGY_Power",undef), ReadingsVal($name,"ENERGY_Today",undef), ReadingsVal($name,"ENERGY_Yesterday",undef), ReadingsVal($name,"ENERGY_Total",undef))}

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 07 Februar 2019, 13:10:32
was in der art?
Vermutlich sucht Christian was in der Art... Für ihn wäre aber ein erweitertes template hilfreicher als dein mühsam von Hand erweitertes Beispiel ::) :P .

Also (ungetestet, habe kein passendes Device) sowas:
name:A_01b_tasmota_POW
filter:TYPE=MQTT2_DEVICE
desc:Applies to Sonoff POW devices<br>NOTE: Power topic will be set to POWER1; the format the device is sending data will also be changed to lowercase!
set DEVICE attrTemplate A_01a_tasmota_basic_state_power1
attr DEVICE stateFormat {sprintf("aktuell: %.1f W Tag: %.2f Kw/h Gestern: %.3f Kw/h Gesamt: %.4f Kw/h", ReadingsVal($name,"ENERGY_Power",undef), ReadingsVal($name,"ENERGY_Today",undef), ReadingsVal($name,"ENERGY_Yesterday",undef), ReadingsVal($name,"ENERGY_Total",undef))}
attr DEVICE model A_01b_tasmota_POW
Fehlt ggf. dann noch die uptime; da sollte es reichen ggf. autocreate am DEVICE wieder einzuschalten.

Gruß, Beta-User

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: DasQ am 07 Februar 2019, 17:58:17
ja sorry, hat sich irgenwie überschnitten.

aber dafür test ich gleich mal morgen
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: helmut am 19 Februar 2019, 18:22:23
Hallo Beta-User,

heute habe ich zum ersten Mal die Templates fuer ein Sonoff Pow Device ausprobiert.
Das funktioniert sehr gut, aber bei der Masseinheit zur Anzeige der Arbeit habe ich einen
Fluechtigkeitsfehler gefunden. Die Arbeit wird in Leistung mal Zeiteinheit ausgedrueckt,
daher muss es statt "Kw/h" "kWh" heissen.

name:A_01c_tasmota_POW
[...]
attr DEVICE stateFormat {sprintf("aktuell: %.1f W Tag: %.2f Kw/h Gestern: %.3f Kw/h Gesamt: %.4f Kw/h", ReadingsVal($name,"ENERGY_Power",undef), ReadingsVal($name,"ENERGY_Today",undef), ReadingsVal($name,"ENERGY_Yesterday",undef), ReadingsVal($name,"ENERGY_Total",undef))}

Gruss Helmut
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 19 Februar 2019, 19:08:22
Thx, habe da leider wirklich nicht drauf geachtet, sondern das einfach so übernommen wie übermittelt :( . Ist im svn jetzt hoffentlich richtig.

Danke für die positive Rückmeldung im Übrigen :) .
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: helmut am 20 Februar 2019, 11:41:12
Danke, jetzt ist es richtig. Das duerfte den Meisten nicht auffallen. Aber als gelerntem
Starkstroemer springt Dir sowas ins Auge ;-)

Gruss Helmut
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: carlos am 20 Februar 2019, 23:43:37
Dank dem neuen support für mehrere gleichzeitige devStateIcons in einem device von justme1968, sieht mein sonoff 4ch jetzt so aus:
defmod MQTT2_sonoff4ch MQTT2_DEVICE sonoff4ch
attr MQTT2_sonoff4ch IODev m2s
attr MQTT2_sonoff4ch alias Sonoff4ch
attr MQTT2_sonoff4ch autocreate 0
attr MQTT2_sonoff4ch devStateIcon Online:10px-kreis-gruen@green Offline:10px-kreis-rot@red 1.on:on:POWER1+off 1.off:off:POWER1+on 2.on:on:POWER2+off 2.off:off:POWER2+on 3.on:on:POWER3+off 3.off:off:POWER3+on 4.on:on:POWER4+off 4.off:off:POWER4+on
attr MQTT2_sonoff4ch icon hue_filled_outlet
attr MQTT2_sonoff4ch readingList tele/sonoff4ch/LWT:.* LWT\
tele/sonoff4ch/STATE:.* { json2nameValue($EVENT) }\
tele/sonoff4ch/SENSOR:.* { json2nameValue($EVENT) }\
tele/sonoff4ch/INFO.:.* { json2nameValue($EVENT) }\
stat/sonoff4ch/RESULT:.* { json2nameValue($EVENT) }\
sonoff4ch:cmnd/sonoff4ch/POWER:.* POWER\
sonoff4ch:stat/sonoff4ch/POWER1:.* POWER1\
sonoff4ch:stat/sonoff4ch/POWER2:.* POWER2\
sonoff4ch:stat/sonoff4ch/POWER3:.* POWER3\
sonoff4ch:stat/sonoff4ch/POWER4:.* POWER4\
sonoff4ch:tele/sonoff4ch/UPTIME:.* { json2nameValue($EVENT) }
attr MQTT2_sonoff4ch room MQTT2_DEVICE
attr MQTT2_sonoff4ch setList POWER1:on,off cmnd/sonoff4ch/POWER1 $EVTPART1\
POWER2:on,off cmnd/sonoff4ch/POWER2 $EVTPART1\
POWER3:on,off cmnd/sonoff4ch/POWER3 $EVTPART1\
POWER4:on,off cmnd/sonoff4ch/POWER4 $EVTPART1
attr MQTT2_sonoff4ch stateFormat LWT\
1:POWER1\
2:POWER2\
3:POWER3\
4:POWER4\
<br>\
<a href="http://IPAddress" target="_blank">IPAddress</a>
attr MQTT2_sonoff4ch webCmd POWER1:POWER2:POWER3:POWER4

setstate MQTT2_sonoff4ch Online\
1:on\
2:off\
3:off\
4:on\
<br>\
<a href="http://192.168.178.186" target="_blank">192.168.178.186</a>

Evtl kann man das jetzt ja auch in den templates benutzen.
Entsprechend für die sonoff Dual
Gruß

Carlos
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 21 Februar 2019, 07:43:48
Dank dem neuen support für mehrere gleichzeitige devStateIcons in einem device von justme1968, sieht mein sonoff 4ch jetzt so aus:
Danke für die Info.
Habe eben eine angepaßte Fassung ins svn geschoben, erst mal nur für den 4-kanaligen. Eine kurze Rückmeldung wäre nett, ob das alles soweit paßt (auch mit den Leerzeichen, die ich für meine eigene Orientierung in dem file gerne so behalten würde). Wenn ja, erhät auch der Rest bei Gelegenheit eine "Renovierung" (da war auch was mit uptime, das ist jetzt im Basistemplate auch neu drin).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: carlos am 21 Februar 2019, 09:52:18
Hab es jetzt noch ein wenig abgeändert, Sieht jetzt so aus für meinen 4CH und Dual.
Aber das ist alles Geschmackssache.
Ich hatte mir vorher eine ähnliche Ansich mit readingsgroup gemacht.
Das ist jetzt aber alles nicht mehr nötig.
Man kann mit dem neuen devstateicon jede Menge readings mit rein nehmen.

Gruß
Carlos
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 21 Februar 2019, 09:58:59
Hab es jetzt noch ein wenig abgeändert,
Ähm, kannst du mir bitte erläutern, was das für das/die templates heißt? Funktioniert der im heutigen update enthaltene 4-er Code soweit, oder besteht Änderungsbedarf bzw. gibt es Wünsche oder Anregungen dazu?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: carlos am 21 Februar 2019, 10:55:11
Als initiales template ist das erst mal ok.
Ich kann es gerade nicht testen. Heute Abend dann.
Ich fürchte aber die Leerzeichen müssen raus.

Im stateformat könnte man halt noch beliebige Readings mit reinnehmen
Ich habe mir den link für die IP adresse und die Tasmota Version mit reingenommen.
Aber das kann ja dann jeder selbst für sich entscheiden was er da noch mit anzeigen will.

Gruß

Carlos
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 21 Februar 2019, 11:15:01
Danke für die vorläufige Rückmeldung.

Die IP-Adresse finde ich ok, wie es umgesetzt ist; es gab hier ja auch schon den Wunsch, das mit reinzunehmen, deswegen habe ich das in der Form auch ins template integriert (Version finde ich overdone). Wer die IP nicht mag, kann's ja löschen, und wer die Version braucht, hat ein Beispiel mit der IP...

Unklarheiten auf meiner Seite bzw. Anmerkungen:
- Das devStateIcon kann man ja auch zur Bedienung nutzen, oder? Macht dann die webCmd-Sache noch großen Sinn?
- Wenn, könnte man es noch aufhübschen wie beim Shelly4pro (attr DEVICE setList \  relay0:iconSwitch,on,li_wht_off,off,li_wht_on shellies/DEVNAME/relay/0/command $EVTPART1\), wobei ich hier vorschlagen würde, statt der "li_wht_.*"-Icons schlicht die on/off-Varianten zu nutzen.

 
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: carlos am 21 Februar 2019, 11:56:53
Ja, da gebe ich dir recht.
Deswegen als initiale Version finde das template gut so.
Und ja das devStateIcon kann man zur Bedienung nutzen, deshalb kann webcmd entfallen
Auch die on/off Variante als Icon ist mir persöhnlich ausreichend.

Wie schon gesagt als Standard Version ist das template so gut, wer mehr will kann das Device ja dann anpassen.
Wenn man die duals und basics die templates ähnlich aufbaut hätte man eine gute Lösung für die Sonoffs bzw. für die Tasmota MQTT2 devices.
Gruß

Carlos
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: carlos am 22 Februar 2019, 00:30:03
Hi,
Ich habe das template noch mal getestet.
Wie schon erwähnt müssen die Leerzeichen zumindest im stateformat raus.
Mit dieser Änderung sollte es funtionieren.
Gruß
Carlos
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 22 Februar 2019, 08:18:08
Moin,

habe eben die beiden geänderten Tasmota-templates noch ins svn geschoben (4-er ohne Leerzeichen, 2-er nach dem 4-er Muster). Wäre nett, wenn das jemand (carlos?) testen könnte, bevor das morgen in das update geht :D .

Ein screenshot sam zugehörigem List für's Wiki wäre auch noch nett, dann kommt das noch nach "device-Overview anpassen", als 2. (schaltbares) Beispiel für das neue Feature :) .

Gruß, Beta-User
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: carlos am 24 Februar 2019, 11:29:36
Hallo,
Ich habe das 2er noch mal getestet. Bei einem komplett leeren device ohne readings muss man DEVNAME noch abändern.
Ansonsten funktioniert das jetzt.
Sieht dann so aus:

Gruß
Carlos
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 24 Februar 2019, 16:28:19
Danke für die Rückmeldung!

Das mit DEVNAME ist klar, das leitet das template aus der readingList ab - ist die leer oder liefert aus anderen Gründen kein Ergebnis, wird nachgefragt...
Hättest du noch ein list zum 2-er?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: carlos am 24 Februar 2019, 16:38:43
Ja hier noch das list, habe mir aber das stateformat abgeändert:
Internals:
   CFGFN      /opt/fhem/fhem.mqtt2.cfg
   CID        sonoffdualR2
   DEF        sonoffdualR2
   DEVICETOPIC MQTT2_sonoffdualR2
   FUUID      5c455979-f33f-ffe7-1032-c86d551089617a3b
   IODev      m2s
   LASTInputDev m2s
   MSGCNT     129
   NAME       MQTT2_sonoffdualR2
   NR         729
   STATE      Online
<a href="http://XXX.XXX.XXX.XXX" target="_blank">sonoffdualR2-4159</a>
<br>
<b>Tasmota Revision:</b>
6.4.1.18(68c60c3-sonoff)
1:off
2:off
   TYPE       MQTT2_DEVICE
   m2s_MSGCNT 129
   m2s_TIME   2019-02-24 16:31:13
   .attraggr:
   .attrminint:
   OLDREADINGS:
   READINGS:
     2019-02-24 11:26:05   FallbackTopic   cmnd/sonoffdualR2_fb/
     2019-02-24 11:26:05   GroupTopic      sonoffs
     2019-02-24 11:26:05   Hostname        sonoffdualR2-4159
     2019-02-24 11:26:05   IPAddress       XXX.XXX.XXX.XXX
     2019-02-24 11:26:05   LWT             Online
     2019-02-24 16:31:13   LoadAvg         19
     2019-02-24 11:26:05   Module          Sonoff Dual R2
     2019-02-24 16:31:13   POWER1          off
     2019-02-24 16:31:13   POWER2          off
     2019-02-24 11:26:05   RestartReason   Software/System restart
     2019-02-24 11:12:35   SaveData        on
     2019-02-24 11:12:34   SetOption26     on
     2019-02-24 16:31:13   Sleep           50
     2019-02-24 16:31:13   SleepMode       Dynamic
     2019-02-24 11:12:33   StateText1      off
     2019-02-24 11:12:34   StateText2      on
     2019-02-24 11:12:34   StateText3      toggle
     2019-02-24 11:12:34   StateText4      hold
     2019-02-24 16:31:13   Time            2019-02-24T16:31:13
     2019-02-24 16:31:13   Uptime          0T05:05:14
     2019-02-24 16:31:13   Vcc             3.448
     2019-02-24 11:26:05   Version         6.4.1.18(68c60c3-sonoff)
     2019-02-24 11:26:05   WebServerMode   Admin
     2019-02-24 16:31:13   Wifi_AP         1
     2019-02-24 16:31:13   Wifi_BSSId      XX:XX:XX:XX:XX:XX
     2019-02-24 16:31:13   Wifi_Channel    1
     2019-02-24 16:31:13   Wifi_Downtime   0T00:00:04
     2019-02-24 16:31:13   Wifi_LinkCount  1
     2019-02-24 16:31:13   Wifi_RSSI       98
     2019-02-24 16:31:13   Wifi_SSId       XXX
Attributes:
   IODev      m2s
   alias      SonoffdualR2
   autocreate 0
   devStateIcon Online:10px-kreis-gruen@green Offline:10px-kreis-rot@red 1.on:on:POWER1+off 1.off:off:POWER1+on 2.on:on:POWER2+off 2.off:off:POWER2+on
   icon       hue_filled_outlet
   model      A_02a_tasmota_2ch_unified
   readingList tele/sonoffdualR2/LWT:.* LWT
  tele/sonoffdualR2/STATE:.* { json2nameValue($EVENT) }
  tele/sonoffdualR2/SENSOR:.* { json2nameValue($EVENT) }
  tele/sonoffdualR2/INFO.:.* { json2nameValue($EVENT) }
  stat/sonoffdualR2/RESULT:.* { json2nameValue($EVENT) }
  tele/sonoffdualR2/UPTIME:.* { json2nameValue($EVENT) }
  stat/sonoffdualR2/POWER1:.* POWER1
  stat/sonoffdualR2/POWER2:.* POWER2
   room       MQTT2_DEVICE
   setList    POWER1:on,off,toggle cmnd/sonoffdualR2/POWER1 $EVTPART1
  POWER2:on,off,toggle cmnd/sonoffdualR2/POWER2 $EVTPART1
   setStateList on off toggle
   stateFormat LWT
<a href="http://IPAddress" target="_blank">Hostname</a>
<br>
<b>Tasmota Revision:</b>
Version
1:POWER1
2:POWER2
   webCmd     POWER1:POWER2

Sieht bei mir jetzt so aus.
Gruß

Carlos
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 04 März 2019, 10:03:36
Kurze Info an eventuelle Mitleser hier:

Für das MQTT2_CLIENT-Basis-Bridge-template wäre m.E. eine grundlegende Änderung der bridgeRegexp sinnvoll. Ist ein spezielles Thema, daher dazu ein neuer Thread hier:
https://forum.fhem.de/index.php/topic,98126.0.html

Tester (und Rückmeldungen) wären dort willkommen ;) .

Ja hier noch das list, habe mir aber das stateformat abgeändert:
Im Prinzip: Danke.

Zwei Anmerkungen:
- Ich kann sowas dann in einer gegenüber dem template-Ergebnis abgeänderten Fassung nicht wirklich gut ins Wiki übertragen, da man dann zu viel erklären muß...
- (mehr an mich selbst: besser ist ein "list -r <device>", also das RAW-Format....)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 11 März 2019, 13:29:35
Die Frage wäre m.E. besser hier aufgehoben gewesen: https://forum.fhem.de/index.php/topic,94494.msg872200.html#msg872200 (bzw. es handelt sich ggf. sogar um eine ganz allgemeine Frage zum ganzen...)

Grundsätzlich gehört immer zusammen, was ab "name:" bis vor das nächste "name:" steht.
"desc:" ist das, was als Beschreibung bei Aufruf von ? erscheint.

Was mit Replace gemeint ist, kann ich nur raten:
Wenn man irgendeine Variable vorab mit Inhalt füllen will, der dann in den nachfolgenden Zeilen statt der Variable eingesetzt werden soll, macht man das mit "par: ...". Dabei ist die Syntax: VARIABLENNAME;Hinweistext, der in einem Dialogfeld zur Erstetzen im Aufruf erscheint, wenn die hinter dem nächsten Trenner (";") stehende Perl-Funktion "undef" zurückgibt. Wird was anderes als undef (oder vielleicht ""?) zurüchgeliefert, wird das direkt und ohne weitere Rückfrage übernommen.

Wenn das in der Form noch nicht weiterhilft, bitte in den anderen Thread ausweichen!

Bei Aufruf von ? bekommt man in der Kombinationsliste alle name: angezeigt, das ist klar.
Wähle ich ein Template aus erscheint das Anwendungsfenster siehe Bild im Anhang.

Im Anwendungsfenster findest du Replace, dort obendrüber hätte ich desc: erwartet. Ehrlich gesagt hab ich darauf noch nie geachtet und eigentlich mein ich ist mir eine Beschreibung bewusst nirgendwo bisher aufgefallen .Beschäftige mich zum ersten mal damit wegen dem angesprochenen IR-Template.

Das mit par: ist auch klar, das hab ich schon hinbekommen.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 11 März 2019, 13:44:14
Ah ok, dieses "Replace" war gemeint.

Das scheint aus dem allg. AttrTemplate-Code zu kommen und wird immer (nur) angezeigt, wenn mind. eine der par:-Anweisungen nicht aufgelöst werden kann, also undef zurückgibt.

Für das IR-template (gedanklich erst mal mit den 3 Anweisungen für on, off und volume_up) würde ich daher vorschlagen, einen Beispielcode in den Hinweistext aufzunehmen. Dann würde aus:
par:BASE_ID;BASE_ID typically is milight;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*ates/.*:, ? $1 : undef }ungetestet in etwa sowas:
par:ONCOMMAND;ONCOMMAND is the needed JSON-Code to be sent like '{"protocol": "NEC","bits": 32, "data": 551489775}' (without '');{ undef }
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Capu am 11 März 2019, 13:51:32
Mahlzeit zusammen,
mir ist grad noch ein kleiner Schönheitsfehler aufgefallen. In der Template-Datei steht bei den Devices L_08..L_11 die Description noch (halb)falsch drin.
Ein Flüchtigkeitsfehler der wahrscheinlich beim erstellen/abändern passiert ist...

L_08_ist:
desc: Temp/hum/hpa sensor via zigbee2mqtt <br>Tested with: Xiaomi Aqara RTCGQ11LM Human Motion SensorL_08_soll:
desc: Human motion sensor via zigbee2mqtt <br>Tested with: Xiaomi Aqara RTCGQ11LM Human Motion Sensor
L_09_ist:
desc: Temp/hum/hpa sensor via zigbee2mqtt <br>Tested with: Xiaomi Aqara DJT11LM Smart Motion SensorL_09_soll:
desc: Smart motion sensor via zigbee2mqtt <br>Tested with: Xiaomi Aqara DJT11LM Smart Motion Sensor
L_10_ist:
desc: Temp/hum/hpa sensor via zigbee2mqtt <br>Tested with: Xiaomi Aqara SJCGQ11LM Water Leak SensorL_10_soll:
desc: Water leak sensor via zigbee2mqtt <br>Tested with: Xiaomi Aqara SJCGQ11LM Water Leak Sensor
L_11_ist:
desc: Temp/hum/hpa sensor via zigbee2mqtt <br>Tested with: Xiaomi Aqara WXKG02LM 2btn Smart Light SwitchL_11_soll:
desc: Smart light switch 2btn via zigbee2mqtt <br>Tested with: Xiaomi Aqara WXKG02LM 2btn Smart Light Switch
Tut der Funktion keinen Abbruch. Nur etwas Kosmetik. :)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 11 März 2019, 14:01:40
ups....
Korrektur kommt. Werde allerdings dann wenn möglich auch gleich noch die neuen Filteroptionen einbauen: Rudi hat was gebastelt, dass man jeweils noch mehr/anders als bisher filtern kann. Dann erhält man zukünftig ggf. die meisten zigbee-templates nur noch angezeigt, wenn die CID auch zigbee_.* entspricht, entsprechend für milight, shelly....

Geht ggf. auch nicht auf einmal, und euer feedback wäre auch nicht schlecht :) .
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 11 März 2019, 17:55:33
"desc:" ist das, was als Beschreibung bei Aufruf von ? erscheint.
Jetzt   ;D, es war mir bisher noch nicht einmal der Gedanke gekommen ein set <MQTT2_DEVICE-NAME> attrTemplate ? auszuführen. ::)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 11 März 2019, 18:02:16
"desc:" ist das, was als Beschreibung bei Aufruf von ? erscheint.
Jetzt   ;D , es war mir bisher noch nicht einmal der Gedanke gekommen ein set <MQTT2_DEVICE-NAME> attrTemplate ? auszuführen. ::)
:o 8) ;D ;D ;D

Für was gebe ich mir eigentlich die Mühe, sowas ins Wiki zu schreiben bzw. warum packt Rudi sowas das in die commandref?!? (Mist, da fällt mir noch ein, dass das da ggf. noch fehlt und ich einen offenen Punkt habe...)

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 11 März 2019, 22:10:49
Werde allerdings dann wenn möglich auch gleich noch die neuen Filteroptionen einbauen

So, Filter sind ergänzt.

Bitte also nicht wundern, wenn die Liste der angezeigten attrTemplates jetzt deutlich kürzer ist als bisher!
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: ripperle am 12 März 2019, 20:00:42

So, Filter sind ergänzt.

Bitte also nicht wundern, wenn die Liste der angezeigten attrTemplates jetzt deutlich kürzer ist als bisher!


Wollte gerade nach nem Update ne neue Ikea Birne anlernen als ich schon Panik bekomme habe, warum auf einmal die templates weg sind..

Wo ist denn beschrieben wie das jetzt funktioniert mit dem Filter?

Ich lege bisher die mqtt2 Devices händisch an und setzte dann das entsprechende template mit device topic...

Auto create nutze ich nicht, oder muss man das jetzt nutzen  ??? :o

Gruß
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 12 März 2019, 20:17:39
Wo ist denn beschrieben wie das jetzt funktioniert mit dem Filter?
Gefiltert wird bei den zigbee-Devices nach CID. Die muß mit zigbee beginnen (und wird bei manuellem Anlegen durch eine weitere Angabe nach dem Device-TYPE MQTT2_DEVICE erzeugt).

Was jeweils relevant ist, hängt vom verwendeten Filter ab (=>Quellcode lesen...), bei den tasmotas z.B. muß ein readingList-Eintrag mit tele oder cmnd da sein; wo es ging, habe ich mit CID gearbeitet.

Einen entsprechenden Hinweis werde ich bei nächster Gelegenheit mit in das erste "template" aufnehmen.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: ripperle am 12 März 2019, 20:32:24
Gefiltert wird bei den zigbee-Devices nach CID. Die muß mit zigbee beginnen (und wird bei manuellem Anlegen durch eine weitere Angabe nach dem Device-TYPE MQTT2_DEVICE erzeugt).

Was jeweils relevant ist, hängt vom verwendeten Filter ab (=>Quellcode lesen...), bei den tasmotas z.B. muß ein readingList-Eintrag mit tele oder cmnd da sein; wo es ging, habe ich mit CID gearbeitet.

Einen entsprechenden Hinweis werde ich bei nächster Gelegenheit mit in das erste "template" aufnehmen.

Ähh hää  ;D

Hab mal ein Gerät angelegt Mit define test MQTT2_DEVICE zigbee...

Da kann ich trotzdem kein template wählen...

Und in welchem Quellcode soll ich nachschauen?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 12 März 2019, 20:53:23
Hab mal ein Gerät angelegt Mit define test MQTT2_DEVICE zigbee...
Da kann ich trotzdem kein template wählen...
Ähm, mit den Punkten? (Ging das?!?) Das könnte dann schon das Problem sein...
Nomalerweise (also bei Verwendung von autocreate und der bridge aus den templates) ist das sowas, was dann in der DEF landet: zigbee_0x90fd9ffffe0bcd51

Damit ging es jedenfalls eben bei mir mit aktuellem FHEM aus dem regulären update...

Zitat
Und in welchem Quellcode soll ich nachschauen?
in dem von ./FHEM/lib/AttrTemplate/mqtt2.template
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: ripperle am 12 März 2019, 21:09:13
Ähm, mit den Punkten? (Ging das?!?) Das könnte dann schon das Problem sein...
Nomalerweise (also bei Verwendung von autocreate und der bridge aus den templates) ist das sowas, was dann in der DEF landet: zigbee_0x90fd9ffffe0bcd51

Damit ging es jedenfalls eben bei mir mit aktuellem FHEM aus dem regulären update...
in dem von ./FHEM/lib/AttrTemplate/mqtt2.template

Nein ohne die Punkte... Aber also das hier oben eingegeben

define zigbee_test MQTT2_DEVICE zigbee
Eingegeben und dann kann man nur eine zigbee bridge auswählen (siehe Bild) ...

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 12 März 2019, 21:11:40
Ich habe gerade mitdefine test MQTT2_DEVICE zigbee...ein Geraet angelegt, und kriege jede Menge attrTemplate Moeglichkeiten.

@ripperle: ist dein FHEM aktuell? Konkret: hast du _heute_ update in FHEM ausgefuehrt?
@Beta-User: Punkte sind kein Problem, ist halt ein komisches CID.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: ripperle am 12 März 2019, 21:18:55
Gerade nochmal ein Update gemacht, da stand nothing to do... Dann nochmal ein Neustart von fhem und jetzt tauchen die templates auf! Seht komisch! :o
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 12 März 2019, 21:30:21
Gerade nochmal ein Update gemacht, da stand nothing to do... Dann nochmal ein Neustart von fhem und jetzt tauchen die templates auf! Seht komisch! :o
Sicher, dass du einen Neustart nach dem letzten update gemacht hattest?

@Rudi:
Danke für's Einbauen und Sorry für den Aufwand, der bis grade damit noch verbunden war.
Bin mal gespannt, wie viele Probleme damit noch aufschlagen, aber im Ergebnis finde ich das "Wegfiltern" von nicht passenden Detail-Templates mind. bei MQTT2 sinnvoll. Die templates an sich werden ja gerne angenommen, daher war das m.E. schon jetzt sehr unübersichtlich geworden.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: ripperle am 12 März 2019, 21:36:33
Also ich telefoniere hier parallel mit meinem Vater der das ganze bei seinem fhem Server auch machen will...

Hat auch soeben 2 mal ein Update mit anschließendem restart von fhem gemacht... Auch mal den Cache im Browser gelöscht.. Leider tauchen bei ihm immernoch nicht alle templates auf...

Irgendwie komisch  ???

EDIT:
KOMMANDO zurück! Es tut... Net sicher was wir falsch gemacht haben... Nochmal alles gelöscht, gesaved, und nochmal angelegt...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 15 März 2019, 19:17:46
Hallo Beta-User,

ein paar Fragen bleiben mir noch zu u.a. Template.

1. Ob nun für hier oder irgendwann mal woanders. Das Kommando besteht aus dem Befehl IRsend und den zugehörigen Parametern (bei hex, dec der JSON und bei raw einfach kommasepariert) aber getrennt durch ein Leerzeichen!
Ist es möglich mit der Parameterübergabe auch dieses Leerzeichen mitzugeben/durch ein Zeichen zu ersetzen  ?
So das der Anwender das ganze Kommando, nicht nur die zugehörigen Parameter, eintragen muss, also mit IRsend.
 
 2. Weshalb kommen noch keine INFO.* Readings rein und schlieslich die IP nicht angezeigt ? Den ESP hab ich mehrfach neu gestartet, hab mir das von A_04b_tasmota_4ch_unified_icon abgeschaut und auch getestet das klappt, nur bei dem IR-Template noch nicht, ich sehe den Fehler nicht ?
hat sich erledigt, topic war falsch angegeben

3. 
Zitat
... und am Ende Perl-Code. Gibt der undef zurück, wird der Parameter abgefragt, kann das template den Wert alleine ermitteln, wird er ohne Rückfrage verwendet.

 Komm ich jetzt nicht mit. Hab das mit dem Perl Code und undef so übernommen wie du im letzten Beispiel gezeigt hast trotzdem bekomme ich (without '') nach dem Nutzerhinweis angezeigt siehe Bild im Anhang.
Es passt aber alles, es wird alles so angelegt wie gewünscht, es hat aber auch zuvor ohne Meldung alles geklappt als ich den Perl Code und undef hinter dem Nutzerhinweis noch gar nicht stehen hatte

#tasmota device with Infrared-circuit
name:A_01d_tasmota_ir
desc:Demonstrates three options (dec, hex, raw) how to configure tasmota devices as IR remote control extension.<br><a href="https://forum.fhem.de/index.php/topic,67316.0.html">Forum Thread</a><br><a href=https://github.com/arendst/Sonoff-Tasmota/wiki/Commands#irremote">Tasmota IRremote Commands</a><br><a href="https://github.com/altelch/SonoffIR">Simple IR-circuit</a>
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
par:POWERCMD;needed command to be sent like in example dec '{"protocol":"NEC","bits":32,"data":551489775}' (without '');{ undef }
par:VOLUMEUPCMD;needed command to be sent like in example raw '0,926,844,958,832,1798,868,902,848,900,870,900,852,908,918,958,794,934,874,928,1738,934,856,1764' (without '');{ undef }
par:MULTIPLE1CMD;needed command to be sent like in example hex '{"Protocol":"NEC","Bits":32,"Data":0x8166817E}' (without '');{ undef }
par:MULTIPLE2CMD;needed command to be sent like in example hex '{"Protocol":"NEC","Bits":32,"Data":0x8166817E}' (without '');{ undef }
set DEVICE attrTemplate A_01d_tasmota_ir
attr DEVICE setList \
power:noArg cmnd/DEVNAME/IRsend POWERCMD\
volumeup:noArg cmnd/DEVNAME/IRsend VOLUMEUPCMD\
11:noArg cmnd/DEVNAME/Backlog IRsend MULTIPLE1CMD;delay 8;IRsend MULTIPLE2CMD
attr DEVICE readingList \
  tele/DEVNAME/INFO.:.* { json2nameValue($EVENT) }
attr DEVICE stateFormat state\
<br>\
<a href="http://IPAddress" target="_blank">IPAddress</a>
attr DEVICE event-on-change-reading .*
attr DEVICE icon IR
attr DEVICE model A_01d_tasmota_ir

Gruß

Thomas
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 17 März 2019, 07:48:05
Moin,

Danke für das IR-template, habe ich eben leicht abgeändert eingecheckt, Test wäre nett.
Zu den Fragen:
ad 1. Keine Ahnung wg. der Leerzeichen; evtl. wäre es einen Test wert, das durch die html-Entsprechung zu ersetzten? (Vielleicht versteht der Tasmota das; im Prinzip ist es ja dieselbe Payload wie bei Steuerung via html-command)

ad 3. undef ist einfach Perl-mäßig "nicht vorhanden"; von daher war das vermutlich "overdone", was ich geschrieben habe... Das template ist jetzt  ohne das {undef} eingecheckt (das war die zu testende Änderung).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 17 März 2019, 12:52:23
Hallo Beta-User,

auf einem jungfräulichen aktuellen FHEM hab ich jetzt einfach mal einen MQTT2_CLIENT definiert, auf complex gestellt  und beobachtet wie folgende Devices angelegt:

MQTT2_ebusd
MQTT2_ebusd_700
MQTT2_ebusd_bai
MQTT2_myMQTT2CLIENT

Bisher war es so das man auf das Sammeldevice MQTT2_myMQTT2CLIENT A_00_MQTT2_CLIENT_general_bridge mit autocreate 1 anwendete und die Geräte des Sammeldevice damit vereinzelt wurden. Wähle ich hier bei dem neuen System A_00_MQTT2_CLIENT_general_bridge aus passiert nichts, das model wird nicht übernommen, kein BridgeRegexp Attribute angelegt. Wo ist mein Denkfehler, hab ich die BridgeRegexp-Änderungen die du die Tage vorgenommen nicht richtig verstanden und das vereinzeln der Geräte geht nur noch von Hand und die General-Bridge soll gar nicht mehr verwendet werden ?

Gruß

Thomas
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 17 März 2019, 15:25:32
Hallo Thomas,
da scheint irgendwas schief zu sein. Was nutzt du als MQTT-Server? Läuft da im Hintergrund im selben FHEM ein MQTT2_SERVER (mit aktiviertem autocreate)? Darauf deutet es jedenfalls hin, dass da gleich mehrere Ebus-Devices angelegt werden...

Grundsätzlich sollte man neuerdings nicht mehr das Sammeldevice als Basis für die GeneralBridge nehmen, sondern eine Kopie und vor Anwendung des template die CID ändern (sollte auch so in den Hinweisen stehen, siehe auch den Thread zu dem speziellen template).


Zu dem IR-Dingens noch:

Evtl. kannst du noch einen setList-Eintrag generieren, der dann $EVTPART1 bis 3 (?) nutzt und die freie Eingabe von Protokoll, Bits und Data zuläßt (wäre dann ein Textfeld, alle Eingaben nur durch Leerzeichen getrennt. Damit könnte man dann das remotecontrol-Modul nutzen, ähnlich wie im Wiki beschrieben (der Artikel mit der speziellen firmware);
Wenn das klappt, wäre das m.E. sehr cool...

Wenn du da weitere Hinweise brauchst: ggf. neuen Thread aufmachen, hier verlinken.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 17 März 2019, 16:25:12
Hallo Thomas,
da scheint irgendwas schief zu sein. Was nutzt du als MQTT-Server? Läuft da im Hintergrund im selben FHEM ein MQTT2_SERVER (mit aktiviertem autocreate)? Darauf deutet es jedenfalls hin, dass da gleich mehrere Ebus-Devices angelegt werden...


Auf meinem Haupt-FHEM-Server läuft wie die ganze Zeit schon Mosquitto, deshalb nutze ich dort ja MQTT2_Client.
Wie gesagt auf dem neuen Test-System hab ich nichts weiter definiert ausser dem MQTT2_Client mit der IP:Port des Hauptserver.
Setze ich diesen auf complex werden die erwähnten Geräte automatisch angelegt, deshalb meine Frage ob das so gedacht war.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 17 März 2019, 17:19:15
Falls das was bringt, anbei ein verbose 5 Log des MQTT2_Client nachdem ich ihn von autocreate no auf complex gestellt habe und alle zuvor angelegten Geräte wieder gelöscht habe.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 18 März 2019, 07:36:19
Wenn du von einem "jungfräulichen" FHEM sprichst, bedeutet das wirklich, dass es noch nie irgendwelche MQTT2-Geräte gab?

Ich hatte ähnliche Feststellungen auf dem einen oder anderen Testsystem, aber das lag (außer einem versehenltich parallel laufendem MQTT2_SERVER) in der Regel daran, dass ich zwar alles gelöscht hatte, aber dann FHEM nicht wieder neu gestartet. In solchen Fällen kann es scheinbar sein, dass die bridgeRegexp FHEM-intern noch gespeichert ist (die wird in einen hash gelesen).

Was (nur) hilft, wenn man auf einem "bereits genutzten System" wirklich "jungfäulich" sein will, ist autocreate am IO auszuschalten, dann alles zu löschen, save, FHEM neu starten, dann autocreate wieder an.

War es evtl. das bei dir? (andernfalls muß ich wirklich intensiver das log ansehen bzw. dann sollte das Rudi wissen...)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 18 März 2019, 12:41:27

Was (nur) hilft, wenn man auf einem "bereits genutzten System" wirklich "jungfäulich" sein will, ist autocreate am IO auszuschalten, dann alles zu löschen, save, FHEM neu starten, dann autocreate wieder an.

War es evtl. das bei dir? (andernfalls muß ich wirklich intensiver das log ansehen bzw. dann sollte das Rudi wissen...)

Danke, einen restart hatte ich nach ein / aus schalten von autocreate und löschen der Devices nicht gemacht, mit restart wird nur das eine Sammeldevice MQTT2_myMQTT2CLIENT angelegt.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 18 März 2019, 12:57:48
...nachdem ich vorhin noch im zigbee-Thread ein Hilfsmittel zur Prüfung meiner These erhalten habe, dass intern was nicht ganz korrekt aktualisiertes verwendet wird, war ich fast sicher, dass das die Ursache war.

Danke für die Rückmeldung!

Ergänzend:
Bitte daran denken, für den "splitter", eine Kopie des "Sammeldevices" zu nehmen und erst mal die CID zu ändern.


Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 18 März 2019, 13:18:32
Zitat
Ergänzend:
Bitte daran denken, für den "splitter", eine Kopie des "Sammeldevices" zu nehmen und erst mal die CID zu ändern
.

Ich habs jetzt begriffen  :P, beides, das mit dem restart und der CID sollte meiner Meinung nach hier (https://wiki.fhem.de/wiki/MQTT2_CLIENT) Erwähnung finden.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 18 März 2019, 13:40:51
Ich habs jetzt begriffen  :P , beides, das mit dem restart und der CID sollte meiner Meinung nach hier (https://wiki.fhem.de/wiki/MQTT2_CLIENT) Erwähnung finden.
>:( >:( >:( >:( >:( :-*
Jetzt mache ich mir in den wenigen Tagen, in denen ich das "Problem" kenne, schon die Mühe,
a) eine hoffentlich nachvollziehbare Anleitung in das template zu schreiben und hier im Forum zu sensibilisieren und
b) Rudi eine halbwegs sinnvolle Darstellung zu liefern, was für Probleme mit Änderungen der bridgeRegexp verbunden sein könnten,

und du als (ausdrücklich darauf hingewiesener Tester bist "unzufrieden", weil es noch nicht im Wiki steht, ich fasse es nicht  ;D ;D ;D ;D ;D ...

Jedenfalls Danke für die Erinnerung, ist mir schon klar, dass da im Wiki noch ein Punkt ist (die ebus-Anleitung in den Praxisbeispielen wäre auch noch weiter zu kürzen, btw ;) ).

Aber: Eile mit Weile, und vielleicht findet sich ja auch jemand anderes, der das Problem verstanden hat und das in vertändlicher Form ins Wiki bringen kann (wenn ggf. der Punkt von Rudi auch gefixt ist, macht ja keinen Sinn, Würgarounds darzustellen (Neustart), wenn das Problem nicht mehr exisitert)...

Du darfst übrigens auch gerne selbst Hand anlegen :P .
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: wk2000 am 25 März 2019, 18:12:39
Moin,

ich versuche gerade meine Selbstbau-Bastel-ESP-8266's auf Tasmota umzustellen. Die sind hauptsächlich als LED Controller (über PWM) im Einsatz. Jeder Controller steuert momentan 3 LED-Stripes (über Mosfets).

Nun die Frage:

Ich hätte gerne ein Device, das in etwa so aussieht, wie die von den Tradfri/Hue Bulbs. Also mit Slider.
Und am Besten für jeden Stripe ein eigenes Device.

Für den Anfang fände ich es aber schon klasse, wenn ich überhaupt mal einen Stripe Dimmen könnte, und nicht nur On Off.

gibts da irgend einen Trick / Template?

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 25 März 2019, 18:23:53
Bau A_17a_shelly2rgbw_4w_split um ;) . Was sledge da gebastelt hatte, dürfte schon recht nah an deinen Anforderungen liegen (4 dimmbare weiß-Kanäle).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: wk2000 am 25 März 2019, 18:45:52
Bau A_17a_shelly2rgbw_4w_split um ;) . Was sledge da gebastelt hatte, dürfte schon recht nah an deinen Anforderungen liegen (4 dimmbare weiß-Kanäle).

öhm, das klinkt ziemlich gut.

Vielleicht doofe Frage, wo finde ich das? Die Forumssuche spuckt nix aus :o und bei den Standard Templates ist es ja auch nicht dabei???
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 25 März 2019, 21:52:02
öhm, das klinkt ziemlich gut.

Vielleicht doofe Frage, wo finde ich das? Die Forumssuche spuckt nix aus :o und bei den Standard Templates ist es ja auch nicht dabei???
Ist in der template-file schon drin, aber man sieht den großen Teil der templates in der Regel nicht, die für andere firmwares usw. sind.

Ansonsten steht hier, wo die template-file zu suchen ist und wie ggf. eigene templates gebaut werden können:
https://forum.fhem.de/index.php/topic,94495.msg872201.html#msg872201
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: SirUli am 03 Mai 2019, 13:53:17
Hi Beta-User,

im Template L_01_zigbee2mqtt_bridge hat sich ein Fehler eingeschlichen. Nach
y_device_setting:textField zigbee2mqtt/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}}fehlt der abschließende \ sodass die weiteren Zeilen nicht ausgeführt werden. Sollte also so aussehen:
y_device_setting:textField zigbee2mqtt/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}}\Vielleicht kannst du das nachliefern? Auf "x_bind:textField" meint er sonst dass das unknown sei ;)

Danke im Voraus!
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 04 Mai 2019, 11:34:58
im Template L_01_zigbee2mqtt_bridge hat sich ein Fehler eingeschlichen.
Thx für den Hinweis, ist ab morgen korrekt im update ::) .
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 07 Mai 2019, 19:20:42
Anregung an mich selbst: die Tasmota-readingList-Auswertung tolerant für "populäre" Änderungen der topic-Struktur bei tasmota machen.

Umsetzung: Ab morgen via update verfügbar, benötigt wird ein vorhandenes LWT-Reading, das aber nach meiner Kenntnis stetig erneuert wird, also zeitnah via autocreate vorhanden sein sollte. Ich konnte das allerdings nur grob austesten, kann sein, dass mir beim Ausrollen über alle templates kleinere Fehler passiert sind oder die regex doch nicht paßt...

Bei der Gelegenheit habe ich den rf mal aufgenommen, die Sendeseite ist da aber noch unvollständig.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: DasQ am 08 Mai 2019, 17:03:57
also das mit dem milight_hub template klappt irgendwie nicht. für den milight hub ist doch des X_01_esp_milight_hub_bridge template?

ich hab kein plan wo du die IP her hast, oder den status. bei mir zeigts beides nicht an da der client diese infos garnicht liefert.
auch ist denk ich noch ein denkfehler drin. Lösch ich den hub, habe aber noch mi devices, erzeugts die readings nicht mehr für die existrierenden devices.

lösch ich dann die devices, kommen auch die readings wieder.
aber dann erstellts mir nicht mehr die devices.

Internals:
   CFGFN     
   CID        milight_hub_10693013
   DEF        milight_hub_10693013
   DEVICETOPIC milight_hub
   FUUID      5cd2ea5e-f33f-9f3d-83d1-3e61744999c5edf8
   IODev      MQTT2_Broker
   LASTInputDev MQTT2_Broker
   MQTT2_Broker_MSGCNT 79
   MQTT2_Broker_TIME 2019-05-08 16:54:03
   MSGCNT     79
   NAME       milight_hub
   NR         321
   STATE      <a href="http://ip_address" target="_blank">
OFF
</a>Version:
version
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-05-08 16:54:00   brightness      105
     2019-05-08 16:54:00   bulb_mode       color
     2019-05-08 16:53:51   color_b         255
     2019-05-08 16:53:51   color_g         255
     2019-05-08 16:53:51   color_r         255
     2019-05-08 16:53:51   color_temp      296
     2019-05-08 16:54:00   hue             103
     2019-05-08 16:53:51   kelvin          66
     2019-05-08 16:54:00   level           41
     2019-05-08 16:54:00   saturation      71
     2019-05-08 16:54:03   state           OFF
     2019-05-08 16:54:00   status          OFF
Attributes:
   IODev      MQTT2_Broker
   autocreate 1
   bridgeRegexp milight_hub_10693013:milight/[^/]*at[^/]+[/]/(0x....)/.*/([0-4])?.*:.* "milight_$1_$2"
   devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
   model      X_01_esp_milight_hub_bridge
   readingList milight_hub_10693013:milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/2:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/states/0x5D02/rgb_cct/2:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/3:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/states/0x5D02/rgb_cct/3:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/4:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/states/0x5D02/rgb_cct/4:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/1:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/states/0x5D02/rgb_cct/1:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/updates/0x248C/rgb_cct/3:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/updates/0x248C/rgb_cct/4:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setStateList on off
   stateFormat <a href="http://ip_address" target="_blank">
status
</a>Version:
version
   verbose    5

defmod milight_hub MQTT2_DEVICE milight_hub_10693013
attr milight_hub IODev MQTT2_Broker
attr milight_hub autocreate 1
attr milight_hub bridgeRegexp milight_hub_10693013:milight/[^/]*at[^/]+[/]/(0x....)/.*/([0-4])?.*:.* "milight_$1_$2"
attr milight_hub devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr milight_hub model X_01_esp_milight_hub_bridge
attr milight_hub readingList milight_hub_10693013:milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/2:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/states/0x5D02/rgb_cct/2:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/3:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/states/0x5D02/rgb_cct/3:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/4:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/states/0x5D02/rgb_cct/4:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/1:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/states/0x5D02/rgb_cct/1:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/updates/0x248C/rgb_cct/3:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/updates/0x248C/rgb_cct/4:.* { json2nameValue($EVENT) }
attr milight_hub room MQTT2_DEVICE
attr milight_hub setStateList on off
attr milight_hub stateFormat <a href="http://ip_address" target="_blank">\
status\
</a>Version: \
version
attr milight_hub verbose 5

setstate milight_hub <a href="http://ip_address" target="_blank">\
OFF\
</a>Version: \
version
setstate milight_hub 2019-05-08 16:54:00 brightness 105
setstate milight_hub 2019-05-08 16:54:00 bulb_mode color
setstate milight_hub 2019-05-08 16:53:51 color_b 255
setstate milight_hub 2019-05-08 16:53:51 color_g 255
setstate milight_hub 2019-05-08 16:53:51 color_r 255
setstate milight_hub 2019-05-08 16:53:51 color_temp 296
setstate milight_hub 2019-05-08 16:54:00 hue 103
setstate milight_hub 2019-05-08 16:53:51 kelvin 66
setstate milight_hub 2019-05-08 16:54:00 level 41
setstate milight_hub 2019-05-08 16:54:00 saturation 71
setstate milight_hub 2019-05-08 16:54:03 state OFF
setstate milight_hub 2019-05-08 16:54:00 status OFF


bin ich jetzt vollenz aufm holzweg?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 08 Mai 2019, 17:29:53
Der Hub liefert die mit der aktuellen dev-Version (1.9.x) :) .
Aber außer dass die Anzeige "kaputt" ist, sollte das klappen; ansonsten kannst du ja nur stateFormat löschen, nicht gleich die ganze bridge.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: DasQ am 08 Mai 2019, 19:11:49
wie gesagt, nach dem hub und dem template werden keine blubs angelegt

2019.05.08 19:10:10 4: MQTT2_Broker_192.168.1.163_49153 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/0:{"saturation":9}
2019.05.08 19:10:10 5: MQTT2_Broker: dispatch autocreate=simple\000milight_hub_10693013\000milight/updates/0x5D02/rgb_cct/0\000{"saturation":9}
2019.05.08 19:10:10 5: PUBLISH: 02(0) milight/updates/0x5D02/rgb_cct/0{"saturation":4}
2019.05.08 19:10:10 4: MQTT2_Broker_192.168.1.163_49153 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/0:{"saturation":4}
2019.05.08 19:10:10 5: MQTT2_Broker: dispatch autocreate=simple\000milight_hub_10693013\000milight/updates/0x5D02/rgb_cct/0\000{"saturation":4}
2019.05.08 19:10:11 5: PUBLISH: 02(0) milight/updates/0x5D02/rgb_cct/0{"saturation":1}
2019.05.08 19:10:11 4: MQTT2_Broker_192.168.1.163_49153 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/0:{"saturation":1}
2019.05.08 19:10:11 5: MQTT2_Broker: dispatch autocreate=simple\000milight_hub_10693013\000milight/updates/0x5D02/rgb_cct/0\000{"saturation":1}
2019.05.08 19:10:11 5: PUBLISH: 04(0) milight/updates/0x5D02/rgb_cct/0{"color_temp":320}
2019.05.08 19:10:11 4: MQTT2_Broker_192.168.1.163_49153 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/0:{"color_temp":320}
2019.05.08 19:10:11 5: MQTT2_Broker: dispatch autocreate=simple\000milight_hub_10693013\000milight/updates/0x5D02/rgb_cct/0\000{"color_temp":320}
2019.05.08 19:10:11 5: PUBLISH: 04(0) milight/updates/0x5D02/rgb_cct/0{"color_temp":262}
2019.05.08 19:10:11 4: MQTT2_Broker_192.168.1.163_49153 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/0:{"color_temp":262}
2019.05.08 19:10:11 5: MQTT2_Broker: dispatch autocreate=simple\000milight_hub_10693013\000milight/updates/0x5D02/rgb_cct/0\000{"color_temp":262}
2019.05.08 19:10:11 5: PUBLISH: 04(0) milight/updates/0x5D02/rgb_cct/0{"color_temp":257}
2019.05.08 19:10:11 4: MQTT2_Broker_192.168.1.163_49153 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/0:{"color_temp":257}
2019.05.08 19:10:11 5: MQTT2_Broker: dispatch autocreate=simple\000milight_hub_10693013\000milight/updates/0x5D02/rgb_cct/0\000{"color_temp":257}
2019.05.08 19:10:11 5: PINGREQ: (192)(0)
2019.05.08 19:10:11 4: MQTT2_Broker_192.168.1.162_49207 ESP_5Vrelais PINGREQ
2019.05.08 19:10:11 5: PUBLISH: 04(0) milight/updates/0x5D02/rgb_cct/0{"color_temp":253}
2019.05.08 19:10:11 4: MQTT2_Broker_192.168.1.163_49153 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/0:{"color_temp":253}
2019.05.08 19:10:11 5: MQTT2_Broker: dispatch autocreate=simple\000milight_hub_10693013\000milight/updates/0x5D02/rgb_cct/0\000{"color_temp":253}
2019.05.08 19:10:11 5: PUBLISH: 04(0) milight/updates/0x5D02/rgb_cct/0{"color_temp":240}
2019.05.08 19:10:11 4: MQTT2_Broker_192.168.1.163_49153 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/0:{"color_temp":240}
2019.05.08 19:10:11 5: MQTT2_Broker: dispatch autocreate=simple\000milight_hub_10693013\000milight/updates/0x5D02/rgb_cct/0\000{"color_temp":240}
2019.05.08 19:10:11 5: PUBLISH: 04(0) milight/updates/0x5D02/rgb_cct/0{"color_temp":235}
2019.05.08 19:10:11 4: MQTT2_Broker_192.168.1.163_49153 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/0:{"color_temp":235}
2019.05.08 19:10:11 5: MQTT2_Broker: dispatch autocreate=simple\000milight_hub_10693013\000milight/updates/0x5D02/rgb_cct/0\000{"color_temp":235}
2019.05.08 19:10:12 5: PUBLISH: 04(0) milight/updates/0x5D02/rgb_cct/0{"color_temp":220}
2019.05.08 19:10:12 4: MQTT2_Broker_192.168.1.163_49153 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/0:{"color_temp":220}
2019.05.08 19:10:12 5: MQTT2_Broker: dispatch autocreate=simple\000milight_hub_10693013\000milight/updates/0x5D02/rgb_cct/0\000{"color_temp":220}
2019.05.08 19:10:12 5: PUBLISH: 04(0) milight/updates/0x5D02/rgb_cct/0{"color_temp":220}
2019.05.08 19:10:12 4: MQTT2_Broker_192.168.1.163_49153 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/0:{"color_temp":220}
2019.05.08 19:10:12 5: MQTT2_Broker: dispatch autocreate=simple\000milight_hub_10693013\000milight/updates/0x5D02/rgb_cct/0\000{"color_temp":220}

mir schaut das topic auch arg eigenartig aus

************************edit*********************

mit dem alten regex legt er wieder die lampen an ...
attr Milight_hub bridgeRegexp milight_hub_10693013:milight/states/(0x....)/.*/([0-4])?.*:.* "milight_$1_$2"
2019.05.08 19:20:27 4: MQTT2_Broker_192.168.1.163_49154 milight-hub-10693013 PUBLISH milight/states/0x5D02/rgb_cct/4:{"state":"OFF","status":"OFF","brightness":105,"level":41,"hue":103,"saturation":100,"color":{},"bulb_mode":"color"}
2019.05.08 19:20:27 5: MQTT2_Broker: dispatch autocreate=simple\000milight_hub_10693013\000milight/states/0x5D02/rgb_cct/4\000{"state":"OFF","status":"OFF","brightness":105,"level":41,"hue":103,"saturation":100,"color":{},"bulb_mode":"color"}
2019.05.08 19:20:27 5: PUBLISH: 01(0) milight/updates/0x5D02/rgb_cct/4{"state":"OFF"}
2019.05.08 19:20:27 4: MQTT2_Broker_192.168.1.163_49154 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/4:{"state":"OFF"}
2019.05.08 19:20:27 5: MQTT2_Broker: dispatch autocreate=simple\000milight_hub_10693013\000milight/updates/0x5D02/rgb_cct/4\000{"state":"OFF"}
2019.05.08 19:20:27 5: PUBLISH: 0:(0) milight/updates/0x5D02/rgb_cct/4{"command":"night_mode"}
2019.05.08 19:20:27 4: MQTT2_Broker_192.168.1.163_49154 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/4:{"command":"night_mode"}
2019.05.08 19:20:27 5: MQTT2_Broker: dispatch autocreate=simple\000milight_hub_10693013\000milight/updates/0x5D02/rgb_cct/4\000{"command":"night_mode"}
2019.05.08 19:20:27 5: PUBLISH: 1(185)(1)(0)(31)milight/states/0x5D02/rgb_cct/4{"state":"OFF","status":"OFF","brightness":105,"level":41,"bulb_mode":"night","color":{"r":255,"g":255,"b":255},"effect":"night_mode","device_id":23810}
2019.05.08 19:20:27 4: MQTT2_Broker_192.168.1.163_49154 milight-hub-10693013 PUBLISH milight/states/0x5D02/rgb_cct/4:{"state":"OFF","status":"OFF","brightness":105,"level":41,"bulb_mode":"night","color":{"r":255,"g":255,"b":255},"effect":"night_mode","device_id":23810}
2019.05.08 19:20:27 5: MQTT2_Broker: dispatch autocreate=simple\000milight_hub_10693013\000milight/states/0x5D02/rgb_cct/4\000{"state":"OFF","status":"OFF","brightness":105,"level":41,"bulb_mode":"night","color":{"r":255,"g":255,"b":255},"effect":"night_mode","device_id":23810}
2019.05.08 19:20:28 5: PUBLISH: 0:(0) milight/updates/0x5D02/rgb_cct/4{"command":"night_mode"}
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 09 Mai 2019, 07:35:57
Bei der Neufassung (weil manche nur die state, nicht aber die states-Topics hatten) ist mir ein "/" zu viel in die bridgeRegexp reingeraten... Jetzt sollte es wieder passen. Danke für den Hinweis!
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: DasQ am 09 Mai 2019, 09:17:19
klappt top!

du ich versuch mich gerade an die bunten devstateicons. grundsätzlich ein nettes feature, nur verhält sich extrem widerspenstig.
in den milights gibts ja die gruppe "all" und da wills partu nicht funktionieren. das liegt daran das all nicht die hex werte erzeugt.

auch verhält sich die steuerung aus all etwas eigenartig, da es an z.b. gruppe 1 dann nicht den farbwert umstellt.

ich weis doof zu erklären , also nagel mich da jetzt nicht auf wortfetzen oder begrifflichkeiten von mir fest, ich versuchs nur halbwechs verständig zu erklären. aber man kanns auf den screenshot ganz gut erkennen.

vielleicht hast ja noch ne idee oder nenn tip. bzw. kann man nicht auf andere farbcodierungen wechseln? am liebsten hue



******************edit***************************

Hast du evtl. in dem anderen Thread überlesen: Kann er seit neuestem sehr wohl, https://github.com/sidoh/esp8266_milight_hub/releases/tag/1.9.0-rc.5 (https://github.com/sidoh/esp8266_milight_hub/releases/tag/1.9.0-rc.5) :P . Gerne nehme ich einen Vorschlag für ein Comment-Attribut entgegen, wie man das konfigurieren muß ;) .
Seit RC3 (?) ist auch das Group-Handling verbessert, kann sein, dass das schon dein Problem aus dem allgemeinen "template-Thread" löst (https://github.com/sidoh/esp8266_milight_hub/releases/tag/1.9.0-dev4)..

[erledigt]

Siehe Screenshot
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: KölnSolar am 24 Mai 2019, 11:28:01
Hi Beta,
ich bin mir nicht sicher, ob es wirklich an dem template liegt oder ich nur ein Symptom gelöst habe, da ich mich mit dem ganzen "oberflächengedöns" wenig auskenne.  :'(

Zum Verständnis die Historie:: Ich hatte tint-bulbs in mein System integriert und dazu das mqtt2-template genutzt. Funktionierte auch alles bestens. Dann hatte ich nach einem update permanente 2019.05.20 15:10:18 1: PERL WARNING: Use of uninitialized value $n in hash element at fhem.pl line 4413, <GEN38> line 2858. im Log. Hab dann stacktrace angeschmissen und bekam 2019.05.23 07:54:10 1: PERL WARNING: Use of uninitialized value $n in hash element at fhem.pl line 4445.
2019.05.23 07:54:10 1: stacktrace:
2019.05.23 07:54:10 1:     main::__ANON__                      called by fhem.pl (4445)
2019.05.23 07:54:10 1:     main::ReadingsVal                   called by ./FHEM/10_MQTT2_DEVICE.pm (736)
2019.05.23 07:54:10 1:     main::zigbee2mqtt_devStateIcon255   called by (eval 656537) (1)
2019.05.23 07:54:10 1:     (eval)                              called by ./FHEM/01_FHEMWEB.pm (2864)
2019.05.23 07:54:10 1:     main::FW_dev2image                  called by ./FHEM/01_FHEMWEB.pm (3187)
2019.05.23 07:54:10 1:     main::FW_devState                   called by ./FHEM/01_FHEMWEB.pm (1785)
2019.05.23 07:54:10 1:     main::FW_makeDeviceLine             called by ./FHEM/01_FHEMWEB.pm (1958)
2019.05.23 07:54:10 1:     main::FW_showRoom                   called by ./FHEM/01_FHEMWEB.pm (1117)
2019.05.23 07:54:10 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (567)
2019.05.23 07:54:10 1:     main::FW_Read                       called by fhem.pl (3749)
2019.05.23 07:54:10 1:     main::CallFn                        called by fhem.pl (748)
Dann hab ich mir meine zigbee-devices näher angesehen und fand attr Deckenlamped devStateIcon {zigbee2mqtt_devStateIcon255($name)}
.
.
attr Deckenlamped stateFormat {lc ReadingsVal("$name","state",0)}
Das kam mir etwas komisch vor und ich habe aufattr Deckenlamped stateFormat {lc ReadingsVal($name,"state",0)}geändert. Funktioniert weiterhin, aber nun ohne Warning.

Im template sind ja einige ReadingsVal mit doppelten Anführungszeichen.
Bug oder hab ich nur irgendeine seltsame Konstellation, dass das scheinbar nicht richtig auflöst ?  :-\ :-[
Grüße Markus
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 24 Mai 2019, 11:46:35
Hallo Markus,

Danke für den Hinweis, die "" kommen bei Gelegenheit raus...
Lerne (leider oder zum Glück...) fast jeden Tag noch was dazu :) .

Btw.: für farbige?) tints sollte mitlerweile auch ein farbiges devStateIcon gehen, (das optional auch noch den SetExtensions-Status mit auswirft).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: KölnSolar am 26 Mai 2019, 20:12:54
Zitat
Lerne (leider oder zum Glück...) fast jeden Tag noch was dazu  .
Wem sagst Du das.  ;D
Das war es dann aber doch nicht bzw. nicht allein.  ::) Frag besser nicht. "Plötzlich"  ??? waren die warnings wieder da.

Das "Problem" ist, dass Du die Funktionsparameter erweitert hast. zigbee2mqtt_devStateIcon255($;$$)Wenn nun die Attribute nicht angepasst werden, ist natürlich ab dem 2. Parameter jeder Parameter undefined und damit fällt my $rgb = ReadingsVal($name, $rgbReadingName, "FFFFFF");
auf die Nase.

OT: von Perl-Newbie zu Perl-Newbie: Was macht das Semikolon bei den Funktionsparametern ? :-[
Grüße Markus
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 26 Mai 2019, 21:49:12
Erster Parameter pflicht, zwei Weitere optional.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: DasQ am 26 Mai 2019, 22:02:26
find ich ja super intressant, wird hier aber niemals einer wieder finden ... schade
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 27 Mai 2019, 09:25:35
So, seit eben sind die "$name"-Angaben im svn ohne Hochkommata.

Soweit ich das überflogen habe, ist immer da, wo es relevant ist auch das Attribut "setExtensionsEvent" für die lange Form des devStateIcons gesetzt, für die templates sollte das also passen. Die Hinweise im anderen Thread sind jetzt entsprechend aufgebohrt.

[zu OT]
Nennt sich prototypes und steht als Stichwort seit neuestem auch im Wiki bei "99_myUtils..." (@DasQ: wenn du also weißt, nach was du suchst, wirst du es ggf. auch - als Stichowrt - wiederfinden). Das Wiki (oder auch das Forum) ist aber nicht dazu da, Perl-Grundlagen zu vermitteln. Mehr als das Stichworte geliefert werden können, unter denen man dann in der "richtigen" Doku (perldoc u.a.) nachsehen kann, sollte man auch langfristig nicht erwarten.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: DasQ am 27 Mai 2019, 13:17:32
@Beta-User thx für den hinweis! wenn´s im wiki ist, wirds auch irgendwie wiedergefunden, hier im forum hatte/habe ich so meine bedenken. Aber egal, ich werd immer mal wieder so "fussnoten" verfassen wenn ich denk, das könnten andere auch interssieren. im dümsten fall kommt ein neues system dabei raus das diese daten/informationen "automatisch" als intressant kennzeichnet. bin immer noch der meinung, das man die "gefällt mir" "informativ" und "zustimmen" funktion weiter verwerten sollte.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Tobias am 15 Juli 2019, 09:01:49
GIbt es schon ein Template für ein Xiaomi FlowerSens?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 15 Juli 2019, 09:37:10
GIbt es schon ein Template für ein Xiaomi FlowerSens?
Scheinbar nicht...
Kannst gerne ein list einstellen. Beschränkt sich das - im Prinzip - auf ein passendes stateFormat oder ist da mehr zu beachten?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Tobias am 15 Juli 2019, 14:02:18
Das sind BLE Devices. Man benötigt also eine Generic_Bridge (zb. auf dem Raspi Zero W) sowie MQTT2_Devices (FHEM Server)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 15 Juli 2019, 14:19:01
Hmm, das klingt "speziell" und ist vermutlich auch kein Thema, das sich leicht durch attrTemplate@mqtt2 lösen ließe...

Habe ich das richtig verstanden: Es gibt ein "Neben-FHEM", in dem die BLE-Devices "leben". Diese (bzw. deren Readings) werden per MQTT_GENERIC_BRIDGE an das "Haupt-FHEM" weitergegeben, auf dem ein MQTT2_SERVER läuft und sollen dann dort wieder nicht in einem Großdevice (TYPE=MQTT2_DEVICE) "enden", sondern wieder "vereinzelt" werden?

Dann würde ich folgendes Konzept vorschlagen: Du erstellst (auf dem Haupt-FHEM) eine "eigene" "Bridge", also ein MQTT2_DEVICE mit einer bridgeRegexp, das die eingehenden Messages (von der MQTT_GENERIC_BRIDGE her kommend) wieder "sortiert" und daraus einzelne MQTT2_DEVICEs generiert, die den Geräten auf dem Neben-FHEM entsprechen.
Dazu solltest du ggf. mal mitteilen, wie sich der topic-tree zusammensetzt, dann können wir versuchen, das zusammen rauszufieseln. Ist aber ein Thema, das wir gesondert behandeln sollten (ist evtl. auch eine Sache, die man gut ins Wiki (zu den Praxisbeispielen oder gesondert zu MQTT_GENERIC_BRIDGE) bringen könnte...
Wenn du ein Beispiel suchst, wie so eine "eigene Bridge" aussehen könnte: Schau dir mal die bridgeRegexp von L_01_zigbee2mqtt_bridge an. Im Prinzip sollte es genügen, die CID aus dem abzuleiten, was als $device auf Seiten der MQTT_GENERIC_BRIDGE verwendet wird...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Tobias am 15 Juli 2019, 14:48:37
alles klar, danke... ich fiesel mich mal durch ;)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: mahowi am 20 September 2019, 11:14:43
Für die zigbee2mqtt Bridge hat sich ein Fehler in der setList zum Setzen der "device_options" eingeschlichen, da ist ein Anführungszeichen zuviel.

Index: mqtt2.template
===================================================================
--- mqtt2.template      (Revision 20203)
+++ mqtt2.template      (Arbeitskopie)
@@ -73,7 +73,7 @@
   y_device_setting:textField BASE_TOPIC/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}\
   x_bind:textField BASE_TOPIC/bridge/bind/$EVTPART1 $EVTPART2\
   x_bind_unbind:textField BASE_TOPIC/bridge/unbind/$EVTPART1 $EVTPART2\
-  x_device_options:textField BASE_TOPIC/bridge/config/device_options {"friendly_name":"$EVTPART1",""options": {"$EVTPART2": "$EVTPART3"}}\
+  x_device_options:textField BASE_TOPIC/bridge/config/device_options {"friendly_name":"$EVTPART1","options": {"$EVTPART2": "$EVTPART3"}}\
   x_group_add_to:textField BASE_TOPIC/bridge/group/$EVTPART1/add $EVTPART2\
   x_group_rm_from:textField BASE_TOPIC/bridge/group/$EVTPART1/remove $EVTPART2\
   x_group_rm_from_all:textField BASE_TOPIC/bridge/group/$EVTPART1/remove_all $EVTPART2\
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 20 September 2019, 12:28:48
Thx, u.a. habe ich eben auch diesen bugfix eingecheckt. Sorry for inconvenience...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: mahowi am 21 September 2019, 10:45:40
Wenn ich nach dem heutigen Update die Templates neu anwende, bekomme ich die Fehlermeldung:
Unknown command zigbee2mqtt/([A-Za-z0-9._]*)[/]?.*:.*, try help.
Unknown command zigbee2mqtt/bridge/config/devices
, try help.
Unknown command zigbee2mqtt/bridge/networkmap, try help.
Unknown command zigbee2mqtt/bridge/networkmap, try help.
Unknown command zigbee2mqtt/bridge/state:.*, try help.
Unknown command zigbee2mqtt/bridge/config/devices:.*, try help.
Unknown command zigbee2mqtt/bridge/config/log_level:.*, try help.
Unknown command zigbee2mqtt/bridge/config/permit_join:.*, try help.
Unknown command zigbee2mqtt/bridge/config/rename:.*, try help.
Unknown command zigbee2mqtt/bridge/log:.*\"type\".\"devices\".\"message\".*, try help.
Unknown command zigbee2mqtt/bridge/log:.*, try help.
Unknown command zigbee2mqtt/bridge/networkmap:.*, try help.
Unknown command zigbee2mqtt/bridge/networkmap/graphviz:.*, try help.
Unknown command zigbee2mqtt/bridge/networkmap/raw:.*, try help.
Unknown command zigbee2mqtt/bridge/config:.*, try help.
Unknown command zigbee2mqtt/bridge/config/log_level, try help.
Unknown command zigbee2mqtt/bridge/config/permit_join, try help.
Unknown command zigbee2mqtt/bridge/config/remove, try help.
Unknown command zigbee2mqtt/$EVTPART1/set, try help.
Unknown command zigbee2mqtt/bridge/bind/$EVTPART1, try help.
Unknown command zigbee2mqtt/bridge/unbind/$EVTPART1, try help.
Unknown command zigbee2mqtt/bridge/config/device_options, try help.
Unknown command zigbee2mqtt/bridge/group/$EVTPART1/add, try help.
Unknown command zigbee2mqtt/bridge/group/$EVTPART1/remove, try help.
Unknown command zigbee2mqtt/bridge/group/$EVTPART1/remove_all, try help.
Unknown command zigbee2mqtt/bridge/config/add_group, try help.
Unknown command zigbee2mqtt/bridge/config/remove_group, try help.
Unknown command zigbee2mqtt/bridge/config/elapsed, try help.
Unknown command zigbee2mqtt/bridge/config/last_seen, try help.
Unknown command zigbee2mqtt/bridge/config/ban, try help.
Unknown command zigbee2mqtt/bridge/config/rename, try help.
Unknown command zigbee2mqtt/bridge/config/reset, try help.

Edit:
zigbee2mqtt_TempHum_Sensor funktioniert,  beim zigbee2mqtt_TempMotion_sensor bekomme ich:
Unknown command zigbee2mqtt:.*, try help.
Beim Bewegungsmelder kommt die Fehlermeldung allerdings nicht mehr, wenn ich das Template mehrfach anwende. Beim dritten Versuch klappt es.  ???
Bei der Bridge hilft auch mehrfaches Anwenden nichts.

Edit2:
Wenn ich die Bridge lösche und neu anlege, funktioniert alles. Scheinbar gibt es nur Probleme beim Ändern des Templates.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 22 September 2019, 08:01:50
Danke für's melden. Wundert mich etwas, dass da bisher noch keiner drübergestolpert ist, die regexe sind an der Stelle schon "ewig" so :o .

Habe jetzt (hoffentlich) alle zigbee2mqtt-templates so umgestellt, dass die funktionieren, egal, ob man die CID noch in der readingList drin hat oder nicht. Ist seit eben im svn (=> kommt mit update morgen), wäre nett, wenn ihr meldet, wenn es doch nicht funktioniert.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Tobias am 23 September 2019, 11:06:59
Hi,
da das das Bugs Forum ist:

nach erfolgreicher Umstellung vom Device "mqtt" auf das "MQTT2_CLIENT" Modul ging nach ca. 3 Wochen nichts mehr. Das Modul hat "connected" angezeigt aber es lief keine Kommunikation mehr mit dem mosquitto Server. Auch ein fhem-Neustart brachte nichts.
Ich musste wieder zurück auf das alte, normale "mqtt" Modul gehen.

Auch in den Logs war nichts zu sehen. Seit dem (2 Monate her) läufts wieder
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 23 September 2019, 11:15:44
 ;D ...das ist zwar ein "bugs"-Thread, aber zu mqtt2-template ;) .

Bitte die Frage gesondert stellen, für MQTT2_CLIENT bin ich nicht zuständig, und ich bin mir ziemlich sicher, dass Rudi gerne hätte, dass zum einen die aktuelle Version des Moduls getestet wird, lists angefügt und evtl. verbose 5 - logs...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: mahowi am 23 September 2019, 16:32:00
Danke für's melden. Wundert mich etwas, dass da bisher noch keiner drübergestolpert ist, die regexe sind an der Stelle schon "ewig" so :o .

Habe jetzt (hoffentlich) alle zigbee2mqtt-templates so umgestellt, dass die funktionieren, egal, ob man die CID noch in der readingList drin hat oder nicht. Ist seit eben im svn (=> kommt mit update morgen), wäre nett, wenn ihr meldet, wenn es doch nicht funktioniert.

Wahrscheinlich ändern die wenigsten das Template zwischendurch, daher fiel das nicht auf.

Jetzt konnte ich das Template bei der Bridge auf jeden Fall fehlerfrei ein zweites Mal anwenden.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 23 September 2019, 17:38:43
Danke für die Rückmeldung. In der Tat dürfte es bei "Erstverabreichung" nie ein Problem gegeben haben.

Die Umstellung betraf übrigens alle zigbee2mqtt-templates, aber auch da sollte das jetzt völlig stressfrei "fluppen", wenn man das wiederholt anwendet (die Übung war nicht schlecht, ich habe wieder etwas regexen geübt...).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: HomeAlone am 14 Oktober 2019, 22:01:42
Ich habe gerade meinen ersten Erfolg mit der Verwendung der mqtt2.templates errungen und nachdem ich fleißig die Templates meinen Sensoren zugeordnet habe ist mir Folgendes in der Darstellung aufgefallen:

Bei den Templates zigbee2mqtt_TempHumSensor und zigbee2mqtt_TempHumHpaSensor werden Temperatur und Luftfeuchtigkeit unterschiedliche dargestellt: Einmal mit den Abkürzungen T und H und einmal mit Temperature und Humidity.

Ich fände es übersichtlicher, wenn hier eine einheitliche Benennung bei denselben Dingen verwendet würde. Persönlich gefällt mir die Langform besser, da intuitiver.

Ich vermute, folgende Zeile in der Templatebeschreibung von zigbee2mqtt_TempHumSensor wäre abzuändern von
attr DEVICE stateFormat T: temperature H: humidityin
attr DEVICE stateFormat {sprintf ("Temperature: %.1f°C Humidity: %.1f%% ", ReadingsVal($name,"temperature",0), ReadingsVal($name,"humidity",0)) }?


Des weiteren verwende ich das zigbee2mqtt_light_cct Template, welches ein Icon (light_control) verwendet. Das finde ich auch sehr hilfreich bei der Übersicht.
Macht es nicht auch Sinn, so etwas bei den anderen Sensoren (wenn sinnvolle Icons vorhanden sind) zu ergänzen?

Z.B. bei besagten Temperatur/Luftfeuchte Sensoren:
attr DEVICE icon temperature_humidity?

Viele Grüße
Sascha
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: HomeAlone am 14 Oktober 2019, 23:00:32
Ich habe einen Sensor, für den noch kein Template existiert: Den Xiaomi DJT11LM Vibration Sensor (http://"https://www.zigbee2mqtt.io/devices/DJT11LM.html").

Der Sensor heißt zwar offiziell Vibration Sensor, ich finde aber, dass es eher ein Alarm-Sensor oder Gyroscope-Sensor ist: Er kann Fall, Drehung/Neigung sowie Klopfen registrieren.

Folgende Readings besitzt der via autocreate erzeugte Sensor:

setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:41 nn_Vibrationskontakt_action drop
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_angle 83
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_angle_x 2
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_angle_x_absolute 88
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_angle_y 1
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_angle_y_absolute 89
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_angle_z 88
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_battery 100
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_dateCode 20180130
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_friendlyName nn_Vibrationskontakt
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_hwVersion 3
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_ieeeAddr 0x00158d0002a4ee26
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_manufId 4151
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_manufName LUMI
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_modelId lumi.vibration.aq1
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_nwkAddr 47946
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_powerSource Battery
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_status online
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_swBuildId 3000-0001
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_type EndDevice
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_linkquality 126
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_voltage 3005

Leider habe ich das Format in /opt/fhem/FHEM/lib/AttrTemplate noch nicht ganz verstanden - vor allem die ganzen par Zeilen mit den RegExps. Das, was ich vermeintlich verstanden habe würde ich so zusammenfassen:


name:zigbee2mqtt_AlarmSensor
desc: Alarm  sensor via zigbee2mqtt <br>Can report actions drop, tilt or vibration as well as x,y,z coordinates of its movement.<br>Sensitivity can be set to low, medium or high.<br>Tested with: Xiaomi DJT11LM Vibration Sensor
filter:TYPE=MQTT2_DEVICE:FILTER=CID=zigbee.*
order:L_15
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[\b]?([^/:]+)[/].*:, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/]([^/]+).*:, ? $1 : undef }
attr DEVICE stateFormat Action: action X: angle_X Y: angle_Y Z: angle_Z
attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE model zigbee2mqtt_AlarmSensor

Action kann drei Zustände annehmen: tilt, drop, vibration. Muss das hier noch irgendwie verarbeitet werden?
Auch wenn ich bei Temperature und Humidity die Langform schöner fand: Bei Koordinaten dürfen es gerne knackige Werte X, Y und Z sein. :)

Zudem kann der Sensor auch einen Wert entgegen nehmen: Sensitivity mit den Werten low, medium, high. Siehe hierzu
https://github.com/Koenkk/zigbee-shepherd-converters/pull/74 (https://github.com/Koenkk/zigbee-shepherd-converters/pull/74)

Wie würde man das in dem mqtt2.template realisieren? Irgendwie über
attr DEVICE setStateList low medium high?

Schon mal vielen Dank für Eure Mithilfe.

Viele Grüße
Sascha
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 15 Oktober 2019, 10:22:22
Moin, sieht doch schon mal ganz gut aus.

Habe den eben mal eingecheckt, und eine setList hinzugefügt für die Empfindlichkeit, und auch das stateFormat von dem temp/hum angepaßt. Muß zwar nicht zwingend alles einheitlich sein, aber hier schadet es auch nicht... Allerdings sind die Readings, die da via setstate angezeigt werden, etwas komisch, (und ich sehe jetzt erst die Kleinschreibung). Hast du autocreate am IO auf "complex"?

(setStateList ist für "was anderes", aber das könnte man ggf. ach noch ergänzen, wenn es jemand stören sollte, wo das Setzen der Empfindlichkeit jetzt landet.)
Was Icons angeht, habe ich den Code jetzt insgesamt so umgestellt, dass bereits (vom User) gesetzte Icons erhalten bleiben, wenn jemand Vorschläge für die bisher fehlenden macht, pflege ich das auch noch ein, kein Thema...

@HomeAlone: Wenn du da jeweils ein komplettes RAW lieferst, kann ich manches etwas besser nachstellen (hier ist es hoffentlich "gegessen", ggf. muß noch Kleinschreibung genommen werden).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: HomeAlone am 15 Oktober 2019, 23:26:58
Allerdings sind die Readings, die da via setstate angezeigt werden, etwas komisch, (und ich sehe jetzt erst die Kleinschreibung). Hast du autocreate am IO auf "complex"?
Ja, habe autocreate auf komplex stehen. Mein IO Device ist ein MQTT2_CLIENT, welcher wiederum auf einen mosquitto in einem Docker-Container verweist. Was heißt genau komisch? Habe keine Ahnung von der Materie, aber ich finde sie aussagekräftig  ;D

(setStateList ist für "was anderes", aber das könnte man ggf. ach noch ergänzen, wenn es jemand stören sollte, wo das Setzen der Empfindlichkeit jetzt landet.)
Was Icons angeht, habe ich den Code jetzt insgesamt so umgestellt, dass bereits (vom User) gesetzte Icons erhalten bleiben, wenn jemand Vorschläge für die bisher fehlenden macht, pflege ich das auch noch ein, kein Thema...
Ich kann gerne mal draufgucken, welche Icons passen würden und Vorschläge machen.

@HomeAlone: Wenn du da jeweils ein komplettes RAW lieferst, kann ich manches etwas besser nachstellen (hier ist es hoffentlich "gegessen", ggf. muß noch Kleinschreibung genommen werden).
Meinst Du das RAW aus der Definition des FHEM-Sensors, oder ein anderes RAW? Hier das komplette RAW vom Sensor:
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:33 associatedWith MQTT2_zigbee_bridge
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 22:23:56 nn_Vibrationskontakt_action tilt
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_angle 83
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_angle_x 84
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_angle_x_absolute 6
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_angle_y 1
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_angle_y_absolute 89
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_angle_z 6
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_battery 100
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_dateCode 20180130
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_friendlyName nn_Vibrationskontakt
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_hwVersion 3
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_ieeeAddr 0x00158d0002a4ee26
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_manufId 4151
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_manufName LUMI
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_modelId lumi.vibration.aq1
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_nwkAddr 47946
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_powerSource Battery
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_status online
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_swBuildId 3000-0001
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_type EndDevice
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_linkquality 136
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_voltage 3005

Ich teste das von Dir eingecheckte Template morgen aus (da wird es vermutlich im Update sein) und berichte.

Mir ist übrigens noch aufgefallen, dass im RAW am Ende der Zeile mit dem _device_dateCode ein roter Punkt erscheint. Wenn ich alle setstates markiere und kopiere, landen nur die Werte bis zum _device_dateCode 20180130 in der Zwischenablage... siehe Anhang. Könnte das in Verbindung mit "komisch" stehen?

Viele Grüße
Sascha
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 16 Oktober 2019, 07:24:39
"komisch" meint im wesentlichen: unnötig lang (eben wg. complex). "complex" ist was feines, wenn man es braucht. Aber ich kenne nur ganz wenige Fälle, in denen man es benötigt, der wichtigste sind gleich aufgebaute JSON auf unterschiedliche Topics beim EBUS, die sich dann auch auf eine andere Baugruppe am Bus beziehen.
In der Regel genügt aber "simple", um "aussagefähige" Readingnamen zu erhalten, ganz unabhängig von der Art des IO.

Mit komplettem RAW ist übrigens auch das "defmod" gemeint, so sehe ich nur die setstates ;) .
Ich mache das in der Regel so, dass ich den Curser in das Textfeld plaziere und dann mit Strg+a alles markiere und mit Strg+Einf kopiere (Mausaktionen sind in Browserfenstern immer gefühlter Mist...).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: pwlr am 16 Oktober 2019, 12:57:54
Moin,
diese Templates sind sicher ne super Sache und erleichtern die Definition in der Entwicklungsphase erheblich. Keine Frage.

Aber wenn alles läuft oder man die Templates nicht braucht (so wie ich mit meinen Device-Eigenentwicklungen), würde ich die gern aus der SetList weg haben
set <device> attrTemplate
Meine Anregung wäre, das mit einem neuen attr individuell steuern zu können. Als Default könnte man die Liste gern aktivieren. Analog zum attr disable.

Was haltet ihr davon?
Moin
Bernd

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 16 Oktober 2019, 13:10:13
Moin. Mich hat das bisher nicht ernsthaft gestört, hätte aber auch nichts dagegen, das ausblendbar zu machen. M.E. ist das hier aber die falsche Adresse, das gehört allgemein zu attrTemplate (also zu "Automatisierung" lt. Maintainer.txt) und hätte wohl auch Auswirkungen auf weitere Module, die das (potentiell) nutzen (im Hintergrund ist es eine "Extension" zu SetExtensions).

Rudi liest hier zwar vermutlich mit, aber ob er die Frage hier wahrnimmt, kann ich nicht sagen ;) .
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 16 Oktober 2019, 13:12:16
Will gerade nicht raten: aus welchem Grund will man attrTemplate nicht in der Liste haben?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: pwlr am 16 Oktober 2019, 13:38:57
weil ich mir Devices mit dem ESP8266-12F selbst baue / programmiere. Da passen die Templates von den Industrieprodukten sicher nicht.
Ich finde auch, dass eine manuelle Definition (eigener Devices) kein Hexenwerk ist und fhem mit der großen Bandbreite der User-Anforerungen möglichst individuell sein sollte.

Wäre (aus meiner Sicht) wirklich gut, weil in der Weboberfläche eines Device dann nur noch die für den Betrieb relevante Dinge auftauchen würden. Fehlfunktionen durch falsche Bedienung eines Nutzers könnten vermieden werden.


Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 16 Oktober 2019, 14:26:07
Zitat
Wäre (aus meiner Sicht) wirklich gut, weil in der Weboberfläche eines Device dann nur noch die für den Betrieb relevante Dinge auftauchen würden. Fehlfunktionen durch falsche Bedienung eines Nutzers könnten vermieden werden.
Wenn man diese Begruendung ernst nimmt, dann muesste jedes einzelne Befehl bei jedem FHEM-Geraet optional unterbunden werden koennen, und das je nach Zugang konfigurabel. Das konsistent und effizient umzusetzen ist aufwendig (bzw. ich habe keine dazu passende geniale Idee), und der Bedarf bisher ist auch nicht ueberwaeltigend.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: pwlr am 16 Oktober 2019, 16:06:33
Ich unterscheide immer bei den Bedürfnissen zwischen Entwicklern und Nutzern. Der Nutzer will eigentlich nur (beispielsweise) ein Device ein- oder ausschalten und hat sonst keine Ahnung von fhem. Ich denke da so an meine Familienmitglieder...

Es ist richtig, dass auch bei den anderen Devices jede Menge Befehle angezeigt werden.

Ich dachte an eine Vorgehensweise analog wie bei TYPE dummy und dem attr setList. Z.B.:

attr setList default -> alle Systembefehle werden angezeigt
attr setList default Hugo Emma Erna -> zusätzlich eigene Befehle
attr setlist Hugo Emma Erna -> nur eigene Befehle

Vielleicht geht es ja, ich bin bestimmt kein Fachmann für fhem-Internals. Wollte es nur mal anregen.

Bernd



Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 16 Oktober 2019, 16:12:39
Ähm, darf ich darum bitten, diese OT-Diskussion an anderer Stelle weiterzuführen?

(Es sei hier nur noch angemerkt, dass es zur Beschränkung der Optionen "normaler Nutzer" andere Mechanismen (mir bekannt jedenfalls im Zusammenspiel mit in FHEMWEB, siehe allowedCommands und die forbiddenroom bzw. hidden.*-Attribute) gibt, um das für diese Nutzer gedachte UI "unfallverhütungsgerecht" zu gestalten...)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: HomeAlone am 16 Oktober 2019, 16:19:05
Ich hätte schwören können, dass ich gestern alles inkl. defmod kopiert hatte... na ja, aller guten Dinge sind drei. ;)
defmod MQTT2_zigbee_nn_Vibrationskontakt MQTT2_DEVICE zigbee_nn_Vibrationskontakt
attr MQTT2_zigbee_nn_Vibrationskontakt IODev mosquittoATnucgulp
attr MQTT2_zigbee_nn_Vibrationskontakt alias MQTT2_zigbee_nn_Vibrationskontakt
attr MQTT2_zigbee_nn_Vibrationskontakt model zigbee2mqtt_AlarmSensor
attr MQTT2_zigbee_nn_Vibrationskontakt readingList zigbee2mqtt/nn_Vibrationskontakt:.* { json2nameValue($EVENT) }\
zigbee2mqtt/nn_Vibrationskontakt/set:.* { json2nameValue($EVENT, 'set_', $JSONMAP) }
attr MQTT2_zigbee_nn_Vibrationskontakt room MQTT2_DEVICE
attr MQTT2_zigbee_nn_Vibrationskontakt setList sensitivity:low,medium,high zigbee2mqtt/nn_Vibrationskontakt/set {"sensitivity":"$EVTPART1"}
attr MQTT2_zigbee_nn_Vibrationskontakt stateFormat Action: action X: angle_X Y: angle_Y Z: angle_Z

setstate MQTT2_zigbee_nn_Vibrationskontakt Action: vibration X: angle_X Y: angle_Y Z: angle_Z
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-16 12:44:08 action vibration
... (der Rest wie bereits gepostet)

Übrigens schneidet er auch mit CTRL+C und CTRL+V ab dem roten Punkt ab.   :(

Leider klappt es noch nicht: Im Raum MQTT2_DEVICE werden z.B. bei den TempHum Sensoren die Daten in der Übersicht schön aktualisiert - beim Alarm-Sensor aber nicht. Und kurz nachgedacht, habe ich glaube ich, den Fehler gefunden:
Anstelle von:
attr DEVICE stateFormat Action: action X: angle_X Y: angle_Y Z: angle_Z
muss da
attr DEVICE stateFormat Action: action X: angle_x Y: angle_y Z: angle_z
stehen (also X, Y, Z -> x, y, z).  :-[ mea culpa.

Das set funktioniert leider auch nicht: Das meldet der Sensor (aus dem MQTT-Protokoll)

{
  "type" : "zigbee_publish_error",
  "message" : "Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.",
  "meta" : {
    "entity" : {
      "ID" : "0x00158d0002a4ee26",
      "type" : "device",
      "friendlyName" : "nn_Vibrationskontakt"
    },
    "message" : "{\"sensitivity\":\"medium\"}"
  }
}

Jetzt könnte man meinen, er findet die Bridge nicht, aber wenn ich ihn drehe, runterfallen lasse etc. melden mir sowohl mosquitto als auch die Webpage für den Sensor fleißig, dass die Daten korrekt ankommen.
Ich habe auch darauf geachtet, vor dem Absenden des set Befehls auf den Button des Sensors zu drücken, damit er aktiv ist, wenn das set command kommt.

Hier der log output vom Mosquitto:
10/16/2019, 11:17:46 AM - info: Zigbee publish to device 'nn_Vibrationskontakt', genBasic - write - [{"attrId":65293,"dataType":32,"attrData":21}] - {"manufSpec":1,"disDefaultRsp":1,"manufCode":4447} - 1
10/16/2019, 11:17:47 AM - error: Zigbee publish to device 'nn_Vibrationskontakt', genBasic - write - [{"attrId":65293,"dataType":32,"attrData":21}] - {"manufSpec":1,"disDefaultRsp":1,"manufCode":4447} - null failed with error Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.
10/16/2019, 11:17:47 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.","meta":{"entity":{"ID":"0x00158d0002a4ee26","type":"device","friendlyName":"nn_Vibrationskontakt"},"message":"{\"sensitivity\":\"low\"}"}}'

Hier der Beweis, dass der Sensor im Netzwerk ist:
10/16/2019, 11:20:19 AM - info: MQTT publish: topic 'zigbee2mqtt/nn_Vibrationskontakt', payload '{"linkquality":2,"angle_x":2,"angle_y":1,"angle_z":88,"angle_x_absolute":88,"angle_y_absolute":89,"angle":16,"battery":97,"voltage":2995,"action":"vibration","device":{"ieeeAddr":"0x00158d0002a4ee26","friendlyName":"nn_Vibrationskontakt","type":"EndDevice","nwkAddr":47946,"manufId":4151,"manufName":"LUMI","powerSource":"Battery","modelId":"lumi.vibration.aq1","hwVersion":3,"swBuildId":"3000-0001","dateCode":"20180130\u0000","status":"online"}}'

Werde das heute Abend noch mal mit dem Sensor direkt neben dem Coordinator testen, aber eigentlich kann das nicht das Problem sein...

Bis dahin habe ich es auch mit den klein geschriebenen Koordinaten getestet - muss jetzt aber fix weg und wollte schon mal das Gefundene rückmelden.

Viele Grüße
Sascha

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 16 Oktober 2019, 16:35:14
 :) Das mit der Kleinschreibung hatte ich ja schon angemerkt (aber leider nicht rechtzeitig vor dem Einchecken gesehen).

Was das Setzen des Werts angeht, bin ich etwas ratlos, wo die rückgemeldeten escape-Anweisungen ("\") für die Anführungszeichen herkommen bzw. ob das die Ursache für eventuelle Probleme ist. Kannst du mal mosquitto_pub bemühen und das darüber testen, ob die Reaktion dann dieselbe ist? (Wenn ja, ist nicht FHEM die Ursache und der setList-Eintrag paßt so bzw. muß so bleiben. Der Fehler wäre dann bei zigbee2mqtt zu melden bzw. da im github mal nachzusehen, ob das dort schon bekannt ist). Andernfalls mal ohne die Anführungszeichen versuchen?
Jedenfalls bei allen anderen settern (für zigbee2mqtt) hat das bisher nach diesem Muster (in der Regel auch mit Anführungszeichen) probemlos funktioniert...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: HomeAlone am 16 Oktober 2019, 20:53:24
OK, mit kleinen Buchstaben für x, y und z klappt die Anzeige. Check! :)

Bzgl. des Setzens der Sensitivity: Da machst Du alles richtig, hab es gerade überprüft: mosquitto_pub, MQTT.fx und MQTT Explorer schicken die Nachricht genauso raus. Und es gibt jedesmal dieselbe Fehlermeldung.

Ich google gerade noch mal bei zigbee2mqtt nach der Fehlermeldung, ob ich irgendwas finde und frage ansonsten mal dort nach.
Habe gerade etwas gefunden, was darauf hinweist, dass es manchmal zu Instabilitäten mit Routern kommen kann. Abhilfe: Router ablernen neu anlernen, aber das kann ich erst morgen machen, da der im Schlafzimmer meiner kleinen auf dem Schrank ist. :)

Melde mich, wenn ich was neues weiß. Prizipiell kann man das Template für den Sensor so freigeben. Soll ich es noch im Contributing Thread (http://"https://forum.fhem.de/index.php/topic,94495.0.html") veröffentlichen, wenn das Update morgen raus ist?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 17 Oktober 2019, 09:26:07
Moin, zur Info: die Korrektur habe ich grade (mit) ins svn geschoben, eine weitere Info des Maintainers bzw. die Bitte an ihn, das zu veröffentlichen (über den anderen Thread) ist daher nicht erforderlich  ;D .

Mit reingekommen ist auch ein template für mehrere DS18x20 an Tasmota, siehe hier (https://forum.fhem.de/index.php/topic,104475.0.html). Kann sein, dass da noch Optimierungsbedarf besteht...

Ansonsten bin ich mal gespannt, was die Ursache dafür ist/war, warum das auf der zigbee2mqtt-Seite nicht wollte, aber das ist hier eigentlich dann auch OT...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: HomeAlone am 18 Oktober 2019, 21:53:55
Ich habe jetzt noch einmal ganz von vorne angefangen: Alle MQTT2-Devices, Clients etc gelöscht und Stück für Stück mit dem Aufbau begonnen.
Anbei meine Beobachtungen - und die daraus resultiernden Anregungen :)

Ich habe, wie im Wiki für den MQTT-Client (http://"https://wiki.fhem.de/wiki/MQTT2_CLIENT") beschrieben, mit dem Teil für Tasmota, Shelly und ESPEasy angefangen. Zunächst einmal stelle ich mir die Frage, warum diese drei "MQTT-Dialekte" in einer Bridge zusammengefasst werden, obwohl sie anscheinend unterschiedlich aufgebaute MQTT-Messages haben? Sollte ich mich hier irren, dann gerne Kontra geben. :)
Ansonsten wäre es mMn intuitiver die auto-created Bridge-Devices entsprechend zu trennen: Also nicht nur
MQTT2_GeneralBridge
sondern
MQTT2_BridgeTasmota
MQTT2_BridgeShelly
MQTT2_BridgeESPEasy
MQTT2_BridgeZigbee2MQTT
...
welche wiederum jeweils mit autocreate 0 beglückt werden, damit die Befüllung erst erfüllt, wenn diese "Sub"-Bridges korrekt konfiguriert, bzw. benötigt werden.  Ich weiß nicht, ob man das mit dem autocreate Befehl eine Ebene höher nicht schön lösen könnte? Dann wäre das natürlich noch besser. Also bei der Auswahl des Attributs autocreate eine Liste mit Checkboxen für die gewünschten "Sub"-Bridges. Ich weiß aber nicht, ob das programmatisch (sinnvoll) machbar ist.

Was mir als nächstes aufgefallen ist: Wenn die MQTT2_GeneralBridge mit dem attrTemplate für MQTT2_CLIENT_general_bridge belegt wird, wird das Attribut bridgeRegexp automatisch mit den korrekten MQTT-Strings (hoffe der Begriff ist richtig) befüllt.

Das führt bei mir dazu, dass erst mal keine Geräte automatisch angelegt werden, da ich abweichend vom Standard als prefix noch ein tasmota/ verwende. Also die bridgeRegexp entsprechend angepasst und schwupps, werden die devices erzeugt. Hier zur Verdeutlichung meine MQTT2_GeneralBridge:

defmod MQTT2_GeneralBridge MQTT2_DEVICE MQTT2_GeneralBridge
attr MQTT2_GeneralBridge IODev mosquittoATnucgulp
attr MQTT2_GeneralBridge alias MQTT2_GeneralBridge
attr MQTT2_GeneralBridge autocreate 1
attr MQTT2_GeneralBridge bridgeRegexp (tasmota/tele|tasmota/cmnd)[/]([^/]+)[/].*:.* "$2"\
  shellies[/]([^/]+)[/].*:.* "$1"\
  (ESPClient_[^/]+)[/].*:.* "$1"
attr MQTT2_GeneralBridge comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
attr MQTT2_GeneralBridge model MQTT2_CLIENT_general_bridge
attr MQTT2_GeneralBridge room MQTT2_DEVICE
attr MQTT2_GeneralBridge setStateList on off

Jetzt haben wir an dieser Stelle mMn bereits alles, was wir benötigen, um - zumindest Tasmota-Sensoren - korrekt anzusprechen. Shelly und ESPEasy kann ich gerade nicht überprüfen.

Als nächstes einem automatisch erzeugten Tasmota Geräte die zugehörige attrTemplate zuordnen. Hier eine Sonoff S20 Steckdose nach dem autocreate (und vor der Zuweisung eines attrTemplates):
defmod MQTT2_SonoffS20004 MQTT2_DEVICE SonoffS20004
attr MQTT2_SonoffS20004 IODev mosquittoATnucgulp
attr MQTT2_SonoffS20004 alias MQTT2_SonoffS20004
attr MQTT2_SonoffS20004 readingList tasmota/tele/SonoffS20004/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_SonoffS20004 room MQTT2_DEVICE

Wähle ich nun das zugehörige attrTemplate (tasmota_basic_state_power_1) aus, öffnet sich ein Dialog:
Input field:
set MQTT2_SonoffS20004 attrTemplate tasmota_basic_state_power1 CMNDTOPIC TELETOPIC STATTOPIC
Text:
Replace
CMNDTOPIC: with the Command topic prefix, without trailing /
TELETOPIC: with the info topic prefix, without trailing /
STATTOPIC: with the ack topic prefix, without trailing /

Ist dieser Dialog nötig (ich rede wie gesagt vom Tasmota-Device)?: In der readingLIst ist die korrekte Syntax drin, in der bridgeRegex des Bridge-Devices ebenso und zwar in allen möglichen Varianten.
Wenn ich mich hier irren sollte (was übrigens auch bei allem weiter oben Geschriebenem sein kann  ;)), könnte man das nicht dahingehend vereinfachen, dass man nicht alle drei Topics zusammensetzen muss? Der Aufbau für cmnd, tele und stat ist ja immer identisch und kann, soweit ich weiß, nicht unterschiedlich aufgebaut sein.
Also alternativ etwas wie:
Please enter the syntax to issue commands to your Tasmota device. Use %COMMAND% as placeholder for the tasmota command, %SENSOR% as placeholder for the sensor.
e.g.: %COMMAND%/%SENSOR% will result in
TELETOPIC = tele/MQTT2_SonoffS20004/...
STATTOPIC = stat/MQTT2_SonoffS20004/...
CMNDTOPIC = cmnd/MQTT2_SonoffS20004/...
Anschließend wird die Definition wie gehabt zusammengebaut.

Und noch einen Schritt weitergehend: Wenn man die jeweiligen "Sub"-Bridges wie oben angeregt definieren könnte, könnte diese Syntax sogar dort einmal hinterlegt werden und die einzelnen Sensoren müssten dann nicht jedesmal den Dialog anzeigen sondern könnten diese einfach nur von einer Ebene höher anwenden.

Ich weiß natürlich nicht, mit welchen Aufwänden das verbunden ist! Aber ich denke, das Das ist mir eben aufgefallen, als ich das jetzt zum ersten Mal richtig durchexerziert habe - zugegebenermaßen jetzt "NUR" für Tasmota Devices.

Unabhängig davon: Ich finde es super, welcher Aufwand bereits betrieben wurde, um die Anbindung der Sensoren möglichst einfach zu gestalten. Daher bitte nicht als Kritik sondern als Anregung verstehen.

Viele Grüße
Sascha
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: HomeAlone am 19 Oktober 2019, 00:12:17
Ich hatte in einem früheren Posting gesagt, ich könne mir die verfügbaren Icons einmal anschauen und für die verschiedenen Sensortypen Vorschläge machen. Das habe ich jetzt gemacht und auch bei mir angewandt. Hier ein erster Wurf:

Funktion -> icon
==========================
contact -> audio_pause
climate -> temperature_humidity
alarm -> secur_alarm
dimmer -> light_control
smoke detector -> secur_smoke_detector
motion sensor -> people_sensor
switch -> control_home | taster
double switch -> control_on_off | taster_ch
plug -> message_socket
plug with energy -> black_Steckdose.on
Sonoff S20 -> hue_filled_outlet
mqtt_bridge -> mqtt
button -> rc_rec
not defined/default -> mqtt_device

Wer könnte eigentlich neue Icons erstellen und hinzufügen und wo frage ich das an? Bin mir nicht ganz sicher, in welchen Thread das gehört.
Z.B. könnte man den Contact Sensor, welcher mMn sehr häufig vorkommt aus dem Pause Icon einfach erzeugen. Ein mqtt Bridge Icon sollte für den Autor des mqtt und mqtt_device icons auch einfach erstellbar sein. :)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 19 Oktober 2019, 16:15:32
Danke vorab mal für die Icon-Vorschläge. Als patch wäre es zwar einfacher gewesen, aber es geht auch so...

Übernommen habe ich v.a. die farblosen Vorschläge.
Bei den farbigen (und beim Einfärben) ist immer das Problem, dass das auch zum Farbschema passen sollte - bisher war ich da auch eher vorsichtig, aber mittlerweile bleiben ja vom User voreingestellte Icons erhalten :) . Und da, wo es nichts spezifisches gibt, ist es mMn. besser, nichts zu tun, wen's stört, der kann ja nacharbeiten...
Hoffe, das ist jetzt weitgehend vollständig.

Für neue Icons gibt es einen Thread, da kann man (unter Beachtung eventueller urheberrechtlicher Fragen) Vorschläge machen bzw. einreichen, was man selbst erstellt hat.


Was die bridge-Fragen angeht, scheint es mir so zu sein, dass ein wesentlicher Teil der geschilderten Probleme mit zwei oder drei Dingen zusammenhängen:
1. Es wird "CLIENT" verwendet. Das macht es generell etwas schwieriger;
2. Du nutzt eine "spezielle" Konfiguration; bei den "Praxisbeispielen" steht ganz vorne, dass man es am einfachsten hat, wenn man die "defaults" der Geräte belässt bzw. nur dort ändert, wo es das Wiki erwähnt. Du hast was spezielles gemacht, damit bist du - überspitzt formuliert - "Fortgeschritten" und nicht mehr die engere Zielgruppe des Wiki-Artikels (und der attrTemplates@MQTT2_DEVICE :P );
3. letztlich scheint es mir aber so zu sein, dass du das "Pech" hattest, dass in den readingList-Attributen (noch) kein LWT-Element drin war, denn eigentlich hätte auch mit deinem Topic-Pfad die "Aufdröselung" klappen sollen (und dann kein Dialogfeld mehr kommen).

Vielleicht checkst du an einem Beispiel, ob das der Fall war bzw. das anders ist, wenn die LWT-Info da ist?
 
Vom Grundsatz her ist es so gedacht, dass man eigentlich nur autocreate am IO ein- und ausschalten müssen sollte, (fast) alles andere sollte (mit nur einem General-Bridge-Gerät) automatisch passieren, ohne dass man irgendwelche Zweige ausdrücklich zu- oder abschaltet... Nur wer "spezielle" Hardware hat (wie zigbee2mqtt oder eBus), muß dann den jeweils ersten weiteren Schritt dann wieder anschubsen, aber für alle anderen, "einfacheren" Geräte/Zweige, wo es auch keine "Bridge-Hardware" gibt (wie den zigbee2mqtt-Dienst samt Dongle oder den eBus-Daemon), ist eigentlich mMn. auch kein separates Zwischengerät erforderlich. Eher würde man weitere bridgeRegex-Zeilen (z.B. für andere verbreitete ESP-firmwares) hinzufügen.

Würde mich interessieren, was du nach dem "LWT-Test" dazu denkst?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: HomeAlone am 20 Oktober 2019, 12:03:40
Danke vorab mal für die Icon-Vorschläge. Als patch wäre es zwar einfacher gewesen, aber es geht auch so...

Übernommen habe ich v.a. die farblosen Vorschläge.
Bei den farbigen (und beim Einfärben) ist immer das Problem, dass das auch zum Farbschema passen sollte - bisher war ich da auch eher vorsichtig, aber mittlerweile bleiben ja vom User voreingestellte Icons erhalten :) . Und da, wo es nichts spezifisches gibt, ist es mMn. besser, nichts zu tun, wen's stört, der kann ja nacharbeiten...
Hoffe, das ist jetzt weitgehend vollständig.
Ja, ich bin absolut bei Dir, nur die "Standard-Icons" zu verwenden. Beim Gosund Zwischenstecker bot sich das aber an, weil der Ring ja - theoretisch - je nach Verbrauch unterschiedliche Farben anzeigen können sollte - auch noch eine Baustelle bei mir.  ::)

Bei den Icons, wo es nichts gibt, würde ich dennoch vorschlagen, das Icon für mqtt_device zu verwenden: Andernfalls hat man unschöne Sprünge bei der Deviceauflistung: Einige Devices mit und einige ohne macht das schnelle Suchen in der Liste schwerer. Ich habe z.B. aktuell 28 Devices eingebunden und finde die Variante mit einheitlicher Listdarstellung übersichtlicher. Siehe angehängter screeny.

Für neue Icons gibt es einen Thread, da kann man (unter Beachtung eventueller urheberrechtlicher Fragen) Vorschläge machen bzw. einreichen, was man selbst erstellt hat.
Ich würde so etwas unter Frontends vermuten, finde da und in den jeweiligen Unterthemen aber nichts passendes. Werde es ansonsten einfach direkt in Frontends mal anfragen.

Was die bridge-Fragen angeht, scheint es mir so zu sein, dass ein wesentlicher Teil der geschilderten Probleme mit zwei oder drei Dingen zusammenhängen:
1. Es wird "CLIENT" verwendet. Das macht es generell etwas schwieriger;
2. Du nutzt eine "spezielle" Konfiguration; bei den "Praxisbeispielen" steht ganz vorne, dass man es am einfachsten hat, wenn man die "defaults" der Geräte belässt bzw. nur dort ändert, wo es das Wiki erwähnt. Du hast was spezielles gemacht, damit bist du - überspitzt formuliert - "Fortgeschritten" und nicht mehr die engere Zielgruppe des Wiki-Artikels (und der attrTemplates@MQTT2_DEVICE :P );
3. letztlich scheint es mir aber so zu sein, dass du das "Pech" hattest, dass in den readingList-Attributen (noch) kein LWT-Element drin war, denn eigentlich hätte auch mit deinem Topic-Pfad die "Aufdröselung" klappen sollen (und dann kein Dialogfeld mehr kommen).

Vielleicht checkst du an einem Beispiel, ob das der Fall war bzw. das anders ist, wenn die LWT-Info da ist?
Ich als "Fortgeschrittener" hab jetzt erst mal eine halbe Stunde versucht herauszufinden, was LWT sein soll...  ;)
Last-Will retain ist hoffentlich die Antwort.

Habe hierzu noch mal eine Sonoff S20 Steckdose hinzugefügt. Und siehe da: Die hat ein Reading LWT mit dem Wert Online. Zudem weiß er von einem Module Sonoff S2X und weiteren im Webfrontend der Steckdose eingestellten Dingen, was vermutlich der Grund dafür ist, dass es klappt:
Wenn ich bei diesem Sensor die Dropdown Liste bei attrTemplate auswähle, sehe ich (so bilde ich mir zumindest ein) auch viel mehr Auswahlmöglichkeiten. Zudem erscheinen die ganzen Zigbee2MQTT Optionen nicht mehr dort (außer zigbee2mqtt_bridge).
Wähle ich nach der Auswahl des korrekten Templates set an, erscheint der Dialog, von dem ich oben weit und breit erzählt habe nicht mehr. Top! Demzufolge ist es jetzt wirklich intuitiv gelöst.

Hast Du eine Idee, warum vorher das LWT Online nicht in den Readings erschien? Muss man der Bridge erst mal ein wenig Zeit geben, MQTT-Messages zu empfangen, eh man an die Konfiguration der Sensoren geht? 

Vom Grundsatz her ist es so gedacht, dass man eigentlich nur autocreate am IO ein- und ausschalten müssen sollte, (fast) alles andere sollte (mit nur einem General-Bridge-Gerät) automatisch passieren, ohne dass man irgendwelche Zweige ausdrücklich zu- oder abschaltet... Nur wer "spezielle" Hardware hat (wie zigbee2mqtt oder eBus), muß dann den jeweils ersten weiteren Schritt dann wieder anschubsen, aber für alle anderen, "einfacheren" Geräte/Zweige, wo es auch keine "Bridge-Hardware" gibt (wie den zigbee2mqtt-Dienst samt Dongle oder den eBus-Daemon), ist eigentlich mMn. auch kein separates Zwischengerät erforderlich. Eher würde man weitere bridgeRegex-Zeilen (z.B. für andere verbreitete ESP-firmwares) hinzufügen.
OK, kann ich nachvollziehen. Das mit dem AutoCreate und den diversen so automatisch erzeugten "Hilfs-Devices" muss ich auch noch mal nachvollziehen - aber da gucke ich erst noch mal und würde explizit noch mal nachfragen, wenn dann etwas unklar geblieben ist.

Würde mich interessieren, was du nach dem "LWT-Test" dazu denkst?
Nachdem das Reading LWT da ist, finde ich das Handling um Welten einfacher. Jetzt muss ich nur noch genau verstehen, wie das Meshing bei Zigbee2MQTT funktioniert, aber das ist ein ganz anderes Thema...  ;D

Danke noch mal für die große Hilfe!

Viele Grüße
Sascha
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 20 Oktober 2019, 19:01:50
Was die Teile mit Strommeßfunktion angeht: Da hatten wir neulich eine Diskussion bzgl. shelly, evtl. kannst du dich da bedienen und mal einen Vorschlag machen (oder zwei)?

Was fehlende Icons angeht, bin ich eher auf dem Tripp: lieber keines als ein "falsches". "mqtt" sagt zwar was über die Art der Datenübermittlung aus, aber das ist keine Aussage, die ich "vergrafikenswert" finde. Lieber soll sich der User damit auseinandersetzen, dass er was tun muß, wenn er es "hübsch" haben will. Aber wenn da mehr dafür sind, soll's an mir nicht hängen ::) .
Den Icon-Thread hast du jetzt ja gefunden...

Dass da keine LWT-Info bei vielen deiner Geräte vorhanden war, hing vermutlich damit zusammen, dass FHEM die Infos von mosquitto schon mal abgerufen hatte; wäre wohl anders gewesen, wenn entweder die Geräte mal neu gestartet gewesen worden wären oder die Verbindung von FHEM zu mosquitto neu aufgebaut worden wäre (FHEM-restart oder evtl. auch set active/disable... oä). Evtl. könnte da im Wiki noch was ergänzt werden (?).
Dass und wie da gefiltert wird, hast du ja jetzt live gesehen, und es scheint auch für dich Sinn zu machen, wie das funktioniert bzw. was man wann zu sehen bekommt. Von daher ist es m.E. ok, wenn der user, dem was "fehlt", erst mal darauf verwiesen wird, dass er dafür sorgen sollte, dass FHEM die Daten (nochmal) erhält (bei Tasmota: die LWT-messages). Dann funktioniert auch der Rest (hoffentlich) reibungslos :) .
(Ich vergesse das nur hin und wieder auch, dass mache Ding ehat gewisse Vorbedingungen benötigen bzw. welche das im Detail sind).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: HomeAlone am 24 Oktober 2019, 21:55:24
Was die Teile mit Strommeßfunktion angeht: Da hatten wir neulich eine Diskussion bzgl. shelly, evtl. kannst du dich da bedienen und mal einen Vorschlag machen (oder zwei)?
Gerne, gerade schlage ich mich aber noch mit der Topologie meines Zigbee2MQTT Netzes rum. 😅

Dass da keine LWT-Info bei vielen deiner Geräte vorhanden war, hing vermutlich damit zusammen, dass FHEM die Infos von mosquitto schon mal abgerufen hatte; wäre wohl anders gewesen, wenn entweder die Geräte mal neu gestartet gewesen worden wären oder die Verbindung von FHEM zu mosquitto neu aufgebaut worden wäre (FHEM-restart oder evtl. auch set active/disable... oä). Evtl. könnte da im Wiki noch was ergänzt werden (?).
Beachte ich auch gerne. Wenn ich mein Netz neu aufbaue (komme da erst Mitte nächster Woche zu)  gebe ich hierzu noch mal Feedback, was eventuell klarer dargestellt werden kann oder wo mir etwas fehlt.
Viele Grüße
Sascha
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 09 November 2019, 14:22:11
Hi,

mein Ziel wäre gewesen: Ich liefere einen Patch... (ich will keine Kritik üben, ich will nur meinen Eindruck aufschreiben)
Ich scheitere:
- ich müsste wissen wie man ein Patch erstellt, da bin ich aber am lesen. Das allein scheint nicht so schwer :)
- ich müsste wissen wie das mit dem attrTemplate erstellen wirklich geht. Ist mir auf die Schnelle zu undurchsichtig. Hier (https://wiki.fhem.de/wiki/AttrTemplate) stehen ein paar Fragmente, für mich ist es zu wenig und gleichzeitig zuviel. Wenn man sich durch den "dritten" Link gearbeitet hat qualmt der Kopf :)
Da ich jetzt erstmal ein paar Wochen weg von FHEM sein werde, will ich aber noch mein Ergebnis der letzten Tage teilen:

Ich habe mir die Themen attrTemplate MQTT(2) und HTTPMOD (ich weiß Beta-User Du suchst Mitstreiter-ich bin noch weit davon entfernt ;) ) am Shelly PlugS angeschaut.
Basis war ein aktuelles FHEM, MQTT2_SERVER, die API (https://shelly-api-docs.shelly.cloud/#shelly-family-overview)
Ich habe mit wirklich viel Recherche und Tests diese Minimalvariante gebaut. Die hat keinen Schnickschnack (wie Icon usw) und kann aus meiner Sicht alles was die mqtt API Shelly derzeit hergibt.
defmod shellyplug_s_2 MQTT2_DEVICE
attr shellyplug_s_2 IODev mqtt2s
attr shellyplug_s_2 readingList shellies/shellyplug-s-040E41/online:.* online\
shellies/announce:.* { $EVENT =~ m,..id...shellyplug-s-040E41...mac.*, ? json2nameValue($EVENT) : undef }\
shellies/shellyplug-s-040E41/relay/0/power:.* power\
shellies/shellyplug-s-040E41/relay/0:.* state\
shellies/shellyplug-s-040E41/temperature:.* temperature\
shellies/shellyplug-s-040E41/temperature_f:.* temperature_f\
shellies/shellyplug-s-040E41/overtemperature:.* overtemperature\
shellies/shellyplug-s-040E41/relay/0/energy:.* energy
attr shellyplug_s_2 room MQTT2_DEVICE
attr shellyplug_s_2 setList request_announces:noArg {"shellies/shellyplug-s-040E41/command announce"}\
reading_update:noArg {"shellies/shellyplug-s-040E41/command update"}\
do_fw_update:noArg {"shellies/shellyplug-s-040E41/command update_fw"}\
off:noArg {"shellies/shellyplug-s-040E41/relay/0/command off"}\
on:noArg {"shellies/shellyplug-s-040E41/relay/0/command on"}
Was mich daran stört: Es sind ein Haufen Befehle (on-for-timer usw.) in der List die so nicht vorhanden und auch nicht einfach umsetzbar sind. (ginge mit HTTPMOD)
Kann man die automatische Befehlsliste auch unterdrücken / eindämmen?

Zum Vergleich, das Ergebnis was allein mit autocreate aus dieser Nachricht
shellies/shellyplug-s-040E41/relay/0/power 0.00
shellies/shellyplug-s-040E41/relay/0 off
shellies/shellyplug-s-040E41/temperature 29.81
shellies/shellyplug-s-040E41/temperature_f 85.65
shellies/shellyplug-s-040E41/overtemperature 0
entsteht:
defmod MQTT2_shellyplug_s_040E41 MQTT2_DEVICE shellyplug_s_040E41
attr MQTT2_shellyplug_s_040E41 IODev mqtt2s
attr MQTT2_shellyplug_s_040E41 readingList shellyplug_s_040E41:shellies/shellyplug-s-040E41/relay/0/power:.* relay_0_power\
shellyplug_s_040E41:shellies/shellyplug-s-040E41/relay/0:.* relay_0\
shellyplug_s_040E41:shellies/shellyplug-s-040E41/temperature_f:.* temperature_f\
shellyplug_s_040E41:shellies/shellyplug-s-040E41/overtemperature:.* overtemperature
attr MQTT2_shellyplug_s_040E41 room MQTT2_DEVICE
Auffällig ist, dass dabei ein Eintrag für temperature_f (die Temp in Fahrenheit) entsteht, die temperature (in Celsius) aber weggelassen wird. Ist das eine Nachlässigkeit in autocreate vom MQTT2?

Jetzt habe ich das attrTemplate shellyplug angewendet:
defmod MQTT2_shellyplug_s_040E41 MQTT2_DEVICE shellyplug_s_040E41
attr MQTT2_shellyplug_s_040E41 IODev mqtt2s
attr MQTT2_shellyplug_s_040E41 devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";;;; my $light = ReadingsVal($name,"state","off");;;; my $show = '<a href="';;;;$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">';;;;$show .= FW_makeImage("10px-kreis-".$onl)."</a>";;;; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a>" }
attr MQTT2_shellyplug_s_040E41 getList power:noArg shellies/shellyplug-s-040E41/relay/power power
attr MQTT2_shellyplug_s_040E41 model shellyplug
attr MQTT2_shellyplug_s_040E41 readingList shellies/shellyplug-s-040E41/relay/0:.* state\
  shellies/shellyplug-s-040E41/relay/0:.* relay0\
  shellies/shellyplug-s-040E41/input/0:.* input0\
  shellies/shellyplug-s-040E41/online:.* online\
  shellies/shellyplug-s-040E41/announce:.* { json2nameValue($EVENT) }\
  shellies/announce:.* { $EVENT =~ m,..id...shellyplug-s-040E41...mac.*, ? json2nameValue($EVENT) : undef }\
shellyplug_s_040E41:shellies/shellyplug-s-040E41/relay/0/power:.* relay_0_power\
shellyplug_s_040E41:shellies/shellyplug-s-040E41/temperature_f:.* temperature_f\
shellyplug_s_040E41:shellies/shellyplug-s-040E41/overtemperature:.* overtemperature
attr MQTT2_shellyplug_s_040E41 room MQTT2_DEVICE
attr MQTT2_shellyplug_s_040E41 setList off:noArg shellies/shellyplug-s-040E41/relay/0/command off\
  on:noArg shellies/shellyplug-s-040E41/relay/0/command on\
  x_update:noArg shellies/shellyplug-s-040E41/command update_fw\
  x_mqttcom shellies/shellyplug-s-040E41/command $EVTPART1
da fällt mir folgendes auf:
getList
- dieser Eintrag ist nicht funktional
readingList
Die readings sind nicht komplett im Template und werden sofort wieder von autocreate ergänzt?
- temperature und energy fehlt
- shellies/shellyplug-s-040E41/announce: und ... input: gibt es meines Wissens in der shelly Antwort nicht
setList
- announce fehlt. Wobei der Eintrag aus dem Template shelly_announces (könnte man ja zusätzlich anwenden) einen request an alle shelly Geräte auslöst. Das find ich nicht gut.
- update fehlt, stattdessen gibt es ->
- x_mqttcom ist aus meiner Sicht überflüssig weil man alle 5 Kommandos hinterlegen kann.

Ich habe noch ein HTTPMOD Device angelegt, mit dem kann man den Shelly PlugS konfigurieren. Das poste ich an andere Stelle (https://forum.fhem.de/index.php/topic,97694.30.html).

Gruß Otto
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 09 November 2019, 14:58:17
Hmmm,

(ich hoffe, ich erwische jetzt alle angerissenen Dinge, sonst bitte nachfragen):

- Als template wäre wohl besser das mit energy metering gewesen, da sind temperature und energy schon drin, wenn ich das richtig sehe (ich habe nur sehr wenige MQTT-Geräte selbst und muß mich daher auf Zuarbeit verlassen).

- Es gibt gewisse Ungereimtheiten, die aus einer Änderung der Philosophie der shelly-firmware herrühren; das mit dem announce war ursprünglich mal nicht über eine zentrale Stelle gelöst, sondern pro Device. Insgesamt wäre es mMn. (beachte: das ist eine Aussage ohne Praxiserfahrung mit den Geräten und daher sehr "der Spur nach"!) sinnvoll, da die Struktur so zu ändern, dass es eben ein zentrales (announce-) Device gibt, über das updates abgewickelt werden, das braucht man eigentlich nicht "überall", das macht nur den Code und die Nachrichtenauswertung kompliziert...

- Das was du "automatische Befehlsliste" nennst, kommt wohl von den SetExtensions? Und bei dem on-for-timer ist ein auf dem Aktor laufender Timer (statt den aus SE) gemeint? (Geht afaik via MQTT (noch) nicht).

- Das mit temperature verstehe ich nicht. Es scheint jedenfalls dann nach der 2. Meldung wieder in die rL ergänzt zu werden. Ist natürlich irritierend, wenn die erste Meldung "verschluckt" wird, warum auch immer (vermute ein regex-"Problem"). Das ist jedenfalls Bestandteil der pm-Varianten, und daher m.E. jedenfalls kein template-Thema.

- das "plug"-template (mit der getList) ist vermutlich eine Art Karteileiche, wenn die getList keinen Sinn macht, ist das ganze template überflüssig... Werde jedenfalls zumindest mal die getList deaktivieren, mal sehen, ob die irgendjemand fehlt... Dass da "input" dran ist, ist dem Umstand geschuldet, dass da intern das allgemeine shelly-template angewendet wird, und da scheint es einen Button zu geben. Wenn der beim "plug" fehlt, könnte man das ausbauen, aber ob das erforderlich ist, ist eine andere Frage (es ist halt eine überflüssige Zeile, die macht aber auch von alleine keinen Unsinn, sondern nur hier keinen großen Sinn).

- x_mqttcom: Da hatten wir in dem Shelly-Thread afaik eine Diskussion zu (hier nur aus dem Kopf): Klar kann man das technisch gesehen auseinanderdröseln, aber eigentlich sind das Experten-Optionen, die der normale User eigentlich nicht braucht. Dann bekommt er eine ganze Liste und fragt sich, was er damit soll...
Bin da aber leidenschaftslos.

Was HTTPMOD für die shellys angeht, bin ich skeptisch, ob bzw. inwieweit das Vorteile gg. pah's Modul bietet; das ist uU. im Prinzip Doppelarbeit?
Bin da aber schon mangels Hardware nicht durch und will mich damit auch nicht belasten; wie du schreibst: dass ich HTTPMOD-template-Maintainer bin, ist eher eine Notlösung...

Schönen Urlaub jedenfalls,

Gruß, Beta-User
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 09 November 2019, 15:29:19
 :)
Wie immer in FHEM - viele Lösungen. Klar gibt es noch das Modul von pah - das habe ich mir nicht angeschaut, da für mich die mqtt Variante optimal scheint.

Anregung: Ich würde Templates immer so minimalistisch wie möglich in die Distribution nehmen. Wie Du schon sagst, da bekommt der User sonst einen "Riesenstrauß" und sieht nicht mehr was eigentlich wichtig ist.

SetExtensions: Ja offenbar. In dem Moment wo die setList on und off kennt, kommt das webCmd in die Übersicht und die setExtension Liste in die Auswahlbox.
Aber bei mqtt gehen (ja auch in allen anderen Fällen) meines Wissens ja dann immer nur erstmal on und off. Jeden weiteren setExtension Befehl müsste man ja zu Fuß in die setList stricken. Insofern würde ich mir dort weniger wünschen. Aber das ist sicher auch ein tiefer liegender FHEM Automatismus ;) und kein Template Thema.
Das war ja jetzt ein gedanklicher Fehler von mir  :o natürlich gehen alle Befehle in der setExtension - klar nur in FHEM und nicht autark in der Hardware.
Für den on-for-timer kann man sicher ein Stück perlcode machen, dafür alleine ist ein HTTPMOD Device überzogen ;)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: aperoap am 10 November 2019, 11:22:51
Hallo Zusammen,
betreibe seit paar Wochen auch zigbee Komponente bei mir. Bis vor eine Woche habe ich MQTT(mosquitto) und zigbee2mqtt von Koenkk mit cc3251 als Controller und ein cc3251 Router betrieben. Seit eine Woche bin ich auf mqtt2 Server umgestigen un mosquitto gelöscht.
Soweit läuft alles und kann betrieben werden. Die integrierten Templates sind hervorragend.

Problem:

-Der Router wurde erkannt und als mqtt2 device angelegt.
 meldet sich minütlich bei Controller und setzt folgende readings.
Readings
associatedWith MQTT2_zigbee_0x00Xxxxxxxxx 2019-11-09 08:18:50
led_state true 2019-11-09 08:35:50
linkquality 0 2019-11-09 08:35:50
state true 2019-11-09 08:35:50
ich habe leider kein template gefunden, welches (online / offline) Anzeigt wie mqtt.

Anbei Screenshots von komplettes List und angelege mqtt2device.

Der Status bleibt immer auf true, wird minütlich aktualisiert und wechselt nicht auf false auch wenn nicht aktualisiert wird.

Den Vorschlag von Beta-User finde ich sehr gut:
- Vermutlich würde es Sinn machen, in dem Fall auch die Verbindungsqualität irgendwie zu visualisieren (farbig?).

Wäre echt Super.

Ob man LED mit mqtt schalten kann habe ich nicht ausprobiert. Werde ich heute Abend versuchen und berichten. ;)

P.S.

Beta-User ich hoffe bin richtig hier ;)


Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 11 November 2019, 08:30:50
@aperoap:
Hier bist du richtig :) .

Zunächst mal wäre es natürlich hilfreich, wenn nicht FHEM einen Timer verwalten müßte, um online/offline zu erkennen. Ich meine, dazu gäbe es eine timeout-Option in der yaml, die für alle netzbetriebenen Geräte gültig ist (=>bitte selbst suchen; die entsprechende Option müßte dann in den comment-Text des attrTemplates!).

Für die linkquality hatte ich schon in der Antwort in "contributing" nach dem erwartbaren Wertebereich gefragt, das müßte man dann in ein Farbschema übersetzen. "0" finde ich jedenfalls nicht selbsterklärend. Ist das nun "sehr gut" oder "erdenliedrig"?!?

Für zukünftige Fälle:
Screenshots sind wenig hilfreich, einfacher zu handhaben ist Text, einzupacken in Code-Tags ("#"-Button). Für MQTT2_DEVICE und attrTemplate gerne auch im RAW-Format.


@Otto123:
Die templates sind so, wie die user das haben wollten, die sich aktiv beteiligt haben; das feedback dazu war tendenziell sehr positiv.
Ich sehe das zwar auch so, dass manches nicht erforderlich wäre, aber zum einen ist "abspecken" tendenziell einfacher, wie was dazu zu basteln, oder ich müßte mehrere Varianten anbieten, was auch entsprechender Pflegeaufwand ist.

Im Moment ist user sledge dabei, v.a. das devStateIcon-Thema im Wiki zu erweitern, um da dann auch andere, (einfachere) Varianten auzuzeigen. Wie herum wir das dann am Ende machen: mMn. noch offen (ich tendiere auch leicht zu "weniger ist mehr")...

Was shelly-on-for-timer angeht: die IP-Adresse ist ja bekannt, da kann man vermutlich schon eine HTTP-Lösung basteln (braucht dann aber Passwörter, die man irgendwo eingibt, abspeichert...).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: aperoap am 11 November 2019, 20:32:12
Hi Beta, Danke erstmal für den Tipp mit dem timeout. Hab jetzt in /opt/zigbee2mqtt/data/configuration.yaml mit availability_timeout: 60 timeout definiert. Dadurch bekomme ich folgende readings
 defmod MQTT2_zigbee_0x00124b000be88fe7 MQTT2_DEVICE zigbee_0x00124b000be88fe7
attr MQTT2_zigbee_0x00124b000be88fe7 IODev MQTT2_SERVER
attr MQTT2_zigbee_0x00124b000be88fe7 alias Router_CC2531_EG_WC
attr MQTT2_zigbee_0x00124b000be88fe7 group Bridge
attr MQTT2_zigbee_0x00124b000be88fe7 icon mqtt_device
attr MQTT2_zigbee_0x00124b000be88fe7 imageLink /fhem/deviceimages/mqtt2/CC2530.ROUTER.jpg
attr MQTT2_zigbee_0x00124b000be88fe7 readingList zigbee2mqtt/0x00124b000be88fe7:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00124b000be88fe7/availability:.* availability
attr MQTT2_zigbee_0x00124b000be88fe7 room MQTT2_DEVICE

setstate MQTT2_zigbee_0x00124b000be88fe7 true
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-11 19:20:40 associatedWith MQTT2_mqttjs_f6b1e812
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-11 20:16:46 availability online
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-11 20:17:19 led_state true
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-11 20:17:19 linkquality 0
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-11 20:17:19 state true
Ist der Router aus, bekommt availability offline state bleibt weiterhin auf true.
"devStateIcon" bezieht sich doch immer auf "state" oder kann man das auf availability beziehen und virsualisieren mit grüne und rote punkte?

Das mit "linkquality" verstehe ich auch nicht. Die Geräte sind meistens auf 0.

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 12 November 2019, 09:14:43
...wenn wir beide linkquality nicht verstehen, lassen wir es erst mal weg...

Was devStateIcon angeht, solltest du dich erst mal noch etwas einlesen, wobei das Attribut selbst nicht völlig isoliert im Raum steht ;) . Startpunkte vielleicht: https://wiki.fhem.de/wiki/DeviceOverview_anpassen und https://wiki.fhem.de/wiki/DevStateIcon

Im file mqtt2.template sind auch einige Variante vorhanden, für online/offline z.B. auch für die zigbee2mqtt-bridge, wenn ich das richtig im Kopf habe.
Würde vorschlagen, du schaust dich ein wenig um und versuchst zunmindest eine erste Version, dann können wir das ggf. erforderlichenfalls weiter optimieren?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: aperoap am 12 November 2019, 20:43:35
Sie sieht das mittlerweile bei mir aus
defmod MQTT2_zigbee_0x00124b000be88fe7 MQTT2_DEVICE zigbee_0x00124b000be88fe7
attr MQTT2_zigbee_0x00124b000be88fe7 IODev MQTT2_SERVER
attr MQTT2_zigbee_0x00124b000be88fe7 alias Router_CC2531_EG_WC
attr MQTT2_zigbee_0x00124b000be88fe7 devStateIcon online:rc_GREEN offline:rc_RED
attr MQTT2_zigbee_0x00124b000be88fe7 group Bridge
attr MQTT2_zigbee_0x00124b000be88fe7 icon mqtt_device
attr MQTT2_zigbee_0x00124b000be88fe7 imageLink /fhem/deviceimages/mqtt2/CC2530.ROUTER.jpg
attr MQTT2_zigbee_0x00124b000be88fe7 readingList zigbee2mqtt/0x00124b000be88fe7/availability:.* availability\
zigbee2mqtt/0x00124b000be88fe7:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_0x00124b000be88fe7 room MQTT2_DEVICE
attr MQTT2_zigbee_0x00124b000be88fe7 stateFormat availability

setstate MQTT2_zigbee_0x00124b000be88fe7 online
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-12 20:01:24 associatedWith MQTT2_mqttjs_f6b1e812
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-12 20:34:25 availability online
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-12 20:38:24 led_state true
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-12 20:38:24 linkquality 0
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-12 20:38:24 state true

Ist sehr einfach gehalten. Zeigt jedoch wenn der Router offline oder online ist mit rc_GREN und rc_RED.

Was hältst du davon, kann man das besser machen? :-)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 14 November 2019, 16:06:30
Besser ist immer relativ.

Habe das availability jetzt direkt zu state gemacht, weiß aber noch nicht, ob das soooo toll ist. Bei "normalen" routern, z.B. Leuchten ist das nicht so toll, und dann hat man unterschiedliche Readingnamen für dieselbe Sache (=> Rückmeldung erbeten!)...

Wenn man weitere Dinge hat zum Anzeigen, finde ich die kleinen Punkte eigentlich ganz nett (10px-Icons), die bei den Shelly-templates für on-/offline verwendet werden. Aber für die Anzeige "solo" sind die eben auch sehr klein...

Wie dem auch sei, Vorschlag mdB. um Test:
#A pure router device, e.g. a CC2531 flashed with router firmware
#Contributed by aperoap, https://forum.fhem.de/index.php/topic,94494.msg992467.html#msg992467
name:zigbee2mqtt_router_only_device
desc: For zigbee2mqtt pure router devices, e.g. a CC2531 flashed with router firmware. To get information on device going offline, set "availability_timeout" to a reasonable value in zigbee2mqtt's configruation.yaml.
filter:TYPE=MQTT2_DEVICE:FILTER=CID=zigbee.*
order:L_02a1
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[\b]?([^/:]+)[/].*:, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/]([^/]+).*:, ? $1 : undef }
par:ICON;ICON as set, defaults to light_control;{ AttrVal("DEVICE","icon","mqtt_device") }
attr DEVICE icon ICON
attr DEVICE devStateIcon online:rc_GREEN offline:rc_RED
attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }\
  BASE_TOPIC/DEV_ID/availability:.* state
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE comment To get also information on device going offline, set "availability_timeout" to a reasonable value in configruation.yaml.
farewell:template has been applied successfully. Please check configuration.yaml to get regular updates on availability.
attr DEVICE model zigbee2mqtt_router_only_device
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: aperoap am 14 November 2019, 19:31:15
hallo,
availability jetzt direkt zu state habe ich auch schon ausprobiert gehabt.zigbee2mqtt/xxxxxxx/availability:.* stateProblem: availability und state werten in unterschiedlichen Zeitpunkten aktualisiert ist STATE nicht mit stateFormat in attr. definiert, bekommt STATE automatisch den Wert von state sobald state aktualisiert, somit wechselt STATE zwischen online und true. Daher habe ich in meinem Beispiel mit stateFormat mit availability in attr. gesetzt.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: ulli am 17 November 2019, 17:02:55
Hallo zusammen,
ich nutze schon erfolgreich einige xiaomi Sensoren.
Bei anderen Komponenenten Werte ich über das Monitoring Modul den Batterie Status erfolgreich aus.
Leider stellt das mqtt template kein reading mit batteriestatus bereit, daher geht mein monitoring Modul nicht mit den Xiaomis.

Wie macht ihr das? Könnte man das Batterie reading ggf umbenennen in batterie_pct und ändert das Batterie reading in einen Status ok,low

Was denkt ihr?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 17 November 2019, 19:04:11
Ich weiss nicht wie die Readings in deinem Fall angelegt sind, es gibt aber mehrere Moeglichkeiten diese umzubennen.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 18 November 2019, 11:08:28
Leider stellt das mqtt template kein reading mit batteriestatus bereit, daher geht mein monitoring Modul nicht mit den Xiaomis.

Wie macht ihr das? Könnte man das Batterie reading ggf umbenennen in batterie_pct und ändert das Batterie reading in einen Status ok,low

Was denkt ihr?
batterie_pct finde ich nicht gut, wir sollten uns entweder an dem rrientieren, was der Autor von zigbee2mqtt sich gedacht hatte ("battery"), oder diesen Wert in eine Reading-Nomenklatur überführen, der "FHEM-konform" ist, siehe dazu auch diese Diskussion (https://forum.fhem.de/index.php/topic,87575.0.html). Danach wäre es batteryPercent, am einfachsten für die zigbee2mqtt-Batterie-Geräte wohl zu realisieren über ein JSONMAP.

Tendenziell würde ich mich dagegen aussprechen, hier weitere Auswertungen via template dazu zu basteln, das will am Ende jeder anders haben bzw. die Grenzwerte anders setzen usw., jedenfalls besteht die Gefahr, dass das nicht mehr als "ermittelter Wert" für jeden erkennbar ist. Wenn jemand einen Vorschlag macht, kann ich das gerne entweder als eine Art "add-on" versuchen mit reinzubasteln, oder wir übernehmen das als erweiterte Nutzerkonfigurations-Option in die "Praxisbeispiele".

Wer dazu was liefern will: Erweiterte Funktion json2nameValue verwenden ("json2nameValue($EVENT,'',$JSONMAP)") und ein passendes Attribut ("attr <device> jsonMap battery:batteryPercent").
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 25 November 2019, 13:40:19
Via pm hat jemand angemerkt, dass für den shellydimmer pct versendet, aber brightness (im JSON) zurückgemeldet wird, damit scheint der "Rückweg" nicht ganz geschlossen zu sein. Da aber der Wertebereich lt. https://shelly-api-docs.shelly.cloud/#dimmer-sl-settings nur bis 100 geht, erscheint mir der Name "pct" logischer, als es nach brightness umzubenennen (so wird es im JSON übertragen).

Daher die allgemeine Frage an die Gemeinde: ich würde dazu tendieren, Helligkeitswerte von 0-255 in das "brightness"-Reading zu schieben, und solche im Bereich 0-100 nach "pct".

Frage: Gibt es dazu Einwände?
(Im Moment scheint das nur die Shelly-Nutzer (shellydimmer, shelly2rgbw_4w_split, shelly2rgbw_color) zu betreffen, die wären also vorrangig aufgefordert, ihre Meinung abzugeben... Das wirkt sich übrigens auch nur aus, wenn man das template nochmal anwendet, vorhandene Konfigurationen werden - wie immer bei attrTemplate - nicht automatisch angetastet!).

Das fragliche template für den shellydimmer sähe dann so aus, bitte testen:
#shellydimmer
# contributed by zeppelin, https://forum.fhem.de/index.php/topic,94495.msg994764.html#msg994764
name:shellydimmer
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shellydimmer <br>Tested with 20191119-085746/master@e3a747f5
order:A_18
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
par:ICON;ICON as set, defaults to light_control;{ AttrVal("DEVICE","icon","light_control") }
attr DEVICE icon ICON
attr DEVICE setList\
  off:noArg shellies/DEVNAME/light/0/command off\
  on:noArg shellies/DEVNAME/light/0/command on\
  pct:slider,0,1,100 shellies/DEVNAME/light/0/set {"turn": "on","brightness": $EVTPART1}\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
deletereading -q DEVICE status_.*
attr DEVICE readingList \
  shellies/DEVNAME/light/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}\
  shellies/DEVNAME/temperature:.* temperature\
  shellies/DEVNAME/temperature_f:.* temperature_f\
  shellies/DEVNAME/overtemperature:.* overtemperature\
  shellies/DEVNAME/overload:.* overload\
  shellies/DEVNAME/loaderror:.* loaderror\
  shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : undef }
attr DEVICE webCmd pct:on:off
attr DEVICE jsonMap brightness:pct
attr DEVICE devStateIcon {my $lderr = ReadingsVal($name,"loaderror","true") eq "true"?"10px-kreis-rot":"10px-kreis-gruen";; my $light = ReadingsVal($name,"ison","false") eq "true"?"on":"off";; my $cons = ReadingsVal($name,"light_0_power","unknown");; FW_makeImage($lderr)."<a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Leistung: $cons</div>"}
set DEVICE x_mqttcom announce
attr DEVICE model shellydimmer

Gruß, Beta-User
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 25 November 2019, 14:23:35
Hallo zusammen,

ich selber habe keinen Shelly Dimmer. Allerdings habe ich den RGBW2. Bei dem sehe ich keine Probleme. Außer, das ich diesen nicht sauber über Alexa steuern kann. Bei rot oder weiß macht er nicht ganz mit. Aber das ist wohl nur eine Kleinigkeit in der Umrechnung der von Alexa gewollten Werte... Habe ich mich aber auch nicht weiter mit beschäftigt, da aktuell wenig Zeit.

Was den Dimmer angeht - Macht es in meinen Augen schon Sinn über PCT zu arbeiten. Alleine wegen der Alexa Steuerung. Geht bei Rollos, geht bei anderen Lampen und sollte einheitlich sein.

Gruß,
Kai / jemand :-P
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 25 November 2019, 14:38:05
@87insane:
Ist die Rückmeldung so zu verstehen, dass du das mit der jsonMap im RGBW2 ausgetestet hattest?
(@all: Das sollte da bzw. auch bei dem dritten) genauso funktionieren, wenn die erste Zeile der readingList geändert und das attr jsonMap (ggf. auch bei den weiteren Kanälen) auf "brightness:pct" gesetzt wird).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 25 November 2019, 15:23:09
Hi nochmal,

jsonMap: Nein. Ich hatte nur mal ein wenig quer gelesen. Was will Alexa, was machen/geben die Geräte und was geht direkt, bei welchen Werten, mit welchen Readings. Da blau und grün z.B. super geht und auch Mix Farben, in denen Rot mit drin ist, kann ich auch nicht alle Geräte falsch verkabelt haben ;)
Müsste das bei mir genutzte Template zum RGBW2 auch mal gegen das aktuelle im SVN legen. Ich weiß nicht ob Du/Ihr ggf. noch was geändert hattet, nachdem ich das nutzte... Prüfe das mal eben...

EDIT: Habe mal drüber gesehen. Scheint keine Änderungen mehr gegeben zu haben, die hier relevant wären. Nutze die rgb_on usw Setter. Finde das mit Alexa besser, da diese dann auch direkt das Licht an macht und nicht nur die Modi einstellt.

Nochmal EDIT: Da wir aber schon dabei sind.. Ich habe an dem RGBW2 Template nicht mit gewirkt und ggf. liegt es daran, dass ich das nicht ganz checke. Es gibt ein Userreading, welches rgb ein wenig anders darstellt.
   
rgb:red.* {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);"$a$a$a"}}

Kann mir das einer kurz erklären? Ich sehe es soll auf rot.* Änderungen reagieren. Danach wird die Mode abgefragt und die Werte der Farben eingesetzt. Wen die Mode nicht Color ist, wird $a definiert. In $a wird die Helligkeit rein geschrieben wenn keine Farbe aktiv..
Warum bzw wofür das ganze genau?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 27 November 2019, 12:47:40
Zu dem RGBW2:
Der Shelly braucht als Input getrennte Angaben für die drei Farben (als JSON) und liefert das auch so zurück. Ist die Farbe weiß, sind alle drei Kanäle gleich. Lesend findest du das z.B. im userReadings als "$a$a$a", schreibend, indem "plötzlich" brightness+white gesendet wird. Da der Hex-Wert (hier: $a) sich aber mit der Helligkeit ändert, wird eben bei der Auswertung eine Variable verwendet und kein fester Wert, wobei zwischendurch noch eine Umrechnung von pct (0-100) nach hex (00-ff=255) sein muß...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 02 Dezember 2019, 17:50:25
Hallo zusammen,

Frage/Anregung allgemein zu Tasmota, nachdem ich so langsam aber sicher auch verstanden habe, wie das mit dem JSONMAPing funktioniert und das Thema hier (https://forum.fhem.de/index.php/topic,105901.0.html) hochkam:

Die Tasmota-Geräte verwenden in der Regel POWER1 für die Rückmeldung zum ersten Kanal. Häufig gibt der das Hauptreading wieder, sollte also optimalerweise nach "state" (entsprechend bei den mehrkanaligen "split"-Versionen dann für POWER2 usw.). Das wäre recht einfach mit JSONMAP zu machen, allerdings wäre das ein breaking change.
In der readingList wäre der Eintrag für RESULT zu ändern in
stat/sonoff3/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }und statt der stateFormat-Sache würde man
attr DEVICE jsonMap POWER1:statesetzen.
Wer es weiter wie bisher haben will, müßte dann stateFormat beibehalten und das jsonMap-Attribut löschen.

Ich tendiere dazu, das bei allen Tasmotas dann bei Gelegenheit so umzusetzen (evtl. mit zwei Converter-templates zum vereinfachten Umstellen), aber wenn es große Einwände gibt, gilt wie immer: Ihr bekommt, was ihr bestellt...

Grüße, Beta-User


Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 03 Dezember 2019, 09:29:29
Hey und guten Morgen,

anbei mal die kompletten Infos zum ShellyDimmer. Hab mir diese von einem anderen Kollegen mit einem solchen besorgt. Ggf. klärt es das noch offene Thema mit den pct.

shellies/shellydimmer-bla/light/0/set {"turn": "on","brightness": 35}
shellies/shellydimmer-bla/light/0 on
shellies/shellydimmer-bla/light/0/status {"ison":true,"mode":"white","brightness":35}
shellies/shellydimmer-bla/temperature 43.74
shellies/shellydimmer-bla/temperature_f 110.74
shellies/shellydimmer-bla/overtemperature 0
shellies/shellydimmer-bla/overload 0
shellies/shellydimmer-bla/loaderror 0
shellies/shellydimmer-bla/light/0/power 9.56
shellies/shellydimmer-bla/online true

Gruß,
Kai
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 12 Dezember 2019, 07:17:19
Hey und guten Morgen,

an anderer Stelle hatte mich jemand gefragt ob es mögliche seie bei Geräten, die sehr geringe Spannung aufweisen, eine Art Prüfung laufen zu lassen. Bei den Shellys (nicht alles aber z.B. Plug S) ist es so, dass unter 1W nicht immer sauber gemessen wird.
Nun ist es so das der Plug S an der Stelle z.B. immer mal wieder was an FHEM sendet. Ich habe mir das in so fern zu nutze gemacht, als das ich das Template vom washer genommen habe und dort eine kleine Anpassung. Anstelle von Wert unter x, wird hier einfach geprüft ob das Reading älter als y ist. Tatsächlich eine sehr kleine Anpassung aber bringt den gewünschten Erfolg. Vielleicht ist das für jemanden interessant :)


Das hier muss weg (Readingslist):
shellies/SHELLY_NAME/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? "off":"on"; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : undef }



und das hier soll dahin (Readingslist):
shellies/SHELLY_NAME/relay/0/power:.* { my $compare = ReadingsAge($NAME,"relay_0_power",3800) > 3600 ? "off":"on"; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : undef }

Gruß,
Kai
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 12 Dezember 2019, 07:41:10
Guten Morgen nochmal,

im washer Template hat sich ein kleiner Fehler eingeschlichen. devStateIcon geht bei aktuellem Verbrauch auf das reading "power", müsste aber auf relay_0_power.

falsch:
attr DEVICE devStateIcon { my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $pic = ReadingsVal($name,"loadState","") eq "on"?'scene_laundry_room_fem@green':'scene_laundry_room_fem';; my $text = ReadingsVal($name,"loadState","") eq "on"?"Waschmaschine läuft - Aktuell: ".ReadingsVal($name,"power","")." W":'Standby';; my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";; "<div> $show ".FW_makeImage($pic)." $text </div>" }

richtig:
attr DEVICE devStateIcon { my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $pic = ReadingsVal($name,"loadState","") eq "on"?'scene_laundry_room_fem@green':'scene_laundry_room_fem';; my $text = ReadingsVal($name,"loadState","") eq "on"?"Waschmaschine läuft - Aktuell: ".ReadingsVal($name,"relay_0_power","")." W":'Standby';; my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";; "<div> $show ".FW_makeImage($pic)." $text </div>" }


Gruß,
Kai
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 12 Dezember 2019, 16:39:39
Thx, hab's eingecheckt!

Neu ist auch ein template für den Mexcio YX-DE02 (https://forum.fhem.de/index.php/topic,106227.msg1000955.html#msg1000955) (bzw- DE04). Die habe ich selbst seit einigen Tagen, sind ganz interessant, da die einen USB-Anschluß haben (ich habe eigentlich nach einem Ladegerät gesucht..., und dazu noch eine farbige LED, die mal als Statusanzeige dienen soll). Da habe ich das auch mit dem jsonMap anders gelöst als bisher, was vor allem deswegen interessant ist, weil man aus den "gesplitteten" Mehrkanaligen damit auch die Readings in den weiteren Devices verbannen kann, die man da gar nicht braucht...

Sonst wundert mich etwas, dass dazu keiner was sagen will/kann?!?
Ich tendiere dazu, das bei allen Tasmotas dann bei Gelegenheit so umzusetzen (evtl. mit zwei Converter-templates zum vereinfachten Umstellen), aber wenn es große Einwände gibt, gilt wie immer: Ihr bekommt, was ihr bestellt...
Ungetestete erste Version der Umstellungstemplates wäre hier (https://forum.fhem.de/index.php/topic,105968.msg998921.html#msg998921) zu finden; vielleicht komme ich noch dazu, das in Ruhe auszutesten, wird aber vermutlich bis nächstest Jahr dauern, vielleicht mag jemand das ja optimieren?!?

Gruß, Beta-User
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 12 Dezember 2019, 19:03:51
Naja...hab auch USB-Steckdosen. Da lädt einer großer Akku aber auch ewig dran. Bei denen SICHER auch. Für eine Nacht-Ladung, sicher gut aber nicht für mal eben schnell.

jsonMap gefällt mir :) Bin gespannt wie es am Ende genutzt wird.
Noch offen ist z.B. Shelly Dimmer. Da meldet sich leider auch keiner. Die meisten nutzen das umbiegen oder doppelte erfassen. Das Template steht aber noch aus.
Gleiches auch für "Alexa - Wohnzimmer weiß", bei Shelly im RGBW2 Template. Dabei kommt rot rauß. Shelly selber bzw. Teracomunications wissen auch nicht wie sie das hinbekommen sollen. Die Programmiere von denen baten offiziell um Hilfe  :o - Scheint mir ein wenig auf Alexa Seite oder Skill/Mapping Anpassung. Fhem kann das doch sicher! :)
Titel: Tasmota - falsches devStateIcon - setlist mit Eingabefeld für Tasmota möglich?
Beitrag von: bigtruite am 13 Dezember 2019, 10:43:23
Hallo,

ich mach seit gestern meine ersten Schritte in Richtung MQTT2_Server, MQTT2_Devices etc. Ihr habt echt eine gute Arbeit gemacht... :-) Ich habe seit gestern einen LED-Controller (Arilux LC01 mit Tasmota) und eine Gosund SP111 (mit Tasmota) über MQTT2_Server bzw. MQTT2_Devices laufen. Läuft echt rund.

Folgendes ist mir aufgefallen.

1. Beim Template "tasmota_rgb_led_controller" muss das devStateIcon geändert werden. Sonst reagiert das Icon nicht. Ich habe es abgeändert und "Dimmer" entfernt. Obowohl es laut Wiki so passen würde. Geht aber nicht. Jetzt gehen dimmer, Farbei und Ein- und Aus. Könntet ihr das Prüfen und buxfixen?
Richtig: {Color::devStateIcon($name,"rgb","Color","POWER1")}

2. Ich schlage vor bei den Templates der "Tasmota"-Familie die Setlist um den Namen "Command" um einem Eingabefeld zu erweitern, damit man dort direkt einen Tasmota Befehl (siehe https://github.com/arendst/Tasmota/wiki/commands (https://github.com/arendst/Tasmota/wiki/commands)) ausführen kann, der nicht in der Setlist enthalten ist. Damit erschlagen wir enorm viel. Und damit würde man sich das (umständliche) absetzen über über einen MQTT Publish über den MQTT2_Server sparen. Da muss man nämlich wieder das Topic raussuchen etc.

Könntet ihr bitte 1 fixen? Was haltet ihr von Punkt 2? Gebt mir Bescheid.






Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 13 Dezember 2019, 13:03:48
Vorab mal Danke für das feedback :)

Ad 1:
Danke für's Nachforschen.
Habe grade versucht, das für meine Maxcio YX-DE02 (template: tasmota_plug_with_rgb_split, Tasmota 7.1.2) anzupassen, da war schon etwas ratlos, warum das da nicht geklappt hatte. Ergebnis war aber auch negativ...
Allerdings ist da jsonMap mit im Spiel (es wird daher "state" statt "POWERx" verwendet) und der Tasmota liefert einen 8-stelligen Farbwert (mit 00 am Ende, das ist wohl die Opacity) zurück. Letzteres scheint scheint das eigentliche Problem zu sein, jedenfalls bei einem dunklen Hintergrund sieht man nichts; evtl. liefert bei dir Dimmer auch nichts verwertbares zurück (?), mit den jswonMap-"pct"-Werten aus dem anderen Template (tasmota_plug_with_rgb_split) klappt das jedenfalls auch wie im Wiki angegeben (wenn man das Reading manuell auf einen 6-stelligen Wert ändert), und auch der Code ist so wie im Wiki dargestellt.
Müßte man wohl mal auf Theo/das Tasmota-Team (weglassen bzw. senden des korrekten Werts in der firmware?) oder Andre zugehen, ob man da in Color.pm was ändern kann/sollte (das Wegkürzen der Info wäre aber vermutlich farbtechnisch falsch, wenn denn die "00" heute richtig ist...).

Ist das bei dir (noch) anders und du bekommst einen 6-Stelligen hex-Wert?

Grundsätzlich würde ich das template (wie alle Tasmotas) gerne auf die jsonMap-Variante umstellen, von daher wäre das dann gleich Teil einer größeren Lösung...

Ad 2:
Bin da gespalten. Einerseits ist es eine Vereinfachung für die, die das brauchen/wollen, andererseits ist es ein "erklärungsbedürftiger Setter" für den Rest der user. Neige daher dazu, das zur Vereinfachung aus den attrTemplates draußen zu halten. Es spricht aber überhaupt nichts dagegen, das im Wiki (mit Beispielen) aufzunehmen (das darf gerne jemand anderes machen).
Aber ich bin da leidenschaftslos, bei den shellys gab's auch genügend Fürsprecher, die das "x_mqttcom" haben wollten. Wie dort sollte es aber möglichst durch die Namenswahl ans Ende gestellt werden (selber Name? (da selbe Funktion?!?)).

Gruß, Beta-User
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: bigtruite am 13 Dezember 2019, 13:24:35
Sehr gerne fürs Feedback,

zu 1.
bei meinem Arilux LC-01 mit Tasmota 6.7.1 wird ein 6 stelliger Farbwert übermittelt. Folgender Publish aus der Tasmota Console...
13:10:17 MQT: stat/LED_Leiste/RESULT = {"POWER1":"on","Dimmer":100,"Color":"FF0000","HSBColor":"0,100,100","Channel":[100,0,0]}

bei meinem Arilux LC-06mit Tasmota 6.5.0.7 folgender Farbwert.... (wobei der RGB Farbe, WW und CW hat)
13:22:44 MQT: lc06/lc06/stat/RESULT = {"POWER":"ON","Dimmer":100,"Color":"00FF0000","HSBColor":"120,100,100","Channel":[0,100,0,0]}

das angeführte Problem hatte ich mit dem Arilux LC-01 mit Tasmota 6.7.1

zu 2.
ich sehe es anders, wenn es um spezielle Features geht... der eine will eine Updatefunktion drin haben. Der andere dies und jenes... aber hier geht es nur um ein Eingabefeld für gleichermaßen alle CMD Befehle.... damit erschlagen wir alles.... über die Namenswahl könnte man reden. Ich habe kein Shelly... Am Ende wäre gut... wie wäre es mit "x_command" oder von mir aus auch gerne "x_mqttcom", dann wäre es mit den Shellies gleich ?

grüße bigtruite


Vorab mal Danke für das feedback :)

Ad 1:
Danke für's Nachforschen.
Habe grade versucht, das für meine Maxcio YX-DE02 (template: tasmota_plug_with_rgb_split, Tasmota 7.1.2) anzupassen, da war schon etwas ratlos, warum das da nicht geklappt hatte. Ergebnis war aber auch negativ...
Allerdings ist da jsonMap mit im Spiel (es wird daher "state" statt "POWERx" verwendet) und der Tasmota liefert einen 8-stelligen Farbwert (mit 00 am Ende, das ist wohl die Opacity) zurück. Letzteres scheint scheint das eigentliche Problem zu sein, jedenfalls bei einem dunklen Hintergrund sieht man nichts; evtl. liefert bei dir Dimmer auch nichts verwertbares zurück (?), mit den jswonMap-"pct"-Werten aus dem anderen Template (tasmota_plug_with_rgb_split) klappt das jedenfalls auch wie im Wiki angegeben (wenn man das Reading manuell auf einen 6-stelligen Wert ändert), und auch der Code ist so wie im Wiki dargestellt.
Müßte man wohl mal auf Theo/das Tasmota-Team (weglassen bzw. senden des korrekten Werts in der firmware?) oder Andre zugehen, ob man da in Color.pm was ändern kann/sollte (das Wegkürzen der Info wäre aber vermutlich farbtechnisch falsch, wenn denn die "00" heute richtig ist...).

Ist das bei dir (noch) anders und du bekommst einen 6-Stelligen hex-Wert?

Grundsätzlich würde ich das template (wie alle Tasmotas) gerne auf die jsonMap-Variante umstellen, von daher wäre das dann gleich Teil einer größeren Lösung...

Ad 2:
Bin da gespalten. Einerseits ist es eine Vereinfachung für die, die das brauchen/wollen, andererseits ist es ein "erklärungsbedürftiger Setter" für den Rest der user. Neige daher dazu, das zur Vereinfachung aus den attrTemplates draußen zu halten. Es spricht aber überhaupt nichts dagegen, das im Wiki (mit Beispielen) aufzunehmen (das darf gerne jemand anderes machen).
Aber ich bin da leidenschaftslos, bei den shellys gab's auch genügend Fürsprecher, die das "x_mqttcom" haben wollten. Wie dort sollte es aber möglichst durch die Namenswahl ans Ende gestellt werden (selber Name? (da selbe Funktion?!?)).

Gruß, Beta-User
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 13 Dezember 2019, 14:19:24
Hmm, zu der Tasmota-Stellenanzahl siehe https://github.com/arendst/Tasmota/wiki/Lights. Geht also vorrangig wohl darum, ob auch Weiß vorhanden ist. Muß mal hirnen, ob man dafür einen separaten Setter braucht/haben will und was der ggf. bewirkt. Irgendwie unschön (was den link zu Color.pm angeht).

Der Code in Color.pm geht auch davon aus, dass Dimmer auf 0 geht, wenn das Ding aus ist; daher funktioniert das mit dem Schalten (vermeintlich?) nicht? Muß mal checken, ob da in Zeile 501 eigentlich was ähnliches reingehört wie in Zeilen 443ff.

Was command angeht, hatte ich schon verstanden, dass das generisch gemeint war, habe aber zu wenig Erfahrung, um
a) sagen zu können, dass das Sinn macht (ich bezweifle das nach wie vor auch bei den shellys) und
b) ob es dasselbe ist (wenn ja, sollte man wenn, dann denselben Namen nehmen, wenn nein, grade anders rum....).

(Und du brauchst mich nicht vollst. zu zitieren bei Antworten; in der Regel editiere ich nichts nachträglich rum oder lösche Beiträge... (Voll-) Zitate machen m.E. ansonsten erst dann Sinn, wenn es sonst schwierig ist, den Kontekt zu erfassen, z.B. weil zu viel anderes dazwischengerutscht ist.)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: bigtruite am 13 Dezember 2019, 14:32:28
Gut ich dachte die E-Mailbenachrichtungsfunktion geht nur wenn man zitiert. --> zur Kenntnis genommen. Wie müsste ich die Setlist manuell verändern, damit ich das Eingabefeld habe. 
   
off:noArg cmnd/LED_Leiste/POWER1 0
  on:noArg cmnd/LED_Leiste/POWER1 1
  toggle:noArg cmnd/LED_Leiste/POWER1 2
  Color:colorpicker,RGB cmnd/LED_Leiste/COLOR
  Dimmer:colorpicker,BRI,0,5,100 cmnd/LED_Leiste/DIMMER
  x_mqttcom:textField cmnd/LED_Leiste

Das neue rote klappt nicht. Was ist falsch?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: sledge am 13 Dezember 2019, 14:41:42
Naja...hab auch USB-Steckdosen. Da lädt einer großer Akku aber auch ewig dran. Bei denen SICHER auch. Für eine Nacht-Ladung, sicher gut aber nicht für mal eben schnell.

jsonMap gefällt mir :) Bin gespannt wie es am Ende genutzt wird.
Noch offen ist z.B. Shelly Dimmer. Da meldet sich leider auch keiner. Die meisten nutzen das umbiegen oder doppelte erfassen. Das Template steht aber noch aus.
Gleiches auch für "Alexa - Wohnzimmer weiß", bei Shelly im RGBW2 Template. Dabei kommt rot rauß. Shelly selber bzw. Teracomunications wissen auch nicht wie sie das hinbekommen sollen. Die Programmiere von denen baten offiziell um Hilfe  :o - Scheint mir ein wenig auf Alexa Seite oder Skill/Mapping Anpassung. Fhem kann das doch sicher! :)
Ich nutze zwar die Shelly RGBW2, aber eben nur mit weißen Stripes. Werde mir wohl mal einen RGB-Streifen besorgen müssen, dann kann ich mir das ja mal anschauen. Und auch ggf das Template korrigieren.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 13 Dezember 2019, 14:42:50
Ich nutze zwar die Shelly RGBW2, aber eben nur mit weißen Stripes. Werde mir wohl mal einen RGB-Streifen besorgen müssen, dann kann ich mir das ja mal anschauen. Und auch ggf das Template korrigieren.
Mega gut! Danke!

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: sledge am 13 Dezember 2019, 14:53:04
Gut ich dachte die E-Mailbenachrichtungsfunktion geht nur wenn man zitiert. --> zur Kenntnis genommen. Wie müsste ich die Setlist manuell verändern, damit ich das Eingabefeld habe. 
   

  x_mqttcom:textField cmnd/LED_Leiste

Das neue rote klappt nicht. Was ist falsch?
Schonmal die Setlist der Shelly angeschaut? Ist ja im template-File zu sehen.

Here we go:
x_mqttcom shellies/DEVICE/command $EVTPART1
Wobei ich das Feature nicht benötige, es mir aber auch egal ist.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: bigtruite am 13 Dezember 2019, 14:57:50
Ich finde die Readings aus stat/LED_Leiste/RESULT schon wichtig. Möchte sie definitiv nicht missen... Mir gehts nicht nur um POWER1...... bitte drinnen lassen.

Hallo zusammen,

Frage/Anregung allgemein zu Tasmota, nachdem ich so langsam aber sicher auch verstanden habe, wie das mit dem JSONMAPing funktioniert und das Thema hier (https://forum.fhem.de/index.php/topic,105901.0.html) hochkam:

Die Tasmota-Geräte verwenden in der Regel POWER1 für die Rückmeldung zum ersten Kanal. Häufig gibt der das Hauptreading wieder, sollte also optimalerweise nach "state" (entsprechend bei den mehrkanaligen "split"-Versionen dann für POWER2 usw.). Das wäre recht einfach mit JSONMAP zu machen, allerdings wäre das ein breaking change.
In der readingList wäre der Eintrag für RESULT zu ändern in
stat/sonoff3/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }und statt der stateFormat-Sache würde man
attr DEVICE jsonMap POWER1:statesetzen.
Wer es weiter wie bisher haben will, müßte dann stateFormat beibehalten und das jsonMap-Attribut löschen.

Ich tendiere dazu, das bei allen Tasmotas dann bei Gelegenheit so umzusetzen (evtl. mit zwei Converter-templates zum vereinfachten Umstellen), aber wenn es große Einwände gibt, gilt wie immer: Ihr bekommt, was ihr bestellt...

Grüße, Beta-User
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 13 Dezember 2019, 15:23:34
Bei dem Shelly (shelly2rgbw_color) kapiere ich nicht recht, wo auf template-Seite das Problem sein könnte. Es gibt doch einen on-setter bzw. weiß-setter... Wenn es darüber geht, das Ding zu schalten, ist die Frage hier m.E. OT und irgendwo bei Sprachsteuerung zu führen. Wenn es Probleme gibt, darüber zu schalten, können wir überlegen, da was zu ändern, um bugs in der firmware zu kompensieren, aber das scheint ja nicht das Problem zu sein, oder?

(OT: der YX-irgendwas liefert jedenfalls nominal min. 4x so viel wie das Ladegerät, das grade fest verbaut ist... Sollte also eine Verbesserung sein, unabhängig davon, ob es eine gute Lösung ist. Außerdem wollte ich mal OTA-Tasmota-flashing testen :P , und da sah' das nach einem "interessanten" Gerät aus ::) .) 

Was das devStateIcon angeht: Zeile 499 in Color erweitern um/auf
... || $onoff && ::ReadingsVal($name,$onoff,undef) =~ m,off,i);scheint das Problem mit on/off zu beheben, ohne dass man auf die Dimmer-Anzeige verzichten muß.

Zum jsonMap: Es bleiben alle nicht genannten Readings erhalten mit dem alten Namen. Nur POWER1 würde zu "state", was z.B. das mapping für Sprachsteuerung deutlich vereinfachen sollte (es gab früher Leute, die extra dafür ein userReadings angelegt haben...).
Erst bei dem 2. Kanal von mehrkanaligen wäre zu überlegen, ob man das Doppeln von Readings verhindert (mit "not-wanted-reading:0"). Prototyp dazu: der YX-DE...  ;) .

Das neue rote klappt nicht. Was ist falsch?
Wie von sledge bereits angemerkt: Es muß was übergeben werden (z.B. $EVTPART1). Vermutlich ist das aber nicht das, was du willst (ich vermute mehrere Leerzeichen-separierte Worte, wovon ein Teil zum Topictree gehört? Dann wäre eine umfangreiche Perl-Nachbearbeitung erforderlich => m.E. ein nogo, da für Nichtexperten komplett unverständlich, auch in der Anwendung...)

Zitat
Gut ich dachte die E-Mailbenachrichtungsfunktion geht nur wenn man zitiert. --> zur Kenntnis genommen.
Kann durchaus sein, aber jedenfalls ich nutze das Forum anders, und ein Vollzitat dürfte nicht erforderlich sein.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 13 Dezember 2019, 15:26:57
Was Alexa usw angeht hast du vermutlich recht wegen OT. Hier sind aber die, die es betrifft. An dem Modul für alexa muss nix geändert werden. Maximal am mapping und das wäre in meinen Augen wieder Template.

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 13 Dezember 2019, 15:57:02
Schon, aber mMn. "ein besonderes" (oder mehrere).

Meine Bitte wäre: Mach' ggf. dazu einen separaten Thread auf, den du gerne für interessierte Mitleser hier von hier aus verlinken darfst. Wenn es dann konkrete Ideen gibt, was ggf. in template-Form (option:...) gegossen werden kann, mache ich mir dazu auch Gedanken, aber so ist es vermutlich nicht wirklich zielführend, da mir das alles nichts sagt.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 13 Dezember 2019, 15:58:27
Hat sich doch schon jemand gemeldet :) wenn das so nicht klappt, dann deine Idee. Denke aber er bekommt das hin :)

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:Tasmota - falsches devStateIcon - setlist mit Eingabefeld für Tasmota möglich?
Beitrag von: Beta-User am 14 Dezember 2019, 18:14:02
Folgendes ist mir aufgefallen.

1. Beim Template "tasmota_rgb_led_controller" muss das devStateIcon geändert werden.
 [...]

Könntet ihr bitte 1 fixen?
Andre hat Color.pm freundlicherweise erweitert; jetzt sollte auch die lange Version korrekte Ergebnisse liefern. Bitte testen (kommt mit update morgen früh).

Was die 8-stelligen hex-Werte angeht, scheint es so zu sein, dass man auch den Weiß-Kanal mit darüber steuern kann/könnte.
Jedenfalls wird's bei "set  MQTT2_DVES_EFFE7E_CH2 Color 00000088" hell in Weiß...
Es gibt aber afaik bisher noch keine Implementierung für einen Setter oder eine Auswertung der Rückmeldung dazu, update für die YX-DE0x folgt bei Gelegenheit.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: bigtruite am 15 Dezember 2019, 10:52:36
Hab es mit meinem Arilux-01 unter Tasmota und dem Template tasmota_rgb_led_controller getestet. Mit den Standardsettings

devStateIcon {Color::devStateIcon($name,"rgb","Color","Dimmer","POWER1")}
 funktioniert jetzt auch die Farbe des Icons. Dimmer geht. Und beim Klicken auf das Icon toggelt es... besten dank.  :D
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 15 Dezember 2019, 11:00:17
Immer wieder gerne  :) .

Habe eben noch zwei kleine Änderungen vorgeschlagen; mit der einen würde dann auch die Anzeige im "Weiß"-Modus auf die Standardhintergrundfarbe wechseln, wenn nur weiß an ist (die andere betrifft reine Dimmer).

Ein neues/zusätzliches attrTemplate für rgbw-Devices (mit Steuermöglichkeit für den Weiß-Anteil) folgt dann bei Gelegenheit.
Frage: Das benötigt separate Slider für pct und weiß. Welche nehmen? 2*BRI oder lieber BRI+CT (das paßt dann aber nicht so recht von der Farbgebung her).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: vbs am 19 Dezember 2019, 18:18:53
Eine Anmerkung zu den Templates (evtl. versteh ich es auch einfach falsch):

Die Templates heißen z.B. "zigbee2mqtt_Light_Switch". Ich finde das erstmal sehr unspezifisch. Wenn man es anwählt, dann bekommt zwar noch eine Beschreibung:
Zitat
Smart light switch 2btn via zigbee2mqtt
Tested with: Xiaomi Aqara WXKG02LM 2btn Smart Light Switch

Aber man weiß trotzdem nicht, für welche konkreten Geräte das Template funktioniert. Klar, der Ersteller hat es vermutlich auch nur für ein Gerät entwickelt und getestet und theoretisch könnte es "zufällig" auch für andere Geräte funktionieren. Wenn ich mir ein neues zigbee-Gerät kaufe, dann finde ich es schwierig herauszufinden, welches Template ich nehmen muss und ob das Template ordnungsgemäß funktioniert.

Ich denke, ich fände es besser, wenn die Templates auf konkrete Geräte zugeschnitten wären, die dann auch im Namen auftauchen.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: vbs am 19 Dezember 2019, 19:02:03
Würde eigentlich gerne noch ein Frage anschließen:
Wenn ich jetzt ein Template poste, was ich für "Aqara Opple" verwende (inhaltlich eigentlich nichts Spezielles). Wie soll ich das nennen? Es ist eigentlich identisch mit "Wireless Button", aber ohne "action" im stateFormat.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 19 Dezember 2019, 19:19:09
Naja, die Namen Vergabe und auch der Inhalt waren für mich am Anfang wie bei dir.  Fand es "komisch".


ABER dem ist nicht so. Mittlerweile (einige templates später) sehe ich es als gut an, wie es ist.

Hintergrund ist ja der, das man in der Theorie alles mögliche da rein werfen könnte. Die templates dienen aber als inspiration, sind aber voll benutzbar und sicher die meisten, sehr gut gelöst. Deswegen gibt es zu einer Sache / Gerät auch fast immer nur ein Template. Man stelle sich vor, es wären sonst wegen jedem Kram diverse Templates. Dann wäre der Sinn aus dem folgendem text verloren :-P

Wegen der Namen. Verhält sich das nicht gerätespezifisch, weil es diverse geräte gibt die gleich gesteuert werden. Somit kannst du Gerät X mit einer Funktion Y ausstatten. Bei den shellys zb geht das natürlich nicht wie mit Geräten die mit tasmota geflasht wurden. Deswegen wirst du bei den shellys auch meist Namen der Geräte finden im template Namen. Bei x Schaltern, die aber mit tasmota geflasht sind wiederum, wirst du nur die Funktion, als Name finden. Warum? Weil es einfacher ist und auch Sinn ergibt. Umgekehrt, wenn du auf einen shelly tasmota flasht, muss du natürlich auch ein tasmota Template wählen. Kannst aber wegen der Funktions Wahl, dann auch direkt zb tasmota Rollo nutzen oder oder oder....

Aber ich gebe dir recht. Am Anfang war das für mich auch komisch.

Hoffe ich konnte es verständlich erklären und wünsche einen schönen Abend.

Gruß,
Kai

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: vbs am 19 Dezember 2019, 20:04:27
Hm, ich verstehe schon worauf du hinaus willst. Aber mMn funktioniert das für mich als User nur, wenn ich fundiertes Wissen habe 1.) über die interne Funktionweise/Nachrichten meines MQTT-Geräts und 2.) über die Internas der Templates bzw. welche Templates wie arbeiten.

Aber vielleicht fehlt mir einfach noch das nötige Verständnis oder die Übung. Lass mich nochmal anders herum fragen:

Konkreter Fall: Ich hab jetzt hier ein "Aqara Opple". Das ist ein Wandtaster mit 6 Buttons. Das Gerät hab ich in zigbee2mqtt angelegt und ein Device wurde in FHEM angelegt. Also fehlt mir jetzt zu meinem Glück nur noch ein passendes Template. Wie muss ich jetzt vorgehen, um herauszufinden, ob es ein passendes Template gibt, mit dem ich das Teil vollständig nutzen kann?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 19 Dezember 2019, 20:24:15
Du hast zum suchen vier Dinge (denke ich).
- Protokoll (hast du)
- Funktion / was soll es machen (hast du / denke ich mal)
- Anzahl der Knöpfe (hast du / hilft bei der Suche aber nur manchmal)
- Beschreibung

Das alles kannst du außerhalb von fhem in der mqtt2 Template Datei lesen. Da steht sowohl der Quelltext als auch die Beschreibungen, die du im fhem siehst. Wenn du ein wenig dahinter geblickt hast, siehst du dann auch direkt was es macht. Ich selber tue mich schwer bei Farb umrechnungen. Die templates verstehe ich zwar aber nicht die Umrechnung bei all diesen Varianten. Ist aber auch egal, da man die Funktion als solche nachvollziehen kann.

Wenn aber alle stricke reißen, dann einfach mal überlegen was willst du am ende willst. Also die Funktion. Danacg, alles passende einfach mal testen. Meist bleiben eh nicht mehr als 2 über. Ansonsten hilft hier schreiben meist :)
Ich selber hab den Schalter nicht aber mir fällt gerade auch nicht ein wofür. Wofür willst du ihn am ende nutzen?

Ach ja und als Bonus kannst du dich in der template Datei immer inspirieren lassen. Hast du also zb mal ein Template besonders gut gefunden und willst Funktionen für ein anderes Gerät haben, weil es zb gut aussah oder aber ne gute Funktion enthalten war, kann man sie daraus kopieren.

Gruß,
Kai

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 19 Dezember 2019, 22:49:08
Schnelle Kurzfassung:
- Es ist heute nicht alles optimal, ja; man lernt gelegentlich dazu... (heißt nicht, dass es schlecht ist, aber verbesserungsfähig, eben noch nicht optimal)
- meine Tendenz geht teilweise zu jsonMap-Nutzung (@zigbee2mqtt: Doppelrelais-Beispiel), würde gerne auch die bestehenden in diese Richtung umbauen (teilweise statt stateFormat, betrifft auch tasmota).
- zigbee2mqtt abstrahiert bereits recht weitgehend => Produktnamen machen da im Namen keinen Sinn, die gehören mMn. nach desc; ist heute leider bei weitem nicht vollständig.
- Der 6-fach-Taster ist eventuell was neues, oder eben eine weitere Variante einer Fernbedienung  (analog der großen runden Tradfri und ein paar anderen wie dem cube) mit etwas anderen Events, die man sowieso anderweitig weiterverwendet. Wenn ganz anders, macht es Sinn, da ein entsprechendes neues template zu bauen, man kann eventuell "template-in-template" nutzen, um gleiches vorneweg zu machen. Wenn nein, sollte man ggf. (nur?) die jsonMap für die einzelnen Typen unterschiedlich machen. Bräuchte mehr Info, kann mich aber voraussichtlich erst im neuen Jahr wieder kümmern.

Vielleicht mag zwischenzeitlich jemand mit schon etwas mehr Übung mal über ein RAW drübersehen und helfen; bitte auch Events für diverse Tastendrücke dazu liefern und ggf. die JSON-Blobs mitschneiden...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: vbs am 20 Dezember 2019, 13:38:45
Ok, danke, sollte auch keine Beschwerde sein. Nur mal so als Usability Rückmeldung eins unbedarften Users ;) Klappt ja alles soweit und ich finde die Struktur in FHEM zum Handling auch technisch sinnvoll und schön modular. Hat aber eben auch eine gewisse Komplexität.

Einzige sinnvolle Infos, die ich zum Gerät finden konnte, sind hier im Video:
https://youtu.be/L62IO4sPQV8?t=18

Im Moment sehe ich jedoch nur single-Presses und wenn man eine Sekunde gedrückt hält, bekomme ich ein Hold-Event und beim Loslassen ein Release. Komischerweise klappt das nur auf den mittleren beiden Buttons (also 3 & 4). Im Video ist ja eigentlich von Long-Press-Events die Rede. Evtl. ist das so gewollt, evtl. geht da aber auch irgendwo auf dem Weg etwas in die Hose.

Ich werde das jetzt erstmal so machen, dass ich mir für die Geräte-Typen, die ich benutze, Kopien der Templates mit konkreten Typ-Namen als User-Templates anlege.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 20 Dezember 2019, 13:42:50
Kurz weil Handy: kopier dir einfach aus den ganzen Templates deinen Wunsch zusammen. Das ganze kannst du am ende dann vorstellen und ggf sind noch wünsche offen. Da kann dann jeder hier helfen. Ende vom Lied, es gäbe ein neues Template und alle sind glücklich :)

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 20 Dezember 2019, 14:19:12
...hatte das auch nicht als Beschwerde aufgefaßt...

Wie gesagt: Es ist noch nicht perfekt, und vieles (eigentlich das meiste, was Informationsmöglichkeiten zu den einzelnen templates angeht und viel von der Funktionalität) ist erst im Verlauf der Zeit entstanden. Die volle Bandbreite aller Optionen ist von daher eben eigentlich noch bei keinem der templates reingearbeitet usw..
Wenn dann mal wieder jemand kommt und sich (zurecht!) traut, Fragen zu stellen, ist das eine gute Sache!

(Und ich habe selbst praktisch keine Hardware; ich kam von der MiLight-Ecke her, hatte kurz mit zigbee2mqtt experimentiert und neulich erst meinen ersten Tasmota in vorläufigen Produktivbetrieb genommen... => das meiste beruht auf dem, was mir jemand zugerufen hat, und teils wollte ich dann nicht mit noch mehr Rückfragen, kritischen Anmerkungen & Experimenten "nerven", (gell, Kai...!), das war teilweise schon so "recht viel").

(@Kai: auch wenn es eine ganze Anzahl von "Showcases" und Varianten gibt: für Standarddevices sollte ein user recht einfach zu dem auf seine Anforderung passenden template finden; erst wer "etwas mehr" will oder spezielle Anforderungen hat, darf/soll/kann in der file nach Belieben wühlen...).

Was die Benennung angeht:
"zigbee2mqtt_Light_Switch" sollte man wohl nach "zigbee2mqtt_Relay_w_2_buttons" oder "zigbee2mqtt_lightSwitch_w_2Buttons" umbenennen; an sich ist es so, dass die optimalerweise einigermaßen beschreibend sind, was sich an Readings der Optionen so dahinter verbirgt. War in dem Fall vermutlich eher nicht gelungen...

[OT]
Diesen 6-fach-Taster kannte ich noch gar nicht, die anderen/alten waren alle viel größer, oder?
Paßt der in ein "europäisches" Schalterprogramm (namentlich: Jung CD 500)? (Ich hatte eine ziemliche Enttäuschung mit einem Jung ZLL 5004, firmwareupdate ist da für Januar angekündigt, mal schauen...)
[/OT]
Wenn da keine Infos im MQTT2_DEVICE ankommen, wird evtl. von zigbee2mqtt-Seite nicht alles ausgewertet (=> Nachrichten bei zigbee sniffen wie von kkoenk beschrieben). Manchmal ist es aber auch irritierend, wie diese "Scene-Controller" funktionieren (siehe den Jung oben). Es gibt auch eine Gruppe im Forum hier, die sich die "große" tradfri vorgenommen hatten, Wissen dazu ist also auch hier vorhanden.

Und wenn du Typ-Namen hast, die zu bestimmten vorhandenen Templates passen: her damit!

Schließlich sollen es neue, "unbedarfte" Nutzer nicht schwerer haben als nötig...
Was wir also zusammen in diese Richtung hinbekommen, wird gerne eingearbeitet, und über den Weg darf man auch konträrer Ansicht sein bzw. das ausdiskutieren ;) .
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 26 Dezember 2019, 18:54:16
Wenn ich einen shelly plug s automatisch anlegen lasse und anschließend das attrTemplate shelly1 anwende, sieht das devStateIcon so aus:
{my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $light = ReadingsVal($name,"state","off");; my $show = '<a href="';;$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">';;$show .= FW_makeImage("10px-kreis-".$onl)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a>" }Da lungert ein offenes <div> im letzten Drittel ;)

Wäre das im Anhang ein Patch? :)

Gruß Otto
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: johndoe am 29 Dezember 2019, 22:45:55
Hallo zusammen,

Frage/Anregung allgemein zu Tasmota, nachdem ich so langsam aber sicher auch verstanden habe, wie das mit dem JSONMAPing funktioniert und das Thema hier (https://forum.fhem.de/index.php/topic,105901.0.html) hochkam:

Die Tasmota-Geräte verwenden in der Regel POWER1 für die Rückmeldung zum ersten Kanal. Häufig gibt der das Hauptreading wieder, sollte also optimalerweise nach "state" (entsprechend bei den mehrkanaligen "split"-Versionen dann für POWER2 usw.). Das wäre recht einfach mit JSONMAP zu machen, allerdings wäre das ein breaking change.
In der readingList wäre der Eintrag für RESULT zu ändern in
stat/sonoff3/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }und statt der stateFormat-Sache würde man
attr DEVICE jsonMap POWER1:statesetzen.
Wer es weiter wie bisher haben will, müßte dann stateFormat beibehalten und das jsonMap-Attribut löschen.

Ich tendiere dazu, das bei allen Tasmotas dann bei Gelegenheit so umzusetzen (evtl. mit zwei Converter-templates zum vereinfachten Umstellen), aber wenn es große Einwände gibt, gilt wie immer: Ihr bekommt, was ihr bestellt...

Grüße, Beta-User

Also ich wäre dafür. Ohne diese Anpassung zeigte mein Sonoff S20 dauerhaft nur set_on bzw. set_off im state an.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 30 Dezember 2019, 12:28:30
Nachdem die letzten "tasmota"-jsonMap-Rückmeldungen positiv waren, anbei eine vollständige Version, wie das zukünftig @Tasmota aussehen könnte.

Wäre nett, wenn der eine oder andere die mal testen könnte und Rückmeldung geben, ob das soweit paßt. Ich habe "in der Basis" dazu bisher keine weiteren Tests gemacht, aber das json-Mapping an sich ist erprobt, wie oben geschildert. Fehler/fehlende interne Weiterleitungen in einzelnen Fällen sind daher allerdings auch nicht ganz auszuschließen. "Umstellungstemplates" wollten mir erst mal nicht glücken, daher muß es ohne gehen, wenn niemand sonst sich kümmern mag...

Bin noch unschlüssig, ob die "alten" noch bereitgehalten werden sollten oder nicht, ich tendiere aber zum "breaking change" (wer heute konfigurierte Devices hat, kann die ja weiter nutzen und bei Bedarf auch die bisherigen attrTemplate-Versionen aus dem svn holen! Und wer Testen will, kann einfach erst mal parallel mit einer Kopie seiner funktionierenden Devices arbeiten.).

Wenn ich kein feedback bekomme, checke ich das in ca. 2 Wochen so ein...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 08 Januar 2020, 19:05:47
Hey zusammen,

anbei eine Idee um es bei dem Shelly 2.5 im Roller Mode einheitlich zu gestalten. Das Template fügt die "Ampel" mit allen Funktionen hinzu und die Icons werden in kürzerem Code abgefragt.
Hier handelt es sich rein um das Design bzw. devStateIcon.

Was haltet Ihr davon?


Normal (in meinen Augen) - (0% = Rollo ist oben - 100% = Rollo ist komplett unten/es ist dunkel im Innenraum :-P)
{
my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";;
my $con = ReadingsVal($name,"state","undef");;
my $pic = $con eq "opening" ? 'fts_shutter_up@red' : $con eq "closing" ? 'fts_shutter_down@red' : $con eq "100" ? 'fts_shutter_100' : $con =~ /(\d)\d/ ? 'fts_shutter_'.$1.'0' : $con =~ /\b\d\b/ ? 'fts_shutter_10' : 'fts_shutter_updown';;
my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";;
"<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\"></a>".FW_makeImage($pic)." </div>"
}

Invertiert (0% = Rollo ist unten - 100% = Rollo ist oben)
{
my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";;
my $con = ReadingsVal($name,"state","undef");;
$con = 100 - $con if $con =~ /\d+/;;
my $pic = $con eq "opening" ? 'fts_shutter_up@red' : $con eq "closing" ? 'fts_shutter_down@red' : $con eq "100" ? 'fts_shutter_100' : $con =~ /(\d)\d/ ? 'fts_shutter_'.$1.'0' : $con =~ /\b\d\b/ ? 'fts_shutter_10' : 'fts_shutter_updown';;
my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";;
"<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\"></a>".FW_makeImage($pic)." </div>"
}


Danke an Beta-User (Hat mir mal wieder was beigebracht) ;)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 08 Januar 2020, 21:07:30
Ist eingecheckt, samt der Umrechnung der Werte im shelly 2.5 (shellies/DEVNAME/relay/1/energy:.* {'relay_1_energy' => sprintf("%.2f",$EVENT/60/1000)}\).

Bitte melden, wenn was nicht funktioniert oder die Formel einen Hau haben sollte...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 10 Januar 2020, 12:00:34
Bitte noch stateFormat aus dem Template löschen. Ist hier ja nicht mehr notwendig...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 12 Januar 2020, 14:04:53
Wenn ich kein feedback bekomme, checke ich das in ca. 2 Wochen so ein...
So, nun ist es zu spät für kritische Rückmeldungen zu der grundsätzlichen Entscheidung, die Weichen im svn stehen auf $JSONMAP...

Es gab noch ein paar kleinere Änderungen, bin mal gespannt auf euer weiteres feedback; wie immer bei solchen Umstellungen sind Fehler leider nicht auszuschließen, hoffe, es ist mir nicht zu viel "raus" ::) .


Bitte noch stateFormat aus dem Template löschen. Ist hier ja nicht mehr notwendig...
Hmm, hatte mir das kurz angesehen, bin aber grad etwas ratlos gewesen, wie da im Moment stateFormat noch reinkommt?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: raiderxxl am 15 Januar 2020, 08:25:31
Hallo,

besteht die Chance für das WLED Template noch die Favoriten oder sogar die Effect inkl. Color-Palette einzubauen?

Gerne kann ich auch einen Meter WS2812B spendieren ;) falls keine Hardware vorhanden ist...

Grüßle

Pascal
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 15 Januar 2020, 09:27:10
Du beziehst dich auf das template "wled_controller" (für https://github.com/Aircoookie/WLED/wiki/MQTT)?

Sollte möglich sein, ist aber kein ganz einfaches Thema, weil dann die HTTP API Syntax irgendwie verarbeitet werden muß, und die kommt mir ziemlich kryptisch vor. Daher bitte dazu einen gesonderten Thread hier im MQTT-Bereich aufmachen, dann können wir auch ohne Hardware das eine oder andere Experiment machen..

In Schritt 1 könntest du die setList erweitern um einen setter nach diesem Schema
api_call BASE_ID/DEVNAME/api $EVTPART1Damit sollte sich dann der HTTP-Api-Call auch via MQTT versenden lassen, also z.B. "FX=73", um den entsprechenden Effect aufzurufen. Einzelne Dinge könnte man dann entweder dynamisch (mit Zahlenauswahl für den Effekt) oder statisch (einzelne bestimmte Effekte) in die setList einbauen.
Was "die Favoriten" sind, hat sich mir aus der API-Beschreibung nicht erschlossen, vielleicht schreibst du dann auch was dazu in dem separaten Thread.
(dto, wenn es sich um ein ganz anderes attrTemplate handeln sollte, um das es gehen soll).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: frankreed am 19 Januar 2020, 13:18:23
Hallo,

ich habe ein FHEM update gemacht und es wurde auch ein neues mqtt2.template heruntergeladen.
Dort habe ich mal reingeschaut und es stehen viele tasmota-Geräte drin.
Nur kann ich die attrTemplate weder einlesen noch werden sie mit attrTemplate ? angezeigt.
PS: shutdown restart und auch einen kompletten reboot habe ich natürlich auch schon gemacht aber? Nada....

Irgendwas stimmt mit dem Aufbau der Liste nicht bzw. Anzeige und Auswahl des entsprechenden Templates nicht.
Habe einen Sonoff Dual und will den jetzt als MQTT2-Device einrichten.

Hat jemand eine Idee?

Grüße Frank
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 19 Januar 2020, 13:30:20
Erscheinen die auch nicht in der Liste, die erscheint, wenn du set <irgendein MQTT2_DEVICE> attrTemplate ? ausführst?

In der Dropdown-Auswahl erscheinen eine ganze Anzahl der templates erst, wenn die jeweils den Filterkriterien entsprechen (idR. einen passenden readingList-Eintrag haben, der typischerweise zu autocreate@default-Einstellung der firmware passt).

Anwenden lassen sich die attrTemplates jeweils trotzdem (über die Kommandozeile), aber man muß manuell die entsprechenden Parameter-Abfragen beantworten...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: schwatter am 19 Januar 2020, 21:10:34
Ich habe hier einen HDMI-Switch, welcher mit einem Wemos D1 mini bestückt ist.
Das Projekt ist von Frank Enderle.

https://github.com/fenderle/esphome-vorke-hd41

Da ich denke, das der Personenkreis eher sehr klein ist, stelle ich hier meine "Raw definition" zur Verfügung.
Falls es interessant für ein Template ist, kann es gerne mit aufgenommen werden. Für Verbesserungsvorschläge
bin ich aber auch dankbar  :)

defmod Vorke_HD41_HdmiSwitch MQTT2_DEVICE vorke_hd41_demo_2cf4321291b8
attr Vorke_HD41_HdmiSwitch IODev myFhembroker
attr Vorke_HD41_HdmiSwitch autocreate 0
attr Vorke_HD41_HdmiSwitch icon rc_HDMI
attr Vorke_HD41_HdmiSwitch oldreadings debug
attr Vorke_HD41_HdmiSwitch readingList vorke_hd41_demo_2cf4321291b8:vorke_hd41_demo/debug:.* { $EVENT =~ s/\033.*?m//g;; { debug=>$EVENT } }
attr Vorke_HD41_HdmiSwitch room 03.Wohnzimmer,MQTT2_DEVICE
attr Vorke_HD41_HdmiSwitch setList HDMI:input_1_source,input_2_source,input_3_source,input_4_source,auto_source vorke_hd41_demo/switch/$EVTPART1/command ON\
AUTOSOURCE:ON,OFF vorke_hd41_demo/switch/auto_source/command $EVTPART1\
AUDIO:stereo_20,dolbydts_51,hd_audio_71,auto_edid vorke_hd41_demo/switch/$EVTPART1/command ON\
ARC:ON,OFF vorke_hd41_demo/switch/arc/command $EVTPART1
attr Vorke_HD41_HdmiSwitch stateFormat {OldReadingsVal($name,"debug","undef")}
attr Vorke_HD41_HdmiSwitch webCmd HDMI:AUTOSOURCE:AUDIO:ARC

setstate Vorke_HD41_HdmiSwitch [D][switch:045]: 'Input 2 Source': Sending state ON
setstate Vorke_HD41_HdmiSwitch 2020-01-19 20:44:07 debug [D][switch:045]: 'Input 1 Source': Sending state OFF
setstate Vorke_HD41_HdmiSwitch 2020-01-19 20:44:07 state HDMI

2 Besonderheiten
-  das Topic debug wurde wegen Ansi Escape Sequenzen erweitert -> s/\033.*?m//g.
-  oldreadings, da das letzte Reading immer den State OFF vom vorherigen Input/Source ausgibt.

2020-01-19 21:07:41 MQTT2_DEVICE Vorke_HD41_HdmiSwitch debug: [D][switch:021]: 'Input 1 Source' Turning ON.
2020-01-19 21:07:41 MQTT2_DEVICE Vorke_HD41_HdmiSwitch debug: [D][switch:045]: 'Input 1 Source': Sending state ON
2020-01-19 21:07:41 MQTT2_DEVICE Vorke_HD41_HdmiSwitch debug: [D][switch:045]: 'Input 2 Source': Sending state OFF
2020-01-19 21:07:56 MQTT2_DEVICE Vorke_HD41_HdmiSwitch HDMI
2020-01-19 21:07:57 MQTT2_DEVICE Vorke_HD41_HdmiSwitch debug: [D][switch:021]: 'Input 2 Source' Turning ON.
2020-01-19 21:07:57 MQTT2_DEVICE Vorke_HD41_HdmiSwitch debug: [D][switch:045]: 'Input 2 Source': Sending state ON
2020-01-19 21:07:57 MQTT2_DEVICE Vorke_HD41_HdmiSwitch debug: [D][switch:045]: 'Input 1 Source': Sending state OFF
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: frankreed am 20 Januar 2020, 09:42:12
Erscheinen die auch nicht in der Liste, die erscheint, wenn du set <irgendein MQTT2_DEVICE> attrTemplate ? ausführst?

Das hab' ich noch nicht versucht, mache ich aber mal.

In der Dropdown-Auswahl erscheinen eine ganze Anzahl der templates erst, wenn die jeweils den Filterkriterien entsprechen (idR. einen passenden readingList-Eintrag haben, der typischerweise zu autocreate@default-Einstellung der firmware passt).

Sorry das blick' ich nicht was Du meinst. Ich kann im Zusammenhang mit der Tasmota-Firmware nichts mit autocreate anfangen. Und wie kann ich denn die Filterkriterien setzen?

Ich dachte mir, ich gehe beim Anlegen so vor, dass ich ein MQTT2_Device so anlege:

1. define xyz MQTT2_DEVICE
2. Mir dann im angelegten Device in der Auswahlliste bei set xyz attrTemplate alle templates aus mqtt2.template angezeigt werden und ich dann nur noch das passende auswählen muss.

Aber irgendwie werden mir beim beschriebenen Weg nur einige templates angezeigt, sprich die Gesamtliste ist gefiltert. Aber einen Filter habe ich ja nicht gesetzt....
Wo ist mein Denkfehler?

PS: Achso, als Broker habe ich einen mosquitto-Server laufen, der über den MQTT2-Client eingebunden ist.

Grüße

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 20 Januar 2020, 10:54:48
Zitat
Aber einen Filter habe ich ja nicht gesetzt....
Wo ist mein Denkfehler?
Der Filter wird im template gesetzt, damit Geraete nichts "irrelevantes" angeboten bekommen.

Normalerweise veroeffentlicht ein MQTT Geraet nach der Verbindung mit dem Server ein Topic, autocreate legt ein Device an, und aus der Nachricht wird auch sofort ein Reading erstellt. attrTemplate kann anhand reading/readingList raten, was fuer ein Geraet das ist, und das Angebot filtern.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 20 Januar 2020, 10:58:51
...etwas zu langsam, aber ausführlicher:
Zitat
PS: Achso, als Broker habe ich einen mosquitto-Server laufen, der über den MQTT2-Client eingebunden ist.
Ok, "the hard way"...

Wenn du keine MQTT_GENERIC_BRIDGE am Start hast und dein Broker nur Daten verwaltet, die du letztlich in FHEM haben willst, kannst du am CLIENT auch "autocreate" auf "simple" stellen und dann so vorgehen, wie im Wiki zu MQTT2_CLIENT beschrieben (das "Sortierdevice" konfigurieren).

Ansonsten:

Ich kann im Zusammenhang mit der Tasmota-Firmware nichts mit autocreate anfangen. Und wie kann ich denn die Filterkriterien setzen?
autocreate bezieht sich dabei (fast) immer auf das MQTT2-IO in FHEM, das ist völlig unabhängig von der Frage, wie der externe Client (z.B. die Tasmota-firmware) tickt...
Du brauchst für "autocreate" also ein aktives "autocreate-Device" (TYPE=autocreate), und das Attribut "autocreate" am IO (hier MQTT2_CLIENT).

Zitat
Ich dachte mir, ich gehe beim Anlegen so vor, dass ich ein MQTT2_Device so anlege:

1. define xyz MQTT2_DEVICE
2. Mir dann im angelegten Device in der Auswahlliste bei set xyz attrTemplate alle templates aus mqtt2.template angezeigt werden und ich dann nur noch das passende auswählen muss.

Aber irgendwie werden mir beim beschriebenen Weg nur einige templates angezeigt, sprich die Gesamtliste ist gefiltert. Aber einen Filter habe ich ja nicht gesetzt....
Die Filter definiere ich als Maintainer der template-File. Indem du nicht autocreate nutzt, profitierst du eben nicht davon, dass jeweils nur das angezeigt wird, was grade relevant ist, sondern hast "das Problem", dass das meiste weggefiltert wird.
Wie geschrieben: Anwenden kann man die "nur gefilterten" templates trotzdem, nur dann eben über die Kommandozeile, wobei man dann eben die weiteren Angaben (v.a. betreffend die Topic-Struktur) in dem Dialogfeld eingeben muß, das man dann angezeigt bekommt.
Es ist mAn. aber einfacher, erst mal wenigstens einen readingList-Eintrag (nämlich bei Tasmota den "LWT") manuell zu setzen (TELETOPIC/LWT:.* LWT), was da für "TELETOPIC" steht, ist nämlich der Topic-Tree-Eintrag, der für die automatische Parametrierung verwendet wird. Da kannst du auch gleich sehen, ob die Verbindung an sich klappt...

PS: demnächst wird es ein update geben, das das prereq:-feature nutzt, dann sind manche templates gar nicht mehr ausführbar, da schon nicht geladen! Das wird z.B. die MiLight- und OpenMQTTGateway-templates betreffen, bei denen Voraussetzung ist, dass man erst mal eine Bridge definiert hat, wähl- und ausführbar bleibt dann erst mal nur das Bridge-Template...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 20 Januar 2020, 11:09:45
Da ich denke, das der Personenkreis eher sehr klein ist, stelle ich hier meine "Raw definition" zur Verfügung.
Falls es interessant für ein Template ist, kann es gerne mit aufgenommen werden.
Der Personenkreis ist sicher beschränkt, aber der Code ist mMn. wegen dem OldReadings-Teil auch für andere interessant; es wird damit ein "allgemeines" Problem gelöst, nämlich die "falsche" Reihenfolge eingehender Nachrichten. Muß mal überlegen, ob ich das vertemplate oder ggf. einfach im Wiki einarbeite...

Zitat
Für Verbesserungsvorschläge bin ich aber auch dankbar  :)
Evtl. wäre eine eventMap hifreich, um die eher technische Namensgebung der setter und Readings "anwenderfreundlicher" anzuzeigen (sonst müßte man auf Perl ausweichen). Vermutlich läuft das Ding aber eh' eher im Hintergrund, und Eventhandlern ist das egal...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: frankreed am 22 Januar 2020, 18:36:51
Sorry für die späte Rückmeldung.
Aber bei mir (Dummy) haut das nicht hin  :(

Wie geschrieben habe ich den mosquitto als Broker am Laufen, der tut.

Um die Verbindung zwischen den MQTT2-Devices in FHEM und dem externen Broker zu machen habe ich wie empfohlen einen MQTT2_CLIENT angelegt:

Raw-Definition
defmod myMQTT2Client MQTT2_CLIENT 192.168.xxx.yyy:1883
attr myMQTT2Client alias myMQTT2Client
attr myMQTT2Client autocreate complex
attr myMQTT2Client icon mqtt
attr myMQTT2Client room IO_Devices

setstate myMQTT2Client opened
setstate myMQTT2Client 2020-01-19 13:20:57 state opened

So, jetzt möchte ich einen Tasmota-Dual als MQTT2_DEVICE einrichten.
Dort habe ich in der Firmware als MQTT-topic die eindeutige Ident-Nr. eingetragen wie im WIKI (DVES_%06X im Feld topic)

In FHEM dann
define hugo MQTT2_DEVICE ?
So und nun? Nix mit dem automatischen Erkennen oder Anlegen von Readings. Auch keine Auswahl des Dual oder anderer tasmota-devices über die Auswahlliste, dort ist wie bisher nur der tasmota-basic.

Sorry ich bin zu blöd dazu oder habe die bereits gemachten guten Erklärungen nicht richtig verstanden bzw. umgesetzt.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 23 Januar 2020, 13:47:04
oder habe die bereits gemachten guten Erklärungen nicht richtig verstanden bzw. umgesetzt.

Du bist hier im flaschen Thread. Bitte einen neuen aufmachen und da auch verlinken, welche der Erklärungen du zugrunde gelegt hast, nur dann kann "jemand" die auch so gestalten, dass sie jeder versteht...

Du kannst dich auch gerne hier (https://forum.fhem.de/index.php/topic,107531.0.html) anhängen, das ist mMn. genau dasselbe Thema...

Bitte aber das "complex" durch "simple" ersetzen, das stand mit ziemlicher Sicherheit in keiner Erklärung...

Und dann bitte jeweils "list -r"-Ausgaben von folgenden devspec anfügen:

TYPE=MQTT2_DEVICE
TYPE=autocreate
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: schwatter am 02 Februar 2020, 16:46:13
@Beta-User

Du hast ein gutes Allgemeinwissen wenn es um Fhem geht  ;D
Gibt es eine Möglichkeit, Dropdownmenüs zu beschriften? Also im Dropdown(setList) ein Platzhalter, der die Funktionen wiederspiegelt.

In meinem Fall geht es im den HDMI-Switch, den ich gepostet habe. Da dieser viele verschiedene Funktionen hat,
wollte ich Settings per Dropdown splitten. Leider sieht das optisch nicht so toll aus. Ein toter Platzhalter wäre toll.


Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 02 Februar 2020, 16:55:43
Du suchst webCmdLabel

Beispiel:

attr MQTT2_ebusd_bai webCmd Hc1Heizkurve:HwcTempDesired:z1DayTemp:z1NightTemp:FlowHysteresisON:FlowHysteresisOff
attr MQTT2_ebusd_bai webCmdLabel Heizkurve &#58;;:Warmwasser\
:Tagestemperatur:Nachttemperatur\
:FlowHysteresisON:FlowHysteresisOff

Gruß

Thomas
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: schwatter am 02 Februar 2020, 16:59:13
Ja, das kenn ich. Trotzdem danke  :)

edit:

da ich keine Werte zurück erhalte, sind die Dropdown's leer. Daher bietet sich der freie Platz an.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 03 Februar 2020, 07:38:49
Gibt es eine Möglichkeit, Dropdownmenüs zu beschriften? Also im Dropdown(setList) ein Platzhalter, der die Funktionen wiederspiegelt.
Vielleicht würde "setStateList on off" helfen (macht funktional keinen Sinn, bewirkt aber, dass die Readings auf "set_xy" gehen), dazu ggf. eine eventMap? Mußt du vermutlich etwas rumspielen, vielleicht hilft "DeviceOverview anpassen" im Wiki weiter?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: KölnSolar am 03 Februar 2020, 08:35:03
Hi Beta,
kannst Du bitte hier (https://forum.fhem.de/index.php/topic,89898.msg1020388.html#msg1020388) mal mit Deinem Expertenwissen drauf gucken. Macht es Sinn das bei WENIGEN zu erwartenden USERN überhaupt in die templates mit auszunehmen ? Und wenn ja, da stecken ne Menge user-/device-spezifische zu ersetzende Strings drin. Wie müsste man die "definieren", damit ein template leicht für den individuellen Einsatz nutzbar ist.
Grüße Markus
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 03 Februar 2020, 11:24:01
Macht es Sinn das bei WENIGEN zu erwartenden USERN überhaupt in die templates mit auszunehmen ?
Weiß nicht recht... An sich bin ich geneigt, funktionierende templates auch zu veröffentlichen, es steckt - vor allem in diesen speziellen Fällen - einfach in der Regel viel Wissen drin, was ggf. auch für ähnliche Fragen weiter genutzt werden kann. Im Moment beschäftigt mich in dem Zusammenhang allerdings die Frage, ob es nicht sinnvoll wäre, das attrTemplate feature nach der ersten Konfiguration ggf. ausschaltbar zu machen oder eine Art "Generalkonfiguration" zu ermöglichen, was die Zahl der in den Speicher zu ladenden attrTemplate angeht (auch im Zusammenhang mit dem Sprachsteuerungsthema). Bin da aber gedanklich noch nicht ganz durch und habe jüngst ers die ersten Schritte in diese Richtung gemacht. Es werden z.B. die meisten MiLight-templates jetzt nicht mehr automatisch geladen...

Zum Rest melde ich mich im anderen Thread.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: KölnSolar am 03 Februar 2020, 12:28:10
Zitat
An sich bin ich geneigt, funktionierende templates auch zu veröffentlichen, es steckt - vor allem in diesen speziellen Fällen - einfach in der Regel viel Wissen drin, was ggf. auch für ähnliche Fragen weiter genutzt werden kann.
Womit wir wieder beim Thema wären: wo dokumentiert man am sinnvollsten "Codeschnipsel" für die Nachwelt. Gegen ein template spricht dann, dass es dort irgendwann ziemlich unübersichtlich wird.

Und ja viel Wissen/Erfahrung, ich bin seit 9 Monaten dabei, dem Bot die Cloud abzugewöhnen und habe nun das erste große Ziel erreicht, den Bot mit FHEM zu steuern und Infos zu empfangen. 8) (Leider noch mit Python-Add-on für den MQTT-Server) :'(

Grüße Markus
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 03 Februar 2020, 16:34:05
ACHTUNG:

Ab morgen gibt es mit dem update ein paar Neuerungen, die evtl. für einige "interessant" sind, für andere evtl. hinderlich, und ob das alles funktioniert, werden wir dann sehen, ich kann das leider nicht in allen Facetten vorab testen...
Und nachdem meine Aufrufe zum vorab-Testen in der Vergangenheit leider wenig feedback erbracht hatten, jetzt eben direkt der "live"-Test ;D . (Es sind mehrere Commits, notfalls könnte man auch nur Teile wieder deaktivieren, wenn unerwarteterweise grundsätzliche Probleme auftauchen sollten).

Im Einzelnen:
- Die Tasmota-Templates habe ich nochmal überarbeitet, und hoffe, dass nunmehr v.a. der "state" nicht ständig unnötig aktualisiert wird, sondern NUR NOCH BEI ÄNDERUNG. Zum Hintergrund vgl. diesen Beitrag/Thread (https://forum.fhem.de/index.php/topic,107859.msg1018495.html#msg1018495). Wer unbedingt zyklische state-updates braucht, muß die jsonMap-Attribute händisch anfassen.
(Dasselbe Thema gibt es bei den shelly's. Aber da habe ich keine Hardware und kann daher nicht testen, wie man das ggf. besser im zitierten Sinn machen kann. Dazu hatte ich im Shelly-Thread was geschrieben, feedback wäre m.E. dort gut untergebracht).

- Ganz viele Templates sollten jetzt automatisch auch die passenden Attribute setzen, wenn (mind.) ein Sprachassistent vorhanden ist, zu den Vorarbeiten siehe hier: https://forum.fhem.de/index.php/topic,99195.msg1019125.html#msg1019125
An sich sollte das soweit passen, Schwierigkeiten könnten die "unified"-Templates machen, bei denen mehrere schaltbare Kanäle da sind; könnte sein, dass da manches noch nicht paßt und/oder aktiv gelöscht werden sollte.

Wie immer:
- Bitte melden, wenn was nicht funktioniert
- Für manche genericTypes ist das noch nicht vollständig, wer also dazu was beitragen kann und möchte: feel free ;) .

Und schonmal vorab: sorry for inconvenience ::) .

Womit wir wieder beim Thema wären: wo dokumentiert man am sinnvollsten "Codeschnipsel" für die Nachwelt. Gegen ein template spricht dann, dass es dort irgendwann ziemlich unübersichtlich wird.
Hmm, vermutlich gibt es für das Problem nicht "die" Lösung, vor allem, wenn man dem Teil erst mal MQTT beibringen muß... Wenn der Weg dahin zu weit ist, wäre ich für einen "normalen" Codeschnippsel, wir können immer noch ein attrTemplate basteln, das dann die Konfigurationsarbeit abnimmt, wenn sich der user das als eigenes template abspeichert?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: micky0867 am 03 Februar 2020, 21:22:20
Hallo,

ich spiele gerade mit OpenMQTTGateway auf ESP32 rum.
Bisher habe ich mit den Templates noch nichts zu tun gehabt und mir war nur zufällig aufgefallen, dass es ein Template OpenMQTTGateway_BT_scanner überhaupt gibt.
Dies wurde mir mal angeboten, dann wieder nicht...schien an der readingList zu liegen, weil mein Device einen abweichenden Namen hat.

Ich habe den Filter für das Template dann auf
filter:TYPE=MQTT2_DEVICE:FILTER=name=gatewayBTgeändert, womit es deutlich besser funktioniert.
Allerdings kann ich nichts über die Allgemeingültigkeit dieses Filter sagen.

Mir war noch ein Fehler im Template aufgefallen.
Bei den set-Befehlen fehlt ein "config" im Topic, z.B.
BT_scan_interval:textField BASE_ID/DEVNAME/commands/MQTTtoBT/config/set {"interval":$EVTPART1}


Danke für solche genialen Funktionen!

Micky
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 04 Februar 2020, 07:58:25
@all: Betreffend die Spracherkennungsfragen für "255-er"-Leuchten gibt es hier einen Thread zum Anhängen: https://forum.fhem.de/index.php/topic,108080.0.html


Was das OpenMQTTGateway angeht, erst mal Danke für die nette Rückmeldung und den Hinweis auf "config", ist gefixt...

Welche Fassung der attrTemplate-File hast du? Ich habe neulich was umgestellt ;) .
Vorgehensweise ganz allgemein ist die: Erst das "MCU"-template anwenden, das verteilt dann eingehende Nachrichten auf weitere Devices, auf die man dann auch wieder weitere templates anwenden kann, die aber erst geladen werden, wenn es das "MCU"-Device gibt.
(@MiLight-Nutzer: Da ist es jetzt genauso, man muß erst das "Bridge-template" angewendet haben). Kann aber durchaus sein, dass mir da was durch ist...

Bitte weitere Diskussion zum OpenMQTTGateway dann in dem zugehörigen Thread: https://forum.fhem.de/index.php/topic,103737.0.html (https://forum.fhem.de/index.php/topic,103737.0.html)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 19 Februar 2020, 08:57:51
Guten Morgen zusammen,

gestern habe ich ein wenig mit den neuen Tasmota Templates gespielt. Dazu folgendes....
Zum Thema JsonMap habe ich leider zu wenig gefunden um es gut zu verstehen.

Als Beispiel mal tasmota 4ch splitt: Hier geht nach dem Template nicht wirklich alles. Es werden 4CH erstellt aber der Status wird nicht sauber durch gereicht. Es erscheint also die Lampe mit dem "!". Im Schalter sehe ich aber das geschaltet wird. Dann hatte ich mir das mapping  (json) angesehen und wurde nicht so richtig schlau darauß. Wenn ich nun als Beispiel im CH2 einfach sage POWER2=state, geht es wie gewohnt aber auch setStateList musste ich hier anpassen oder einfach löschen. Habe den Schalter an sich am laufen allerdings nicht mit dem originalem Template.

1) Gibt es Lesestoff zu jsonMap usw? Würde hier gerne mit helfen, da ich sah das dies nicht das einzige Template mit Problemen ist. Gerne dürft ihr mir das Thema auch so ein wenig mit Euren Worten erklären :)

2) Auch testete ich z.B. einen Arilux / MagicHome RGBW LED Controller. Der lässt sich mit KEINEM LED Template schalten. Ich weiß das ein List helfen würde, habe hier nur keins, da ich nach Durchsicht der Meinung bin, dass es auch mit der Umstellung auf JsonMap zusammen hängt. Habe aber auch keine große Zeit darein investiert. Würde zuerst gerne lesen und verstehen :)

Danke an alle, für Infos :)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 19 Februar 2020, 09:24:23
Moin.

Zu jsonMap gibt es nicht allzuviel Lesestoff, und ich habe auch "etwas" gebraucht, um zu sehen, wozu man es z.B. im Tasmota-Kontext verwenden kann und sollte. Das wesentliche scheint ja angekommen zu sein: Man kann damit Readings umbenennen, die sich aus dem JSON sonst ergeben würden, und man kann einzelne Informationen aus dem JSON "ausschalten". Das betrifft aber nur die Empfangsrichtung!

Dass es im jsonMap von POWER2 jetzt "0" heißt (also: ausgeschaltet) und nicht "state", hat damit zu tun, dass sonst die Zeitstempel nicht passen - der JSON wird nämlich regelmäßig aktualisiert, auch wenn sich gar nichts ändert. Das finde ich nicht gut, deswegen sollte in der readingsList für POWER2 auch das state-Topic abboniert sein, und nichts anderes (was aber bei dir erwartungswidrig der Fall zu sein scheint, warum auch immer; das template sollte jedenfalls genau das machen).

Allerdings ist POWER2 beim 4-kanaligen auch speziell, weil das 4-kanalige template die ersten beiden Kanäle im wesentlichen über das 2ch-split konfiguriert... Will nicht ausschließen, dass dabei was schief geht.


Was die MagicHome-Dinger angeht: Wenn es mit keinem template zu schalten geht, mach bitte dazu einen neuen Thread auf und liefere dort die Infos, was das Teil unter welchem Topic haben will - Ein ansatzpunkt wären die "subscriptions" im MQTT2-Device, die man zur Abwechslung aber nur in einem list sehen würde, nicht in einem RAW.
Wie gesagt: jsonMap hat damit erst mal wenig zu tun, weil es sich nur auf die Auswertung der Daten auswirkt, nicht auf die Frage, wie was versendet wird.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 19 Februar 2020, 10:07:54
Moin, moin,

da fällt mir glatt nochwas ein.... Hab einen Test Raspi aufgesetzt und aus Spaß einfach mal alle möglichen Sonoff/Tasmota Komponenten rein laufen lassen.
Mir ist aufgefallen, das immer wieder Geräte sich doppelt melden trotz Standard Topic von Tasmota.

Der Vorgang:
1. autocreate erstellt ein Gerät
2. attrTemplate auswählen
3. Gerät geht erstmal

4. Nach einiger Zeit meldet sich ein und das selbe Gerät nochmal und legt sich als neues DEV an. In diesem DEV sind auch nur 1-2 Readings im alten (nicht json) Format.
Da ich keine Lust hatte nun lange zu suchen habe ich bei den betroffenen Geräten einfach die Readings manuell in das zuerst erstelle DEV übertragen und nun melden sich nichts mehr doppelt. Lustig ist das es eigentlich immer Readings wie POWER1 und POWER als cmnd oder stat waren. Konnte also nach dem vierten Gerät schon erraten was es sein wird.

Wie hast du denn am Ende verstanden wie das mit jsonMap läuft? Brauche da echt Stoff.... Du erkennst ja auch die FHEM Zusammenhänge direkt, was ich mir ab und an noch immer durchlesen muss bevor ich es verstehe.

Anderes Ding, was aber gut hierzu passt... Wenn ich einen dummy anlege mit dem state eines anderen MQTT2 Gerätes, zeigt dieser immer invertiert den tatsächlichen Status an. Also wenn der dummy meint es ist ON ist in echt OFF usw. Vermutlich hat das was mit Events zu tun. (kurze Erläuterung: 1. dummy zum einstellen von Temperaturen. 2. threshold um zu schalten bei Differenz usw. 3. eigentliches Gerät was einfach on/off schaltet). Erwarte hier aber auch keine Antwort darauf, da dies ganz leicht OT ist und ich selber noch nicht genau nachgesehen habe.

Hatte durch meine Testerei und die Umstellung der Templates einiges nach zu lesen und deswegen wollte ich mal berichten.

Mich würde es freuen, wenn jemand Lust hat, dass dieser Jemand ggf. eine Beschreibung zu der json Geschichte liefern könnte. Da in diversen Threads aktuell darüber geschrieben wird und auch die FHEM Elite involviert ist, ist das doch sicher möglich :)

PS: Sehr schön, dass die Sprachasi-Geschichte sogar komplett neu angedacht wird. Alleine die Idee, direkt aus zu lesen was es für ein Gerät ist / welche Readings vorhanden sind und dementsprechend eine EventMap zu bauen -> GEIL!
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 19 Februar 2020, 10:46:33
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.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 19 Februar 2020, 10:56:55
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...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 19 Februar 2020, 11:15:30
[OT]
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)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 03 März 2020, 18:51:06
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
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 03 März 2020, 19:10:33
Ich schaue mir das nochmal an, aber hast du mal geschaltet nach der attrTemplate-Anweisung?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 03 März 2020, 19:14:57
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)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 04 März 2020, 01:11:08
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:0Da wäre glaub ich meine Welt auch in Ordnung :)
Symbol bzw. state passt und state wird nicht ständig mit aktualisiert :)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: joelinux am 04 März 2020, 07:17:10
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:0Da 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
 
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 04 März 2020, 08:19:19
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...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 04 März 2020, 08:46:41
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

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 04 März 2020, 09:20:16
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:.* stateund 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? ???
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 04 März 2020, 09:51:28
Zitat
Wie 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() }
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 04 März 2020, 10:00:28
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")...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 04 März 2020, 10:16:42
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?)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Eisix am 04 März 2020, 10:34:02
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
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 04 März 2020, 10:38:59
@Beta-User Kannst Du erklären was Du meinst? Was soll passieren / getestet werden?
Es soll am Ende schlicht (kommentarlos) "nichts" passieren, wenn irgendeine Info über (bei dir:) stat/tasmota_A52F4C/RESULT reinkommt... Das sollte über die leere Perl-Anweisung gehen ({ }).
Wir bekommen die Info ja über den jeweiligen POWERx-Zweig, die wir  brauchen.

Beim Schreiben merke ich: Das stimmt zwar für die "einfachen" on/off-Devices, aber z.B. nicht für die dimmbaren oder rgbw-Geräte...
Grübel... Egal wie man es macht, irgendein Haken ist immer, "tele" mit "{}" abzuschalten macht vermutlich keinen Sinn, da dann wohl andere - erwünschte - Infos fehlen.

Wenn jemand eine zündende Idee hat (und meine unausgegorenen Gedanken nachvollziehen konnte), bitte um Info bzw. konstruktive Vorschläge, ansonsten drehe ich das irgendwann am späteren Nachmittag (nur betreffend die {}-Anweisungen zu "stat") wieder (teilweise, wenn sich "komplexere Geräte" einfach identifizieren/separieren lassen?) zurück.

Musste ich korrigieren dann ging es wieder.
Auch hier die Empfehlung, jsonMap nicht anzupassen, sondern den richtigen Topic für state zu abbonieren. In diese Richtung:
   jsonMap    POWER1:0
[...]
   stat/Server/POWER1:.* state\
[...]

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 04 März 2020, 10:53:37
Vielleicht nochmal für die Templatetester ;)
Eine aktuelle Datei unterhalb von ./FHEM/ aus dem SVN holen und die alte sichern :)
defmod c3 cmdalias pmupdate .* AS {\
  my ($e,$g) = (undef,(split(" ",$EVENT))[0]);;\
  if (defined $g)\
  {\
    $e = qx(mkdir -p ./restoreDir/pm/"$year-$month-$mday"/FHEM/);;\
    $e = qx(cp ./FHEM/$g ./restoreDir/pm/"$year-$month-$mday"/FHEM/);;\
    qx(wget -qO ./FHEM/$g https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/$g)\
  } else {\
    $e = "use pmupdate Filename inside ./FHEM/"\
  }\
  return $e ? $e : "./FHEM/$g backuped and new loaded from SVN\nreload $g or shutdown restart to apply\nfor Templates use {AttrTemplate_Initialize()}"\
}
Dann einfach
pmupdate lib/AttrTemplate/mqtt2.template
Man kann die universelle Variante natürlich auch fest verdrahten und {AttrTemplate_Initialize()} gleich anhängen.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 04 März 2020, 11:51:22
Es soll am Ende schlicht (kommentarlos) "nichts" passieren, wenn irgendeine Info über (bei dir:) stat/tasmota_A52F4C/RESULT reinkommt... Das sollte über die leere Perl-Anweisung gehen ({ }).
Ich sage mal so: Mein Test (und mein Verständnis)
Mit jsonMap POWER1:0 und stat/tasmota_A52F4C/RESULT {json2nameValue($EVENT,'',$JSONMAP)}
2020-03-04_11:35:19 MQTT2_DVES_A52F4C set_off
2020-03-04_11:35:19 MQTT2_DVES_A52F4C off
2020-03-04_11:35:20 MQTT2_DVES_A52F4C set_on
2020-03-04_11:35:20 MQTT2_DVES_A52F4C on
Ohne jsonMap POWER1:0
2020-03-04_11:37:21 MQTT2_DVES_A52F4C set_off
2020-03-04_11:37:21 MQTT2_DVES_A52F4C POWER1: off
2020-03-04_11:37:21 MQTT2_DVES_A52F4C off
2020-03-04_11:37:22 MQTT2_DVES_A52F4C set_on
2020-03-04_11:37:23 MQTT2_DVES_A52F4C POWER1: on
2020-03-04_11:37:23 MQTT2_DVES_A52F4C on
Ohne jsonMap POWER1:0 und stat/tasmota_A52F4C/RESULT {}
2020-03-04_11:38:01 MQTT2_DVES_A52F4C set_off
2020-03-04_11:38:01 MQTT2_DVES_A52F4C off
2020-03-04_11:38:02 MQTT2_DVES_A52F4C set_on
2020-03-04_11:38:02 MQTT2_DVES_A52F4C on

Ergo POWER1:0 knipst das Result weg, RESULT {} knipst das Result weg. Erscheint mir also wie: doppelt hält besser :)

Aber wie Du schon sagst, das ist eine einfacher Schalter. Ein off/on Zyklus erzeugt in der Konsole:
11:45:40 MQT: stat/tasmota_A52F4C/RESULT = {"POWER1":"off"}
11:45:40 MQT: stat/tasmota_A52F4C/POWER1 = off
11:45:41 MQT: stat/tasmota_A52F4C/RESULT = {"POWER1":"on"}
11:45:41 MQT: stat/tasmota_A52F4C/POWER1 = on
Nach meinem Verständnis, kann man die Rückmeldung also mit einem von Beiden bekommen:
stat/tasmota_A52F4C/POWER1:.* state
  stat/tasmota_A52F4C/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }

Mein Bauchgefühl sagt mir: Es ist nicht gut die RESULT Meldungen komplett weg zu werfen.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 04 März 2020, 12:05:10
Es gibt auch einen neue Perl-Routine Svn_GetFile() (in fhem.pl, denke ich), die das ganze vereinfachen kann. Ungetestet:
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }

Zu dem "doppelt genäht": über die "tele"-Schiene kommt mMn. auch "irgendwann" und "immer wieder" ein JSON mit POWER1. Das wird über jsonMap auch noch mit "ausgeknipst", und dieser Teil ist mMn. ein "Muß", es ist also nicht doppelt, sondern "dreifach genäht".

Ergänzend: Wenn man mit dem hier arbeitet
stat/tasmota_A52F4C/RESULT:.* { json2nameValue($EVENT,'stat_',$JSONMAP) }kann man jsonMap so erweitern, dass man die gewünschten (scheinbar) _zusätzlichen_ Readings auswertet - das würde dann - vom Zeitstempel her gedacht - vermutlich passen; das jsonMap wäre aber natürlich zu erweitern auf alle relevanten Readings, die dann auch diesen Präfix haben... Deswegen hatte ich vorhin geschrieben, dass alles dann sehr viel komplexer wird und indirekt die Frage gestellt, ob man nicht besser den "tele"-Zweig (teilweise) ausknippst - was aber dann dort einen Präfix und passende jsonMap-Einträge erfordern würde.

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 04 März 2020, 14:35:03
Das {AttrTemplate_Initialize()} hat irgendwie Seiteneffekte, da tritt dann sowas auf wie im Bild

Also man kann zählen wie oft man die Funktion ausgeführt hat.
Ein Neustart behebt dies ;)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: marvin78 am 04 März 2020, 14:39:17
Das {AttrTemplate_Initialize()} hat irgendwie Seiteneffekte, da tritt dann sowas auf wie im Bild

Also man kann zählen wie oft man die Funktion ausgeführt hat.
Ein Neustart behebt dies ;)

Das ist mir auch aufgefallen. Auch fügt es Leeraum im Device ein. Ein Neustart macht wieder alles gut.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 04 März 2020, 14:44:54
einen Leerraum pro Start  ::) der dann mit den Hilfetexten in der gleichen Anzahl gefüllt wird - wenn man ein Template wählt.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 04 März 2020, 14:58:08
... ist ja lustig, aber ich glaube kaum, dass das ein bug in meinen templates ist  ;D ...
(Jedenfalls so lange, bis mir jemand das Gegenteil beweist...)

(Im Ernst: Der Effekt scheint neu zu sein, das war früher nicht so, jedenfalls soweit ich mich entsinnen kann).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 04 März 2020, 15:05:55
"Wozu" ? ist eigentlich der doppelte Text der zurückgegeben wird?
<script type="text/javascript">
    $(document).ready(function() {
      $("select.set").change(attrAct);
      function
      attrAct(){
        if($("select.set").val() == "attrTemplate") {
          $('<div id="attrTemplateHelp" class="makeTable help"></div>')
                .insertBefore("div.makeTable.internals");
          $("select.select_widget[informid$=attrTemplate]").change(function(){
            var cmd = "{AttrTemplate_Help('"+$(this).val()+"')}";
            FW_cmd(FW_root+"?cmd="+cmd+"&XHR=1", function(ret) {
              $("div#attrTemplateHelp").html(ret);
            });
          });
        } else {
          $("div#attrTemplateHelp").remove();
        }
      }
      attrAct();
    });
  </script>
  <script type="text/javascript">
    $(document).ready(function() {
      $("select.set").change(attrAct);
      function
      attrAct(){
        if($("select.set").val() == "attrTemplate") {
          $('<div id="attrTemplateHelp" class="makeTable help"></div>')
                .insertBefore("div.makeTable.internals");
          $("select.select_widget[informid$=attrTemplate]").change(function(){
            var cmd = "{AttrTemplate_Help('"+$(this).val()+"')}";
            FW_cmd(FW_root+"?cmd="+cmd+"&XHR=1", function(ret) {
              $("div#attrTemplateHelp").html(ret);
            });
          });
        } else {
          $("div#attrTemplateHelp").remove();
        }
      }
      attrAct();
    });
  </script>
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 04 März 2020, 15:25:02
Zitat
Das {AttrTemplate_Initialize()} hat irgendwie Seiteneffekte, da tritt dann sowas auf wie im Bild
Habs gefixt.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: DS_Starter am 05 März 2020, 23:00:51
Hallo zusammen,

habe kürzlich ein Tasmota 8 channel über  MQTT2_DEVICE eingebunden und dafür das Template tasmota_8ch_unified_icon verwendet.
Hat alles prima funktioniert und durch die Templates vereinfacht sich die Einrichtung. Super Sache ... und vielen Dank für die ständige Weiterentwicklung !

Kleine Anmerkung: In dem Template tasmota_8ch_unified_icon hat sich in Zeile 1082 womöglich ein kleiner Cut&Paste Fehler eingeschlichen.

attr DEVICE stateFormat LWT\
<a href="http://IPAddress" target="_blank">Hostname</a>\
<a href="http://IPAddress" target="_blank">IPAddress</a>\
<br>\
1:POWER1\
....

Sollte sicherlich sein:

<a href="http://Hostname" target="_blank">Hostname</a>\
Habe es bei mir so abgeändert und es wird dann auch der Hostname verwendet.

Grüße,
Heiko
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 06 März 2020, 09:48:10
Hat alles prima funktioniert und durch die Templates vereinfacht sich die Einrichtung. Super Sache ... und vielen Dank für die ständige Weiterentwicklung !
Danke für die Rückmeldung  :) ! (Danke zurück auch für deine Aktivitäten - in jüngster Zeit fand ich das mit Synology-Kalender2holiday besonders nett; der code für myUtils kam mir dabei bekannt vor... ;D )

Danke auch für den Hinweis auf dieses "doppelte Lottchen", die zweite Zeile ist mir versehentlich "durchgerutscht", update ist im svn (ich hätte das <br> noch dahinter ziehen können, und eigentlich ist auch webCmd völlig überflüssig, oder...?).

Die erste Zeile war allerdings schon so so beabsichtigt, und sollte auch funktionieren:
- Es werden ja von der firmware beide Infos geliefert;
- solange der dns-Server funktioniert, ist es auch funktional gleichwertig, ob man auf die IP oder den Namen verlinkt, abgesehen davon, dass eben vorab der dns-Server "behelligt" wird;
- erst wenn der dns-Server nicht funktioniert, sieht man den Unterschied: die jetzige Variante im svn liefert trotzdem noch den "richtigen" Link, die Variante mit Hostname als target sollte einen timeout bringen.

Oder übersehe ich schon wieder was?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: DS_Starter am 06 März 2020, 13:38:56
Hallo Beta-User,

die eingecheckte Version passt ja, alles gut. Ich dachte du wolltest dem Nutzer sowohl einen Link über Hostamen (mit DNS-Auflösung) als auch über die IP anbieten. 
Aber so wie es jetzt ist, ist es jetzt richtig.  :)

Momentan betreibe ich schon einige MQTT Devices, nutze die Möglichkeiten bis dato allerdings auch nur aus der Perspektive "Anwender". Aber ich finde MQTT als universelles und etabliertes Protokoll im IoT Bereich verdient es sich damit näher zu befassen.
Deswegen haben wir MQTT als Thema für unseren nächsten Stammtisch auf die Agenda gesetzt. Es wird sicherlich nicht bei nur einem Termin bleiben.
Bis dahin will ich ein paar theoretische Grundlagen zusammentragen/aufbereiten mit Querverweisen zu den best-practice Anwendungsscenarien in FHEM. 
Habe gesehen hier im MQTT-Forum gibt es ja bereits einige angepinnte Verweise zu diversen Quellen. Mal sehen wie ich das nutzen kann damit wir uns am Stammtisch einen gemeinsamen Wissensstand erarbeiten können.
Solltest du noch ein paar Links haben, die du/ihr in diesem Kontext als beachtenswert erachtest, nehme ich die gerne entgegen.

Bleibt also alles spannend und interessant ... mach(t) weiter so.  8)

Achso ...
Zitat
und eigentlich ist auch webCmd völlig überflüssig, oder...?
Es ist ein Template bzw. nur eine Vorlage ... wenn es jemandem nicht gefällt/er es nicht braucht, kann er es ja löschen. Ich würde es so lassen.

Grüße,
Heiko
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 06 März 2020, 14:08:10
Hey Heiko. Habe auch hierdurch mit MQTT angefangen und bin gerne bereit dir einiges grundlegendes zu erklären, bei Bedarf.

Hatten hier sogar kleine skripte gebaut um zb einen win pc mit an zu zeigen und dafür nicht direkt ein Riesen Programm zu installieren.

Gruß,
Kai

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: DS_Starter am 06 März 2020, 14:15:18
Hi Kay,

auf dein Angebot komme ich gerne zurück.  8)

Zunächst versuche ich unsere Stammtischmannschaft auf ein gemeinsames Kenntislevel zu heben, damit wir in der Lage sind uns in der MQTT-FHEM-Welt zurecht zu finden und in diesem Kontext auch fähig sind intelligente Fragen zu stellen (mich eingeschlossen).  ;)

LG,
Heiko
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 06 März 2020, 14:24:50
Wäre ne super Aktion in einem separaten Thread ein FAQ zu eröffnen. In einem anderen Forum habe ich damit auch mal begonnen.

Super idee! Danke! Was sagst du dazu?

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 06 März 2020, 14:40:45
Yep, ist spannend und immer wieder interessant, welche "schrägen" Varianten es gibt.

(Ich bin btw. auch immer froh, wenn ich mich nur aus Anwenderperspektive mit Modulen befassen kann  ::) :) , von daher: gerne geschehen...)

Für den Stammtisch als Anregungen vielleicht:

Einstieg/Grundkurs:
Material:
Je einen "normalen" Shelly(-pm) und Tasmota (notfalls: 2 Tasmota oder Shelly) an einem Demo-FHEM

Ziel:
Einführung in die Basics zu MQTT2_SERVER, autocreate und MQTT2_DEVICE
- Vorher und danach kann man dann mit "set xy attrTemplate ?" anknüpfen: Da kommt nämlich die m.E. längste "Linkliste" an Projekten, die bereits erfolgreich mit FHEM+MQTT umgesetzt wurde... (Wenn ihr Verbesserungsvorschläge zu den desc haben solltet oder weitere Geräte, die da rein sollen: aufschreiben...).
- vorher/danach, um zu Erkennen, wie wegen passender "filter:" dann plötzlich weitere attrTemplate sichtbar werden, wenn man sie vielleicht benötigt;
- dann attrTemplate: Quelltext vom template vorher ansehen, darauf anwenden  und Ergebnis begutachten...
- jsonMap - Funktion (bei Tasmota, einschließlich "Ausknipsen" von unnötigen Zweigen/Teilinfos).

Aufbaukurs I:
Material:
2. FHEM, das mit MQTT2_CLIENT auf den MQTT2_SERVER am anderen FHEM lauscht
Ziel:
Unterschied, besondere Schwierigkeit bei MQTT2_CLIENT-Installationen kennenlernen, Lösungsansatz verstehen.
- "bridge-template" zum Vorsortieren wg. fehlender/irreführender CID ("Einheits-Sammeldevice" für "bekanntes" vermeiden)


Aufbaukurs II:
Material:
Ein (besser: Zwei) ESP32, geflasht als OpenMQTTGateway(s) (wenn 2: mit unterschiedlichen Namen), dazu ein, zwei gtags oä +  (mind.) einen "runden" BT-Xiaomi-Temp/Hum-Sensor (Summe Material: <30 Euro...)
Ziele:
- Funktionsweise/eigentliches Ziel von bridgeRegexp verstehen; (so ähnlich ticken auch weitere "bridge"-templates, insbes. für zigbee2mqtt, ebus, milight: Es gibt ein Zentraldevice, das dem jeweiligen ESP entspricht, der generiert dann ggf. weitere Devices, das OpenMQTTGateway hier dann sogar mehrstufig für die verschiedenen Sende-/Empfangswege...)
- am praktischen Beispiel nachzuvollziehen, wie man Topic-Strukturen mit Perl auswerten kann und daraus dann Reading-Namen etc. baut;
- "Spezialtemplates", die dann komplett neue Geräte generieren (für gtag bzw. den Temp-Sensor, der dann auch nur die passenden Readings bekommt).

Dann wißt ihr im Prinzip nach ca. 2 Stunden in etwa so viel wie ich, fehlt eigentlich nur noch das Nachladen von weiteren templates/myUtils-code (=> ebus, roborock)  :) .

Was im Wiki bzw. als gesammelte "Best-Practice" noch fehlt, wären neben dem publishen via script, das 87insane angesprochen hat, noch "asynchrone" FHEM2FHEM-Verbindungen über MQTT2, Doku über SSL-Absicherung von SERVER nach außen zum allg. INet - da fehlt mir auch die Erfahrung, dto. zu eigentlichen MQTT-Vorteilen wie QoS etc..


In dem Zusammenhang:
Falls sich jetzt jemand mit ".ino"-Erfahrung angesprochen fühlt, sich ESP32 und BT näher anzusehen: Es gibt die Anfrage von Dominik betr. die Unterstützung der eQ-3-BT-Thermostate via ESP32@MQTT (https://forum.fhem.de/index.php/topic,108981.0.html). Gerne bei Interesse da einklinken...
(Und falls jemand sich jetzt erfolgreich dran macht und die Integration der "eckigen" Xiaomi-Thermostate (LYWSD03MMC) ins OpenMQTTGateway hinbekommt: ein ganz besonderes Dankeschön von mir...! (Es gibt irgendwo ein Python-Script, mit dem das mit gattool zu gehen scheint, man müßte es "nur" portieren bzw. vorher vielleicht (?) die gattool-lib in den OMG-code einbauen, falls das jetzt noch nicht mit den vorhandenen libs abbildbar sein sollte...))


FAQ: Gerne, aber das kuratiert dann gerne jemand anderes...


Templates allgemein:
Ich wäre immer noch sehr froh, wenn sich jemand mit regex-Kenntnissen freiwillig melden würde, mit mir (oder ohne mich) den HTTPMOD-Teil zu betreuen  ::) .
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: DS_Starter am 06 März 2020, 14:47:06
@Beta-User ... wow, danke. Jetzt hast du mich aber versorgt !  Das wird mit Sicherheit mehr als ein Abend :D

@87insane
Sowas wie ein FAQ finde ich natürlich sehr hilfreich.
Bin mir nur nicht sicher, ob Forum-Thread als Plattform dafür geeignet ist. Das "zerbröselt" wahrscheinlich sehr schnell weil diskutierte Themen  dann plötzlich ein Eigenleben beginnen.
Wäre das Wiki für soetwas nicht besser geeignet ? Dort gibt es ja auch schon mindestens 3 Einführungsthemen ...
Und im Prinzip kann auch jeder mitarbeiten.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 06 März 2020, 14:55:30
Ich glaube in regex nicht unbedingt mehr Kenntnisse zu haben wie du. Aber vllt. Bringt es ja was. Haste n Link?

Werde es die Tage mal eröffnen. Hab da so ne Vorstellung. Muss es eben nur pflegen.
Wenn fleißig fragen kommen, kann man sie immer oben sammeln nach Beantwortung. Dazu könnte man das Wiki ergänzen.

Gesendet von meinem LM-G810 mit Tapatalk
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 06 März 2020, 14:57:14
@Beta-User ... wow, danke. Jetzt hast du mich aber versorgt !  Das wird mit Sicherheit mehr als ein Abend :D
@Beta-User Du willst die Qualität unserer Treffen ja durch die Decke gehen lassen. Wir werden wohl den Rest des Jahres ausgebucht sein :)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: DS_Starter am 06 März 2020, 15:12:19
 ;D ... Otto
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 06 März 2020, 15:28:39
@Beta-User Du willst die Qualität unserer Treffen ja durch die Decke gehen lassen. Wir werden wohl den Rest des Jahres ausgebucht sein :)
Ihr könnt das gerne so halten, wie ihr wollt ;D , auch in zeitlicher Hinsicht :P .

Ich wollte nur mal (auch für mich) aufschreiben, welche Themen dass es gibt, wo man sie findet und wie man sich das am besten "anarbeitet". Und ernsthaft: Wenn jemand zwei Test-Pi's (oder einen Pi+ein Laptop) hat (und die in einem Netzwerk unterbringen kann) (beide FHEM auf einem Rechner geht auch, aber das ist ziemlich abstrakt), und die Geräte geflasht, aber sonst "sauber" sind, ist man da wirklich in der Größenordnung in 2h durch, Grundkenntnisse in FHEM vorausgesetzt (FHEMWEB-Attribute sollte man schon jedenfalls der Spur nach verstehen).

Es sollte halt jemand demonstrieren, der "das Zeug" kennt, aber (@Otto) für dich sollte es kaum mehr als die 2h Vorbereitung sein (flashen der ESP32 und austesten inclusive, unterstellt, du hast ein paar Tasmota-ESP's ungenutzt rumliegen und Funktion von bridgeRegexp ist "der Spur nach" bekannt). Für MQTT-Noobs (ohne bridgeRegexp-Erfahrungen) ist der direkte OMG-Einstieg wahrscheinlich sehr steil, hier würde ich für eine Einarbeitung im Selbststudium min. 3-4 h veranschlagen, wer z.B. zigbee2MQTT kennt, wird direkt loslegen , also <2h im Selbststudium.

(Vielleicht sollte ich einen OMG-ESP32 und das Laptop nach KA mitnehmen, falls es da jemanden interessiert?).

Ich glaube in regex nicht unbedingt mehr Kenntnisse zu haben wie du. Aber vllt. Bringt es ja was. Haste n Link?
Link wäre hier: https://forum.fhem.de/index.php/topic,97694.0.html

Wäre natürlich nett, wenn du die diversen Templates einfach mal austesten könntest (sind ja in der Regel allg. zugängliche Quellen), aber es ist schon so, dass ich in der regex-Sprache nicht tief genug drin bin und auch die HTTPMOD-Syntax nur unzureichend kenne. Wenn du dich da erst einarbeiten mußt, ist das vermutlich für dich noch frustrierender wie für mich (ich hatte mir das auch vorher nicht so komplex vorgestellt :( ). Aber patche bzw. vollständigen template code (! ;) ) nehme ich da gerne auch entgegen, klar, feel free!

Aber gerade @HTTPMOD ist "best practice sharing" eigentlich besonders hilfreich. Zum Glück und zu meiner großen Freude gibt es auch einige templates, die sich größerer Beliebtheit erfreuen und einige Unterstützer, die super-konstruktive Beiträge geliefert haben! Es ist nur (noch) nicht so wie hier bei MQTT2, dass (fast) alles durchgängig "einfach so" funktioniert, die Qualität ist m.E. einfach noch zu wechselhaft.
Wenn sich also jetzt jemand von denen angesprochen fühlt, die mir da qualitativ über sind: Bitte, Bitte!!!
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: DS_Starter am 06 März 2020, 15:35:30
Ich stelle unserem Stammtisch immer eine kleine Testumgebung auf VMWare FHEM-Instanzen bereit, eine Datenbankmaschine und eine FHEM-Maschine. Die sind gesichert und wir können die nach Herzenslust zerspielen, nach der Session stelle ich die Instanzen aus einem Backup neu her.
Ein paar MQTT-Devices kann ich auch bereitstellen zum Spielen. Nur ist die Gesamtumgebung nicht vor uns "auf dem Tisch", sondern remote zugreifbar. Aber für die ersten "Mannschaftsschritte" sollte es ausreichen.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: v1nc3nt am 08 März 2020, 13:50:28
Hallo,

da es doch mal passiert, dass man ein Topic bei Zigbee2mqtt umbenennen muss, ist dann das ändern des Topics in allen Attributen von dem Gerät relativ aufwändig. Die Alternative ist löschen und neuanlegen, was man bei größeren Änderung auch nicht immer will.
Deswegen habe ich mir überlegt, dass man mit dem Internal und Attribut Devicetopic eine schnelle Änderung möglich wäre. Damit müsste man nur an einer Stelle eine Änderung vornehmen und es überträgt sich auf alle anderen Attribute. Den dazugehörigen Patch habe ich angehängt als konkreten Vorschlag.

Gruß Vincent
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 08 März 2020, 22:49:21
THX, hab's eingecheckt. Bin mal gespannt, was da für Rückmeldungen kommen, das macht das ganze halt nochmal eine Spur komplexer...


Ansonsten gab's noch ein paar weitere Kleinigkeiten, vorrangig wieder um das Thema Sprachsteuerung rum. Es wäre v.a. nett, wenn sich jemand das Mapping am
 zigbee2mqtt_ContactSensor ansehen könnte, das war etwas sehr "auf Verdacht"...

Wenn das da klappt, dürft ihr mir gerne weitere mappings nach diesem Beispiel liefern, dabei gilt aber weiter: Bitte nur das, was unbedingt benötigt wird, damit es funktioniert - so wie ich das verstanden hatte, hat justme1968 da in jüngerer Vergangenheit einiges verbessert, so dass heute vieles automatisch paßt, ohne dass man groß was einstellen müßte.

Diskussion dazu ggf. dann aber bitte in einem gesonderten Thread, TomLee hat hier schon mal angefangen: https://forum.fhem.de/index.php/topic,108999.0.html, da könnt ihr auch verfolgen, was es an "Spezialitäten" rund um alexa gibt...

Viel Spaß damit,

Beta-User
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 24 März 2020, 10:30:22
Hallo zusammen,

die Shelly Jünger unter uns kennen es. Immer wieder nach einem Neustart ist der Gesamt Energie Wert weg. Das liegt an der original FW, die die Daten eben nicht wie z.B. bei Tasmota im Flash vorhält.
Macht es aus Euren Augen nicht Sinn, ein Reading mit dem wirklichem Total im Shelly zu haben? Anbei mal, wie ich das löse.

attr GERÄTENAME userReadings relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum("$name","relay_0_energy",0)}
Darauf könnte man auch wieder Statistics anwenden usw.

Beta-User sagte das man dies ggf. auch als "optional" einfügen könnte. Also über RADIO (wie bei den Sprachsteuerungen). Kenne ich noch nicht aber gerne nehme ich Lektüre entgegen :)

Gruß,
87insane
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 24 März 2020, 11:25:30
Vielleicht keine direkte Lektüre, aber was zum testen... (ggf. erst mal einen anderen Namen verwenden, unter diesem Namen gibt's das template schon):

name:shelly1_w_energy_meassuring
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
order:A_10b
desc:Applies to single relay Shelly devices offering energy meassuring like Shelly 1PM or Shelly Plug S
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
par:RADIO_SETUSERREADING;Set userreading for total energy consumption;{ undef }
par:RADIO_DONOTSETUSERREADING;Do not set userreading for total energy consumption;{ undef }
par:NEWUSERREADINGS;NEWUSERREADINGS as set if relay_0_energy_total is included, otherwise it will be added;{ my $old =  AttrVal("DEVICE","userReadings",undef);; !defined $old ? 'relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum("$name","relay_0_energy",0)}' : $old =~ m,relay_0_energy_total:relay_0_energy.*, ? $old : $old.', relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum("$name","relay_0_energy",0)}'  }
attr DEVICE setList\
  relay0:on,off,toggle shellies/DEVNAME/relay/0/command $EVTPART1\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on\
  x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE readingList \
  shellies/DEVNAME/relay/0:.* state\
  shellies/DEVNAME/relay/0:.* relay0\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/online:.* online\
  shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : undef }\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/relay/0/power:.* relay_0_power\
  shellies/DEVNAME/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? "off":"on"; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : undef }\
  shellies/DEVNAME/temperature:.* temperature\
  shellies/DEVNAME/overtemperature:.* overtemperature\
  shellies/DEVNAME/relay/0/energy:.* relay_0_energy\
  shellies/DEVNAME/relay/0/energy:.* {'relay_0_kWh' => sprintf("%.2f",$EVENT/60/1000)}\
  shellies/DEVNAME/longpush/0:.* longpush_0
attr DEVICE devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false"?"10px-kreis-rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "10px-kreis-gelb" : "10px-kreis-gruen";; my $light = ReadingsVal($name,"state","off");; my $cons = ReadingsVal($name,"relay_0_power","unknown");; my $total = ReadingsVal($name,"relay_0_kWh","unknown");; my $temp = ReadingsVal($name,"temperature","-100");;"<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Verbrauch: $cons / Total: $total/ Temp: $temp °C</div>"}
attr DEVICE comment To get appropriate loadState values: Change the default limit "100" in readingList to your needs.
attr DEVICE webCmd :
deletereading -q DEVICE (?!associatedWith).*
set DEVICE x_mqttcom announce
set DEVICE attrTemplate speechcontrol_type_switch
attr DEVICE model shelly1_w_energy_meassuring
option:{ RADIO_SETUSERREADING }
attr DEVICE userReadings NEWUSERREADINGS
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 24 März 2020, 11:38:20
Lese ich das richtig?

par:NEWUSERREADINGS;NEWUSERREADINGS as set if relay_0_energy_total is included, otherwise it will be added;{ my $old =  AttrVal("DEVICE","userReadings",undef);; !defined $old ? 'relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum("$name","relay_0_energy",0)}' : $old =~ m,relay_0_energy_total:relay_0_energy.*, ? $old : $old.', relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum("$name","relay_0_energy",0)}'  }Er liest (wenn vorhanden) alte userReadings ein. Sollten alte vorhanden sein, werden diese mitgenommen und das eine hinzugefügt. Wenn keine alten vorhanden sind, dann nur das eine Reading einfügen.

Wieso steht es denn im Template dann nochmal ganz unten unter userReadings?
attr DEVICE userReadings NEWUSERREADINGS relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum("$name","relay_0_energy",0)}
Nur mal um die Nachwelt und auch mich auf den aktuellen Stand zu bringen was die "optionalen" Setter angeht....
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 24 März 2020, 11:43:00
Mist, die letzte Zeile war ein Kopierrest, die muß weg (ich editiere das gleich nochmal)...

Ansonsten ist das korrekt: Es sollten eventuelle andere vorhandene userreadings nicht angetastet werden...

(die Namensgebung ist übrigens nicht sooo super, m.E. wäre was kürzeres hier besser, oder nicht?)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 24 März 2020, 12:21:51
Geht soweit ohne die letzte Zeile. Ich werde gefragt (echt cool!) und dann kann ich auswählen.

Danach kommt aber noch "Unknown template_entry_name speechcontrol_type_switch".... Also mal eben erst die aktuellen Template Dateien gezogen (falls jemand das mal haben sollte).
Erneut getestet, nun alles super.

Nur ggf. wegen Copy&Paste ist in devStateIcon anstatt °C ein ?C (ASCII Fragezeichen, kein normales). Da müsste wie im 1pm Template dann stehen: °C

Da es nun wie in einem Wizard klickbar ist, kann man ja quasi alles so aufbauen. Also nochmal alles neu machen... :-P

Das gleiche muss auch noch für relay 1 existieren. Der Shelly 2.5 hat z.B. zwei Relays. Dazu ist der Name der Relays abhängig davon ob er im Schalt oder Roller Modus ist (roller_0_energy/relay_0_energy / im Roller Mode hat der Shelly2.5 auch nur roller0 und keinen roller1). Willst du das als "sub Template" einfach aufrufen lassen? Wenn ja, wäre der Name dann sowas wie shelly_total_energy_fix

Für mich das nur ein Workaround. Shelly selber wird das aber auch erstmal nicht ändern.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 24 März 2020, 13:05:05
Man _kann_ schon alles modular aufbauen mit der Technik... Ist aber ein ziemlicher Auswand, und man müßte wissen, wo man hinwill usw....

Würde z.B. dazu neigen, das "shelly-announce"-Gerät dazu zu nutzen, das generelle Verhalten der attrTemplate im shelly-Zweig zu beeinflussen, und z.B. im Standard einiges wegzulassen (die Ampel, die announce-Abos, z.B.). Das was man nach meiner persönlichen Meinung besser zentral erledigt eben...

ABER: Das umzubauen, ist ein ziemlicher Aufwand, wer mag, kann für den shelly-Teil gerne patches liefern - ein Anfang wäre der Versuch, das für den shelly 2.5 mal zu modularisieren, Beispiele für die "Mitnutzung" des 1. Kanals findet man zwischenzeitlich auch in einer "bedingten sprachsteuerungs-Variante" schon bei Tasmota ;) .

Ich selbst werde mich bei Gelegenheit erst mal um die Tasmota-Ecke kümmern, da gibt es eine ganze Ladung ähnlicher Fragen (siehe separaten Thread dazu...). Ist aber nicht von so hoher Prio, das funktioniert ja alles erst mal soweit.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 24 März 2020, 13:05:24
PS: Es sollte natürlich ReadingsVal anstatt ReadingsNum heißen... Sorry!

Mein Vorschlag, nach Durchsicht der Speech Geschichte bleibt bei "shelly_total_energy_fix".
Die Optionen gefallen mir. So kann man in der Theorie ein Gerät von A bis Z einrichten. Man könnte fragen, "soll das eine Waschmaschine werden"?, welchen Schwellwert hat diese?, soll es ein Gesamt Energie Reading geben?, welches devStateIcon willst du... usw... Echt genial!

name:?????????????
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
order:A_10b
desc:Applies to single relay Shelly devices offering energy meassuring like Shelly 1PM or Shelly Plug S
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
par:RADIO_SETUSERREADING;Set userreading for total energy consumption;{ undef }
par:RADIO_DONOTSETUSERREADING;Do not set userreading for total energy consumption;{ undef }
par:NEWUSERREADINGS;NEWUSERREADINGS as set if relay_0_energy_total is included, otherwise it will be added;{ my $old =  AttrVal("DEVICE","userReadings",undef);; !defined $old ? 'relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsVal("$name","relay_0_energy",0)}' : $old =~ m,relay_0_energy_total:relay_0_energy.*, ? $old : $old.', relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsVal("$name","relay_0_energy",0)}'  }
attr DEVICE setList\
  relay0:on,off,toggle shellies/DEVNAME/relay/0/command $EVTPART1\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on\
  x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE readingList \
  shellies/DEVNAME/relay/0:.* state\
  shellies/DEVNAME/relay/0:.* relay0\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/online:.* online\
  shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : undef }\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/relay/0/power:.* relay_0_power\
  shellies/DEVNAME/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? "off":"on"; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : undef }\
  shellies/DEVNAME/temperature:.* temperature\
  shellies/DEVNAME/overtemperature:.* overtemperature\
  shellies/DEVNAME/relay/0/energy:.* relay_0_energy\
  shellies/DEVNAME/relay/0/energy:.* {'relay_0_kWh' => sprintf("%.2f",$EVENT/60/1000)}\
  shellies/DEVNAME/longpush/0:.* longpush_0
attr DEVICE devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false"?"10px-kreis-rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "10px-kreis-gelb" : "10px-kreis-gruen";; my $light = ReadingsVal($name,"state","off");; my $cons = ReadingsVal($name,"relay_0_power","unknown");; my $total = ReadingsVal($name,"relay_0_kWh","unknown");; my $temp = ReadingsVal($name,"temperature","-100");;"<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Verbrauch: $cons / Total: $total/ Temp: $temp °C</div>"}
attr DEVICE comment To get appropriate loadState values: Change the default limit "100" in readingList to your needs.
attr DEVICE webCmd :
deletereading -q DEVICE (?!associatedWith).*
set DEVICE x_mqttcom announce
set DEVICE attrTemplate speechcontrol_type_switch
attr DEVICE model shelly1_w_energy_meassuring
option:{ RADIO_SETUSERREADING }
attr DEVICE userReadings NEWUSERREADINGS
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 24 März 2020, 13:32:41
ReadingsNum ist m.E. an der Stelle total ok! Why not?!?

Und warum einen anderen Namen nehmen? Das mit dem Umbenennen des templates war nur für's Testen erforderlich, meine Frage bezog sich auf den Namen des Readings - der sollte wohl was mit dem Kanal zu tun haben, aber so lang braucht er nicht zu sein, oder?

Das mit dem "°C" habe ich zwar gesehen, aber den Verdacht, dass das irgendwie spezifisch ist für das jeweilige Zielsystem - da sollte wohl eher ein sauber codiertes "html"-Zeichen stehen, oder? (Hat jemand einen Tipp?).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 24 März 2020, 15:53:30
Hi,

Zitat
ReadingsNum ist m.E. an der Stelle total ok! Why not?!?
Ja... Geht natürlich aber macht es einen Unterschied?

Zitat
Und warum einen anderen Namen nehmen? Das mit dem Umbenennen des templates war nur für's Testen erforderlich, meine Frage bezog sich auf den Namen des Readings - der sollte wohl was mit dem Kanal zu tun haben, aber so lang braucht er nicht zu sein, oder?
Finde das Reading sollte klar zu erkennen sein und direkt ersichtlich sein woher/warum. Weswegen in meinen Augen der Ursprung erhalten bleiben sollte und dahinter dann eben etwas wie _total, _fix,..... Ist zwar "lang" aber besser zu erkennen für jeden.

Zitat
Das mit dem "°C" habe ich zwar gesehen, aber den Verdacht, dass das irgendwie spezifisch ist für das jeweilige Zielsystem - da sollte wohl eher ein sauber codiertes "html"-Zeichen stehen, oder? (Hat jemand einen Tipp?).
Gibt es ja nicht nur in "meinen" Templates. Ist auch in anderen Templates enthalten. Finde es nicht schlimm, das es so muss. Habe es auch nur so hinbekommen "damals".
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: OppiM am 26 März 2020, 18:23:12
Hi,

Ich hab gerade mal versucht, einen Sonoff T1 2ch mit dem Template "tasmota_2channel_split" einzurichten.

Das ursprüngliche Gerät funktioniert danach als CH1 wie erwartet. Das zweite läßt sich zwar schalten, zeigt aber nicht den Status an. Grund ist, dass die readingList nicht richtig gesetzt wird:
attr MQTT2_SonoffT1_CH2 readingList STATTOPIC/POWER2:.* state
Diese Zeile scheint im Template "tasmota_2channel_split" zu fehlen:
par:STATTOPIC;ack topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}stat$3" : undef }

Das gleiche gilt für "tasmota_4channel_split".

Gruß,
Michael
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 26 März 2020, 22:10:54
Danke für die Info, update ist im svn.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Feuerpfeil am 30 März 2020, 12:10:15
Hallo zusammen,

auch auf die Gefahr hin, dass es jetzt für mich peinlich werden könnte :

Ich verusche das zigbee2mqtt_ContactSensor Template anzuwenden und bekomme die Fehlermeldung :
"Empty parameters are not allowed"

Versuche ich dann das Template erneut anzuwenden, erscheint ein Dialogfeld :

Specify the unknown parameters for zigbee2mqtt_ContactSensor:
base topic set in configuration.yaml of the zigbee2mqtt bridge   
name of the device in the zigbee2mqtt bridge

Des Weiteren kann ich auch nicht, mittels dropdown, das device auf open/close setzen
set MQTT2_zigbee_DEVICE open

gibt :
Unknown argument false, choose one of attrTemplate


Ich habe allerdings auch keine Homebridge oder sonstigen Sprachassistenten installiert.

Mache ich hier etwas falsch ?

Viele Grüße,
Lars
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 30 März 2020, 12:27:34
Ohne ein list (oder besser zwei: vorher/nachher) sage ich dazu nichts...
Hat aber vermutlich nichts mit den Sprachsteuerungsgeschichten zu tun, da scheint einfach keine readingList da zu sein, die augelöst würde, daher mußt du beide Angaben in dem Dialogfeld selbst eingeben.

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Feuerpfeil am 30 März 2020, 12:33:38
Die Readings sind jedenfalls vorhanden :

Readings
associatedWith     MQTT2_zigbee_pi   2020-03-30 11:37:19
battery      100      2020-03-30 12:27:25
contact      true     2020-03-30 12:27:25
linkquality     60     2020-03-30 12:27:25
voltage     3105     2020-03-30 12:27:25

und
readingList   zigbee2mqtt/0x00158d00045cfc54:.* { json2nameValue($EVENT) }

nach Anwenden des Templates

readingList   $DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
devicetopic   zigbee2mqtt/0x00158d00045cfc54
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 30 März 2020, 12:50:59
ok. Damit ist der 2. Durchlauf erklärt (muß ich mir noch was dazu überlegen). Nach dem ersten
sollte im Attribut "devicetopic" auch "zigbee2mqtt/0x00158d00045cfc54" stehen.
Um das "Empty parameters are not allowed" muß ich mich gesondert kümmern, das scheint tatsächlich ein Problem zu sein, weiß aber noch nicht so recht woher...

Was das mit dem "set" angeht: Verstehe ich nicht. Das ist doch ein reiner Sensor, oder etwa nicht? Daher sollte es auch keine setList geben, wenn du - aus welchen Gründen auch immer - einen Anlaß siehst da einzugreifen, mußt du "setreading" verwenden. Aber richtigerweise sollte man m.E. versuchen, das auf der Seite von zigbee2mqtt zu adressieren. Das müßte für aktuelle Daten sorgen, nicht FHEM oder du...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 30 März 2020, 14:04:20
Gefunden, und auch gleich noch ein paar weitere "Kleinigkeiten" gefunden (ein volles RAW-listing wäre trotzdem besser gewesen, so mußte ich zum Testen erst mal basteln...):

name:zigbee2mqtt_ContactSensor
desc: Contact sensor via zigbee2mqtt <br>Tested with: Xiaomi models Aqara and Mijia
filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
order:L_06
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^/:]+)[/].+, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[^/]+[/]([^/]+).+, ? $1 : undef }
attr DEVICE devStateIcon open:fts_window_1w_open@red close:fts_window_1w@green
#attr DEVICE genericDeviceType contact
attr DEVICE eventMap true:close false:open
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE jsonMap contact:state
deletereading -q DEVICE (?!associatedWith).*
set DEVICE attrTemplate speechcontrol_gdt_and_mapping GENERICDEVTYPE=contact HOMEBRIDGEMAPPING="ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED"
attr DEVICE model zigbee2mqtt_ContactSensor

Damit sollte es laufen, und zwar auch das 2. Mal, und damit sollte es auch in der dropdown-Liste angezeigt werden.

(Wird etwas dauern, bis ich alle betroffenen Templates durch habe, und das gesammelt im update landet, aber bei den anderen taucht der Anlaß für deine völlig berechtigte Frage nicht auf...).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Feuerpfeil am 30 März 2020, 15:03:34
ganz herzlichen Dank, für Deine Rückmeldung !

Genau...bei den Templates für zigbee2mqtt_Human_Motion_Sensor so wie zigbee2mqtt_plug, hatte ich die "Probleme" nicht. Daher war ich ein wenig verwundert.
Sorry, dass ich kein RAW-listing geliefert habe. Ich mache einfach zu selten etwas an fhem, sodass mir schnell und gerne, grundlegende Dinge verloren gehen. :-/

Wegen der setList : Da stimme ich Dir zu. Der Status eines Sensors muss, normalerweise, nicht manuell geändert werden.
Die setList wurde automatisch angelegt und da ich gerade ein notify getestet habe, habe ich versucht mittels dem Set aus der setList, den Zustand des Sensors zu setzen.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 30 März 2020, 15:12:36
Na ja, der Unterschied zu dem plug ist der, dass der Contact etwas mehr an mapping-Infos braucht, und genau da war der Hund begraben, was aber sehr schwer auffällt, da sich dort (und nur bei dem einen template...) schlicht zwischen dem Parameter= und dem Wert ein Leerzeichen reingemogelt hatte...

Aber so war es ein Anlaß, mal wieder etwas intensiver damit zu spielen und gleich noch was anderes zu verbessern ;D .

(Aber es wäre mir echt neu, dass autocreate bei MQTT2_DEVICE gleich noch eine setList anlegt, vermutlich reden wir da aneinander vorbei...).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 31 März 2020, 13:50:10
So, update ist im svn, wäre nett, wenn jemand vorab testen könnte, ob alles soweit i.O. ist - neben dem "Contact" sind noch ein paar Nettigkeiten gefixt:
- Die FILTER waren insgesamt irgendwie "kaputt";
- bei den zigbee-Geräten klappt jetzt auch (wieder) das wiederholte Anwenden (das automatische Auflösen der Parameter war im Zuge der "devicetopic"-Umstellung vorübergehend "kaputt" gegangen).


Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: slowfinger am 10 April 2020, 12:57:06
Hallo
mir ist noch im Template

tasmota_2ch_shutter_invert_1 und auch beim tasmota_2ch_shutter_invert_0

aufgefallen, dass die setlist beim Befehl HALF nicht den Rolo auf 50% fährt, sondern die "Kalibrierung hier ist 50%" auslöst. Besser & richtiger (?) wäre

close:noArg cmnd/Rolladen_KleinerBalkon/ShutterClose1
   open:noArg cmnd/Rolladen_KleinerBalkon/ShutterOpen1
   half:noArg cmnd/Rolladen_KleinerBalkon/ShutterPosition1 50
   pct:slider,0,1,100 cmnd/Rolladen_KleinerBalkon/ShutterPosition1 $EVTPART1
   stop:noArg cmnd/Rolladen_KleinerBalkon/ShutterStop1
   resetClose:noArg cmnd/Rolladen_KleinerBalkon/ShutterSetClose1
   x_configuration cmnd/Rolladen_KleinerBalkon/$EVTPART1 $EVTPART2
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: flummy1978 am 10 April 2020, 19:35:20
Hallo Beta-User & Hallo alle anderen,

ich hab mal ne Anregung zu den Templates generell....

Ich weiß nicht wie es andere halten, aber ich versuche das Gespamme in meinen Logs (bzw Event Monitor- weil ich mit diesem sehr viel arbeite) im Griff zu halten und auch beim Erstellen neuer Devices auf möglichst notwendige Events zu reduzieren. Selbst wenn man ALLE Änderungen als Event haben möchte, so wäre es doch sinnvoll ein
attr event-on-change-reading .*für alle Geräte pauschal mit aufzunehmen oder ?

Diejenigen die darauf achten, welche Readings sie in einem ein Event brauchen, passen es eh noch an und alle anderen werden zumindst nicht mit Updates zugespammt oder "verpassen" Änderungen, weil es aus irgendeinem Grund vorher kein Event ausgelöst hat.....

Just my 2cent - Idee .... wenn Blödsinn, wäre ich für den Grund dankbar (kann ja nur was davon lernen), dann kann man es schnell wieder vergessen ;)

Grüße
Andreas
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 10 April 2020, 20:15:24
Zitat
so wäre es doch sinnvoll ein "attr event-on-change-reading .*" für alle Geräte pauschal mit aufzunehmen oder ?
Meiner Ansicht nach nicht, sonst waere das die Voreinstellung.
Nachteile:
- man weiss nicht, ob ein Geraet noch lebt
- man muss in den Plots Fantasiewerte einbauen
- in der Kombination mit anderen event-* Attributen bekommt man nicht das, was man denkt

Ich wuerde die Daten in der Quelle auf einen "normalen" Mass beschraenken (Meldung alle 1-5 Minuten), und meine Finger von jeglichen event-* Attributen lassen.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 11 April 2020, 06:54:44
Hallo zusammen,

im svn ist wieder eine aktualisierte Version, eingeflossen sind:

- neues template für McLightning (https://forum.fhem.de/index.php/topic,109946.0.html, thx an Andi89);

- Änderungen bei OpenMQTTGateway:
 -- "Erster" bei periodicCmd für ein attrTemplate...
 -- (Hoffentlich funktionierende) Erweiterung für "non-JSON" sendende Builds

Mein Server hat in dem Zusammenhang eine ignoreRegexp erhalten:
attr MQTT2_FHEM_Server ignoreRegexp homeassistant/.*/config:.*Damit werden "discovery"-Meldungen, die für HomeAssistant gedacht sind, direkt verworfen (hoffentlich jedenfalls). Eigentlich wäre das ein separates template wert (bzw. evtl. mehrere), vielleicht mag jemand den Gedanken aufgreifen, und z.B. ein template bauen, mit dem man aus einem Tasmota-Device heraus den installations-spezifischen "cmnd-Pfad" ermitteln kann, schauen, ob der schon in ignoreRegexp des IO's steht und diese ggf. dort ERWEITERN (und auf das IO wechseln)?

- dimup/down bei shellydimmer geändert (ich hoffe, das was sich um https://forum.fhem.de/index.php/topic,94060.msg1040699.html#msg1040699 herum findet zutreffend interpretiert zu haben? Die "7" verstehe ich allerdings nicht, wäre ohne testen auf 5 oder 9 gekommen.)

Zu dem event-on-... Thema:
Rudi hat recht, flummy1987 kann ich mit dem Anliegen aber auch sehr gut verstehen... Rudi und ich hatten im Prinzip dieselbe Diskussion vor wenigen Wochen schon mal. Für reine "on/off(/dimm)"-Devices (mit dem flummy1987 sich zuletzt intensiv beschäftigt hatte, s.o.),  ist es gefühlt einfach nur "falsch", dass der  shellyständig "bin noch an" (usw.) zu melden scheint (irgendwo gab's dazu eine Diskussion, bei der afaik auch Otto123 beteiligt war; es könnte einen Einstellung in der shelly-firmware geben, mit der man das ausschalten kann). Für tasmota müßten wir das jetzt durch die ganzen jsonMap-Geschichten indirekt im Griff haben, bei shelly hat sich dagegen noch keiner damit beschäftigt...

Rudi's Punkt ist der: Sobald es nicht um on/off/Dimmwert oä geht, die statisch sind, solange niemand sie ändert, sondern z.B. um Temperaturwerte, will man typischerweise eben auch den unveränderten Meßwert haben. (Für die Frage, ob das Device noch lebt, paßt die Argumentation mMn. bei MQTT _meistens_ nicht, jedenfalls, wenn es ein "ordentlich programmiertes" Gerät ist, das "Last Will" (z.B. LWT@Tasmota) so nutzt, wie es gedacht ist. Machen aber auch nicht immer alle...)

Für den McLighting habe ich das btw. auch mit .* übernommen wie vorgeschlagen, da ich davon ausgehe, dass das Teil eher in die "statische Ecke" paßt. Allerdings enthält dessen readingList nichts, das auf den ersten Blick wie ein LWT-Pfad aussieht.

Nu ja, einen Schritt nach dem anderen...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: joelinux am 12 April 2020, 08:14:24

- dimup/down bei shellydimmer geändert (ich hoffe, das was sich um https://forum.fhem.de/index.php/topic,94060.msg1040699.html#msg1040699 herum findet zutreffend interpretiert zu haben? Die "7" verstehe ich allerdings nicht, wäre ohne testen auf 5 oder 9 gekommen.)

In meinen Versuchen die shellydimmer dimup und dimdown Logik nach Tasmota zu überführen ist mir aufgefallen das die Multiplikation mit 10 in den Zeilen 1986 und 1987 fehlt.
  dimup:noArg { my $num=int((ReadingsNum($NAME,'pct',0)+4)/10)*10+10; return qq {shellies/DEVNAME/light/0/set {"turn": "on", "brightness": $num}}; }\
  dimdown:noArg my $num=int((ReadingsNum($NAME,'pct',0)+7)/10)*10-10; return qq {shellies/DEVNAME/light/0/set {"turn": "on", "brightness": $num}}; }\

[workinprogress]
Für ein Tasmota Gerät mit jsonmap Dimmer:pct Reading habe ich bisher

dimup:noArg { my $num=int((ReadingsNum($NAME,'pct',0)+4)/10)*10+10; return qq {cmnd/Tasmota-LSC-Filament-2/Dimmer $num}; }
dimdown:noArg { my $num=int((ReadingsNum($NAME,'pct',0)+7)/10)*10-10; return qq {cmnd/Tasmota-LSC-Filament-2/Dimmer $num}; }

in einem Tasmota Template kann daraus

  dimup:noArg { my $num=int((ReadingsNum($NAME,'pct',0)+4)/10)*10+10; return qq {CMNDTOPIC/Dimmer $num}; }\
  dimdown:noArg { my $num=int((ReadingsNum($NAME,'pct',0)+7)/10)*10-10; return qq {CMNDTOPIC/Dimmer $num}; }\

werden.

[/workinprogress]

Mit freundlichem Gruß

joelinux
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Pacman111178 am 12 April 2020, 10:41:30
Hallo Fhem User und Programmierer .
Ich bin ein totaler Anfänger, stelle gerade von Mqtt ( Moskito) auf Mqtt2Fhem_Server  um . Funktioniert sogar Prima . Aber wenn Ich das Template vom Sonoff Pow für einen Sonoff Pow lade , stürzt die Fhem ab !
Habe sie eigentlich auf nem Zero laufen habe aber zum testen gerade einen Pi3B+ dran .. aber das gleiche Problem .
Ich denke nicht das meine Frage um Hilfe hier richtig ist aber Ich komme hier im Forum nicht ganz klar!

LG Boris

Gesendet von meinem SM-G960F mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 12 April 2020, 10:46:47
Steht etwas im LOG?
Wie genau meinst du das "es stürzt ab".?
 Welche Meldung(en) erhält du?
Ist fhem nach ca 20 Sekunden wieder an und siehst du das Gerät dann noch?



Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Pacman111178 am 12 April 2020, 11:29:07
Hallo Danke für die schnelle Antwort!
"Connection Lost try in 5 Seconds " kommt von der Fhem nachdem Ich Set gedrückt habe !
Habe gerade das Template vom basic_state_power1 reingelade ohne Probleme.. habe gesehen das das wohl das Grund template vom Pow ist !
Aber alle Features vom Pow habe Ich wohl nicht ! Was kann Ich denn noch probieren wo kann Ich dir den log zeigen ?

Gesendet von meinem SM-G960F mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 12 April 2020, 11:32:06
Im Menü links steht Logfile. Da steht ggf genau zur Absturz Zeit etwas drin warum das so ist.

Hinzu würde ich grundsätzlich mal ein update machen. Vom lesen her ist das für mich ein Wunder das du fhem am laufen hast. Bitte nimm mir den Kommentar nicht böse.

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Pacman111178 am 12 April 2020, 11:40:03
Nein Kein Problem [emoji1]
Ich habe das vorher mit einem Kumpel gemacht , mittlerweile kämpfe Ich mich alleine weiter .. hab ne Awtrix alleine eingebunden und dadurch kam auch die Umstellung auf Mqtt2 ! Funktioniert ja auch super bei den Sonoff Basic , Sonoff SV  und einen  H801RGBW Controller  aber den kann Alexa leider nur Ein/ Aus und Dimmen schalten! Keine Farben .

Ich werde jetzt mal den Pow  komplett löschen und ihn wieder finden lassen von der Fhem dann werde Ich das Template versuchen zu laden und danach gucke Ich in den log !
Vielen Dank für deine Gedult !

Gesendet von meinem SM-G960F mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Pacman111178 am 12 April 2020, 11:43:28
PS : Fhem und Pow hatte Ich vorher upgedatet !

Gesendet von meinem SM-G960F mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 12 April 2020, 11:49:40
Löschen und neu anlegen hört sich gut an. Sind ja nur 10 Sekunden.



Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Pacman111178 am 12 April 2020, 12:01:29
So , Ich hoffe das hilft ...(https://uploads.tapatalk-cdn.com/20200412/443012406db974fd432a379d70db2582.jpg)

Gesendet von meinem SM-G960F mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 12 April 2020, 12:13:38
Leider bringt das nix.

Hast du dir den Artikel durchgelesen wie das mit mqtt2 funktioniert?
Hinzu empfehle ich dir mal so ein fhem guide durch zu lesen. Ich bin mir aktuell nicht mal sicher ob du fhem überhaupt über einen Browser öffnest.

Wir brauchen hier grundsätzlich immer ein list vom betroffenen Gerät. Hinzu alle Infos die wichtig sein könnten. Dazu zählen hier zb log Einträge oder der genaue Fehler usw. Leider scheinen wir das aber nicht hin zu bekommen. Also du muss unbedingt ein wenig lesen. Ich glaube das dir da so einige Dinge auffallen wo du dich freuen wirst das gelesen zu haben.

Danach bitte ein list vom neuen Gerät am besten vor Auswahl des templates und ein list danach...
Und bitte in die logdatei gucken. Wenn es geht bitte ein Bild was nicht aus der putty Konsole kommt.

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 13 April 2020, 06:58:53
[workinprogress]
in einem Tasmota Template kann daraus
  dimup:noArg { my $num=int((ReadingsNum($NAME,'pct',0)+4)/10)*10+10; return qq {CMNDTOPIC/Dimmer $num}; }\
  dimdown:noArg { my $num=int((ReadingsNum($NAME,'pct',0)+7)/10)*10-10; return qq {CMNDTOPIC/Dimmer $num}; }\
werden.
[/workinprogress]

Thx. für den Hinweis, hab's korrigiert bzw. aufgenommen...

(Noch ein Argument, das modularer aufzubauen, aber im Moment komme ich da nicht voran... => feel free, Vorschläge zu machen ;) ).


So , Ich hoffe das hilft ...(https://uploads.tapatalk-cdn.com/20200412/443012406db974fd432a379d70db2582.jpg)

Gesendet von meinem SM-G960F mit Tapatalk
Wie schon geschrieben: Screenshots sind Sch... (falls das eine Linux-Konsole ist, aus der du was rauskopieren willst: Strg+Umschalt+c geht, wenn man mit der Maus markiert hat).

Der screenshot sieht so aus, als würde die attrTemplate-Anweisung aus einem "alten" Fenster ausgeführt werden => browser vorher refreshen, wenn FHEM oben ist.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: joelinux am 13 April 2020, 07:42:06
Ich denke nicht das meine Frage um Hilfe hier richtig ist aber Ich komme hier im Forum nicht ganz klar!

LG Boris

Hallo Boris,

dein Gefühl, das deine Anfrage hier nicht 'richtig' ist trifft zu. Ebenso kann die Menge an Informationen im Forum einen schier erschlagen (zumindest geht es mir so).

Deine Anfrage kann gerne als neuer Gesprächsfaden im Bereich Anfängerfragen von dir eröffnet werden.
Dort kannst du auch Hilfestellung bei einer Erstellung einer detaillierten Problembeschreibung erhalten.

Im übrigen wundert es mich nicht das du FHEM zum Laufen gebracht hast.
FHEM zeigt damit eine seiner Stärken. Nach moderatem Studium von CommandRef, Wiki und Co. ist es möglich mit berechtigter Freude ein funktionsfähiges Hausautomations Projekt zu führen. Es freut mich, das du deinem persönlichen Hausautomations Projekt weitere Aufgaben hinzufügst und diese mit FHEM lösen möchtest.

Mit freundlichem Gruß

joelinux
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: riker1 am 14 Mai 2020, 08:25:48
Hallo, hätte hier eine Frage.

ich versuche stateFormat für ein Gosundsp1 so anzupassen, das ich
LWT IPADDress
POWER
und die Energiedaten
angezeigt bekomme und auch schalten kann.

das folgende geht so leider nicht. da werden die Werte nicht aufgelöst.
LWT
<a href="http://IPAddress" target="_blank">IPAddress</a>
POWER
{sprintf("aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"))}

das geht und die Energie Werte werden angezeigt. -> bekomme da aber nicht LWT, IP und Power rein.

LWT
{sprintf("aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"))}


wenn ich stateFormat so definiere:

{sprintf("aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"))
LWT
<a href="http://IPAddress" target="_blank">IPAddress</a>
POWER}

kommt die Fehlermeldung:
syntax error at (eval 10829061) line 2, near ")
LWT"

wenn ich es dann so eingebe:


{sprintf("aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"))
LWT
POWER
<a href="http://IPAddress" target="_blank">IPAddress</a>}
Search pattern not terminated at (eval 10832050) line 4.

und diese Variante:
{sprintf("aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1")),
LWT,
POWER
}
liefert

Bareword "LWT" not allowed while "strict subs" in use at (eval 10830429) line 1.
Bareword "POWER" not allowed while "strict subs" in use at (eval 10830429) line 1.

Danke für die Hilfe, bin leider kein PERL Kenner, ....

VG T
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 14 Mai 2020, 08:33:12
Also entweder du nutzt Perl oder aber so wie es vorgesehen ist. Du mischt aber.

Wenn du state Format in reinform nutzt, kannst du einfach den Namen des reading schreiben so wie bei lwt und es erscheint der Inhalt des readings.
Habe deinen Code nur überflogen aber auch hier macht es Sinn mal zu schauen, wie funktioniert stateformat eigentlich. Dazu auch den Zusammenhang mit devstateicon usw.

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 14 Mai 2020, 08:40:44
Bitte mißbraucht diesen Thread nicht für Basisfragen zu FHEM.

@riker1: Was du suchst ist ReadingsVal() & Co. Bitte dazu die commandref (Perl specials?) bemühen und notfalls dann einen separaten Thread im Anfängerbereich aufmachen.
Es gibt auch ein paar Perl-Beispiel in der attrTemplate-file, wie man das mit den href-Anker lösen kann. Das steht dann aber eher in devStateIcon, denke ich.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: riker1 am 14 Mai 2020, 09:13:01
Bitte mißbraucht diesen Thread nicht für Basisfragen zu FHEM.

@riker1: Was du suchst ist ReadingsVal() & Co. Bitte dazu die commandref (Perl specials?) bemühen und notfalls dann einen separaten Thread im Anfängerbereich aufmachen.
Es gibt auch ein paar Perl-Beispiel in der attrTemplate-file, wie man das mit den href-Anker lösen kann. Das steht dann aber eher in devStateIcon, denke ich.

ok danke werde da mal suchen
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Astrofreak85 am 08 Juni 2020, 10:00:23
Hi,

für den Shelly 3EM gibt es scheinbar noch keine templates?
Ich habs bisher zumindest gepackt die Wh und kWh umzurechnen, analog der anderen Shellys...
Was mir in der Anzeige fehlt sind:
Aktuelle Gesamtleistung
Gesamtverbrauch
ggf. ne Hochrechnung (sofern das realisierbar ist...?)

anbei mal die Readings.... die über MQTT kommen....ggf. hilft das jemanden ;)

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 08 Juni 2020, 10:56:57
Was mehr helfen würde, wäre ein (anonymisiertes) RAW - daraus kann man nämlich leichter attrTemplates basteln...
(Das ist übrigens nicht sooo schwer: hier wäre das 1er-pm als Basis eigentlich schon ganz gut und dann die addons für die Messkanäle dazupacken. Vielleicht magst du das mal versuchen? Was Trends angeht, bin ich aber wenig optimistisch, dass das so einfach zu lösen ist. Evtl. verlinkst du von hier aus zu deinem anderen Thread, dann können ggf. andere dabei helfen (ich habe keine Idee, event aggregator scheint auch nicht das richtige zu sein)).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Astrofreak85 am 08 Juni 2020, 11:48:03
defmod MQTT2_shellyem3_XXX MQTT2_DEVICE shellyem3_XXX
attr MQTT2_shellyem3_XXX IODev myBroker
attr MQTT2_shellyem3_XXX readingList shellyem3_XXX:shellies/shellyem3-XXX/online:.* online\
shellyem3_XXX:shellies/shellyem3-XXX/announce:.* { json2nameValue($EVENT, 'announce_', $JSONMAP) }\
shellyem3_XXX:shellies/shellyem3-XXX/relay/0:.* relay_0\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/0/power:.* emeter_0_power\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/0/pf:.* emeter_0_pf\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/0/current:.* emeter_0_current\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/0/voltage:.* emeter_0_voltage\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/1/power:.* emeter_1_power\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/1/pf:.* emeter_1_pf\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/1/current:.* emeter_1_current\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/1/voltage:.* emeter_1_voltage\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/2/power:.* emeter_2_power\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/2/pf:.* emeter_2_pf\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/2/current:.* emeter_2_current\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/2/voltage:.* emeter_2_voltage\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/0/energy:.* emeter_0_energy\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/0/returned_energy:.* emeter_0_returned_energy\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/0/total:.* emeter_0_total\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/0/total:.* {'emeter_0_kWh' => sprintf("%.2f",$EVENT/60/1000)}\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/0/total_returned:.* emeter_0_total_returned\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/1/energy:.* emeter_1_energy\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/1/returned_energy:.* emeter_1_returned_energy\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/1/total:.* emeter_1_total\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/1/total:.* {'emeter_1_kWh' => sprintf("%.2f",$EVENT/60/1000)}\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/1/total_returned:.* emeter_1_total_returned\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/2/energy:.* emeter_2_energy\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/2/returned_energy:.* emeter_2_returned_energy\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/2/total:.* emeter_2_total\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/2/total:.* {'emeter_2_kWh' => sprintf("%.2f",$EVENT/60/1000)}\
shellyem3_XXX:shellies/shellyem3-XXX/emeter/2/total_returned:.* emeter_2_total_returned
attr MQTT2_shellyem3_XXX room MQTT2_DEVICE

setstate MQTT2_shellyem3_XXX 2020-06-07 23:58:51 announce_fw_ver 20200601-123421/v1.7.0@d7961837
setstate MQTT2_shellyem3_XXX 2020-06-07 23:58:51 announce_id shellyem3-XXX
setstate MQTT2_shellyem3_XXX 2020-06-07 23:58:51 announce_ip 1.1.4.1
setstate MQTT2_shellyem3_XXX 2020-06-07 23:58:51 announce_mac XXX
setstate MQTT2_shellyem3_XXX 2020-06-07 23:58:51 announce_new_fw false
setstate MQTT2_shellyem3_XXX 2020-06-08 11:39:09 emeter_0_current 0.44
setstate MQTT2_shellyem3_XXX 2020-06-08 11:35:01 emeter_0_energy 54
setstate MQTT2_shellyem3_XXX 2020-06-08 11:35:01 emeter_0_kWh 0.06
setstate MQTT2_shellyem3_XXX 2020-06-08 11:39:09 emeter_0_pf 0.11
setstate MQTT2_shellyem3_XXX 2020-06-08 11:39:09 emeter_0_power 10.94
setstate MQTT2_shellyem3_XXX 2020-06-08 11:35:01 emeter_0_returned_energy 0
setstate MQTT2_shellyem3_XXX 2020-06-08 11:35:01 emeter_0_total 3535.3
setstate MQTT2_shellyem3_XXX 2020-06-08 11:35:01 emeter_0_total_returned 0.0
setstate MQTT2_shellyem3_XXX 2020-06-08 11:39:09 emeter_0_voltage 232.35
setstate MQTT2_shellyem3_XXX 2020-06-08 11:39:09 emeter_1_current 0.70
setstate MQTT2_shellyem3_XXX 2020-06-08 11:35:01 emeter_1_energy 372
setstate MQTT2_shellyem3_XXX 2020-06-08 11:35:01 emeter_1_kWh 0.08
setstate MQTT2_shellyem3_XXX 2020-06-08 11:39:09 emeter_1_pf 0.45
setstate MQTT2_shellyem3_XXX 2020-06-08 11:39:09 emeter_1_power 73.54
setstate MQTT2_shellyem3_XXX 2020-06-08 11:35:01 emeter_1_returned_energy 0
setstate MQTT2_shellyem3_XXX 2020-06-08 11:35:01 emeter_1_total 4618.8
setstate MQTT2_shellyem3_XXX 2020-06-08 11:35:01 emeter_1_total_returned 0.0
setstate MQTT2_shellyem3_XXX 2020-06-08 11:39:09 emeter_1_voltage 232.54
setstate MQTT2_shellyem3_XXX 2020-06-08 11:39:09 emeter_2_current 0.30
setstate MQTT2_shellyem3_XXX 2020-06-08 11:35:01 emeter_2_energy 294
setstate MQTT2_shellyem3_XXX 2020-06-08 11:35:01 emeter_2_kWh 0.45
setstate MQTT2_shellyem3_XXX 2020-06-08 11:39:09 emeter_2_pf 0.81
setstate MQTT2_shellyem3_XXX 2020-06-08 11:39:09 emeter_2_power 57.25
setstate MQTT2_shellyem3_XXX 2020-06-08 11:35:01 emeter_2_returned_energy 0
setstate MQTT2_shellyem3_XXX 2020-06-08 11:35:01 emeter_2_total 26923.1
setstate MQTT2_shellyem3_XXX 2020-06-08 11:35:01 emeter_2_total_returned 8190.0
setstate MQTT2_shellyem3_XXX 2020-06-08 11:39:09 emeter_2_voltage 234.34
setstate MQTT2_shellyem3_XXX 2020-06-07 23:58:51 online true
setstate MQTT2_shellyem3_XXX 2020-06-08 11:39:09 relay_0 off


Der andere Thread: https://forum.fhem.de/index.php/topic,111905.0.html
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 09 Juni 2020, 08:48:43
Den em habe ich jetzt in einer ersten Fassung mit aufgenommen.

Was da noch zu verbessern wäre ist das Thema stateFormat/devStateIcon. Auf Basis der hoffentlich jetzt vorhandenen userReadings sollte das eigentlich eine lösbare Aufgabe sein, das vollends zuzuarbeiten...


Ich habe (u.a. auch) den shelly-2.5 angepaßt (https://forum.fhem.de/index.php/topic,111785.0.html). Da wäre es nicht schlecht, wenn das jemand mal testen würde... (@87insane: das war nicht so trivial, wie du dir das vorgestellt hast, schau mal bitte in den changelog, dann wird das hoffentlich etwas klarer).

Bitte Antworten
- zu dem em möglichst in dem em-Thread und
- zum 2.5 in dem verlinkten Thread oder dem allg. Shelly-Thread (da gibt es ggf. mehr betroffene User).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Astrofreak85 am 10 Juni 2020, 16:35:07
Für den 3EM wurden durch das Template bei mir keine userReadings angelegt..hmm
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 10 Juni 2020, 17:45:18
Hey und guten Nachmittag,

ich wollte mir mal wünschen. In wie weit das zu implementieren ist, weiß ich nicht bzw. kann ich nicht abschätzen.

Ich würde gerne nach Template Auswahl die Möglichkeit haben, ein Gerät zurück zu setzen. Also quasi auf Zustand wie es ankam. Da die Templates an sich nur etwas hineinschreiben und das ja auch nur change ist, müsste dies doch möglich sein oder?

Ja - natürlich kann man zum testen eine Kopie anlegen usw. Aber gerade für Anfänger scheint mir das eine gute Lösung.

Gruß,
87Insane
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 10 Juni 2020, 19:36:27
Das ist der Wunsch nach "undo", und damit das einigermassen sicher funktioniert, muss man vorher ein save, und nachher ein restore+restart durchfuehren.
Z.Zt. ist mit fhem.cfg nur ein "undo" am Tag moeglich, bei configdb weiss ich nicht.
Ein "Restore" Knopf koennten wir beim nachsten Umbau der Menu-Leiste ueberlegen, um den Vorgang fuer Kommandozeilen-Phobiker zu erleichtern.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 10 Juni 2020, 22:41:58
Das ist sogar weiter gedacht! Gute Idee! Danke

Bei den Templates habe ich eher an eine kleine ausgelagerte Datei gedacht die mitläuft sobald attrtemplate..
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 11 Juni 2020, 06:30:37
Ob man den Luxus braucht? (Ich werde niemandem dazu in den Arm fallen, aber z.B. die Optionen, die mir als configDB-User zur Verfügung stünden, nutze ich auch fast nicht...).
Finde aber die Idee von 87insane durchaus charmant und würde mich auch freuen, wenn du (87insane) dazu Code bereitstellst bzw. (nach den ersten Versuchen!) einen neuen Thread anfängst. Würde sogar gleich zwei Varianten anbieten, die allerdings - anders als das einfache vorherige save+shutdown/restart ohne nochmaliges save - Schwierigkeiten mit mehrkanaligen Devices hätten. Alle diese  templates kämen nach general_use, (jedoch nicht als "versteckte").

1. Kopie im laufenden System halten, attrTemplate auf originales Device anwenden, "Rücksichern" durch delete+rename.
Syntax (1. Variante nur via Kommandozeile...):
set <device> attrTemplate makeCopy attrtemplate_name
set <device> attrTemplate recoverFromCopy

2. Kopie als RAW-list ins log-Verzeichnis
set <device> attrTemplate saveRawCopy
set <device> attrTemplate recoverFromRawCopy
Das würde (überschreibend) ein RAW-list ins log-Verzeichnis (Filesystem) packen, Namensgebung: DEVICE_YYYYMMDD.rawdef, und beim "recover" alle Attribute+Readings löschen und dann den RAW-Code drüberklatschen?

Ich denke, ggf. mit etwas Unterstützung von meiner Seite (oder es darf auch jemand anderes coachen) bekommst du, 87insane, das hin ;) . Falls du es nicht angehen willst und sich viele Befürworter finden, die sich ebenfalls nicht in der Lage dazu sehen, mache ich mich notfalls auch selbst dran...?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: moskito am 16 Juni 2020, 18:52:12
Ich wollte gerade einen Shelly2.5 neu einrichten und musste feststellen, dass das Template in der aktuellen Version von FHEM nicht mehr passt.
Aus dem svn:
name:shelly25_split
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shelly2.5 using original firmware. <br>NOTE: a second device will be created for the second channel
order:A_11a1
par:DEVNAME;Shelly2 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
par:CALLSPEECHRECOGN;Set this to 0 to not set any speech recogn. related attributes;{ 1 }
set DEVICE attrTemplate shelly1_w_energy_meassuring \CALLSPEECHRECOGN=0

In einer alten Version aus meinen Backups:
name:shelly25_split
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shelly2.5 using original firmware. <br>NOTE: a second device will be created for the second channel
order:A_11a1
par:DEVNAME;Shelly2 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
set DEVICE attrTemplate shellyplug

Irgendwas ist da durcheinander...

Gruß
Danny
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 16 Juni 2020, 20:23:41
Anders ja, aber: was genau funktioniert nicht?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: moskito am 16 Juni 2020, 20:42:08
Es legt keinen 2. Channel an, das war eigentlich das auffälligste.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 17 Juni 2020, 08:21:31
Danke für den Hinweis; hatte da ergänzend was umgestellt und offenbar dabei die beiden 2-kanaligen Shelly übersehen... Jetzt (svn-Version bzw. nach dem morgigen update) sollte es wieder (anders) funktionieren :) .
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: CBSnake am 17 Juni 2020, 13:07:07
Hi,

ich häng mich mal ran, warte aber das morgige update ab :-)
Ich kann keinen meiner beiden shelly 2.5 mehr schalten (über des webinterface der shelly gehts noch) und bekomm auch keine Werte (Power Schaltzustand usw) mehr in FHEM.

Grüße
Achim
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 17 Juni 2020, 13:18:06
ich häng mich mal ran, warte aber das morgige update ab :-)
Ich kann keinen meiner beiden shelly 2.5 mehr schalten (über des webinterface der shelly gehts noch) und bekomm auch keine Werte (Power Schaltzustand usw) mehr in FHEM.
Ähm, da werde ich nicht so recht schlau draus:
- das attrTemplate (u.a.) für die beiden shelly2-Modelle hatte ich umgebaut, aber vorrangig im Hinblick auf den allgemeinen Umbau der "Grundstruktur" aller mehrkanaligen Devices. Dabei habe ich ein zentrales (nicht speziell auf MQT2_DEVICE gemünztes) attrTemplate eingeführt, das mit ein paar Optionen aufgerufen werden kann und dann Kopien anlegt (der Teil war mir raus => jetzt gefixt),  die Querbezüge (comment+associatedWith) setzt usw..
- Bzgl. Shelly scheinen ein paar neue Topics dazugekommen zu sein (temperature_f usw.). Da habe ich auch was ergänzt, das könnte bzgl. Power helfen, hat aber mit dem Schalten nichts zu tun.

ABER: Wenn ein ehemals funktionierendes Device (danach klingt es, oder habe ich den Punkt falsch verstanden?) einfach nur nicht mehr funktioniert, klingt das danach, als wäre irgendwas grundsätzlich geändert worden. Da der Hersteller scheinbar grade neue firmware-Versionen rausbringt, wäre das m.E. mal näher zu untersuchen und ggf. dann die betreffenden templates insgesamt zu überarbeiten.

Dazu wäre aber interessant zu wissen, ob ein fw-update durchgeführt wurde, und was ggf. autocreate daraus so an Device/readingList macht... Details dazu dann aber bitte nicht hier, sondern in dem Shelly-attrTemplate-Thread.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: CBSnake am 17 Juni 2020, 14:12:12
Hi,

eigentlich wollte ich dir jetzt ein List von einem shelly posten, hab dann aber gemerkt da haut was nicht hin ;-) Update um 03:00 letzte Readings aber 05:00 hab jetzt den PI mal durchgestartet, geht wieder *puhh* sorry für die aufregung

Grüße
Achim
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: bicmac am 19 Juni 2020, 16:07:44
Hi,
OpenSprinkler unterstützt seid heute ja MQTT und damit kan ich auch endlich den Status der Bewässerungsanlage ohne HTTPMOD abfragen.
Er meldet ansich auch schon gut an FHEM und hat das Device angelegt. 
Leider sehe ich in der Erstellung von templates nicht wirklich durch und wollte fragen ob mir jemand dort helfen bzw mir ein template bauen könnte.
Hier die Beschreibung der Topics in der aktuellen FW Version von Opensprinkler:

https://openthings.freshdesk.com/support/solutions/articles/5000859089-how-to-use-mqtt

Firmware 2.1.9(4) Topics:
At the moment of this writing, the OpenSprinkler firmware only supports publishing data to the broke. You can use a subscriber client (e.g. the mosquitto_sub command, or a mobile MQTT client, or a home automation hub that supports MQTT) to receive the data. A list of currently supported topics are detailed below:

The root topic name is always opensprinkler. In future firmware, we will allow users to customize the root topic, in order to provide better support for multiple OpenSprinkler devices you may have.
opensprinkler/system: this topic receives {"state":"started"} message when the controller boots.
opensprinkler/station/x: where x is the index (starting from 0) of the station/zone. For example, the first zone is 0, the second zone is 1 and so on. This topic receives {"state":1} message when station/zone x starts running, and {"state":0,"duration":ss} message when the zone finishes running, where ss is the number of seconds that it ran. To receive data for all stations, you can subscribe to wildcard topic opensprinkler/station/#
opensprinkler/sensor1: this topic receives {"state":1} when sensor 1 activates and {"state":0} when sensor 1 deactivates.
opensprinkler/sensor2: similar to above but for sensor 2.
opensprinkler/raindelay: similar to above but for rain delay.
opensprinkler/sensor/flow: this topic receives {"count":cc,"volume":vv} when the flow sensor generates data (usually when a zone finishes running), where cc is the flow count, and vv is the amount of volume.

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 19 Juni 2020, 16:30:42
Das sollte sich hinbekommen lassen.

Bitte mach' einen neuen Thread dazu auf und poste dort eine RAW-Definition.
Wäre gut, wenn sich dann ggf. noch jemand einklinken würde, der das noch hat/nutzt.

Das das ganze im Moment nicht aktiv gesteuert werden kann, sondern nur zur Statusanzeige gedacht zu sein scheint, dürfte das nicht allzu kompliziert sein.

Wenn ich das so lese, kann man auf der opensprinkler-Seite (derzeit noch) nichts einstellen, also insbesondere nichts an den Topic-Pfaden ändern?

Falls wir mittelfristig darüber auch steuern können sollen, wäre die Frage, ob man die einzelnen Zonen als eigene Devices anlegt (bräuchte man für FHEM-on-for-timer)?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: bicmac am 19 Juni 2020, 16:43:56
ja ich denke früher oder später kann man damit auch steuern und amit wären pro zone eigene Devices ggf garnicht schlecht.
für den Anfang jetzt würde mir auch eine nur anzeige in dem normalem device reichen.
ich hatte es mit folgender Readinglist probiert aber die ging nicht. :-(

OS_D8803963182F:opensprinkler/availability:.* availability
OS_D8803963182F:opensprinkler/system:.* { "system-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/sensor1:.* { "sensor1-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/sensor1:.* { "sensor2-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/raindelay:.* { "raindelay-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/sensor/flow:.* { "flow-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/0:.* { "Station0-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/1:.* { "Station1-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/2:.* { "Station2-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/3:.* { "Station3-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/4:.* { "Station4-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/5:.* { "Station5-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/6:.* { "Station6-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/7:.* { "Station7-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/8:.* { "Station8-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/9:.* { "Station9-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/10:.* { "Station10-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/11:.* { "Station11".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/12:.* { "Station12-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/13:.* { "Station13".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/14:.* { "Station14-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/15:.* { "Station15-".json2nameValue($EVENT) }
OS_D8803963182F:opensprinkler/station/16:.* { "Station16-".json2nameValue($EVENT) }


Ich mache mal einen neuen thread dazu auf.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 19 Juni 2020, 16:51:21
Gut; aber gleich eine Anmerkung zu json2nameValue(). Das hat eine andere Syntax und der Perl-Aufruf sollte (exemplarisch für Sensor 1 => S1_...) eher so aussehen:
{ json2nameValue($EVENT,'S1_',$JSONMAP) }
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: bicmac am 19 Juni 2020, 17:00:25
ja so hat es nun geklappt:

attr Opensprinkler readingList OS_D8803963182F:opensprinkler/availability:.* availability\
OS_D8803963182F:opensprinkler/system:.* { json2nameValue( $EVENT, 'System_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/sensor1:.* { json2nameValue( $EVENT, 'Sensor1_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/sensor2:.* { json2nameValue( $EVENT, 'Sensor2_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/raindelay:.* { json2nameValue( $EVENT, 'raindelay_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/sensor/flow:.* { json2nameValue( $EVENT, 'flow_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/0:.* { json2nameValue( $EVENT, 'Station0_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/1:.* { json2nameValue( $EVENT, 'Station1_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/2:.* { json2nameValue( $EVENT, 'Station2_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/3:.* { json2nameValue( $EVENT, 'Station3_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/4:.* { json2nameValue( $EVENT, 'Station4_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/5:.* { json2nameValue( $EVENT, 'Station5_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/6:.* { json2nameValue( $EVENT, 'Station6_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/7:.* { json2nameValue( $EVENT, 'Station7_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/8:.* { json2nameValue( $EVENT, 'Station8_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/9:.* { json2nameValue( $EVENT, 'Station9_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/10:.* { json2nameValue( $EVENT, 'Station10_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/11:.* { json2nameValue( $EVENT, 'Station11_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/12:.* { json2nameValue( $EVENT, 'Station12_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/13:.* { json2nameValue( $EVENT, 'Station13_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/14:.* { json2nameValue( $EVENT, 'Station14_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/15:.* { json2nameValue( $EVENT, 'Station15_', $JSONMAP ) }\
OS_D8803963182F:opensprinkler/station/16:.* { json2nameValue( $EVENT, 'Station16_', $JSONMAP ) }

evtl kann man das ja schon in ein Template packen zum Anzeigen. Ich update auch mal meinen anderen Thread dazu.
Titel: Antw:mqtt2.template: tasmota_ir
Beitrag von: drhirn am 01 Juli 2020, 15:58:17
Hi,

versuche gerade ein Device einzurichten, das mit Tasmota_IR geflashed wurde. Da werden beim Übernehmen des Templates ein paar Dinge gefragt. Und ich hab keine Ahnung, was die zu bedeuten haben bzw. was ich hier eintragen soll.

Specify the unknown parameters for tasmota_ir:
needed command to be sent like in example dec '{"protocol":"NEC","bits":32,"data":551489775}' (without '')
needed command to be sent like in example raw '0,926,844,958,832,1798,868,902,848,900,870,900,852,908,918,958,794,934,874,928,1738,934,856,1764' (without '')
needed command to be sent like in example hex '{"Protocol":"NEC","Bits":32,"Data":0x8166817E}' (without '')
needed command to be sent like in example hex '{"Protocol":"NEC","Bits":32,"Data":0x8166817E}' (without '')

Kann mir da bitte jemand weiterhelfen?

Danke!
Stefan
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 01 Juli 2020, 16:34:58
Das ist ein Henne-Ei-Problem:

Du kannst das erst wissen, wenn du die IR-Codes gesehen hast, und dazu brauchst du wiederum erst die Infos, die in den Readings des zu erstellenden Devices drin sind...

Hmm, habe jetzt mal gesucht, aber scheinbar gibt es keinen wirklichen Thread zur (Weiter-)Entwicklung des templates. Vorläufig bzw. beim ersten Mal würde ich vorschlagen, einfach die Beispiele zu kopieren und dann das Ding mal näher anzusehen. Die weitere Ausarbeitung und Anpassung dann an deine IR-Codes ist sowieso "Handarbeit" ;) .

Falls Interesse besteht, das template weiterzuentwickeln, bitte einen separaten Thread starten... (Ich habe den Tasmota zwischenzeitlich nicht mehr im Einsatz, das geht bei mir jetzt alles via LAN).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: drhirn am 02 Juli 2020, 16:43:28
Nun, mir wurden automatisch zwei Devices angelegt. Beim einen hab ich schon brauchbare Readings:

IrReceived_Bits            32
IrReceived_Data          0x12181140
IrReceived_DataLSB    0x48188802
IrReceived_Protocol     NEC_LIKE
IrReceived_Repeat      0

Ich weiß nur nicht, was needed command to be sent like in example hex und die anderen drei Sätze bedeuten sollen.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 02 Juli 2020, 17:07:10
Na ja, vermutlich wollte ich einfach drei (nicht 4, das dürfte ein Versehen sein) Varianten zeigen, wie man Sendecodes notieren und erfolgreich versenden kann...?
Was du davon nutzt, bleibt dir überlassen; du kannst die betreffenden Zeilen am Ende auch aus dem "fertigen" Device rauslöschen.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: drhirn am 02 Juli 2020, 17:49:38
Verstehe. Gut, ich hab da jetzt einfach mal irgendwas eingetragen. Und die IR-Codes dann händisch korrigiert. Hat funktioniert.

Danke dir!
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 02 Juli 2020, 17:55:05
Na ja, falls du Vorschläge hast, wie man das besser darstellen oder erklären kann, überarbeite ich das template gerne (und auch das praktisch baugleiche RF) bzw. übernehme entsprechende Vorschläge... Ist nur eben so, dass ich das effektiv nur zu Testzwecken genutzt hatte und die IR-Reichweite für den eigentlichen Einsatzzweck zu gering gewesen war, daher habe ich das irgendwann auf die Seite gelegt bzw. auch vorher schon (historisch bedingt) hauptsächlich im "remotecontrol"-Modus genutzt.

Bisher war das Interesse anderer User auch eher gering, die meisten scheinen die UDP-KVP-firmware mit dem Ding zu verwenden.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: drhirn am 02 Juli 2020, 18:07:45
Es ist jetzt nicht so, dass ich der große Hero in Bezug auf MQTT und Templates wäre. Somit auch eher keine große Hilfe.

Aber wenn wir schon dabei sind, gibt's eigentlich irgendwo eine aktuelle Erklärung, wie man so ein Template erstellt? Habe die letzten Tage danach gesucht, wurde aber nicht wirklich fündig.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 03 Juli 2020, 09:36:06
Bei meiner Anfrage geht es auch eher um Themen wie "wording" bei der Parameter-Abfrage und der Beschreibung, die man ggf. vorher erhält. Das ist eigentlich nichts attrTemplate-spezifisches, sondern eher eine Doku-Frage, daher dachte ich, damit ggf. an den richtigen geraten zu sein ;) .

Doku zu attrTemplate allg. ist hier: https://wiki.fhem.de/wiki/AttrTemplate. Der einfachste Weg ist mMn.,
- Konfiguration des Geräts vornehmen (ganz normal);
- RAW-Def kopieren;
- ähnliches Device suchen, für das ein attrT. exisitiert und das dann zu überarbeiten, indem man das RAW dann parametriert und die Doku entsprechend anpasst.

Das Problem liegt häufiger eher darin, Schritt 1 sauber zu machen, also die Gerätekonfiguration nicht nur "sosolala" hinzubiegen, sondern das wirklich dahingehend zu optimieren, dass jeder "Teilschritt zu einem guten Device" durchdacht ist, die Möglichkeiten der firmwares usw. auf der Gegenstelle genutzt werden bzw. möglichst "ausgereizt", (FHEM-) Standards (Readingnamen) beachtet werden usw....
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: FunkOdyssey am 03 Juli 2020, 09:49:59
Es gibt die Vorlage tasmota_4channel_split. Dabei werden zusätzliche Kanäle 2,3 und 4 angelegt. Kanal 1 beinhaltet zusätzlich noch sämtliche Tasmota-Daten.

Kann man das auch so splitten, dass man eine Tasmota-Bridge dafür hat und die Kanäle 1-4 nur mit dem state-Reading?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 03 Juli 2020, 10:12:28
Na ja, man könnte schon 5 Geräte daraus machen, aber den Mehrwert sehe ich auf die Schnelle nicht. Eine echte "bridge" wird das weitere Device aber mMn. nicht, als "bridge" werden innerhalb der mqtt2.template in der Regel nur Geräte bezeichnet, die eine bridgeRegex enthalten.
Eigentlich finde ich das bei allen diesen mehrkanaligen zielführend, dass der erste Kanal die weiteren Daten enthält und der Rest eher spartanisch ist (der 4-er ist insoweit nur eine erweiterte Kopie des 2-er...).

Du hast aber jederzeit die Option, einfach mit einer weiteren Kopie vom 1. Kanal zu arbeiten und da den Teil zu lassen, der nichts mit dem eigentlichen Aktor zu tun hat und im anderen den Rest rauszuwerfen. Nur eben nicht via attrTemplate.

Falls da allg. Bedarf gesehen wird: Es gibt zur Frage einer eventuellen Neustrukturierung/Diversifizierung der Tasmota-Templates einen eigenen Thread. Wer auch immer (am besten: vercodete) Vorschläge machen will, darf das da gerne zur Diskussion stellen (ich wäre für eine "classic line" zu haben, die insbesondere eher einfachere devStateIcon enthält...).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: FunkOdyssey am 03 Juli 2020, 10:45:08

Du hast aber jederzeit die Option, einfach mit einer weiteren Kopie vom 1. Kanal zu arbeiten und da den Teil zu lassen, der nichts mit dem eigentlichen Aktor zu tun hat und im anderen den Rest rauszuwerfen. Nur eben nicht via attrTemplate.


Danke. So werde ich das machen. Ich habe einfach zu viele Informationen in dem Kanal 1, die ich nicht überall (event-on..., FileLog) wieder ausschließen möchte.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: riker1 am 09 August 2020, 10:30:36
Hallo, hätte eine Frage zu den AttribTemplate.
Wo sehe ich denn im nach hinein, welches Template ich verwendet habe?

Wo wird das denn gespeichert?

Danke T

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 09 August 2020, 11:03:28
Zitat
Wo wird das denn gespeichert?

Im Attribut model

Gruß

Thomas
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: riker1 am 09 August 2020, 11:21:14
Im Attribut model

Gruß

Thomas

Hi Thomas, super danke.

Das attribute kann man aber nur durch set attrtemplate verändern, bzw initial setzen. dann, oder?

Ich kann nicht einfach das attrib model manuel füllen?


Vielen Dank T
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 09 August 2020, 11:34:34
Versuch macht kluch
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: riker1 am 09 August 2020, 11:37:09
Versuch macht kluch

das stimmt, leider immer blöd da man oft in PRODUKTION arbeitet und ich mir schon oft EIER ins Nest gelegt hatte.....

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 09 August 2020, 12:17:51
Hi Thomas, super danke.

Das attribute kann man aber nur durch set attrtemplate verändern, bzw initial setzen. dann, oder?

Ich kann nicht einfach das attrib model manuel füllen?


Vielen Dank T
Worin steckt der Sinn dieser Frage? Wenn attrTemplate dieses Attribute setzt und es damit das Template welches verwendet wurde repräsentiert warum sollte man es danach manuell setzen?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: riker1 am 09 August 2020, 12:23:28
Worin steckt der Sinn dieser Frage? Wenn attrTemplate dieses Attribute setzt und es damit das Template welches verwendet wurde repräsentiert warum sollte man es danach manuell setzen?

Hi Otto,

habe halt diverse tasmotas und es kommen ja nach Modell ja diverse readinglists, setlists, etc. über die Templates.

Manchmal heissen die readings dann aber anders mit anderen Prefixes, etc.

Wollte dann einiges angleichen und mir war nicht klar wie ich dies manuell anpasse.

AttrTemplates erneut setzen überschreibt dann manchmal zuviel.

vielleicht macht es das klarer.

VG T
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 09 August 2020, 12:33:15
Das Attribut model ist völlig unabhängig von der Konfiguration des Devices, kannst da reinschreiben was du möchtest oder auch löschen.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 09 August 2020, 12:39:59
Naja entweder baust Du konsequenter eigene Templates und setzt dort auch wieder konsequenterweise ein anderes model.
Aber verhindern ein anders Template anzuwenden tut das auch nicht. Wenn Du es nur für Dich kennzeichnen willst setzt doch einfach ein Reading Deiner Wahl?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: riker1 am 09 August 2020, 12:45:57
Naja entweder baust Du konsequenter eigene Templates und setzt dort auch wieder konsequenterweise ein anderes model.
Aber verhindern ein anders Template anzuwenden tut das auch nicht. Wenn Du es nur für Dich kennzeichnen willst setzt doch einfach ein Reading Deiner Wahl?

..daran arbeite ich gerade mit meinen begrenzen Kenntnissen.....

Danke für die Hilfe
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: riker1 am 09 August 2020, 12:55:46
Hallo

allerdings hätte ich ne Frage.

Warum klappt die Verwendung von $NAME

rule1:on,off cmnd/$NAME/rule1 $EVTPART1

in der Setlist aber nicht in der readinglist?

Danke VG T


Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 09 August 2020, 13:11:26
schau mal hier: https://forum.fhem.de/index.php?topic=108376.0
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 10 August 2020, 09:41:43
Manchmal heissen die readings dann aber anders mit anderen Prefixes, etc.
Wäre nett, wenn du eventuell gefundene Inkonsistenzen dann ggf. etwas konkreter benennen könntest - in der Regel ist das dann eher nicht beabsichtigt, sondern gleiche Dinge sollten eigentlich auch gleich heißen (und - sofern setzbar - auch gleich funktionieren).

Neben dem "model"-Attribut wird btw. auch seit einigen Monaten auch das Reading "attrTemplateVersion" geschrieben - so kann z.B. ich auch erkennen, wann das das letzte Mal angefaßt wurde und leichter feststellen, ob eine Frage die aktuelle oder eine ggf. bereits veraltete Variante betrifft. Das war btw. auch eine Anregung aus dem Kreis der User. Vielleicht hilft dir das auch, eventuelle Änderungen schneller zu identifizieren? Über das Datum sollte sich dann auch leichter im svn feststellen lassen, wie die Änderung genau war, wenn du längere attrTemplate mit deinen aktuellen Settings vergleichen müßtest.

Und nochmal zum Basisverständnis: attrTemplate funktioniert nicht "autmatisch", sondern es setzt immer eine User-Aktion voraus. Du kannst also die model- und attrTemplateVersion-Infos selbst beliebig setzen und verwenden, solange du keines der "Standard"-attrTemplate benutzt, passiert da auch nichts - jedenfalls nicht durch AttrTemplate.pm.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: riker1 am 12 August 2020, 10:05:46
Hallo


danke für die Antworten

habe halt viel mit diversen tasmotas rumgespielt als ich von ESPEasy zu tasmota wechselte.

Habe Witty Clouds, ESP01, ESP8266, Gosund, Sonoff, etc.  mit verschiedensten Funktionen bzw Sensoren dran.


Aufgeallen sind mir Inkonsistenzen , wenn es wirklich welche sind vor allem z.B. bei:
IPAddress.
Aber auch Gross und Kleinschreibung von Readingnames
- wobei die ReadingsValue wegen Gross/Klein wohl über tasmota setoptions gesteuert werden

Kann aber nicht mehr genau sagen durch welche templates es entstanden ist, da ich die templates auch wieder neu gesetzt hatte. Manchmal mit deletereadings device .*

Teileweise sind sie wohl auch durch autocreate entstanden und commands über die Tasmota Console.
War hat viel rumgespiele dabei da ich mich hier erst neu einarbeiten musste.
Eventuell hilft das?

Beispiele:IP

 STATUS5_StatusNET_IPAddress
IPAddress
StatusNET_IPAddress

INFO2_IPAddress

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 12 August 2020, 10:54:31
Hmm, kann nur vermuten, dass du zum einen irgendwann mal "complex" am IO eingestellt gehabt hattest und zum anderen die Erwartung hast, dass die automatisch generierten Readingnamen dem entsprechen, was dann nach den attrTemplate-Anweisungen rauskommt.

Insbesondere letztere wollen die attrTemplate gar nicht erfüllen, denn es soll am Ende immer dasselbe rauskommen, egal, ob man am IO-Device "complex" oder "simple" für autocreate verwendet (oder alles manuell macht), und es soll auch möglichst bei verschiedenen Firmwares derselbe content am Ende denselben Readingnamen haben (v.a. wenn es um "temperature" etc. geht). Das läßt sich gar nicht anders machen, wie dass man bestimmte Dinge umbenennt... Genau deswegen werden die alten Readings mit den nicht fortgeführten Namen ja gelöscht ;) .

Interessant sind m.E. daher nur solche "Inkonsistenzen", die _nach_ der Anwendung von attrTemplate ggf. noch verbleiben, der Rest ist mir ehrlich gesagt ziemlich gleichgültig.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: lin_win am 12 August 2020, 17:34:27
Hallo,
wie bekomme ich bei automaisch angelegten MQTT2 Devices in der Set-Liste das "set attrTemplate" weg ?
Nachdem ich "set attrTemplate" angewendet habe, taucht es noch als erster Eintrag auf.
Klar gibt es Anwendungen mehrmals das attrTemplate zu nutzen, aber in den meisten
Fällen (speziell bei mir) führt es zu Verwirrung.

LG
Jürgen
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 12 August 2020, 17:46:29
Über "global" läßt sich das attrTemplate-feature komplett deaktivieren. Ist aber 0/1, das bedeutet, das gilt für alle Geräte (auch HTTPMOD etc.)
Falls du andere User hast, die ggf. Zugriff auf FHEM haben, ist es evtl. zielführender, für diese eine eigene FHEMWEB-Instanz einzurichten und dort dann nur eingeschränkte Commands.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: lin_win am 12 August 2020, 18:09:02
Danke für den Tip, hab es dann auch in Wiki über AttrTemplate gefunden  8)
attr global disableFeatures attrTemplate

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: gerdshi am 30 August 2020, 00:57:58
Ich habe seit 2 Tage ein Shelly 3EM und bei der Anweung des passende Template, bekomme ich die Fehlermeldung:
Global symbol "$state" requires explicit package name at (eval 41328) line 1Daher die Frage ist das ein Bug oder habe ich was falsch gemacht bzw. was solte ich korrigieren? ;-)
Da es ein Testversion sein soll, laut ?, dachte mir vielleicht hilft die Meldung beim debugen?

Die Energiewerte passen alle, jedoch das ein und auschalten des Relais funktioniert nicht.

Danke!
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 30 August 2020, 06:25:46
Danke für's melden. Da waren noch mehrere Kleinigkeiten zu verbessern ::) ... (Die anderen beiden user, die den hatten, waren leider nicht besonders rückmeldefreudig zu diesem attrTemplate) Jetzt könnte es dann passen, aber bitte wirklich erst nochmal sehr kritisch über das Ergebnis drüber sehen!

Generell: Bei einigen mehrkanaligen gab es auch noch die eine oder andere Unsauberkeit, und auch das mit der Sprachsteuerungsintegration ist in dem Bereich irgendwie noch nicht ganz so, wie ich mir das vorstelle... (siehe https://forum.fhem.de/index.php/topic,113827.0.html)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: gerdshi am 30 August 2020, 10:34:08
Danke für die schnelle Reaktion.
Verstehe, werde es Testen und Bescheid geben.

Edit: Ich habe es ausprobiert und es fällt mir nun auf, dass beim setzen des Templates mir durch das alexa-fhem Modul 2 Abfragen angezeigt anstelle von eine. Ist das so richtig weil es in beide Richtugen den Stromverbrauch messen kann?

Auffällt auch das in der Übersicht als State die 3 Phasen 3 mal wiederholen.

Das Relais lässt sich über der Icone noch nicht ganz steuern  - einschalten ja, abschalten nein. Wenn man es aber per MQTT-Befehl umschlatet, zeigt es aber auf jeden Fall den richtigen Status an.

Ich habe das Device gelöscht und automatisch neu anlegen lies, damit das Template nicht evtl. von alten Readings gestört wird.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 30 August 2020, 14:19:28
Danke für die prompte Rückmeldung.

Das mit dem doppelten Alexa ist (hoffentlich: war) ein bug, ebenso der dreifache STATE. Sollte jetzt beides weg sein, und eigentlich müßte sich das Relay dann auch über das verbleibende eine Icon auch korrekt in beide Richtungen schalten lassen.

Ich müßte aber ggf. das Gesamtergebnis sehen, falls es noch nicht klappt; dann würde mich ein RAW (als Text in code-Tags) samt der setstate-Zeilen interessieren - in dem Zustand, dass Icon und Sollzustand auseinanderfallen...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: gerdshi am 31 August 2020, 09:59:11
Danke für die prompte Anpassung!

Über der Icone gelingt es mir immer noch nicht das Relais zu schalten. Oder mache ich was falsch?
Am Ende webCmd     : ist so richtig?
Edit: Es lässt sich immer noch nur einschalten und dann nicht mehr abschalten über der Icone - wenn ich drauf drücke, kommt im Log dies: 020-08-31 10:03:31 MQTT2_DEVICE MQTT2_shellyem3_123456789012 on Obwohl bei andere Geräte sowas kommt:2020-08-31 10:05:15 MQTT2_DEVICE MQTT2_DVES_E81036 set_toggle
2020-08-31 10:05:16 MQTT2_DEVICE MQTT2_DVES_E81036 off

Das Problem mit den 4-fachen Anzeige der Leistung ist nun weg.

Die Anzeige mit total_sum funktioniert leider noch nicht.

Hier die RAW definition (habe lediglich die MAC-Adresse des Shellys ersetzt):defmod MQTT2_shellyem3_123456789012 MQTT2_DEVICE shellyem3_123456789012
attr MQTT2_shellyem3_123456789012 IODev MQTT2_Server
attr MQTT2_shellyem3_123456789012 comment To get appropriate loadState values: Change the default limit "100" in readingList to your needs.
attr MQTT2_shellyem3_123456789012 devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";;;; my $light = ReadingsVal($name,"state","off");;;; my $cons1 = ReadingsVal($name,"emeter_0_power","unknown");;;; my $cons2 = ReadingsVal($name,"emeter_1_power","unknown");;;; my $cons3 = ReadingsVal($name,"emeter_2_power","unknown");;;; my $total1 = ReadingsVal($name,"emeter_0_kWh","unknown");;;; my $total2 = ReadingsVal($name,"emeter_1_kWh","unknown");;;; my $total3 = ReadingsVal($name,"emeter_2_kWh","unknown");;;; my $total_sum = $total1+$total2+$total3;;;; "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>P1: $cons1 W / Total P1: $total1 kWh<br>P2: $cons2 W / Total P2: $total2 kWh<br>P3: $cons3 W / Total P3: $total3 kWh</div>"}
attr MQTT2_shellyem3_123456789012 model shelly3em
attr MQTT2_shellyem3_123456789012 readingList shellies/shellyem3-123456789012/online:.* online\
  shellies/shellyem3-123456789012/announce:.* { json2nameValue($EVENT) }\
  shellies/announce:.* { $EVENT =~ m,..id...shellyem3-123456789012...mac.*, ? json2nameValue($EVENT) : return }\
  shellies/shellyem3-123456789012/relay/0:.* state\
  shellies/shellyem3-123456789012/input_event/0:.* { json2nameValue($EVENT) }\
  shellies/shellyem3-123456789012/input/0:.* input0\
  shellies/shellyem3-123456789012/online:.* online\
  shellies/shellyem3-123456789012/emeter/0/power:.* emeter_0_power\
  shellies/shellyem3-123456789012/emeter/0/pf:.* emeter_0_pf\
  shellies/shellyem3-123456789012/emeter/0/current:.* emeter_0_current\
  shellies/shellyem3-123456789012/emeter/0/voltage:.* emeter_0_voltage\
  shellies/shellyem3-123456789012/emeter/1/power:.* emeter_1_power\
  shellies/shellyem3-123456789012/emeter/1/pf:.* emeter_1_pf\
  shellies/shellyem3-123456789012/emeter/1/current:.* emeter_1_current\
  shellies/shellyem3-123456789012/emeter/1/voltage:.* emeter_1_voltage\
  shellies/shellyem3-123456789012/emeter/2/power:.* emeter_2_power\
  shellies/shellyem3-123456789012/emeter/2/pf:.* emeter_2_pf\
  shellies/shellyem3-123456789012/emeter/2/current:.* emeter_2_current\
  shellies/shellyem3-123456789012/emeter/2/voltage:.* emeter_2_voltage\
  shellies/shellyem3-123456789012/emeter/0/energy:.* emeter_0_energy\
  shellies/shellyem3-123456789012/emeter/0/returned_energy:.* emeter_0_returned_energy\
  shellies/shellyem3-123456789012/emeter/0/total:.* emeter_0_total\
  shellies/shellyem3-123456789012/emeter/0/total:.* {'emeter_0_kWh' => sprintf("%.2f",$EVENT/1000)}\
  shellies/shellyem3-123456789012/emeter/0/total_returned:.* emeter_0_total_returned\
  shellies/shellyem3-123456789012/emeter/1/energy:.* emeter_1_energy\
  shellies/shellyem3-123456789012/emeter/1/returned_energy:.* emeter_1_returned_energy\
  shellies/shellyem3-123456789012/emeter/1/total:.* emeter_1_total\
  shellies/shellyem3-123456789012/emeter/1/total:.* {'emeter_1_kWh' => sprintf("%.2f",$EVENT/1000)}\
  shellies/shellyem3-123456789012/emeter/1/total_returned:.* emeter_1_total_returned\
  shellies/shellyem3-123456789012/emeter/2/energy:.* emeter_2_energy\
  shellies/shellyem3-123456789012/emeter/2/returned_energy:.* emeter_2_returned_energy\
  shellies/shellyem3-123456789012/emeter/2/total:.* emeter_2_total\
  shellies/shellyem3-123456789012/emeter/2/total:.* {'emeter_2_kWh' => sprintf("%.2f",$EVENT/1000)}\
  shellies/shellyem3-123456789012/emeter/2/total_returned:.* emeter_2_total_returned\
shellyem3_123456789012:shellies/shellyem3-123456789012/info:.* { json2nameValue($EVENT, 'info_', $JSONMAP) }
attr MQTT2_shellyem3_123456789012 room MQTT2_DEVICE
attr MQTT2_shellyem3_123456789012 setList relay0:on,off,toggle shellies/shellyem3-123456789012/relay/0/command $EVTPART1\
  off:noArg shellies/shellyem3-123456789012/relay/0/command off\
  on:noArg shellies/shellyem3-123456789012/relay/0/command on\
  x_update:noArg shellies/shellyem3-123456789012/command update_fw\
  x_mqttcom shellies/shellyem3-123456789012/command $EVTPART1
attr MQTT2_shellyem3_123456789012 stateFormat { my $light = ReadingsVal($name,"state","off");;;; my $cons1 = ReadingsVal($name,"emeter_0_power","unknown");;;; my $cons2 = ReadingsVal($name,"emeter_1_power","unknown");;;; my $cons3 = ReadingsVal($name,"emeter_2_power","unknown");;;; my $total1 = ReadingsVal($name,"emeter_0_kWh","unknown");;;; my $total2 = ReadingsVal($name,"emeter_1_kWh","unknown");;;; my $total3 = ReadingsVal($name,"emeter_2_kWh","unknown");;;; return qq(Relay: $light,<br>P1: $cons1 W / Total P1: $total1 kWh<br>P2: $cons2 W / Total P2: $total2 kWh<br>P3: $cons3 W / Total P3: $total3 kWh) }
attr MQTT2_shellyem3_123456789012 userReadings emeter_0_energy_total:emeter_0_energy:.* monotonic {ReadingsNum("$name","emeter_0_energy",0)}, emeter_1_energy_total:emeter_1_energy:.* monotonic {ReadingsNum("$name","emeter_1_energy",0)}, emeter_2_energy_total:emeter_2_energy:.* monotonic {ReadingsNum("$name","emeter_2_energy",0)}

setstate MQTT2_shellyem3_123456789012 Relay: off,<br>P1: 84.28 W / Total P1: 2.07 kWh<br>P2: 9.91 W / Total P2: 0.49 kWh<br>P3: 6.19 W / Total P3: 2.38 kWh
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:17 attrTemplateVersion 20200830_1
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:08 emeter_0_current 0.60
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:01 emeter_0_energy 85
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:01 emeter_0_energy_total 86
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:08 emeter_0_kWh 2.07
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:08 emeter_0_pf 0.60
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:08 emeter_0_power 84.28
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:01 emeter_0_returned_energy 0
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:08 emeter_0_total 2070.9
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:08 emeter_0_total_returned 0.0
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:08 emeter_0_voltage 233.59
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:09 emeter_1_current 0.08
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:01 emeter_1_energy 10
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:01 emeter_1_energy_total 10
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:09 emeter_1_kWh 0.49
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:09 emeter_1_pf 0.53
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:08 emeter_1_power 9.91
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:01 emeter_1_returned_energy 0
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:09 emeter_1_total 492.7
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:09 emeter_1_total_returned 0.0
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:09 emeter_1_voltage 235.20
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:09 emeter_2_current 0.08
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:01 emeter_2_energy 7
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:01 emeter_2_energy_total 8
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:09 emeter_2_kWh 2.38
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:09 emeter_2_pf 0.34
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:09 emeter_2_power 6.19
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:01 emeter_2_returned_energy 0
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:09 emeter_2_total 2380.6
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:09 emeter_2_total_returned 0.0
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:09 emeter_2_voltage 236.67
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 fw_ver 20200813-140420/v1.8.1@1b2a49be
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 id shellyem3-123456789012
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_actions_stats_skipped 0
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_cfg_changed_cnt 2
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_cloud_connected false
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_cloud_enabled false
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_1_current 0.60
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_1_is_valid true
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_1_pf 0.59
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_1_power 83.88
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_1_total 2062.5
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_1_total_returned 0.0
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_1_voltage 233.85
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_2_current 0.08
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_2_is_valid true
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_2_pf 0.55
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_2_power 10.43
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_2_total 491.8
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_2_total_returned 0.0
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_2_voltage 236.27
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_3_current 0.08
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_3_is_valid true
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_3_pf 0.35
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_3_power 6.51
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_3_total 2379.9
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_3_total_returned 0.0
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_emeters_3_voltage 237.29
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_fs_free 153863
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_fs_mounted true
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_fs_size 233681
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_has_update false
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_mac 123456789012
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_mqtt_connected true
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_ram_free 19696
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_ram_total 49432
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_relays_1_has_timer false
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_relays_1_is_valid true
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_relays_1_ison true
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_relays_1_overpower false
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_relays_1_source mqtt
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_relays_1_timer_duration 0
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_relays_1_timer_remaining 0
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_relays_1_timer_started 0
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_serial 1737
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_time 09:48
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_unixtime 1598867297
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_update_has_update false
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_update_new_version 20200813-140420/v1.8.1@1b2a49be
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_update_old_version 20200813-140420/v1.8.1@1b2a49be
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_update_status idle
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_uptime 70671
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_wifi_sta_connected true
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_wifi_sta_ip 192.168.178.69
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_wifi_sta_rssi -73
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 info_wifi_sta_ssid FRITZ!Box 7362 SL
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 ip 192.168.178.69
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 mac 123456789012
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 model SHEM-3
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 new_fw false
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:48:18 online true
setstate MQTT2_shellyem3_123456789012 2020-08-31 09:54:08 state off
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 31 August 2020, 10:24:23
Hmmm, wir sollten die Diskussion dann jetzt hier fortsetzen: https://forum.fhem.de/index.php/topic,111905.0.html (bitte ab jetzt da antworten, gerne für die anderen User dort mit einem Link nach hierhin).

webCmd : ist mMn. ok, das Problem ist evtl. eher, dass toggle via SetExtensions läuft. Ergänze bitte mal eine setStateList:attr MQTT2_shellyem3_123456789012 setStateList on off toggleDas mit der Gesamtsumme war (als Frage von meiner Seite, ob der Shelly das nicht liefern kann) schon Gegenstand in der anderen Diskussion; hier fehlt mMn. einfach die "gibt das auch aus"-Anweisung:
attr MQTT2_shellyem3_123456789012 devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");; my $cons1 = ReadingsVal($name,"emeter_0_power","unknown");; my $cons2 = ReadingsVal($name,"emeter_1_power","unknown");; my $cons3 = ReadingsVal($name,"emeter_2_power","unknown");; my $total1 = ReadingsVal($name,"emeter_0_kWh","unknown");; my $total2 = ReadingsVal($name,"emeter_1_kWh","unknown");; my $total3 = ReadingsVal($name,"emeter_2_kWh","unknown");; my $total_sum = $total1+$total2+$total3;; "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>P1: $cons1 W / Total P1: $total1 kWh<br>P2: $cons2 W / Total P2: $total2 kWh<br>P3: $cons3 W / Total P3: $total3 kWh<br>3 Phases total: $total_sum kWh</div>"}
(Die "returned"-Readings sind sicher auch was, was dort den einen oder anderen interessieren dürfte).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 01 September 2020, 09:44:51
Jetzt doch eine Rückmeldung vor dem Hintergund des 3em:

Beim shelly1pm (von dem kommt die setList des 3em) habe ich jetzt allg. das direkte toggle eingefügt, und noch an diversen Stellen ein paar doppelte ";;" entfernt.

Damit sollten sowohl der shelly1pm und der shelly 3em jetzt passen.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: ulli am 03 September 2020, 15:48:40
Ich hab mir den Powerplug BW-SHP13 von Blitzwolf besorgt und suche das richtige template.
Eigentlich müsste es folgendes sein zigbee2mqtt_smart+plug, nur leider lässt sich das nicht setzen.
--> Unknown template_entry_name zigbee2mqtt_smart+plug

Hat wer eine Idee wie ich den plug in fhem ans laufen  bekomme?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 03 September 2020, 16:18:56
Interessantes Device :) .

Wie kommst du drauf, dass es ein attrTemplate dieses Namens (noch) gibt? Was es gibt, sollte (samt Beschreibung) in der drop-down liste zu sehen sein, die Klartextsuche nach dem plug+ führt mich zu "zigbee2mqtt_plug".

Ansonsten wäre ein RAW-list in der Regel hilfreich, kann immer mal wieder auch sein, dass es an irgendwas anderem liegt (Filter oder prereq).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: ulli am 03 September 2020, 17:08:08
Sorry copypast Fehler ich rede vom template zigbee2mqtt_plug_w_energy_measuring
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 03 September 2020, 17:52:42
ah, ok; das ist ein interner Aufruf, um den es da geht. Versuch's mal mit dem genannten plug-template, bei Gelegenheit kommt dann ein update.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: ulli am 03 September 2020, 20:18:16
Ich hab mal selbst angefangen zu basteln.
Meine definition sieht nun so aus
defmod MQTT2_zigbee_0x842e14fffe13939c MQTT2_DEVICE zigbee_0x842e14fffe13939c
attr MQTT2_zigbee_0x842e14fffe13939c IODev MQTT
attr MQTT2_zigbee_0x842e14fffe13939c devStateIcon {my $current = ReadingsVal($name,"current",0);;;; my $pwr = ReadingsVal($name,"power",0);;;; my $energy = ReadingsVal($name,"energy",0);;;;"<div> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($state)."</a> Aktuell: $current A  Leistung.: $pwr W<b></b>"}
attr MQTT2_zigbee_0x842e14fffe13939c devicetopic zigbee2mqtt/0x842e14fffe13939c
attr MQTT2_zigbee_0x842e14fffe13939c eventMap { dev=>{ON=>'on',OFF=>'off'} }
attr MQTT2_zigbee_0x842e14fffe13939c icon message_socket
attr MQTT2_zigbee_0x842e14fffe13939c readingList $DEVICETOPIC:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_0x842e14fffe13939c setList on:noArg $DEVICETOPIC/set {"state":"ON"}\
  off:noArg $DEVICETOPIC/set {"state":"OFF"}\
attr MQTT2_zigbee_0x842e14fffe13939c setStateList on off

Was hältst du davon? ggf. könnte man damit das besagte Template fertig stellen?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 03 September 2020, 21:53:12
Danke, das hilft deutlich weiter.

Habe eben mal ein update ins svn geschoben, der das mit kleinen Änderungen so übernimmt und einen direkten toggle-Command einführt, wäre klasse, wenn du das testen würdest.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: ulli am 04 September 2020, 09:15:24
Welches template hast jetzt angpasst?
Das zigbee2mqtt_plug_w_energy_measuring verhält sich wie vorher.

Update
Es braucht einen fhem Neustart das die templates da sind.
Leider funktioniert das template nicht mehr
Wenn ich auf on schalte zeigt er die Glühbirne mit Rufzeichen an und im state steht set_on anstatt on. (Scheinbar wird das vom Attribute setstatelist verursacht)
Auch die Steckdose schaltete jetzt nicht mehr
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 04 September 2020, 09:29:30
Ändere mal bitte die eventMap (oder lösche das einfach mal testweise, evtl. funktioniert das zwischenzeitlich auch so):attr DEVICE eventMap { dev=>{'ON'=>'on','OFF'=>'off'} }Wenn die Lampe nicht schaltet, ist "set_xy" vermutlich richtig, das ist ein Übergangszustand bis die Rückmeldung der Leuchte kommt (oder ein Fehler bei der Auswertung, falls sie angeht). Also ist entweder der publish kaputt oder der Dienst nicht verfügbar.

Zeig mal bitte ein RAW, wie das jetzt aussieht, falls klar ist, dass der Dienst an sich funktioniert (z.B. über das Bridge-Device die device-Liste anfordern).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: ulli am 04 September 2020, 09:34:49
Ne funktioniert  nicht. Auch wenn ich eventmap lösche
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: ulli am 04 September 2020, 09:40:17
Problem gefunden.
Bei der Übernahme des templates schneidet er das letzte Zeichen desdevicetopics weg. Damit ist die id nicht mehr richtig.
Jetzt geht's wenn man das händisch wieder korrigiert.

Der übergangszustand mit der birne mit Rufezeichen ist unschön. Kann man das ändern oder ist das bei allen Mqtt Devices so gelöst?
Schön wäre es noch wenn er das toggle Kommando in der weboberflache anbietet neben on und off
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 04 September 2020, 10:24:32
Oha, das mit dem Abschneiden des letzten Zeichens, wenn ein $DEVICETOPIC bereits vergeben war ist unschön! (wundert mich, dass sich bisher noch keiner darüber beschwert hatte, ist bei allen zigbee2mqtt-templates ein Thema...).
Fixe ich bei Gelegenheit.

Was den Übergangszustand angeht: Das ist (auch) eine Folge von setStateList und beabsichtigt. Ergo: Du kannst das Löschen, wenn du willst, aber es ist ein mMn. gutes feature, weil man so erkennen kann, ob ein Kommunikationsproblem besteht, und: Die "anderen Readings" werden dann auch korrekt gesetzt, falls es mehr einstellbare Elemente am Zieldevice gibt. Sonst geht z.B. ein brightness-command auch auf state ;) .
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 04 September 2020, 11:27:32
Es braucht einen fhem Neustart das die templates da sind.
Es geht auch leichter :)
Nach dem Update von FHEM
{ AttrTemplate_Initialize() }Oder nur Update der Templates:
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }Gruß Otto
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 04 September 2020, 15:05:12
Oder nur Update der Templates:
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }
:) Jetzt wäre dann demnächst (hoffentlich) ein guter Zeitpunkt, das zu tun...
(Da waren auch noch in den zweikanaligen ZigBee-split noch ein paar andere Kleinigkeiten).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: 87insane am 25 September 2020, 18:34:30
Hey - bin auch mal wieder im Leben angekommen...

für die ganz faulen auch "MQTT Template reload,cmd={ AttrTemplate_Initialize() }" als Menü Eintrag im Web Device.

Könnte zb so aussehen:
menuEntries: FHEM Update,cmd=update,MQTT Template reload,cmd={ AttrTemplate_Initialize() },FHEM neu starten,cmd=shutdown restartAlso ein klickbarer Button.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: grappa24 am 11 Oktober 2020, 10:22:10
Eine Frage zu den Shelly templates bzgl. devStateIcon:

Ich versuche nachzuvollziehen, wie die grün/gelb/roten Punkte zum eigentlichen Icon "dazugemischt" werden.

{my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen"; my $light = ReadingsVal($name,"state","off"); my $show = '<a href="';$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">'; $show .= FW_makeImage("10px-kreis-".$onl)."</a>"; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a></div>" }
Wenn ich das richtig verstehe verbirgt sich das Icon hinter der Variablen $light, die entweder on/off ist und die dafür sorgt, dass das Icon "Glühbirne" angezogen wird.

Geht das auch mit anderen Icons als mit den standardmäßigen FS20.on/FS20.off Glühbirnen? Sprich, ich möchte die Status-Punkte zu eigenen/anderen Icons kombinieren ... ?

Schöne Aufgabe für einen verregneten Sonntag  ;)
grappa24
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 11 Oktober 2020, 13:53:23
Hi,

hier scheint die Sonne  8)

Du suchst ja den Punkt, der steckt hier FW_makeImage("10px-kreis-".$onl)
Wenn $light nur on oder off enthält wird das default Icon genommen - die Birne. FW_makeImage($light)
Wenn Du die analog zu dem Kreis mit einem Namen des Icons füllst wird dieses angezeigt.

Zumindest versteh ich den Code so ;) muss nicht unbedingt stimmen.

Aber eine konkrete Frage dazu solltest Du eventuell neu beginnen, da es hier eher um die vorhandenen Templates geht :)

Gruß Otto
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 11 Oktober 2020, 14:08:28
Passt schon mit der Frage, und das Verhalten ist auch nicht Shelly-spezifisch...

Die FS20-Birne ist übrigens nicht immer das default-Icon für on/off, das hängt u.A. am verwendeten FHEMWEB-Style und/oder dem defaultIcon-Attribut der FHEMWEB-Instanz.

Vermutlich bist du besser beraten, entweder den Style auf f18 umzustellen (da sind es die durchscheinenden "Strahlebirnchen" wie im angehängten Bild), oder eben das Attribut anzupassen.

Wenn du es nur lokal ändern willst: der ursprüngliche Vorschlag von 87insane (?) sah eine "Pendelleuchte" vor, die je nach Status eine unterschiedliche Farbe hatte. Da (müßte in dem Shelly-template-Thread sein) findest du dann auch andere Varianten, was an FW_makeImage() übergeben werden kann ;) ).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: grappa24 am 11 Oktober 2020, 15:16:54
Danke, da kann ich ansetzen.

Style-Änderung nützt mir nichts in diesem Fall, da mein Shelly ein Garagentor steuert und ich die beiden anliegenden Icons verwende. Werde es mal mit FW_makeImage() versuchen einzubauen. Sehe nur noch nicht, wie ich die beiden Zustände hineinbekomme ....  :-\
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 11 Oktober 2020, 15:33:18
Ausgehend davon, dass es  im Moment so aussieht:
attr DEVICE devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen"; my $light = ReadingsVal($name,"state","off"); my $show = '<a href="';$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">'; $show .= FW_makeImage("10px-kreis-".$onl)."</a>"; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a></div>" }'
Wäre dann (nur) der $light-Teil vermutlich so zu ändern:
my $light = ReadingsVal($name,"state","off") eq "off" ? "garage_up_down" : "garage_up_down_working";
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: grappa24 am 11 Oktober 2020, 15:39:29
blöd, jetzt kann ich mir schon wieder ein neues Projekt suchen  ;D
Danke!

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Heimweh am 20 November 2020, 11:27:30
Ich habe einen SONOFF4CH den ich mit Tasmota geflasht habe. Die 4 Kanäle sind als einzelne Devices angelegt worden.
Ein Template habe ich hier nicht verwendet (wenn ich mich recht erinnere) - ich kann auch keines setzen, set attrTemplate wird hier gar nicht angeboten, sowie das
bei meinen zahlreichen S20 SONOFFs der Fall ist. Aufgefallen ist mir das weil ich nach dem Wikieintrag "Praxisbeispiele" MQTT2 gerne ein on-for-timer über Pulsetime in der setList hinzufügen wollte.
Muss ich das in meinem Fall über eventMap "nachrüsten"?
Meine zweite Frage ist, wieso hab ich das Atribut setList gar nicht zur Auswahl habe...

Hier mal ein list des SONOFF4CH Kanals

Internals:
   DEF        192.168.178.71 80 espBridge SONOFF4CH_Relais1
   ESP_BUILD  148
   ESP_SLEEP  0
   ESP_UNIT   0
   ESP_VERSION 9
   FUUID      5d74fb5a-f33f-55ed-389d-24ac42ad68a73820
   HOST       192.168.178.71
   IDENT      SONOFF4CH_Relais1
   INTERVAL   300
   IODev      espBridge
   LASTInputDev espBridge
   MAX_CMD_DURATION 1
   MSGCNT     12092
   NAME       ESPEasy_SONOFF4CH_Relais1
   NOTIFYDEV  global
   NR         1097
   NTFY_ORDER 50-ESPEasy_SONOFF4CH_Relais1
   PORT       80
   STATE      off
   SUBTYPE    device
   TYPE       ESPEasy
   VERSION    2.18
   espBridge_MSGCNT 12092
   espBridge_TIME 2020-11-20 11:26:21
   READINGS:
     2020-11-20 11:26:21   Relais          off
     2020-11-20 11:23:34   presence        present
     2020-11-20 11:26:21   state           Rel: off
   helper:
     fpc        1605262409
     mapLightCmds:
     pm:
       Encode     1
       JSON       1
     received:
       Relais     1605867981
   sec:
     admpwd     
Attributes:
   IODev      espBridge
   Interval   300
   alias      Strang 1 - EG Badezimmer
   devStateIcon on:rc_GREEN:off off:rc_RED:on absent:rc_BLUE:off gpio:rc_YELLOW:off
   eventMap   /gpio 12 on:on/gpio 12 off:off/gpio 12 gpio:off/gpio 12 output:off/
   group      Heizung
   icon       sani_heating_manual
   presenceCheck 1
   readingSwitchText 1
   room       EG_Temperaturen,Heizungskeller
   setState   3
   stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"Relais","")}
   userattr   Straenge_EG Straenge_EG_map structexclude
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 20 November 2020, 11:32:24
@Heimweh Du bist im falschen Board? Hier geht es um mqtt2, Du machst ESPEasy ... ::)
Zitat
  TYPE       ESPEasy
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Heimweh am 20 November 2020, 11:33:40
@Heimweh Du bist im falschen Board? Hier geht es um mqtt2, Du machst ESPEasy ... ::)

 :o da ist was durcheinander gekommen. SORRY
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Snocksman am 06 Dezember 2020, 17:22:47
Hallo zusammen,

ich habe mir mal ein paar Zigbee Devices besorgt und diese bislang auch Problemlos angebunden bekommen... Danke hier schonmal für die Templates ! Nun habe ich mir einen Heizkörperthermostat vorgenommen; Hier mal ein link zu dem Teil: https://de.aliexpress.com/item/4001050739921.html?spm=a2g0s.9042311.0.0.54624c4dCtUJKR (https://de.aliexpress.com/item/4001050739921.html?spm=a2g0s.9042311.0.0.54624c4dCtUJKR)
Angelernt wurde das Teil und FHEM bekommt auch Daten, aber wenn ich das richtig sehe, gibt es für Zigbee Heizkörperthermostate noch kein Template ? Wäre cool, wenn das jemand ergänzen könnte.

Hier einmal die RAW-definition:
defmod MQTT2_zigbee_0xbc33acfffe45850a MQTT2_DEVICE zigbee_0xbc33acfffe45850a
attr MQTT2_zigbee_0xbc33acfffe45850a IODev MQTT2_FHEM_Server
attr MQTT2_zigbee_0xbc33acfffe45850a readingList zigbee2mqtt/0xbc33acfffe45850a:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_0xbc33acfffe45850a room MQTT2_DEVICE

setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 13:02:38 associatedWith MQTT2_zigbee_bridge
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 auto_lock MANUAL
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 away_mode OFF
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 away_preset_days 1
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 away_preset_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 boost_time 300
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 child_lock UNLOCKED
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 comfort_temperature 20
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 current_heating_setpoint 27.5
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 eco_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 force normal
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_1_hour 6
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_1_minute 0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_1_temperature 20
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_2_hour 8
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_2_minute 0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_2_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_3_hour 11
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_3_minute 30
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_3_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_4_hour 12
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_4_minute 30
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_4_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_5_hour 17
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_5_minute 30
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_5_temperature 20
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_6_hour 22
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_6_minute 0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_6_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 16:53:12 linkquality 99
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 local_temperature 22.0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 local_temperature_calibration -1.0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 max_temperature 35
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 min_temperature 5
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 position 100
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 preset manual
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 system_mode manual
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 week 5+2
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 window_detection OFF
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 window_detection_params_minutes 10
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 window_detection_params_temperature 5
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_1_hour 6
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_1_minute 0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_1_temperature 20
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_2_hour 8
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_2_minute 0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_2_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_3_hour 11
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_3_minute 30
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_3_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_4_hour 12
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_4_minute 30
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_4_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_5_hour 17
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_5_minute 30
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_5_temperature 20
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_6_hour 22
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_6_minute 0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_6_temperature 15
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 06 Dezember 2020, 17:55:43
Uiuiuiuiui...

Das wird vermutlich kompliziert, kannst du dafür ein neues Topic aufmachen und mal RAW-JSON-Daten loggen?
Vorab empfehle ich die Lektüre der Threads zu den beiden Spirit-attrTemplates (zigbee2mqtt_eurotronic_spirit => https://forum.fhem.de/index.php/topic,114994.0.html und tasmota_zigbee2tasmota_eurotronic_spirit => https://forum.fhem.de/index.php/topic,116094.0.html).
Der letztere ist etwas mehr straight-forward, der erstere ist zigbee2mqtt-bezogen und das attrTemplate vermutlich die geschicktere Ausgangsbasis)....

Es wird aber definitiv nicht einfach "jemand" machen können, sondern aktives Mitarbeiten erforderlich sein, und für Temperaturlisten (das Teil scheint sowas zu können) etc. braucht es vermutlich myUtils-Code.

Bein blakadder scheint das die richtige Page (https://zigbee.blakadder.com/Moes_HY369-ZB-RVT.html) zu sein, auch wenn der Link bei zigbee2mqtt dann ein ganz anderes Teil zeigt...?!?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: dcboy am 06 Dezember 2020, 18:45:36
Hallo zusammen,

ich habe mir mal ein paar Zigbee Devices besorgt und diese bislang auch Problemlos angebunden bekommen... Danke hier schonmal für die Templates ! Nun habe ich mir einen Heizkörperthermostat vorgenommen; Hier mal ein link zu dem Teil: https://de.aliexpress.com/item/4001050739921.html?spm=a2g0s.9042311.0.0.54624c4dCtUJKR (https://de.aliexpress.com/item/4001050739921.html?spm=a2g0s.9042311.0.0.54624c4dCtUJKR)
Angelernt wurde das Teil und FHEM bekommt auch Daten, aber wenn ich das richtig sehe, gibt es für Zigbee Heizkörperthermostate noch kein Template ? Wäre cool, wenn das jemand ergänzen könnte.

Hier einmal die RAW-definition:
defmod MQTT2_zigbee_0xbc33acfffe45850a MQTT2_DEVICE zigbee_0xbc33acfffe45850a
attr MQTT2_zigbee_0xbc33acfffe45850a IODev MQTT2_FHEM_Server
attr MQTT2_zigbee_0xbc33acfffe45850a readingList zigbee2mqtt/0xbc33acfffe45850a:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_0xbc33acfffe45850a room MQTT2_DEVICE

setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 13:02:38 associatedWith MQTT2_zigbee_bridge
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 auto_lock MANUAL
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 away_mode OFF
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 away_preset_days 1
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 away_preset_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 boost_time 300
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 child_lock UNLOCKED
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 comfort_temperature 20
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 current_heating_setpoint 27.5
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 eco_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 force normal
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_1_hour 6
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_1_minute 0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_1_temperature 20
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_2_hour 8
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_2_minute 0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_2_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_3_hour 11
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_3_minute 30
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_3_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_4_hour 12
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_4_minute 30
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_4_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_5_hour 17
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_5_minute 30
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_5_temperature 20
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_6_hour 22
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_6_minute 0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 holidays_6_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 16:53:12 linkquality 99
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 local_temperature 22.0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 local_temperature_calibration -1.0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 max_temperature 35
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 min_temperature 5
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 position 100
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 preset manual
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 system_mode manual
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 week 5+2
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 window_detection OFF
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 window_detection_params_minutes 10
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 window_detection_params_temperature 5
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_1_hour 6
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_1_minute 0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_1_temperature 20
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_2_hour 8
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_2_minute 0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_2_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_3_hour 11
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_3_minute 30
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_3_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_4_hour 12
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_4_minute 30
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_4_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_5_hour 17
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_5_minute 30
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_5_temperature 20
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_6_hour 22
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_6_minute 0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-06 17:06:24 workdays_6_temperature 15

Da hatten wir wohl heute beide den gleichen Gedanke, ich habe mir auch am Singles Day Thermostate bestellt und heute festgestellt, dass es bisher noch kein Template dafür gibt. Meine sind jedoch diese hier:
https://zigbee.blakadder.com/Moes_HY368-ZB.html
https://de.aliexpress.com/item/4001065031604.html

Das angelegte Device liefert aber bei mir so ziemlich die gleichen Daten:

defmod MQTT2_zigbee_0x842e14fffee56f43 MQTT2_DEVICE zigbee_0x842e14fffee56f43
attr MQTT2_zigbee_0x842e14fffee56f43 IODev MQTT2_FHEM_Server
attr MQTT2_zigbee_0x842e14fffee56f43 readingList zigbee2mqtt/0x842e14fffee56f43:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_0x842e14fffee56f43 room MQTT2_DEVICE

setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 associatedWith MQTT2_zigbee_bridge
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 auto_lock MANUAL
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 away_mode OFF
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 away_preset_days 1
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 away_preset_temperature 15
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 battery_low false
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 boost_time 300
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 child_lock UNLOCKED
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 comfort_temperature 20
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 current_heating_setpoint 20
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 eco_temperature 15
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 force normal
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_1_hour 6
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_1_minute 0
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_1_temperature 20
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_2_hour 8
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_2_minute 0
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_2_temperature 15
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_3_hour 11
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_3_minute 30
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_3_temperature 15
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_4_hour 12
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_4_minute 30
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_4_temperature 15
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_5_hour 145
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_5_minute 30
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_5_temperature 20
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_6_hour 22
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_6_minute 0
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 holidays_6_temperature 15
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 local_temperature 19.5
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 local_temperature_calibration -1
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 max_temperature 35
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 min_temperature 5
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 position 25
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 preset schedule
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 system_mode auto
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 week 5+2
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 window_detection OFF
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 window_detection_params_minutes 10
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 window_detection_params_temperature 5
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_1_hour 6
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_1_minute 0
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_1_temperature 20
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_2_hour 8
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_2_minute 0
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_2_temperature 15
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_3_hour 11
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_3_minute 30
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_3_temperature 15
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_4_hour 12
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_4_minute 30
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_4_temperature 15
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_5_hour 17
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_5_minute 30
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_5_temperature 20
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_6_hour 22
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_6_minute 0
setstate MQTT2_zigbee_0x842e14fffee56f43 2020-12-06 18:30:42 workdays_6_temperature 15

Wenn ich was testen oder Daten liefern soll, gerne. Bin allerdings nicht so ganz tief drin bei FHEM, lese mich da aber gerne mit Unterstützung ein!
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 07 Dezember 2020, 12:43:55
Hallo Jörg,

das Template owntracks_device
Ich denke da gibt es Fehler:
Die getList will immer im Reading raw überprüfen ob was zurückkam. Keiner legt aber dieses Reading an? Wobei die Frage noch ist wie man es richtig macht?
owntracks/TRACKER_ID/DEV_ID.* raw
da geht auch jeder Befehl sofort in dieses Reading.

Die setList
Für alle: es fehlt doch eine Eingabemöglichkeit? :textField
waypoints
waypoints owntracks/TRACKER_ID/DEV_ID/cmd {"_type":"cmd","action":"setWaypoints","waypoints":{"_type":"waypoints","waypoints":$EVTPART1}\
Da fehlt mindestens eine } Klammer am Ende, dann müsste man [{wp1},{wp2},{wp3}] - also mit den [] einwerfen. Ich würde die auch noch in den Befehl packen:
waypoints:textField owntracks/TRACKER_ID/DEV_ID/cmd {"_type":"cmd","action":"setWaypoints","waypoints":{"_type":"waypoints","waypoints":[$EVTPART1]}}\

Die Frage ist noch: gerade hier - wie sag ich dem User eigentlich sollen solche setter verwendet werden? Der Syntax ist ja nicht ableitbar, man muss ins Handbuch schauen!

Ein Schönheitsproblem: damit entstehen Readings der Form waypoints_waypoints_x - sollte man so anbieten? Was bringt das außer eine volle Readingliste?
owntracks/TRACKER_ID/DEV_ID/waypoints:.* { json2nameValue($EVENT,'waypoints_',$JSONMAP) }

Die jsonMap verstehe ich in weiten Bereichen gar nicht, aber ich habe Android und da fehlen einige Readings/Bereiche sowieso, die Frage wäre ein Template für Android und ein Template für Apfel? Für Android könnte ich vorschlagen - noch Ideen zur Strukturierung?

generell: Im Template gleich das attr devicetopic anlegen und konsequent im Code verwenden?

Gruß Otto
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 07 Dezember 2020, 13:16:01
Hmm, also: das owntracks-Ding habe ich einfach so übernommen, (leider scheint der Link falsch zu sein, woher...) EDIT: das wäre richtig: https://forum.fhem.de/index.php/topic,99666.msg1019884.html#msg1019884
Das mit den waypoints-Klammern ziehe ich nach.

Das mit der User-Info ist in der Tat hier und an ein paar anderen Stellen nicht so einfach, und grade bei komplexeren Dingen (die ich zu einem nicht unerheblichen Teil auch nie selbst genutzt oder (funktional) ausgetestet habe), gibt's vermutlich nicht DEN Königsweg.
MAn. könnte das in diesem speziellen Fall mit einem Handbuch-Link via comment gelöst werden, weil auch das Zusammenspiel mit dem owntracks-Modul erklärungsbedürftig sein dürfte.

Das Thema mit der Doku war einer der Gründe, warum ich zuletzt etwas darauf gedrängt habe, dass bestimmte Teile der MQTT2_DEVICE-Familie eigene Wiki-Artikel bekommen; dann kann das jeweils leichter von den Nutzern dieser Geräte-(Gruppe) ergänzt oder verbessert werden. Sollte man z.B. auch bei OpenMQTTGateway bei Gelegenheit mal machen (in https://wiki.fhem.de/wiki/MQTT#OpenMQTTGateway (https://wiki.fhem.de/wiki/MQTT#OpenMQTTGateway) hat mal irgendjemand was ziemlich halblebiges eingefügt; das auszuweiten etc. hat aber für mich selbst im Moment auch nicht die hohe Prio, aber evtl. findet sich ja jemand (?)).

Zu Owntracks speziell würde ich vorschlagen, die Diskussion auszulagern, entweder in den Thread, in dem Loredo (?) das gepostet hatte, oder eben in einen Neuen (wäre für letzteres).


@dcboy und Snocksman:
Wie gesagt: vermutlich ist das ganze bis zu einem gewissen Grad machbar, aber bitte auch das als separates Thema und mit etwas mehr Info über den "rohen" MQTT-Verkehr, damit wir wenigstens die "basics" hingebogen bekommen...
Das bei blakadder/https://www.zigbee2mqtt.io/devices/TS0601_thermostat.html liest sich aber so, als wäre das mit dem "Spirit"-attrTemplate schon in der Basis regelbar? (Das ist aber auch noch teils ungetestet, weil der User, der die Rohdaten geliefert hatte sich nicht überzeugen hat lassen, dass desired-temp und measured-temp "gute" Reading-Namen wären...)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Snocksman am 07 Dezember 2020, 17:24:22
Habe gerade einen separaten Thread für die Thermostate aufgemacht: https://forum.fhem.de/index.php/topic,116535.0.html (https://forum.fhem.de/index.php/topic,116535.0.html)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 07 Dezember 2020, 20:34:22
So, habe eben mal ein update dazu ins svn geschoben, da ist drin:
- OMG - kleinere Änderungen betr. v.a. das gtag-BT-Dongle. Hoffe mal, da fühlt sich jemand wg. Doku angesprochen...
- owntracks - Klammern und $DEVICETOPIC (hoffentlich; ungetestet)
- ein erster stub für diese Thermostat-Geschichte (da ist aber nur das drin, was ich in dem anderen Thread angedeutet hatte, muss nicht funktionieren, nur, dass man mal eine gemeinsame Basis hat...)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 08 Dezember 2020, 00:47:55
Das owntracks-device sieht komisch aus ($\DEVICETOPIC), aber lass mal ich teste das morgen mal durch und liefere einen Vorschlag.

Die bridgeRegexp  CLIENT_general_bridge habe ich mal sortiert, normiert und zusammen gefasst. Schau Dir das mal an - aber vielleicht lieg ich völlig daneben:
(tele|stat|shellies|valetudo|Advantech)/([^/]+)/.*:.* "$2"
  (zigbee2mqtt)/bridge/.*:.* "$1"
  (ESPClient_[^/]+)/.*:.* "$1"
  (ebusd)/global/.*:.* "$1"
  [^/]+/(ems-esp[^/]+)/start:.* "$1"
  (sonos)/connected.* "$1"
  (tvheadend)[/][^/:]+.* "$1"
  (mygateway[\d]+)-(in|out)/.* "$1"
  (milight)/LWT:.* "$1"
  (wallpanel|wled)/([^/]+)/.*:.* "$1_$2"
  (go-eCharger)/([^/]+)/.*:.* "go_eCharger_$2"
  (owntracks)/([^/]+)/([^/]+).*:.* "$1_$2$3"
  (home)/(O[^/]*M[^/]*G[^/]*)/LWT:.* "$2"
  homeassistant/.*/config:.* ""
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 08 Dezember 2020, 07:18:37
Der backslash sieht in der Tat komisch aus, ist aber erforderlich, um die Ersetzung für DEVICE zu verhindern ;) .

CLIENT_general_bridge ist "aufgeräumt", bei der Gelegenheit habe ich dann gleich nochmal weiter vereinfacht bzw. Teile dann auch in "Klartext" notiert, ist vielleicht einfacher zu lesen bzw. zu verstehen?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 08 Dezember 2020, 09:53:39
CLIENT_general_bridge sieht gut aus. Ich bin ja gestern erstmal den anderen Weg gegangen -> alles in match groups, dann sortiert. Dabei habe ich gesehen wie viel da gleich ist und habe zusammengefasst.
Aber Du hast recht, so ist es besser lesbar und man sieht eher was eigentlich passiert. Muss man in Zukunft schauen wo man neues "einsortiert"
Ich denke die Muster sind jetzt konsistent und man kann anhand derer auch schnell was Neues einbauen.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 08 Dezember 2020, 10:08:44
Das mit dem Zusammenfassen war eine gute Idee!

Am Anfang habe ich halt schlicht mal gesammelt und das ganze - mangels eigener Nutzung und fehlender Rückmeldung von anderen - halt einfach "irgendwie" vertemplatet, ohne neben der reinen Funktionalität groß andere Aspekte zu beachten. Da war auch noch nicht so recht klar, dass das Prinzip "ändere (also user) nichts an der Topic-Struktur" als Standard in FHEM gelten kann/wird, aber der Fisch ist wohl zwischenzeitlich in diese Richtung geputzt.

Da zwischenzeitlich genug User da sind, die wissen, wie bridgeRegexp funktioniert (und wo es wie hilft), kann es m.E. zusammengefaßt bleiben, wer es anders haben will, findet dann vermutlich einen kundigen Helfer, der dann eine passende Einzelzeile beisteuern kann...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 08 Dezember 2020, 10:44:23
Ich poste Dir mal hier einen patch weil owntracks_device aus meiner Sicht wirklich derzeit buggy ist
Die Erkennung der Tracker und Device ID ging bei mir nicht und war mM nach auch  wirklich falsch - die regExe geändert und so geprüft - vielleicht habe ich noch nicht alle Varianten bedacht
Das raw Reading eingefügt, wobei ich mit der Lösung final nicht glücklich bin
Das textField bei den settern ergänzt, sonst mach es mM nach keinen Sinn
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 08 Dezember 2020, 11:53:39
Danke. Macht m.E. Sinn - genauso, wie die JSON für die Waypoints zu erhalten...
Vielleicht kannst du dazu noch Code liefern, Rudi hatte das ja sehr kompakt gefasst? (Evtl. sollte man aber die alten Readings vorneweg löschen?)

(Diskussion kann aber gerne in dem anderen Thread geführt werden; ich werde den Tag über mal wieder einsammeln, was mir so vor die Flinte läuft...
Z.B. in OMG habe ich eben auch noch "geschraubt", und bin mir auch nicht mehr so sicher, ob es nicht einfacher wäre, via RADIO-option abzufragen, ob der ESP BT kann und dann setList und readingList "je nachdem" zu verändern....
Vielleicht magst du dich in die Diskussion mit einklinken? => [Gelöst] OpenMQTTGateway + Gigaset Keeper, letzte MAC abfragen )
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 08 Dezember 2020, 12:01:13
Also nur ganz kurz:
Ich mache für owntracks zwei neue Template Vorschläge mit meinen neuen Erkenntnissen :)
owntracks_device - da will ich nur "Android/Basis-Umfang" reinpacken. Die Android Version hat viel weniger Umfang/Readings/Features
owntracks_device_IOS - als "AddOn" da kann ich erstmal nur den existierenden Umfang theoretisch betrachtet dazu packen. Das muss dann ein Apfel testen
Das mach ich aber im anderen Thread   ;) und OMG häng ich mich noch mit rein - mal sehen was ich da kann
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 10 Dezember 2020, 18:00:42
Schau Dir das mal an - aber vielleicht lieg ich völlig daneben:
Zumindest für das owntracks regExp lag ich daneben  :-[
owntracks/([^/]+)/([^/:]+).*:.* "owntracks_$2"wichtig ist [^/:] sonst sehen die erzeugten Geräte gruselig aus. Ich glaube bei den anderen "Kürzungen" war das ok soweit ich das beurteilen kann.
Ich wäre auch dafür, den Namen der Geräte nicht zu kompliziert zu machen. Es reicht doch wenn da owntracks_Meingerät steht. Wozu ist der Zwischenteil gut?
Dann könnte man auch so schreiben
owntracks/[^/]+/([^/:]+).* "owntracks_$1"
Beim owntrack_device Template ist gewaltig was schief gegangen. Es ist patch Text im Template :( und ich hatte Fehler im regExp der DeviceID
Ist es kontraproduktiv wenn ich einen patch liefere? Soll es lieber einfach der template Abschnitt sein?
###############
#OwnTracks
# an OwnTracks device
#contributed by Loredo
#source post: https://forum.fhem.de/index.php/topic,99666.msg1019884.html#msg1019884
# modified by Otto123
name:owntracks_device
desc:A device tracked by OwnTracks, Basics supported for Android
filter:TYPE=MQTT2_DEVICE:FILTER=CID~owntracks.*
order:O_01
par:TRACKER_ID;TrackerID;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,/([^/]+)/, ? $1 : undef }
par:DEV_ID;DeviceID;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,/[^/]+/([^/:]+), ? $1 : undef }
par:WHICHROOM;Actual room of the device, defaults to OwnTracks; {AttrVal("DEVICE","room","OwnTracks" )}
attr DEVICE room WHICHROOM
attr DEVICE icon location_sign
attr DEVICE devicetopic owntracks/TRACKER_ID/DEV_ID
attr DEVICE jsonMap\
  acc:accuracy alt:altitude batt:batteryPercent lat:latitude lon:longitude vac:accuracyVertical vel:velocity
attr DEVICE readingList\
  $\DEVICETOPIC.* raw\
  $\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  $\DEVICETOPIC/event:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  $\DEVICETOPIC/waypoints:.* { my (%h,$cnt); $EVENT=~ s/(\{[^[]*?})/$h{"waypoint_".++$cnt}=$1/ge; \%h }
attr DEVICE getList\
  location:noArg raw $\DEVICETOPIC/cmd {"_type":"cmd","action":"reportLocation"}\
  waypoints:noArg raw $\DEVICETOPIC/cmd {"_type":"cmd","action":"waypoints"}
attr DEVICE setList\
  config:textField $\DEVICETOPIC/cmd {"_type":"cmd","action":"setConfiguration","configuration":$EVTPART1}\
  waypoints:textField $\DEVICETOPIC/cmd {"_type":"cmd","action":"setWaypoints","waypoints":{"_type":"waypoints","waypoints":[$EVTPART1]}}\
  mode:1Quite,2Manual,3Significant,4Move {$EVTPART1=~/(\d)/;my $pl=$1-2;fhem("set $NAME config ".qq({"_type":"configuration","monitoring":$pl}));return undef}\
  x_raw_payload:textField { my $payload = $EVENT;$payload =~ s/$EVTPART0 //; qq($\DEVICETOPIC/cmd $payload)}
attr DEVICE userReadings\
  location:lat.* {ReadingsNum($name,'latitude',0).','.ReadingsNum($name,'longitude',0)},\
  connection:conn.* {my %h=(m=>'mobil',w=>'wifi',o=>'offline'); return $h{ReadingsVal('MQTT2_owntracks_mi6','conn','error')}},\
  place:event.* {ReadingsVal($name,'event','') eq 'leave'?'away':(ReadingsVal($name,'desc','nowhere'))}
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE model owntracks_device
attr DEVICE comment https://owntracks.org/booklet/tech/json/
setreading DEVICE attrTemplateVersion 20201210
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 10 Dezember 2020, 18:06:01
Das mit patches ist an sich schon ok, ich hatte das aber manuell eingepflegt, weil ich zeitgleich ein paar andere Änderungen hatte.

Aber kompletter Code ist auch völlig ok, wenn ich den Bezugspunkt identifizieren kann, ich sehe dann ja vor dem Einchecken, was Sache ist... ( ::) jedenfalls, wenn ich nicht zu viel gleichzeitig schraube).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 10 Dezember 2020, 18:09:16
Ok,
Blöd jetzt von mir, ich habe hier jetzt nicht nur die Fehler sondern gleich das komplett überarbeitete Template gepostet. Wollte ich eigentlich im anderen Thread machen  8)
Titel: tasmota_2ch_shutter_invert_1 Please define Interlock first
Beitrag von: betonkelle am 18 Dezember 2020, 23:42:40
Hallo zusammen,

ich habe einen Shelly 2.5 mit Tasmota 8.5.1 geflashed.
Im Fhem läuft MQTT2.
Wenn ich den Shelly mit dem MQTT2 Server verbinde, wird das device gefunden.
Wenn ich dann das Template
tasmota_2ch_shutter_invert_0
auswähle bekomme uch die Fehlermeldung
"Please define Interlock first", zweimal.
Dann drücke ich es mit Ok weg.
Das Device heißt dann komischerweise
Interlock DVES_.......
Wenn ich dann nochmal auf das Attr gehe will er undefjnierte Parameter füllen die fhem nicht genauer spezifiziert.

Bei dem Invert_1 Template gibt es die Probleme nicht, nur stellt Alexa dann das Rollo verkehrt herum.

Hat jemand eine Idee woran die Fehlermeldung liegt?
Danke
Martin


Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 19 Dezember 2020, 06:44:51
Vermutlich habe ich bei der jüngsten Umstellung (für die Option mit 4 relays) einen Bug reingebastelt. Wäre nett, wenn du nachher ein update machen könntest und checken, ob es jetzt wieder geht.
(Am besten dann nochmal mit einem "frischen" Device starten, also löschen und dann den Tasmota-"Shelly" neu starten)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: betonkelle am 19 Dezember 2020, 08:46:18
Hi Beta-User,

kann ich gerne machen, sag nur ab wann du die Änderungen eingearbeitet hast.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 19 Dezember 2020, 09:46:48
Kommt mit dem regulären update, ist also seit ca. 7:45 Uhr verfügbar...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: betonkelle am 19 Dezember 2020, 14:32:08
Hallo Beta-User,

das Update hat es leider nicht gebracht.

Hat nicht funktioniert.
Selber Fehler.
"Define Interlock first"
"Define Interlock first"
und das Device heißt dann
Interlock DVES_...

Habe "update" und "Shutdown restart" gemacht.

Hast du noch etwas zu testen für mich?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 20 Dezember 2020, 08:46:24
Habe eben nochmal einen fix ins svn geschoben, sorry, da musste man noch mehr "umpacken", damit das klappt...

Wenn du vor dem morgigen update-Lauf testen willst:
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: betonkelle am 20 Dezember 2020, 09:57:34
Hi Beta-Tester,

ich sehe mal zu, das ich es hinbekomme um dir Rückmeldung zu geben.
Danke aber schon mal.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: betonkelle am 20 Dezember 2020, 12:05:07
Hallo Beta-User,

nach dem SVN Checkout bleibt der Fehler.

Kann ich irgendwo debuggen um dir mehr Infos zu geben?
Grüße
Martin

P.S. mit dem Invert_1 template läuft es inkl. der Abfrage nach den Alexa params.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: betonkelle am 21 Dezember 2020, 16:05:29
Hallo Beta-User,

am Fehler hat sich leider nichts getan.
Ich habe gerade nochmal aktualisiert mit folgendem Ergebnis.

Im Log steht:

2020.12.21 15:55:49 1: ERROR evaluating { 1,2;; } : syntax error at (eval 282) line 1, at EOF

Beste Grüße
Martin
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 21 Dezember 2020, 16:12:47
Sorry, wenn es etwas dauert.
Ich hoffe es gefixt zu haben und die Struktur in dem Bereich dann auch wieder so gestaltet, dass man besser erkennen kann, was passiert. Werde das hoffentlich vor dem morgigen update-Lauf einchecken können, aber bis dato ist an der Stelle noch der kaputte Code.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: betonkelle am 21 Dezember 2020, 16:16:00
Hallo Beta-User,

passt für mich.
Danke für deinen Einsatz.

EDIT:

Eine kleine Ergänzung:
Kann sein, dass es auch am mqtt template liegt:

Ich habe noch ein Perl Warning das eine IP-Adresse parsed an andere Module und da gibt es die Meldung:

Argument "192.168.2.29" isn't numeric in  ..und dann kommen verschiedene Einträge wo die IP-Adresse an ein Modul übergeben wird, dass dann eben meckert, weil der Wert nicht numerisch ist.

Die zwei Geräte bei denen es auffällt nutzen das Tasmota_POW Template.

Grüße
Martin
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: betonkelle am 30 Dezember 2020, 20:26:52
Hallo Beta-User,

heute habe ich ein Update gemacht.
Es läuft jetzt wie gewünscht.
Habe nicht mitbekommen, dass du was gefixed hast.
Viele Dank und einen guten Rutsch
Martin
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: RappaSan am 02 Januar 2021, 10:49:47
Gibt es irgendwo eine Liste der internen Variablen, die in den *.template benutzt werden können?
Ich habe hier einen room "MQTT2_DEVICE", den ich neu angelegten Gosund-Steckdosen zuweisen will, aber wenn ich in meinem template
"attr DEVICE room MQTT2_DEVICE"
drin habe, wird aus dem room etwas anderes, z.B. "MQTT2_test".
Ansonsten läuft das mit den templates wirklich prima und ist eine große Hilfe.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 02 Januar 2021, 11:10:03
Auch MQTT2_DEVICE kann man haben, muss aber dann "DEVICE" schützen:
MQTT2_\DEVICE
Sonst:  :) 8)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rob am 10 Januar 2021, 23:37:20
Hallo.

Bin nicht sicher, ob die Info hier relevant ist und geb sie einfach mal her. Das Wiki unter https://github.com/arendst/Sonoff-Tasmota/ scheint es dort nicht mehr zu geben, sodass der Verweis in der Übersicht via...
set myMQTT_DEVICE attrTemplate ?
...
tasmota_rgb_led_controller
Tasmota RGB controller tested with RGB variant of Magichome, arilux LC-01 ,etc... -> https://github.com/arendst/Sonoff-Tasmota/wiki/MagicHome-LED-strip-controller
... nach Aufruf auf die Hauptseite vom Repo redirected wird.

Anscheinend liegt die verlinkte Info nun hier:
https://tasmota.github.io/docs/devices/MagicHome-LED-strip-controller/ (https://tasmota.github.io/docs/devices/MagicHome-LED-strip-controller/)

Naja, nix wildes - aber vielleicht interessant :)

Viele Grüße
rob
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 11 Januar 2021, 11:23:18
Puh, tasmota...

Vermutlich ist es nicht nur dieser Link, den man sich mal ansehen sollte. Mit 9.2 (?) scheinen sich weitere (unnötige) readingList-Einträge ergeben zu haben, und ob für manches jetzt (noch) "tele" paßt oder nach "stat" geändert werden sollte, müßte sich auch "jemand" mal ansehen...
(dazu ggf. die Frage, ob Events und Zeitstempel "gut" gesetzt werden).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rob am 11 Januar 2021, 20:07:28
Ah, OK - soweit hatte ich beim flachen Testen mit RGB(W) noch garnicht geblickt. Dachte ich geb mal laut zu meinem Stolperer.
Ich hatte mit einem Wemos D1 getestet. Soweit klappte das gut.
Muss aber erst tiefer durchsteigen, um eigene Denkfehler von tatsächlichem Anpassungsbedarf unterscheiden zu können. Ich werd mal sammeln was mir ggf. "auffällt".

VG
rob
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: tomcat.x am 12 Januar 2021, 17:48:46
Vermutlich bin ich hier falsch und das ganze gehört ins OpenMQTTGateway-Forum (zumindest in den open issues habe ich dort schon mal gesucht). Ich habe das Problem, dass bei den LYWSD03MMC ein falscher Temperatur-Wert für Temperaturen unter 0 angezeigt wird. Habe gerade erst mit ESP32 und MQTT begonnen, darum ist mir noch nicht alles so klar. Aber das Template und anschließend das generierte Gerät setzt nur die per JSON gelieferten Daten im Sinne von Benennung usw. um, die Ermittlung und Konvertierung aus dem Advertisment-String macht komplett das OpenMQTTGateway, richtig?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 12 Januar 2021, 18:03:54
Ich weiß nicht, ob der Wert "falsch" ist, auch im Thread zu dem Xiaomi-BT-Modul ist von "fehlerhaften" Werten die Rede. Da mich das interessiert hat, habe ich mal nachgeschaut, und siehe da: das Ding ist nicht für Minusgrade spezifiziert...

(Ansonsten bitte einfach einen separaten Thread aufmachen, wenn das weiter diskutiert werden soll).
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: tomcat.x am 12 Januar 2021, 18:49:55
Ok. Ich dachte, das hätte ich schon mal anders gelesen. Aber gerade nachgeschaut: Zumindest auf der Verpackung steht das genauso. Das erklärt es natürlich.

Bei dem XiaomiBTLESens habe ich das auch. Aber ich war im dortigen Thread im Zusammenhang mit der Implementierung der Sensoren auf einen Verweis auf ein Python Skript gestoßen. Und das mittlerweile genauso in Github beim OpenMQTTGateway. Wenn also beide Implementierungen die gleiche Vorlage hatten, wäre auch der Fehler in beiden.

Aber die Diskussion hier ist damit auf jeden Fall schon zu Ende.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: tomcat.x am 15 Januar 2021, 10:37:49
Letzter OT Post hier: Der Temperaturbereich (0-60°C) gilt scheinbar mehr für die MI Firmware. Der verbaute Sensor (SHTV3/SHTC3) kann wohl -40 bis 125°C. Zumindest gehen mit der ATC (oder pvvx) Firmware auch negative Temperaturen, getestet habe ich das bis -18 im Gefrierschrank ;-). Je nach Firmware spielt dann die LCD-Anzeige in der aktuellen Version nicht mehr mit (zu wenig Stellen), aber in fhem habe ich richtige Werte bekommen.

Nicht OT ist vielleicht der Hinweis, dass das OpenMQTTGateway explizit auch mit dem Advertisment-Format der ATC-Firmware umgehen kann und dafür kein weiteres Template notwendig ist, das funktioniert mit OpenMQTTGateway_BT_temp_hum_sensor.

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 15 Januar 2021, 10:49:14
[OT]
Danke für den Hinweis, dass die ATC-firmware das besser macht!

Dann bin ich umso zufriedener, dass ich den Schritt gemacht habe, auch wenn meine bisher alle im Innenbereich zum Einsatz kommen.
 
Falls jemand Ahnung hat, wie man das decoding macht, wäre es evtl. eine gute Idee, CoolTux zu unterstützen und den Sensor in der ATC-Version auch in das XiaomiBTLE-Modul aufzunehmen, das sollte eigentlich kein Hexenwerk sein.

(Grundsätzlich halte ich aber die ESP32/OpenMQTTGateway-Lösung trotz WLAN für die bessere Implementierung, wobei m.E. das Anbringen einer ordentlichen Antenne Pflicht ist; was da auf dem PCB vorhanden ist, scheint nicht unbedingt oprimal zu sein...).

Weitere Diskussion aber bitte ggf. tatsächlich separat...

[/OT]
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: tomcat.x am 01 Februar 2021, 19:38:20
Hallo, 2 Fragen bzw. Anregungen zu den Templates:

1. OpenMQTTGateway_MCU:
Was haltet Ihr davon, folgende oder ähnliche Attribute aufzunehmen? Oder habe nur ich da immer wieder "Schmutz" in den Readings?

2. OpenMQTTGateway_BT_scanner
Das Gerät wird doch auch bei mehreren Gateways nur anhand eines einzelnen über dieses Template angelegt und enthält dann in den Werten für das setlist-Attribut auch nur ein Gateway. Damit werden dann Befehle (z. B. Whitelist) auch nur an dieses eine Gateway gesendet. Oder habe ich bei der Nutzung des Templates was falsch gemacht?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 02 Februar 2021, 11:59:27
Die OpenMQTTGateway-Geschichten können wir gerne separat diskutieren, würde sich ggf. lohnen, dazu einen neuen Thread anzufangen und nicht den "Rolling-Code"-Thread weiterzuführen, zumal es dann auch wieder zu https://wiki.fhem.de/wiki/OpenMQTTGateway passen sollte (bzw. der dort geänderten Fassung).

Vorab vielleicht ein paar Anmerkungen:
- den "scanner" hatte ich mal zur Generalisierung angedacht, also viele GW's => ein "scanner". So läuft das grade bei mir. Ist einerseits praktisch, weil eben alles zusammenläuft, andererseits geht dann darüber das mit Blacklist etc. nicht mehr.
(in meiner Installation dümpelt das ganze gemütlich vor sich hin und funktioniert (mit Temp/Hum-Sensoren) zu meiner Zufriedenheit, bisher war das Interesse von weiteren Usern gering, daher hatte ich da keine große Energie mehr reininvestiert, obwohl es ein "stub" ist; "unnötige Readings" habe ich nicht, aber hartnäckige autocreates (https://forum.fhem.de/index.php/topic,114911.msg1091325.html#msg1091325)).
- Von daher finde ich den Vorschlag gut, das umzubauen. Mein Idee wäre dahingehend, dass wir ein (neues) attrTemplate (OpenMQTTGateway_MCU_BT?) bauen, das beide Funktionen zusammenführt (und einen comment zur Syntax für blacklist enthält), wenn man ein BT-fähiges GW hat? Das "scanner" könnte man dann generalisieren, aber dafür eben die Optionen zu blaicklist etc. weglassen?

Am liebsten wären mir fertige Vorschläge ::) ...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: tomcat.x am 02 Februar 2021, 18:52:58
Ein neuer Thread mach sicher Sinn und die entsprechenden Posts gleich mitnehmen. Müsstest Du das bei einem Admin anfragen, weil das hier Dein Thread ist?

Den Scanner finde ich schon praktisch. War mir halt nicht sicher, ob ich das richtig nutze, weil MQTT für mich komplettes Neuland ist, mit allem was dazu gehört wie Topics, Subscriptions, ...

Von daher bin ich glaube ich noch nicht so weit, da sinnvolle Vorschläge zu machen. Von dem Punkt mit White/Blacklist auf allen Gateways gleich einzustellen, bin ich beispielsweise schon wieder weg. Macht vielleicht schon mehr Sinn, das unterschiedlich einzustellen.

Und zu dem "Schmutz" in den Readings noch: Ich meine da zum Beispiel so was  "__name___ATC_CC9110___rssi__-72__distance__4.28", also keine sinnvollen Readings, die ich einfach nur nicht brauche.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: barneybaer am 28 Februar 2021, 21:41:44
Hallo, ich habe mal am Template für Xiaomi Fenster Kontakten gebastelt, da sie in der aktuellen mqtt2.template nicht von Alexa als Contact Sensoren erkannt werden. Der Patch dazu ist unten zu finden.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 01 März 2021, 08:11:31
Thx, hab's übernommen und hoffe, dass es in der jetzigen Form auch weiter mit anderen Sprachsteuerungslösungen kompatibel ist...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Jan_H am 02 März 2021, 18:49:36
Hallo zusammen,

ich bin gerade dabei mich wieder in FHEM reinzufinden. Ganz neu ist für mich die MQTT-Geräte.
Nachdem ich vor einiger Zeit einen Shelly 1 erfolgreich eingebunden habe, wollte ich heute einen Shelly 2.5 konfigurieren.

Der Shelly wird auch über MQTT in meinem Raum MQTT_DEVICE als MQTT2_shellyswitch25_xxxxxxx angezeigt. Wenn ich jetzt das Template Shelly25_split auswähle und "sei" drücke, erhalte ich eine Abfrage: "Specify the unknown parameters for shelly25_split:" und kann aus zwei Optionen wählen, ob ich das userreading für die Energiemessung setzen möchte. Ich kann auch hinter der jeweiligen Auswahl eine Checkbox auswählen.

Aber: Wie bestätige ich meine Auswahl? Ich komme nachdem ich die Checkbox gesetzt habe nicht weiter. Könnt ihr mir sagen, was ich falsch mache?

Danke und viele Grüße
Jan
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 03 März 2021, 09:54:33
Hab's grade versucht nachzustellen (ohne aktive Sprachsteuerung). Kann auswählen und nach Click auf den Button "OK" wird dann auch der 2. Kanal erstellt.

Bitte um eine genauere Beschreibung, was (nicht) passiert und ggf. einen screenshot von dem Dialogfeld mit der Auswahl, wenn da _kein_ OK-Button sein sollte.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Jan_H am 03 März 2021, 10:26:24
Hallo Beta-User,

vielen Dank für Deine Antwort.

Der OK-Button erscheint nicht. Ich habe es jetzt auch mal mit verschiedenen Styles und Browsern versucht, aber ich sehe ihn nicht.
Hier ist ein Screenshot meines letzten Versuches mit dem Style "Dark" und dem Firefox:


EDIT: Screenshot ausgetauscht
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 03 März 2021, 10:41:50
Wenn ich was zum Nachstellen bekomme (bitte ohne Hardware), dann werde ich das untersuchen.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 03 März 2021, 11:49:56
Wenn ich was zum Nachstellen bekomme (bitte ohne Hardware), dann werde ich das untersuchen.
@Jan_H:
Eine "RAW-Definition" von dem Ausgangsgerät sollte es tun.

Da wir (wenn mich meine Erinnerung nicht trügt) was ähnliches schon mal hatten: FHEM ist tagesaktuell und der Browsercache erneuert (ff: strg+F5)?

Wenn ja, bitte einen neuen Thread dazu aufmachen (bin am Zweifeln, ob MQTT der richtige Bereich ist, aber das sollte ok sein). Hat dann vermutlich nicht speziell was mit diesem attrT zu tun...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Jan_H am 03 März 2021, 12:56:06
@Beta-User

STRG+F5 habe ich beim EDGE gemacht und der Firefox unter Windows war sogar ganz neu installiert, also am Cache kann es nicht liegen.
Die FHEM-Version habe gestern nochmal per update aktualisiert.

Ich mache dann gleich mal einen neuen Thread auf.

Danke!
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: kjmEjfu am 06 April 2021, 10:03:09
Ich habe mal ein Template für openWB gebastelt. Allerdings frage ich mich, ob man den Teil readingList irgendwie kürzen kann. openWB nutzt (derzeit) keine JSON, sondern packt tatsächlich in jeden Pfad(?) den entsprechenden Wert rein.

name:openWB_with_two_loading_points
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*openWB.*
desc:Applies to openWB interface with 2 loading point. Firmware 1.9.x+ is needed <br> For direct connection to openWB MQTT Server. Otherwise check devicetopic.
#order:L_17b
#par:BASE_TOPIC;base topic: Base topic prefix, without trailing /;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^\/:]+)[\/].+, ? $1 : undef }
#par:IODEV;IO Dev without trailing :;{ AttrVal("DEVICE","IODev","") }
attr DEVICE devicetopic openWB
attr DEVICE icon building_carport_socket
attr DEVICE model openWB
setreading DEVICE attrTemplateVersion 20210406
attr DEVICE devicetopic openWB
attr DEVICE stateformat Lademodus: ChargeMode | Ladestatus Lp1: lp_1_ChargeStatus | verbleibende Ladezeit Lp1: lp_1_TimeRemaining <br> Ladestatus Lp2: lp_2_ChargeStatus | verbleibende Ladezeit Lp2: lp_2_TimeRemaining
attr DEVICE readingList \
$\DEVICETOPIC/global/WHouseConsumption:.* WHouseConsumption \
$\DEVICETOPIC/global/WAllChargePoints:.* WAllChargePoints \
$\DEVICETOPIC/global/ChargeMode:.* {my %h=(0=>'SofortLaden',1=>'MinPV',2=>'NurPV',3=>'Stop',4=>'Standby'); return {ChargeMode=>$h{$EVENT}}} \
$\DEVICETOPIC/system/Date:.* Date \
$\DEVICETOPIC/system/Timestamp:.* Timestamp \
$\DEVICETOPIC/system/Uptime:.* Uptime \
$\DEVICETOPIC/system/IpAddress:.* IPAddress \
$\DEVICETOPIC/system/Version:.* Version \
$\DEVICETOPIC/evu/ASchieflast:.* evu_ASchieflast \
$\DEVICETOPIC/evu/Hz:.* evu_Hz \
$\DEVICETOPIC/evu/APhase1:.* evu_Phase1 \
$\DEVICETOPIC/evu/APhase2:.* evu_APhase2 \
$\DEVICETOPIC/evu/APhase3:.* evu_APhase3 \
$\DEVICETOPIC/evu/PfPhase1:.* evu_PfPhase1 \
$\DEVICETOPIC/evu/PfPhase2:.* evu_PfPhase2 \
$\DEVICETOPIC/evu/PfPhase3:.* evu_PfPhase3 \
$\DEVICETOPIC/evu/VPhase1:.* evu_VPhase1 \
$\DEVICETOPIC/evu/VPhase2:.* evu_VPhase2 \
$\DEVICETOPIC/evu/VPhase3:.* evu_VPhase3 \
$\DEVICETOPIC/evu/WPhase1:.* evu_WPhase1 \
$\DEVICETOPIC/evu/WPhase2:.* evu_WPhase2 \
$\DEVICETOPIC/evu/WPhase3:.* evu_WPhase3 \
$\DEVICETOPIC/evu/W:.* evu_W_evu \
$\DEVICETOPIC/evu/WhExported:.* evu_WhExported \
$\DEVICETOPIC/lp/1/P%Soc:.* lp_1_Pct_Soc \
$\DEVICETOPIC/lp/1/countPhasesInUse:.* lp_1_countPhasesInUse \
$\DEVICETOPIC/lp/1/ChargePointEnabled:.* lp_1_ChargePointEnabled \
$\DEVICETOPIC/lp/1/ChargeStatus:.* lp_1_ChargeStatus \
$\DEVICETOPIC/lp/1/kWhChargedSincePlugged:.* lp_1_kWhChargedSincePlugged \
$\DEVICETOPIC/lp/1/kWhActualCharged:.* lp_1_kWhActualCharged \
$\DEVICETOPIC/lp/1/kWhCounter:.* lp_1_kWhCounter \
$\DEVICETOPIC/lp/1/strChargePointName:.* lp_1_strChargePointName \
$\DEVICETOPIC/lp/1/TimeRemaining:.* lp_1_TimeRemaining \
$\DEVICETOPIC/lp/1/VPhase1:.* lp_1_VPhase1 \
$\DEVICETOPIC/lp/1/VPhase2:.* lp_1_VPhase2 \
$\DEVICETOPIC/lp/1/VPhase3:.* lp_1_VPhase3 \
$\DEVICETOPIC/lp/1/APhase1:.* lp_1_APhase1 \
$\DEVICETOPIC/lp/1/APhase2:.* lp_1_APhase2 \
$\DEVICETOPIC/lp/1/APhase3:.* lp_1_APhase3 \
$\DEVICETOPIC/lp/1/W:.* lp_1_W \
$\DEVICETOPIC/lp/2/P%Soc:.* lp_2_Pct_Soc \
$\DEVICETOPIC/lp/2/countPhasesInUse:.* lp_2_countPhasesInUse \
$\DEVICETOPIC/lp/2/ChargePointEnabled:.* lp_2_ChargePointEnabled \
$\DEVICETOPIC/lp/2/ChargeStatus:.* lp_2_ChargeStatus \
$\DEVICETOPIC/lp/2/kWhChargedSincePlugged:.* lp_2_kWhChargedSincePlugged \
$\DEVICETOPIC/lp/2/kWhActualCharged:.* lp_2_kWhActualCharged \
$\DEVICETOPIC/lp/2/kWhCounter:.* lp_2_kWhCounter \
$\DEVICETOPIC/lp/2/strChargePointName:.* lp_2_strChargePointName \
$\DEVICETOPIC/lp/2/TimeRemaining:.* lp_2_TimeRemaining \
$\DEVICETOPIC/lp/2/VPhase1:.* lp_2_VPhase1 \
$\DEVICETOPIC/lp/2/VPhase2:.* lp_2_VPhase2 \
$\DEVICETOPIC/lp/2/VPhase3:.* lp_2_VPhase3 \
$\DEVICETOPIC/lp/2/APhase1:.* lp_2_APhase1 \
$\DEVICETOPIC/lp/2/APhase2:.* lp_2_APhase2 \
$\DEVICETOPIC/lp/2/APhase3:.* lp_2_APhase3 \
$\DEVICETOPIC/lp/2/W:.* lp_2_W \
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE setlist Lademodus:SofortLaden,Min+PV,NurPV,Stop,Standby { my %h=(SofortLaden=>'0','Min+PV'=>'1',NurPV=>'2',Stop=>'3',Standby=>'4');qq({$DEVICETOPIC/set/Chargemode $h{$EVTPART1}}) } \
Lp1_DirectChargeSubMode:Aus,kWh_Laden,SoC_Laden { my %h=(Aus=>'0',kWh_Laden=>'1',SoC_Laden=>'2');qq({$DEVICETOPIC/set/lp/1/DirectChargeSubMode $h{$EVTPART1}}) } \
Lp1_DirectChargeSoc:slider,1,1,100 $DEVICETOPIC/set/lp/1/DirectChargeSoc { $EVTPART1 } \
Lp1_DirectChargeAmps:slide,6,1,32 $DEVICETOPIC/set/lp/1/DirectChargeAmps { $EVTPART1 } \
Lp1_kWhDirectChargeToCharge:slide,1,1,100 $DEVICETOPIC/set/lp/1/kWhDirectChargeToCharge { $EVTPART1 } \
Lp1_ChargePointEnabled:Ein,Aus { my $value = $EVTPART1 eq "Ein" ? "1" : "0"; qq({$DEVICETOPIC/set/lp/1/ChargePointEnabled $value}) } \
Lp1_ResetDirectCharge:noArg $DEVICETOPIC/set/lp/1/boolResetDirectCharge 1 \
Lp2_DirectChargeSubMode:Aus,kWh_Laden,SoC_Laden { my %h=(Aus=>'0',kWh_Laden=>'1',SoC_Laden=>'2');qq({$DEVICETOPIC/set/lp/2/DirectChargeSubMode $h{$EVTPART1}}) } \
Lp2_DirectChargeSoc:slider,1,1,100 $DEVICETOPIC/set/lp/2/DirectChargeSoc { $EVTPART1 } \
Lp2_DirectChargeAmps:slide,6,1,32 $DEVICETOPIC/set/lp/2/DirectChargeAmps { $EVTPART1 } \
Lp2_kWhDirectChargeToCharge:slide,1,1,100 $DEVICETOPIC/set/lp/2/kWhDirectChargeToCharge { $EVTPART1 } \
Lp2_ChargePointEnabled:Ein,Aus { my $value = $EVTPART1 eq "Ein" ? "1" : "0"; qq({$DEVICETOPIC/set/lp/2/ChargePointEnabled $value}) } \
Lp2_ResetDirectCharge:noArg $DEVICETOPIC/set/lp(2/boolResetDirectCharge 1

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 07 April 2021, 15:26:46
Kürzen kann man m.E. nur mit weiteren Tricks, aber es ist sehr die Frage, ob es sinnvoll ist.

An sich finde ich das einen ziemlich coolen Wurf, auch mit den Hashes. Ein wenig irritiert mich das denglisch, und dass es zwar zwei Chargemode-Readings gibt, die aber irgendwie wieder nicht mit dem Setter "Lademods" einen Kreis zu bilden scheinen; bei anderen müßte das aber eigentlich klappen (ChargePointEnabled). Und ob die ganzen Readings mit der automatischen Benennung belassen werden sollten? (Vermutlich könnte man kürzen und umstellen).
Die "slide" sind vermutlich jeweils Typos?

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: kjmEjfu am 08 April 2021, 09:38:29
An sich finde ich das einen ziemlich coolen Wurf, auch mit den Hashes. Ein wenig irritiert mich das denglisch,

Ich habe mich an die Bezeichnungen von openWB gehalten. Kann man aber natürlich komplett englisch machen.
Durchaus auch möglich, dass openWB aktuell in einer Umstellung ist und die Topics in einer der nächsten Versionen komplett englisch sind.

und dass es zwar zwei Chargemode-Readings gibt, die aber irgendwie wieder nicht mit dem Setter "Lademods" einen Kreis zu bilden scheinen;

Der globale Chargemode gibt vor, inwiefern eine PV-Anlage berücksichtigt werden soll, wenn vorhanden. Das ist unabhängig von der Einstellung für die jeweiligen Ladepunkte.
Dann gibt es den Setter DirectChargeSubMode pro Ladepunkt, der aber nur Auswirkugen hat, wenn Chargemode auf 0/SofortLaden gesetzt ist. Gibt aber scheinbar kein Topic aus dem den gesetzten DirectChargeSubMode  entnehmen kann.

bei anderen müßte das aber eigentlich klappen (ChargePointEnabled). Und ob die ganzen Readings mit der automatischen Benennung belassen werden sollten? (Vermutlich könnte man kürzen und umstellen).

Deshalb steht es hier als Entwurf :-)
Ich fand es sinnvoll die Readings zu clustern, die
- entweder mit dem Wert, den openWB zur EVU bekommt/holt, zu tun hat: evu_
- mit dem Ladepunkt 1: lp_1_
- mit dem Ladepunkt 2: lp_2_
- global für die openWB gelten

Die "slide" sind vermutlich jeweils Typos?

Ups, ja.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: yersinia am 07 Mai 2021, 16:14:00
kleines Update für das tasmota_POW template, weil reading IPAddress (zumindest bei meiner Tasmota 9.4.0) durch Info2_IPAddress ersetzt worden ist:
attr DEVICE devStateIcon {my $text = ' uptime: '.ReadingsVal($name,"Uptime","unknown").sprintf(" aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"));; my $onl = ReadingsVal($name,"LWT","false") eq "Online"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");;"<div><a href=\"http://".ReadingsVal($name,"IPAddress",ReadingsVal($name,"Info2_IPAddress","none"))." \"target=\"_blank\">".FW_makeImage($onl).'</a> <a href="/fhem?cmd.dummy=set '.$name.' toggle&XHR=1">'.FW_makeImage($light)."</a>$text<b></b>"}(Zeile 1047 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L1047))

btw, soll das eigtl so
$text<b></b>?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 08 Mai 2021, 15:11:52
Danke für den Hinweis, das mit dem "leeren Fett" ist auch weg...

Btw.: Das mit dem neuen Reading für IPAddress müsste eigentlich noch mehr devices betreffen, oder?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: yersinia am 08 Mai 2021, 15:26:21
Btw.: Das mit dem neuen Reading für IPAddress müsste eigentlich noch mehr devices betreffen, oder?
Ich denke ja. Im fw-check für Tasmota (https://forum.fhem.de/index.php/topic,110350.0.html) benutze ich dieses historisch gewachsene Konstrukt:
ReadingsVal($dev,"Info2_IPAddress",ReadingsVal($dev,"IPAddress",ReadingsVal($dev,"INFO2_IPAddress","0.0.0.0")))
EDIT: das betrifft folgende Zeilen:
1083 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template?rev=24396#L1083)

Diese Zuweisungen im attr stateFormat sehen komisch aus - gibt es ein Reading IPAddress?
<a href="http://IPAddress" target="_blank">IPAddress</a>1139 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template?rev=24396#L1139)
1165 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template?rev=24396#L1165)
1193 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template?rev=24396#L1193)
1245 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template?rev=24396#L1245)
1322 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template?rev=24396#L1322)
1527 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template?rev=24396#L1527)
1658 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template?rev=24396#L1658)
1725 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template?rev=24396#L1725)
2050 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template?rev=24396#L2050)


Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 08 Mai 2021, 15:58:07
Btw.: Das mit dem neuen Reading für IPAddress müsste eigentlich noch mehr devices betreffen, oder?
Ich befürchte, das wird mehr Arbeit  ::)
Ich habe mal gerade ein ganz generisches Device aktualisiert, das hatte bisher kein Template, das ist jetzt in den Readings gefühlt doppelt so lang geworden ...
Das INFO2_... kommt doch auch durch json2namevalue, das könnte man doch wieder wegmappen?
Zitat
     2021-05-08 15:40:03   Info1_FallbackTopic cmnd/DVES_D8B7E5_fb/
     2021-05-08 15:40:03   Info1_GroupTopic cmnd/tasmotas/
     2021-05-08 15:40:03   Info1_Module    Generic
     2021-05-08 15:40:03   Info1_Version   9.4.0(tasmota)
     2021-05-08 15:40:03   Info2_Hostname  tasmota-6117
     2021-05-08 15:40:03   Info2_IPAddress 192.168.178.218
     2021-05-08 15:40:03   Info2_WebServerMode Admin
     2021-05-08 15:40:03   Info3_RestartReason Software/System restart
Es kommen auch ganz neue Topics:
2021.05.08 15:34:46 2: autocreate: define MQTT2_tasmota MQTT2_DEVICE tasmota mqtt2sattr MQTT2_tasmota readingList stat/tasmota/UPGRADE:.* { json2nameValue($EVENT) }Das wird bestimmt noch lustig  ::)
Zitat
gibt es ein Reading IPAddress?
gab es bisher - ja. Das wird jetzt nicht mehr bedient  :'(
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 10 Mai 2021, 09:46:17
Ich befürchte, das wird mehr Arbeit  ::)
Ich habe mal gerade ein ganz generisches Device aktualisiert, das hatte bisher kein Template, das ist jetzt in den Readings gefühlt doppelt so lang geworden ...
Das INFO2_... kommt doch auch durch json2namevalue, das könnte man doch wieder wegmappen?
Müßte eigentlich gehen mit jsonMap, und da praktisch alle über das zentrale Tasmota-attrTemplate laufen, dürfte das auch relativ wenig Aufwand sein; problematisch sind danach eigentlich nur noch die "Spezialfälle", insbesondere mehrkanalige "Einheitsdevices".
Und da wir dann wieder auf einem einheitlichen Stand sind über alle Firmware-Versionen weg, sollte das auch am wenigsten Rückfragen seitens der User verursachen, oder?

Zitat
Es kommen auch ganz neue Topics:
2021.05.08 15:34:46 2: autocreate: define MQTT2_tasmota MQTT2_DEVICE tasmota mqtt2sattr MQTT2_tasmota readingList stat/tasmota/UPGRADE:.* { json2nameValue($EVENT) }Das wird bestimmt noch lustig  ::)
...öfter mal was neues...

Magst du dir das insgesamt mal ansehen? (80/20 wäre für den ersten Schuss schon mal super!)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 10 Mai 2021, 13:55:12
first shot für die Info._ bekommt man das eleganter? Das Reading jsonMap ist ja ziemlich simpel.
Man könnte anstatt $JSONMAP ein Stück Code geben - macht "man" das?  ::) ;D
attr ... readingList tele/tasmota.../INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }attr MQTT2_DVES_D8B7E5 jsonMap Info1_FallbackTopic:FallbackTopic Info1_GroupTopic:GroupTopic Info1_Module:Module Info1_Version:Version Info2_Hostname:Hostname Info2_IPAddress:IPAddress Info2_WebServerMode:WebServerMode Info3_RestartReason:RestartReason
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 10 Mai 2021, 14:13:09
first shot für die Info._ bekommt man das eleganter? Das Reading jsonMap ist ja ziemlich simpel.
Man könnte anstatt $JSONMAP ein Stück Code geben - macht "man" das?  ::) ;D
attr ... readingList tele/tasmota.../INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }attr MQTT2_DVES_D8B7E5 jsonMap Info1_FallbackTopic:FallbackTopic Info1_GroupTopic:GroupTopic Info1_Module:Module Info1_Version:Version Info2_Hostname:Hostname Info2_IPAddress:IPAddress Info2_WebServerMode:WebServerMode Info3_RestartReason:RestartReason
Na ja, _falls_ Code statt $JSONMAP ginge (ein flacher HASH ginge wohl, wenn ich das richtig im Kopf habe), würde man damit wohl das sonstige Mapping abschießen; wenn, dann müßte man $EVENT "vorbehandeln". "Info2_" etc. deutet ja auch darauf hin, dass es noch eine interne Struktur gibt, die eher dem alten Format entspricht. Erst diese Umverpackung (zusätzlich zum Topic) dafür sorgt, dass diese "unglücklichen" Readingnamen entstehen, oder liege ich da falsch...? Ggf. könnte man auch versuchen, das auf alten Stand (via backlog ?) zurückzukonfigurieren, vielleicht kann man den Unsinn abstellen?

Ansonsten ist der jsonMap-Mechanismus (nach meinem Code-Gedächtnis) ein "simpler" hash-lookup, von daher ist an der Stelle dann nichts mit regex.
Man frag sich aber, wer die ganzen Infos wann und warum braucht...

Wäre interessant zu hören, was Rudi zum Thema effiziente Verarbeitung meint, aber da müssten wir wohl etwas MQTT-Traffic zum Spielen liefern, bevor wir ggf. eine Antwort darauf bekommen ;) .
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 10 Mai 2021, 14:24:16
Zitat
dass es noch eine interne Struktur gibt, die eher dem alten Format entspricht.

So ist es auch:

Alt:

14:14:39.567 MQT: tele/DVES_825880/INFO1 = {"Module":"Sonoff 4CH","Version":"9.4.0(sensors)","FallbackTopic":"cmnd/DVES_825880_fb/","GroupTopic":"cmnd/tasmotas/"}
14:14:39.576 MQT: tele/DVES_825880/INFO2 = {"WebServerMode":"Admin","Hostname":"DVES_825880-6272","IPAddress":"192.168.188.61"}
14:14:39.587 MQT: tele/DVES_825880/INFO3 = {"RestartReason":"Software/System restart"}

Neu:

14:14:39.567 MQT: tele/DVES_825880/INFO1 = {"Info1":{"Module":"Sonoff 4CH","Version":"9.4.0(sensors)","FallbackTopic":"cmnd/DVES_825880_fb/","GroupTopic":"cmnd/tasmotas/"}}
14:14:39.576 MQT: tele/DVES_825880/INFO2 = {"Info2":{"WebServerMode":"Admin","Hostname":"DVES_825880-6272","IPAddress":"192.168.188.61"}}
14:14:39.587 MQT: tele/DVES_825880/INFO3 = {"Info3":{"RestartReason":"Software/System restart"}}

Meine Vermutung ist das man die Objektnamen ("Info.": ) mit j2nv ignorieren kann, ist aber wie so oft/immer  ::), entweder zu wenig bisher verstanden oder schon wieder vergessen wie das umzusetzen wäre.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 10 Mai 2021, 14:41:50
_Mit_ j2nv geht wohl nicht, aber _vor_ sollte gehen:

attr DEVICE readingList \
  TELETOPIC/INFO.:.* { $EVENT =~ m,^..Info[1-3]..(.+).$, ?  json2nameValue($1,'',$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 10 Mai 2021, 15:10:24
Ja das passt so.

defmod MQTT2_DVES_825880_CHTest MQTT2_DEVICE DVES_825880
attr MQTT2_DVES_825880_CHTest IODev MQTT2_Server
attr MQTT2_DVES_825880_CHTest autocreate 0
attr MQTT2_DVES_825880_CHTest comment Channel 1 for MQTT2_DVES_825880, see also MQTT2_DVES_825880_CH2, MQTT2_DVES_825880_CH3 and MQTT2_DVES_825880_CH4
attr MQTT2_DVES_825880_CHTest genericDeviceType switch
attr MQTT2_DVES_825880_CHTest icon hue_filled_outlet
attr MQTT2_DVES_825880_CHTest 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_825880_CHTest model tasmota_4channel_split
attr MQTT2_DVES_825880_CHTest readingList tele/DVES_825880/LWT:.* LWT\
  tele/DVES_825880/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/DVES_825880/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/DVES_825880/INFO.:.* { $EVENT =~ m,^..Info[1-3]..(.+).$, ?  json2nameValue($1,'',$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }\
  tele/DVES_825880/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  stat/DVES_825880/POWER1:.* state\
  stat/DVES_825880/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr MQTT2_DVES_825880_CHTest room MQTT2_DEVICE
attr MQTT2_DVES_825880_CHTest setList off:noArg    cmnd/DVES_825880/POWER1 0\
  on:noArg     cmnd/DVES_825880/POWER1 1\
  toggle:noArg cmnd/DVES_825880/POWER1 2\
  setOtaUrl:textField cmnd/DVES_825880/OtaUrl $EVTPART1\
  upgrade:noArg   cmnd/DVES_825880/upgrade 1
attr MQTT2_DVES_825880_CHTest setStateList on off toggle

setstate MQTT2_DVES_825880_CHTest off
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:49 FallbackTopic cmnd/DVES_825880_fb/
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:49 GroupTopic cmnd/tasmotas/
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:54 Heap 23
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:49 Hostname DVES_825880-6272
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:01:52 IODev MQTT2_Server
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:49 IPAddress 192.168.188.61
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:49 LWT Online
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:54 LoadAvg 24
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:49 Module Sonoff 4CH
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:54 MqttCount 1
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:49 RestartReason Software/System restart
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:54 Sleep 50
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:54 SleepMode Dynamic
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:54 Time 2021-05-10T15:04:54
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:54 Uptime 0T00:00:09
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:54 UptimeSec 9
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:49 Version 9.4.0(sensors)
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:49 WebServerMode Admin
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:54 Wifi_AP 1
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:54 Wifi_BSSId FE:EC:DA:FD:26:1A
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:54 Wifi_Channel 3
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:54 Wifi_Downtime 0T00:00:03
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:54 Wifi_LinkCount 1
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:54 Wifi_RSSI 76
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:54 Wifi_SSId FBF
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:54 Wifi_Signal -62
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:04:49 state off
setstate MQTT2_DVES_825880_CHTest 2021-05-10 15:01:52 subscriptions cmnd/DVES_825880/# cmnd/DVES_825880_fb/# cmnd/tasmotas/#

Wie du siehst gibts bei dem STATE-Topic jetzt aber auch den Objektnamen Wifi:
15:04:54.460 MQT: tele/DVES_825880/STATE = {"Time":"2021-05-10T15:04:54","Uptime":"0T00:00:09","UptimeSec":9,"Heap":23,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":24,"MqttCount":1,"POWER1":"off","POWER2":"off","POWER3":"off","POWER4":"off","Wifi":{"AP":1,"SSId":"FBF","BSSId":"FE:EC:DA:FD:26:1A","Channel":3,"RSSI":76,"Signal":-62,"LinkCount":1,"Downtime":"0T00:00:03"}}
Evtl. ist es einfacher/kürzer in Zukunft mit den Prefixen zu leben ?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 10 Mai 2021, 15:40:26
Evtl. ist es einfacher/kürzer in Zukunft mit den Prefixen zu leben ?
Na ja, wenn das bedeuten soll, ohne jsonMap zu arbeiten, dann haben wir zumindest in der Übergangszeit das Problem, dass man diese alternative Abfrage machen muss und man befürchten muss, dass das tendenziell mehr werden wird mit diesen (mAn. unnötig) verschachtelten Objekten.

Von daher neige ich dazu, das eher auf den alten Stand hinzubiegen. Die Frage wäre also, was der effizientere Weg ist, und ich vermute fast, dass es die regex-Variante mit dem "vorbehandelten" $EVENT ist. Ist halt nicht so schön anzusehen, aber wen stört das schon...

Leider ist mir zumindest auf die Schnelle im Tasmota-Changelog nichts dazu über den Weg gelaufen, wo das überhaupt herkommt; ich vermute, das kommt aus dem WiFi-Manager-Framework...?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: hydrotec am 13 Mai 2021, 09:22:27
[FRAGE]

Hallo werte MQTT2-Gemeinde,

bin relativ neu in dem Thema MQTT2.
Erst einmal ein dickes Lob an alle Beteiligten.
Was hier in den letzten Jahren gewachsen ist, Hut ab.

Dankeschön  :)

Lese mich dazu schon einige Tage durch die Dokumentationen (Wiki/Forum).
Sollte die Frage schon einmal behandelt worden sein, bitte ich dies zu entschuldigen.
Ist nicht gerade wenig, wenn auch gut verfasst.

Konkret geht es um zigbee2mqtt (https://www.zigbee2mqtt.io/).
Erst einmal MQTT2_SERVER (inkl. allowed) nach FHEMWiki (https://wiki.fhem.de/wiki/MQTT#FHEM_als_MQTT-Server) angelegt.
Anschließend nach der Anleitung unter Zigbee2mqtt (https://wiki.fhem.de/wiki/Zigbee2mqtt) vorgegangen.
mqtt:
  client_id: 'zigbee_general'

advanced:
  report: true
in der configuration.yaml eingetragen.
Und danach zigbee2mqtt.service gestartet.
Autocreate hat mir auch gleich ein MQTT2-DEVICE angelegt, bei dem ich
set MQTT2_zigbee_general attrTemplate zigbee2mqtt_bridge
angewendet habe.

Soweit so gut, alles wie es sein soll.
zigbee-Devices werden angelegt, und mit den jeweiligen Templates funktioniert auch alles wie es soll.


Jetzt zur eigentlichen Frage. (genau genommen sind es zwei)
Sobald ich das Template zigbee2mqtt_bridge auf MQTT2_zigbee_general anwende, wird mir zusätzlich noch folgendes MQTT2-DEVICE mit angelegt.
define MQTT2_zigbee_bridge MQTT2_DEVICE zigbee_bridge
attr MQTT2_zigbee_bridge DbLogExclude .*
attr MQTT2_zigbee_bridge readingList zigbee2mqtt/bridge/logging:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_bridge room MQTT2_DEVICE

setstate MQTT2_zigbee_bridge 2021-05-12 16:53:15 IODev MQTT2_SERVER
setstate MQTT2_zigbee_bridge 2021-05-12 16:53:15 associatedWith MQTT2_zigbee_general
setstate MQTT2_zigbee_bridge 2021-05-13 08:31:36 level info
setstate MQTT2_zigbee_bridge 2021-05-13 08:31:36 message MQTT publish: topic 'zigbee2mqtt/xi_sensor_light_02', payload '{"battery":100,"illuminance":40115,"illuminance_lux":10266,"linkquality":111,"voltage":3100}'

Was für eine Funktion hat dies, und gibt es hier auch ein Template welches ich anwenden sollte?


Hoffentlich war alles etwas verständlich ausgedrückt.
Sollten noch weitere Informationen fehlen, bitte melden.

Gruß, Karsten



Falls benötigt, noch die anderen Devices (list -r <device>)

MQTT2_SERVER
define MQTT2_SERVER MQTT2_SERVER 1883 global
attr MQTT2_SERVER DbLogExclude .*
attr MQTT2_SERVER group MQTT2
attr MQTT2_SERVER room 03_Service

setstate MQTT2_SERVER 2021-05-12 15:30:19 RETAIN {"zigbee2mqtt/bridge/config":"{\u0022commit\u0022:\u0022f2e39af1\u0022,\u0022coordinator\u0022:{\u0022meta\u0022:{\u0022maintrel\u0022:1,\u0022majorrel\u0022:2,\u0022minorrel\u0022:7,\u0022product\u0022:1,\u0022revision\u0022:20210120,\u0022transportrev\u0022:2},\u0022type\u0022:\u0022zStack3x0\u0022},\u0022log_level\u0022:\u0022info\u0022,\u0022network\u0022:{\u0022channel\u0022:11,\u0022extendedPanID\u0022:\u00220xdddddddddddddddd\u0022,\u0022panID\u0022:58385},\u0022permit_join\u0022:false,\u0022version\u0022:\u00221.18.3\u0022}","zigbee2mqtt/bridge/devices":"[{\u0022definition\u0022:null,\u0022endpoints\u0022:{\u00221\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u002210\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u002211\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[\u0022ssIasAce\u0022],\u0022output\u0022:[\u0022ssIasZone\u0022,\u0022ssIasWd\u0022]},\u0022configured_reportings\u0022:[]},\u0022110\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u002212\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u002213\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[\u0022genOta\u0022],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u00222\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u0022242\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u00223\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u00224\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u002247\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u00225\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u00226\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u00228\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]}},\u0022friendly_name\u0022:\u0022Coordinator\u0022,\u0022ieee_address\u0022:\u00220x00124b00214f3bc4\u0022,\u0022interview_completed\u0022:true,\u0022interviewing\u0022:false,\u0022network_address\u0022:0,\u0022supported\u0022:false,\u0022type\u0022:\u0022Coordinator\u0022},{\u0022date_code\u0022:\u002220161128\u0022,\u0022definition\u0022:{\u0022description\u0022:\u0022Aqara door & window contact sensor\u0022,\u0022exposes\u0022:[{\u0022access\u0022:1,\u0022description\u0022:\u0022Remaining battery in %\u0022,\u0022name\u0022:\u0022battery\u0022,\u0022property\u0022:\u0022battery\u0022,\u0022type\u0022:\u0022numeric\u0022,\u0022unit\u0022:\u0022%\u0022,\u0022value_max\u0022:100,\u0022value_min\u0022:0},{\u0022access\u0022:1,\u0022description\u0022:\u0022Indicates if the contact is closed (= true) or open (= false)\u0022,\u0022name\u0022:\u0022contact\u0022,\u0022property\u0022:\u0022contact\u0022,\u0022type\u0022:\u0022binary\u0022,\u0022value_off\u0022:true,\u0022value_on\u0022:false},{\u0022access\u0022:1,\u0022description\u0022:\u0022Measured temperature value\u0022,\u0022name\u0022:\u0022temperature\u0022,\u0022property\u0022:\u0022temperature\u0022,\u0022type\u0022:\u0022numeric\u0022,\u0022unit\u0022:\u0022°C\u0022},{\u0022access\u0022:1,\u0022description\u0022:\u0022Voltage of the battery in millivolts\u0022,\u0022name\u0022:\u0022voltage\u0022,\u0022property\u0022:\u0022voltage\u0022,\u0022type\u0022:\u0022numeric\u0022,\u0022unit\u0022:\u0022mV\u0022},{\u0022access\u0022:1,\u0022description\u0022:\u0022Link quality (signal strength)\u0022,\u0022name\u0022:\u0022linkquality\u0022,\u0022property\u0022:\u0022linkquality\u0022,\u0022type\u0022:\u0022numeric\u0022,\u0022unit\u0022:\u0022lqi\u0022,\u0022value_max\u0022:255,\u0022value_min\u0022:0}],\u0022model\u0022:\u0022MCCGQ11LM\u0022,\u0022supports_ota\u0022:false,\u0022vendor\u0022:\u0022Xiaomi\u0022},\u0022endpoints\u0022:{\u00221\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[\u0022genBasic\u0022,\u0022genIdentify\u0022,\u0022genOnOff\u0022],\u0022output\u0022:[\u0022genBasic\u0022,\u0022genGroups\u0022]},\u0022configured_reportings\u0022:[]}},\u0022friendly_name\u0022:\u0022xi_sensor_contact_03\u0022,\u0022ieee_address\u0022:\u00220x00158d000669299c\u0022,\u0022interview_completed\u0022:true,\u0022interviewing\u0022:false,\u0022model_id\u0022:\u0022lumi.sensor_magnet.aq2\u0022,\u0022network_address\u0022:26209,\u0022power_source\u0022:\u0022Battery\u0022,\u0022software_build_id\u0022:\u00223000-0001\u0022,\u0022supported\u0022:true,\u0022type\u0022:\u0022EndDevice\u0022},{\u0022definition\u0022:{\u0022description\u0022:\u0022Aqara door & window contact sensor\u0022,\u0022exposes\u0022:[{\u0022access\u0022:1,\u0022description\u0022:\u0022Remaining battery in %\u0022,\u0022name\u0022:\u0022battery\u0022,\u0022property\u0022:\u0022battery\u0022,\u0022type\u0022:\u0022numeric\u0022,\u0022unit\u0022:\u0022%\u0022,\u0022value_max\u0022:100,\u0022value_min\u0022:0},{\u0022access\u0022:1,\u0022description\u0022:\u0022Indicates if the contact is closed (= true) or open (= false)\u0022,\u0022name\u0022:\u0022contact\u0022,\u0022property\u0022:\u0022contact\u0022,\u0022type\u0022:\u0022binary\u0022,\u0022value_off\u0022:true,\u0022value_on\u0022:false},{\u0022access\u0022:1,\u0022description\u0022:\u0022Measured temperature value\u0022,\u0022name\u0022:\u0022temperature\u0022,\u0022property\u0022:\u0022temperature\u0022,\u0022type\u0022:\u0022numeric\u0022,\u0022unit\u0022:\u0022°C\u0022},{\u0022access\u0022:1,\u0022description\u0022:\u0022Voltage of the battery in millivolts\u0022,\u0022name\u0022:\u0022voltage\u0022,\u0022property\u0022:\u0022voltage\u0022,\u0022type\u0022:\u0022numeric\u0022,\u0022unit\u0022:\u0022mV\u0022},{\u0022access\u0022:1,\u0022description\u0022:\u0022Link quality (signal strength)\u0022,\u0022name\u0022:\u0022linkquality\u0022,\u0022property\u0022:\u0022linkquality\u0022,\u0022type\u0022:\u0022numeric\u0022,\u0022unit\u0022:\u0022lqi\u0022,\u0022value_max\u0022:255,\u0022value_min\u0022:0}],\u0022model\u0022:\u0022MCCGQ11LM\u0022,\u0022supports_ota\u0022:false,\u0022vendor\u0022:\u0022Xiaomi\u0022},\u0022endpoints\u0022:{\u00221\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]}},\u0022friendly_name\u0022:\u0022xi_sensor_contact_04\u0022,\u0022ieee_address\u0022:\u00220x00158d000669348a\u0022,\u0022interview_completed\u0022:true,\u0022interviewing\u0022:false,\u0022model_id\u0022:\u0022lumi.sensor_magnet.aq2\u0022,\u0022network_address\u0022:3822,\u0022power_source\u0022:\u0022Battery\u0022,\u0022supported\u0022:true,\u0022type\u0022:\u0022EndDevice\u0022},{\u0022date_code\u0022:\u002220190710\u0022,\u0022definition\u0022:{\u0022description\u0022:\u0022SYMFONISK sound controller\u0022,\u0022exposes\u0022:[{\u0022access\u0022:1,\u0022description\u0022:\u0022Remaining battery in %\u0022,\u0022name\u0022:\u0022battery\u0022,\u0022property\u0022:\u0022battery\u0022,\u0022type\u0022:\u0022numeric\u0022,\u0022unit\u0022:\u0022%\u0022,\u0022value_max\u0022:100,\u0022value_min\u0022:0},{\u0022access\u0022:1,\u0022description\u0022:\u0022Triggered action (e.g. a button click)\u0022,\u0022name\u0022:\u0022action\u0022,\u0022property\u0022:\u0022action\u0022,\u0022type\u0022:\u0022enum\u0022,\u0022values\u0022:[\u0022brightness_move_up\u0022,\u0022brightness_move_down\u0022,\u0022brightness_stop\u0022,\u0022toggle\u0022,\u0022brightness_step_up\u0022,\u0022brightness_step_down\u0022]},{\u0022access\u0022:1,\u0022description\u0022:\u0022Link quality (signal strength)\u0022,\u0022name\u0022:\u0022linkquality\u0022,\u0022property\u0022:\u0022linkquality\u0022,\u0022type\u0022:\u0022numeric\u0022,\u0022unit\u0022:\u0022lqi\u0022,\u0022value_max\u0022:255,\u0022value_min\u0022:0}],\u0022model\u0022:\u0022E1744\u0022,\u0022supports_ota\u0022:true,\u0022vendor\u0022:\u0022IKEA\u0022},\u0022endpoints\u0022:{\u00221\u0022:{\u0022bindings\u0022:[{\u0022cluster\u0022:\u0022genLevelCtrl\u0022,\u0022target\u0022:{\u0022endpoint\u0022:1,\u0022ieee_address\u0022:\u00220x00124b00214f3bc4\u0022,\u0022type\u0022:\u0022endpoint\u0022}},{\u0022cluster\u0022:\u0022genPowerCfg\u0022,\u0022target\u0022:{\u0022endpoint\u0022:1,\u0022ieee_address\u0022:\u00220x00124b00214f3bc4\u0022,\u0022type\u0022:\u0022endpoint\u0022}}],\u0022clusters\u0022:{\u0022input\u0022:[\u0022genBasic\u0022,\u0022genPowerCfg\u0022,\u0022genIdentify\u0022,\u0022genPollCtrl\u0022,\u0022touchlink\u0022],\u0022output\u0022:[\u0022genIdentify\u0022,\u0022genGroups\u0022,\u0022genOnOff\u0022,\u0022genLevelCtrl\u0022,\u0022genOta\u0022,\u0022touchlink\u0022]},\u0022configured_reportings\u0022:[{\u0022attribute\u0022:\u0022batteryPercentageRemaining\u0022,\u0022cluster\u0022:\u0022genPowerCfg\u0022,\u0022maximum_report_interval\u0022:62000,\u0022minimum_report_interval\u0022:3600,\u0022reportable_change\u0022:0}]}},\u0022friendly_name\u0022:\u0022ik_remote_symfonisk_02\u0022,\u0022ieee_address\u0022:\u00220x680ae2fffe1aa806\u0022,\u0022interview_completed\u0022:true,\u0022interviewing\u0022:false,\u0022model_id\u0022:\u0022SYMFONISK Sound Controller\u0022,\u0022network_address\u0022:1941,\u0022power_source\u0022:\u0022Battery\u0022,\u0022software_build_id\u0022:\u00222.1.024\u0022,\u0022supported\u0022:true,\u0022type\u0022:\u0022EndDevice\u0022},{\u0022date_code\u0022:\u002220191118\u0022,\u0022definition\u0022:{\u0022description\u0022:\u0022MiJia light intensity sensor\u0022,\u0022exposes\u0022:[{\u0022access\u0022:1,\u0022description\u0022:\u0022Remaining battery in %\u0022,\u0022name\u0022:\u0022battery\u0022,\u0022property\u0022:\u0022battery\u0022,\u0022type\u0022:\u0022numeric\u0022,\u0022unit\u0022:\u0022%\u0022,\u0022value_max\u0022:100,\u0022value_min\u0022:0},{\u0022access\u0022:1,\u0022description\u0022:\u0022Raw measured illuminance\u0022,\u0022name\u0022:\u0022illuminance\u0022,\u0022property\u0022:\u0022illuminance\u0022,\u0022type\u0022:\u0022numeric\u0022},{\u0022access\u0022:1,\u0022description\u0022:\u0022Measured illuminance in lux\u0022,\u0022name\u0022:\u0022illuminance_lux\u0022,\u0022property\u0022:\u0022illuminance_lux\u0022,\u0022type\u0022:\u0022numeric\u0022,\u0022unit\u0022:\u0022lx\u0022},{\u0022access\u0022:1,\u0022description\u0022:\u0022Link quality (signal strength)\u0022,\u0022name\u0022:\u0022linkquality\u0022,\u0022property\u0022:\u0022linkquality\u0022,\u0022type\u0022:\u0022numeric\u0022,\u0022unit\u0022:\u0022lqi\u0022,\u0022value_max\u0022:255,\u0022value_min\u0022:0}],\u0022model\u0022:\u0022GZCGQ01LM\u0022,\u0022supports_ota\u0022:false,\u0022vendor\u0022:\u0022Xiaomi\u0022},\u0022endpoints\u0022:{\u00221\u0022:{\u0022bindings\u0022:[{\u0022cluster\u0022:\u0022genPowerCfg\u0022,\u0022target\u0022:{\u0022endpoint\u0022:1,\u0022ieee_address\u0022:\u00220x00124b00214f3bc4\u0022,\u0022type\u0022:\u0022endpoint\u0022}},{\u0022cluster\u0022:\u0022msIlluminanceMeasurement\u0022,\u0022target\u0022:{\u0022endpoint\u0022:1,\u0022ieee_address\u0022:\u00220x00124b00214f3bc4\u0022,\u0022type\u0022:\u0022endpoint\u0022}}],\u0022clusters\u0022:{\u0022input\u0022:[\u0022genBasic\u0022,\u0022msIlluminanceMeasurement\u0022,\u0022genIdentify\u0022,\u0022genPowerCfg\u0022],\u0022output\u0022:[\u0022genIdentify\u0022]},\u0022configured_reportings\u0022:[{\u0022attribute\u0022:\u0022batteryVoltage\u0022,\u0022cluster\u0022:\u0022genPowerCfg\u0022,\u0022maximum_report_interval\u0022:62000,\u0022minimum_report_interval\u0022:3600,\u0022reportable_change\u0022:0},{\u0022attribute\u0022:\u0022measuredValue\u0022,\u0022cluster\u0022:\u0022msIlluminanceMeasurement\u0022,\u0022maximum_report_interval\u0022:3600,\u0022minimum_report_interval\u0022:15,\u0022reportable_change\u0022:500}]}},\u0022friendly_name\u0022:\u0022xi_sensor_light_02\u0022,\u0022ieee_address\u0022:\u00220x04cf8cdf3c7ca64e\u0022,\u0022interview_completed\u0022:true,\u0022interviewing\u0022:false,\u0022model_id\u0022:\u0022lumi.sen_ill.mgl01\u0022,\u0022network_address\u0022:39578,\u0022power_source\u0022:\u0022Battery\u0022,\u0022software_build_id\u0022:\u00222019\u005cu0000www.\u0022,\u0022supported\u0022:true,\u0022type\u0022:\u0022EndDevice\u0022}]","zigbee2mqtt/bridge/extensions":"[]","zigbee2mqtt/bridge/groups":"[]","zigbee2mqtt/bridge/info":"{\u0022commit\u0022:\u0022f2e39af1\u0022,\u0022config\u0022:{\u0022advanced\u0022:{\u0022adapter_concurrent\u0022:null,\u0022adapter_delay\u0022:null,\u0022availability_blacklist\u0022:[],\u0022availability_blocklist\u0022:[],\u0022availability_passlist\u0022:[],\u0022availability_timeout\u0022:0,\u0022availability_whitelist\u0022:[],\u0022cache_state\u0022:true,\u0022cache_state_persistent\u0022:true,\u0022cache_state_send_on_startup\u0022:true,\u0022channel\u0022:11,\u0022elapsed\u0022:false,\u0022ext_pan_id\u0022:[221,221,221,221,221,221,221,221],\u0022homeassistant_discovery_topic\u0022:\u0022homeassistant\u0022,\u0022homeassistant_legacy_triggers\u0022:true,\u0022homeassistant_status_topic\u0022:\u0022hass/status\u0022,\u0022last_seen\u0022:\u0022disable\u0022,\u0022legacy_api\u0022:true,\u0022log_directory\u0022:\u0022/opt/zigbee2mqtt/data/log/%TIMESTAMP%\u0022,\u0022log_file\u0022:\u0022log.txt\u0022,\u0022log_level\u0022:\u0022info\u0022,\u0022log_output\u0022:[\u0022console\u0022,\u0022file\u0022],\u0022log_rotation\u0022:true,\u0022log_symlink_current\u0022:false,\u0022log_syslog\u0022:{},\u0022pan_id\u0022:58385,\u0022report\u0022:true,\u0022soft_reset_timeout\u0022:0,\u0022timestamp_format\u0022:\u0022YYYY-MM-DD HH:mm:ss\u0022},\u0022ban\u0022:[],\u0022blocklist\u0022:[],\u0022device_options\u0022:{},\u0022devices\u0022:{\u00220x00158d000669299c\u0022:{\u0022debounce\u0022:1,\u0022filtered_attributes\u0022:[],\u0022friendly_name\u0022:\u0022xi_sensor_contact_03\u0022,\u0022temperature_calibration\u0022:0,\u0022temperature_precision\u0022:{\u002210\u0022:1,\u002230\u0022:0}},\u00220x00158d000669348a\u0022:{\u0022debounce\u0022:1,\u0022friendly_name\u0022:\u0022xi_sensor_contact_04\u0022},\u00220x04cf8cdf3c7ca64e\u0022:{\u0022friendly_name\u0022:\u0022xi_sensor_light_02\u0022},\u00220x680ae2fffe1aa806\u0022:{\u0022debounce\u0022:0.2,\u0022debounce_ignore\u0022:[\u0022action\u0022,\u0022brightness\u0022],\u0022friendly_name\u0022:\u0022ik_remote_symfonisk_02\u0022}},\u0022experimental\u0022:{\u0022output\u0022:\u0022json\u0022},\u0022external_converters\u0022:[],\u0022frontend\u0022:{\u0022host\u0022:\u00220.0.0.0\u0022,\u0022port\u0022:8080},\u0022groups\u0022:{},\u0022homeassistant\u0022:false,\u0022map_options\u0022:{\u0022graphviz\u0022:{\u0022colors\u0022:{\u0022fill\u0022:{\u0022coordinator\u0022:\u0022#e04e5d\u0022,\u0022enddevice\u0022:\u0022#fff8ce\u0022,\u0022router\u0022:\u0022#4ea3e0\u0022},\u0022font\u0022:{\u0022coordinator\u0022:\u0022#ffffff\u0022,\u0022enddevice\u0022:\u0022#000000\u0022,\u0022router\u0022:\u0022#ffffff\u0022},\u0022line\u0022:{\u0022active\u0022:\u0022#009900\u0022,\u0022inactive\u0022:\u0022#994444\u0022}}}},\u0022mqtt\u0022:{\u0022base_topic\u0022:\u0022zigbee2mqtt\u0022,\u0022client_id\u0022:\u0022zigbee_general\u0022,\u0022force_disable_retain\u0022:false,\u0022include_device_information\u0022:false,\u0022server\u0022:\u0022mqtt://192.168.78.131\u0022,\u0022user\u0022:\u0022<user>\u0022},\u0022ota\u0022:{\u0022disable_automatic_update_check\u0022:false,\u0022update_check_interval\u0022:1440},\u0022passlist\u0022:[],\u0022permit_join\u0022:false,\u0022serial\u0022:{\u0022disable_led\u0022:false,\u0022port\u0022:\u0022/dev/ttyUSB0\u0022},\u0022whitelist\u0022:[]},\u0022config_schema\u0022:{\u0022definitions\u0022:{\u0022device\u0022:{\u0022properties\u0022:{\u0022debounce\u0022:{\u0022description\u0022:\u0022Debounces messages of this device\u0022,\u0022title\u0022:\u0022Debounce\u0022,\u0022type\u0022:\u0022number\u0022},\u0022debounce_ignore\u0022:{\u0022description\u0022:\u0022Protects unique payload values of specified payload properties from overriding within debounce time\u0022,\u0022examples\u0022:[\u0022action\u0022],\u0022items\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022title\u0022:\u0022Ignore debounce\u0022,\u0022type\u0022:\u0022array\u0022},\u0022filtered_attributes\u0022:{\u0022description\u0022:\u0022Allows to prevent certain attributes from being published\u0022,\u0022examples\u0022:[\u0022temperature\u0022,\u0022battery\u0022,\u0022action\u0022],\u0022items\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022title\u0022:\u0022Filtered attributes\u0022,\u0022type\u0022:\u0022array\u0022},\u0022friendly_name\u0022:{\u0022description\u0022:\u0022Used in the MQTT topic of a device. By default this is the device ID\u0022,\u0022readOnly\u0022:true,\u0022title\u0022:\u0022Friendly name\u0022,\u0022type\u0022:\u0022string\u0022},\u0022icon\u0022:{\u0022description\u0022:\u0022The user-defined device icon for the frontend. It can be a link to an image (not a path to a file) or base64 encoded data URL like: image/svg+xml;;base64,PHN2ZyB3aW....R0aD\u0022,\u0022title\u0022:\u0022Icon\u0022,\u0022type\u0022:\u0022string\u0022},\u0022optimistic\u0022:{\u0022description\u0022:\u0022Publish optimistic state after set (default true)\u0022,\u0022title\u0022:\u0022Optimistic\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022qos\u0022:{\u0022descritption\u0022:\u0022QoS level for MQTT messages of this device\u0022,\u0022title\u0022:\u0022QoS\u0022,\u0022type\u0022:\u0022number\u0022},\u0022retain\u0022:{\u0022description\u0022:\u0022Retain MQTT messages of this device\u0022,\u0022title\u0022:\u0022Retain\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022retention\u0022:{\u0022description\u0022:\u0022Sets the MQTT Message Expiry in seconds, Make sure to set mqtt.version to 5\u0022,\u0022title\u0022:\u0022Retention\u0022,\u0022type\u0022:\u0022number\u0022}},\u0022required\u0022:[\u0022friendly_name\u0022],\u0022type\u0022:\u0022object\u0022},\u0022group\u0022:{\u0022properties\u0022:{\u0022devices\u0022:{\u0022items\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022type\u0022:\u0022array\u0022},\u0022filtered_attributes\u0022:{\u0022items\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022type\u0022:\u0022array\u0022},\u0022friendly_name\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022optimistic\u0022:{\u0022type\u0022:\u0022boolean\u0022},\u0022qos\u0022:{\u0022type\u0022:\u0022number\u0022},\u0022retain\u0022:{\u0022type\u0022:\u0022boolean\u0022}},\u0022required\u0022:[\u0022friendly_name\u0022],\u0022type\u0022:\u0022object\u0022}},\u0022properties\u0022:{\u0022advanced\u0022:{\u0022properties\u0022:{\u0022adapter_concurrent\u0022:{\u0022description\u0022:\u0022Adapter concurrency (e.g. 2 for CC2531 or 16 for CC26X2R1) (default: null, uses recommended value)\u0022,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Adapter concurrency\u0022,\u0022type\u0022:[\u0022number\u0022,\u0022null\u0022]},\u0022adapter_delay\u0022:{\u0022description\u0022:\u0022Adapter delay\u0022,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Adapter delay\u0022,\u0022type\u0022:[\u0022number\u0022,\u0022null\u0022]},\u0022availability_blacklist\u0022:{\u0022items\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022readOnly\u0022:true,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Availability blacklist (deprecated, use availability_blocklist)\u0022,\u0022type\u0022:\u0022array\u0022},\u0022availability_blocklist\u0022:{\u0022description\u0022:\u0022Prevent devices from being checked for availability\u0022,\u0022items\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Availability Blocklist\u0022,\u0022type\u0022:\u0022array\u0022},\u0022availability_passlist\u0022:{\u0022description\u0022:\u0022Only enable availability check for certain devices\u0022,\u0022items\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Availability passlist\u0022,\u0022type\u0022:\u0022array\u0022},\u0022availability_timeout\u0022:{\u0022default\u0022:0,\u0022description\u0022:\u0022Availability timeout in seconds when enabled, devices will be checked if they are still online. Only AC powered routers are checked for availability\u0022,\u0022minimum\u0022:0,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Availability Timeout\u0022,\u0022type\u0022:\u0022number\u0022},\u0022availability_whitelist\u0022:{\u0022items\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022readOnly\u0022:true,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Availability whitelist (deprecated, use passlist)\u0022,\u0022type\u0022:\u0022array\u0022},\u0022baudrate\u0022:{\u0022description\u0022:\u0022Baud rate speed for serial port, this can be anything firmware support but default is 115200 for Z-Stack and EZSP, 38400 for Deconz, however note that some EZSP firmware need 57600\u0022,\u0022examples\u0022:[38400,57600,115200],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Baudrate\u0022,\u0022type\u0022:\u0022number\u0022},\u0022cache_state\u0022:{\u0022default\u0022:true,\u0022description\u0022:\u0022MQTT message payload will contain all attributes, not only changed ones. Has to be true when integrating via Home Assistant\u0022,\u0022title\u0022:\u0022Cache state\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022cache_state_persistent\u0022:{\u0022default\u0022:true,\u0022description\u0022:\u0022Persist cached state, only used when cache_state: true\u0022,\u0022title\u0022:\u0022Persist cache state\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022cache_state_send_on_startup\u0022:{\u0022default\u0022:true,\u0022description\u0022:\u0022Send cached state on startup, only used when cache_state: true\u0022,\u0022title\u0022:\u0022Send cached state on startup\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022channel\u0022:{\u0022default\u0022:11,\u0022description\u0022:\u0022Zigbee channel, changing requires repairing all devices! (Note: use a ZLL channel: 11, 15, 20, or 25 to avoid Problems)\u0022,\u0022examples\u0022:[11,15,20,25],\u0022maximum\u0022:26,\u0022minimum\u0022:11,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022ZigBee channel\u0022,\u0022type\u0022:\u0022number\u0022},\u0022elapsed\u0022:{\u0022default\u0022:false,\u0022description\u0022:\u0022Add an elapsed attribute to MQTT messages, contains milliseconds since the previous msg\u0022,\u0022title\u0022:\u0022Elapsed\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022ext_pan_id\u0022:{\u0022description\u0022:\u0022Zigbee extended pan ID, changing requires repairing all devices!\u0022,\u0022items\u0022:{\u0022type\u0022:\u0022number\u0022},\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Ext Pan ID\u0022,\u0022type\u0022:\u0022array\u0022},\u0022homeassistant_discovery_topic\u0022:{\u0022description\u0022:\u0022Home Assistant discovery topic\u0022,\u0022examples\u0022:[\u0022homeassistant\u0022],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Homeassistant discovery topic\u0022,\u0022type\u0022:\u0022string\u0022},\u0022homeassistant_legacy_triggers\u0022:{\u0022default\u0022:true,\u0022description\u0022:\u0022Home Assistant legacy triggers, when enabled Zigbee2mqt will send an empty 'action' or 'click' after one has been send. A 'sensor_action' and 'sensor_click' will be discoverd\u0022,\u0022title\u0022:\u0022Home Assistant legacy triggers\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022homeassistant_status_topic\u0022:{\u0022description\u0022:\u0022Home Assistant status topic\u0022,\u0022examples\u0022:[\u0022homeassistant/status\u0022],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Home Assistant status topic\u0022,\u0022type\u0022:\u0022string\u0022},\u0022ikea_ota_use_test_url\u0022:{\u0022default\u0022:false,\u0022description\u0022:\u0022Use IKEA TRADFRI OTA test server, see OTA updates documentation\u0022,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022IKEA TRADFRI OTA use test url\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022last_seen\u0022:{\u0022default\u0022:\u0022disable\u0022,\u0022description\u0022:\u0022Add a last_seen attribute to MQTT messages, contains date/time of last Zigbee message\u0022,\u0022enum\u0022:[\u0022disable\u0022,\u0022ISO_8601\u0022,\u0022ISO_8601_local\u0022,\u0022epoch\u0022],\u0022title\u0022:\u0022Last seen\u0022,\u0022type\u0022:\u0022string\u0022},\u0022legacy_api\u0022:{\u0022default\u0022:true,\u0022description\u0022:\u0022Disables the legacy api (false = disable)\u0022,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Legacy API\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022log_directory\u0022:{\u0022description\u0022:\u0022Location of log directory\u0022,\u0022examples\u0022:[\u0022data/log/%TIMESTAMP%\u0022],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Log directory\u0022,\u0022type\u0022:\u0022string\u0022},\u0022log_file\u0022:{\u0022default\u0022:\u0022log.txt\u0022,\u0022description\u0022:\u0022Log file name, can also contain timestamp\u0022,\u0022examples\u0022:[\u0022zigbee2mqtt_%TIMESTAMP%.log\u0022],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Log file\u0022,\u0022type\u0022:\u0022string\u0022},\u0022log_level\u0022:{\u0022default\u0022:\u0022info\u0022,\u0022description\u0022:\u0022Logging level\u0022,\u0022enum\u0022:[\u0022info\u0022,\u0022warn\u0022,\u0022error\u0022,\u0022debug\u0022],\u0022title\u0022:\u0022Log level\u0022,\u0022type\u0022:\u0022string\u0022},\u0022log_output\u0022:{\u0022description\u0022:\u0022Output location of the log, leave empty to supress logging\u0022,\u0022items\u0022:{\u0022enum\u0022:[\u0022console\u0022,\u0022file\u0022,\u0022syslog\u0022],\u0022type\u0022:\u0022string\u0022},\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Log output\u0022,\u0022type\u0022:\u0022array\u0022},\u0022log_rotation\u0022:{\u0022default\u0022:true,\u0022description\u0022:\u0022Log rotation\u0022,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Log rotation\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022log_symlink_current\u0022:{\u0022default\u0022:false,\u0022description\u0022:\u0022Create symlink to current logs in the log directory\u0022,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Log symlink current\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022log_syslog\u0022:{\u0022properties\u0022:{\u0022app_name\u0022:{\u0022default\u0022:\u0022Zigbee2MQTT\u0022,\u0022description\u0022:\u0022The name of the application (Default: Zigbee2MQTT).\u0022,\u0022title\u0022:\u0022Localhost\u0022,\u0022type\u0022:\u0022string\u0022},\u0022eol\u0022:{\u0022default\u0022:\u0022/n\u0022,\u0022description\u0022:\u0022The end of line character to be added to the end of the message (Default: Message without modifications).\u0022,\u0022title\u0022:\u0022eol\u0022,\u0022type\u0022:\u0022string\u0022},\u0022host\u0022:{\u0022default\u0022:\u0022localhost\u0022,\u0022description\u0022:\u0022The host running syslogd, defaults to localhost.\u0022,\u0022title\u0022:\u0022Host\u0022,\u0022type\u0022:\u0022string\u0022},\u0022localhost\u0022:{\u0022default\u0022:\u0022localhost\u0022,\u0022description\u0022:\u0022Host to indicate that log messages are coming from (Default: localhost).\u0022,\u0022title\u0022:\u0022Localhost\u0022,\u0022type\u0022:\u0022string\u0022},\u0022path\u0022:{\u0022default\u0022:\u0022/dev/log\u0022,\u0022description\u0022:\u0022The path to the syslog dgram socket (i.e. /dev/log or /var/run/syslog for OS X).\u0022,\u0022examples\u0022:[\u0022/dev/log\u0022,\u0022/var/run/syslog\u0022],\u0022title\u0022:\u0022Path\u0022,\u0022type\u0022:\u0022string\u0022},\u0022pid\u0022:{\u0022default\u0022:\u0022process.pid\u0022,\u0022description\u0022:\u0022PID of the process that log messages are coming from (Default process.pid).\u0022,\u0022title\u0022:\u0022PID\u0022,\u0022type\u0022:\u0022string\u0022},\u0022port\u0022:{\u0022default\u0022:123,\u0022description\u0022:\u0022The port on the host that syslog is running on, defaults to syslogd's default port.\u0022,\u0022title\u0022:\u0022Port\u0022,\u0022type\u0022:\u0022number\u0022},\u0022protocol\u0022:{\u0022default\u0022:\u0022tcp4\u0022,\u0022description\u0022:\u0022The network protocol to log over (e.g. tcp4, udp4, tls4, unix, unix-connect, etc).\u0022,\u0022examples\u0022:[\u0022tcp4\u0022,\u0022udp4\u0022,\u0022tls4\u0022,\u0022unix\u0022,\u0022unix-connect\u0022],\u0022title\u0022:\u0022Protocol\u0022,\u0022type\u0022:\u0022string\u0022},\u0022type\u0022:{\u0022default\u0022:\u00225424\u0022,\u0022description\u0022:\u0022The type of the syslog protocol to use (Default: BSD, also valid: 5424).\u0022,\u0022title\u0022:\u0022Type\u0022,\u0022type\u0022:\u0022string\u0022}},\u0022title\u0022:\u0022syslog\u0022,\u0022type\u0022:\u0022object\u0022},\u0022network_key\u0022:{\u0022description\u0022:\u0022Network encryption key, changing requires repairing all devices!\u0022,\u0022oneOf\u0022:[{\u0022title\u0022:\u0022Network key(string)\u0022,\u0022type\u0022:\u0022string\u0022},{\u0022items\u0022:{\u0022type\u0022:\u0022number\u0022},\u0022title\u0022:\u0022Network key(array)\u0022,\u0022type\u0022:\u0022array\u0022}],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Network key\u0022},\u0022pan_id\u0022:{\u0022description\u0022:\u0022ZigBee pan ID, changing requires repairing all devices!\u0022,\u0022oneOf\u0022:[{\u0022title\u0022:\u0022Pan ID (string)\u0022,\u0022type\u0022:\u0022string\u0022},{\u0022title\u0022:\u0022Pan ID (number)\u0022,\u0022type\u0022:\u0022number\u0022}],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Pan ID\u0022},\u0022report\u0022:{\u0022description\u0022:\u0022Enables report feature (deprecated)\u0022,\u0022readOnly\u0022:true,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Reporting\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022rtscts\u0022:{\u0022description\u0022:\u0022RTS / CTS Hardware Flow Control for serial port\u0022,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022RTS / CTS\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022soft_reset_timeout\u0022:{\u0022description\u0022:\u0022Soft reset ZNP after timeout\u0022,\u0022minimum\u0022:0,\u0022readOnly\u0022:true,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Soft reset timeout (deprecated)\u0022,\u0022type\u0022:\u0022number\u0022},\u0022timestamp_format\u0022:{\u0022description\u0022:\u0022Log timestamp format\u0022,\u0022examples\u0022:[\u0022YYYY-MM-DD HH:mm:ss\u0022],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Timestamp format\u0022,\u0022type\u0022:\u0022string\u0022}},\u0022title\u0022:\u0022Advanced\u0022,\u0022type\u0022:\u0022object\u0022},\u0022ban\u0022:{\u0022items\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022readOnly\u0022:true,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Ban (deprecated, use blocklist)\u0022,\u0022type\u0022:\u0022array\u0022},\u0022blocklist\u0022:{\u0022description\u0022:\u0022Block devices from the network (by ieeeAddr)\u0022,\u0022items\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Blocklist\u0022,\u0022type\u0022:\u0022array\u0022},\u0022device_options\u0022:{\u0022type\u0022:\u0022object\u0022},\u0022devices\u0022:{\u0022patternProperties\u0022:{\u0022^.*$\u0022:{\u0022$ref\u0022:\u0022#/definitions/device\u0022}},\u0022propertyNames\u0022:{\u0022pattern\u0022:\u0022^0x[\u005c\u005cd\u005c\u005cw]{16}$\u0022},\u0022type\u0022:\u0022object\u0022},\u0022experimental\u0022:{\u0022properties\u0022:{\u0022output\u0022:{\u0022description\u0022:\u0022Examples when 'state' of a device is published json: topic: 'zigbee2mqtt/my_bulb' payload '{\u005c\u0022state\u005c\u0022: \u005c\u0022ON\u005c\u0022}' attribute: topic 'zigbee2mqtt/my_bulb/state' payload 'ON' attribute_and_json: both json and attribute (see above)\u0022,\u0022enum\u0022:[\u0022attribute_and_json\u0022,\u0022attribute\u0022,\u0022json\u0022],\u0022title\u0022:\u0022MQTT output type\u0022,\u0022type\u0022:\u0022string\u0022},\u0022transmit_power\u0022:{\u0022description\u0022:\u0022Transmit power of adapter, only available for Z-Stack (CC253*/CC2652/CC1352) adapters, CC2652 = 5dbm, CC1352 max is = 20dbm (5dbm default)\u0022,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Transmit power\u0022,\u0022type\u0022:[\u0022number\u0022,\u0022null\u0022]}},\u0022title\u0022:\u0022Experimental\u0022,\u0022type\u0022:\u0022object\u0022},\u0022external_converters\u0022:{\u0022description\u0022:\u0022You can define external converters to e.g. add support for a DiY device\u0022,\u0022examples\u0022:[\u0022DIYRuZ_FreePad.js\u0022],\u0022items\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022External converters\u0022,\u0022type\u0022:\u0022array\u0022},\u0022frontend\u0022:{\u0022properties\u0022:{\u0022auth_token\u0022:{\u0022description\u0022:\u0022Enables authentication, disabled by default\u0022,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Auth token\u0022,\u0022type\u0022:[\u0022string\u0022,\u0022null\u0022]},\u0022host\u0022:{\u0022default\u0022:\u0022 0.0.0.0\u0022,\u0022description\u0022:\u0022Frontend binding host\u0022,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Bind host\u0022,\u0022type\u0022:\u0022string\u0022},\u0022port\u0022:{\u0022default\u0022:8080,\u0022description\u0022:\u0022Frontend binding port\u0022,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Port\u0022,\u0022type\u0022:\u0022number\u0022}},\u0022title\u0022:\u0022Frontend\u0022,\u0022type\u0022:\u0022object\u0022},\u0022groups\u0022:{\u0022patternProperties\u0022:{\u0022^.*$\u0022:{\u0022$ref\u0022:\u0022#/definitions/group\u0022}},\u0022propertyNames\u0022:{\u0022pattern\u0022:\u0022^[\u005c\u005cw].*$\u0022},\u0022type\u0022:\u0022object\u0022},\u0022homeassistant\u0022:{\u0022default\u0022:false,\u0022description\u0022:\u0022Home Assistant integration (MQTT discovery)\u0022,\u0022title\u0022:\u0022Home Assistant integration\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022map_options\u0022:{\u0022properties\u0022:{\u0022graphviz\u0022:{\u0022properties\u0022:{\u0022colors\u0022:{\u0022properties\u0022:{\u0022fill\u0022:{\u0022properties\u0022:{\u0022coordinator\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022enddevice\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022router\u0022:{\u0022type\u0022:\u0022string\u0022}},\u0022type\u0022:\u0022object\u0022},\u0022font\u0022:{\u0022properties\u0022:{\u0022coordinator\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022enddevice\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022router\u0022:{\u0022type\u0022:\u0022string\u0022}},\u0022type\u0022:\u0022object\u0022},\u0022line\u0022:{\u0022properties\u0022:{\u0022active\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022inactive\u0022:{\u0022type\u0022:\u0022string\u0022}},\u0022type\u0022:\u0022object\u0022}},\u0022type\u0022:\u0022object\u0022}},\u0022type\u0022:\u0022object\u0022}},\u0022title\u0022:\u0022Networkmap\u0022,\u0022type\u0022:\u0022object\u0022},\u0022mqtt\u0022:{\u0022properties\u0022:{\u0022base_topic\u0022:{\u0022description\u0022:\u0022MQTT base topic for Zigbee2MQTT MQTT messages\u0022,\u0022examples\u0022:[\u0022zigbee2mqtt\u0022],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Base topic\u0022,\u0022type\u0022:\u0022string\u0022},\u0022ca\u0022:{\u0022description\u0022:\u0022Absolute path to SSL/TLS certificate of CA used to sign server and client certificates\u0022,\u0022examples\u0022:[\u0022/etc/ssl/mqtt-ca.crt\u0022],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Certificate authority\u0022,\u0022type\u0022:\u0022string\u0022},\u0022cert\u0022:{\u0022description\u0022:\u0022Absolute path to SSL/TLS certificate for client-authentication\u0022,\u0022examples\u0022:[\u0022/etc/ssl/mqtt-client.crt\u0022],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022SSL/TLS certificate\u0022,\u0022type\u0022:\u0022string\u0022},\u0022client_id\u0022:{\u0022description\u0022:\u0022MQTT client ID\u0022,\u0022examples\u0022:[\u0022MY_CLIENT_ID\u0022],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Client ID\u0022,\u0022type\u0022:\u0022string\u0022},\u0022force_disable_retain\u0022:{\u0022default\u0022:false,\u0022description\u0022:\u0022Disable retain for all send messages. ONLY enable if you MQTT broker doesn't support retained message (e.g. AWS IoT core, Azure IoT Hub, Google Cloud IoT core, IBM Watson IoT Platform). Enabling will break the Home Assistant integration\u0022,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Force disable retain\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022include_device_information\u0022:{\u0022default\u0022:false,\u0022description\u0022:\u0022Include device information to mqtt messages\u0022,\u0022title\u0022:\u0022Include device information\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022keepalive\u0022:{\u0022default\u0022:60,\u0022description\u0022:\u0022MQTT keepalive in second\u0022,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Keepalive\u0022,\u0022type\u0022:\u0022number\u0022},\u0022key\u0022:{\u0022description\u0022:\u0022Absolute path to SSL/TLS key for client-authentication\u0022,\u0022examples\u0022:[\u0022/etc/ssl/mqtt-client.key\u0022],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022SSL/TLS key\u0022,\u0022type\u0022:\u0022string\u0022},\u0022password\u0022:{\u0022description\u0022:\u0022MQTT server authentication password\u0022,\u0022examples\u0022:[\u0022ILOVEPELMENI\u0022],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Password\u0022,\u0022type\u0022:\u0022string\u0022},\u0022reject_unauthorized\u0022:{\u0022default\u0022:true,\u0022description\u0022:\u0022Disable self-signed SSL certificate\u0022,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Reject unauthorized\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022server\u0022:{\u0022description\u0022:\u0022MQTT server URL (use mqtts:// for SSL/TLS connection)\u0022,\u0022examples\u0022:[\u0022mqtt://localhost:1883\u0022],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022MQTT server\u0022,\u0022type\u0022:\u0022string\u0022},\u0022user\u0022:{\u0022description\u0022:\u0022MQTT server authentication user\u0022,\u0022examples\u0022:[\u0022johnnysilverhand\u0022],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022User\u0022,\u0022type\u0022:\u0022string\u0022},\u0022version\u0022:{\u0022default\u0022:4,\u0022description\u0022:\u0022MQTT protocol version\u0022,\u0022examples\u0022:[4,5],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Version\u0022,\u0022type\u0022:[\u0022number\u0022,\u0022null\u0022]}},\u0022required\u0022:[\u0022base_topic\u0022,\u0022server\u0022],\u0022title\u0022:\u0022MQTT\u0022,\u0022type\u0022:\u0022object\u0022},\u0022ota\u0022:{\u0022properties\u0022:{\u0022disable_automatic_update_check\u0022:{\u0022default\u0022:false,\u0022description\u0022:\u0022Zigbee devices may request a firmware update, and do so frequently, causing Zigbee2MQTT to reach out to third party servers. If you disable these device initiated checks, you can still initiate a firmware update check manually.\u0022,\u0022title\u0022:\u0022Disable automatic update check\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022update_check_interval\u0022:{\u0022default\u0022:1440,\u0022description\u0022:\u0022Your device may request a check for a new firmware update. This value determines how frequently third party servers may actually be contacted to look for firmware updates. The value is set in minutes, and the default is 1 day.\u0022,\u0022title\u0022:\u0022Update check interval\u0022,\u0022type\u0022:\u0022number\u0022}},\u0022title\u0022:\u0022OTA updates\u0022,\u0022type\u0022:\u0022object\u0022},\u0022passlist\u0022:{\u0022description\u0022:\u0022Allow only certain devices to join the network (by ieeeAddr). Note that all devices not on the passlist will be removed from the network!\u0022,\u0022items\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Passlist\u0022,\u0022type\u0022:\u0022array\u0022},\u0022permit_join\u0022:{\u0022default\u0022:false,\u0022description\u0022:\u0022Allow new devices to join (re-applied at restart)\u0022,\u0022title\u0022:\u0022Permit join\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022serial\u0022:{\u0022properties\u0022:{\u0022adapter\u0022:{\u0022description\u0022:\u0022Adapter type, not needed unless you are experiencing problems\u0022,\u0022enum\u0022:[\u0022deconz\u0022,\u0022zstack\u0022,\u0022zigate\u0022,\u0022ezsp\u0022],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Adapter\u0022,\u0022type\u0022:[\u0022string\u0022,\u0022null\u0022]},\u0022disable_led\u0022:{\u0022default\u0022:false,\u0022description\u0022:\u0022Disable LED of the adapter if supported\u0022,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Disable led\u0022,\u0022type\u0022:\u0022boolean\u0022},\u0022port\u0022:{\u0022description\u0022:\u0022Location of the adapter. To autodetect the port, set null\u0022,\u0022examples\u0022:[\u0022/dev/ttyACM0\u0022],\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Port\u0022,\u0022type\u0022:[\u0022string\u0022,\u0022null\u0022]}},\u0022title\u0022:\u0022Serial\u0022,\u0022type\u0022:\u0022object\u0022},\u0022whitelist\u0022:{\u0022items\u0022:{\u0022type\u0022:\u0022string\u0022},\u0022readOnly\u0022:true,\u0022requiresRestart\u0022:true,\u0022title\u0022:\u0022Whitelist (deprecated, use passlist)\u0022,\u0022type\u0022:\u0022array\u0022}},\u0022required\u0022:[\u0022mqtt\u0022],\u0022type\u0022:\u0022object\u0022},\u0022coordinator\u0022:{\u0022meta\u0022:{\u0022maintrel\u0022:1,\u0022majorrel\u0022:2,\u0022minorrel\u0022:7,\u0022product\u0022:1,\u0022revision\u0022:20210120,\u0022transportrev\u0022:2},\u0022type\u0022:\u0022zStack3x0\u0022},\u0022log_level\u0022:\u0022info\u0022,\u0022network\u0022:{\u0022channel\u0022:11,\u0022extended_pan_id\u0022:\u00220xdddddddddddddddd\u0022,\u0022pan_id\u0022:58385},\u0022permit_join\u0022:false,\u0022restart_required\u0022:false,\u0022version\u0022:\u00221.18.3\u0022}","zigbee2mqtt/bridge/state":"online"}
setstate MQTT2_SERVER 2021-05-12 15:38:31 nrclients 1
setstate MQTT2_SERVER 2021-05-12 14:52:20 state Initialized

MQTT2_DEVICE (attrTemplate zigbee2mqtt_bridge)
define MQTT2_zigbee_general MQTT2_DEVICE zigbee_general
attr MQTT2_zigbee_general DbLogExclude .*
attr MQTT2_zigbee_general bridgeRegexp zigbee2mqtt/([A-Za-z0-9._]+)[/]?.*:.* "zigbee_$1"
attr MQTT2_zigbee_general comment To check for new updates of the deamon software, you might want to use a separate HTTPMOD device. See HTTPMOD template zigbee2mqtt_daemon_updates for further details.
attr MQTT2_zigbee_general devicetopic zigbee2mqtt
attr MQTT2_zigbee_general getList devicelist:noArg log $DEVICETOPIC/bridge/config/devices/get\
  networkmap_raw:noArg raw $DEVICETOPIC/bridge/networkmap raw\
  networkmap_graphviz:noArg graphviz $DEVICETOPIC/bridge/networkmap graphviz
attr MQTT2_zigbee_general icon mqtt
attr MQTT2_zigbee_general model zigbee2mqtt_bridge
attr MQTT2_zigbee_general readingList $DEVICETOPIC/bridge/state:.* state\
  $DEVICETOPIC/bridge/config/devices:.* {}\
  $DEVICETOPIC/bridge/config/log_level:.* log_level\
  $DEVICETOPIC/bridge/config/permit_join:.* permit_join\
  $DEVICETOPIC/bridge/config/rename:.* { json2nameValue($EVENT, 'rename_') }\
  $DEVICETOPIC/bridge/log:.*\"type\".\"devices\".\"message\".* devices\
  $DEVICETOPIC/bridge/log:.* log\
  $DEVICETOPIC/bridge/networkmap:.* {}\
  $DEVICETOPIC/bridge/networkmap/graphviz:.* graphviz\
  $DEVICETOPIC/bridge/networkmap/raw:.* raw\
  $DEVICETOPIC/bridge/config:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_general room MQTT2_DEVICE
attr MQTT2_zigbee_general setList log_level:debug,info,warn,error $DEVICETOPIC/bridge/config/log_level $EVTPART1\
  permit_join:true,false $DEVICETOPIC/bridge/config/permit_join $EVTPART1\
  remove:textField $DEVICETOPIC/bridge/config/remove $EVTPART1\
  ota_update:textField $DEVICETOPIC/bridge/ota_update/update $EVTPART1\
  ota_update_check:textField $DEVICETOPIC/bridge/ota_update/check $EVTPART1\
  y_device_setting:textField $DEVICETOPIC/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}\
  x_bind:textField $DEVICETOPIC/bridge/bind/$EVTPART1 $EVTPART2\
  x_bind_unbind:textField $DEVICETOPIC/bridge/unbind/$EVTPART1 $EVTPART2\
  x_device_options:textField $DEVICETOPIC/bridge/config/device_options {"friendly_name":"$EVTPART1","options": {"$EVTPART2": "$EVTPART3"}}\
  x_group_add_to:textField $DEVICETOPIC/bridge/group/$EVTPART1/add $EVTPART2\
  x_group_rm_from:textField $DEVICETOPIC/bridge/group/$EVTPART1/remove $EVTPART2\
  x_group_rm_from_all:textField $DEVICETOPIC/bridge/group/$EVTPART1/remove_all $EVTPART2\
  x_group_add_group:textField $DEVICETOPIC/bridge/config/add_group $EVTPART1\
  x_group_rm_group:textField $DEVICETOPIC/bridge/config/remove_group $EVTPART1\
  z_elapsed:textField $DEVICETOPIC/bridge/config/elapsed $EVTPART1\
  z_last_seen:disable,ISO_8601,epoch,ISO_8601_local $DEVICETOPIC/bridge/config/last_seen $EVTPART1\
  z_ban:textField $DEVICETOPIC/bridge/config/ban $EVTPART1\
  z_rename:textField $DEVICETOPIC/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}\
  z_reset_CC:noArg $DEVICETOPIC/bridge/config/reset
attr MQTT2_zigbee_general setStateList on off

setstate MQTT2_zigbee_general online
setstate MQTT2_zigbee_general 2021-05-12 16:52:58 attrTemplateVersion 20201215
setstate MQTT2_zigbee_general 2021-05-12 17:42:00 log {"message":[{"dateCode":"20210120","friendly_name":"Coordinator","ieeeAddr":"0x00124b00214f3bc4","lastSeen":1620834120086,"networkAddress":0,"softwareBuildID":"zStack3x0","type":"Coordinator"},{"dateCode":"20161128","description":"Aqara door & window contact sensor","friendly_name":"xi_sensor_contact_03","hardwareVersion":2,"ieeeAddr":"0x00158d000669299c","lastSeen":1620831194167,"manufacturerID":4151,"manufacturerName":"LUMI","model":"MCCGQ11LM","modelID":"lumi.sensor_magnet.aq2","networkAddress":26209,"powerSource":"Battery","softwareBuildID":"3000-0001","type":"EndDevice","vendor":"Xiaomi"},{"description":"Aqara door & window contact sensor","friendly_name":"xi_sensor_contact_04","ieeeAddr":"0x00158d000669348a","lastSeen":1620833083573,"manufacturerID":4151,"manufacturerName":"LUMI","model":"MCCGQ11LM","modelID":"lumi.sensor_magnet.aq2","networkAddress":3822,"powerSource":"Battery","type":"EndDevice","vendor":"Xiaomi"},{"dateCode":"20190710","description":"SYMFONISK sound controller","friendly_name":"ik_remote_symfonisk_02","hardwareVersion":1,"ieeeAddr":"0x680ae2fffe1aa806","lastSeen":1620805490206,"manufacturerID":4476,"manufacturerName":"IKEA of Sweden","model":"E1744","modelID":"SYMFONISK Sound Controller","networkAddress":1941,"powerSource":"Battery","softwareBuildID":"2.1.024","type":"EndDevice","vendor":"IKEA"},{"dateCode":"20191118","description":"MiJia light intensity sensor","friendly_name":"xi_sensor_light_02","hardwareVersion":1,"ieeeAddr":"0x04cf8cdf3c7ca64e","lastSeen":1620833708690,"manufacturerID":4718,"manufacturerName":"LUMI","model":"GZCGQ01LM","modelID":"lumi.sen_ill.mgl01","networkAddress":39578,"powerSource":"Battery","softwareBuildID":"2019\u0000www.","type":"EndDevice","vendor":"Xiaomi"}],"type":"devices"}
setstate MQTT2_zigbee_general 2021-05-12 19:05:42 subscriptions zigbee2mqtt/#

Beispielhaft noch ein Sensor
MQTT2_DEVICE (attrTemplate zigbee2mqtt_Light_Intensity_Sensor)
define MQTT2_zigbee_xi_sensor_light_02 MQTT2_DEVICE zigbee_xi_sensor_light_02
attr MQTT2_zigbee_xi_sensor_light_02 DbLogExclude .*
attr MQTT2_zigbee_xi_sensor_light_02 devicetopic zigbee2mqtt/xi_sensor_light_02
attr MQTT2_zigbee_xi_sensor_light_02 model zigbee2mqtt_Light_Intensity_Sensor
attr MQTT2_zigbee_xi_sensor_light_02 readingList $DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr MQTT2_zigbee_xi_sensor_light_02 room MQTT2_DEVICE
attr MQTT2_zigbee_xi_sensor_light_02 stateFormat Lux: illuminance_lux Luminance: illuminance

setstate MQTT2_zigbee_xi_sensor_light_02 Lux: 10266 Luminance: 40115
setstate MQTT2_zigbee_xi_sensor_light_02 2021-05-12 16:55:06 associatedWith MQTT2_zigbee_general
setstate MQTT2_zigbee_xi_sensor_light_02 2021-05-12 16:56:10 attrTemplateVersion 20200904
setstate MQTT2_zigbee_xi_sensor_light_02 2021-05-13 08:31:36 battery 100
setstate MQTT2_zigbee_xi_sensor_light_02 2021-05-13 08:31:36 illuminance 40115
setstate MQTT2_zigbee_xi_sensor_light_02 2021-05-13 08:31:36 illuminance_lux 10266
setstate MQTT2_zigbee_xi_sensor_light_02 2021-05-13 08:31:36 linkquality 111
setstate MQTT2_zigbee_xi_sensor_light_02 2021-05-13 08:31:36 voltage 3100
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 13 Mai 2021, 10:27:52
Das "logging"-Device sieht mir nach einem "Irrläufer" beim "brücken" aus, vermutlich sollte einfach die readingList von "MQTT2_zigbee_general" angepasst werden und der Topic da reingeschrieben werden.
Wenn das (neuerdings?) per default kommt oder "log" umbenannt wurde, kann ich das gerne am "bridge"-attrTemplate anpassen, dann paßt es wieder für alle Neueinsteiger.
(ich vermute, die erfahreneren Nutzer haben das einfach so gemacht, und es hat sich daher eben noch niemand hier wegen der Korrektur gemeldet...)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: hydrotec am 13 Mai 2021, 11:43:58
@Beta-User

Dankeschön für die schnelle Rückmeldung.

Der von mir beschriebene Weg (https://forum.fhem.de/index.php/topic,94494.msg1156128.html#msg1156128) ist eine Erstinstallation, ohne irgendetwas umbenannt zu haben.

Zitat
..., kann ich das gerne am "bridge"-attrTemplate anpassen, dann paßt es wieder für alle Neueinsteiger.
würde ich befürworten.
Ist nicht weiter dramatisch, funktioniert ja alles wie es soll.
Doch für Neueinsteiger (wie mich  ;)) ist es etwas verwirrend.

Ansonsten noch einen schönen Feiertag  8)

Gruß, Karsten
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 21 Mai 2021, 07:57:27
In MQTT2 für Xiaomi Vacuum Sauger (https://forum.fhem.de/index.php/topic,121017.0.html) sind ein paar Fragen aufgetaucht, zu denen ich mangels Hardware konkret relativ wenig sagen kann. Daher an dieser Stelle einfach ein paar allgemeine Anmerkungen, falls jemand was spezifischer interessiert, sollte man diese Themen ggf. in einem gesonderten Thread vertiefen.

Die Fragestellungen, die bei mir angekommen sind:
a) Wie ist das mit "filter:", wenn man zunächst eine readingList-Auswertung hat, die aber hinterher (nach der ersten Anwendung eines attrTemplate) nicht mehr klappt, weil in der readingList dann $DEVICETOPIC steht.
Die Werte nach "filter:" sind devspec, es sollte also ohne weiteres gehen, Alternativen per Komma zu trennen (zur Prüfung: list verwenden). Im konkreten Fall würde ich dabei als 1. match-Möglichkeit (wie gehabt) gegen das readingList-Attribut prüfen und dann ergänzend die 2. match-Möglichkeit gegen das Attribut devicetopic.

Bei den "gebrückten" zigbee2mqtt-Geräten wird das etwas anders gehandhabt, das hat aber damit zu tun, dass die CID dort in den wesentlichen Teilen "bekannt" ist.

b) Handhabung von "verwandten Geräten" - myUtils, Readings usw.:
(So ganz habe ich nicht verstanden, um was es geht)
- Tendenziell wäre es klasse, wenn man zwei unterschiedliche Geräte mit demselben Zweck (z.B. Saugrobis) am Ende (ziemlich) einheitlich gestalten könnte, was Reading- und Setternamen angeht (und ggf. jemand den Job übernehmen würde, da sinnvolle "internationale" (!) Namen zu vergeben/vorzuschlagen.
- die myUtils dazu würde ich tendenziell zusammenführen und versuchen, die jeweiligen Funktionsaufrufe einheitlich zu gestalten. Wenn man da intern "Kenner" oder Marker braucht, um unterschiedliche Typen zu unterscheiden, kann man entweder Readings auswerten (so vorhanden, optimalerweise vom Robi kommend), oder man setzt notfalls - neben dem "model"-Attribut, das immer vorhanden ist - weitere userattr (z.B. subType).

Meine persönliche Wunschvorstellung: Am Ende hat man eine Art "Weather"-Modul, bei der jeweils halt eine andere API im Hintergrund werkelt, aber das Ergebnis sieht (fast) identisch aus...
(die diversen "Thermostate" in den templates kommen dem vermutlich am nächsten, aber z.B. auch ein MQTT-Relay sieht "gleich" aus, egal ob Shelly-firmware oder Tasmota, und die Funktionalität ist auch - soweit möglich - gleich).

c) "Rückwärtskompabilität"
Tendenziell würde ich da nicht zu viel Energie drauf verwenden. Wenn jemand das aktuelle template anwendet, bekommt er die zugehörige myUtils, und das muss eben zusammenpassen, fertig. (Es ist die Entscheidung des Anwenders, ob er überhaupt aktualisieren will, und was er bekommt, kann er (meistens) vorher sehen!).

"alte Funktionsaufrufe" kann man ja ggf. weiter erhalten und die in einen wrapper für die neuen umbauen - oder umgekehrt neue als wrapper für diverse Unterprogramme gestalten, was vermutlich in diesem Fall deutlich einfacher zu pflegen ist, weil dann die jeweiligen Unterprogramme leichter von denjenigen beigesteuert werden können, die die Hardware haben. (Diese myUtils würde ich tendenziell packagen!)

Als Muster für die myUtils (auch was gewisse Vorarbeiten für einheitliche Readingnamen (jsonmap für interne json2nameValue()-Aufrufe) angeht), wären in dem go-echarger-Thread (?) zu finden.

Hoffe, das abstrakte Geschreibsel ist ggf. hilfreich, ansonsten _glaube ich_, dass es sinnvoll wäre, Teilaspekte jeweils gesondert zu beleuchten, weil es allgemeine Fragestellungen sind.
Falls _wirklich_ konkretere Hilfe erbeten wird: Für mich als "Spielmaterial" hilfreich wären für den Fall der Fälle in jedem Fall "unbearbeitete" RAW-Definitionen der diversen Varianten sowie ggf. ein paar "typische" Topic/Messages, aus denen zu erkennen ist, welche Readings eigentlich (wann) woher kommen.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Ralli am 22 Mai 2021, 18:06:51
Beim Einrichten von Sonos über MQTT bin ich über ein kleines Problemchen gestoßen:

Für sonos2mqtt_bridge_comfort müssten die Zeile(n)

attr SonosBridge userReadings favlist:Favorites.* {sonos2mqtt_ur($name,'favlist')},\
grouplist:Favorites.* {sonos2mqtt_ur($name,'grouplist')}

ersetzt werden durch

attr DEVICE userReadings favlist:Favorites.* {sonos2mqtt_ur($name,'favlist')},\
grouplist:Favorites.* {sonos2mqtt_ur($name,'grouplist')}

da es ansonsten zu einem Fehler und einer nicht vollständigen Konfiguration kommt, wenn man das Bridge-Device nicht SonosBridge sondern bspw. MQTT2_SonosBridge benennt.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 22 Mai 2021, 18:59:40
Danke, hab's eingecheckt ;)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: darthi am 23 Mai 2021, 11:26:34
Hallo zusammen,

ich nutze für diverse Tasmota Steckdosen das Sonoff POW Template. Bisher wurde immer die Version 20200529 genutzt. Mit dieser hatte ich auch keine Probleme und alle Stats wurden korrekt angezeigt und ausgewertet.
Für Steckdosen, die ich gestern eingerichtet habe, passt das nun aber nicht mehr. Hier wird das Template 20210521 genutzt. Die Readings werden anscheinend nicht mehr korrekt übersetzt (siehe Screenshot). Die Steckdose mit korrekter Status-Anzeige ist eine mit altem Template und die ohne (auch ohne Uptime) eine mit neuem Template.
Wenn ich mit die Attribute der beiden Steckdosen anschaue, finde ich keinen nennenswerten Unterschied:

Template 20210521:
defmod Aquarium_CO2 MQTT2_DEVICE DVES_453530
attr Aquarium_CO2 alias Aquarium CO2
attr Aquarium_CO2 autocreate 0
attr Aquarium_CO2 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/Corn4/Backlog POWER1 1;; delay '.$duration.';; POWER1 0'}<br>See the "Praxisbeispiele" in the wiki for "pulseTime1" alternative option and it's restrictions.
attr Aquarium_CO2 devStateIcon {my $text = ' uptime: '.ReadingsVal($name,"Uptime","unknown").sprintf(" aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"));;;; my $onl = ReadingsVal($name,"LWT","false") eq "Online"?"10px-kreis-gruen":"10px-kreis-rot";;;; my $light = ReadingsVal($name,"state","off");;;;"<div><a href=\"http://".ReadingsVal($name,"IPAddress",ReadingsVal($name,"Info2_IPAddress","none"))." \"target=\"_blank\">".FW_makeImage($onl).'</a> <a href="/fhem?cmd.dummy=set '.$name.' toggle&XHR=1">'.FW_makeImage($light)."</a>$text"}
attr Aquarium_CO2 genericDeviceType switch
attr Aquarium_CO2 group Aquarium Nanocube
attr Aquarium_CO2 icon hue_filled_outlet
attr Aquarium_CO2 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 Aquarium_CO2 model tasmota_POW
attr Aquarium_CO2 readingList tele/Corn4/LWT:.* LWT\
  tele/Corn4/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/Corn4/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/Corn4/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/Corn4/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  stat/Corn4/POWER1:.* state\
  stat/Corn4/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr Aquarium_CO2 room Büro
attr Aquarium_CO2 setList off:noArg    cmnd/Corn4/POWER1 0\
  on:noArg     cmnd/Corn4/POWER1 1\
  toggle:noArg cmnd/Corn4/POWER1 2
attr Aquarium_CO2 setStateList on off toggle
attr Aquarium_CO2 stateFormat {sprintf("aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"))}
attr Aquarium_CO2 webCmd :

Template 20200529:
defmod Aquarium_Heizung MQTT2_DEVICE DVES_DBBDC1
attr Aquarium_Heizung IODev MQTT_Server
attr Aquarium_Heizung alias Aquarium Heizung
attr Aquarium_Heizung autocreate 0
attr Aquarium_Heizung 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/Gosund_Steckdose1/Backlog POWER1 1;; delay '.$duration.';; POWER1 0'}<br>See the "Praxisbeispiele" in the wiki for "pulseTime1" alternative option and it's restrictions.
attr Aquarium_Heizung devStateIcon {my $text = ' uptime: '.ReadingsVal($name,"Uptime","unknown").sprintf(" aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"));; my $onl = ReadingsVal($name,"LWT","false") eq "Online"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");;"<div><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>$text<b></b>"}
attr Aquarium_Heizung genericDeviceType switch
attr Aquarium_Heizung group Aquarium Nanocube
attr Aquarium_Heizung icon hue_filled_outlet
attr Aquarium_Heizung 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 Aquarium_Heizung model tasmota_POW
attr Aquarium_Heizung readingList tele/Gosund_Steckdose1/LWT:.* LWT\
  tele/Gosund_Steckdose1/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/Gosund_Steckdose1/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/Gosund_Steckdose1/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/Gosund_Steckdose1/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  stat/Gosund_Steckdose1/POWER1:.* state\
  stat/Gosund_Steckdose1/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr Aquarium_Heizung room Büro
attr Aquarium_Heizung setList off:noArg    cmnd/Gosund_Steckdose1/POWER1 0\
  on:noArg     cmnd/Gosund_Steckdose1/POWER1 1\
  toggle:noArg cmnd/Gosund_Steckdose1/POWER1 2
attr Aquarium_Heizung setStateList on off toggle
attr Aquarium_Heizung stateFormat {sprintf("aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"))}
attr Aquarium_Heizung webCmd :

Irgendeine Idee woran das liegen könnte? Er erkennt aus irgendwelchen Gründen auch das IODevice nicht automatisch. Wenn ich es manuell setze, macht es jedoch keinen Unterschied.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 23 Mai 2021, 13:57:52
Sind vermutlich zwei getrennte Themen:
a) Das mit IODev hat nichts mit attrTemplate zu tun, das Attribut wird einfach seit neuestem nicht mehr automatisch gesetzt: https://forum.fhem.de/index.php/topic,120603.0.html
Falls (!) du Probleme damit hast (also v.a. das Reading/Internal falsch gesetzt wird, was - wenn überhaupt - nur dann auftreten kann, wenn du mehrere passende IO's hast), bitte dazu einen neuen Thread aufmachen. (@Rudi, evtl. noch ein Fall, den man sich ansehen sollte: https://forum.fhem.de/index.php/topic,121213.0.html)

b) Ich _vermute_, du hast auch eine neue Tasmota-Version (9.4) geflasht, die etwas andere Infos an die INFO.-Topics sendet. Die readingList wird durch die neue Version leider nicht wie erhofft gesetzt, mir ist leider ausgerechnet das "Zentraltemplate" durchgerutscht. Habe das jetzt nachgeholt, wenn du magst, kannst du die aktuelle Fassung aus dem svn holen, sonst ab morgen per update.
Falls es weiter Probleme gibt, bitte ausnahmsweise dann ein list liefern, wir brauchen bestimmte Infos auch zu den Internals (und Readings), sonst ist es schwierig rauszufinden, wo das Problem ggf. noch steckt
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: darthi am 24 Mai 2021, 18:54:44
Dank dir für die schnelle Antwort. Die Readings passen, daher sollte das IODev keine Probleme machen.

Zum eigentlichen Problem: Du hast mit deiner Vermutung recht. :)
Verwende die aktuelle Tasmota 9.4 (bzw. 9.2), da ich nur eine Steckdose auf die allerletzte Version geholt habe, weil ich erst dachte, es gibt Probleme mit Tasmota. Die anderen Steckdosen, also die mit korrekter Anzeige, laufen noch mit Tasmota 8.x und älter.

Hab mir gerade über ein Update die aktuelle Version des Templates geholt, das Verhalten ist aber leider noch identisch. Hab auch nicht nur das Template neu gesetzt, sondern das ganze Gerät noch einmal per Autocreate anlegen lassen.

Was genau brauchst du von mir, um das Problem weiter einzugrenzen?

Hier schon einmal ein komplettes List meines "Test-Devices" (ich habe nur mal die SSID herausgenommen):
Internals:
   CFGFN     
   CID        DVES_D1FDB8
   DEF        DVES_D1FDB8
   DEVICETOPIC Aquarium_3_Licht
   FUUID      60abd70c-f33f-c6cb-e99f-cc6a1237bc3fdb8c
   IODev      MQTT_Server
   LASTInputDev MQTT_Server
   MQTT_Server_MSGCNT 20
   MQTT_Server_TIME 2021-05-24 18:48:00
   MSGCNT     20
   NAME       Aquarium_3_Licht
   NR         221
   STATE      aktuell: 0.0 W Tag: 0.12 kWh Gestern: 0.118 kWh Gesamt: 0.2540 kWh
   TYPE       MQTT2_DEVICE
   JSONMAP:
     Channel_0  0
     Channel_1  0
     Channel_2  0
     Channel_3  0
     Channel_4  0
     Color      0
     Dimmer     0
     HSBColor   0
     POWER1     0
     POWER2     0
     POWER3     0
     POWER4     0
   OLDREADINGS:
   READINGS:
     2021-05-24 18:48:00   ENERGY_ApparentPower 0
     2021-05-24 18:48:00   ENERGY_Current  0.000
     2021-05-24 18:48:00   ENERGY_Factor   0.00
     2021-05-24 18:48:00   ENERGY_Period   0
     2021-05-24 18:48:00   ENERGY_Power    0
     2021-05-24 18:48:00   ENERGY_ReactivePower 0
     2021-05-24 18:48:00   ENERGY_Today    0.118
     2021-05-24 18:48:00   ENERGY_Total    0.254
     2021-05-24 18:48:00   ENERGY_TotalStartTime 2021-05-22T11:12:35
     2021-05-24 18:48:00   ENERGY_Voltage  0
     2021-05-24 18:48:00   ENERGY_Yesterday 0.118
     2021-05-24 18:42:55   FallbackTopic   cmnd/DVES_D1FDB8_fb/
     2021-05-24 18:42:55   GroupTopic      cmnd/tasmotas/
     2021-05-24 18:48:00   Heap            26
     2021-05-24 18:42:55   Hostname        Corn3-7608
     2021-05-24 18:42:55   IPAddress       192.168.101.138
     2021-05-24 18:42:55   LWT             Online
     2021-05-24 18:48:00   LoadAvg         19
     2021-05-24 18:42:55   Module          JH-G01B1
     2021-05-24 18:48:00   MqttCount       1
     2021-05-24 18:42:55   RestartReason   Software/System restart
     2021-05-24 18:48:00   Sleep           50
     2021-05-24 18:48:00   SleepMode       Dynamic
     2021-05-24 18:48:00   Time            2021-05-24T18:48:00
     2021-05-24 18:48:00   Uptime          0T00:05:09
     2021-05-24 18:48:00   UptimeSec       309
     2021-05-24 18:42:55   Version         9.4.0(tasmota)
     2021-05-24 18:42:55   WebServerMode   Admin
     2021-05-24 18:48:00   Wifi_AP         1
     2021-05-24 18:48:00   Wifi_BSSId      E4:26:8B:8B:AA:B8
     2021-05-24 18:48:00   Wifi_Channel    11
     2021-05-24 18:48:00   Wifi_Downtime   0T00:00:03
     2021-05-24 18:48:00   Wifi_LinkCount  1
     2021-05-24 18:48:00   Wifi_RSSI       64
     2021-05-24 18:48:00   Wifi_SSId     
     2021-05-24 18:48:00   Wifi_Signal     -68
     2021-05-24 18:40:58   attrTemplateVersion 20210521
     2021-05-24 18:43:09   state           off
     2021-05-24 18:42:42   subscriptions   cmnd/Corn3/# cmnd/DVES_D1FDB8_fb/# cmnd/tasmotas/#
Attributes:
   alias      Aquarium 3 Licht
   autocreate 0
   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/Corn3/Backlog POWER1 1; delay '.$duration.'; POWER1 0'}<br>See the "Praxisbeispiele" in the wiki for "pulseTime1" alternative option and it's restrictions.
   devStateIcon {my $text = ' uptime: '.ReadingsVal($name,"Uptime","unknown").sprintf(" aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"));; my $onl = ReadingsVal($name,"LWT","false") eq "Online"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");;"<div><a href=\"http://".ReadingsVal($name,"IPAddress",ReadingsVal($name,"Info2_IPAddress","none"))." \"target=\"_blank\">".FW_makeImage($onl).'</a> <a href="/fhem?cmd.dummy=set '.$name.' toggle&XHR=1">'.FW_makeImage($light)."</a>$text"}
   genericDeviceType switch
   group      Aquarium
   icon       hue_filled_outlet
   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
   model      tasmota_POW
   readingList tele/Corn3/LWT:.* LWT
  tele/Corn3/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }
  tele/Corn3/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }
  tele/Corn3/INFO.:.* { $EVENT =~ m,^..Info[1-3]..(.+).$, ?  json2nameValue($1,'',$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }
  tele/Corn3/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }
  stat/Corn3/POWER1:.* state
  stat/Corn3/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
   room       Wohnzimmer
   setList    off:noArg    cmnd/Corn3/POWER1 0
  on:noArg     cmnd/Corn3/POWER1 1
  toggle:noArg cmnd/Corn3/POWER1 2
   setStateList on off toggle
   stateFormat {sprintf("aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"))}
   webCmd     :

edit: Okay, es scheint doch eher an der Template Version zu liegen statt an der Tasmota Version. Sehe gerade, dass die eine Steckdose, die ebenfalls neu eingerichtet wurde und länger in der Ecke lag, noch auf einer 8er Tasmota Version läuft und dasselbe Verhalten in FHEM zeigt. Hier auch der ihre Readings:
Internals:
   CID        DVES_D31A47
   DEF        DVES_D31A47
   DEVICETOPIC Aquarium_3_Pumpe
   FUUID      60a8d48c-f33f-c6cb-2ee1-461ba56e3e7b0c9f
   IODev      MQTT_Server
   LASTInputDev MQTT_Server
   MQTT_Server_MSGCNT 25
   MQTT_Server_TIME 2021-05-24 19:22:39
   MSGCNT     25
   NAME       Aquarium_3_Pumpe
   NR         115
   STATE      aktuell: 7.0 W Tag: 0.13 kWh Gestern: 0.185 kWh Gesamt: 71.2570 kWh
   TYPE       MQTT2_DEVICE
   JSONMAP:
     Channel_0  0
     Channel_1  0
     Channel_2  0
     Channel_3  0
     Channel_4  0
     Color      0
     Dimmer     0
     HSBColor   0
     POWER1     0
     POWER2     0
     POWER3     0
     POWER4     0
   OLDREADINGS:
   READINGS:
     2021-05-24 19:22:39   ENERGY_ApparentPower 13
     2021-05-24 19:22:39   ENERGY_Current  0.056
     2021-05-24 19:22:39   ENERGY_Factor   0.58
     2021-05-24 19:22:39   ENERGY_Period   1
     2021-05-24 19:22:39   ENERGY_Power    7
     2021-05-24 19:22:39   ENERGY_ReactivePower 11
     2021-05-24 19:22:39   ENERGY_Today    0.133
     2021-05-24 19:22:39   ENERGY_Total    71.257
     2021-05-24 19:22:39   ENERGY_TotalStartTime 2020-10-22T16:09:47
     2021-05-24 19:22:39   ENERGY_Voltage  229
     2021-05-24 19:22:39   ENERGY_Yesterday 0.185
     2021-05-24 19:22:39   Heap            31
     2021-05-24 19:22:39   LoadAvg         19
     2021-05-24 19:22:39   MqttCount       3
     2021-05-24 19:22:39   Sleep           50
     2021-05-24 19:22:39   SleepMode       Dynamic
     2021-05-24 19:22:39   Time            2021-05-24T18:22:38
     2021-05-24 19:22:39   Uptime          2T07:00:15
     2021-05-24 19:22:39   UptimeSec       198015
     2021-05-24 19:22:39   Wifi_AP         1
     2021-05-24 19:22:39   Wifi_BSSId      E4:26:8B:8B:AA:B8
     2021-05-24 19:22:39   Wifi_Channel    11
     2021-05-24 19:22:39   Wifi_Downtime   0T00:00:07
     2021-05-24 19:22:39   Wifi_LinkCount  1
     2021-05-24 19:22:39   Wifi_RSSI       82
     2021-05-24 19:22:39   Wifi_SSId       
     2021-05-24 19:22:39   Wifi_Signal     -59
     2021-05-24 19:09:47   attrTemplateVersion 20210521
     2021-05-24 19:11:09   state           on
Attributes:
   alias      Aquarium 3 Pumpe
   autocreate 0
   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/Corn1/Backlog POWER1 1; delay '.$duration.'; POWER1 0'}<br>See the "Praxisbeispiele" in the wiki for "pulseTime1" alternative option and it's restrictions.
   devStateIcon {my $text = ' uptime: '.ReadingsVal($name,"Uptime","unknown").sprintf(" aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"));; my $onl = ReadingsVal($name,"LWT","false") eq "Online"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");;"<div><a href=\"http://".ReadingsVal($name,"IPAddress",ReadingsVal($name,"Info2_IPAddress","none"))." \"target=\"_blank\">".FW_makeImage($onl).'</a> <a href="/fhem?cmd.dummy=set '.$name.' toggle&XHR=1">'.FW_makeImage($light)."</a>$text"}
   genericDeviceType switch
   group      Aquarium
   icon       hue_filled_outlet
   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
   model      tasmota_POW
   readingList tele/Corn1/LWT:.* LWT
  tele/Corn1/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }
  tele/Corn1/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }
  tele/Corn1/INFO.:.* { $EVENT =~ m,^..Info[1-3]..(.+).$, ?  json2nameValue($1,'',$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }
  tele/Corn1/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }
  stat/Corn1/POWER1:.* state
  stat/Corn1/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
   room       Wohnzimmer
   setList    off:noArg    cmnd/Corn1/POWER1 0
  on:noArg     cmnd/Corn1/POWER1 1
  toggle:noArg cmnd/Corn1/POWER1 2
   setStateList on off toggle
   stateFormat {sprintf("aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"))}
   webCmd     :
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 24 Mai 2021, 19:18:55
Kannst du mal devStateIcon aus der Vorgänger-Version testen? Ich vermute, das "fett ein-aus" hatte doch eine Funktion...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: darthi am 24 Mai 2021, 19:27:12
Ja mit dem alten DevStateIcon {my $text = ' uptime: '.ReadingsVal($name,"Uptime","unknown").sprintf(" aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1")); my $onl = ReadingsVal($name,"LWT","false") eq "Online"?"10px-kreis-gruen":"10px-kreis-rot"; my $light = ReadingsVal($name,"state","off");"<div><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>$text<b></b>"}
funktioniert die Anzeige. Allerdings wird das Gerät nicht als online angezeigt (Kreis rot). Siehe mein edit oben, es scheint wohl auch mit den alten Tasmota Versionen mit dem neuen Template ein Problem zu geben.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 24 Mai 2021, 19:44:08
Zur Sicherheit: das LWT-Reading ist auf Online, aber der Punkt rot?
(Werte werden gelöscht, das dauert uU. etwas.)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: darthi am 24 Mai 2021, 19:55:39
Okay vergiss es. LWT Reading war nicht da... Nun ist er grün. Also scheint es mit dem "alten" DevStateIcon zu funktionieren.

Vielen Dank für die Hilfe!
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 25 Mai 2021, 11:08:05
Danke erst mal für die Rückmeldung, dass
vermute, das "fett ein-aus" hatte doch eine Funktion...
zutreffend war.

Trotzdem finde ich den Hinweis an sich von hier berechtigt:
btw, soll das eigtl so
$text<b></b>?

Hat also jemand eine bessere Idee? Würde z.B. das hier auch zu einer richtigen Anzeige führen (will nicht unbedingt das list abtippen, um es selbst zu testen):
$text</p>
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 29 Mai 2021, 21:28:55
Hallo Jörg,

hab ich zufällig im Template name:OpenMQTTGateway_simple_RF433_switch entdeckt -
dort gibt es die Zeile zweimal?
3998 defmod OMG_DEVCID MQTT2_\DEVICE DEVCID
3999 deletereading -q OMG_DEVCID (?!associatedWith).*
4000 defmod OMG_DEVCID MQTT2_\DEVICE DEVCID
Wenn Du mir jetzt noch bitte sagst, ob ich diese Zeile auch in mein Worx Template reinnehmen sollte damit die komische / deformierte DEF / CID dort nicht steht.
Da wird aus der CID (im MQTT2_CLIENT) android-da1a23fb-12bf-1234-a1d2-123c4567b89b sowas im
MQTT2_DEVICE android_da1a23fb_12bf_1234_a1d2_123c4567b89b_
  ??? ::)

Gruß Otto
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 31 Mai 2021, 09:11:57
dort gibt es die Zeile zweimal?
Das ist ein Versehen und fliegt bei nächster Gelegenheit raus... ::)
(Aber auch kein Beinbruch, wird halt unnötigerweise doppelt gesetzt.)

Zitat
Wenn Du mir jetzt noch bitte sagst, ob ich diese Zeile auch in mein Worx Template reinnehmen sollte damit die komische / deformierte DEF / CID dort nicht steht.
Von hier aus: Schwierig...
Wenn die CID eindeutig ist und "irgendwie" bei der Zuordnung neuer Topics auf das Device hilft: eher drin lassen, auch wenn es "komisch" ist. (Ohne das im Code verifiziert zu haben:) Die "Transformation" (mit den Unterstrichen) dürfte auch bei neuen Topics identisch durchlaufen werden, das ist in dem Zusammenhang eher kein Problem.
Wenn es aber sowieso eine Random-Angabe ist und der M2C Client sowieso auf diese eine Verbindung beschränkt ist (und dieses M2D sowieso "alles bekommt"), kannst du auch die CID ganz löschen (das fände ich dann vom Bauchgefühl her besser, als "irgendwas" zu setzen; allenfalls die aus dem IO abgeleitete CID wäre evtl. noch eine Variante (?).) 

Anm.: Die "händischen" CID-Vergaben sind uU. nicht bis ins Letzte durchdacht, bei der oMG-RF-Geschichte ist es "zum Wiederfinden" ein RF-Code, soweit ich mich entsinne.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 03 Juni 2021, 09:44:08
Ich habe es jetzt nach Deiner Empfehlung gemacht und mache
defmod DEVICE MQTT2_\DEVICEwobei dadurch das Internal CID nicht gelöscht wird.

Ich verstehe noch nicht warum die Bindestriche in der CID beim autocreate des MQTT2_DEVICE in Unterstriche umgewandelt werden (müssen?)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 03 Juni 2021, 10:12:01
Zitat
Ich verstehe noch nicht warum die Bindestriche in der CID beim autocreate des MQTT2_DEVICE in Unterstriche umgewandelt werden (müssen?)
Weil Bindestriche keine gueltigen Zeichen im FHEM-Namen sind, das ist nur a-z0-9._
Siehe auch makeDeviceName() in fhem.pl
Weiss nicht mehr, woher die Aversion gegen dieses Zeichen herkommt, vermutlich hat das was mit Rechnen zu tun.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 03 Juni 2021, 10:32:02
Ja, das habe ich mir auch gedacht. Aber es geht ja nicht um den Namen sondern um eine ClientID von MQTT die malträtiert wird damit sie in den Namen passt (klar) aber diese verunstaltete ClientID wandert anschließend in die DEF und damit in das Internal CID!?

Ok, ich kann das "heilen" in dem ich die DEF nicht leer lassen sondern die echte CID einlese und reinschreibe, damit wird auch das Internal überschrieben. Eine leere DEF löscht das Internal CID nicht.

Und ich habe nicht verstanden, warum die Umwandlung nicht nur Zeichen ersetzt sondern auch noch Eines anfügt - das ist doch ein Bug Edit : in meinem Template, siehe unten?
android-da1a23fb-12bf-1234-a1d2-123c4567b89b
android_da1a23fb_12bf_1234_a1d2_123c4567b89b_
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 03 Juni 2021, 11:28:22
Ich wuerde jetzt eine Wette anbieten, dass da hinten ein unsichtbares Zeichen herumlungert.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 03 Juni 2021, 14:19:10
Ich wollte spontan dagegen halten :) aber ich habe das herumlungernde Zeichen gefunden  ;D :-[
Mit dieser Programmzeile steht am Ende des Strings $uuid ein Zeilenumbruch: :o
{my $uuid=qx(cat /proc/sys/kernel/random/uuid);;fhem("attr MQTT_Worx clientId android-$uuid")}Es ist also ein bug in meinem Template!

Ist es legitim wenn ich es so umschreibe? Ich brauche eigentlich eine UUID mit 32/36 Stellen, die sub genUUID in fhem.pl erzeugt eine UUID mit 36/40 Stellen (da erhebt sich die Frage: Wieso eigentlich? Laut Definition ist das zuviel? https://de.wikipedia.org/wiki/Globally_Unique_Identifier ;)

{my $uuid=substr(genUUID(),0,36);;fhem("attr MQTT_Worx clientId android-$uuid")}

Im Template dann:Das war ein Gedankenfehler, es gibt dafür ja kein Template. Kommt wir oben ins setup.
par:UUID; UUID generate from fhem subroutine; substr(genUUID(),0,36)
...
attr DEVICE clientId android-UUID
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 03 Juni 2021, 15:24:10
Mit der Laenge scheinst Du recht zu haben, komisch, dass bisher das keinem aufgefallen ist.
Bin unsicher, ob ich das jetzt fixen soll, da ich die Nebeneffekte nicht blicke. Meinungen?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 03 Juni 2021, 18:44:27
1. Wer verwendet bisher wirklich die FUUID? Es gab Leute die haben ne Routine geschrieben um die regelmäßig aus der Config zu löschen weil sie "schlimmes" vermuteten.
2. Ich habe im Kopf: Du hast die mal eingeführt weil man das in Zukunft brauchen könnte. Wenn sie bis jetzt nicht Kriegsentscheidend war würde ich es jetzt fixen.
3. die Bestehenden bleiben, die Neuen werden GUID konform. Eine unique ID ist es in jedem Fall. Man könnte auch drübergehen und alle einkürzen - würde ich nur "anbieten" und nicht ungefragt ausführen.

Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 03 Juni 2021, 19:24:11
FUUID wurde auf die Anfrage der Alexa/etc Sprachsteuerungs-Fraktion eingefuehrt, damit Geraete eindeutig uebers Umbennen identifiziert werden koennen. Loeschen muss man es nicht, das Speichern kann man mit dem (undokumentierten) "attr global disableFeatures saveuuid" untersagen. Theoretisch kann man ohne Bedenken kuerzen, weil ja keiner bitte die Laenge pruefen soll, andererseits bin ich in letzter Zeit vorsichtiger, und selbst das hilft nicht immer, siehe die aktuelle IODev Diskussion.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Otto123 am 03 Juni 2021, 19:57:07
Ich weiß, in Jurassic Park hieß es: Die Natur findet einen Weg ... - Bei FHEM heißt es: der Anwender findet einen Weg ... (etwas so zu benutzen wie es nie vorgesehen war)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 04 Juni 2021, 08:03:29
Meinungen?
Keine zur Sache, aber eine zum Ort der Diskussion:

a) Falls es Probleme gibt, wäre es besser, es gäbe dazu einen separaten Thread (in Development?)
b) Falls jemand (ein Developer) im vorhinein Probleme erwartet, wäre es auch gut, wenigstens die Chance zu haben, eine Art Vorwarnung zu erhalten (da, wo man sie vermuten würde, nicht hier irgendwo versteckt in einem Mammutthread für was ganz anderes)... (Oder dann eben einen eindeutigen Ort zu haben, im Nachhinein unerwartete "Fernwirkungen" zu diskutieren).

Ich weiß, in Jurassic Park hieß es: Die Natur findet einen Weg ... - Bei FHEM heißt es: der Anwender findet einen Weg ... (etwas so zu benutzen wie es nie vorgesehen war)
Wie wahr...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 06 Juni 2021, 15:56:21
Wegen dem Thread (https://forum.fhem.de/index.php/topic,121495.msg1161055.html#msg1161055) und der Zeilen
{ AttrVal('DEVICE','IODev',InternalVal('DEVICE','IODev',undef)) }in mqtt2.template .

Mir gibt aus der Kommandozeile ausgeführt:
{InternalVal('<Devicneame>','IODev',undef) }
HASH(0xXXXXXX) zurück, warum ist das so ?

Wenn ich auf LASTInputDev zugreife:
{InternalVal('MQTT2_DVES_561C8B','LASTInputDev',undef) }
wird der korrekte Name des IODev zurückgegeben.

Ergo, ersetze ich die Abfragen
InternalVal('DEVICE','IODev',undef)in mqtt2.template durch eine LASTInputDev-Abfrage gibts auch keine Probleme beim anwenden der Tasmota-Templates.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 06 Juni 2021, 16:55:45
$hash->{IODev} enthaelt den "Zeiger", damit es schneller geht.
Versuchs mal mit { InternalVal('DEVICE', 'IODev', '')->{NAME} }
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 06 Juni 2021, 18:25:51
Eine Suche nach

{ AttrVal('DEVICE','IODev',InternalVal('DEVICE','IODev',undef)) }
ergibt 11 Treffer, die hab ich, zum Test und weil ich nicht weiß ob die Abfrage des Attributs noch benötigt (weil ich die Änderungen zu IODev nicht genau verfolgt habe) durch

{ InternalVal('DEVICE', 'IODev', '')->{NAME} }
ersetzt . Damit kann man die Templates wieder anwenden.

Es gibt noch weitere 11 Treffer die das Attribut abfragen und als Ersatz InternalVal nutzen ( u.a. die ignoreRegexp-Templates und weitere ?) damit hab ich mich nicht weiter beschäftigt.



Wenn ich einen Wert mit InternalVal abrufen möchte würd ich den Wert erwarten der auch drin steht und keinen Zeiger.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 06 Juni 2021, 19:13:25
Zitat
Wenn ich einen Wert mit InternalVal abrufen möchte würd ich den Wert erwarten der auch drin steht und keinen Zeiger.
Ich frag mich gerade, wozu man diesen Wert als Anwender ueberhaupt abrufen will.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 06 Juni 2021, 19:21:27
Hab das nur in Erinnerung dass das in dem fhem2mqttfhem-Faden (oder ähnlicher Name) mal der Fall war, also nicht als Anwender.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 06 Juni 2021, 19:56:26
Ich vermute jetzt schon das mir die Antwort zu weit, hoch ist, frag aber trotzdem, für mich und auch andere (zum Verständnis), warum steht dann in LASTInputDev kein Zeiger ?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: rudolfkoenig am 06 Juni 2021, 20:37:49
LASTInputDev ist was fuers Protokoll, damit man bei mehreren moeglichen Datenleiferenten (z.Bsp. mehrere CULs) mitkriegt, wer die Daten empfangen hat.

IODev wird bei der Kommunikation von logischen Modulen (wie FS20) zu phyischen (wie CUL) verwendet, und ich habe vor 10+ Jahren (FritzBox-Zeiten) befuerchtet, dass ein Lookup bei jedem Schreiben zu aufwendig ist. Deswegen ist IODev ein Zeiger, und alle Anzeigen (list, JsonList2, XmlList, etc) haben extra Code drin, um das nach Menschenlesbar zu konvertieren. InternalVal nicht.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 04 Juli 2021, 16:31:10
Sehe heute das erste mal das die Müller-Tint-GU10 auch Farbtemperatur können, ich meine dazu kam bisher bei mir kein Reading rein.

Das ich das Template auch über die Kommandozeile zuweisen kann ist klar, aber warum stehen mir die entsprechenden Templates mit bspw. dem u.a. Device nicht zur Auswahl ?

Das ist schon ein älteres Device in der DEF stand bisher nur der technische Name (k.A. ob das heute anders wäre beim neu erstellen, habs nicht ausprobiert), den hab ich um zigbee_ ergänzt (für das Internal CID), trotzdem werden die Templates nicht angezeigt ?

defmod MQTT2_zigbee_gu10_6 MQTT2_DEVICE zigbee_0x00158d0003278378
attr MQTT2_zigbee_gu10_6 userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 structexclude wzdl wzdl_map
attr MQTT2_zigbee_gu10_6 IODev MQTT2_Server
attr MQTT2_zigbee_gu10_6 alexaName decke6
attr MQTT2_zigbee_gu10_6 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_zigbee_gu10_6 genericDeviceType light
attr MQTT2_zigbee_gu10_6 group Wohnzimmer
attr MQTT2_zigbee_gu10_6 homebridgeMapping Brightness=brightness::brightness,minValue=0,maxValue=100,max=255,delay=true\
On=state,valueOn=ON,valueOff=OFF
attr MQTT2_zigbee_gu10_6 icon light_control
attr MQTT2_zigbee_gu10_6 imageLink /fhem/deviceimages/mqtt2/404006-404008-404004.jpg
attr MQTT2_zigbee_gu10_6 model L_02a_zigbee2mqtt_light_dimmer
attr MQTT2_zigbee_gu10_6 readingList zigbee2mqtt/0x00158d0003278378:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_gu10_6 room MQTT2_DEVICE,Wohnzimmer
attr MQTT2_zigbee_gu10_6 setList on:noArg zigbee2mqtt/0x00158d0003278378/set {"state":"ON"}\
  off:noArg zigbee2mqtt/0x00158d0003278378/set {"state":"OFF"}\
  brightness:colorpicker,BRI,0,1,255 zigbee2mqtt/0x00158d0003278378/set {"state":"on","$EVTPART0":"$EVTPART1"}
attr MQTT2_zigbee_gu10_6 setStateList on off
attr MQTT2_zigbee_gu10_6 verbose 2
attr MQTT2_zigbee_gu10_6 webCmd brightness
attr MQTT2_zigbee_gu10_6 webCmdLabel Helligkeit\
:

setstate MQTT2_zigbee_gu10_6 ON
setstate MQTT2_zigbee_gu10_6 2021-07-04 16:15:04 IODev MQTT2_Server
setstate MQTT2_zigbee_gu10_6 2021-07-04 16:04:04 brightness 254
setstate MQTT2_zigbee_gu10_6 2021-07-04 16:04:04 color_mode color_temp
setstate MQTT2_zigbee_gu10_6 2021-07-04 16:04:04 color_temp 153
setstate MQTT2_zigbee_gu10_6 2021-07-04 16:04:04 linkquality 127
setstate MQTT2_zigbee_gu10_6 2021-07-04 16:04:04 state ON

list für die CID:
Internals:
   CID        zigbee_0x00158d0003278378
   DEF        zigbee_0x00158d0003278378
   DEVICETOPIC MQTT2_zigbee_gu10_6
   FUUID      5fcd1b4c-f33f-78f5-517f-83893558e44c8d56
   IODev      MQTT2_Server
   LASTInputDev MQTT2_Server
   MQTT2_Server_MSGCNT 24
   MQTT2_Server_TIME 2021-07-04 16:04:04
   MSGCNT     24
   NAME       MQTT2_zigbee_gu10_6
   NR         303
   STATE      ON
   TYPE       MQTT2_DEVICE
   READINGS:
     2021-07-04 16:15:04   IODev           MQTT2_Server
     2021-07-04 16:04:04   brightness      254
     2021-07-04 16:04:04   color_mode      color_temp
     2021-07-04 16:04:04   color_temp      153
     2021-07-04 16:04:04   linkquality     127
     2021-07-04 16:04:04   state           ON
Attributes:
   IODev      MQTT2_Server
   alexaName  decke6
   devStateIcon {zigbee2mqtt_devStateIcon255($name)}
   genericDeviceType light
   group      Wohnzimmer
   homebridgeMapping Brightness=brightness::brightness,minValue=0,maxValue=100,max=255,delay=true
On=state,valueOn=ON,valueOff=OFF
   icon       light_control
   imageLink  /fhem/deviceimages/mqtt2/404006-404008-404004.jpg
   model      L_02a_zigbee2mqtt_light_dimmer
   readingList zigbee2mqtt/0x00158d0003278378:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE,Wohnzimmer
   setList    on:noArg zigbee2mqtt/0x00158d0003278378/set {"state":"ON"}
  off:noArg zigbee2mqtt/0x00158d0003278378/set {"state":"OFF"}
  brightness:colorpicker,BRI,0,1,255 zigbee2mqtt/0x00158d0003278378/set {"state":"on","$EVTPART0":"$EVTPART1"}
   setStateList on off
   userattr   lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 structexclude wzdl wzdl_map
   verbose    2
   webCmd     brightness
   webCmdLabel Helligkeit
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 05 Juli 2021, 07:32:32
Hab's eben mit der (um IODev gekürzten) RAW-Definition ausprobiert, keine Probleme bzw. alle z2m-attrTemplate im dropdown auswählbar...
Browser-refresh bzw. kompletten reload der Seite gemacht?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 05 Juli 2021, 07:43:17
Browser-refresh hatte ich natürlich auch gemacht. es wurde immer nur das z2m_bridge-Template angezeigt, warum auch immer, wenn ich jetzt schaue folgen nach dem Bridge-Template alle weiteren  :o  ::) sry.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 05 Juli 2021, 16:09:10
Ich hab ja mehrere von den GU-10, eben hab ich bei einer weiteren zigbee_ in der DEF ergänzt, gleiches Spiel wie gestern, trotz Browser-refresh keine weiteren Templates, weiterhin nur das Bridge-Template, es muss an was anderem liegen. Einen restart seit der Änderung gestern hatte ich, mein ich, auch nicht gemacht.

defmod MQTT2_zigbee_gu10_1 MQTT2_DEVICE zigbee_0x00158d0003274a6c
attr MQTT2_zigbee_gu10_1 userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 structexclude wzdl wzdl_map
attr MQTT2_zigbee_gu10_1 IODev MQTT2_Server
attr MQTT2_zigbee_gu10_1 alexaName decke1
attr MQTT2_zigbee_gu10_1 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_zigbee_gu10_1 genericDeviceType light
attr MQTT2_zigbee_gu10_1 group Wohnzimmer
attr MQTT2_zigbee_gu10_1 homebridgeMapping Brightness=brightness::brightness,minValue=0,maxValue=100,max=255,delay=true\
On=state,valueOn=ON,valueOff=OFF
attr MQTT2_zigbee_gu10_1 icon light_control
attr MQTT2_zigbee_gu10_1 imageLink /fhem/deviceimages/mqtt2/404006-404008-404004.jpg
attr MQTT2_zigbee_gu10_1 model L_02a_zigbee2mqtt_light_dimmer
attr MQTT2_zigbee_gu10_1 readingList zigbee2mqtt/0x00158d0003274a6c:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_gu10_1 room MQTT2_DEVICE,Wohnzimmer
attr MQTT2_zigbee_gu10_1 setList on:noArg zigbee2mqtt/0x00158d0003274a6c/set {"state": "ON"}\
off:noArg zigbee2mqtt/0x00158d0003274a6c/set {"state": "OFF"}\
brightness:colorpicker,BRI,0,5,255 zigbee2mqtt/0x00158d0003274a6c/set {"state":"on","$EVTPART0":"$EVTPART1"}
attr MQTT2_zigbee_gu10_1 setStateList on off
attr MQTT2_zigbee_gu10_1 verbose 2
attr MQTT2_zigbee_gu10_1 webCmd brightness
attr MQTT2_zigbee_gu10_1 webCmdLabel Helligkeit\
:

setstate MQTT2_zigbee_gu10_1 OFF
setstate MQTT2_zigbee_gu10_1 2021-07-05 16:01:45 IODev MQTT2_Server
setstate MQTT2_zigbee_gu10_1 2020-02-06 22:37:46 abrightness 50
setstate MQTT2_zigbee_gu10_1 2021-07-01 03:33:09 brightness 254
setstate MQTT2_zigbee_gu10_1 2021-07-05 02:21:46 color_mode xy
setstate MQTT2_zigbee_gu10_1 2021-07-05 02:21:46 linkquality 199
setstate MQTT2_zigbee_gu10_1 2021-07-05 02:21:46 state OFF
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 05 Juli 2021, 16:21:58
Hmm, seltsam, das...

Habe nochmal - diesmal mit einem anderen (aktuellen) System - die RAW-DEF (nur den cfg-Teil, ohne IO und alexaName) kopiert und mit dem "grünen Plus" eingespielt, und direkt war nach Aufruf des Devices war eine längere Liste von t2m-attrTemplate wählbar.

Da scheint irgendwas in den internen Datenstrukturen "verklemmt" zu sein, wenn man nachträglich die DEF ändert. Da die bridgeRegexp mWn. auch seit langem unverändert ist, dürfte das ganze auch eher weniger User betreffen. Bin daher eher abgeneigt, größeren Aufwand für Ursachenforschung zu betreiben. Aber falls jemand eine Erklärung oder (praktikable) Lösung hat: her damit...
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: TomLee am 05 Juli 2021, 16:39:05
Zitat
Bin daher eher abgeneigt, größeren Aufwand für Ursachenforschung zu betreiben.

Und ich ergänze nur noch :

Einen restart hab ich auch gleich für ein update genutzt, die mqtt2.template-File tauchte auch im Eventmonitor auf, war also nicht aktuell, die weiteren Templates sind danach vorhanden.
Wieder in einem anderen GU-10 Device die DEF geändert, Verhalten bleibt auch nach update so, keine weiteren Templates, ohne restart.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: kennymc.c am 07 September 2021, 20:19:39
Ich bin vor kurzem vom alten MQTT Modul mit XiaomiMQTTDevice über Zigbee2MQTT auf MQTT2_Client/Device umgestiegen. Das hat soweit auch ganz gut funktioniert. Was mir allerdings aufgefallen ist, das mit dem Template zigbee2mqtt_plug_w_energy_measuring (andere Schalter Templates habe ich bisher nicht getestet) diese Geräte in Homebridge immer als eingeschaltet angezeigt werden auch wenn sie gar nicht eingeschaltet sind. Man kann sie zwar Aus- und wieder Einschalten, nach kurzer Zeit werden sie dann aber wieder als eingeschaltet angezeigt. Das entspricht nicht der Anzeige in Fhem selbst.
Mit XiaomiMQTTDevice musste ich da nichts im HomebridgeMapping ändern. Das steht auch im neuen Device weiterhin auf history:size=1024,type=energy. Könnte man das anpassen, da es mit anderen Geräte keine Probleme über Homebridge gibt?
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: kennymc.c am 08 September 2021, 20:48:36
Ok, mit folgendem HomebridgeMapping funktioniert es:
On=state,valueOn=ON,valueOff=OFF
Wäre nett, wenn man das ins Template integrieren könnte, da es ansonsten keine Auswirkungen hat. Außer es gibt Probleme, da es als Userattribut nicht bei allen vorhanden ist.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 08 September 2021, 20:56:54
Nachdem es doch einige Installationen gibt, die die diversen zigbee2mqtt-on/off-Geräte beinhalten, unterstelle ich mal zwei Dinge:
a) es gibt eine gewisse Anzahl an User darunter, die homebridge nutzen und
b) die finden es völlig ok, dass attrTemplate (für on/off-Geräte) nur den genericDeviceType setzt.

Ergo meine ich: Löschen des Attributs (bzw. Nicht-Setzen wie gehabt) ist die korrekte Vorgehensweise.
(Danach einfach die homebridge-Erkennung/den externen Dienst nochmal starten).

PS: Die im gestaffelten Aufruf der attrTemplate enthaltene Logik ermöglicht es zu erkennen, ob das Attribut "bekannt" sein müßte (also eine Sprachsteuerung aktiviert ist). Sonst wird auch genericDeviceType nicht gesetzt.

Auch hier gilt also: Lass die Automatik machen und verschlimmbessere nicht gleich alles...
Für das Sprachsteuerungs-"Zeug" gilt im übrigen: Weniger ist mehr! Nur setzen, was unbedingt sein muss.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: kennymc.c am 08 September 2021, 22:35:48
Ich habe aus dem Device jetzt alle von mir zusätzlich gesetzten Attribute (Ausnahme room und DBLogExclude) entfernt und das Template erneut angewendet. Es bleibt dabei, dass der State in Homebridge nicht stimmt.

Internals:
   CID        zigbee_WZ_Plug_Amp
   DEF        zigbee_WZ_Plug_Amp
   DEVICETOPIC zigbee2mqtt/WZ_Plug_Amp
   FUUID      6134dbfc-f33f-b03f-1eae-e446ae05a33d7280
   FVERSION   10_MQTT2_DEVICE.pm:0.248610/2021-08-20
   IODev      mqtt2
   LASTInputDev mqtt2
   MSGCNT     2241
   NAME       WZ_Plug_Amp
   NR         537
   STATE      off
   TYPE       MQTT2_DEVICE
   mqtt2_MSGCNT 2241
   mqtt2_TIME 2021-09-08 22:25:27
   Helper:
     DBLOG:
       linkquality:
         DBLogging:
           TIME       1631132310.84627
           VALUE      54
       power:
         DBLogging:
           TIME       1631125194.7511
           VALUE      0
       state:
         DBLogging:
           TIME       1631132346.48746
           VALUE      attrTemplate speechcontrol_general_naming_master_template
   READINGS:
     2021-09-08 04:09:20   IODev           mqtt2
     2021-09-08 18:44:28   associatedWith  ZigBee2MQTT_Bridge
     2021-09-08 22:20:48   attrTemplateVersion 20200903
     2021-09-08 18:44:28   availability    online
     2021-09-08 22:25:27   current         0
     2021-09-08 22:23:24   elapsed         27991
     2021-09-08 22:25:27   energy          16.24
     2021-09-08 22:25:27   last_seen       1631132727914
     2021-09-08 22:25:27   linkquality     60
     2021-09-08 22:25:27   power           0
     2021-09-08 22:25:27   state           OFF
     2021-09-08 22:25:27   voltage         240
Attributes:
   DbLogExclude .*
   devStateIcon {my $light = FW_makeImage(ReadingsVal($name,"state","off")); my $current = ReadingsVal($name,"current",0); my $pwr = ReadingsVal($name,"power",0); my $energy = ReadingsVal($name,"energy",0); qq(<div> <a href="/fhem?cmd.dummy=set $name toggle&XHR=1">$light</a> Aktuell: $current A  Leistung.: $pwr W<b></b>)}
   devicetopic zigbee2mqtt/WZ_Plug_Amp
   eventMap   { dev=>{ON=>'on',OFF=>'off'} }
   genericDeviceType switch
   icon       message_socket
   model      zigbee2mqtt_plug_w_energy_measuring
   readingList $DEVICETOPIC:.* { json2nameValue($EVENT) }
   room       Homebridge,ZigBee
   setList    on:noArg $DEVICETOPIC/set {"state":"ON"}
  off:noArg $DEVICETOPIC/set {"state":"OFF"}
  toggle:noArg $DEVICETOPIC/set {"state":"TOGGLE"}
   setStateList on off toggle

Was ist mit Löschen des Attributs gemeint? GenereicDeviceType? Das zu Löschen hat keine Auswirkung.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 09 September 2021, 08:04:47
Gemeint gewesen war "deleteattr <device> homeBridgeMapping" + anschließender Start der Geräte-Erkennung in homebridge.

Falls es wirklich so ist, dass man da was braucht (an eventuelle Mitleser: Rückmeldung wäre nett!), ist m.E. für diesen Fall das Setzen des Attributs (und damit der Weg über attrTemplate) mAn. die letzt-beste Variante.

Da heutzutage viele Geräte die Großschreibung für "ON" etc. (in state) verwenden, müßte mAn. dann mal auf der homebridge-Seite geklärt werden, ob man das nicht generell abfangen kann. Eventuell gibt es dafür Startoptionen...?
Wenn nein, wäre die Frage, ob man den dortigen Maintainer fragt, ob er sowas einbauen kann und will.

Danach wäre zu klären, ob man dem Sender (=zigbee2mqtt) beibiegen kann, dass man Kleinschreibung haben möchte (analog zu Tasmota)?
 
Erst wenn das alles nichts hilft, ist es nach meinem Dafürhalten ein Thema für homeBridgeMapping (und dann nur, wenn auch homebridge im Spiel ist...? Das macht es nämlich - vorläufig betrachtet - einigermaßen komplex in der konkreten Umsetzung via attrTemplate.)
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: gandy am 19 Oktober 2021, 11:45:38
Hi,

habe gerade einen kleinen Bug im mqtt2.template für shellyflood gefunden: Der Eintrag für readingList enhält DEVICE an Stelle von DEVNAME, was dazu führt, dass die Topics falsch formuliert werden (z.B. "shellies/LeckSensorWaschmaschine/sensor/flood" statt "shellies/shellyflood-613BD7/sensor/flood").

Folgende Version des Templates erzeugt das m.E. korrekte Verhalten:
# shellyflood using original firmware
name:shellyflood
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shellyht using original firmware <br>Just adds stateFormat and icon
order:A_16a
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
par:ICON;ICON as set, defaults to humidity;{ AttrVal("DEVICE","icon","humidity") }
attr DEVICE icon ICON
attr DEVICE setList \
  x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE  readingList shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  shellies/DEVNAME/sensor/temperature:.* temperature\
  shellies/DEVNAME/sensor/flood:.* flood\
  shellies/DEVNAME/sensor/battery:.* batteryPercent\
  shellies/DEVNAME/sensor/error:.* error\
  shellies/DEVNAME/sensor/act_reasons:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE jsonMap 1:report
attr DEVICE stateFormat flood (bat batteryPercent%)
deletereading -q DEVICE (?!associatedWith|IODev).*
set DEVICE x_mqttcom announce
attr DEVICE model shellyflood
setreading DEVICE attrTemplateVersion 202110191

Beste Grüße,
Andy.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 19 Oktober 2021, 13:53:54
Danke für den Hinweis, auch an TomLee wg. des DEVICETOPIC-Themas.

Update folgt bei Gelegenheit.
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: moustic999 am 21 Oktober 2021, 15:03:05
hello all,

Zigbee2mqtt bridge template is not alinged anymore with the api of zigbee2mqtt . They refactres their api in version 1.71.0. Is there someone already looking at updating this template ?

If nobody is working on it, I can make changes but I dont know how to publish the changes
Titel: Antw:mqtt2.template: bugs, Fragen, Anregungen
Beitrag von: Beta-User am 21 Oktober 2021, 15:28:02
Hello back,

afaik, there's no one working on this atm, so I'm pretty sure quite some people will be very glad if there's already suitable attrTemplates available the moment they update the zigbee2mqtt service ;) .

Most likely opening up a new thread (in MQTT) might be a good approach, starting perhaps with a rather simple (dimmable) light to highlight the differences? Then we may decide how to get the transition done for the entire set of affected templates, as I assume we will have to offer both versions (at least for some time).

As format, I'm quite open to any method you prefer - as long as it is (more or less) just possible to copy paste your input (e.g. appended or code-tagged diff or (unformatted) txt is ok).
Having a link with some kind of summary wrt the changes would be fine as well :) .