ebusd.mqtt2.template: Fragen, Anregungen

[rudolfkoenig]

Du willst ein define im template ausführen, und zwar mit dem TPY MQTT2_DEVICE. Das klappt aber nicht, weil der hintere Teil "DEVICE" ersetzt wird durch den Namen, aber ein solches Modul gibt es natürlich nicht...

Ich habe AttrTemplate erweitert: mit \ kann man alle Parameternamen schuetzen. Also MQTT2_\DEVICE wird zu MQTT2_DEVICE, und nicht wie bisher zu MQTT2_\Lampe

[Beta-User]

Ich habe AttrTemplate erweitert: mit \ kann man alle Parameternamen schuetzen. Also MQTT2_\DEVICE wird zu MQTT2_DEVICE, und nicht wie bisher zu MQTT2_\Lampe

Das beseitigt zwar die prinzipiellen Einwände nicht, ist aber evtl. doch praktisch . Dann werde ich das wohl im General-bridge-template auch verwenden...

Kannst du mir und Reinhart dann noch verraten, was wir ans Ende des templates schreiben sollten, wenn wir das neu erstellte Device gleich in FHEMWEB angezeigt bekommen wollen? (Sonst bleibt man beim aufrufenden Device, was - aus Anwendersicht - m.E. etwas intransparent ist).

[rudolfkoenig]

Wäre nett, wenn ihr einen kurzen Blick drauf werfen könntet...

Was mir aufgefallen ist (heisst aber nicht unbedingt, dass es geaendert werden soll):
- Bei MQTT2_SERVER ist autocreate Voreinstellung (im Wiki wird es noch explizit gesetzt)
- commandref laedt mit https://fhem.de/commandref_modular.html#set schneller

was wir ans Ende des templates schreiben sollten, wenn wir das neu erstellte Device gleich in FHEMWEB angezeigt bekommen wollen?

Am besten diesen Wunsch verkneifen, und associatedWith setzen.
Ich koennte was kompliziertes basteln in der Art "trigger $hash->{CL} JS:...", aber das waere FHEMWEB spezifisch, und ich will FHEMWEB immer noch nicht als das einzig moegliche Frontend zementieren.

[Beta-User]

Was mir aufgefallen ist (heisst aber nicht unbedingt, dass es geaendert werden soll):
- Bei MQTT2_SERVER ist autocreate Voreinstellung (im Wiki wird es noch explizit gesetzt)

Das schaue ich mir nochmal an; beim ebus ist es so, dass man es zur Bereinigung der readingList m.E. tatsächlich erst aus- und dann wieder (anders) einschalten sollte. Oder ist beim MQTT2_SERVER complex die Voreinstellung? Dann würde es in der Tat genügen, die readingList der anderen Devices zu säubern...

- commandref laedt mit https://fhem.de/commandref_modular.html#set schneller

Ähm, eigentlich verwende ich (hoffentlich) durchgängig die entsprechende Vorlage (https://wiki.fhem.de/w/index.php?title=Vorlage:Link2CmdRef&action=edit). Das wäre ggf. eine Sache, die man insgesamt ändern sollte. Soll ich dazu einen Post im Wiki machen, oder hast du eine Idee, wie das ginge? Ich bin in diesen Themen so gar nicht drin...

Am besten diesen Wunsch verkneifen, und associatedWith setzen.
Ich koennte was kompliziertes basteln in der Art "trigger $hash->{CL} JS:...", aber das waere FHEMWEB spezifisch, und ich will FHEMWEB immer noch nicht als das einzig moegliche Frontend zementieren.

Bitte nix kompliziertes, das lohnt nicht, bin wie geschrieben auch nicht so begeistert von der Vorgehensweise an sich (wobei associatedWith evtl. eine Aspekt ist, warum man das doch mit defmod usw. lösen sollte, muß mal sacken lassen)...
Einwände für den Fall der Fälle gegen "show" NEWDEVICE? (Ich hoffe, der Aufruf geht halt einfach ins Leere, wenn man das nicht aus FHEMWEB aufruft)

[Reinhart]

Kannst du das bitte so erklaeren, dass ich das nachstellen kann?

wenn ich im Template angebe:

Code Auswählen Erweitern

attr MQTT2_ebusd_status room MQTT2_DEVICE

dann entseht daraus ein Room mit dem Namen:

Code Auswählen Erweitern

MQTT2_MQTT2_DEVICE
weil intern die Variable "DEVICE" den Wert "MQTT2_DEVICE" beinhaltet.

LG

[rudolfkoenig]

Solte ab morgen mit

Code Auswählen Erweitern

attr MQTT2_ebusd_status room MQTT2_\DEVICE
funktionieren

[Beta-User]

Generelle Anmerkung:
Wäre es nicht günstiger, "abgeleitete", neu erstellte Devices in denselben Raum zu packen wie das "Stammdevice"? Fände ich logischer. Code-Ansatz dazu aus dem Generic-Bridge-template (wäre aus den DEVICE-Attribut direkt zu entnehmen):

Code Auswählen Erweitern

par:IODEVROOM;Room of the IOdevice; {AttrVal(AttrVal("DEVICE","IODev",""),"room","" ) ? AttrVal(AttrVal("DEVICE","IODev",""),"room","" ) : undef }

@Rudi: gibt es eigentlich dazu eine Art Regel oder Abfolge, die man einhalten sollte, denn damit könnte sich ja unter Umständen dasselbe Ergebnis ergeben, wenn dann das Stammdevice in MQTT2_DEVICE war. Aber ich vermute mal, er wird erst template-weit der vorhandene Parameter DEVICE ersetzt, dann der nächste Parameter (in order of appearance) ausgewertet, die Ersetzung durchgeführt usw.?
Kann das grade nicht gut testen...

[rudolfkoenig]

Ich wuerde room fuer neu erstellte Geraete auf TYPE (MQTT2_DEVICE) setzen, so macht das auch autocreate.
Und bei Vorhandenen room nicht anfassen.

[Beta-User]

Generell bin ich da bei dir (und habe das neulich auch so entsprechend in MYSENSORS_DEVICE geändert).

ABER: dieser Auszug war aus dem General-Bridge-Template, und da war die Rückmeldung, dass es eine gute Idee sei, dieses "spezielle Device" in denselben room zu packen wie das IO. Was noch fehlte, war dann auch diesen room anzuzeigen; da du zu "show" bisher nichts kritisches gesagt hast, werde ich wohl das nutzen.

HIER geht es darum, abgeleitete Devices für einen speziellen Zweck (Anzeige für diverse Dinge) zu generieren, wenn ich das richtig verstanden habe. Hätte ich jetzt eine Heizung mit ebusd, kämen die betreffenden Geräte typischerweise alle in einen Raum "Heizung". Würde ich jetzt dazu ein neues Device generieren wollen, fände ich es umständlich, die jeweils aus dem Raum "MQTT2_DEVICE" oder "readingsGroup" wieder in den Heizungsraum holen zu müssen...
Das ist aber ein spezielles Thema, das so eigentlich m.E. nur in diesen beiden Konstellationen (bisher) aufgetreten ist.

[rudolfkoenig]

show habe ich schon verdraengt, ist nicht von mir.
Sollte funktionieren, wenn man es ueber FHEMWEB aufruft.
Sonst kriegt man eine unverstaendliche Fehlermeldung.

[Beta-User]

show funktioniert leider nicht...

Habe vorhin trotzdem das GenericBridge-template auf einen defmod umgestellt mit der neuen Option, das DEVICE zu escapen. Wenn man jetzt noch irgendwie "in die Nähe des Zieldevices" käme, wäre das super (in den Room, optimal: direkt zum defmod-Device...).

Dazu habe ich im Moment kleine weitere Idee, eine Steighilfe auf dieses Pferd wäre ggf. nett... (geht aber auch so, Erläuterungen, Warnhinweise usw. sind da, nur noch nicht im Wiki; daher ist es im svn).

[rudolfkoenig]

Dazu habe ich im Moment kleine weitere Idee, eine Steighilfe auf dieses Pferd wäre ggf. nett...

show funktioniert nicht, weil bei set und attr die Webseite nicht neu geladen wird: der Befehl wird "nur" mit XHR an FHEM uebermittelt, und die neuen Attribute werden angezeigt, weil ueber deren Aenderung fhemweb.js (d.h. die "laufende" Seite) benachrichtigt wird.

Folgendes funktioniert beim Setzen des Attributes ueber FHEMWEB (gerade getestet):

{ fhem "trigger $FW_wname JS:location.href='$FW_ME?room=mqtt'" if($cl && $cl->{TYPE} eq "FHEMWEB") }

Allerdings benoetigt das "if" hinter dem Befehl eine gerade eingecheckte AttrTemplate Aenderung.
Ohne if gibt es Nebeneffekte, wenn man den Befehl nicht ueber FHEMWEB absetzt.

Wie ich sagte: ich wuerde room nicht anfassen, ich weiss schon warum

[Beta-User]

Wie ich sagte: ich wuerde room nicht anfassen, ich weiss schon warum

Hmm, irgendwie kommt man halt um die Frage des Raums nicht rum, wenn man neue Geräte erstellt (was eh' die Ausnahme sein sollte!). Und wenn der User eine Funktion wählt, die ausdrücklich dazu da ist, sollte er wissen, was er tut (ok, sehe ich ein, dass da "Theorie" ne "Praxis", aber vom Prinzip her...).

Aber du hast zum einen mehr Erfahrung und zum anderen gibt es auch das Prinzip, dass irgendwie automatisch erstellte MQTT2-Devices in einem bestimmten Raum landen. Daher wird das jetzt bei der GeneralBridge so werden . Reinhart kann das ja mit den ebus-Dingen anders machen, das fände ich in diesem Fall stringenter, aber zum Glück muß ich das nicht entscheiden .

Danke auf jeden Fall für den Schubser und vor allem den Code zum Anzeigen des "richtigen Raums" (ich werde das dann vermutlich bei der Bridge so machen, dass man gleich auf der Detailseite landet).

Vielleicht noch eine Sache: Manchmal wäre es ganz praktisch, dem User am Ende noch einen Hinweis anzuzeigen, hier also, dass das Device erstellt wurde und man es jetzt in den "Raum der Wahl" verschieben kann. Ich denke dabei v.a. an spezielle Devices, bei denen man eigentlich nicht umhin kommt, nach der template-Anwendung noch was einzustellen - z.B. Laufzeiten bei einem Rollladenaktor, siehe die beiden templates für tasmota, das ich gestern eingecheckt habe.
Ist aber ein Wunsch mit geringer Prio!

[Beta-User]

Zum escapen des "DEVICE" noch eine Anmerkung:

Innerhalb der par-Anweisungen bzw. des Perl-Codes da scheint das nicht zu klappen.

Code Auswählen Erweitern

par:NEWDEVROOM;Room of the calling device; {AttrVal("DEVCID","room","MQTT2_\DEVICE" )}

Führt zum Rückgriff auf einen Raumnamen, der auch aus dem aufrufenden DEVICE-Namen besteht.

@Reinhart:
Wenn du zum neu erstellten Device (hier:DEVCID) kommen willst, geht das als eine Zeile im template so (heute noch: AttrTemplate.pm aus dem svn):

Code Auswählen Erweitern

{ fhem "trigger $FW_wname JS:location.href='$FW_ME?detail=DEVCID'" if($cl && $cl->{TYPE} eq "FHEMWEB") }

Rudi: Danke, das ist eine deutliche Verbesserung!
Selbst wenn die Bridge jetzt halt immer - egal, ob es sich schon gibt und ein anderer Raum attributiert war - im Raum MQTT2_DEVICE landet...

[rudolfkoenig]

Innerhalb der par-Anweisungen bzw. des Perl-Codes da scheint das nicht zu klappen.

Habs gefixt.

Manchmal wäre es ganz praktisch, dem User am Ende noch einen Hinweis anzuzeigen, hier also, dass das Device erstellt wurde und man es jetzt in den "Raum der Wahl" verschieben kann.

Habe was eingebaut, nennt sich farewell. Es werden keine Ausdruecke ausgewertet, da ich noch nicht wueeste, wozu.
Falls vorhanden, wird per asyncOutput eine Sekunde nach dem letzten Befehl ein Text angezeigt.
Bin nicht ganz sicher, ob es ohne Nebeneffekte ist, es faellt mir aber nach etwas Experimentieren nichts Besseres dazu ein.

Code Auswählen Erweitern

farewell:Thank you for your patience<br>Bye!