mqtt2.template: bugs, Fragen, Anregungen

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

Vorheriges Thema - Nächstes Thema

frankreed

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.

Beta-User

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 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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

schwatter

@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.



TomLee

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

schwatter

#199
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.

Beta-User

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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

KölnSolar

Hi Beta,
kannst Du bitte hier 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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

KölnSolar

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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Beta-User

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. 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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

micky0867

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

Beta-User

#206
@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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

87insane

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 :)

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

87insane

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!