Autor Thema: Widget-Dokus; War: svgplot widget update - wie update "hochladen"?  (Gelesen 547 mal)

Offline curt

  • Full Member
  • ***
  • Beiträge: 320
@setstate
Eine Frage zum Vorgehen bei fehlerhaften Widgets, die ohne bekannten Autor sind, aber (wohl) über Deinen update-Mechanismus verteilt werden.

Konkret geht es um svgplot: Das funktioniert mit aktuellen FTUI-Versionen nicht. Mit zwei kleinen Änderungen kann es lauffähig gemacht werden, hier beschrieben: https://forum.fhem.de/index.php?topic=77223.0
Ich habe die Änderungen getestet - ja, dann funktioniert das svgplot-Widget wieder.

Wie geht man da weiter vor?
Kannst Du die beiden kleinen Änderungen bei diesem Widget einpflegen - auf dass das Widget fehlerfrei über update verteilt wird?

Subject nach Threaddrift angepasst.
« Letzte Änderung: 10 November 2018, 23:36:30 von curt »
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline setstate

  • Hero Member
  • *****
  • Beiträge: 3823
  • FHEM TabletUI
    • FHEM Tablet UI
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #1 am: 19 Oktober 2018, 11:18:56 »
ist jetzt im Ftui svgplot widget geändert

Offline curt

  • Full Member
  • ***
  • Beiträge: 320
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #2 am: 20 Oktober 2018, 02:10:44 »
Danke-schön.
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline curt

  • Full Member
  • ***
  • Beiträge: 320
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #3 am: 09 November 2018, 04:37:07 »
@setstate

Ich habe mir erlaubt, einen kurzen Wiki-Artikel zu diesem FTUI-Modul zu schreiben. Die Situation ist doch folgende: Irgendwo im Forum-Raum kreiseln FTUI-Module rum, manche sind in Deinem update-Zyklus, andere nur im Forum veröffentlicht, manche davon (DWD-opendata) nicht mehr funktional: Irgendwann mit schneller Hand gecodet, im Forum veröffentlicht, kaputt, tot.

Allein typisch ist: Der Autor ist verschollen.

Mein Ziel ist weniger, die Modulwelt von FTUI zu retten. Es ist schon Eigennutz, Du siehst es ganz am (rechten) Rande meines neu geschriebenen Artikels: Da ist der Kasten, der erzählt wer der Autor (hier: u/i) ist. Und wo der Hauptthread im Forum ist.

Ich halte das für extrem wichtig - also das bei allen FTUI-Wiki-Artikeln der Kasten rein kommt. Denn dieser Kasten fehlt bei praktisch allen FTUI-Artikeln. Ich will mich da gern aktiv beteiligen.

Vielleicht sollte ich noch die URL zum Artikel verraten: https://wiki.fhem.de/wiki/FTUI_Widget_Svgplot

(Dort ist mir der Codeblock missraten. Aber das ist lässlich: Wiki-Prinzip: Habe Mut!)

@eki geht mit gutem Beispiel voran ... (Oder soll ich das machen, eki?)
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline setstate

  • Hero Member
  • *****
  • Beiträge: 3823
  • FHEM TabletUI
    • FHEM Tablet UI
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #4 am: 09 November 2018, 06:55:27 »
Sehr gut!
Dokumentationen ist wichtig, ich weiß. Leider bin ich nicht der Wortakrobat, wie man unschwer erkennen kann.  :)

Umso besser finde ich es, wenn das jemand spontan übernimmt.

Offline curt

  • Full Member
  • ***
  • Beiträge: 320
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #5 am: 09 November 2018, 07:13:55 »
Sehr gut!
Dokumentationen ist wichtig, ich weiß. Leider bin ich nicht der Wortakrobat, wie man unschwer erkennen kann.  :)

Umso besser finde ich es, wenn das jemand spontan übernimmt.

Naja, Dokus kann ich schon.
Das Problem ist eher, dass jeder [selbst ich] auch noch ein Leben hat, man hat ja auch noch anderes. Das bedeutet:  Der Weg zur Hölle ist mit guten Vorsätzen gepflastert ...

Im ersten Schritt habe ich vor, sämtlichen Wiki-FTUI-Artikeln den Kasten (rechts) "Der war Autor, den erreichst Du so, das ist hier der primäre Thread" zu verpassen.

Da ich nun auch nicht der Heiland bin, mir wächst ja kein Gras aus der Tasche, würde ich Dich immer informieren wollen: Vier Augen sehen ja mehr als zwei. Ich weiß noch nicht, wie ich diesen Teil (Dich informieren) löse.
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Online Ulm32b

  • Full Member
  • ***
  • Beiträge: 295
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #6 am: 10 November 2018, 01:29:48 »
Naja, Dokus kann ich schon.
Das Problem ist eher, dass jeder [selbst ich] auch noch ein Leben hat, man hat ja auch noch anderes. Das bedeutet:  Der Weg zur Hölle ist mit guten Vorsätzen gepflastert ...

Im ersten Schritt habe ich vor, sämtlichen Wiki-FTUI-Artikeln den Kasten (rechts) "Der war Autor, den erreichst Du so, das ist hier der primäre Thread" zu verpassen.

Da ich nun auch nicht der Heiland bin, mir wächst ja kein Gras aus der Tasche, würde ich Dich immer informieren wollen: Vier Augen sehen ja mehr als zwei. Ich weiß noch nicht, wie ich diesen Teil (Dich informieren) löse.

Für die Mitarbeit am Wiki möchte ich hier ausdrücklich werben, denn manches lässt sich noch verbessern. Anhand des Doku-Threads https://forum.fhem.de/index.php?topic=66578.15 kann man nachvollziehen, wieviel Herzblut und Nachtstunden hier schon eingeflossen sind. Es gelang ein erstaunlich hoher Standardisierungsgrad, z.B. indem bereits der erste Satz quasi genormt ist (Da weicht svgplot schon ab). Bei den css-Klassen wird nicht eine flache Tabelle gefüllt, sondern mit cleveren Verweisen gearbeitet. Auch die Gliederung ist weitgehend vereinheitlicht:
  • Attribute
  • css-Klassen
  • Hinweise
  • Beispiele
  • Web-links
Den Mehrwert eines durchgängigen Infokastens sehe ich noch nicht so recht:
  • Zweck/Funktion: Wird durch einen guten ersten Satz erschöpfend beschrieben.
  • Typ: Inoffiziell: Was sagt mir das?
  • Dokumentation: Die beste Dokumentation ist doch genau die Seite, auf der ich mich gerade befinde.
  • Modulname: Redundante Information, steht schon in der Überschrift.
  • Verweis auf commandref: Na ja, kein einziges FTUI-Widget ist in der FHEM-Commandref beschrieben, weil das dort nicht hingehört.
Zusammen mit der Suchfunktion im Forum kommt man bei bestehenden Widget-Beschreibungen doch schon ziemlich weit. Mehr bringen würde m.E.:
  • Eine systematische Untersuchung auf Vollständigkeit der Attribute und css-Klassen.
  • Erstellung von fehlenden Widget-Beschreibungen (dabei am besten den Quelltext bestehender Widgets zugrunde legen, damit die Standards zur Anwendung kommen).
  • Füllen von Lücken, z.B. Navigationsmethoden
Neulich habe ich versucht, die Errungenschaften des vergangenen Quartals im Wiki festzuhalten. Beispiel: Text im Bild. Vielleicht etwas hemdsärmlig wurde eine halbwegs passende Stelle gesucht und dann vorrangig mit copy-Paste gearbeitet. Von Zeit zu Zeit ist da ein ordnender Blick ganz nützlich. Zu tun gibt es genug...

Offline curt

  • Full Member
  • ***
  • Beiträge: 320
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #7 am: 10 November 2018, 21:24:17 »
@Ulm32b
Danke für Deinen umfangreichen Post. Selbstverständlich werde ich mich an von der Mehrheit getragende Standards halten. Zu einigen Punkten meine -subjektive- Sicht bzw. Antwort:

Es gelang ein erstaunlich hoher Standardisierungsgrad, z.B. indem bereits der erste Satz quasi genormt ist (Da weicht svgplot schon ab).

Wo genau kann ich mir die Normung ansehen? Bzw. kannst Du bitte an Hand des ersten Satzes mir zeigen/begründen, wie man es richtig macht?

Es gelang ein Den Mehrwert eines durchgängigen Infokastens sehe ich noch nicht so recht:

Ausgehend von meinem Nutzerverhalten (gibt es ein FTUI-Widget für meine Aufgabe) scheint es mir mehrere Klassen von FTUI-Widgets zu geben: Widgets, die im update-Prozess von @setstate integriert sind (Unterklassen: funktional, defekt); Widgets, die nicht integriert sind, aber funktional sind sowie Widgets, die defekt sind.

In vielen solchen Fällen wäre der Autor von Interesse - dessen Name/Nick fehlt flächendeckend.

Die Angabe des Hauptthreads für dieses Widget im Forum wäre für Fragen hilfreich.

Es gelang ein
  • Dokumentation: Die beste Dokumentation ist doch genau die Seite, auf der ich mich gerade befinde.

Ich habe den einzigen vorhandenen Kasten (und das ist der von FTUI selbst) kopiert und minimal abgewandelt. Das der nicht richtig passt - ist mir klar. Ich bin (siehe oben) aber schon davon überzeugt, dass ein Kasten mit grundlegenden Informationen (vierte vielleicht: wird weiter entwickelt / eingestellt) erforderlich ist.

Es gelang ein
  • Verweis auf commandref: Na ja, kein einziges FTUI-Widget ist in der FHEM-Commandref beschrieben, weil das dort nicht hingehört.

Ich hatte das drin gelassen, weil ich nicht überschauen kann, ob es bei manchen Widgets Referenzbezüge gibt.

Es gelang ein Zusammen mit der Suchfunktion im Forum kommt man bei bestehenden Widget-Beschreibungen doch schon ziemlich weit.

Das sehe ich aus eigenem Erleben ganz und gar nicht so. Ich erlebe das ständig völlig anders: Entwickler verschollen (falls überhaupt erkennbar ist, wer das war). Unklar, ob Widget noch funktioniert und ich zu dumm bin - oder eben nicht mehr funktioniert. Vermutlich hat das oft mit Versionswechseln von FTUI zu tun.

Es gelang ein
  • Eine systematische Untersuchung auf Vollständigkeit der Attribute und css-Klassen.

Eine Vielzahl von Widgets sind nicht einmal schlecht im Wiki dokumentiert - sie sind überhaupt nicht dokumentiert. Ein Blick auf die FTUI-Wikiseite (unten sind Links auf zwei Widget-Klassen) reicht. Selbst wenn sie dokumentiert sind, dann sind mögliche Optionen/Schalter/Attribute nicht dokumentiert; vgl. beispielhaft Calview-Widget.

Anderes Beispiel:
Derzeit scheitere ich im Forum selbst mit aktiven Nachfragen an einem Widget für DWD-opendata, das sind die Daten mit Vorhersage des Deutschen Wetterdienstes. Der ist aus zwei Gründen interessant: Der ist der einzige hier vorhandene mit einem 1km-1km-Raster. Der kommt mit einer Vielzahl an validen Daten. -
Das Widget weather scheint das integriert zu haben, es ist unklar ob in der aktuellen Version. Weiterhin ist die konkrete Nutzung (mir) völlig unklar. Darüber hinaus existieren ein (vermutlich sogar zwei) weitere DWD-opendata-Widgets. Da von mir gefundene ist mir Quelltext im Forum, scheint aber nicht funktional zu sein.

Es gelang ein
  • Erstellung von fehlenden Widget-Beschreibungen (dabei am besten den Quelltext bestehender Widgets zugrunde legen, damit die Standards zur Anwendung kommen).

Mir wäre lieb, wenn wir uns über den Kasten verständigen könnten. Ich halte den aus eigenem Erleben für notwendig. Wir können das gern auch in einem passenderen Thread diskutieren.
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline curt

  • Full Member
  • ***
  • Beiträge: 320
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #8 am: 10 November 2018, 23:51:49 »
Anderes Beispiel:
Derzeit scheitere ich im Forum selbst mit aktiven Nachfragen an einem Widget für DWD-opendata, das sind die

Dazugehörige Diskussion hier: https://forum.fhem.de/index.php/topic,86847.0.html
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline curt

  • Full Member
  • ***
  • Beiträge: 320
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #9 am: 11 November 2018, 05:16:20 »
Auch die Gliederung ist weitgehend vereinheitlicht:
  • Attribute
  • css-Klassen
  • Hinweise
  • Beispiele
  • Web-links

Weiterer Nachtrag, hierzu:
Das ist alles schön und fein - und idealerweise super korrekt. Und ich komme mir ganz klein vor:

Ich fand das Widget svgplot, es funktionierte nicht. Dann fand ich einen Beitrag, der war ein Jahr her: Da schrieb jemand, wie man dieses Widget wieder zum Leben erwecken könne - Antwort erhielt er nie.

Ich habe dessen Änderungen getestet - funktioniert.
Sodann habe ich @setstate (das Modul ist in seinem Updatezyklus) gebeten, mal heftig ins Getriebe zu greifen und ohne Kenntnis seines verschollenen Autoren die Änderungen einzuarbeiten. Hat er getan. (Und gelegentlich können wir alle mal darüber nachdenken, warum ein Jahr vergehen musste.)

Ich habe anschließend diese Wiki-Kurzdoku geschrieben. Und soeben -falls ich Deinen Hinweis recht verstanden habe- den ersten Satz geändert.

Gleichzeitig bitte ich um Verständnis:

Erstens bin ich hier nicht der, der sybillische Andeutungen analysiert: Entweder sagst Du klar, was ich falsch machte. - Oder es gibt für mich das Wiki-Prinzip "sei mutig". Ich habe meine Lebenszeit nicht in der Lotterie gewonnen.

Zweitens werde ich das Widget nicht analysieren. Weder auf CSS-Klassen noch auf sonstwas. - Ich habe es gefunden. Es funktioniert. Im Wiki beschreibe ich, wie man das nutzt.

Du darfst auch gutwillige neue Autoren (fremder Widgets) gern mitnehmen: Ich werde keine 22 Seiten des von Dir vorgeschlagenen Threads daraufhin prüfen, ob da irgendwo eine Guideline steht. Die steht da mit einiger Sicherheit nicht, da steht vermutlich die Entstehungsgeschichte der Guideline. Die ist nicht relevant.

Relevant wäre
* wo im Wiki steht die Guideline für FTUI-Module
* wo im Wiki finde ich die kopierfähige Blaupause?

Ich bleibe weiterhin dabei
* es braucht einen Kasten mit den relevanten Infos zum FTUI-Modul (näheres gern später)

Nicht aufregen, bitte: Ich bin im Team der Guten.
Lieber nochmal lesen.
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Online Ulm32b

  • Full Member
  • ***
  • Beiträge: 295
Gleich vorab: Dies ist mein letzter Beitrag zu diesem Thema. Vielleicht gerade rechtzeitig, bevor sich die Debatte verselbständigt wie z.B. im Calview-"Bugreport" (https://forum.fhem.de/index.php/topic,91903.msg845561.html#msg845561).
Zitat
Wo genau kann ich mir die Normung ansehen? Bzw. kannst Du bitte an Hand des ersten Satzes mir zeigen/begründen, wie man es richtig macht?
Eine Doku der Doku gibt es nicht. Mein Hinweis auf den Doku-Thread war auch nicht als Aufforderung gedacht, ihn zu studieren. Wenn man möchte, kann man dort nachvollziehen, wie fast aus dem Nichts etwas sehr Vorzeigbares entstand. Bildet man die Schnittmenge von
  • "Das Widget Checkbox ist ein Widget für FHEM Tablet UI, welches als Umschalter zwischen zwei Zuständen eingesetzt wird."
  • "Das Circlemenu Widget ist ein Widget für FHEM Tablet UI, das mehrere Widgets nach einem Klick auf ein einziges anzeigen kann."
  • "Das Widget Clock ist ein Widget für FHEM Tablet UI, welches die aktuelle Zeit des jeweiligen Endgerätes in digitaler Form wiedergibt."
  •   ... (das sind einfach mal die ersten drei in der Reihe)
sollten gewisse Ähnlichkeiten erkennbar sein. (Bei dieser Gelegenheit fällt mir auf, dass die genaue Position des Wortes Widget nicht einheitlich ist.  8))
Zitat
In vielen solchen Fällen wäre der Autor von Interesse - dessen Name/Nick fehlt flächendeckend.
Die Frage habe ich mir eigentlich nie gestellt. Wenn es ein Problem gab, habe ich stets versucht, selbiges möglichst verständlich zu schildern. Dann haben "alle" mitgelesen. Und wenn einer helfen konnte, hat er geholfen. Was will man mehr? Oft ist es gar nicht der Autor, sondern ein anderer User, der sein Anwenderwissen teilt.
Zitat
Die Angabe des Hauptthreads für dieses Widget im Forum wäre für Fragen hilfreich.
Es gibt im Allgemeinen keinen Hauptthread. Und wenn, dann ist er unübersichtlich und damit unpraktisch, siehe:
Zitat
(Zitat Thorsten Pferdekämper vom 15.8.2018 [FUIP]: "
Btw.: Ich hatte schon einmal darum gebeten, für neue Probleme neue Threads aufzumachen. Anscheinend interessiert das keinen, daher mache ich diesen hier jetzt zu,
Gruß,
   Thorsten"
Grundsätzlich ist gegen die Angabe des Autors nichts einzuwenden (wenn er einverstanden ist). Immerhin wäre diese Angabe auf Dauer valide. In den überschaubaren Fällen, wo jemand ein Widget in Pflege genommen hat, könnte man das zusätzlich vermerken. Nützlich erscheint mir auch: "Bekannte Fehler" (stichwortartig kurz und prägnant mit Link auf den zugehörigen Thread; in erster Linie sollten Bugs im Forum abschließend behandelt werden und es deshalb gar nicht bis zum Wiki schaffen). Das wären schon einmal mögliche Inhalte eines Infokastens. Ein Hinweis "Zuletzt getestet <Datum>" wäre dann und nur dann sinnvoll, wenn sich jemand findet, der das regelmäßig für alle Widgets (in allen denkbaren Konstellationen  :o) nachhält. Wenn nicht, wird daraus schnell Datenmüll.

Ich finde, dass Du in Deinen Beiträgen mit leuchtenden Farben schwarz malst:
Zitat
"nicht funktional, kaputt, defekt, eingestellt, verschollen, tot."
- Na ja, da sieht man sich ja auf einem Trümmerfeld.
Zitat
"Eine Vielzahl von Widgets sind nicht einmal schlecht im Wiki dokumentiert - sie sind überhaupt nicht dokumentiert. Ein Blick auf die FTUI-Wikiseite (unten sind Links auf zwei Widget-Klassen) reicht. Selbst wenn sie dokumentiert sind, dann sind mögliche Optionen/Schalter/Attribute nicht dokumentiert; vgl. beispielhaft Calview-Widget."
Wenn man die Nesges-Widgets mitzählt, gibt es für ca. 90% der gelisteten integrierten Widgets eine (höchstwahrscheinlich unvollkommene) Doku. Aber man kann natürlich wieder schwarz malen und größere Lücken bei den 3rd-Party-Widgets bemängeln. Wenn man die einfach einmal gedanklich ausblendet ("Die gibt es gar nicht."), dann vermisst man sie nicht und fühlt sich doch gleich wohler.
Erfreulicherweise hast Du bei Calview Dein erarbeitetes Wissen geteilt. Das haben in anderen Widgets schon viele andere gemacht, gewiss auch zu Deinem Nutzen.

Die wahrscheinlich von Dir hier zugeordnete Kategorie "Modul (inoffiziell)" sollte in FTUI nicht verwendet werden; das sind FHEM-Module.
Zitat
Derzeit scheitere ich im Forum selbst mit aktiven Nachfragen an einem Widget für DWD-opendata.
Die meisten Anwender (so auch ich) scheinen mit den verfügbaren Wetterdaten (z.B. Proplanta) zufrieden zu sein und engagieren sich entsprechend weniger für DWD, zumal dort wohl öfter ein Pflegeaufwand droht. Das ist Deine Chance. Stattdessen wird gejammert, dass der Support nicht funktioniert. Wenn sich jemand solche Kritik zu Herzen nehmen sollte, wird er doch abgeschreckt, Neues auszuprobieren und Gleichgesinnte zu suchen.
Zitat
Ich fand das Widget svgplot, es funktionierte nicht. Dann fand ich einen Beitrag, der war ein Jahr her: Da schrieb jemand, wie man dieses Widget wieder zum Leben erwecken könne - Antwort erhielt er nie.
Ich habe dessen Änderungen getestet - funktioniert.
Sodann habe ich @setstate (das Modul ist in seinem Updatezyklus) gebeten, mal heftig ins Getriebe zu greifen und ohne Kenntnis seines verschollenen Autoren die Änderungen einzuarbeiten. Hat er getan. (Und gelegentlich können wir alle mal darüber nachdenken, warum ein Jahr vergehen musste.)
Könnte man auch als Seitenhieb auf setstate deuten, na prima.
Zitat
Zweitens werde ich das Widget nicht analysieren. Weder auf CSS-Klassen noch auf sonstwas. - Ich habe es gefunden. Es funktioniert. Im Wiki beschreibe ich, wie man das nutzt.
Schade; die Kompetenz dafür dürftest Du haben.

Dein Ansatz scheint zu sein: Für jedes Widget wird ein Verantwortlicher benannt; gerne schreibst Du selbst das Protokoll. Und dann erwartest Du, dass Anfragen aller Art zeitnah beantwortet werden. So läuft das nicht. Auch besonders aktive User nehmen sich teils mehrmonatige Auszeiten; das ist vollkommen in Ordnung. Dann muss man sich mit Anfragen/Wünschen eben in Geduld üben. Oder sich selbst helfen. Und wenn ein Know-how-Träger ganz aussteigt, ist das nichts anderes als der normale Gang der Dinge (auch wenn man teilweise nicht daran denken mag).

Es gibt gewiss Dinge, die man bei FTUI (gerade weil es inzwischen beachtliche Reife erreicht hat) anders machen könnte. Zu Grundsatzfragen äußere mich aber nur, wenn ich selbst einen Lösungsbeitrag leisten kann.
Zitat
Nicht aufregen, bitte: Ich bin im Team der Guten.
Lieber nochmal lesen.
Habe ich mehrmals gemacht und nehme in Kauf, hier nicht das letzte Wort zu haben.
« Letzte Änderung: Gestern um 16:35:59 von Ulm32b »

Offline curt

  • Full Member
  • ***
  • Beiträge: 320
Der Thread nimmt eine unschöne Wendung, das missbehagt mir.

Ich nehme zur Kenntnis, dass ich bereits den Einleitungssatz falsch machte, da gibt es Richtlinien. Gleichzeitig gibt es sie nicht (zum nachlesen). Gut - da habe ich keine Chance. Mir leuchtet ein, dass es besser ist unter sich zu bleiben.

Ich nehme zur Kenntnis, dass der Autor bedeutungslos sei. Ich nehme zur Kenntnis, dass ein Hinweis auf einen vorhandenen Anker-Thread nicht erwünscht ist. Ich nehme zur Kenntnis, dass der Autor bedeutungslos sei. Ein Hinweis, wann das Widget funktionierte ist auch nicht gewünscht. Hingegen erfahre ich meine Motivation, meinen Ansatz. Interessant.

Damit hat sich jede Diskussion über die Nennung des Widget-Autoren erledigt.

Klarstellung zu svgplot: Das Widget ist offensichtlich verwaist (und einer der Gründe, warum ich vorhatte, bei der Doku mitzuhelfen). Vor gut einem Jahr hatte jemand samt Lösung im Forum darauf verwiesen, gleichwohl an unerwarteter Stelle. - Ich habe vor einigen Tagen @setstate auf den Bugfix verwiesen. Er hat das sehr schnell in (ein fremdes) Widget eingebaut. Wo da ein Seitenhieb auf setstate ist, wird Dein Geheimnis bleiben.

Tatsächlich ist richtig, dass ich mir (und anderen) die Arbeit vereinfachen will. Nur so entwickelte sich die Menschheit. Und selbstverständlich ist es schöner, schnell Antworten zu bekommen - als gar keine.

Danke für die freundliche Begrüßung.
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

 

decade-submarginal