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.
@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!
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.
@sinus61
Ist die folgende Anweisung im Userreading notwendig?
$ip =~ s/<[^>]*>//gs;
Denn eigentlich steht ja in IPAddress nur die IP-Adresse drin ...
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>
Zitat von: OdfFhem am 06 Januar 2019, 17:47:43
Denn eigentlich steht ja in IPAddress nur die IP-Adresse drin ...
Aber nur am Anfang. Wenn sich das Reading mal aktualisiert steht da der HTML Kram mit drin und vermehrt sich dann jedesmal.
Zitat von: Beta-User am 06 Januar 2019, 18:03:04
also das mit den userReadings gefällt mir allgemein nicht, und da besteht auch die Gefahr, dass irgendwas überschrieben wird, was schon da ist (oder ich muß lernen, wie man vernünftig grept, um nur den Teil zu schreiben/tauschen.
Genaugenommen wird ja nur das echte Reading IPAddress mit einem Link versehen, kein zusätzliches Userreading angelegt. Könnte man vielleicht auch über ein Template lösen, ich wollte aber kein zusätzliches Reading haben, sondern das vorhandene nutzen.
@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 ...
Zitat von: OdfFhem am 06 Januar 2019, 18:17:28
Ist das erstrebenswert, da ja der ursprüngliche Wert quasi verlorengeht ?
Ist vielleicht Geschmackssache, die IP Adresse bleibt aber ja genauso sichtbar wie vorher, ist jetzt nur mit einem Link versehen, ähnlich wie es z.B. bei IODev ist.
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).
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
Zitat von: santalaus am 12 Januar 2019, 12:22:50
ist es möglich in A_01b_tasmota_1ch+motion+SI7021
Das ganze "flexibel" für SI7020/7021 zu gestallten?
Hmm, in dem aktuellen template ist keine readingList drin, es geht aber davon aus, dass die Werte an ein bestimmtes Reading geschickt werden. Wenn das anders ist, funktioniert es natürlich nicht...
Kann jemand sagen, wo der konkrete Pfad herkommt, an den der Tasmota publisht? Wenn man das vereinheitlichen könnte (ggf. durch eine Anweisung via MQTT) ginge das vielleicht. Am besten wäre, wenn das Reading dann jeweils generisch wäre (temperature und humidity?).
Aber dazu sollte sich das erst mal jemand ansehen, der ein oder mehrere solcher Geräte hat. Beispiele, wie das mit dem Umkonfigurieren ginge, sind in der aktuellen template-file zu finden.
Ansonsten kannst du ja die Readings, auf die zugegriffen wird im devStateIcon auch manuell ändern; die templates sollen/müssen m.E. nicht jeden konkreten Fall abdecken, sondern ggf. auch als "Steinbruch" genutzt werden können für eigene Ideen ;) .
Zitat von: sinus61 am 06 Januar 2019, 18:15:31
Genaugenommen wird ja nur das echte Reading IPAddress mit einem Link versehen, kein zusätzliches Userreading angelegt. Könnte man vielleicht auch über ein Template lösen, ich wollte aber kein zusätzliches Reading haben, sondern das vorhandene nutzen.
Ok, das habe ich jetzt verstanden, finde es aber nach wie vor suboptimal (weil andere andere userReadings haben können und ich das Attribut möglichst nicht unbesehen überschreiben will).
In den aktuellen templates ist ein auskommentierter Vorschlag für eine eventMap drin. Sowas müßte eigentlich mit demselben Effekt funktionieren ohne Nebenwirkungen, könnt ihr euch das mal ansehen?
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
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!
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
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 :) .
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
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
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 ;) .
Zitat von: Beta-User am 20 Januar 2019, 15:07:16
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
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
Zitat von: deimos84 am 26 Januar 2019, 20:51:29
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.
Vielen Danke für die echt schnelle Antwort!
Zitat von: Beta-User am 27 Januar 2019, 08:32:05
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"
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).
Zitat 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...), ...
Die habe ich tatsächlich vergessen. Ich bin aber auch ein Depp. Hilft aber letztendlich auch nichts. Dann erkennt er readingsVal nicht.
Zitat von: Beta-User am 27 Januar 2019, 10:35:47
..., oder evtl. mal $name (kleingeschrieben) versuchen (wäre mein Favorit).
Beide Schreibweisen (groß und klein) ergeben die gleiche Fehlermeldung.
Sorry, habe bei der Schreibweise einen Fehler reingebaut: ReadingsVal() schreibt sich groß...
Nimm aber besser ReadingsNum().
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!
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
Schalten und Zustand sollte mit A_01_tasmota_basic möglich sein.
Hi,
ja, vielen Dank. Hat nun geklappt. Ein . (Punkt) im Topic mag das System nicht.
Aber damit kann ich leben
LG Christian
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))}
Zitat von: DasQ am 07 Februar 2019, 12:48:26
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_POWFehlt ggf. dann noch die uptime; da sollte es reichen ggf. autocreate am DEVICE wieder einzuschalten.
Gruß, Beta-User
ja sorry, hat sich irgenwie überschnitten.
aber dafür test ich gleich mal morgen
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
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 :) .
Danke, jetzt ist es richtig. Das duerfte den Meisten nicht auffallen. Aber als gelerntem
Starkstroemer springt Dir sowas ins Auge ;-)
Gruss Helmut
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
Zitat 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:
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).
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
Zitat von: carlos am 21 Februar 2019, 09:52:18
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?
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
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.
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
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
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
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
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?
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
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 ;) .
Zitat von: carlos am 24 Februar 2019, 16:38:43
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....)
Zitat von: Beta-User am 11 März 2019, 13:10:10
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.
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 }
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 Sensor
L_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 Sensor
L_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 Sensor
L_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 Switch
L_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. :)
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 :) .
"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. ::)
Zitat 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. ::)
: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...)
Zitat von: Beta-User am 11 März 2019, 14:01:40
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!
Zitat von: Beta-User am 11 März 2019, 22:10:49
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ß
Zitat von: ripperle am 12 März 2019, 20:00:42
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.
Zitat von: Beta-User am 12 März 2019, 20:17:39
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?
Zitat von: ripperle am 12 März 2019, 20:32:24
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...
ZitatUnd in welchem Quellcode soll ich nachschauen?
in dem von ./FHEM/lib/AttrTemplate/mqtt2.template
Zitat von: Beta-User am 12 März 2019, 20:53:23
Ä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 zigbeeEingegeben und dann kann man nur eine zigbee bridge auswählen (siehe Bild) ...
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.
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
Zitat 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
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.
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...
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_irGruß
Thomas
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).
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
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.
Zitat 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...
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.
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.
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...)
Zitat von: Beta-User am 18 März 2019, 07:36:19
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.
...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.
ZitatErgä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.
Zitat von: TomLee am 18 März 2019, 13:18:32
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 .
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?
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).
Zitat 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).
ö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???
Zitat von: wk2000 am 25 März 2019, 18:45:52
ö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
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!
Zitat von: SirUli am 03 Mai 2019, 13:53:17
im Template L_01_zigbee2mqtt_bridge hat sich ein Fehler eingeschlichen.
Thx für den Hinweis, ist ab morgen korrekt im update ::) .
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.
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?
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.
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"}
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!
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***************************
Zitat von: Beta-User am 09 Mai 2019, 09:58:59
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
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
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).
ZitatLerne (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
Erster Parameter pflicht, zwei Weitere optional.
find ich ja super intressant, wird hier aber niemals einer wieder finden ... schade
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.
@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.
GIbt es schon ein Template für ein Xiaomi FlowerSens?
Zitat von: Tobias am 15 Juli 2019, 09:01:49
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?
Das sind BLE Devices. Man benötigt also eine Generic_Bridge (zb. auf dem Raspi Zero W) sowie MQTT2_Devices (FHEM Server)
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...
alles klar, danke... ich fiesel mich mal durch ;)
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\
Thx, u.a. habe ich eben auch diesen bugfix eingecheckt. Sorry for inconvenience...
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.
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.
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
;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...
Zitat 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.
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.
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...).
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: humidity
in
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
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
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).
Zitat von: Beta-User am 15 Oktober 2019, 10:22:22
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
Zitat von: Beta-User am 15 Oktober 2019, 10:22:22
(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.
Zitat von: Beta-User am 15 Oktober 2019, 10:22:22
@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 3005Ich 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
"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...).
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
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 ;) .
Will gerade nicht raten: aus welchem Grund will man attrTemplate nicht in der Liste haben?
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.
ZitatWä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.
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
Ä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...)
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
:) 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...
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?
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...
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
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. :)
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?
Zitat 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.
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.
Zitat von: Beta-User am 19 Oktober 2019, 16:15:32
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.
Zitat von: Beta-User am 19 Oktober 2019, 16:15:32
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?
Zitat von: Beta-User am 19 Oktober 2019, 16:15:32
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.
Zitat von: Beta-User am 19 Oktober 2019, 16:15:32
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
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).
Zitat 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)?
Gerne, gerade schlage ich mich aber noch mit der Topologie meines Zigbee2MQTT Netzes rum. 😅
Zitat von: Beta-User am 20 Oktober 2019, 19:01:50
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
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
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
:)
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 ;)
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 ;)
@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...).
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.
...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?
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? :-)
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
hallo,
availability jetzt direkt zu state habe ich auch schon ausprobiert gehabt.zigbee2mqtt/xxxxxxx/availability:.* state
Problem: 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.
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?
Ich weiss nicht wie die Readings in deinem Fall angelegt sind, es gibt aber mehrere Moeglichkeiten diese umzubennen.
Zitat von: ulli am 17 November 2019, 17:02:55
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").
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
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
@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).
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?
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ß...
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
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
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
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
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?!?
Zitat von: Beta-User am 02 Dezember 2019, 17:50:25
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
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! :)
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.
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
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
Zitat 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
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.)
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?
Zitat 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! :)
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.
Zitat von: sledge am 13 Dezember 2019, 14:41:42
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
Zitat 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.
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 $EVTPART1Wobei ich das Feature nicht benötige, es mir aber auch egal ist.
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.
Zitat 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
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... ;) .
Zitat von: bigtruite am 13 Dezember 2019, 14:32:28
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...)
ZitatGut 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.
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
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.
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
Zitat von: bigtruite am 13 Dezember 2019, 10:43:23
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.
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
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).
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:
ZitatSmart 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.
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.
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
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?
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
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...
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.
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
...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 ;) .
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
Zitat 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
Also ich wäre dafür. Ohne diese Anpassung zeigte mein Sonoff S20 dauerhaft nur set_on bzw. set_off im state an.
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...
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) ;)
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...
Bitte noch stateFormat aus dem Template löschen. Ist hier ja nicht mehr notwendig...
Zitat von: Beta-User am 30 Dezember 2019, 12:28:30
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" ::) .
Zitat von: 87insane am 10 Januar 2020, 12:00:34
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?
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
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 $EVTPART1
Damit 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).
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
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...
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
Zitat 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?
Das hab' ich noch nicht versucht, mache ich aber mal.
Zitat von: Beta-User am 19 Januar 2020, 13:30:20
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
ZitatAber 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.
...etwas zu langsam, aber ausführlicher:
ZitatPS: 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:
Zitat von: frankreed am 20 Januar 2020, 09:42:12Ich 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).
ZitatIch 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...
Zitat von: schwatter am 19 Januar 2020, 21:10:34
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...
ZitatFü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...
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.
Zitat von: frankreed am 22 Januar 2020, 18:36:51
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
@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.
Du suchst webCmdLabel
Beispiel:
attr MQTT2_ebusd_bai webCmd Hc1Heizkurve:HwcTempDesired:z1DayTemp:z1NightTemp:FlowHysteresisON:FlowHysteresisOff
attr MQTT2_ebusd_bai webCmdLabel Heizkurve :;:Warmwasser\
:Tagestemperatur:Nachttemperatur\
:FlowHysteresisON:FlowHysteresisOff
Gruß
Thomas
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.
Zitat von: schwatter am 02 Februar 2020, 16:46:13
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?
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
Zitat von: KölnSolar am 03 Februar 2020, 08:35:03
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.
ZitatAn 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
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 ::) .
Zitat von: KölnSolar am 03 Februar 2020, 12:28:10
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?
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=gatewayBT
geä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
@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)
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 :)
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.
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!
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.
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...
[OT]
Zitat von: 87insane am 19 Februar 2020, 10:56:55
1. Gerät/Aktor/Schalter (tatsächliche Hardware)
2. dummy für die Temperaturen und für den threshold
3. threshold zur Überwachung
Was spricht dagegen, das in einer ReadingsGroup zusammenzufassen, statt den dummy mühevoll zu füttern?
(Bitte hier keine Antwort mehr dazu)
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
Ich schaue mir das nochmal an, aber hast du mal geschaltet nach der attrTemplate-Anweisung?
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)
Ich habe jetzt mal mit etwas Unverstand (also Lesen Versuch Irrtum) jsonMap so gesetzt:
POWER1:state POWER2:0 POWER3:0 POWER4:0 Dimmer:0 Channel_0:0 Channel_1:0 Channel_2:0 Channel_3:0 Channel_4:0 HSBColor:0 Color:0
Da wäre glaub ich meine Welt auch in Ordnung :)
Symbol bzw. state passt und state wird nicht ständig mit aktualisiert :)
Zitat von: Otto123 am 04 März 2020, 01:11:08
POWER1:state POWER2:0 POWER3:0 POWER4:0 Dimmer:0 Channel_0:0 Channel_1:0 Channel_2:0 Channel_3:0 Channel_4:0 HSBColor:0 Color:0
Da wäre glaub ich meine Welt auch in Ordnung :)
Das möchte ich bestätigen.
Der state wird von set_on oder set_off dann auch nach on oder off gewechselt.
Tasmota liefert Ergebnisse im STATTOPIC/RESULT json Array und in einer einzelnen STATTOPIC/POWER1 Nachricht.
Kann es sein das die Unterdrückung aus dem jsonmap (die eigentlich nur die Antwort im RESULT Array bearbeiten soll) beide Antworten erfasst? Race Condition? :o
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...
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
Das ist meine Version:
Tasmota Version 8.1.0(tasmota)
Build-Datum & -Uhrzeit 2019.12.25 12:47:07
Core-/SDK-Version 2_6_1/2.2.2-dev(38a443e)
Also Du hast den
stat/DVES_EFFB7F/POWER1:.* state
und ich den
tele/tasmota_A52F4C/POWER1:.* state
Wenn ich das so setze ist die Welt auch in Ordnung:
defmod MQTT2_DVES_A52F4C MQTT2_DEVICE DVES_A52F4C
attr MQTT2_DVES_A52F4C IODev mqtt2s
attr MQTT2_DVES_A52F4C autocreate 0
attr MQTT2_DVES_A52F4C comment NOTE: For on-for-timer SetExtensions are used. You may add on-for-timer option running on the device. The following is limited to 1h max duration, but will not affect future simple "on" commands:<br>on-for-timer {my $duration = $EVTPART1*10;; 'cmnd/cmnd/tasmota_A52F4C/Backlog POWER1 1;; delay '.$duration.';; POWER1 0'}<br>See the "Praxisbeispiele" in the wiki for "pulseTime1" alternative option and it's restrictions.
attr MQTT2_DVES_A52F4C icon hue_filled_outlet
attr MQTT2_DVES_A52F4C jsonMap POWER1:0 POWER2:0 POWER3:0 POWER4:0 Dimmer:0 Channel_0:0 Channel_1:0 Channel_2:0 Channel_3:0 Channel_4:0 HSBColor:0 Color:0
attr MQTT2_DVES_A52F4C model tasmota_basic_state_power1
attr MQTT2_DVES_A52F4C readingList tele/tasmota_A52F4C/LWT:.* LWT\
tele/tasmota_A52F4C/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/tasmota_A52F4C/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/tasmota_A52F4C/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/tasmota_A52F4C/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
stat/tasmota_A52F4C/POWER1:.* state\
stat/tasmota_A52F4C/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr MQTT2_DVES_A52F4C room MQTT2_DEVICE
attr MQTT2_DVES_A52F4C setList off:noArg cmnd/tasmota_A52F4C/POWER1 0\
on:noArg cmnd/tasmota_A52F4C/POWER1 1\
toggle:noArg cmnd/tasmota_A52F4C/POWER1 2\
setOtaUrl:textField cmnd/tasmota_A52F4C/OtaUrl $EVTPART1\
upgrade:noArg cmnd/tasmota_A52F4C/upgrade 1
attr MQTT2_DVES_A52F4C setStateList on off toggle
Dein gerät ist mit dem alten Template (Weihnachten) angelegt, im neuen Template (Update gestern) steht das drin
TELETOPIC/POWER1:.* state\
STATTOPIC/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
Edit:
Wenn ich den TELETAPPI gegen STATTOPIC austausche funktioniert es auch.
Wie kann ich FHEM eigentlich sagen, er soll den im Hintergrund korrigierten mqtt2.template nehmen? Gibt es sowas wie reload oder geht nur Neustart? ???
ZitatWie kann ich FHEM eigentlich sagen, er soll den im Hintergrund korrigierten mqtt2.template nehmen? Gibt es sowas wie reload oder geht nur Neustart? ???
{ AttrTemplate_Initialize() }
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")...
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?)
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
Zitat von: Otto123 am 04 März 2020, 10:16:42
@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.
Zitat von: Eisix am 04 März 2020, 10:34:02
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\
[...]
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.
Zitat von: Beta-User am 04 März 2020, 10:38:59
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 onOhne 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 onOhne 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 onErgo 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 = onNach 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.
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.
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 ;)
Zitat 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 ;)
Das ist mir auch aufgefallen. Auch fügt es Leeraum im Device ein. Ein Neustart macht wieder alles gut.
einen Leerraum pro Start ::) der dann mit den Hilfetexten in der gleichen Anzahl gefüllt wird - wenn man ein Template wählt.
... 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).
"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>
ZitatDas {AttrTemplate_Initialize()} hat irgendwie Seiteneffekte, da tritt dann sowas auf wie im Bild
Habs gefixt.
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
Zitat von: DS_Starter am 05 März 2020, 23:00:51
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?
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
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
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
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
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 ::) .
@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.
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
Zitat 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
@Beta-User Du willst die Qualität unserer Treffen ja durch die Decke gehen lassen. Wir werden wohl den Rest des Jahres ausgebucht sein :)
;D ... Otto
Zitat von: Otto123 am 06 März 2020, 14:57:14
@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?).
Zitat 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?
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!!!
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.
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
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
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
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
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....
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?)
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.
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.
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
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?).
Hi,
ZitatReadingsNum ist m.E. an der Stelle total ok! Why not?!?
Ja... Geht natürlich aber macht es einen Unterschied?
ZitatUnd 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.
ZitatDas 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".
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
Danke für die Info, update ist im svn.
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
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.
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
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...
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...).
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.
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...).
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).
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
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
Zitatso 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.
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...
Zitat von: Beta-User am 11 April 2020, 06:54:44
- 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
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
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
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
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
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
PS : Fhem und Pow hatte Ich vorher upgedatet !
Gesendet von meinem SM-G960F mit Tapatalk
Löschen und neu anlegen hört sich gut an. Sind ja nur 10 Sekunden.
Gesendet von meinem LM-G810 mit Tapatalk
So , Ich hoffe das hilft ...(https://uploads.tapatalk-cdn.com/20200412/443012406db974fd432a379d70db2582.jpg)
Gesendet von meinem SM-G960F mit Tapatalk
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
Zitat von: joelinux am 12 April 2020, 08:14:24
[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 ;) ).
Zitat 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
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.
Zitat von: Pacman111178 am 12 April 2020, 10:41:30
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
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
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
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.
Zitat 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.
ok danke werde da mal suchen
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 ;)
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)).
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
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).
Für den 3EM wurden durch das Template bei mir keine userReadings angelegt..hmm
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
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.
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..
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...?
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
Anders ja, aber: was genau funktioniert nicht?
Es legt keinen 2. Channel an, das war eigentlich das auffälligste.
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 :) .
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
Zitat von: CBSnake am 17 Juni 2020, 13:07:07
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.
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
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.
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)?
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.
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) }
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.
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
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).
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.
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.
Verstehe. Gut, ich hab da jetzt einfach mal irgendwas eingetragen. Und die IR-Codes dann händisch korrigiert. Hat funktioniert.
Danke dir!
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.
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.
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....
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?
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...).
Zitat von: Beta-User am 03 Juli 2020, 10:12:28
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.
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
ZitatWo wird das denn gespeichert?
Im Attribut model
Gruß
Thomas
Zitat von: TomLee am 09 August 2020, 11:03:28
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
Versuch macht kluch
Zitat von: TomLee am 09 August 2020, 11:34:34
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.....
Zitat von: riker1 am 09 August 2020, 11:21:14
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?
Zitat von: Otto123 am 09 August 2020, 12:17:51
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
Das Attribut model ist völlig unabhängig von der Konfiguration des Devices, kannst da reinschreiben was du möchtest oder auch löschen.
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?
Zitat 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?
..daran arbeite ich gerade mit meinen begrenzen Kenntnissen.....
Danke für die Hilfe
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
schau mal hier: https://forum.fhem.de/index.php?topic=108376.0
Zitat von: riker1 am 09 August 2020, 12:23:28
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.
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
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.
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
Ü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.
Danke für den Tip, hab es dann auch in Wiki über AttrTemplate gefunden 8)
attr global disableFeatures attrTemplate
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 1
Daher 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!
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)
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.
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...
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
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 toggle
Das 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).
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.
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?
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).
Sorry copypast Fehler ich rede vom template zigbee2mqtt_plug_w_energy_measuring
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.
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?
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.
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
Ä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).
Ne funktioniert nicht. Auch wenn ich eventmap lösche
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
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 ;) .
Zitat von: ulli am 04 September 2020, 09:15:24
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
Zitat von: Otto123 am 04 September 2020, 11:27:32
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).
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 restart
Also ein klickbarer Button.
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
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
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 ;) ).
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 .... :-\
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";
blöd, jetzt kann ich mir schon wieder ein neues Projekt suchen ;D
Danke!
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
@Heimweh Du bist im falschen Board? Hier geht es um mqtt2, Du machst ESPEasy ... ::)
ZitatTYPE ESPEasy
Zitat von: Otto123 am 20 November 2020, 11:32:24
@Heimweh Du bist im falschen Board? Hier geht es um mqtt2, Du machst ESPEasy ... ::)
:o da ist was durcheinander gekommen. SORRY
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
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...?!?
Zitat 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
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!
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
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...)
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)
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...)
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:.* ""
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?
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.
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...
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
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 )
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
Zitat von: Otto123 am 08 Dezember 2020, 00:47:55
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
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).
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)
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
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)
Hi Beta-User,
kann ich gerne machen, sag nur ab wann du die Änderungen eingearbeitet hast.
Kommt mit dem regulären update, ist also seit ca. 7:45 Uhr verfügbar...
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?
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() }) }
Hi Beta-Tester,
ich sehe mal zu, das ich es hinbekomme um dir Rückmeldung zu geben.
Danke aber schon mal.
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.
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
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.
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
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
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.
Auch MQTT2_DEVICE kann man haben, muss aber dann "DEVICE" schützen:
MQTT2_\DEVICE
Sonst: :) 8)
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
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).
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
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?
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).
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.
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.
[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]
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?
- periodicCmd -> deleteReadings:1440
- setList -> deleteReadings:noArg {fhem "deletereading -q $NAME (?!LWT|attrTemplateVersion|state|subscriptions).* 86400"}
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?
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 ::) ...
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.
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.
Thx, hab's übernommen und hoffe, dass es in der jetzigen Form auch weiter mit anderen Sprachsteuerungslösungen kompatibel ist...
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
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.
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
Wenn ich was zum Nachstellen bekomme (bitte ohne Hardware), dann werde ich das untersuchen.
Zitat von: rudolfkoenig am 03 März 2021, 10:41:50
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...
@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!
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
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?
Zitat von: Beta-User am 07 April 2021, 15:26:46
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.
Zitat von: Beta-User am 07 April 2021, 15:26:46
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.
Zitat von: Beta-User am 07 April 2021, 15:26:46
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
Zitat von: Beta-User am 07 April 2021, 15:26:46
Die "slide" sind vermutlich jeweils Typos?
Ups, ja.
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>
?
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?
Zitat von: Beta-User am 08 Mai 2021, 15:11:52Btw.: 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)
Zitat von: Beta-User am 08 Mai 2021, 15:11:52
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?
Zitat2021-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 ::)
Zitatgibt es ein Reading IPAddress?
gab es bisher - ja. Das wird jetzt nicht mehr bedient :'(
Zitat von: Otto123 am 08 Mai 2021, 15:58:07
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?
ZitatEs kommen auch ganz neue Topics:
2021.05.08 15:34:46 2: autocreate: define MQTT2_tasmota MQTT2_DEVICE tasmota mqtt2s
attr 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!)
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
Zitat 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
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 ;) .
Zitatdass 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.
_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) }
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 ?
Zitat von: TomLee am 10 Mai 2021, 15:10:24
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...?
[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
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...)
@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
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.
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.
Danke, hab's eingecheckt ;)
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.
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
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 :
Kannst du mal devStateIcon aus der Vorgänger-Version testen? Ich vermute, das "fett ein-aus" hatte doch eine Funktion...
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.
Zur Sicherheit: das LWT-Reading ist auf Online, aber der Punkt rot?
(Werte werden gelöscht, das dauert uU. etwas.)
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!
Danke erst mal für die Rückmeldung, dass
Zitat von: Beta-User am 24 Mai 2021, 19:18:55
vermute, das "fett ein-aus" hatte doch eine Funktion...
zutreffend war.
Trotzdem finde ich den Hinweis an sich von hier berechtigt:
Zitat von: yersinia am 07 Mai 2021, 16:14:00
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>
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
Zitat von: Otto123 am 29 Mai 2021, 21:28:55
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.)
ZitatWenn 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.
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?)
ZitatIch 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.
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_
Ich wuerde jetzt eine Wette anbieten, dass da hinten ein unsichtbares Zeichen herumlungert.
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
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?
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.
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.
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)
Zitat von: rudolfkoenig am 03 Juni 2021, 15:24:10
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).
Zitat 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)
Wie wahr...
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.
$hash->{IODev} enthaelt den "Zeiger", damit es schneller geht.
Versuchs mal mit { InternalVal('DEVICE', 'IODev', '')->{NAME} }
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.
ZitatWenn 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.
Hab das nur in Erinnerung dass das in dem fhem2mqttfhem-Faden (oder ähnlicher Name) mal der Fall war, also nicht als Anwender.
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 ?
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.
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
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?
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.
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
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...
ZitatBin 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.
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?
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.
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.
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.
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.)
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.
Danke für den Hinweis, auch an TomLee wg. des DEVICETOPIC-Themas.
Update folgt bei Gelegenheit.
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
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 :) .
Ich habe da mal ne Frage. Ich würde gerne in den Templates die Icons etwas abändern.
Im devStateIcon steht ja z.B. folgendes:
my $light = FW_makeImage(ReadingsVal($name,"state","off"));
Kann mir jemand erklären wie die Argumente für FW_makeImage ein Icon ergeben ? Hier wird doch der State übegeben und kein Icon ?
Laut Doku zu FW_makeImage (https://wiki.fhem.de/wiki/DevelopmentFHEMWEB-API (https://wiki.fhem.de/wiki/DevelopmentFHEMWEB-API)):
lauten die Parameter ja
$html = FW_makeImage($icon, $text, $class);
Gibt es irgendwie, irgendwo eine versteckte Funktion die aus dem State und dem Namen des Gerätes ein Standard Icon zaubert ?
(Fast) korrekt, es wird der Textinhalt von "state" übergeben. Da die "typischen" on/off-state-Wörter aber zugleich Icon-Namen sind, klappt das...
(Die beiden weiteren Argumente scheinen optional zu sein, war mit bisher nicht aufgefallen, dass es die gibt).
ZitatGibt es irgendwie, irgendwo eine versteckte Funktion die aus dem State und dem Namen des Gerätes ein Standard Icon zaubert ?
FW_dev2image macht sowas.
Die Reihenfolge bei der Bildersuche ist:
$icon = FW_iconName("$name.$state") if(!$icon); # lamp.Aus.png
$icon = FW_iconName("$name.$rstate") if(!$icon); # lamp.on.png
$icon = FW_iconName($name) if(!$icon); # lamp.png
$icon = FW_iconName("$model.$state") if(!$icon && $model); # fs20st.off.png
$icon = FW_iconName($model) if(!$icon && $model); # fs20st.png
$icon = FW_iconName("$type.$state") if(!$icon); # FS20.Aus.png
$icon = FW_iconName("$type.$rstate") if(!$icon); # FS20.on.png
$icon = FW_iconName($type) if(!$icon); # FS20.png
$icon = FW_iconName($state) if(!$icon); # Aus.png
$icon = FW_iconName($rstate) if(!$icon); # on.png
wobei $state der angezeigte Status ist, und $rstate der Status vor eventMap.
Den .png Zusatz im Kommentar bitte ignorieren.
Bild-Dateien umbenennen muss man nicht, dafuer gibts die Datei /opt/FHEM/www/images/*/iconAlias.txt
Moin zusammen,
erstmal klasse! Was schon alles gut funktioniert. Ich bin seit ein paar Tagen mit zigbee2mqtt unterwegs und muss noch einige Dinge ergründen.
Einige Devices laufen schon recht gut, an dieser Stelle vielen Dank für das Template.
Dann hätte ich zwei Fragen in Verbindung mit einer "Hue white and color ambiance".
- Ein Klick auf die Schaltfläche "white" macht ein gelbes Licht. Wo könnte ich das einstellen/verbessern?
- An Stelle des Colorpickers(?) ("FFFFFF") wäre ein Farbslider sehr schön. Den kriege ich auf keinen Fall hin, probiere schon seit ein paar Stunden, hier fehlen die Kenntnisse. Könnte das Template dahingehend erweitert werden?
VG Helmut
So, Dank meines Kumpels sind wir mit der "Hue white and color ambiance". weiter.
Diese Def sieht am GUI schon recht gut aus, allerdings gibt es eine FM, die ich leider nicht deuten kann.
Die Farb-Icons sind super und die Funktionen für "warm" und "white" erzeugen die richtigen Farben.
defmod MQTT2_zigbee_HUE_Leuchte MQTT2_DEVICE zigbee_HUE_Leuchte
attr MQTT2_zigbee_HUE_Leuchte alias HUE-Leuchte
attr MQTT2_zigbee_HUE_Leuchte devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_zigbee_HUE_Leuchte devicetopic zigbee2mqtt/HUE_Leuchte
attr MQTT2_zigbee_HUE_Leuchte icon hue_filled_white_and_color_e27_b22
attr MQTT2_zigbee_HUE_Leuchte jsonMap color_temp:ct
attr MQTT2_zigbee_HUE_Leuchte model zigbee2mqtt_light_rgbw_hex
attr MQTT2_zigbee_HUE_Leuchte readingList $DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr MQTT2_zigbee_HUE_Leuchte room MQTT2_DEVICE
attr MQTT2_zigbee_HUE_Leuchte setList on:noArg $DEVICETOPIC/set {"state":"ON"}\
off:noArg $DEVICETOPIC/set {"state":"OFF"}\
warm:noArg $DEVICETOPIC/set {"brightness": 200 , "color_temp": 360}\
white:noArg $DEVICETOPIC/set {"brightness": 254, "color_temp": 250}\
ct:colorpicker,CT,250,1,454 $DEVICETOPIC/set {"color_temp":"$EVTPART1"}\
brightness:colorpicker,BRI,0,5,255 $DEVICETOPIC/set {"state":"on","$EVTPART0":"$EVTPART1"}\
hex:colorpicker,HEX,0,15,255 $DEVICETOPIC/set {"color":{"$EVTPART0":"#$EVTPART1"}}
attr MQTT2_zigbee_HUE_Leuchte stateFormat {lc ReadingsVal($name,"state",0)}
attr MQTT2_zigbee_HUE_Leuchte userReadings hex:color_y.* {Color::xyY2hex(ReadingsVal($name,"color_x",0),ReadingsVal($name,"color_y",0),ReadingsVal($name,"brightness",254))}
attr MQTT2_zigbee_HUE_Leuchte webCmd toggle:on:off:brightness:ct:warm:white:hex:hex ff0000:hex 98ff23:hex 0000ff
setstate MQTT2_zigbee_HUE_Leuchte on
setstate MQTT2_zigbee_HUE_Leuchte 2022-01-09 13:25:48 IODev MyMQTT
setstate MQTT2_zigbee_HUE_Leuchte 2022-01-09 13:25:48 associatedWith MQTT2_zigbee_pi
setstate MQTT2_zigbee_HUE_Leuchte 2022-01-09 13:26:56 attrTemplateVersion 20211018
setstate MQTT2_zigbee_HUE_Leuchte 2022-01-09 13:27:25 brightness 254
setstate MQTT2_zigbee_HUE_Leuchte 2022-01-09 13:27:25 color_hue 40
setstate MQTT2_zigbee_HUE_Leuchte 2022-01-09 13:27:25 color_mode color_temp
setstate MQTT2_zigbee_HUE_Leuchte 2022-01-09 13:27:25 color_saturation 49
setstate MQTT2_zigbee_HUE_Leuchte 2022-01-09 13:25:53 color_temp 366
setstate MQTT2_zigbee_HUE_Leuchte 2022-01-09 13:27:25 color_x 0.3804
setstate MQTT2_zigbee_HUE_Leuchte 2022-01-09 13:27:25 color_y 0.3767
setstate MQTT2_zigbee_HUE_Leuchte 2022-01-09 13:27:25 ct 250
setstate MQTT2_zigbee_HUE_Leuchte 2022-01-09 13:27:25 hex Error evaluating MQTT2_zigbee_HUE_Leuchte userReading hex: Undefined subroutine &Color::xyY2hex called at (eval 715) line 1.\
setstate MQTT2_zigbee_HUE_Leuchte 2022-01-09 13:27:25 linkquality 92
setstate MQTT2_zigbee_HUE_Leuchte 2022-01-09 13:27:25 state ON
setstate MQTT2_zigbee_HUE_Leuchte 2022-01-09 13:27:25 update_available false
setstate MQTT2_zigbee_HUE_Leuchte 2022-01-09 13:27:25 update_state idle
im File mqtt2.template scheint sich oben ein "</a>" davon gemacht zu haben, sodass ein recht großer Bereich zu einem einzigen Link wird (wenn ich "set <Device-Name> attrTemplate ?") aufrufe:
...
name:General_Info
filter:TYPE=MQTT2_DEVICE
desc: <a href="https://forum.fhem.de/index.php/topic,94495.0.html">Forum Thread for <br>- suggesting ...
wahrscheinlich war es vorher so:
...
desc: <a href="https://forum.fhem.de/index.php/topic,94495.0.html">Forum Thread</a> for <br>- suggesting ...
Nix tragisches. Wollte das nur rückmelden.
VG
rob
Habs schnell gefixt, hoffentlich nicht zu schnell. Beta-User ist schon wieder wach :)
Zitat von: Otto123 am 12 Januar 2022, 10:02:36
Habs schnell gefixt, hoffentlich nicht zu schnell. Beta-User ist schon wieder wach :)
:) Paßt schon, ich hätte halt bei der Gelegenheit (demnächst) noch das Tasmota-BT-Bridge-Ding mit eingecheckt (und hoffe noch darauf, dass jemand einen Vorschlag für das "Flora" liefert).
Dann hänge ich grade im Zusammenhang mit zigbee2mqtt noch an zwei Punkten:
- zum einen gibt es Hardware, die die "hue"-Endpunkte verstehen. Für die wäre eigentlich ein "dreifach-Regler" wie (oberhalb) https://wiki.fhem.de/wiki/Color#echtes_HSV sinnvoll. Wenn ich es richtig verstehe, gibt das dann ein Werte-Tripple zurück, das man auch für Einzelreadings wie "sat" und "hue" benutzen könnte...? Also falls jemand so eine Hardware hat und "basteln" will: Gerne (Rückmeldung/Fragen aber bitte entweder in z2m-Thread oder einen neuen aufmachen).
- zum anderen war irgendwo jüngst hier ein "list" für das Lidl-Lichterketten-Ding zu sehen mit "schlechten" userReadings, aber vielen Szenen-Settern. Wäre m.e. auch ein gutes Beispiel...
@Otto: Danke auch für die Klarstellung im "wie geht das"-Thread, habe das als Anregung genommen, im Wiki an diversen Stellen noch Hinweise zu verteilen :) .
Hi, gibt es denn schon ein Template für die neuen Shelly TRV?
Habe meine heute bekommen und kann gern Daten zur Verfügun stellen wenn ihr mir sagt was ihr braucht.
hie rmal ein list vom Devce was das autocreate angelegt hat:
Internals:
CID shellytrv_60A423D3F804
DEF shellytrv_60A423D3F804
DEVICETOPIC MQTT2_shellytrv_60A423D3F804
FUUID 61e01599-f33f-34fb-cd84-693f36df04504f3c
IODev fhemprod.MQTT2Server
LASTInputDev fhemprod.MQTT2Server
MSGCNT 3
NAME MQTT2_shellytrv_60A423D3F804
NR 368
STATE ???
TYPE MQTT2_DEVICE
fhemprod.MQTT2Server_CONN fhemprod.MQTT2Server_192.168.2.88_52436
fhemprod.MQTT2Server_MSGCNT 3
fhemprod.MQTT2Server_TIME 2022-01-13 13:10:15
Helper:
DBLOG:
ram_free:
DBLogging:
TIME 1642075815.26559
VALUE 30784
thermostats_1_tmp_value:
DBLogging:
TIME 1642075815.26559
VALUE 23.7
time:
DBLogging:
TIME 1642075815.26559
VALUE 13:10
unixtime:
DBLogging:
TIME 1642075815.26559
VALUE 1642075814
uptime:
DBLogging:
TIME 1642075815.26559
VALUE 143
wifi_sta_rssi:
DBLogging:
TIME 1642075815.26559
VALUE -55
READINGS:
2022-01-13 13:10:11 IODev fhemprod.MQTT2Server
2022-01-13 13:10:15 actions_stats_skipped 0
2022-01-13 13:10:15 bat_value 100
2022-01-13 13:10:15 bat_voltage 4.134
2022-01-13 13:08:03 build_info_build_id 20211223-144805/v2.1.0@d30148ec
2022-01-13 13:08:03 build_info_build_timestamp 2021-12-23T14:48:05Z
2022-01-13 13:08:03 build_info_build_version 2021122314
2022-01-13 13:10:15 calibrated true
2022-01-13 13:10:15 cfg_changed_cnt 0
2022-01-13 13:10:15 charger false
2022-01-13 13:08:03 child_lock false
2022-01-13 13:10:15 cloud_connected false
2022-01-13 13:10:15 cloud_enabled false
2022-01-13 13:08:03 coiot_enabled true
2022-01-13 13:08:03 coiot_peer 192.168.2.33:5683
2022-01-13 13:08:03 coiot_update_period 3600
2022-01-13 13:10:15 dbg_flags 0
2022-01-13 13:08:03 device_hostname shellytrv-60A423D3F804
2022-01-13 13:08:03 device_mac 60A423D3F804
2022-01-13 13:08:03 device_num_outputs 0
2022-01-13 13:08:03 device_type SHTRV-01
2022-01-13 13:08:03 discoverable true
2022-01-13 13:08:03 display_brightness 4
2022-01-13 13:08:03 display_flipped false
2022-01-13 13:10:15 fs_free 59504
2022-01-13 13:10:15 fs_size 65536
2022-01-13 13:08:03 fw 20211223-144805/v2.1.0@d30148ec
2022-01-13 13:10:15 fw_info_device shellytrv-60A423D3F804
2022-01-13 13:10:15 fw_info_fw 20211223-144805/v2.1.0@d30148ec
2022-01-13 13:10:15 fw_ver 20211223-144805/v2.1.0@d30148ec
2022-01-13 13:10:15 has_update false
2022-01-13 13:08:03 hwinfo_batch_id 0
2022-01-13 13:08:03 hwinfo_hw_revision dev-prototype
2022-01-13 13:10:15 id shelly-eg-wz-heizung-1
2022-01-13 13:10:15 ip 192.168.2.88
2022-01-13 13:08:03 lat 49.865710
2022-01-13 13:08:03 lng 8.626040
2022-01-13 13:08:03 login_default_username admin
2022-01-13 13:08:03 login_enabled false
2022-01-13 13:08:03 login_unprotected false
2022-01-13 13:08:03 login_username admin
2022-01-13 13:10:15 mac 60A423D3F804
2022-01-13 13:10:15 model SHTRV-01
2022-01-13 13:08:03 mqtt_clean_session true
2022-01-13 13:10:15 mqtt_connected true
2022-01-13 13:08:03 mqtt_enable true
2022-01-13 13:08:03 mqtt_id shelly-eg-wz-heizung-1
2022-01-13 13:08:03 mqtt_max_qos 0
2022-01-13 13:08:03 mqtt_retain false
2022-01-13 13:08:03 mqtt_server 192.168.2.45:1883
2022-01-13 13:08:03 mqtt_update_period 60
2022-01-13 13:08:03 mqtt_user fhemuser
2022-01-13 13:08:03 name shelly-eg-wz-heizung-1
2022-01-13 13:10:15 new_fw false
2022-01-13 13:10:15 online true
2022-01-13 13:08:03 pin_code
2022-01-13 13:10:15 ps_mode 0
2022-01-13 13:10:15 ram_free 30784
2022-01-13 13:10:15 ram_total 97280
2022-01-13 13:10:15 serial 0
2022-01-13 13:08:03 sleep_mode_period 60
2022-01-13 13:08:03 sleep_mode_unit m
2022-01-13 13:08:03 sntp_enabled true
2022-01-13 13:08:03 sntp_server time.google.com
2022-01-13 13:08:03 thermostats_1_ext_t_enabled false
2022-01-13 13:10:15 thermostats_1_pos 100.0
2022-01-13 13:10:15 thermostats_1_schedule false
2022-01-13 13:10:15 thermostats_1_schedule_profile 0
2022-01-13 13:08:03 thermostats_1_schedule_profile_names_1 Livingroom
2022-01-13 13:08:03 thermostats_1_schedule_profile_names_2 Livingroom 1
2022-01-13 13:08:03 thermostats_1_schedule_profile_names_3 Bedroom
2022-01-13 13:08:03 thermostats_1_schedule_profile_names_4 Bedroom 1
2022-01-13 13:08:03 thermostats_1_schedule_profile_names_5 Holiday
2022-01-13 13:10:15 thermostats_1_target_t_enabled false
2022-01-13 13:10:15 thermostats_1_target_t_units C
2022-01-13 13:10:15 thermostats_1_target_t_value 31.0
2022-01-13 13:08:03 thermostats_1_temperature_offset 0.0
2022-01-13 13:10:15 thermostats_1_tmp_is_valid true
2022-01-13 13:10:15 thermostats_1_tmp_units C
2022-01-13 13:10:15 thermostats_1_tmp_value 23.7
2022-01-13 13:10:15 time 13:10
2022-01-13 13:08:03 timezone Europe/Berlin
2022-01-13 13:08:03 tz_dst false
2022-01-13 13:08:03 tz_dst_auto true
2022-01-13 13:08:03 tz_utc_offset 3600
2022-01-13 13:08:03 tzautodetect true
2022-01-13 13:10:15 unixtime 1642075814
2022-01-13 13:10:15 update_has_update false
2022-01-13 13:10:15 update_new_version 20211223-144805/v2.1.0@d30148ec
2022-01-13 13:10:15 update_old_version 20211223-144805/v2.1.0@d30148ec
2022-01-13 13:10:15 update_status unknown
2022-01-13 13:10:15 uptime 143
2022-01-13 13:08:03 wifi_ap_enabled false
2022-01-13 13:08:03 wifi_ap_ssid shellytrv-60A423D3F804
2022-01-13 13:10:15 wifi_sta_connected true
2022-01-13 13:08:03 wifi_sta_dns 192.168.2.1
2022-01-13 13:08:03 wifi_sta_enabled true
2022-01-13 13:08:03 wifi_sta_gw 192.168.2.1
2022-01-13 13:10:15 wifi_sta_ip 192.168.2.88
2022-01-13 13:08:03 wifi_sta_ipv4_method static
2022-01-13 13:08:03 wifi_sta_mask 255.255.255.0
2022-01-13 13:10:15 wifi_sta_rssi -55
2022-01-13 13:10:15 wifi_sta_ssid AD.NET IOT
Attributes:
event-on-change-reading .*
readingList shellytrv_60A423D3F804:shellies/shelly-eg-wz-heizung-1/online:.* online
shellytrv_60A423D3F804:shellies/shelly-eg-wz-heizung-1/announce:.* { json2nameValue($EVENT) }
shellytrv_60A423D3F804:shellies/shelly-eg-wz-heizung-1/info:.* { json2nameValue($EVENT) }
shellytrv_60A423D3F804:shellies/shelly-eg-wz-heizung-1/settings:.* { json2nameValue($EVENT) }
room SYSTEM->DEVICES->MQTT2_DEVICE
Zitat von: bicmac am 13 Januar 2022, 13:14:57
Hi, gibt es denn schon ein Template für die neuen Shelly TRV?
Nein. Damit hast du dich erfolgreich für die dankbare Aufgabe beworben :P ...
Im Ernst: Das Ding ist - einmal mehr - ziemlich speziell, aber immerhin scheint es sich (mind.) stündlich zu melden.
Vermutlich kannst du die Grundfunktionen relativ schnell zusammenschustern, wenn du dir die attrTemplate für die zigbee2mqtt-TRV's mal ansiehst, ggf. die zugehörigen Threads überfliegst und dich etwas mit den Grundlagen befasst (wie jsonMap).
Sowas wie weekprofile dafür zu basteln, wird wohl eine größere Sache, weil überhaupt nicht klar ist, wie man sich das beim Hersteller gedacht hat.
Fang' doch dazu bitte einen separaten Thread an, den wir dann vielleicht auch gleich dazu nutzen können, den Wiki-Artikel zu verbessern: https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt (https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt)
Wenn ich das könnte hätte ich es ja getan :-) Aber im Ernst ich bin da eher DAU user und consumer. Ich verstehe das mit dem Templates nicht wirklich.
Ich denke nur die Teile werden ja mehr User haben als ich und hoffe das irgendwer es schafft die einzubinden. Denn ich kann sie momentan sonst nicht nutzen da ich die Shelly Ap nicht benutze sondern ale Shellys über FHEM und MQTT2 anspreche.
.....
Zitat von: Beta-User am 13 Januar 2022, 13:24:44
Nein. Damit hast du dich erfolgreich für die dankbare Aufgabe beworben :P ...
Im Ernst: Das Ding ist - einmal mehr - ziemlich speziell, aber immerhin scheint es sich (mind.) stündlich zu melden.
Vermutlich kannst du die Grundfunktionen relativ schnell zusammenschustern, wenn du dir die attrTemplate für die zigbee2mqtt-TRV's mal ansiehst, ggf. die zugehörigen Threads überfliegst und dich etwas mit den Grundlagen befasst (wie jsonMap).
Sowas wie weekprofile dafür zu basteln, wird wohl eine größere Sache, weil überhaupt nicht klar ist, wie man sich das beim Hersteller gedacht hat.
Fang' doch dazu bitte einen separaten Thread an, den wir dann vielleicht auch gleich dazu nutzen können, den Wiki-Artikel zu verbessern: https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt (https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt)
Zitat von: bicmac am 13 Januar 2022, 13:28:44
Wenn ich das könnte hätte ich es ja getan :-) Aber im Ernst ich bin da eher DAU user und consumer. Ich verstehe das mit dem Templates nicht wirklich.
;D ...ungefär so fangen die Threads bei den zigbee2mqtt-Dingern (und viele andere) auch an :P ...
Just do it!
Du mußt es auch nicht als attrTemplate liefern, was wir erst mal benötigen, ist ein "funktionierendes RAW".
Moin,
ich habe mal eine Verständnisfrage zu folgendem readingList:
shellies/announce:.* { $EVENT =~ m,..id...EG_BZ_WS...mac.*, ? json2nameValue($EVENT) : return }
Ich versuche zu verstehen warum der Perl match Operator bei folgendem String funktioniert:
{"id":"EG_BZ_WS","model":"SHSW-1","mac":"xxxxxxxx","ip":"xxxxxxx","new_fw":false,"fw_ver":"20211109-124958/v1.11.7-g682a0db"}
Drei aufeinanderfolgenden Punkte bedeutet doch 3 beliebige Zeichen hintereinander? Wie kann dann "mac" nach EG_BZ_WS Matchen?
Viele Grüße
Basti
Hi Basti,
warum bist Du der Meinung das es matched? Kann eigentlich nicht.
Gruß Otto
Hallo Otto,
Du hast natürlich Recht. Das Device hat noch ein weiteres readingList.
shellies/EG_BZ_WS/announce:.* { json2nameValue($EVENT) }
Dadurch greift das globale announce nicht. https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L2524
Ein Bugfix kann man nur übers SVN einkippen?
VG
Basti
Zitat von: travelling-man am 13 Januar 2022, 19:23:13
shellies/announce:.* { $EVENT =~ m,..id...EG_BZ_WS...mac.*, ? json2nameValue($EVENT) : return }
{"id":"EG_BZ_WS","model":"SHSW-1","mac":"xxxxxxxx","ip":"xxxxxxx","new_fw":false,"fw_ver":"20211109-124958/v1.11.7-g682a0db"}
Zitat von: travelling-man am 13 Januar 2022, 23:49:44
shellies/EG_BZ_WS/announce:.* { json2nameValue($EVENT) }
Mit den angegebenen Informationen ist klar, dass - abhängig vom
Topic - nur ein Eintrag aus readingList relevant sein kann. Der eine Eintrag verarbeitet allgemeine Events, der andere Eintrag die speziell für das FHEM-Device gedachten Events.
Wenn Du sagst, dass der von Dir angegebene
Payload verarbeitet wurde, kann er nur zu einem der beiden Einträge passen ... der mit der Bedingung kann es schon mal nicht sein ... bei der Ermittlung, welcher Eintrag relevant ist, spielt allerdings der Payload gar keine Rolle ... das Topic alleine entscheidet bei den von Dir genannten Einträgen aus der readingList.
Mir erscheint die formulierte Bedingung im allgemeinen Eintrag auch verbesserungswürdig ... klar, man will den Payload nur verarbeiten, wenn er für das betrachtete FHEM-Device gedacht ist ... aber wieso klammert man sich zusätzlich an "mac", denn generell kann "mac" irgendwo vor oder hinter der "id" stehen ... übrigens ist auch die "id" nicht generell auf den Anfang des Payloads fixiert, was die beiden Punkte am Anfang des regulären Ausdrucks suggerieren könnten - die beiden Punkte stehen für beliebige Zeichen und nicht zwanghaft für {" ...
***
Jeder kann Verbesserungsvorschläge machen, aber nicht jeder kann diese selbst für die Allgemeinheit ins SVN einstellen ... interessant wäre jetzt vermutlich, wie Dein Bugfix aussieht ... "(weiter)entwickeln" und "austesten" kann man ja vorab nach Herzenslust auf seinem eigenen System ...
Was dieses "announce"-Topic angeht, war ich schon immer skeptisch, ob man das braucht, und wenn es (meistens?) untauglich ist, stellt sich die Frage, ob man das nicht ganz "erden" sollte und (zusätzlich) empfehlen, diesen Zweig in "ignoreRegexp" zu ergänzen (statt das zu "verbessern")...
[partly OT]
Könnte evtl. jemand isy den "Knopf" zeigen, wie man bei dem shellyplus1 das "generic status update via MQTT" einschaltet... (https://forum.fhem.de/index.php/topic,125408.0.html (https://forum.fhem.de/index.php/topic,125408.0.html))
Hallo zusammen, arbeitet schon jemand an einem Template für den Shelly Uni?
Hier ein List vom Device so wie es vom Autocreate angelegt wurde:
Internals:
CFGFN
CID shellyuni_98CDAC2514D0
DEF shellyuni_98CDAC2514D0
DEVICETOPIC MQTT2_shellyuni_98CDAC2514D0
FUUID 61ee089b-f33f-7637-2fd5-b0408adf85b24269
IODev MQTT2
LASTInputDev MQTT2
MQTT2_MSGCNT 6310
MQTT2_TIME 2022-01-24 16:14:56
MSGCNT 6310
NAME MQTT2_shellyuni_98CDAC2514D0
NR 461
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2022-01-24 15:43:27 0_event
2022-01-24 15:43:27 0_event_cnt 0
2022-01-24 15:43:27 1_event
2022-01-24 15:43:27 1_event_cnt 0
2022-01-24 15:43:27 announce_fw_ver 20211109-131507/v1.11.7-g682a0db
2022-01-24 15:43:27 announce_id shellyuni-98CDAC2514D0
2022-01-24 15:43:27 announce_ip *****
2022-01-24 15:43:27 announce_mac 98CDAC2514D0
2022-01-24 15:43:27 announce_model SHUNI-1
2022-01-24 15:43:27 announce_new_fw false
2022-01-24 15:43:27 info_actions_stats_skipped 0
2022-01-24 15:43:27 info_adcs_1_voltage 0.00
2022-01-24 15:43:27 info_cfg_changed_cnt 0
2022-01-24 15:43:27 info_cloud_connected false
2022-01-24 15:43:27 info_cloud_enabled false
2022-01-24 15:43:27 info_fs_free 147086
2022-01-24 15:43:27 info_fs_size 233681
2022-01-24 15:43:27 info_has_update false
2022-01-24 15:43:27 info_inputs_1_event
2022-01-24 15:43:27 info_inputs_1_event_cnt 0
2022-01-24 15:43:27 info_inputs_1_input 0
2022-01-24 15:43:27 info_inputs_2_event
2022-01-24 15:43:27 info_inputs_2_event_cnt 0
2022-01-24 15:43:27 info_inputs_2_input 0
2022-01-24 15:43:27 info_mac 98CDAC2514D0
2022-01-24 15:43:27 info_mqtt_connected true
2022-01-24 15:43:27 info_ram_free 37488
2022-01-24 15:43:27 info_ram_total 49984
2022-01-24 15:43:27 info_relays_1_has_timer false
2022-01-24 15:43:27 info_relays_1_ison false
2022-01-24 15:43:27 info_relays_1_source input
2022-01-24 15:43:27 info_relays_1_timer_duration 0
2022-01-24 15:43:27 info_relays_1_timer_remaining 0
2022-01-24 15:43:27 info_relays_1_timer_started 0
2022-01-24 15:43:27 info_relays_2_has_timer false
2022-01-24 15:43:27 info_relays_2_ison false
2022-01-24 15:43:27 info_relays_2_source input
2022-01-24 15:43:27 info_relays_2_timer_duration 0
2022-01-24 15:43:27 info_relays_2_timer_remaining 0
2022-01-24 15:43:27 info_relays_2_timer_started 0
2022-01-24 15:43:27 info_serial 1
2022-01-24 15:43:27 info_time 15:43
2022-01-24 15:43:27 info_unixtime 1643035406
2022-01-24 15:43:27 info_update_has_update false
2022-01-24 15:43:27 info_update_new_version 20211109-131507/v1.11.7-g682a0db
2022-01-24 15:43:27 info_update_old_version 20211109-131507/v1.11.7-g682a0db
2022-01-24 15:43:27 info_update_status idle
2022-01-24 15:43:27 info_uptime 162472
2022-01-24 15:43:27 info_wifi_sta_connected true
2022-01-24 15:43:27 info_wifi_sta_ip *****
2022-01-24 15:43:27 info_wifi_sta_rssi -68
2022-01-24 15:43:27 info_wifi_sta_ssid *****
2022-01-24 16:14:56 input_0 0
2022-01-24 16:14:56 input_1 0
2022-01-24 15:43:27 online true
2022-01-24 16:14:56 relay_0 off
2022-01-24 16:14:56 relay_1 off
Attributes:
IODev MQTT2
readingList shellyuni_98CDAC2514D0:shellies/shellyuni-98CDAC2514D0/online:.* online
shellyuni_98CDAC2514D0:shellies/shellyuni-98CDAC2514D0/announce:.* { json2nameValue($EVENT, 'announce_', $JSONMAP) }
shellyuni_98CDAC2514D0:shellies/shellyuni-98CDAC2514D0/info:.* { json2nameValue($EVENT, 'info_', $JSONMAP) }
shellyuni_98CDAC2514D0:shellies/shellyuni-98CDAC2514D0/relay/0:.* relay_0
shellyuni_98CDAC2514D0:shellies/shellyuni-98CDAC2514D0/relay/1:.* relay_1
shellyuni_98CDAC2514D0:shellies/shellyuni-98CDAC2514D0/input/0:.* input_0
shellyuni_98CDAC2514D0:shellies/shellyuni-98CDAC2514D0/input_event/0:.* { json2nameValue($EVENT, '0_', $JSONMAP) }
shellyuni_98CDAC2514D0:shellies/shellyuni-98CDAC2514D0/input/1:.* input_1
shellyuni_98CDAC2514D0:shellies/shellyuni-98CDAC2514D0/input_event/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
room MQTT2_DEVICE
Danke für eure Unterstützung!
Viele Grüße
Christian
Paßt das "shelly25_split" nicht auch dafür?
Zitat von: Beta-User am 25 Januar 2022, 10:53:31
Paßt das "shelly25_split" nicht auch dafür?
Ich probiere es aus und melde mich wieder
Zitat von: Beta-User am 25 Januar 2022, 10:53:31
Paßt das "shelly25_split" nicht auch dafür?
Hallo Beta-User,
grundsätzlich passt das zum schalten mit den beiden Kanälen. Die Temperaturanzeigen in der Übersicht funktionieren logischerweise nicht und wie es mit messen und den übrigen Funktionen des UNI aussieht kann ich nicht sagen, weil ich es nicht getestet habe. Aber Eingänge lesen und Ausgänge schalten funktioniert.
Eine Anpassung speziell für den UNI wäre aber wahrscheinlich für eine vollständige Unterstützung erforderlich. Leider bin ich dazu überhaupt nicht kompetent.
Danke für den Tipp mit dem shelly25_split. Mein Problem ist damit erstmal erledigt.
Viele Grüße
Christian
Zitat von: Brandensittich am 28 Januar 2022, 10:09:29
grundsätzlich passt das zum schalten mit den beiden Kanälen. Die Temperaturanzeigen in der Übersicht funktionieren logischerweise nicht und wie es mit messen und den übrigen Funktionen des UNI aussieht kann ich nicht sagen, weil ich es nicht getestet habe. Aber Eingänge lesen und Ausgänge schalten funktioniert.
Vielleicht machst du für das Thema einen separaten Thread auf oder hängst dich an den "allgemeinen Shelly-Thread" mit dran (da sind ein paar Leute, die die Hardware - im Unterschied zu mir - vielleicht auch haben)?
Auf Basis des von dir gezeigten list kann ich dir nicht so recht folgen. Der UNI hatte bis dato nur die Schaltzustände geliefert, und der Teil sollte mit dem "kleinen split"-template zusammenpassen.
Neuerdings scheint man aber zumindest Infos über laufende timer zu bekommen...?
Hallo.
Habe jetzt endlich mal, teilw. erfolgreich auf MQTT2_SERVER & DEVICE von mosquitto + MQTT + TASMOTA_DEVICE (abgekündigt) umgestellt.
Einfache Sonoff basic's mit tasmota funktionieren einwandfrei.
Jetzt habe ich aber einen SOnoff Basic mit an den IN's angeschlossenen Betten Sensoren, diese werden wie folgt gesendet im Tasmota LOG:
19:56:23 MQT: /smarthome/sz/bedsensor/cmnd/POWER2 = ON
19:56:23 MQT: /smarthome/sz/bedsensor/stat/RESULT = {"Command":"Error"}
19:56:24 MQT: /smarthome/sz/bedsensor/cmnd/POWER2 = OFF
19:56:24 MQT: /smarthome/sz/bedsensor/stat/RESULT = {"Command":"Error"}
19:56:24 MQT: /smarthome/sz/bedsensor/cmnd/POWER2 = ON
19:56:24 MQT: /smarthome/sz/bedsensor/cmnd/POWER2 = OFF
19:56:24 MQT: /smarthome/sz/bedsensor/stat/RESULT = {"Command":"Error"}
19:56:25 MQT: /smarthome/sz/bedsensor/stat/RESULT = {"Command":"Error"}
19:56:25 MQT: /smarthome/sz/bedsensor/cmnd/POWER2 = ON
19:56:25 MQT: /smarthome/sz/bedsensor/stat/RESULT = {"Command":"Error"}
19:56:40 MQT: /smarthome/sz/bedsensor/cmnd/POWER2 = OFF
19:56:40 MQT: /smarthome/sz/bedsensor/stat/RESULT = {"Command":"Error"}
Wie kann ich das nun dem MQTT2 device beibringen damit das auch POWER2 & POWER3 übersetzt?
Danke
Zitat von: popy am 29 Januar 2022, 20:03:56
Wie kann ich das nun dem MQTT2 device beibringen damit das auch POWER2 & POWER3 übersetzt?
Indem du ggf. einfach die betreffenden Topics abonnierst...?
Kann sein, dass das "basic"-attrTemplate das Attribut "autocreate" am MQTT2_DEVICE auf 0 stellt - das dann ggf. ändern, dann sollten die weiteren Topics automatisch erkannt werden. (Wobei: Da ist Großschreibung - ist da überhaupt ein attrTemplate im Spiel gewesen?!?)
Na jedenfalls:
Falls du nicht mit obigem Hinweis bereits weiterkommst, empfehle ich die Lektüre von https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt.
Falls du damit dann auch nicht weiterkommst, mach bitte einen neuen Thread auf und liefere alle Infos, die in https://forum.fhem.de/index.php/topic,112327.0.html zu finden sind.
Nabend,
ich habe gerade ein update gefahren. Nun habe ich eine zigbee2mqtt Gruppe erstellt und wollte sie manuell adden ( wie ich hier gelesen hatte : https://forum.fhem.de/index.php/topic,91394.msg908357.html#msg908357 ).
Leider finde ich im template die zigbee2mqtt_light_dimmer
in der Datei /opt/fhem/FHEM/lib/AttrTemplate/mqtt2.template sehe ich es aber.
Habe schon einen anderen Browser funktioniert. Die attr Liste sieht irgendwie anders aus als sonst - ich kann es aber nicht beschreiben / erklären
Kann jemand helfen?
EDIT: Ich vermute, dass es an der fehlenden CID liegt.
Edit2: Nach dem einmaligen Aus/Ein Schalten wurde per autocreate ein neues Objekt erstellt. Dieses konnte ich normal das template zuweisen.
Somit erledigt. Nur falls es noch wer hat, lasse ich es hier drin, wenn iO.
Zitat 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
Warum wurde das OpenWB template nicht übernommen oder übersehe ich da was?
Gruß Carlos
Zitat von: carlos am 18 Juni 2022, 11:53:58
Warum wurde das OpenWB template nicht übernommen oder übersehe ich da was?
Na ja, es gab irgendwie (aus meiner Sicht) ein paar offene Punkte (siehe die Folgebeiträge), so dass ich nach wie vor nicht so richtig sicher bin, ob das jetzt irgendwie als "fertig" betrachtet werden soll/kann...
Update: Da die Kommunikation über den "alten / falschen Thread lief, dort aber gelöst wurde, hier der Link dorthin:
https://forum.fhem.de/index.php/topic,129414.msg1237494.html#msg1237494
Sorry noch mal für die Konfusion.
Hallo zusammen,
ich habe diese Lampe von Paul Neuhaus: https://www.zigbee2mqtt.io/devices/NLG-TW_light.html
Über die GUI von Zigbee2MQTT kann ich sie einwandfrei steuern.
In fhem habe ich ihr das mqttTemplate
zigbee2mqtt_light_cct verpasst.
Das funktioniert soweit auch einwandfrei, bis auf eine Kleinigkeit:
Wenn ich über den Color Picker in der GUI von fhem die Farbtemperatur ändere, springt der Slider nach der Einstellung immer wieder auf den Minimalwert zurück.
Dies ist aber nur optisch - die Lampe wird sehr wohl auf die ausgewählte Farbtemperatur eingestellt. Das läßt sich sowohl visuell an der Lampe als auch über den Blick in die Zigbee2MQTT Oberfläche überprüfen, wo der Wert entsprechend abgeändert wird.
Hier die Definition der Lampe in fhem:
defmod MQTT2_zigbee_wz_Sofatisch_Licht MQTT2_DEVICE zigbee_wz_Sofatisch_Licht
attr MQTT2_zigbee_wz_Sofatisch_Licht alias MQTT2_zigbee_wz_Sofatisch_Licht
attr MQTT2_zigbee_wz_Sofatisch_Licht devicetopic zigbee2mqtt/wz_Sofatisch_Licht
attr MQTT2_zigbee_wz_Sofatisch_Licht genericDeviceType light
attr MQTT2_zigbee_wz_Sofatisch_Licht homebridgeMapping Brightness=brightness::brightness,maxValue=100,factor=0.39216,delay=true
attr MQTT2_zigbee_wz_Sofatisch_Licht icon light_control
attr MQTT2_zigbee_wz_Sofatisch_Licht jsonMap color_temp:ct color_temp_startup:ct_startup
attr MQTT2_zigbee_wz_Sofatisch_Licht model zigbee2mqtt_light_cct
attr MQTT2_zigbee_wz_Sofatisch_Licht readingList $DEVICETOPIC:.* { my $ret=json2nameValue($EVENT);; $ret->{state}=lc($ret->{state}) if defined $ret->{state};; return $ret }\
zigbee2mqtt/wz_Sofatisch_Licht/availability:.* availability
attr MQTT2_zigbee_wz_Sofatisch_Licht room MQTT2_DEVICE,Wohnzimmer
attr MQTT2_zigbee_wz_Sofatisch_Licht setList on:noArg $DEVICETOPIC/set {"state":"ON"}\
off:noArg $DEVICETOPIC/set {"state":"OFF"}\
brightness:colorpicker,BRI,0,5,255 $DEVICETOPIC/set {"state":"on","$EVTPART0":"$EVTPART1"}\
ct:colorpicker,CT,153,2,370 $DEVICETOPIC/set {"color_temp":"$EVTPART1"}\
ct_startup:coolest,cool,neutral,warmest,previous $DEVICETOPIC/set {"color_temp_startup":"$EVTPART1"}
attr MQTT2_zigbee_wz_Sofatisch_Licht webCmd toggle:on:off:brightness:ctEinzige Veränderung, die ich gegenüber dem originalen zigbee2mqtt_light_cct vorgenommen habe: Ich habe im setList für den colorpicker den Bereich für die Color Temperature an meine Lampe angepasst (153-370), da ich dachte, dass dies die Ursache für das Problem sein könnte. Das Verhalten ist aber sowohl mit den Originalwerten (154-500) als auch mit meinen angepassten Werten identisch.
Wenn ich die Helligkeit in der GUI von Zigbee2MQTT ändere, wird diese auch korrekt in in fhem Web dargestellt - ändere ich die Color Temperature bleibt der slider in fhem unbeeindruckt auf der 153 stehen - die Lampe reagiert aber sehr wohl.
Hat jemand eine Idee, woran das liegen kann / wie es zu beheben ist?
Beste Grüße
Sascha
P.S. Ich hätte noch zwei Verbesserungsvorschläge, um diesen Thread besser finden zu können:
- anpinnen, so dass er nicht aus der ersten Seite rausrutscht.
- Diesen Thread hier in mqtt2.template: Contributing (https://forum.fhem.de/index.php/topic,94495.0.html) nicht nur oben im Text verlinken sondern auch unten in der Liste mit "links zu diversen template-Threads und auch den Begriff bugs mit aufnehmen :)
Zitat von: HomeAlone am 30 September 2022, 10:02:52
P.S. Ich hätte noch zwei Verbesserungsvorschläge, um diesen Thread besser finden zu können:
- anpinnen, so dass er nicht aus der ersten Seite rausrutscht.
- Diesen Thread hier in mqtt2.template: Contributing (https://forum.fhem.de/index.php/topic,94495.0.html) nicht nur oben im Text verlinken sondern auch unten in der Liste mit "links zu diversen template-Threads und auch den Begriff bugs mit aufnehmen :)
@Rudi, bzw. sonst ein mitlesender Mod: Kannst du das mit dem anpinnen bitte erledigen?
Den als 2. Punkt angeregten Link habe ich eingefügt, eine inhaltliche Antwort zum eingentlichen Thema ist bereits in https://forum.fhem.de/index.php/topic,129414.0.html zu finden.
Zitat@Rudi, bzw. sonst ein mitlesender Mod: Kannst du das mit dem anpinnen bitte erledigen?
Habs gemacht.
In einigen Templates (älteren und neueren) werden HTML-Tags in farewell verwendet die in dem Dialogfeld gar nicht "interpretiert" werden.
Stolpere nur so nebenbei darauf und frage mich ob das mal ging und jetzt nicht mehr ?
@Beta-User: Falls es noch nie ging, warum verwendest die dann immer wieder ?
Zitat von: TomLee am 07 Dezember 2022, 16:55:21
@Beta-User: Falls es noch nie ging, warum verwendest die dann immer wieder ?
Keine Ahnung, ob es je ging ::) .
Werfe ich bei Gelegenheit dann raus, falls was zu ändern ist bzw. wenn es mir wo auffällt.
Hi,
es ist bestimmt was ganz banales, was mach ich bei der rL denn noch falsch das es im Dialogfeld zu den u.a. Meldungen kommt:
# tasmota+bla
name:tasmota_bla
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd|stat).*
desc:bla
order:A_01b2
par:TELETOPIC;info topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}tele$3" : undef }
par:STATTOPIC;ack topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}stat$3" : undef }
par:IO_DEV;Currently used IO;{ AttrVal('DEVICE','IODev',InternalVal('DEVICE','IODev',undef)->{NAME}) }
attr DEVICE devStateIcon Motion..true:people_sensor Motion..false:motion_detector
attr DEVICE event-on-change-reading occupancy
attr DEVICE icon people_sensor
attr DEVICE jsonMap Switch1:occupancy
attr DEVICE model tasmota_bla
attr DEVICE readingList \
TELETOPIC/INFO.:.* {}
TELETOPIC/LWT:.* LWT\
TELETOPIC/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/STATE:.* {}\
STATTOPIC/POWER:.* occupancy\
STATTOPIC/RESULT:.* {}
attr DEVICE stateFormat Motion: occupancy
attr DEVICE timestamp-on-change-reading occupancy
deletereading -q DEVICE .*
set IO_DEV publish CMNDTOPIC/Backlog SwitchMode1 1; StateText1 false; StateText1 true; TelePeriod 3600;
set IO_DEV publish CMNDTOPIC/Restart 1
setreading DEVICE attrTemplateVersion 20xxxxxx
Unknown command tele/tasmota_55756B/INFO.:.*, try help.
Unknown command .*, try help.
Unknown command tele/tasmota_55756B/LWT:.*, try help.
Unknown command tele/tasmota_55756B/SENSOR:.*, try help.
Unknown command tele/tasmota_55756B/STATE:.*, try help.
Unknown command stat/tasmota_55756B/POWER:.*, try help.
Unknown command stat/tasmota_55756B/RESULT:.*, try help.
edit:
bei TELETOPIC/INFO... ist das \ am Ende bei meinen Tests vorhanden, ist hier nur ein Kopierfehler
define MQTT2_tasmota_55756B MQTT2_DEVICE tasmota_55756B
attr MQTT2_tasmota_55756B readingList stat/tasmota_55756B/RESULT:.* { json2nameValue($EVENT) }\
tele/tasmota_55756B/LWT:.* LWT\
tele/tasmota_55756B/INFO1:.* { json2nameValue($EVENT) }\
tele/tasmota_55756B/INFO2:.* { json2nameValue($EVENT) }\
tele/tasmota_55756B/INFO3:.* { json2nameValue($EVENT) }\
tele/tasmota_55756B/STATE:.* { json2nameValue($EVENT) }\
tele/tasmota_55756B/SENSOR:.* { json2nameValue($EVENT) }\
stat/tasmota_55756B/POWER:.* POWER
attr MQTT2_tasmota_55756B room MQTT2_DEVICE
# CFGFN
# CID tasmota_55756B
# DEF tasmota_55756B
# FUUID 63aaf0e6-f33f-78f5-d19f-4aef827704920c7e
# IODev MQTT2_Server
# LASTInputDev MQTT2_Server
# MQTT2_Server_CONN MQTT2_Server_192.168.188.25_53729
# MQTT2_Server_MSGCNT 4
# MQTT2_Server_TIME 2022-12-27 14:21:06
# MSGCNT 4
# NAME MQTT2_tasmota_55756B
# NR 79962
# STATE ???
# TYPE MQTT2_DEVICE
# eventCount 12
# .DT:
# DEVICETOPIC MQTT2_tasmota_55756B
# .attraggr:
# .attrminint:
# READINGS:
# 2022-12-27 14:19:44 Heap 27
# 2022-12-27 14:19:34 IODev MQTT2_Server
# 2022-12-27 14:19:40 Info1_FallbackTopic cmnd/DVES_55756B_fb/
# 2022-12-27 14:19:40 Info1_GroupTopic cmnd/tasmotas/
# 2022-12-27 14:19:40 Info1_Module Generic
# 2022-12-27 14:19:40 Info1_Version 12.3.1(tasmota)
# 2022-12-27 14:19:40 Info2_Hostname tasmota-55756B-5483
# 2022-12-27 14:19:40 Info2_IPAddress 192.168.188.25
# 2022-12-27 14:19:40 Info2_WebServerMode Admin
# 2022-12-27 14:19:40 Info3_BootCount 98
# 2022-12-27 14:19:40 Info3_RestartReason Software/System restart
# 2022-12-27 14:19:40 LWT Online
# 2022-12-27 14:19:44 LoadAvg 19
# 2022-12-27 14:19:44 MqttCount 1
# 2022-12-27 14:21:06 POWER true
# 2022-12-27 14:19:35 Restart Restarting
# 2022-12-27 14:19:44 Sleep 50
# 2022-12-27 14:19:44 SleepMode Dynamic
# 2022-12-27 14:19:44 Switch1 true
# 2022-12-27 14:19:44 Time 2022-12-27T14:19:43
# 2022-12-27 14:19:44 Uptime 0T00:00:08
# 2022-12-27 14:19:44 UptimeSec 8
# 2022-12-27 14:19:44 Wifi_AP 1
# 2022-12-27 14:19:44 Wifi_BSSId 02:EC:DA:FD:26:1A
# 2022-12-27 14:19:44 Wifi_Channel 3
# 2022-12-27 14:19:44 Wifi_Downtime 0T00:00:03
# 2022-12-27 14:19:44 Wifi_LinkCount 1
# 2022-12-27 14:19:44 Wifi_Mode 11n
# 2022-12-27 14:19:44 Wifi_RSSI 68
# 2022-12-27 14:19:44 Wifi_SSId FBF
# 2022-12-27 14:19:44 Wifi_Signal -66
# 2022-12-27 14:21:04 associatedWith MQTT2_Owntracks_Bridge
#
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Heap 27
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:34 IODev MQTT2_Server
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info1_FallbackTopic cmnd/DVES_55756B_fb/
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info1_GroupTopic cmnd/tasmotas/
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info1_Module Generic
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info1_Version 12.3.1(tasmota)
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info2_Hostname tasmota-55756B-5483
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info2_IPAddress 192.168.188.25
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info2_WebServerMode Admin
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info3_BootCount 98
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info3_RestartReason Software/System restart
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 LWT Online
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 LoadAvg 19
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 MqttCount 1
setstate MQTT2_tasmota_55756B 2022-12-27 14:21:06 POWER true
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:35 Restart Restarting
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Sleep 50
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 SleepMode Dynamic
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Switch1 true
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Time 2022-12-27T14:19:43
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Uptime 0T00:00:08
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 UptimeSec 8
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_AP 1
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_BSSId 02:EC:DA:FD:26:1A
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_Channel 3
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_Downtime 0T00:00:03
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_LinkCount 1
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_Mode 11n
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_RSSI 68
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_SSId FBF
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_Signal -66
setstate MQTT2_tasmota_55756B 2022-12-27 14:21:04 associatedWith MQTT2_Owntracks_Bridge
Hmm, irgendwie irritierend, dass da bisher noch keiner drüber gestolpert ist...
Anscheinend muss die LWT-Zeile am Anfang stehen.
Hallo Zusammen,
seit vielen Jahren setze ich 1-Wire ein. Dazu hatte ich die initialen Module für FHEM ins Leben gerufen und später, gemeinsam mit Boris, die Module OWServer und OWDevice entwickelt.
Leider kommt es bei meinen Netzwerk immer wieder zu BlockingCalls, so dass andere Module nachhaltig beeinträchtigt werden. Selbst eine Auslagerung auf ein dediziertes FHEM System, läuft nicht immer "rund".
Daher will ich meine komplette 1-Wire Anbindung FHEM-seitig über MQTT abwickeln. Hierzu habe ich ein schönes Projekt gefunden:
https://github.com/FragJage/MqttOwfs
Die Daten werden brav an einen MQTT2 Server Device geliefert und im "General Bridge" Device wird eine entsprechende readingList erzeugt. (Ausschnitt):
MqttOwfs:owfs/20\x2e03F30F000000/PIO\x2eA:.* PIO.A
MqttOwfs:owfs/20\x2e03F30F000000/PIO\x2eB:.* PIO.B
MqttOwfs:owfs/20\x2e03F30F000000/PIO\x2eC:.* PIO.C
MqttOwfs:owfs/20\x2e03F30F000000/PIO\x2eD:.* PIO.D
MqttOwfs:owfs/20\x2e03F30F000000/volt\x2eA:.* volt.A
MqttOwfs:owfs/20\x2e03F30F000000/volt\x2eB:.* volt.B
MqttOwfs:owfs/20\x2e03F30F000000/volt\x2eC:.* volt.C
MqttOwfs:owfs/20\x2e03F30F000000/volt\x2eD:.* volt.D
MqttOwfs:owfs/20\x2e03F30F000000/volt2\x2eA:.* volt2.A
MqttOwfs:owfs/20\x2e03F30F000000/volt2\x2eB:.* volt2.B
MqttOwfs:owfs/20\x2e03F30F000000/volt2\x2eC:.* volt2.C
MqttOwfs:owfs/20\x2e03F30F000000/volt2\x2eD:.* volt2.D
[...]
MqttOwfs:owfs/28\x2e525715020000/temperature:.* temperature
MqttOwfs:owfs/28\x2e525715020000/temphigh:.* temphigh
MqttOwfs:owfs/28\x2e525715020000/templow:.* templow
[...]
MqttOwfs:owfs/12\x2e1F2173000000/PIO\x2eA:.* PIO.A
MqttOwfs:owfs/12\x2e1F2173000000/PIO\x2eB:.* PIO.B
MqttOwfs:owfs/12\x2e1F2173000000/sensed\x2eA:.* sensed.A
MqttOwfs:owfs/12\x2e1F2173000000/sensed\x2eB:.* sensed.B
[...]
MqttOwfs:owfs/01\x2e463A73140000/isPresent:.* isPresent
[...]
MqttOwfs:owfs/81\x2e93302D000000/isPresent:.* isPresent
[...]
MqttOwfs:owfs/1D\x2eD1490F000000/counters\x2eA:.* counters.A
MqttOwfs:owfs/1D\x2eD1490F000000/counters\x2eB:.* counters.B
[...]
Bisher habe ich noch nicht mit den Templates gearbeitet, würde diese aber gerne nutzen, entsprechend dem Typ korrekte Devices anzulegen.
Anhand der 1-Wire Family, die ersten beiden Stellen der ID im Topic bilden diese ab, möchte ich beim Autocreate dem Devicenamen die Klartextbezeichnung voranstellen. Das "1D" steht z.B. für ein "DS2423" und das "20" für ein "DS2450", usw. Daraus soll dann je ein Device mit dem Namen "DS2423_1D.D1490F000000" erzeugt werden (und wer sich an dem "." im Devicenamen stört, optional auch ohne diesem).
Jedes Device soll dann anhand der Family Id auch ein entsprechendes model Attribut erhalten und je nach Typ angepasste stateFormats und ggf. userReadings vorbelegen. Ich würde hierzu ein dediziertes "Bridge Device" einsetzen wollen, dass die entsprechenden Topics verarbeitet und via Autocreate neue Device anlegt.
Hat wer Lust, das Template / die Templates? gemeinsam mit mir zu entwickeln? Vielleicht jemand, der tiefer im Thema ist, als ich es derzeit bin. ;)
Abgesehen vom Timing zur Verarbeitung der Nutzlast durch den MQTT2 Server, hätten wir dann eine zu 100% BlockingCall freie Implementierung von 1-Wire via MQTT.
Hallo Martin,
kann gerne versuchen, mit "allgemeinem AttrTemplate-Wissen" weiterzuhelfen, allerdings laufen hier nur "einige" DS18B20, die ebenfalls asynchron per MySensors-Arduinos ausgelesen werden - mit OWServer habe ich daher nichts am Hut.
Würde vorschlagen, das in einem separaten Thread zu behandeln?
An sich scheint das ähnlich zu sein wie einige andere "Dienst + viele Einzelgeräte"-Lösungen, die "irgendwas" in MQTT überführen, wobei bei der Vielfalt der möglichen Geräte der Vergleich zu zigbee2mqtt vielleicht am besten paßt. Dazu gäbe es auch ein etwas ausführlichereres Wiki unter https://wiki.fhem.de/wiki/Zigbee2mqtt.
Man würde also ein "bridge-Device" basteln müssen, das über "bridgeRegexp" dann alles, was zu einem 1-Wire-Baustein gehört je in eine eigene MQTT2_DEVICE-Instanz verweist. Soweit mir das in Erinnerung ist, kann man dabei aber nicht einfach einen "ID2model"-Hash bauen, sondern müsste das hart vercoden, wie z.B. in dieser exemplarischen Zeile:
attr bridge bridgeRegexp owfs/(28[^/]+)/.* DS18B20_$1
Anschließend könnte man für derartige Devices dann passende readingList-Attribute vergeben und "schöne" stateFormat/devStateIcon-defaults vorbereiten.... Wobei es sich bei der Namensvergabe kaum (ohne weiteres) vermeiden läßt, dass das "MQTT_"-Präfix dazukommt.
"Blöd" ist halt, dass das Punkte in den Topics drin sind, das ist erfahrungsgemäß nicht so richtig lustig und ich komme auch immer wieder ins Schleudern, wie man damit umgehen muss. Aber Versuch macht bekanntlich kluch (wenn man nicht in den Quelltext schauen will).
Hallo Jörg,
Zitat von: Beta-User am 17 April 2023, 16:00:53kann gerne versuchen, mit "allgemeinem AttrTemplate-Wissen" weiterzuhelfen, allerdings laufen hier nur "einige" DS18B20, die ebenfalls asynchron per MySensors-Arduinos ausgelesen werden - mit OWServer habe ich daher nichts am Hut.
gerne nehme ich die Hilfe an! Mit OWServer hat das hier allerdings auch nichts zu tun. Die "Architektur" dahinter ist:
OWFS Server -> MqttOwfs Daemon -> MQTT2_SERVER -> MQTT2_DEVICE
ZitatWürde vorschlagen, das in einem separaten Thread zu behandeln?
Ich bin da leidenschaftslos.
ZitatMan würde also ein "bridge-Device" basteln müssen, das über "bridgeRegexp" dann alles, was zu einem 1-Wire-Baustein gehört je in eine eigene MQTT2_DEVICE-Instanz verweist.
Das ist soweit verstanden und auch in der Anwendung. Aus dieser Richtung bin ich gestartet:
[^/:]+/(1D\\x2e\S{12})/.*:.* DS2423_$1erzeugt ein Device namens
MQTT_DS2423_1D.40500B000000Man achte auf den Punkt, der hier korrekt verarbeitet wird. Ansonsten ist mir Deine Anmerkung bzgl. der zulässigen Zeichen im Topic bewusst, doch der MqttOwfs Daemon kodiert es (leider) so. FHEM selbst hat keine Probleme damit. So nutze ich Punkte in allen meinen FHEM Notationen schon seit mehr als 15 Jahren. ;)
ZitatAnschließend könnte man für derartige Devices dann passende readingList-Attribute vergeben und "schöne" stateFormat/devStateIcon-defaults vorbereiten.... Wobei es sich bei der Namensvergabe kaum (ohne weiteres) vermeiden läßt, dass das "MQTT_"-Präfix dazukommt.
Ja, das "MQTT_"-Präfix ist nicht schön aber damit lebe ich erst einmal. Genau um den Rest soll es gehen:
vorgefertigte Templates, die sich an der "Familie" orientieren.
Ein DS18B20 soll z.B. automatisch die Temperatur im STATE anzeigen und ein DS2406 z.B. ob ein Kontakt offen oder geschlossen ist.
Natürlich habe ich mir Beispiel angesehen, vielleicht auch noch ein Verständnisproblem.
"Meine Denke" ist ein entsprechendes Template a-la
name:MqttOwfs_Gateway
filter:TYPE=MQTT2_DEVICE
desc:Use this for the Mqtt daemon to communicate with one wire device.<br>For further details visit https://github.com/FragJage/MqttOwfs.
order:M_02
par:DEV_FAMILY;DEV_FAMILY contains the 1-Wire family identifier;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m,[^/:]+/([0-9A-Z]{2})\\x2e\S{12}/.*:.*, ? $1 : undef}
par:DEV_ID;DEV_ID contains the 1-Wire device id;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m,[^/:]+/([0-9A-Z]{2})\\x2e(\S{12})/.*:.*, ? "$1.$2" : undef}
[...]
anzulegen und dann für jeden Typ ein weiteres Template a-la
name:MqttOwfs_Gateway_DS2423
prereq:{my @devices=devspec2array("model=MqttOwfs_Gateway");return 1 if $devices[0];return 0}
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*/1D[^/]*/.*
desc:use this with an DS2423 sensor
order:X_01f
[...]
defmod ??? MQTT2_\DEVICE <DS_xxxx>_DEV_ID
(oder so) vorzuhalten.
Aber vermutlich bin ich noch nicht 100% auf Spur bzgl. der Templates. So würde ich ja bereits DEV_ID und DEV_FAMILY im "MqttOwfs_Gateway" parsen und auswerten. Dieses Template würde ich - nach meinem Verständnis - auch als Vorlage für das MQTT2_"bridge"_DEVICE nehmen.
Ähnlich dem "MQTT2_CLIENT_general_bridge" Template aus mqtt2.template. Dort wäre dann auch die Regexp aufgehoben:
attr DEVICE bridgeRegexp \
[^/:]+/(01\\x2e\S{12})/.*:.* DS2401_$1\
[^/:]+/(05\\x2e\S{12})/.*:.* DS2405_$1\
[^/:]+/(10\\x2e\S{12})/.*:.* DS18S20_$1\
[^/:]+/(12\\x2e\S{12})/.*:.* DS2406_$1\
[...]
Aber ich glaube, dass ich mich gerade noch etwas "verrannt" habe. Ich will das Prefix z.B. DS18B20_ vor den Devicenamen stellen aber auch als Modell im entsprechenden Attribut hinterlegen. Und da der Devicename später ja auch umbenannt werden könnte, ist das nur für das Autocreate von Bedeutung.
Bzgl. der Vorarbeiten brauche ich mal etwas Nachhilfe:
- erst das Template für die Bridge bauen und festlegen, WAS alles dort definiert werden kann
- dann je FAMILY ein weiteres Template mit prereq auf die Bridge
Liege ich da richtig? Werden die "FAMILY" Templates dann beim Autocreate verwendet?
Wald: Bäume -> Blätter
* ;-)
* Warum musste ich jetzt an Trees und Leaves von Novel Netware 4.0 denken? *amkopfkratz* :o
Zitat von: Martin Fischer am 17 April 2023, 21:38:49gerne nehme ich die Hilfe an! Mit OWServer hat das hier allerdings auch nichts zu tun. Die "Architektur" dahinter ist:
OWFS Server -> MqttOwfs Daemon -> MQTT2_SERVER -> MQTT2_DEVICE
Ok, sorry, da war ich ungenau, gemeint war OWFS Server, die Architektur ist soweit klar.
ZitatZitatWürde vorschlagen, das in einem separaten Thread zu behandeln?
Ich bin da leidenschaftslos.
:) Scheint vollends schnell zu gehen, von daher können wir auch hier bleiben. Mir ging/geht es eher darum, "unfreiwillige Mitleser", die hier irgendwann mal was gepostet hatten, nicht zu langweilen...
ZitatZitatMan würde also ein "bridge-Device" basteln müssen, das über "bridgeRegexp" dann alles, was zu einem 1-Wire-Baustein gehört je in eine eigene MQTT2_DEVICE-Instanz verweist.
Das ist soweit verstanden und auch in der Anwendung. Aus dieser Richtung bin ich gestartet:
[^/:]+/(1D\\x2e\S{12})/.*:.* DS2423_$1erzeugt ein Device namens
MQTT_DS2423_1D.40500B000000Man achte auf den Punkt, der hier korrekt verarbeitet wird. Ansonsten ist mir Deine Anmerkung bzgl. der zulässigen Zeichen im Topic bewusst, doch der MqttOwfs Daemon kodiert es (leider) so. FHEM selbst hat keine Probleme damit. So nutze ich Punkte in allen meinen FHEM Notationen schon seit mehr als 15 Jahren. ;)
Na ja, wenn es "von außen" so (unbeeinflussbar) kommt, ist es halt so. Den Punkt finde ich persönlich nicht so "anfängergeeignet", da "doppeldeutig", aber jeder wie er mag. Im MQTT-Topic-Kontext ist es halt "schlecht lesbar" (für Uneingeweihte).
ZitatZitatAnschließend könnte man für derartige Devices dann passende readingList-Attribute vergeben und "schöne" stateFormat/devStateIcon-defaults vorbereiten.... Wobei es sich bei der Namensvergabe kaum (ohne weiteres) vermeiden läßt, dass das "MQTT_"-Präfix dazukommt.
Ja, das "MQTT_"-Präfix ist nicht schön aber damit lebe ich erst einmal. Genau um den Rest soll es gehen:
vorgefertigte Templates, die sich an der "Familie" orientieren.
Ok, also geht es im Wesentlichen um das "dazwischen". Dazu ein paar Anmerkungen:
Du machst eine m.E. nicht nötige Unterscheidung zwischen dem "MqttOwfs_Gateway" und dem "bridge"-Device? Die bridgeRegexp ist m.E. nur ein funktionaler Teil, der zum "Zentraldevice" gehört und eben eine "Vorsortierung macht, das "MqttOwfs_Gateway" braucht als Parameter dagegen eigentlich nur die BASE_ID (also das base-Topic wie im MqttOwfs Daemon konfiguriert).
ZitatAber vermutlich bin ich noch nicht 100% auf Spur bzgl. der Templates. So würde ich ja bereits DEV_ID und DEV_FAMILY im "MqttOwfs_Gateway" parsen und auswerten.
Nein, s.o.. Davon abgesehen: Man muss sowieso "auf jeder Stufe" (also in jedem attrTemplate) alle erforderlichen Parameter wieder separat ermitteln. Man kann höchstens bereits ermittelte Parameter bei einem internen attrTemplate-Aufruf mit übergeben (das ist hier aber voraussichtlich nicht relevant).
ZitatAber ich glaube, dass ich mich gerade noch etwas "verrannt" habe. Ich will das Prefix z.B. DS18B20_ vor den Devicenamen stellen aber auch als Modell im entsprechenden Attribut hinterlegen. Und da der Devicename später ja auch umbenannt werden könnte, ist das nur für das Autocreate von Bedeutung.
Bzgl. der Vorarbeiten brauche ich mal etwas Nachhilfe:
- erst das Template für die Bridge bauen und festlegen, WAS alles dort definiert werden kann
- dann je FAMILY ein weiteres Template mit prereq auf die Bridge
Liege ich da richtig? Werden die "FAMILY" Templates dann beim Autocreate verwendet?
"Verrannt" würde ich es nicht nennen. Du scheinst nur eventuell zu viel zu erwarten und zu viel auf einmal erreichen zu wollen :) .
Schritt 1 ist erst mal, das "Zentraldevice" schlicht funktional zu haben und zu wissen, was man von ihm erwartet. MAn. sollte das sein:
- Statusinfo zum OWFS Server (wenn möglich) und zum MqttOwfs Daemon (online/offline, evtl. Fehlermeldungen)
- bridgeRegexp, die schlicht alles, was zu einer (noch nicht bekannten) Seriennummer gehört ein eigenes Device weitergibt.
Schritt 2 wäre dann, "einfache Devices" wie Temperatursensoren "hübsch" zu konfigurieren,
Schritt 3 würde sich dann mit "nicht ganz einfachen Devices" befassen (z.B. latch.A ist ein Relay, latch.B ein anderes => "split"-attrTemplate, das beide Relays mit on/off schaltbar macht, damit SetExtensions genutzt werden können.
Schritt 4 wäre dann, mit "prereq" und "filter" ggf. eine Benutzerführung zu basteln, mit der man (neben den unvermeidlichen allgemeinen Sachen) nur noch sieht, was einen grade interessieren könnte (prereq: Zentralevice, filter: anhand der ID?).
Klarer bzw. hilfreich?
Sodele, gerade etwas Zeit gehabt...
Danke für Deine Ausführungen. Ich habe mal etwas gestrickt. Soweit funktioniert es. Alle Devices werden angelegt, nur die automatische Zuordnung des Templates bei der Erstellung eines neuen Devices, hier im Beispiel ein DS18B20, erfolgt nicht. Manuell geht es jedoch.
Hast Du eine Idee für mich, warum das Template "MqttOwfs_DS18B20" nicht automatisch bei der Anlage des Devices ausgeführt wird?
MQTT2_DS1420_81.93302D000000
MQTT2_DS1420_81.A7C02F000000
MQTT2_DS18B20_28.28609C030000
MQTT2_DS18B20_28.2C373C020000
MQTT2_DS18B20_28.4B909C030000
MQTT2_DS18B20_28.4F999C030000
MQTT2_DS18B20_28.525715020000
MQTT2_DS18B20_28.65529C030000
MQTT2_DS18B20_28.796C9C030000
MQTT2_DS18B20_28.F9673C020000
MQTT2_DS18B20_28.FD649C030000
MQTT2_DS2401_01.463A73140000
MQTT2_DS2423_1D.13C80F000000
MQTT2_DS2423_1D.17C90F000000
MQTT2_DS2423_1D.40500B000000
MQTT2_DS2423_1D.4EC80D000000
MQTT2_DS2423_1D.57D20D000000
MQTT2_DS2423_1D.59600B000000
MQTT2_DS2423_1D.A1460F000000
MQTT2_DS2423_1D.EA490F000000
MQTT2_DS2438_26.126545010000
MQTT2_DS2438_26.168417010000
MQTT2_DS2438_26.28A940010000
MQTT2_DS2438_26.455E23010000
MQTT2_DS2438_26.FBA040010000
MQTT2_DS2450_20.03F30F000000
MQTT2_DS2450_20.1FF3461B0000
owfs2mqtt.bridge
name:MqttOwfs_bridge
filter:TYPE=MQTT2_DEVICE
desc:Use this for the Mqtt daemon to communicate with one wire device.<br>For further details visit https://github.com/FragJage/MqttOwfs.
order:MO_00
par:BASE_TOPIC;base topic as set in MqttOwfs.conf of the MqttOwfs Daemon;{ AttrVal("DEVICE","devicetopic","") =~ m,[\b]?([^/:]+)(/.+)?, ? $1 : AttrVal("DEVICE","readingList","") =~ m,[\b]?([^/:]+)/owfs/.+, ? $1 : undef }
par:ICON;ICON as set, defaults to mqtt;{ AttrVal("DEVICE","icon","mqtt") }
attr DEVICE devicetopic BASE_TOPIC
attr DEVICE bridgeRegexp\
BASE_TOPIC/(01\x2e\S{12})/.*:.* "DS2401_$1"\
BASE_TOPIC/(05\x2e\S{12})/.*:.* "DS2405_$1"\
BASE_TOPIC/(10\x2e\S{12})/.*:.* "DS18S20_$1"\
BASE_TOPIC/(12\x2e\S{12})/.*:.* "DS2406_$1"\
BASE_TOPIC/(1D\x2e\S{12})/.*:.* "DS2423_$1"\
BASE_TOPIC/(20\x2e\S{12})/.*:.* "DS2450_$1"\
BASE_TOPIC/(21\x2e\S{12})/.*:.* "DS1921_$1"\
BASE_TOPIC/(22\x2e\S{12})/.*:.* "DS1822_$1"\
BASE_TOPIC/(26\x2e\S{12})/.*:.* "DS2438_$1"\
BASE_TOPIC/(28\x2e\S{12})/.*:.* "DS18B20_$1"\
BASE_TOPIC/(29\x2e\S{12})/.*:.* "DS2408_$1"\
BASE_TOPIC/(3A\x2e\S{12})/.*:.* "DS2413_$1"\
BASE_TOPIC/(81\x2e\S{12})/.*:.* "DS1420_$1"\
BASE_TOPIC/([0-9A-Z]\x2e\S{12})/.*:.* "OWFS_$1"
attr DEVICE autocreate 1
# set DEVICE attrTemplate do_general_mqtt_cleanup
attr DEVICE model MqttOwfs_bridge
setreading DEVICE attrTemplateVersion 20230418
name:MqttOwfs_DS18B20
prereq:{my @devices=devspec2array("model=MqttOwfs_bridge");;return 1 if $devices[0];;return 0}
desc:DS18B20 sensor via MqttOwfs
filter:TYPE=MQTT2_DEVICE:FILTER=CID=DS18B20_28\.[0-9A-Z]{12}
order:MO_DS18B20
par:BASE_TOPIC;base topic as set in MqttOwfs.conf of the MqttOwfs Daemon;{ AttrVal("DEVICE","devicetopic","") =~ m,[\b]?([^/:]+)(/.+)?, ? $1 : AttrVal("DEVICE","readingList","") =~ m,[\b]?([^/:]+)[/].+, ? $1 : undef }
par:DEV_FAMILY;DEV_FAMILY contains the 1-Wire family identifier;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m,[^/:]+/([0-9A-Z]{2})\\x2e\S{12}/.*:.*, ? $1 : undef}
par:DEV_ID;DEV_ID contains the 1-Wire device id;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m,[^/:]+/([0-9A-Z]{2})\\x2e(\S{12})/.*:.*, ? "$1.$2" : undef}
attr DEVICE stateFormat {sprintf ("T: %.1f°C", ReadingsVal($name,'temperature',0)) }
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE readingList $\DEVICETOPIC/temperature:.* temperature\
$\DEVICETOPIC/templow:.* templow\
$\DEVICETOPIC/temphigh:.* temphigh
deletereading -q DEVICE (?!associatedWith|IODev).*
attr DEVICE model DS18B20
setreading DEVICE attrTemplateVersion 20230418
Durch die Bridge frisch angelegt:
define MQTT2_DS18B20_28.525715020000 MQTT2_DEVICE DS18B20_28.525715020000
attr MQTT2_DS18B20_28.525715020000 readingList owfs/28\x2e525715020000/temperature:.* temperature
attr MQTT2_DS18B20_28.525715020000 room AUTOCREATE
# CFGFN
# CID DS18B20_28.525715020000
# DEF DS18B20_28.525715020000
# FUUID 643ef11a-f33f-ce77-d623-47b95a40667a995a
# IODev mqtt.server
# LASTInputDev mqtt.server
# MSGCNT 1
# NAME MQTT2_DS18B20_28.525715020000
# NR 417
# STATE ???
# TYPE MQTT2_DEVICE
# eventCount 2
# mqtt.server_CONN mqtt.server_172.16.230.1_60068
# mqtt.server_MSGCNT 1
# mqtt.server_TIME 2023-04-18 21:36:43
# READINGS:
# 2023-04-18 21:35:54 IODev mqtt.server
# 2023-04-18 21:35:54 associatedWith owfs2mqtt.bridge
# 2023-04-18 21:36:43 temperature 22
# helper:
# bm:
# MQTT2_DEVICE_Attr:
# cnt 1
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 18.04. 21:35:54
# max 0.000392913818359375
# tot 0.000392913818359375
# mAr:
# set
# MQTT2_DS18B20_28.525715020000
# readingList
# owfs/28\x2e525715020000/temperature:.* temperature
# MQTT2_DEVICE_Define:
# cnt 1
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 18.04. 21:35:54
# max 0.00113391876220703
# tot 0.00113391876220703
# mAr:
# HASH(0x564526511cf8)
# MQTT2_DS18B20_28.525715020000 MQTT2_DEVICE DS18B20_28.525715020000 mqtt.server
# MQTT2_DEVICE_Get:
# cnt 1
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 18.04. 21:40:01
# max 3.19480895996094e-05
# tot 3.19480895996094e-05
# mAr:
# HASH(0x564526511cf8)
# MQTT2_DS18B20_28.525715020000
# ?
# MQTT2_DEVICE_Set:
# cnt 6
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 18.04. 21:40:01
# max 0.000113010406494141
# tot 0.000241994857788086
# mAr:
# HASH(0x564526511cf8)
# MQTT2_DS18B20_28.525715020000
# ?
#
setstate MQTT2_DS18B20_28.525715020000 2023-04-18 21:35:54 IODev mqtt.server
setstate MQTT2_DS18B20_28.525715020000 2023-04-18 21:35:54 associatedWith owfs2mqtt.bridge
setstate MQTT2_DS18B20_28.525715020000 2023-04-18 21:36:43 temperature 22
MqttOwfs_DS18B20 Template, manuell zugewiesen:
define MQTT2_DS18B20_28.FD649C030000 MQTT2_DEVICE DS18B20_28.FD649C030000
attr MQTT2_DS18B20_28.FD649C030000 devicetopic owfs/28.FD649C030000
attr MQTT2_DS18B20_28.FD649C030000 model DS18B20
attr MQTT2_DS18B20_28.FD649C030000 readingList $DEVICETOPIC/temperature:.* temperature\
$DEVICETOPIC/templow:.* templow\
$DEVICETOPIC/temphigh:.* temphigh
attr MQTT2_DS18B20_28.FD649C030000 room AUTOCREATE
attr MQTT2_DS18B20_28.FD649C030000 stateFormat {sprintf ("T: %.1f°C", ReadingsVal($name,'temperature',0)) }
# CFGFN
# CID DS18B20_28.FD649C030000
# DEF DS18B20_28.FD649C030000
# FUUID 643ef013-f33f-ce77-701d-b596f444e07dcb77
# IODev mqtt.server
# LASTInputDev mqtt.server
# MSGCNT 4
# NAME MQTT2_DS18B20_28.FD649C030000
# NR 332
# STATE T: 23.1°C
# TYPE MQTT2_DEVICE
# eventCount 6
# mqtt.server_CONN mqtt.server_172.16.230.1_60068
# mqtt.server_MSGCNT 4
# mqtt.server_TIME 2023-04-18 21:38:09
# OLDREADINGS:
# READINGS:
# 2023-04-18 21:31:31 IODev mqtt.server
# 2023-04-18 21:31:31 associatedWith owfs2mqtt.bridge
# 2023-04-18 21:32:03 attrTemplateVersion 20230418
# 2023-04-18 21:38:09 temperature 23.125
# helper:
# bm:
# MQTT2_DEVICE_Attr:
# cnt 5
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 18.04. 21:32:03
# max 0.000235080718994141
# tot 0.000686883926391602
# mAr:
# set
# MQTT2_DS18B20_28.FD649C030000
# readingList
# $DEVICETOPIC/temperature:.* temperature
#$DEVICETOPIC/templow:.* templow
#$DEVICETOPIC/temphigh:.* temphigh
# MQTT2_DEVICE_Define:
# cnt 1
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 18.04. 21:31:31
# max 0.000837087631225586
# tot 0.000837087631225586
# mAr:
# HASH(0x564526353850)
# MQTT2_DS18B20_28.FD649C030000 MQTT2_DEVICE DS18B20_28.FD649C030000 mqtt.server
# MQTT2_DEVICE_Get:
# cnt 3
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 18.04. 21:31:47
# max 2.69412994384766e-05
# tot 5.88893890380859e-05
# mAr:
# HASH(0x564526353850)
# MQTT2_DS18B20_28.FD649C030000
# ?
# MQTT2_DEVICE_Set:
# cnt 24
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 18.04. 21:32:03
# max 0.00835299491882324
# tot 0.00937867164611816
# mAr:
# HASH(0x564526353850)
# MQTT2_DS18B20_28.FD649C030000
# attrTemplate
# MqttOwfs_DS18B20
#
setstate MQTT2_DS18B20_28.FD649C030000 T: 23.1°C
setstate MQTT2_DS18B20_28.FD649C030000 2023-04-18 21:31:31 IODev mqtt.server
setstate MQTT2_DS18B20_28.FD649C030000 2023-04-18 21:31:31 associatedWith owfs2mqtt.bridge
setstate MQTT2_DS18B20_28.FD649C030000 2023-04-18 21:32:03 attrTemplateVersion 20230418
setstate MQTT2_DS18B20_28.FD649C030000 2023-04-18 21:38:09 temperature 23.125
Sieht doch schon gut aus!
Anmerkungen:
Zitatnur die automatische Zuordnung des Templates bei der Erstellung eines neuen Devices, hier im Beispiel ein DS18B20, erfolgt nicht.
Diese Erwartungshaltung kann attrTemplate nicht erfüllen, es ist immer so gedacht, dass der User für ein von autocreate erstelltes neues Device das passende attrTemplate manuell anwendet. Das gilt auch dann, wenn per bridgeRegexp das autocreate "angeschubst" wurde.
Kannst du mir diese Zeile aus bridgeRegexp erläutern:
BASE_TOPIC/([0-9A-Z]\x2e\S{12})/.*:.* "OWFS_$1" Da scheint es um "alles mögliche" zu gehen, was mit dem OWFS-Server zu tun hat. Warum braucht da jedes Einzel-Zeichen ein eigenes Device?
Oder ist das so gedacht, dass alles andere erkannt wird, was oben nicht abgefrühstückt ist? Dann müßten es vorne zwei Zeichen sein, oder? Wenn ja: Obacht! Alle bridgeRegexp-Ausdrücke aller MQTT2_DEVICE-Instanzen werden intern in einem gemeinsamen Hash verwaltet, und "doppelte/mehrfache Treffer-Möglichkeiten" ergeben zufällige (!) Ergebnisse...! Lieber auf sowas verzichten!
Ansonsten noch zu dem DS18B20-template. "Üblich" wäre:
- ein Icon zu setzen
(- intern noch ein Sprachssteuerungs-attrTemplate aufzurufen, das dem Ding noch einen passenden "genericDeviceType" zuweist und einem "Klartextnamen"; gilt für switches oder Lichter, nicht bei Thermometern)
par:ICON;ICON as set, defaults to temperature_humidity;{ AttrVal("DEVICE","icon","temperature_humidity") }
attr DEVICE icon ICON
Zitat von: Beta-User am 19 April 2023, 11:48:32Zitatnur die automatische Zuordnung des Templates bei der Erstellung eines neuen Devices, hier im Beispiel ein DS18B20, erfolgt nicht.
Diese Erwartungshaltung kann attrTemplate nicht erfüllen, es ist immer so gedacht, dass der User für ein von autocreate erstelltes neues Device das passende attrTemplate manuell anwendet. Das gilt auch dann, wenn per bridgeRegexp das autocreate "angeschubst" wurde.
Ok, dann hatte ich das Mißverstanden. Ich ging davon aus, warum auch immer, dass nach dem Autocreate automatisch das Template gezogen wird, was ja "genauestens" darauf zugeschnitten ist. Es fehlt ja eigentlich nur ein "set <device> attrTemplate <foobar>".
ZitatKannst du mir diese Zeile aus bridgeRegexp erläutern:
BASE_TOPIC/([0-9A-Z]\x2e\S{12})/.*:.* "OWFS_$1"
Da nicht alle 1wire Sensoren in der Bridge, sondern nur die geläufigen, abgefangen werden, werde nicht geparste Familycodes hiermit erfasst und zumindest noch mit dem Prefix OWFS_ versehen.
ZitatWenn ja: Obacht! Alle bridgeRegexp-Ausdrücke aller MQTT2_DEVICE-Instanzen werden intern in einem gemeinsamen Hash verwaltet, und "doppelte/mehrfache Treffer-Möglichkeiten" ergeben zufällige (!) Ergebnisse...! Lieber auf sowas verzichten!
Aus meiner Sicht ist die Gefahr doch eher zu vernachlässigen. Denn "BASE_TOPIC/([0-9A-Z]\x2e\S{12})/.*:.*"
erfasst ja nur Topics, die z.B. ausgeschrieben "owfs/4E\2xe93302D000000/<irgendwas>:<irgendwas>" (oder im Klartext "owfs/4E.93302D000000") treffen. Dies impliziert ja, dass eine 1wire Family, die mit 4E anfängt ja kein Template hat und daher eben das OWFS_ vorangestellt wird. Die Wahrscheinlichkeit, dass es weitere MQTT Topics in diesem Format vorliegen, sehe ich doch als eher sehr gering an.
ZitatAnsonsten noch zu dem DS18B20-template. "Üblich" wäre:
- ein Icon zu setzen
(- intern noch ein Sprachssteuerungs-attrTemplate aufzurufen, das dem Ding noch einen passenden "genericDeviceType" zuweist und einem "Klartextnamen"; gilt für switches oder Lichter, nicht bei Thermometern)
par:ICON;ICON as set, defaults to temperature_humidity;{ AttrVal("DEVICE","icon","temperature_humidity") }
attr DEVICE icon ICON
Die Frage ist ja hier: Was ist üblich? :D
Ich persönlich verzichte in meinen FHEM Instanzen nahezu komplett auf Icons. Nur sehr wenige Devices haben eins. Daher werde ich das in diesem Template für mich nicht erzwingen. ;)
Das mit der Sprachsteuerung behalte ich im Hinterkopf für andere Geräteklassen. Danke für den Hinweis!
Nun gilt es noch die "komplizierteren" Devices anzugehen. Z.B. die, die einen Split erfordern. Hast Du hier noch ein gutes "nachvollziehbares" Beispiel für mich?
Da gäbe es z.B. noch Sensoren, die mehrere Kanäle für sensed, latch oder counter haben, um nur drei Beispiele zu nennen.
Zitat von: Martin Fischer am 19 April 2023, 12:16:08Ok, dann hatte ich das Mißverstanden. Ich ging davon aus, warum auch immer, dass nach dem Autocreate automatisch das Template gezogen wird, was ja "genauestens" darauf zugeschnitten ist. Es fehlt ja eigentlich nur ein "set <device> attrTemplate <foobar>".
Na ja, das mit "genauestens" ist so eine Sache...
Für einen "autocreate-plus"-Mechanismus könnte man ein archetype einsetzen, aber m.E. lohnt das nicht. Die User, die attrTemplate kennen, kennen in der Regel den fehlenden Automatismus, und es geht immer noch (hauptsächlich) darum, Attribute zu setzen. Und die "gehören" halt dem User.
ZitatDa nicht alle 1wire Sensoren in der Bridge, sondern nur die geläufigen, abgefangen werden, werde nicht geparste Familycodes hiermit erfasst und zumindest noch mit dem Prefix OWFS_ versehen.
MAn. fehlt dann aber noch ein Zeichen in der Regex ;) .
Und wenn du das mal in einer Testinstallation dann mit der "zweistelligen" bridgeRegexp (mehrmals) versuchen magst, kannst du vielleicht verstehen, warum ich von solchen "Würfeleien" Abstand nehmen würde. Wer dann was hat, was noch nicht bekannt/hart vercoded ist, kann ja die bridgeRegexp einfach um den konkret erforderlichen Ausdruck erweitern, ist ja (fast) selbsterklärend, was schon da steht.
ZitatDie Frage ist ja hier: Was ist üblich? :D
Es stand da in Anführungsszeichen, weil man sich bekanntlich nicht über Geschmacksfragen zu streiten braucht. Gemeint war damit: "wir" machen das in den anderen attrTemplates eben so. Das hat teils historische Gründe, teils spiegelt das meinen ganz persönlichen Geschmack wieder, und teils entsprechend klare Forderungen ganzer Kohorten von Usern...
ZitatNun gilt es noch die "komplizierteren" Devices anzugehen. Z.B. die, die einen Split erfordern. Hast Du hier noch ein gutes "nachvollziehbares" Beispiel für mich?
Da gäbe es z.B. noch Sensoren, die mehrere Kanäle für sensed, latch oder counter haben, um nur drei Beispiele zu nennen.
Bei allem, was Sensorik ist, tendiere ich dazu, das im "Hauptdevice" zu lassen (also dem, was die bridgeRegexp für diese ID als CID erkennt und an autocreate weitergibt).
"split" spielt nur da eine Rolle, wo es um
mehrere schaltbare Elemente (auf derselben Hardware) geht, vorrangig wegen der Themen SetExtensions und Sprachsteuerung.
Wenn du bisher keine MQTT2_DEVICEs hattest, wird vermutlich alles mehr oder weniger gut "nachvollziehbar" sein. Die vorhandenen haben alle ein "split" im Namen, kannst einfach von oben her in "zigbee2mqtt_2channel_split" oder "zigbee2mqtt_2channel_dimmer_split" schauen.
Zitat von: Beta-User am 19 April 2023, 12:41:07ZitatDa nicht alle 1wire Sensoren in der Bridge, sondern nur die geläufigen, abgefangen werden, werde nicht geparste Familycodes hiermit erfasst und zumindest noch mit dem Prefix OWFS_ versehen.
MAn. fehlt dann aber noch ein Zeichen in der Regex ;) .
Gerne darfst Du mich mit der Nase darauf stupsen. ;) Aber tatsächlich könnte man es noch optimieren, da ein "A-Z" nicht nötig ist, sondern nur "A-F".
ZitatUnd wenn du das mal in einer Testinstallation dann mit der "zweistelligen" bridgeRegexp (mehrmals) versuchen magst, kannst du vielleicht verstehen, warum ich von solchen "Würfeleien" Abstand nehmen würde.
Du, ich bin da leidenschaftslos. Ich kann das auch herausnehmen. Für mich war nachvollziehbar, dass es nur wenig bis keine Kollisionen geben mag. Ich hatte das auf meinem Broker mit ~1200 Topics getestet und es führte zu keinen Komplikationen.
Und da ja die Templates eh manuell nachgearbeitet werden müssen (was aber dank devspec Filter ganz gut auch bulk geht), spielt dass dann auch keine große Rolle mehr. Es würde nur den Kreis der erfassten aber nicht zugewiesenen Devices anhand des Prefixes "OWFS_" sichtbarer machen.
ZitatEs stand da in Anführungsszeichen, weil man sich bekanntlich nicht über Geschmacksfragen zu streiten braucht.
Auch hier: alles gut! Ich sah hier keinen Widerspruch oder eine Provokation. Wie Du schon schriebst: "Die Attribute gehören dem User.". Von daher sollte man m.M.n. die technisch sinnvollen Attribute setzen und alles was zum "Schick, Schick" o.ä. zählt, dem User überlassen. So etwas ist dann ja auch hier dank devspec Filtern etc. schnell manuell erledigt.
ZitatBei allem, was Sensorik ist, tendiere ich dazu, das im "Hauptdevice" zu lassen (also dem, was die bridgeRegexp für diese ID als CID erkennt und an autocreate weitergibt).
Dem stimme ich (zum Teil) zu. Es gibt ja auch Anwendungen, wo z.B. in einem 1wire Counter zwei Geräte "gezählt" werden, die jeweils z.B. unterschiedlichen Räumen zugewiesen werden müssen. Auch hier gibt es nicht immer "den einen Weg", sondern ggf. auch fallweise Abweichungen. Aber auch das gehört hier ja nicht ausdiskutiert, da beide Argumente ja durchaus ihre Berechtigung haben.
Zitat"split" spielt nur da eine Rolle, wo es um mehrere schaltbare Elemente (auf derselben Hardware) geht, vorrangig wegen der Themen SetExtensions und Sprachsteuerung.
Volle Zustimmung.
ZitatWenn du bisher keine MQTT2_DEVICEs hattest, wird vermutlich alles mehr oder weniger gut "nachvollziehbar" sein.
Na ja... wie oben geschrieben, gibt es da schon ein paar Topics die ich verarbeitet. ;) Es sind also "einige" MQTT2_DEVICEs vorhanden. Ich habe u.a. z.B. 10 Fhem Instanzen am Start, die nicht via fhem2fhem. sondern über MQTT zusammenwirken. Auch meine 1wire Anbindung, die bisher Fhem-seitig via OWServer und OWDevice angebunden und via MQTT_GENERIC_BRIDGE publishen, sind dort enthalten.
Doch da meine Instanzen mittlerweile so umfangreich sind, bekomme ich immer mehr Probleme mit dem Timing. Daher will ich das jetzt komplett auslagern.
ZitatDie vorhandenen haben alle ein "split" im Namen, kannst einfach von oben her in "zigbee2mqtt_2channel_split" oder "zigbee2mqtt_2channel_dimmer_split" schauen.
Ich schau mir das mal an. Danke für Deinen Rat und die Hinweise. Gerne mehr ;)
Stups:
Statt
BASE_TOPIC/([0-9A-F]\x2e\S{12})/.*:.* "OWFS_$1"
z.B.
BASE_TOPIC/([0-9A-F][0-9A-F]\x2e\S{12})/.*:.* "OWFS_$1" oder
BASE_TOPIC/([[:xdigit:]]{2}\x2e\S{12})/.*:.* "OWFS_$1"
Have fun!
Was die "Geschmacksfragen" vs. "technisch notwendig" angeht: Nach meinem persönlichen Eindruck war es zumindest bisher ganz ok, auch "Gimmicks" mit auszuliefern, die man "eigentlich" ohne weiteres selbst anflanschen kann, wie z.B. einige Perl-devStateIcons oder (teilweise) userReadings. So haben erst einige (mich eingeschlossen) verstanden, wie die Dinge ineinandergreifen...
(Ansonsten: alles gut :) ).
Zitat von: Beta-User am 19 April 2023, 14:56:40Stups:
BASE_TOPIC/([0-9A-F][0-9A-F]\x2e\S{12})/.*:.* "OWFS_$1" oder
BASE_TOPIC/([[:xdigit:]]{2}\x2e\S{12})/.*:.* "OWFS_$1"
ABSOLUT! Was für ein Schnitzer. :-[ Es fehlte tatsächlich ein "Stelle". Ich habe es vollkommen übersehen. Danke!
Noch eine Frage zum setList in einem Template in Verbindung mit MQTT:
Wenn das Attribut devicetopic gesetzt ist und das Template ein
attr DEVICE setList \
request:noArg $\DEVICETOPIC/command/REQUEST\
refreshDevices:noArg $\DEVICETOPIC/command/REFRESH_\DEVICES\
refreshValues:noArg $\DEVICETOPIC/command/REFRESH_VALUES
sollte das dann ausreichen, dass der Command published wird? Oder muss da noch irgendetwas bzgl. des IODEV rein?
$DEVICETOPIC wird auch in setList aufgelöst, der publish geht dann über das für das Device gültige IO - was auch "falsch" sein kann... Da sollte man aber so oder so prüfen, ob das (Reading) richtig ist und ggf. dann das korrigieren (mAn. via Attribut).
Ansonsten wegen der zwei Zeichen: Hast du jetzt schon mal "heiteres Würfeln mit Perl" ausprobiert oder nicht...?
Hey zusammen,
da ich gerade mein FHEM umziehe, bearbeite ich die ganzen alten Sachen und passe sie an. Dazu gehört auch das Shelly 1 Washer Example. Anbei mal eine Version die ein wenig aufgeräumt ist, mit devStateIcon und event-on.*
Was habe ich angepasst:
- devStateIcon
- devicetopic eingefügt
- event-on-change-reading eingefügt
- event-on-update-reading eingefügt
- readingList $DEVICETOPIC/relay/0/energy:.* energy gelöscht und nur relay_0_kWh übergelassen. $DEVICETOPIC/relay/0/power:.* Werteprüfung eingebaut, da meine Waschmaschine z.B. sonst immer einen 0.x Wert anzeigt obwohl sie aus ist.
- userReadings auf Gegebenheiten angepasst.
defmod MQTT2_shellyplug_s_040C7E MQTT2_DEVICE shellyplug_s_040C7E
attr MQTT2_shellyplug_s_040C7E 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@red'\
: '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 <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\"></a>".FW_makeImage($pic)." $text </div>" \
}
attr MQTT2_shellyplug_s_040C7E devicetopic shellies/shellyplug-s-040C7E
attr MQTT2_shellyplug_s_040C7E event-on-change-reading state,online,overtemperature,relay_0_.*,relay0,loadState,wash,price,relay_0_kWh_total
attr MQTT2_shellyplug_s_040C7E event-on-update-reading stat[ERT].*
attr MQTT2_shellyplug_s_040C7E genericDeviceType switch
attr MQTT2_shellyplug_s_040C7E model shelly1_w_energy_measuring
attr MQTT2_shellyplug_s_040C7E readingList $DEVICETOPIC/relay/0:.* {{ state => $EVENT, relay0 => $EVENT}}\
$DEVICETOPIC/online:.* online\
shellies/announce:.* { $EVENT =~ m,..id...shellyplug-s-040C7E...mac.*, ? json2nameValue($EVENT) : return }\
$DEVICETOPIC/announce:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/relay/0/power:.* {'relay_0_power' => $EVENT > 1 ? $EVENT : '0'}\
$DEVICETOPIC/relay/0/power:.* { my $compare = $EVTPART0 < 3 ? 'off':'on';; ReadingsVal($NAME,'loadState','off') ne $compare ? { loadState => $compare } : return }\
$DEVICETOPIC/temperature:.* temperature\
$DEVICETOPIC/temperature_f:.* {}\
$DEVICETOPIC/input_event/0:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/overtemperature:.* overtemperature\
$DEVICETOPIC/relay/0/energy:.* { relay_0_kWh => sprintf("%.2f",$EVENT/60/1000)}\
$DEVICETOPIC/longpush/0:.* longpush_0\
$DEVICETOPIC/info:.* { json2nameValue($EVENT) }
attr MQTT2_shellyplug_s_040C7E setList relay0:on,off,toggle $DEVICETOPIC/relay/0/command $EVTPART1\
toggle:noArg $DEVICETOPIC/relay/0/command toggle\
off:noArg $DEVICETOPIC/relay/0/command off\
on:noArg $DEVICETOPIC/relay/0/command on\
x_update:noArg $DEVICETOPIC/command update_fw\
x_mqttcom $DEVICETOPIC/command $EVTPART1
attr MQTT2_shellyplug_s_040C7E setStateList on off toggle
attr MQTT2_shellyplug_s_040C7E userReadings total_temp:loadState:.on { ReadingsNum($name,'relay_0_kWh',0) },\
wash:loadState:.off { ReadingsNum($name,'relay_0_kWh',0) - ReadingsNum($name,'total_temp',0) },\
price:loadState:.off {sprintf("%.2f",ReadingsNum($name,'wash',1)*ReadingsNum('du_kosten','kWhPreis',0))},\
time:loadState:.off {strftime("%H:%M", localtime(ReadingsAge($name,'total_temp',0)-3600))},\
relay_0_kWh_total:relay_0_kWh:.* monotonic {ReadingsNum($name,'relay_0_kWh',0)}
attr MQTT2_shellyplug_s_040C7E webCmd :
ich weiß, @Beta-User du hast gerne fertige Templates. Das mache ich aber noch gesammelt, da ich auch im Bereich Zigbee2mqtt aufräume. Hinzu kommt, dass ich meine alten Gen1 Shellys bis auf die PlugS rauß geschmissen habe und mit den Gen2 Shelly noch einiges testen muss.
Gruß,
87insane
Kann es sein, dass es im "Template hoymiles_opendtu_hub_bridge" einen Bug gibt? Oder ist der mehr in meine Hirn, wegen der mqtt Verwirrungen? ;-)
Aber "ac/power" und "dc/power" werden doch beide auf "power" gemapped. Damit hat man immer nur einen der beiden Werte ("dc/power"). Und zwar in dem Fall nicht den, der in der Weboberfläche der openDTU als "Gesamtleitung" angezeigt wird. Dadurch ist es mir aufgefallen. Das gleiche gilt für "is_valid", aber da habe ich noch keine unterschiedlichen Werte gesehen.
Entsprechend dem "hoymiles_opendtu_microinverter" könnte man für "dc/power" "powerdc" nehmen und für "ac/power" "power" lassen.
Zitat von: tomcat.x am 23 Mai 2023, 09:54:09Kann es sein, dass es im "Template hoymiles_opendtu_hub_bridge" einen Bug gibt? Oder ist der mehr in meine Hirn, wegen der mqtt Verwirrungen? ;-)
Kann schon sein - das ist vor längerem mal auf die Schnelle entstanden und ggf. schlicht "unfertig" - daher auch das "early version" in der desc..
Du kannst gerne hier (oder im hoymiles-Thread) einen aktualisierten Vorschlag machen, ich mag nur nicht "raten". Die aktuell vercodete readingList für das bub_bridge-Dingens ist nämlich irritierend kurz...
Hallo,
ich hab vor Kurzem gesehen, dass Nuki in ihrer neuen Firmware für das Nuki 3.0 Pro jetzt auch ein Interface per MQTT implementiert hat - damit sollte es möglich sein, dieses Schloss jetzt ohne dedizierte bridge in FHEM einzubinden.
Nach dem Anmelden an den MQTT-Server habe ich folgende Einträge in der reading-List der bridge gefunden (ID durch xxx ersetzt):
fhemRPI3:nuki/xxx/connected:.* connected
fhemRPI3:nuki/xxx/deviceType:.* deviceType
fhemRPI3:nuki/xxx/name:.* name
fhemRPI3:nuki/xxx/firmware:.* firmware
fhemRPI3:nuki/xxx/serverConnected:.* serverConnected
fhemRPI3:nuki/xxx/state:.* state
fhemRPI3:nuki/xxx/mode:.* mode
fhemRPI3:nuki/xxx/doorsensorState:.* doorsensorState
fhemRPI3:nuki/xxx/batteryCritical:.* batteryCritical
fhemRPI3:nuki/xxx/batteryChargeState:.* batteryChargeState
fhemRPI3:nuki/xxx/batteryCharging:.* batteryCharging
fhemRPI3:nuki/xxx/keypadBatteryCritical:.* keypadBatteryCritical
fhemRPI3:nuki/xxx/doorsensorBatteryCritical:.* doorsensorBatteryCritical
fhemRPI3:nuki/xxx/timestamp:.* timestamp
fhemRPI3:nuki/xxx/lockActionEvent:.* lockActionEvent
fhemRPI3:nuki/xxx/commandResponse:.* commandResponse
nach dem ich die set list dann folgendermassen gesetzt habe:
lock:noArg nuki/xxx/lockAction 2
unlock:noArg nuki/xxx/lockAction 1
open:noArg nuki/xxx/lockAction 3
hat das eigentlich schon recht gut funktioniert.
Ich bin leider nicht soweit, dass ich selber ein template anlegen könnte, aber vielleicht hat ja ein anderer Interesse.
Die Dokumentation der aktuellen mqtt-Api von Nuki habe ich hier gefunden:
https://developer.nuki.io/t/mqtt-api-specification-v1-4/19223
Grüsse,
Chris
Zitat von: grizu am 10 August 2023, 16:25:19Hallo,
ich hab vor Kurzem gesehen, dass Nuki in ihrer neuen Firmware für das Nuki 3.0 Pro jetzt auch ein Interface per MQTT implementiert hat - damit sollte es möglich sein, dieses Schloss jetzt ohne dedizierte bridge in FHEM einzubinden.
[...]
Ich bin leider nicht soweit, dass ich selber ein template anlegen könnte, aber vielleicht hat ja ein anderer Interesse.
Danke auf alle Fälle für's Posten.
Vielleicht kannst du mal auch die Readings bzw. deren Änderung (in einem separaten Thread und selbstredend anonymisiert) posten?
Speziell interessieren würde mich, ob die "state"-Anweisungen dann in der Rückmeldung von der Nuki-Bridge dann auch wieder in state landen oder woanders. In letzterem Fall sollte man das ggf. irgendwie umbiegen....
Hallo Beta-User
im Template shelly25_roller_invert_0 ist ein kleiner Fehler drin.
Das Attribut devStateIcon müsste von
.*/open:fts_shutter_up@red .*/close:fts_shutter_down@red true:10px-kreis-gruen false:10px-kreis-rot 0/stop:fts_shutter_100 100/stop:fts_shutter_10 9\d/stop:fts_shutter_10 8\d/stop:fts_shutter_20 7\d/stop:fts_shutter_30 6\d/stop:fts_shutter_40 5\d/stop:fts_shutter_50 4\d/stop:fts_shutter_60 3\d/stop:fts_shutter_70 2\d/stop:fts_shutter_80 1\d/stop:fts_shutter_90 0\d/stop:fts_shutter_100 set_.*:fts_shutter_updownzu
.*/opens:fts_shutter_up@red .*/closes:fts_shutter_down@red true:10px-kreis-gruen false:10px-kreis-rot 0/stop:fts_shutter_100 100/stop:fts_shutter_10 9\d/stop:fts_shutter_10 8\d/stop:fts_shutter_20 7\d/stop:fts_shutter_30 6\d/stop:fts_shutter_40 5\d/stop:fts_shutter_50 4\d/stop:fts_shutter_60 3\d/stop:fts_shutter_70 2\d/stop:fts_shutter_80 1\d/stop:fts_shutter_90 0\d/stop:fts_shutter_100 set_.*:fts_shutter_updowngeändert werden.
Das angehangene "s" bei open und close macht den unterschied.
Danke
melde mich seit langem mal wieder, bin nicht auf dem Laufenden ;)
Frage:
Ich hab mir ein paar neue Shelly PlusPlugS geholt und festgestellt, dass die sich in der Struktur der Daten doch gewaltig von der ersten Generation PlugS unterscheiden.
Gibts (vielleicht schon) eine Empfehlung für ein passendes Template?
Grüße, Dieter
Wie beim normalen PlugS auch.. Nimm einfach das Plus1PM Template.
Zitat von: 87insane am 10 November 2023, 14:50:16Wie beim normalen PlugS auch.. Nimm einfach das Plus1PM Template.
ah, cool - danke
Auslesen kann ich den PlusPlugS damit, aber nicht schalten?
Vielleicht hab ich auch nur die MQTT-Parameter im Shelly falsch gesetzt (siehe Anhang)?
hier noch ein List:
Internals:
CFGFN
CID shellyplusplugs_hwr_trockner
DEF shellyplusplugs_hwr_trockner
FUUID 6550e8e8-f33f-b5ae-3f85-6bcf55dc21bfcd1a
IODev myBroker
LASTInputDev myBroker
MSGCNT 8
NAME MQTT2_shellyplusplugs_hwr_trockner
NR 68739
STATE ???
TYPE MQTT2_DEVICE
eventCount 12
myBroker_CONN myBroker_192.168.178.130_50105
myBroker_MSGCNT 8
myBroker_TIME 2023-11-12 16:04:01
JSONMAP:
params_switch_0_temperature_tC temperature
params_switch_0_temperature_tF 0
params_wifi_sta_ip ip
result_in_mode in_mode
switch_aenergy_total aenergy_total
switch_apower apower
switch_state state
switch_temperature_tC temperature
switch_temperature_tF 0
OLDREADINGS:
READINGS:
2023-11-12 16:02:00 IODev myBroker
2023-11-12 16:03:41 attrTemplateVersion 20220303
2023-11-12 16:04:01 dst shellyplusplugs/events
2023-11-12 16:03:47 ip 192.168.178.130
2023-11-12 16:04:01 method NotifyStatus
2023-11-12 16:03:47 online true
2023-11-12 16:03:47 params_cloud_connected false
2023-11-12 16:03:42 params_events_1_component sys
2023-11-12 16:03:42 params_events_1_event scheduled_restart
2023-11-12 16:03:42 params_events_1_time_ms 997
2023-11-12 16:03:42 params_events_1_ts 1699801422.01
2023-11-12 16:03:47 params_mqtt_connected true
2023-11-12 16:04:01 params_switch_0_aenergy_by_minute_1 0.000
2023-11-12 16:04:01 params_switch_0_aenergy_by_minute_2 0.000
2023-11-12 16:04:01 params_switch_0_aenergy_by_minute_3 0.000
2023-11-12 16:04:01 params_switch_0_aenergy_minute_ts 1699801439
2023-11-12 16:04:01 params_switch_0_aenergy_total 741.019
2023-11-12 16:03:47 params_switch_0_apower 0.0
2023-11-12 16:03:47 params_switch_0_current 0.000
2023-11-12 16:04:01 params_switch_0_id 0
2023-11-12 16:03:47 params_switch_0_output true
2023-11-12 16:03:47 params_switch_0_source init
2023-11-12 16:03:47 params_switch_0_voltage 237.3
2023-11-12 16:03:47 params_sys_cfg_rev 43
2023-11-12 16:03:47 params_sys_fs_free 143360
2023-11-12 16:03:47 params_sys_fs_size 458752
2023-11-12 16:03:47 params_sys_kvs_rev 0
2023-11-12 16:03:47 params_sys_mac D4D4DAEBA234
2023-11-12 16:03:47 params_sys_ram_free 133480
2023-11-12 16:03:47 params_sys_ram_size 261236
2023-11-12 16:03:47 params_sys_restart_required false
2023-11-12 16:03:47 params_sys_schedule_rev 0
2023-11-12 16:03:47 params_sys_time 16:03
2023-11-12 16:03:47 params_sys_unixtime 1699801426
2023-11-12 16:03:47 params_sys_uptime 3
2023-11-12 16:03:47 params_sys_webhook_rev 0
2023-11-12 16:04:01 params_ts 1699801440.56
2023-11-12 16:03:47 params_wifi_rssi -77
2023-11-12 16:03:47 params_wifi_ssid Skynet
2023-11-12 16:03:47 params_wifi_status got ip
2023-11-12 16:03:47 params_ws_connected false
2023-11-12 16:04:01 src shellyplusplugs-d4d4daeba234
2023-11-12 16:03:47 temperature 36.9
2023-11-12 16:03:41 x_reboot set
Attributes:
devStateIcon {my $onl = ReadingsVal($name,'online','false') eq 'false'?'10px-kreis-rot':'10px-kreis-gruen'; $onl = FW_makeImage($onl); my $light = FW_makeImage(ReadingsVal($name,'state','off')); my $cons = ReadingsNum($name,'apower',0); my $total = round(ReadingsNum($name,'aenergy_total',0)/1000,3); my $temp = ReadingsVal($name,'temperature','-100'); my $ip = ReadingsVal($name,'ip','none'); my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':''; qq(<a href="http://$ip" target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>$reb<div>Verbrauch: $cons W / Total: $total kwh / Temp: $temp °C</div>)}
devicetopic shellyplusplugs
getList in_mode:noArg in_mode $DEVICETOPIC/rpc {"id": 1,"src":"$DEVICETOPIC", "method": "Switch.GetConfig", "params": {"id": 0}}
icon message_socket
jsonMap switch_state:state switch_aenergy_total:aenergy_total switch_apower:apower switch_temperature_tC:temperature switch_temperature_tF:0 params_wifi_sta_ip:ip params_switch_0_temperature_tC:temperature params_switch_0_temperature_tF:0 result_in_mode:in_mode
model shellyPlus_1pm
readingList $DEVICETOPIC/online:.* online
$DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/status/mqtt:.* { json2nameValue($EVENT, 'mqtt_', $JSONMAP) }
$DEVICETOPIC/status/sys:.* { json2nameValue($EVENT, 'sys_', $JSONMAP) }
$DEVICETOPIC/status/switch_0:.* { $EVENT =~ s/"output":true/"state":"on"/g; $EVENT =~ s/"output":false/"state":"off"/g; json2nameValue($EVENT, 'switch_', $JSONMAP) }
$DEVICETOPIC/status/cloud:.* {}
$DEVICETOPIC/rpc:.* { json2nameValue($EVENT, 'req_', $JSONMAP, 'in_mode')}
$DEVICETOPIC/status/input_0:.* { json2nameValue($EVENT, 'input_', $JSONMAP) }
fhem2shelly/rpc:.* {}
room MQTT2_DEVICE
setList toggle:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Toggle","params": {"id":0}}
off:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false}}
on:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":true}}
on-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":true,"toggle_after":$EVTPART1}}
off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false,"toggle_after":$EVTPART1}}
in_mode:toggle,flip,detached {fhem("sleep 0.2; get $NAME in_mode"); my $val = $EVTPART1 ne 'toggle' ? $EVTPART1 : ReadingsVal($NAME,'in_mode','flip') eq 'flip' ? 'detached':'flip'; qq($DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$val"}}})}
x_update:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Shelly.Update","params": {"stage":"stable"}}
x_reboot:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Shelly.Reboot"}
x_eco:true,false $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
setStateList on off toggle on-for-timer off-for-timer
webCmd :
Zitat von: grappa24 am 11 November 2023, 23:37:08Vielleicht hab ich auch nur die MQTT-Parameter im Shelly falsch gesetzt (siehe Anhang)?
das wars, "Generic status update over MQTT" muss aktiviert sein in der Shelly-Konfig.
Danke nochmal @87insane für den Tipp mit dem Plus_1pm Template ;)
Hi, ich versuche ein Template für den Philips HUE Outdoor Sensor zu erstellen (der ein paar Werte/Einstellungen bietet, die im vorhandenen Template für den hue sensor nicht enthalten sind). U.a. möchte ich, dass das Reading für erkannte Bewegung nicht "occupancy", sondern "motion" heißt. Deswegen habe ich im Template
attr DEVICE jsonMap occupancy:motion
gesetzt. Das funktioniert aber nicht. Was übersehe ich?
MQTT2_DEVICE vor dem Anwenden des Templates:
Internals:
CFGFN
CID zigbee_Motion_ELW_Eingang
DEF zigbee_Motion_ELW_Eingang
FUUID 6555ce25-f33f-e1ef-c901-36d864d7c921bd4c
IODev myBroker
LASTInputDev myBroker
MSGCNT 55
NAME MQTT2_zigbee_Motion_ELW_Eingang
NR 3441
STATE ???
TYPE MQTT2_DEVICE
eventCount 56
myBroker_MSGCNT 55
myBroker_TIME 2023-11-16 10:17:21
READINGS:
2023-11-16 09:09:09 IODev myBroker
2023-11-16 10:17:21 Motion_ELW_Eingang_battery 100
2023-11-16 10:17:21 Motion_ELW_Eingang_illuminance 26262
2023-11-16 10:17:21 Motion_ELW_Eingang_illuminance_lux 423
2023-11-16 10:17:21 Motion_ELW_Eingang_led_indication false
2023-11-16 10:17:21 Motion_ELW_Eingang_linkquality 47
2023-11-16 10:17:21 Motion_ELW_Eingang_motion_sensitivity low
2023-11-16 10:17:21 Motion_ELW_Eingang_occupancy false
2023-11-16 10:17:21 Motion_ELW_Eingang_occupancy_timeout 1
2023-11-16 10:17:21 Motion_ELW_Eingang_temperature 7.64
2023-11-16 09:09:09 associatedWith MQTT2_zigbee_bridge
Attributes:
readingList zigbee2mqtt/Motion_ELW_Eingang:.* { json2nameValue($EVENT, 'Motion_ELW_Eingang_', $JSONMAP) }
room MQTT2_DEVICE
Und danach:
Internals:
CFGFN
CID zigbee_Motion_ELW_Eingang
DEF zigbee_Motion_ELW_Eingang
FUUID 6555ce25-f33f-e1ef-c901-36d864d7c921bd4c
IODev myBroker
LASTInputDev myBroker
MSGCNT 57
NAME Motion_ELW_Eingang
NR 3441
STATE motion
TYPE MQTT2_DEVICE
eventCount 59
myBroker_MSGCNT 57
myBroker_TIME 2023-11-16 10:27:20
JSONMAP:
occupancy motion
OLDREADINGS:
READINGS:
2023-11-16 09:09:09 IODev myBroker
2023-11-16 09:09:09 associatedWith MQTT2_zigbee_bridge
2023-11-16 10:21:08 attrTemplateVersion 20231115
2023-11-16 10:27:20 battery 100
2023-11-16 10:27:20 illuminance 25807
2023-11-16 10:27:20 illuminance_lux 381
2023-11-16 10:27:20 led_indication false
2023-11-16 10:27:20 linkquality 47
2023-11-16 10:27:20 motion_sensitivity low
2023-11-16 10:27:20 occupancy false
2023-11-16 10:27:20 occupancy_timeout 1
2023-11-16 10:27:20 temperature 7.64
Attributes:
devStateIcon motion:motion_detector@red .*:motion_detector
devicetopic zigbee2mqtt/Motion_ELW_Eingang
icon people_sensor
jsonMap occupancy:motion
model zigbee2mqtt_hueMotionOutdoorSensor
readingList $DEVICETOPIC:.* { json2nameValue($EVENT) }
$DEVICETOPIC/availability:.* availability
room MQTT2_DEVICE
setList motion_sensitivity:low,medium,high,very_high,max $DEVICETOPIC/set {"motion_sensitivity": "$EVTPART1"}
led_indication:true,false $DEVICETOPIC/set {"led_indication": "$EVTPART1"}
occupancy_timeout:slider,0,1,40,0 $DEVICETOPIC/set {"occupancy_timeout": "$EVTPART1"}
stateFormat motion
Der aktuelle Template-Entwurf:
name:zigbee2mqtt_hueMotionOutdoorSensor
desc: Philips Hue Outdoor Motion Sensor
filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
order:L_04a
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 }
par:ICON;ICON as set, defaults to motion_detector;{ AttrVal("DEVICE","icon","people_sensor") }
attr DEVICE icon ICON
attr DEVICE jsonMap occupancy:motion
# attr DEVICE readingList $\DEVICETOPIC:.* { my $ret=json2nameValue($EVENT); $ret->{state}=lc($ret->{state}) if defined $ret->{state}; return $ret }
attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT) }\
$\DEVICETOPIC/availability:.* availability
deletereading -q DEVICE (?!associatedWith|IODev).*
attr DEVICE devStateIcon motion:motion_detector@red .*:motion_detector
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE setList \
motion_sensitivity:low,medium,high,very_high,max $\DEVICETOPIC/set {"motion_sensitivity": "$EVTPART1"}\
led_indication:true,false $\DEVICETOPIC/set {"led_indication": "$EVTPART1"}\
occupancy_timeout:slider,0,1,40,0 $\DEVICETOPIC/set {"occupancy_timeout": "$EVTPART1"}
attr DEVICE stateFormat motion
attr DEVICE model zigbee2mqtt_hueMotionOutdoorSensor
setreading DEVICE attrTemplateVersion 20231115
Wäre klasse, wenn mir jemand kurz vom Schlauch helfen könnte bitte.
Hallo,
im Template bei :
attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT) }
json2namevalue so ergänzen:
attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
Dein MQTT2_SERVER myBroker ist auf autocreate complex eingestellt ? Warum ?
Hallo,
ich habe mir einen neuen ShellyPlusPlugS gekauft und bekomme diesen leider nicht zum laufen.
Ich würde gern bei der Fehlersuche helfen, benötige aber etwas Anleitung.
defmod MQTT2_shellyplusplugs_d4d4daf50c10 MQTT2_DEVICE shellyplusplugs_d4d4daf50c10
attr MQTT2_shellyplusplugs_d4d4daf50c10 devStateIcon {my $onl = ReadingsVal($name,'online','false') eq 'false'?'10px-kreis-rot':'10px-kreis-gruen';; $onl = FW_makeImage($onl);; my $light = FW_makeImage(ReadingsVal($name,'state','off'));; my $cons = ReadingsNum($name,'apower',0);; my $total = round(ReadingsNum($name,'aenergy_total',0)/1000,3);; my $temp = ReadingsVal($name,'temperature_tC','0');; my $ip = ReadingsVal($name,'ip','none');; my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':'';; qq(<a href="http://$ip" target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>$reb<div>Verbrauch: $cons W / Total: $total kwh / Temp: $temp °C</div>)}
attr MQTT2_shellyplusplugs_d4d4daf50c10 devicetopic shellyplusplugs
attr MQTT2_shellyplusplugs_d4d4daf50c10 getList in_mode:noArg in_mode $DEVICETOPIC/rpc {"id": 1,"src":"$DEVICETOPIC", "method": "Switch.GetConfig", "params": {"id": 0}}
attr MQTT2_shellyplusplugs_d4d4daf50c10 icon message_socket
attr MQTT2_shellyplusplugs_d4d4daf50c10 jsonMap switch_state:state switch_aenergy_total:aenergy_total switch_apower:apower switch_temperature_tC:temperature switch_temperature_tF:0 params_wifi_sta_ip:ip params_switch_0_temperature_tC:temperature params_switch_0_temperature_tF:0 result_in_mode:in_mode
attr MQTT2_shellyplusplugs_d4d4daf50c10 model shellyPlus_1pm
attr MQTT2_shellyplusplugs_d4d4daf50c10 readingList $DEVICETOPIC/online:.* online\
$DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT,'',$JSONMAP) }\
$DEVICETOPIC/status/mqtt:.* { json2nameValue($EVENT, 'mqtt_', $JSONMAP) }\
$DEVICETOPIC/status/sys:.* { json2nameValue($EVENT, 'sys_', $JSONMAP) }\
$DEVICETOPIC/status/switch_0:.* { $EVENT =~ s/"output":true/"state":"on"/g;; $EVENT =~ s/"output":false/"state":"off"/g;; json2nameValue($EVENT, 'switch_', $JSONMAP) }\
$DEVICETOPIC/status/cloud:.* {}\
$DEVICETOPIC/rpc:.* { json2nameValue($EVENT, 'req_', $JSONMAP, 'in_mode')}\
$DEVICETOPIC/status/input_0:.* { json2nameValue($EVENT, 'input_', $JSONMAP) }\
fhem2shelly/rpc:.* {}\
shellyplusplugs_d4d4daf50c10:shellyplusplugs-d4d4daf50c10/events/rpc:.* { json2nameValue($EVENT) }\
shellyplusplugs_d4d4daf50c10:shellyplusplugs-d4d4daf50c10/status/switch_0:.* { json2nameValue($EVENT) }\
shellyplusplugs_d4d4daf50c10:shellyplusplugs-d4d4daf50c10/online:.* online\
shellyplusplugs_d4d4daf50c10:shellyplusplugs-d4d4daf50c10/status/ble:.* ble\
shellyplusplugs_d4d4daf50c10:shellyplusplugs-d4d4daf50c10/status/cloud:.* { json2nameValue($EVENT) }\
shellyplusplugs_d4d4daf50c10:shellyplusplugs-d4d4daf50c10/status/ffs:.* { json2nameValue($EVENT) }\
shellyplusplugs_d4d4daf50c10:shellyplusplugs-d4d4daf50c10/status/mqtt:.* { json2nameValue($EVENT) }\
shellyplusplugs_d4d4daf50c10:shellyplusplugs-d4d4daf50c10/status/plugs_ui:.* plugs_ui\
shellyplusplugs_d4d4daf50c10:shellyplusplugs-d4d4daf50c10/status/sys:.* { json2nameValue($EVENT) }\
shellyplusplugs_d4d4daf50c10:shellyplusplugs-d4d4daf50c10/status/wifi:.* { json2nameValue($EVENT) }\
shellyplusplugs_d4d4daf50c10:shellyplusplugs-d4d4daf50c10/status/ws:.* { json2nameValue($EVENT) }
attr MQTT2_shellyplusplugs_d4d4daf50c10 room MQTT2_DEVICE
attr MQTT2_shellyplusplugs_d4d4daf50c10 setList toggle:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Toggle","params": {"id":0}}\
off:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false}}\
on:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":true}}\
on-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":true,"toggle_after":$EVTPART1}}\
off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false,"toggle_after":$EVTPART1}}\
in_mode:toggle,flip,detached {fhem("sleep 0.2;; get $NAME in_mode");; my $val = $EVTPART1 ne 'toggle' ? $EVTPART1 : ReadingsVal($NAME,'in_mode','flip') eq 'flip' ? 'detached':'flip';; qq($DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$val"}}})}\
x_update:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Shelly.Update","params": {"stage":"stable"}}\
x_reboot:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Shelly.Reboot"}\
x_eco:true,false $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
attr MQTT2_shellyplusplugs_d4d4daf50c10 setStateList on off toggle on-for-timer off-for-timer
attr MQTT2_shellyplusplugs_d4d4daf50c10 webCmd :
setstate MQTT2_shellyplusplugs_d4d4daf50c10 set_toggle
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:05:29 IODev myBroker
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 aenergy_by_minute_1 0.000
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 aenergy_by_minute_2 0.000
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 aenergy_by_minute_3 0.000
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 aenergy_minute_ts 1700162099
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 aenergy_total 0.000
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 apower 0.0
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:06:08 attrTemplateVersion 20220303
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 available_updates_beta_version 1.1.0-beta2
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 ble {}
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 cfg_rev 6
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 connected true
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 current 0.000
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 dst shellyplusplugs-d4d4daf50c10/events
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 fs_free 143360
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 fs_size 458752
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 id 0
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 kvs_rev 0
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 mac D4D4DAF50C10
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 method NotifyStatus
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 online true
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 output false
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_cloud_connected false
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_mqtt_connected true
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 params_switch_0_aenergy_by_minute_1 0.000
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 params_switch_0_aenergy_by_minute_2 0.000
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 params_switch_0_aenergy_by_minute_3 0.000
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 params_switch_0_aenergy_minute_ts 1700162099
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 params_switch_0_aenergy_total 0.000
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_switch_0_apower 0.0
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_switch_0_current 0.000
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 params_switch_0_id 0
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_switch_0_output false
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_switch_0_source init
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_switch_0_temperature_tC 37.4
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_switch_0_temperature_tF 99.3
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_switch_0_voltage 0.0
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_sys_available_updates_beta_version 1.1.0-beta2
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_sys_cfg_rev 6
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_sys_fs_free 143360
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_sys_fs_size 458752
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_sys_kvs_rev 0
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_sys_mac D4D4DAF50C10
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_sys_ram_free 123128
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_sys_ram_size 261044
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_sys_restart_required false
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_sys_schedule_rev 0
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_sys_time 20:08
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_sys_unixtime 1700161729
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_sys_uptime 197
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_sys_webhook_rev 0
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 params_ts 1700162100.43
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_wifi_rssi -47
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_wifi_ssid FRITZ!Box 7490
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_wifi_sta_ip 192.168.9.254
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_wifi_status got ip
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 params_ws_connected false
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 plugs_ui {}
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 ram_free 121828
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 ram_size 260972
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 restart_required false
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 rssi -47
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 schedule_rev 0
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 source init
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 src shellyplusplugs-d4d4daf50c10
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 ssid FRITZ!Box 7490
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 sta_ip 192.168.9.254
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:06:23 state set_toggle
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 status got ip
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 temperature_tC 37.4
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 temperature_tF 99.3
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 time 20:08
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 ts 0
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 unixtime 1700161729
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 uptime 197
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:15:00 voltage 0.0
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:08:49 webhook_rev 0
setstate MQTT2_shellyplusplugs_d4d4daf50c10 2023-11-16 20:06:08 x_reboot set
Mein Problem:
Der Shelly lässt sich nicht schalten.
Als Template nutze ich ShellyPlus_1pm (ShellyPlug ist nicht vorhanden)
Anbindung an Fhem funktioniert, bis auf das Schalten.
Gruß Rico
hatte ich auch das Problem. Das Template ShellyPlus_1pm funktioniert.
Bei mir lag es an den MQTT Einstellungen im Shelly.
U.a. braucht jeder Shelly aus GEN2 wohl sein eigenes Prefix, während die Client-ID offensichtlich niemanden interessiert ...
[quot
Zitat von: grappa24 am 16 November 2023, 22:03:06U.a. braucht jeder Shelly aus GEN2 wohl sein eigenes Prefix, während die Client-ID offensichtlich niemanden interessiert ...
Danke für den Tipp.
Ich werde dort heute mal herum probieren...allerdings ist es da einzigste Gerät (ShellyPlug)in meiner Testumgebung
ich habs deshalb erwähnt, weil meine shellies GEN1 alle das gleiche MQTT-Prefix haben und sich dann in der ID unterscheiden.
Die GEN2 shellies müssen sich offensichtlich schon im Prefix unterscheiden
Hallo nochmal,
ich brauch scheinbar mehr Hilfe.
Am Prefix liegt es nicht. Was kann ich noch testen?
Anbei noch ein Auszug aus dem Log und dem Device Log.
2023.11.17 13:54:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/status/switch_0 => { json2nameValue($EVENT) }
2023.11.17 13:55:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 13:55:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/status/switch_0 => { json2nameValue($EVENT) }
2023.11.17 13:55:29 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 13:55:29 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/status/switch_0 => { json2nameValue($EVENT) }
2023.11.17 13:55:31 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 13:55:31 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/status/switch_0 => { json2nameValue($EVENT) }
2023.11.17 13:55:32 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 13:55:32 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/status/switch_0 => { json2nameValue($EVENT) }
2023.11.17 13:55:58 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 13:55:58 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/status/sys => { json2nameValue($EVENT) }
2023.11.17 13:55:58 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 13:56:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 13:56:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/status/switch_0 => { json2nameValue($EVENT) }
2023.11.17 13:57:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 13:57:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/status/switch_0 => { json2nameValue($EVENT) }
2023.11.17 13:58:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 13:58:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/status/switch_0 => { json2nameValue($EVENT) }
2023.11.17 13:59:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 13:59:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/status/switch_0 => { json2nameValue($EVENT) }
2023.11.17 14:00:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 14:00:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/status/switch_0 => { json2nameValue($EVENT) }
2023.11.17 14:01:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 14:01:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/status/switch_0 => { json2nameValue($EVENT) }
2023.11.17 14:02:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 14:02:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/status/switch_0 => { json2nameValue($EVENT) }
2023.11.17 14:02:25 3: MQTT2_DEVICE set MQTT2_KuecheHermann off
2023.11.17 14:02:52 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 14:02:55 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 14:02:56 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 14:02:58 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 14:02:59 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 14:03:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 14:03:00 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/status/switch_0 => { json2nameValue($EVENT) }
2023.11.17 14:03:01 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 14:03:02 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }
2023.11.17 14:03:03 4: MQTT2_DEVICE_Parse: MQTT2_KuecheHermann d4d4daf50c10/events/rpc => { json2nameValue($EVENT) }2023-11-17_15:01:00 MQTT2_KuecheHermann src: shellyplusplugs-d4d4daf50c10
2023-11-17_15:01:00 MQTT2_KuecheHermann params_switch_0_id: 0
2023-11-17_15:01:00 MQTT2_KuecheHermann params_switch_0_aenergy_by_minute_1: 0.000
2023-11-17_15:01:00 MQTT2_KuecheHermann params_switch_0_aenergy_by_minute_3: 0.000
2023-11-17_15:01:00 MQTT2_KuecheHermann method: NotifyStatus
2023-11-17_15:01:00 MQTT2_KuecheHermann params_ts: 1700229660.81
2023-11-17_15:01:00 MQTT2_KuecheHermann current: 0.000
2023-11-17_15:01:00 MQTT2_KuecheHermann output: true
2023-11-17_15:01:00 MQTT2_KuecheHermann aenergy_by_minute_3: 0.000
2023-11-17_15:01:00 MQTT2_KuecheHermann aenergy_minute_ts: 1700229659
2023-11-17_15:01:00 MQTT2_KuecheHermann source: init
2023-11-17_15:01:00 MQTT2_KuecheHermann temperature_tF: 109.5
2023-11-17_15:01:00 MQTT2_KuecheHermann id: 0
2023-11-17_15:01:00 MQTT2_KuecheHermann temperature_tC: 43.1
2023-11-17_15:01:00 MQTT2_KuecheHermann apower: 0.0
2023-11-17_15:01:00 MQTT2_KuecheHermann aenergy_by_minute_2: 0.000
2023-11-17_15:01:00 MQTT2_KuecheHermann aenergy_by_minute_1: 0.000
2023-11-17_15:01:00 MQTT2_KuecheHermann aenergy_total: 0.000
2023-11-17_15:01:00 MQTT2_KuecheHermann voltage: 234.8
2023-11-17_15:02:00 MQTT2_KuecheHermann params_switch_0_aenergy_by_minute_2: 0.000
2023-11-17_15:02:00 MQTT2_KuecheHermann params_switch_0_aenergy_minute_ts: 1700229719
2023-11-17_15:02:00 MQTT2_KuecheHermann dst: d4d4daf50c10/events
2023-11-17_15:02:00 MQTT2_KuecheHermann params_switch_0_aenergy_total: 0.000
2023-11-17_15:02:00 MQTT2_KuecheHermann method: NotifyStatus
2023-11-17_15:02:00 MQTT2_KuecheHermann params_ts: 1700229720.81
2023-11-17_15:02:00 MQTT2_KuecheHermann params_switch_0_aenergy_by_minute_1: 0.000
2023-11-17_15:02:00 MQTT2_KuecheHermann src: shellyplusplugs-d4d4daf50c10
2023-11-17_15:02:00 MQTT2_KuecheHermann params_switch_0_id: 0
2023-11-17_15:02:00 MQTT2_KuecheHermann params_switch_0_aenergy_by_minute_3: 0.000
2023-11-17_15:02:00 MQTT2_KuecheHermann apower: 0.0
2023-11-17_15:02:00 MQTT2_KuecheHermann temperature_tC: 43.1
2023-11-17_15:02:00 MQTT2_KuecheHermann aenergy_by_minute_2: 0.000
2023-11-17_15:02:00 MQTT2_KuecheHermann aenergy_by_minute_1: 0.000
2023-11-17_15:02:00 MQTT2_KuecheHermann aenergy_total: 0.000
2023-11-17_15:02:00 MQTT2_KuecheHermann voltage: 235.1
2023-11-17_15:02:00 MQTT2_KuecheHermann aenergy_by_minute_3: 0.000
2023-11-17_15:02:00 MQTT2_KuecheHermann current: 0.000
2023-11-17_15:02:00 MQTT2_KuecheHermann output: true
2023-11-17_15:02:00 MQTT2_KuecheHermann source: init
2023-11-17_15:02:00 MQTT2_KuecheHermann temperature_tF: 109.6
2023-11-17_15:02:00 MQTT2_KuecheHermann aenergy_minute_ts: 1700229719
2023-11-17_15:02:00 MQTT2_KuecheHermann id: 0
@rico5588:
Hast du alle o.a. Häkchen in der MQTT Konfig gesetzt? Bei mir hatte generic status update gefehlt. Ich konnte lesen, aber nicht schreiben
Ja das sieht bei mir genau gleich aus. Alle Haken sind drin.
Hast du ein Tool wie z.b. den MQTT Explorer, dass du mal schauen kannst, ob und was dein Broker sendet?
Die Lösung war doch recht simpel. Warum ich das übersehen habe? ...keine Ahnung. Es ist anders wie vorherige Shelly Teilnehmer.
Fazit ist das der MQTT Prefix nicht zusammengepasst hat.
Im attr devicetopic des Gerätes muss der gleiche Wert drin stehen wie im Shelly unter MQTT Prefix.
Drauf gekommen bin ich über den MQTT Browser. Ein sehr nettes Tool, kannte ich so noch nicht.
Danke für die schnelle Hilfe.
Ein schönes Wochende.
Hallo zusammen,
ich habe einen 4chpror3 (https://sonoff.tech/product/diy-smart-switches/4chr3-4chpror3/) von sonoff, den ich mit der original FW und mit Hilfe von Nickwaterton (https://github.com/NickWaterton/eWeLink-mqtt)python code in fhem integriert habe.
Das Gerät ist jetzt in fhem als Device integriert (autocreate =1) und ich kann alle redeings sehen.
r1.PNG
Wenn ich jedoch eine Vorlage auswähle, erhalte ich folgendes, von dem ich nicht weiß, wie ich es ausfüllen soll.
t1.PNG
Command topic prefix, without trailing /
info topic prefix, without trailing /
ack topic prefix, without trailing /Im Grunde sollte es ähnlich wie tasmota_4ch_unified_icon sein, auch mit tasmota_basic das gleiche abgefragt wird. Irgendeine Idee, wie ich das beheben kann?
Die Steuerung mit dem Gerät funktioniert in Terminal. Ich kann die folgende Anfrage übermitteln :
Zitatmosquitto_pub -t "/ewelink_command/100cf33331/switches" -m "0 off 1 off 2 off 3 on"
und es wird im fhem readings angezeigt. aber
Mein Ziel ist es jedoch, alles innerhalb von fhem zu machen.
Besten dank
Hi,
schrägen Ansatz fährst Du mMn, ein Template anwenden wollen was nicht für das Gerät gedacht ist. :o
Tipp: drück nicht blind set, sondern schau Dir den Text an wenn Du das Template auswählst, da steht alles drin was Du ev. gebrauchen kannst.
Wenn die Abfrage kommt die Du hier nachfragst - ist allgemein was schief gelaufen, hier: Template passt nicht zum Device.
mMn macht es in deinem Fall keinen Sinn wenn Du die Frage beantwortest (die Felder ausfüllst)
Gruß Otto
Hallo zusammen,
Ich verwende das Template ,,hoymiles_opendtu_hub_bridge" um meine Hoymiles Wechselrichter per OpenDTU an FHEM anzubinden.
Nachdem das so weit alles lief, viel mir auf, dass die Summen-Leistung ,,Power" die als Reading im Device DTU angezeigt wird, nicht mit dem Wert auf der OpenDTU Oberfläche übereinstimmt.
Habe mir das heute mal angesehen und dabei ist mir aufgefallen, dass sowohl die AC-Leistung als auch die DC-Leistung auf das Reading ,,Power" gemapt wird.
Da zwischen AC- und DC-Leistung der Wirkungsgrad des Wechselrichters liegt, macht das so nach meiner Meinung keinen Sinn.
Viele Grüße Michael
Zitat von: Elektron am 25 Februar 2024, 18:19:46Habe mir das heute mal angesehen und dabei ist mir aufgefallen, dass sowohl die AC-Leistung als auch die DC-Leistung auf das Reading ,,Power" gemapt wird.
Bei mir habe ich DC-Leistung auf "powerdc" gemappt, ohne über Namenskonventionen weiter nachzudenken (also nicht sicher, ob das so ins template sollte). Auch das was mich eigentlich interessiert, ist die AC-Leistung, die habe ich auf "power" gelassen.
Zitat von: tomcat.x am 07 März 2024, 10:14:22Zitat von: Elektron am 25 Februar 2024, 18:19:46Habe mir das heute mal angesehen und dabei ist mir aufgefallen, dass sowohl die AC-Leistung als auch die DC-Leistung auf das Reading ,,Power" gemapt wird.
Bei mir habe ich DC-Leistung auf "powerdc" gemappt, ohne über Namenskonventionen weiter nachzudenken (also nicht sicher, ob das so ins template sollte). Auch das was mich eigentlich interessiert, ist die AC-Leistung, die habe ich auf "power" gelassen.
Das aktuelle template nennt das soweit erkennbar auch "powerdc" (es gibt afaik leider (!) noch keine Namenskonvention für PV-bezogene Readings). Aber immer noch gilt die Bitte, diesen Thread nur als "Anlaufstelle" zu nutzen, für Hoymiles gibt es den Spezialthread https://forum.fhem.de/index.php?topic=121282.0.
Platzhalter Post
Hi
Ich werd hier noch etliches rein editieren, deshalb die Kennzeichnung als Platzhalter.
Ich hab mir 4 Tür und Fenster Kontakte besorgt. Shelly Blu door/windows
Die waren günstig und ich dachte mir, in meiner blauäugigen Art, das wird schon.
Denkste! Geplant war, die einfach zu mein bestehenden BLE tasmota dran zu hängen.
(Klingt jetzt für euch alles sehr wirr und was soll das hier im Thread,aber wartet erstmal ab. ich lager des zum einen nochmals aus und zum andern sind mir einige fehlerchen/Änderungen in den templates aufgefallen. In Summe aber soviel, das ich mir die zuerstmal selbst sortieren muß)
Und zwar geht es um die templates bezüglich openMqttGabeway. (Da hat sich einiges getan und man sollte die templates ggf überarbeiten o. Ergänzen)
Mein zweites Anliegen, ich hab jetzt wieder zwei Tage intensiv pingpong im Forum gelesen, weil die Informationen, atomisiert verstreut zu finden sind ... oder auch nicht.
Deshalb:
Ums Wiki will ich mich dann auch gleich noch kümmern. Denn ich denke die Bluetooth Geschichte nimmt mehr und mehr Fahrt auf.
BLE ist hier das Schlagwort und z.t. Sehr lange Batterie Laufzeiten.
Also bitte nicht sofort steinigen, der Text hier oben fliegt zeitnah wieder raus und landet in nem gesonderten Thread.
**** eigentlicher Teil des post****(hier kommt noch einiges)
1.
Ich habe wie auf dem Screenshot zu sehen ist. 3 OMG (OpenMqttGateways) am laufen.
Die mit dem ergebniss (oberstes OMG_ESP32) nach Anwenden des templates so aussehen.
Die variablen im statesformat passen nicht. Hab ich schon händisch bei den unteren geändert. Codeschnipsel folgt.
2.
Wie kann man über das Template Set config Befehle absenden in dem Format
mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoBT/config -m '{"hasspresence":true}'
Set device config -m hasspresence:true ?
Geht das überhaupt über den Weg? Könne man ggf die Anleitung nach dem post hier dann anpassen. Im Wiki machs ich. Und ggf wärs ja was für die commandref?
Moin zusammen,
mir ist grad aufgefallen, dass das Template für WLED nur max. 15 Presets anzeigt.
Da ich 20 Presets definiert habe, sollte das ggf. auf einen höheren Wert angepasst werden.
Außerdem, falls möglich, wären die Namen der Presets ganz nett.
Lässt sich das so umsetzen?
Grüße
[ANFRAGE]
Ich habe seit neuestem ein NUKI und möchte mir die Bridge sparen.
Dabei bin ich auf das Github Projekt Nuki_hub (https://github.com/technyon/nuki_hub) gestoßen.
Damit kann ein ESP32 Modul geflasht und als MQTT Schnittstelle verwendet werden.
Es wäre Prima hierfür ein MQTT2 Modul zu haben.
Leider bin ich nicht in der Lage ein solches zu erstellen.
Mag das jemand übernehmen, um das NUKI kostengünstig an FHEM anbinden zu können?
Die Nuki Bridge ist ja um den Faktor 10 teurer (gebraucht)
Zitat von: Dlay am 14 März 2024, 23:36:08[ANFRAGE]
Ich habe seit neuestem ein NUKI und möchte mir die Bridge sparen.
Dabei bin ich auf das Github Projekt Nuki_hub (https://github.com/technyon/nuki_hub) gestoßen.
Damit kann ein ESP32 Modul geflasht und als MQTT Schnittstelle verwendet werden.
Es wäre Prima hierfür ein MQTT2 Modul zu haben.
Leider bin ich nicht in der Lage ein solches zu erstellen.
Mag das jemand übernehmen, um das NUKI kostengünstig an FHEM anbinden zu können?
Die Nuki Bridge ist ja um den Faktor 10 teurer (gebraucht)
So sehen die Readings aus, die MQTT2 automatisch anlegt.
nukihub:nuki/maintenance/networkDevice:.* networkDevice
nukihub:nuki/lock/action:.* action
nukihub:nuki/lock/query/battery:.* battery
nukihub:nuki/lock/query/config:.* config
nukihub:nuki/lock/query/lockstate:.* lockstate
nukihub:nuki/maintenance/reset:.* reset
nukihub:nuki/maintenance/mqttConnectionState:.* mqttConnectionState
nukihub:nuki/info/nukiHubIp:.* nukiHubIp
nukihub:nuki/maintenance/uptime:.* uptime
nukihub:nuki/info/nukiHubVersion:.* nukiHubVersion
nukihub:nuki/lock/address:.* address
nukihub:nuki/lock/query/lockstateCommandResult:.* lockstateCommandResult
nukihub:nuki/lock/trigger:.* trigger
nukihub:nuki/lock/lastLockAction:.* lastLockAction
nukihub:nuki/lock/completionStatus:.* completionStatus
nukihub:nuki/lock/doorSensorState:.* doorSensorState
nukihub:nuki/battery/critical:.* critical
nukihub:nuki/battery/charging:.* charging
nukihub:nuki/battery/level:.* level
nukihub:nuki/battery/keypadCritical:.* keypadCritical
nukihub:nuki/lock/json:.* { json2nameValue($EVENT) }
nukihub:nuki/presence/devices:.* { json2nameValue($EVENT) }
nukihub:nuki/battery/voltage:.* voltage
nukihub:nuki/battery/drain:.* drain
nukihub:nuki/battery/maxTurnCurrent:.* maxTurnCurrent
nukihub:nuki/battery/lockDistance:.* lockDistance
nukihub:nuki/configuration/buttonEnabled:.* buttonEnabled
nukihub:nuki/configuration/ledEnabled:.* ledEnabled
nukihub:nuki/configuration/ledBrightness:.* ledBrightness
nukihub:nuki/configuration/singleLock:.* singleLock
nukihub:nuki/info/firmwareVersion:.* firmwareVersion
nukihub:nuki/info/hardwareVersion:.* hardwareVersion
nukihub:nuki/configuration/autoUnlock:.* autoUnlock
nukihub:nuki/configuration/autoLock:.* autoLock
nukihub:nuki/lock/rssi:.* rssi
nukihub:nuki/lock/log:.* log
nukihub:nuki/lock/authorizationId:.* authorizationId
nukihub:nuki/lock/authorizationName:.* authorizationName
nukihub:nuki/maintenance/wifiRssi:.* wifiRssi
Eine kleine setList hab ich hinbekommen:
lock:noArg nuki/lock/action lock
unlock:noArg nuki/lock/action unlock
unlatch:noArg nuki/lock/action unlatch
lockNgo:noArg nuki/lock/action lockNgo
lockNgoUnlatch:noArg nuki/lock/action lockNgoUnlatch
fullLock:noArg nuki/lock/action fullLock
hubreboot:noArg nuki/maintenance/reset 1
In der Docu gibt es noch weit mehr :-\
Zitat von: Dlay am 13 März 2024, 19:58:44Moin zusammen,
mir ist grad aufgefallen, dass das Template für WLED nur max. 15 Presets anzeigt.
Da ich 20 Presets definiert habe, sollte das ggf. auf einen höheren Wert angepasst werden.
Außerdem, falls möglich, wären die Namen der Presets ganz nett.
Lässt sich das so umsetzen?
Grüße
Dann helf ich mir mal selbst:
Einfach in der setList-Zeile von 15 auf 30 erhöhen und schon gehts mit mehr Presets:
Vorher:
preset:selectnumbers,0,1,15,0,lin wled/display/api PL=$EVTPART1Nachher:
preset:selectnumbers,0,1,30,0,lin wled/display/api PL=$EVTPART1