Anleitung zu eigenen Widgets

[nageniil]

Hallo Community,

ich möchte gerne tiefer in die Materie einsteigen und für FTUI ein eigenes Widget (widget_mywidget.js) schreiben, das - logischerweise - auf die Attribute, Readings und evtl. sonstige Internals eines Devices zugreifen soll.

Mit der "widget_example.js" komme ich nicht wirklich weiter und auch das Studium diverser offizieller Widget-Javascripts bringt keine Erleuchtung. Auch die Suchfunktion des Forums und Tante Google habe ich  - ohne Erfolg - bemüht...

Deshalb meine Frage:

Gibt es irgendwo eine Dokumentation über die Eigenschaften und Methoden der (standardmäßig) als elem. und me. bezeichneten Objekte?

So etwa nach dem Muster der Modulentwicklung in https://wiki.fhem.de/wiki/DevelopmentModuleIntro.

Ich schildere jetzt kein konkretes Problem (wie z.B. dass ich bei elem.getReading('xyz').val nur ein "undefined" bzw. bei elem.getReading('xyz') nur ein "[object Objekt]" erhalte), weil ich es grundlegend und nicht nur punktuell verstehen will.

Vielen Dank für jede Anregung!

[drhirn]

Hilft das? https://wiki.fhem.de/wiki/FTUI_eigene_Widgets

[setstate]

genau, das hatte ich nach dem Posting zusammen geschoben. Ist bestimmt noch nicht detailliert genug, aber ein Anfang ...

[nageniil]

genau, das hatte ich nach dem Posting zusammen geschoben. Ist bestimmt noch nicht detailliert genug, aber ein Anfang ...

Vielen Dank - das hilft für's erste schon mal. Am Wochenende werde ich mich dem Thema wieder intensiver widmen und sehen, ob ich jetzt weiterkomme...

[Thyraz]

Wenn weitere Fragezeichen auftauchen, notiere sie dir.

Kann man evtl. einiges im Wiki ergänzen...

[nageniil]

Dann gleich schon mal das erste Fragezeichen:
Gibt es so etwas wie ein elem.getAttribut('xyz').val ?

Ich möcht nicht nur auf ein Reading eines Devices zugreifen, sondern auch direkt auf ein Attribut, das ich im entsprechenden FHEM-Modul gesetzt habe.

Wenn nicht, könnte man ja wohl:
- das Attribut als Reading im FHEM-Modul 1:1 anlegen (behagt mir nicht so dolle, da überflüssige Redundanz)
- das Attribut aus der fhem.cfg per RegEx herausfischen (behagt mir auch nicht so dolle, da es besser eine generische Lösung geben sollte)

Nun ja: "geht nicht, gibt's nicht", aber vielleicht geibt es ja bereits die Lösung - ich sehe sie nur nicht...

[setstate]

Es wird nicht zwischen Attribute und Reading unterschieden. Ist beides unter getReading zu finden.

[nageniil]

Vielen Dank einstweilen! So langsam komme ich der Sache näher:

Wenn man im FTUI-HTML ein widget einbindet und im <div data-irgendwas="XYZ"> angibt, kann man das im widget.js als elem.initData('irgendwas', Wert) vorbelegen (falls es im HTML-div nicht enthalten ist) oder den im HTML-div angegebenen Wert (hier: XYZ) übernehmen. Prima, das geht.
Dann spricht man das im weiteren Verlauf als elem.data('irgendwas') an und erhält Wert bzw XYZ.
Das empfiehlt sich also für alle Eigenschaften, die durch das FHEM-Device selbst nicht geändert werden und somit "statisch" sind für die Anzeige im FTUI.
Beispiel: <div ... data-color="green"> -> elem.initData('color', 'red'); x=elem.data('color') // x='green'

Nun kann aber der Wert auch ein Verweis sein auf den Namen eines Attributs oder Readings.
Dann spricht man im weiteren Verlauf vom elem.getReading('irgendwas').val, um den Wert des Readings/Attributs Wert zu bekommen.
Beispiel: <div ... data-get="Temp"> -> elem.initData('get', 'STATE'); -> x=elem.getReading('get').val // x=Wert des Readings/Attributs Temp

Damit werde ich es weiter versuchen und berichten.

Wozu allerdings me.area gut ist und der Unterschied zwischen me.elements.filterDeviceReading(...) und me.elements.filter(...) - nun ja, das wird sich auch irgendwann offenbaren... Und möglicherweise gibt es noch viel mehr Attribute und Methoden, wer weiß...

[drhirn]

Ich würde das großartig finden, wenn du deine Erkenntnisse dann im Wiki unterbringen könntest!

(Oder dann einfach hier zusammenfassen und ich stell's in Wiki. Glaube aber, die erste Möglichkeit ist schlauer.)

[setstate]

me.area ist eine Gruppierung von Widgets. Zum Beispiel alle Labels einer Pagebutton-Unterseite. Dadurch kann man nur die Widgets auf der (gerade neu geladenen) Unterseite initialisieren. me.area enthält den jQuery-Selector des gruppierenden Containers (z.B. "#subpage2") und wird zur Eingrenzung der Filterung herangezogen.

filterDeviceReading() filtert alle Widgets raus, die das Event passen.

Zum Beispiel:

device='aussen'
reading='temp'
me.elements.filterDeviceReading('get', device, reading)

filtert die Elemente, wo data-device='aussen' und data-get='temp' angegeben ist bzw. data-get='aussen:temp'

[nageniil]

Ich würde das großartig finden, wenn du deine Erkenntnisse dann im Wiki unterbringen könntest!

Ehrensache, mache ich. Aber erst mal möchte ich noch mehr durchblicken - anhand der Entwicklung eines eigenen Moduls und eines widgets dazu.

Da kommen dann noch ganz andere Problemchen dazu, die aber nix mit FHEM zu tun haben (Konvertierung in perl und/oder javascript von String in eine Number und so Scherze, weil es sonst im switch-case net funzt...)

Und dann bin ich so eitel, erst dann was zu verlautbaren, wenn ich selbst genug darüber nachgedacht habe.
Und dann bin ich mal in Urlaub - dauert mit dem "Reverse Engineering" also leider noch ein Weilchen...

[drhirn]

Nur so aus Interesse: Was für ein Widget schwebt dir im Geiste vor?

[nageniil]

Nicht nur im Geiste, sondern läuft auch schon leidlich:

Zur Verbesserung des WAF eine Bilderschau wie in herkömmlichen "Digitalen Bilderrahmen" mit einer automatisch ablaufenden "SlideShow".
Festlegung der Parameter (Bilderverzeichnis, Übergangseffekt, Anzeigedauer etc.) in einem Device, aber auch per widget_slideshow.js noch änderbar.

Und damit es nicht zu einfach wird, mit eigenem javscript (ohne jQuery) und mehrere widgets auf einer Seite.
Mit Zusatzideen: ... und alternativ im Vollbildmodus. Oder generell mal untersuchen, wie sich automatisch austauschende "Wechsel-Widgets" realisieren lassen. Oder im FHEM-Web eine Upload- und Lösch-Funktion für die Bilder vorsehen...

Ist also wirklich nur als Gimmick und Lernprojekt gedacht.

Wen es interessiert - hier die Vorabversion (fertige Version gibt es aber dann in einem neuen Thread):