FHEM 6.1

[betateilchen]

Etwas anderes Thema:
Vielleicht könnte man in der "modular"-Variante einen neuen Abschnitt schaffen für Kurzbeschreibungen aus "contrib"?

Dagegen!

Die commandref ist aufgrund der jetzt schon enthaltenen offiziellen Module bereits ein Moloch. Daran ändert auch der modulare Aufbau nichts.

Hast Du Dir mal angeschaut, welcher Müll teilweise in contrib rumdümpelt? Wenn wir nun anfangen, Teile davon in die commandref aufzunehmen, provozieren wir als erstes die Frage "warum steht Modul A in der commandref, aber Modul B nicht?"

• contrib ist für mich eher eine Spielwiese, die im regulären Update aus guten Gründen nicht berücksichtigt wird.
• Im Gegenzug wird die commandref immer als "die einzig wahre Quelle der Moduldokumentationen" bezeichnet.

Beide Punkte haben ihre Daseinsberechtigung. Aber wir sollten auf keinen Fall anfangen, diese zwei Welten in irgendeiner Form zu vermischen.

[Dr. Boris Neubert]

Kriterien könnte sein: Modul seit x Jahren nicht mehr geupdated UND keine aktiven Posts vom Maintainer im Forum (ggf. müsste man die Leute mal kurz anschreiben, ob sie noch gewillt sind weiter zu maintainen). Bei "wichtigen" Modulen die so durchfallen würden, sollten wir dann einen Aufruf starten, ob sich jemand findet der weiter maintained.

Sehe es wie Beta-User: es gibt viele Module, die gut funktionieren, bei nicht (mehr) vielen Anwendern im Einsatz sind, und kein Thema im Forum sind. Da gehört vermutlich das meiste davon dazu, was ich in den frühen Jahren ab 2006  zu FHEM beigetragen habe.

Die Diskussion, ein Modul als veraltet zu entfernen, taucht ja nur auf, wenn es dazu Support- oder Änderungsbedarf gibt, der vom Maintainer nicht bedient wird.

Außerdem nix, was wir kurz vor Release angehen sollten.

[Beta-User]

Hast Du Dir mal angeschaut, welcher Müll teilweise in contrib rumdümpelt?

Teilweise.

Genau deswegen auch der Gedanke...:
Mit dem meisten Zeug aus der Spielwiese fängt niemand Uneingeweihtes irgendwas an, es gibt in der Regel keine Doku, keinen Hinweis auf Threads, wo man irgendwas näheres erfahren könnte, einfach halt "nichts".

Es gibt aber auch Ausnahmen und/oder Dinge, die in der Vorbereitung sind für eine Übernahme als reguläres Modul, und/oder Fragmente, Demo-Code, ..., die niemand je finden wird, wenn man nicht für etwas Ordnung sorgt...

Wenn wir nun anfangen, Teile davon in die commandref aufzunehmen, provozieren wir als erstes die Frage "warum steht Modul A in der commandref, aber Modul B nicht?"

   
• contrib ist für mich eher eine Spielwiese, die im regulären Update aus guten Gründen nicht berücksichtigt wird.
• Im Gegenzug wird die commandref immer als "die einzig wahre Quelle der Moduldokumentationen" bezeichnet.

Beide Punkte haben ihre Daseinsberechtigung. Aber wir sollten auf keinen Fall anfangen, diese zwei Welten in irgendeiner Form zu vermischen.

Mein Vorschlag war ausdrücklich NICHT, beides komplett zu vermischen, sondern das - z.B. in einen eigenen Abschnitt schlagwortartig - aufzunehmen, _wenn_ der betreffende Maintainer das "provoziert". Damit bliebe das zum überwiegenden Teil weiter die "bewährte Spielwiese", und für die Fälle, in denen der Maintainer für Transparenz sorgt, wäre es eben eine etwas transparentere Spielwiese....

Man kann das Ziel selbstredend auch irgendwie anders erreichen, und das muss auch nicht jetzt und gleich sein.

[Adimarantis]

Meine 2ct zu GPIO4:
- "Jemand" sollte es kennzeichnen als "outdated". Würde vorschlagen, das du (@Adimarantis) das asap machst, jedenfalls, sobald der Ersatz direkt verfügbar ist (commandref-Einleitung und Kurzbeschreibungen);
- Optimal wäre es, wenn du auch gleich "Umstellungscode" mit anbieten könntest (hatte ich bei Heating_Control so gemacht, weil da ein paar Kleinigkeiten bei WeekdayTimer anders sind (Attributnamen)), damit "Ist-User" für einige Zeit die Möglichkeit haben, einfach umzusteigen. Entsprechende Log-Einträge können helfen (und sind jedenfalls hinterher hilfreich, damit man berechtigterweise sagen kann, dass eine längere Vorwarnzeit gegeben war...).

GPIO4 ist unter contrib, d.h. commandref bringt nichts und das Modul ändern bringt auch nichts da nicht im Update. Ich würde es daher einfach nach deprecated verschieben und das Wiki https://wiki.fhem.de/wiki/Raspberry_Pi_und_1-Wire anpassen, welches prominent drauf referenziert.
Umstellung ist auch kein Thema da zu den mir bekannten Versionen voll kompatibel (am einfachsten fhem.cfg editieren - hat bei mir einwandfrei geklappt), was ich natürlich im Wiki dokumentieren werde.
Warum ich trotzdem den Namen ändern möchte, hab ich ja im Thread dargelegt.

Zu weiteren Modulen:

Ich hab mir zumindest mal MAINTAINER.txt gegen FHEM directory abgeglichen, folgende .pm files haben keinen offizellen Maintainer:
FHEM/00_KNXTUL
X FHEM/00_Schellenberg
FHEM/00_SmartMeterP1
X FHEM/10_GFPROBT
X FHEM/10_SchellenbergHandle
X FHEM/23_ALL4027
X FHEM/26_KM273
FHEM/48_BlinkCamera
FHEM/59_GSI
FHEM/59_Netzfrequenz
FHEM/70_HYDRAWISE
FHEM/73_WaterCalculator
X FHEM/89_AndroidDBHost
X FHEM/89_AndroidDB
FHEM/89_ESPEInk
FHEM/93_RFHEM
X FHEM/97_PiXtendV2
FHEM/98_HMtemplate

Die mit "X" davor sind laut Statistik nicht ein einziges mal verwendet, manche andere zumindest sehr selten.
Auch wenn nicht jeder sendStatistics aktiviert hat, würde ich daher plädieren zumindest alle "X" nach contrib zu verschieben.

FHEM/70_DENON_AVR_ZONE hat die falsche Nummer im MAINTAINER (sollte 71_ sein)

[Christoph Morrison]

GSI gehört herrmannj
Netzfrequenz gehört ebenfalls herrmannj
Blink gehört Viegener

[Beta-User]

GPIO4 ist unter contrib, d.h. commandref bringt nichts und das Modul ändern bringt auch nichts da nicht im Update. Ich würde es daher einfach nach deprecated verschieben und das Wiki https://wiki.fhem.de/wiki/Raspberry_Pi_und_1-Wire anpassen, welches prominent drauf referenziert.

OK, habe mich nie damit näher beschäftigt, (ich habe schlechte Erfahrungen mit PI-GPIO gemacht und weiß, wie man einen Arduino programmiert)...

Umstellung ist auch kein Thema da zu den mir bekannten Versionen voll kompatibel (am einfachsten fhem.cfg editieren - hat bei mir einwandfrei geklappt), was ich natürlich im Wiki dokumentieren werde.

Bitte: Kein cfg-geeditiere im Wiki darstellen! Das geht grundsätzlich bei denen schief, die sich nicht selbst helfen können...

Besser: RAW-Definition anzeigen lassen und kopieren, Ausgangsdevice löschen, neues Device mit der RAW anlegen, dabei nur den TYPE ändern.

Code Auswählen Erweitern

Ich hab mir zumindest mal MAINTAINER.txt gegen FHEM directory abgeglichen, folgende .pm files haben keinen offizellen Maintainer:
Zum Teil sollte/könnte man das nachtragen, teilweise sind die Module erst jüngst dazugekommen und es wäre kein gutes Signal an die betreffenden Maintainer, da irgendwas zu verschieben, schon gleich nicht, ohne dass es eine Doku gibt, über das man die betreffenden (funktionierenden?) Kandidaten unproblematisch wiederfinden kann (ich habe das nur ab Beispiel Schellenberg kurz nachvollzogen, und damit ggf. auch die rühmliche Ausnahme erwischt)...

Prinzipiell finde ich es nach wie vor sinnvoll, "irgendwie" aufzuräumen, aber das trifft es eigentlich ganz gut:

Außerdem nix, was wir kurz vor Release angehen sollten.

Vielleicht sollten wir mir FHEM 6.2 dann nicht wieder so lange warten und die hier zu findenen Gedanken bis dahin aufgreifen und Lösungen finden, die eine etwas breitere Basis haben?

[rudolfkoenig]

Auch wenn nicht jeder sendStatistics aktiviert hat, würde ich daher plädieren zumindest alle "X" nach contrib zu verschieben.

Ich schlage vor, vorher den Autor zu kontaktieren (siehe svn log), und ihn bitten, sich in MAINTAINER.txt einzutragen..

[Adimarantis]

Besser: RAW-Definition anzeigen lassen und kopieren, Ausgangsdevice löschen, neues Device mit der RAW anlegen, dabei nur den TYPE ändern.

Definitiv. Gibt es den RAW Editor auch irgendwo Device-unabhängig? Es "fühlt" sich komisch an, wenn man nach dem Löschen in den RAW Editor einer anderen Device gehen muss, um die Funktionalität zu bekommen, auch wenn das wunderbar klappt.

Vielleicht sollten wir mir FHEM 6.2 dann nicht wieder so lange warten und die hier zu findenen Gedanken bis dahin aufgreifen und Lösungen finden, die eine etwas breitere Basis haben?

Gerne. War jetzt auch nur ein schneller Abgleich für den Fall das was offensichtliches dabei ist. Der Punkt mit den neuen Devices (wobei ja klar dokumentiert ist, dass der Eintrag in MAINTAINER.txt Pflicht ist) leuchtet schon ein.

Ich schlage vor, vorher den Autor zu kontaktieren (siehe svn log), und ihn bitten, sich in MAINTAINER.txt einzutragen..

Kann ich machen bzw. offensichtlich aktive Autoren die schon Module eingetragen haben, gleich eintragen.

[Beta-User]

Definitiv. Gibt es den RAW Editor auch irgendwo Device-unabhängig? Es "fühlt" sich komisch an, wenn man nach dem Löschen in den RAW Editor einer anderen Device gehen muss, um die Funktionalität zu bekommen, auch wenn das wunderbar klappt.

Es gibt (aber "nur" in f18) das "grüne Plus". Damit geht es ganz genauso...
(und es ist auch nicht verkehrt, den Usern mal einen Weg zu erklären, der sich auf den ersten Blick "komisch anfühlt" - aber eben nur beim ersten Mal, bis man weiß, was man da tut... Hauptsache: kein cfg-edit!)

[Christoph Morrison]

Ich schlage vor, vorher den Autor zu kontaktieren (siehe svn log), und ihn bitten, sich in MAINTAINER.txt einzutragen..

viegener und hermannj habe ich schon angeschrieben.

[herrmannj]

Wird erledigt. Danke!

[Adimarantis]

viegener und hermannj habe ich schon angeschrieben.

Hab den Rest angeschrieben.

[Beta-User]

Nachdem die Liste der Module immer länger wird, die mit rereadcfg nicht zurecht kommt (jetzt insbesondere auch noch CUL_HM): Wäre es nicht ggf. an der Zeit, die cfg-Editierer zu enttäuschen und die Option ab 6.1 nicht mehr zuzulassen? (also weder das Editieren noch den Befehl)

Mit dem "grünen Plus" (f18 und andere) und "Raw definition" (alle FHEMWEB-styles) stehen eigentlich genug Alternativen bereit, die ausreichend viele Leute kennen, um bei Problemen weiterhelfen zu können.

Alternative wäre, shutdown restart bei "edit cfg" zum default beim Speichern zu machen?

Ansonsten hoffe ich, dass martinp876 denmächst Zeit findet, sich die Patchvorschläge zu CUL_HM anzusehen, ich _glaube_, das meiste wäre jetzt auf einem akzeptablen Level patchbar.

Falls zap nicht selbst noch dazu kommt, einen Hinweis zu HMCCU 5.0 in UPGRADE reinzubasteln, wäre das m.E. auch noch eine gute Idee (angepingt hatte ich ihn diesbezüglich schon).

[rudolfkoenig]

Wie genau kommen diese Module mit rereadcfg nicht zurecht?

Edit will ich nicht ausbauen, habe aber kein Problem damit, beim rereadcfg ein shutdown restart auszufuehren.

[Beta-User]

Dass CUL_HM mit rereadcfg ein massives Problem hat, ist mir rund um diesem Beitrag aufgegangen: https://forum.fhem.de/index.php/topic,123608.msg1182501.html#msg1182501

Habe nicht versucht rauszufinden, welchen Ausgangsstand bzgl. der Behandlung von REREADCFG in der NotifyFn() von CUL_HM der TE hatte. Habe dann in der Folge versucht, das zu reparieren, bin aber nicht draufgekommen, woran es letztlich scheitert, das Ergebnis war immer dasselbe: Die VCCU hatte jedesmal nach einem rereadcfg praktisch alle ihre funktionalen Attribute verloren, und ich gehe davon aus, dass CUL_HM damit insgesamt nicht mehr funktional war. Speichert dann ein unbedarfter User das ganze auch noch, dürfte die Verärgerung (berechtigterweise) ziemlich groß sein.

Ob bzw. welche weiteren Attribute bei welchem "model" ggf. jeweils noch betroffen sind, hat mich schon alleine wegen der zentralen Bedeutung der CCU-FHEM nicht mehr interessiert, ich vermute aber schlimmeres...

Im Moment bleibt mir nur, auf das Problem hinzuweisen, die Besonderheiten von rereadcfg im Verhältnis zu INITIALIZED waren ja auch an anderer Stelle schon von Leuten problematisiert worden, die ggf. eher in der Lage gewesen wären, das zu reparieren. Ich glaube jedenfalls grade nicht daran, dass es mir gelingen wird, das in überschaubarer Zeit zu fixen, daher an der Stelle hier der Hilferuf... (Zumal jeder Fix-Versuch dann uU. dazu führt, dass man weitere Tests machen müßte).

Daher von meiner Seite: Danke für das Angebot betr. direktem "shutdown restart"!