FHEM Forum

FHEM - Entwicklung => FHEM Development => Thema gestartet von: rudolfkoenig am 15 September 2021, 17:36:44

Titel: FHEM 6.1
Beitrag von: rudolfkoenig am 15 September 2021, 17:36:44
Ich wuerde gerne ein FHEM 6.1 Paket erstellen, damit das erste update kleiner ausfaellt, und damit Nicht-Eingeweihte auch sehen, dass bei FHEM sich was tut. Weiterhin habe ich kuerzlich FHEM/lib/Net/* entfernt (die "alten" MQTT Bibliotheken muss man von CPAN holen), das erfordert auch ein neues Ausgangspaket.

Geplant ist es etwa in 3-4 Wochen (Mitte Oktober), es waere nett, wenn dann der Stand halbwegs stabil ist.

P.S.: Ich habe vor die Voreinstellung von "attr global commandref" von full auf modular zu aendern.
Titel: Antw:FHEM 6.1
Beitrag von: rudolfkoenig am 23 Oktober 2021, 12:22:44
Ich waere soweit, und in den naechsten Tagen das Release zusammenpacken.
Da ich zuletzt gelesen habe, dass bestimmte Module (CUL_HM?) nicht in einem stabilen Zustand sind, waere nett, wenn jemand Feedback geben koennte, ob das immer noch so ist.
Titel: Antw:FHEM 6.1
Beitrag von: erwin am 23 Oktober 2021, 12:51:18
Noch eine Bitte: wär's möglich das modul 10_EIB.pm für die release nach contrib zu verschieben?
Ist seit 2018 deprecated und nicht supported - abgelöst durch KNX.pm. - steht  auch so im help.
da ich nicht der owner von dem modul bin.....
l.g. erwin
Titel: Antw:FHEM 6.1
Beitrag von: Beta-User am 23 Oktober 2021, 15:03:54
Da ich zuletzt gelesen habe, dass bestimmte Module (CUL_HM?) nicht in einem stabilen Zustand sind, waere nett, wenn jemand Feedback geben koennte, ob das immer noch so ist.
"stabil" vielleicht schon wieder, aber leider noch nicht gut - so zumindest meine Meinung (v.a., wenn man einen HMLAN als (mit-) IO im Einsatz hat.

Mit "Homematic" hatte ich neulich aber auch HMCCU.* gemeint. Vielleicht kann sich @zap noch melden, ob es sinnvoll ist, auf das 5.0 release zu warten?

@erwin:
MAn. könntest du das durchaus selbst machen, ohne groß gegen die Regeln zu verstoßen, dann aber bitte gleich ins Unterverzeichnis "deprecated" (oder hat jemand "wissendes" eine andere Meinung?).
Du bis schließlich derzeit "Mister KNX"...
(Zum Vorgehen: man kann afaik die Dateien nicht per svn-Befehl verschieben, sondern muss löschen und hinzufügen (und am besten dann noch die Infos nach CHANGED und UPGRADE schreiben), und kann am Ende alles auf einen Rutsch einchecken.)
Titel: Antw:FHEM 6.1
Beitrag von: erwin am 24 Oktober 2021, 08:26:58
@Beta-User:
..kann ich gerne selbst machen, die Bitte war an Rudolf gerichtet, da das de jure gegen die Regeln verstößt...
- mit seinem ok - kein Thema!
Versteh ich das richtig? Falls das 10_EIB Modul nicht mehr im SVN Verzeichnis ist, wird es NICHT durch update im user Verzeichnis gelöscht?
PS: es gibt noch immer 11 Installationen (lt. Statistik) mit EIB...
l.g.erwin
Titel: Antw:FHEM 6.1
Beitrag von: Beta-User am 24 Oktober 2021, 08:43:40
@Beta-User:
..kann ich gerne selbst machen, die Bitte war an Rudolf gerichtet, da das de jure gegen die Regeln verstößt...
- mit seinem ok - kein Thema!
...ich hab's jetzt einfach erledigt...

Das formale Problem wäre das Einverständnis des bisherigen Maintainers gewesen, aber der hat ja schon vor längerem zum einen kundgetan, dass man KNX verwenden soll, und zum anderen die Pflege abgegeben. Es war m.E. einfach ein verwaister Eintrag...

Zitat
Versteh ich das richtig? Falls das 10_EIB Modul nicht mehr im SVN Verzeichnis ist, wird es NICHT durch update im user Verzeichnis gelöscht?
PS: es gibt noch immer 11 Installationen (lt. Statistik) mit EIB...
l.g.erwin
Nein, es wird nicht gelöscht, es ist nur bei einer Neuinstallation nicht mehr da. Anders gesagt: Es ist kein unmittelbares Problem für die "Noch-Nutzer", es wird erst durch eine Neuinstallation zu einem solchen (oder durch eventuelle Änderungen am FHEM-Core, die zu Inkompabilitäten führen). Daher der mehrfache Verweis auf die Vorgehensweise zu MQTT_BRIDGE - da stellten sich dieselben Fragen.

Falls jemand meine "Eigenmächtigkeiten" nicht ok findet: bitte melden, dann machen wir das eben wieder rückgängig...
Titel: Antw:FHEM 6.1
Beitrag von: rudolfkoenig am 24 Oktober 2021, 10:19:04
Ich meine wir sollten solche Verschiebungen in der UPGRADE Datei eintragen, damit Leute, die nur alle paar Jahre update durchfuehren, es auch mitkriegen.
Ansonsten warte ich auf Feedback fuer HMCCU / Homematic.
Titel: Antw:FHEM 6.1
Beitrag von: betateilchen am 24 Oktober 2021, 21:11:30
Nein, es wird nicht gelöscht, es ist nur bei einer Neuinstallation nicht mehr da. Anders gesagt: Es ist kein unmittelbares Problem für die "Noch-Nutzer",

Für Nutzer, die ihr FHEM direkt aus SVN updaten, wird das zu einem sehr direkten Problem, weil bei diesen Anwendern die verschobene Datei sehr wohl aus der bestehenden Installation gelöscht wird.

Ansonsten warte ich auf Feedback fuer HMCCU / Homematic.

Hast Du schon eine konkrete Deadline und ein Release-Datum geplant?
Hintergrund meiner Frage ist, dass ich zeitnah den Buildprozess für das nightly build kontrollieren und ggf. anpassen muss.
Titel: Antw:FHEM 6.1
Beitrag von: rudolfkoenig am 25 Oktober 2021, 09:59:09
Eigentlich wollte ich das jetzt machen, aber es kam kein Feedback.
Da ewig zu warten auch nicht hilft: in zwei Wochen, d.h. 6./7.11
Einspruch wird natuerlich beruecksichtigt.
Titel: Antw:FHEM 6.1
Beitrag von: Beta-User am 25 Oktober 2021, 10:19:23
Hast Du schon eine konkrete Deadline und ein Release-Datum geplant?
Hintergrund meiner Frage ist, dass ich zeitnah den Buildprozess für das nightly build kontrollieren und ggf. anpassen muss.
Das "Problem" dürfte sein, dass martinp876 anscheinend derzeit sehr wenig Zeit findet, sich zu kümmern, und mind. ein Problem gelöst werden sollte, bevor CUL_HM zumindest ein "befriedigend" bekommen kann. Siehe https://forum.fhem.de/index.php/topic,123608.msg1182082.html#msg1182082. Ich werde jetzt noch versuchen, den "autocreate"-Prozess zu fixen und zu checken, ob es jetzt mit der Initialisierung des HMLAN ein Probem gibt oder nicht und dann Martin wieder direkt anpingen.

@zap könnte ggf. ja mal jemand anpingen, der die Module nutzt. Auch dort scheint die Meinung der user in die Richtung zu gehen, dass Neueinsteiger besser mit der aktuellen 5.0beta hantieren sollten wie mit 4.3... (Evtl. könnte man das 6.1. package auch mit der 5.0beta fertig machen, updates für 4.3 scheint es nicht mehr zu geben...?)

Ich meine wir sollten solche Verschiebungen in der UPGRADE Datei eintragen, damit Leute, die nur alle paar Jahre update durchfuehren, es auch mitkriegen.
Da (und in UPDATE) hatte ich es vermerkt, nur MAINTAINER.txt ist mir erst durchgerutscht.

Für Nutzer, die ihr FHEM direkt aus SVN updaten, wird das zu einem sehr direkten Problem, weil bei diesen Anwendern die verschobene Datei sehr wohl aus der bestehenden Installation gelöscht wird.
Danke für den Hinweis. Leider habe ich grade keine Idee, wie man auch noch dieses Problem sauber umschiffen kann und erbitte entsprechende Vorschläge.

EIB einfach "forever" drin zu lassen erscheint jedenfalls mir keine bessere Option zu sein, und meine bisherigen Erfahrungen mit Heating_Control (mehr als 1,5 Jahre) und MQTT_BRIDGE (einige Wochen) gehen dahin, dass es nicht die User sind, die svn-updates durchführen, die dann irgendwann ein Problem haben, sondern ein anderer "User-Typ"...
Titel: Antw:FHEM 6.1
Beitrag von: rudolfkoenig am 25 Oktober 2021, 10:42:53
Zitat
Für Nutzer, die ihr FHEM direkt aus SVN updaten, wird das zu einem sehr direkten Problem, weil bei diesen Anwendern die verschobene Datei sehr wohl aus der bestehenden Installation gelöscht wird.
Diese Gruppe duerfte eher klein sein, und erfahren.
Wenn sie bei EIB bleiben wollen, dann muessen sie nach dem Update die Datei aus contrib ins FHEM Verzeichnis kopieren.
Titel: Antw:FHEM 6.1
Beitrag von: betateilchen am 25 Oktober 2021, 11:20:42
Diese Gruppe duerfte eher klein sein, und erfahren.
Wenn sie bei EIB bleiben wollen, dann muessen sie nach dem Update...

Beides richtig, mir ging es nur darum, die Notwendigkeit einer klaren Kommunikation (z.B. in UPGRADE) deutlich zu machen.
Titel: Antw:FHEM 6.1
Beitrag von: Beta-User am 25 Oktober 2021, 12:33:58
Beides richtig, mir ging es nur darum, die Notwendigkeit einer klaren Kommunikation (z.B. in UPGRADE) deutlich zu machen.
Da sind wir völlig beieinander.

Falls es (außer der vergessenen und nachgeholten Änderung gleich auch in MAINTAINER.txt) Kritikpunkte an https://svn.fhem.de/trac/changeset/25112/ gibt: tell me... UPGRADE wurde da jedenfall ausdrücklich auch angefasst ;) .

werde jetzt noch versuchen, den "autocreate"-Prozess zu fixen und zu checken, ob es jetzt mit der Initialisierung des HMLAN ein Probem gibt
Aktualisierte Versionen stehen in https://forum.fhem.de/index.php/topic,123436.0/topicseen.html zum Testen (und/oder zur fachlichen Begutachtung) bereit, falls jemand möchte...
Titel: Antw:FHEM 6.1
Beitrag von: Adimarantis am 26 Oktober 2021, 07:50:28
Macht es Sinn im Rahmen des Versionsupgrade generell mal durchzuschauen, welche Module noch aktiv maintained sind und diese ggf. nach contrib oder sogar nach deprecated zu verschieben?
Ich hätte da gleich noch zwei Kandidaten (RFHEM -> deprecated weil jetzt komplett über FHEM2FHEM abgedeckt, und GPIO4 -> deprecated da ich kurz davor bin das Ersatzmodul RPI_1Wire einzuchecken und ursprünglicher Author nicht erreichbar).

Wenn sie jemand noch im Einsatz hat, dann spielt das ja erstmal keine Rolle (werden ja nicht gelöscht) aber wir halten neue User davon ab auf Module zu setzen, die keiner mehr wartet.

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.

Jörg
Titel: Antw:FHEM 6.1
Beitrag von: Beta-User am 26 Oktober 2021, 09:39:08
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...).

Generell finde ich es gut, wenn "untaugliche" und v.a. "überholte" Sachen rausfliegen, aber das nur anhand des Alters des letzten "Anfassens" festzumachen, ist m.E. etwas zu kurz gegriffen. Neulich hatten wir z.B. "X10", das "ewig" nicht mehr angefasst worden war, und "nur" den kleinen Makel hatte, dass es (noch) nicht die aktuellen readings.*Update-Routinen eingebaut hatte. Die Aktualisierung war im Prinzip eine Kleinigkeit (https://svn.fhem.de/trac/changeset/25094/trunk/fhem/FHEM). Wegen sowas muss man nicht gleich eine größere Aktion anstoßen...

Wichtig fände ich jedenfalls, wenn man derzeitige User nicht zu schnell vor vollendete Tatsachen stellt und Probleme verursacht, ohne das anzukündigen.


Etwas anderes Thema:
Vielleicht könnte man in der "modular"-Variante einen neuen Abschnitt schaffen für Kurzbeschreibungen aus "contrib"? Wer als Maintainer Kurzbeschreibungen mitliefert, könnte damit bewirken, dass sein "contrib"-Modul zumindest als "prinzipiell vorhanden" erwähnt wird.
Titel: Antw:FHEM 6.1
Beitrag von: betateilchen am 26 Oktober 2021, 10:10:21
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?"


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


Titel: Antw:FHEM 6.1
Beitrag von: Dr. Boris Neubert am 26 Oktober 2021, 10:26:18
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.
Titel: Antw:FHEM 6.1
Beitrag von: Beta-User am 26 Oktober 2021, 12:08:30
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...

Zitat
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.
Titel: Antw:FHEM 6.1
Beitrag von: Adimarantis am 26 Oktober 2021, 12:33:10
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)

Titel: Antw:FHEM 6.1
Beitrag von: Christoph Morrison am 26 Oktober 2021, 12:50:05
GSI gehört herrmannj
Netzfrequenz gehört ebenfalls herrmannj
Blink gehört Viegener

Titel: Antw:FHEM 6.1
Beitrag von: Beta-User am 26 Oktober 2021, 12:54:54
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 (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)...

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

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?
Titel: Antw:FHEM 6.1
Beitrag von: rudolfkoenig am 26 Oktober 2021, 13:27:05
Zitat
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..
Titel: Antw:FHEM 6.1
Beitrag von: Adimarantis am 26 Oktober 2021, 13:32:35
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.

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

Titel: Antw:FHEM 6.1
Beitrag von: Beta-User am 26 Oktober 2021, 13:38:09
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!)
Titel: Antw:FHEM 6.1
Beitrag von: Christoph Morrison am 26 Oktober 2021, 13:41:10
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.
Titel: Antw:FHEM 6.1
Beitrag von: herrmannj am 26 Oktober 2021, 14:39:45
Wird erledigt. Danke!
Titel: Antw:FHEM 6.1
Beitrag von: Adimarantis am 26 Oktober 2021, 15:38:21
viegener und hermannj habe ich schon angeschrieben.
Hab den Rest angeschrieben.
Titel: Antw:FHEM 6.1
Beitrag von: Beta-User am 29 Oktober 2021, 15:20:28
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).
Titel: Antw:FHEM 6.1
Beitrag von: rudolfkoenig am 29 Oktober 2021, 16:24:04
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.
Titel: Antw:FHEM 6.1
Beitrag von: Beta-User am 29 Oktober 2021, 16:48:16
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"!
Titel: Antw:FHEM 6.1
Beitrag von: rudolfkoenig am 02 November 2021, 18:29:58
Zitat
Daher von meiner Seite: Danke für das Angebot betr. direktem "shutdown restart"!
Wohl zu frueh: ich will mein Angebot zurueckziehen.

Ich habe die Funktion implementiert aber nicht eingecheckt.
#1: beim Testen stellt sich raus, dass das Editieren der fhem.cfg ueber FHEMWEB damit problematisch ist. Da ich den zufaelligen CSRF Token nicht so recht ueber restart retten kann, muss die Seite nach Save zum FHEMWEB-Root navigiert werden. Bin auch unsicher, ob meine aktuelle Loesung keine Seiteneffekte hat.
#2: beim rereadcfg bleibt der Prozess bestehen, beim shutdown restart nicht. Wenn das Startprogramm (systemd, init, etc) sich darauf verlaesst, dann gibt es nach save Chaos. Das ist nicht FHEMWEB-spezifisch, rereadcfg kann auch anderweitig ausgeloest werden (z.Bsp. kill -HUP).
#3: Die Doku muss an vielen Stellen angepasst werden, genauso wie sinnloser Code in 100+ Modulen. Dass ich die Aenderung unbedingt an featurelevel binden will, macht die Sache nicht einfacher.

Ich haette Ideen, #1 und #2 technisch zu loesen (keine Ahnung ob es klappt), fuer #3 habe ich keine gute Idee.

Ich bin geneigt rereadcfg zu lassen, wie es ist, und hoffen, dass die Benutzer (die aktuell auch dieses Problem haben), die Maintainer der kaputten Module zum fixen des Problems bewegen. Es hat ja schliesslich schon mal funktioniert.
Titel: Antw:FHEM 6.1
Beitrag von: Beta-User am 03 November 2021, 10:29:27
Schade eigentlich...

ad #3 verstehe ich den Punkt mit der Doku, "sinnloser" Code ist es vermutlich in den meisten Fällen nicht, weil sowieso in den meisten Fällen keine Unterscheidung zwischen INITIALIZED und REREADCFG gemacht wird. Aber egal.

Zwischenzeitlich meine ich die Ursache gefunden zu haben, warum es nicht funktioniert hatte: CUL_HM weist nur genau einer Instanz ein NOTIFYDEV zu - im Rahmen der Initialisierung. Werden dann alle Devices gelöscht, gibt es keine Instanz mehr, die auf das "global"-Event hören würde, es passiert schlicht "nichts".

Problem erkannt, Problem vermutlich gebannt... (aber noch lange nicht im svn, und ich bin mal gespannt, welche Ideen Martin dazu dann noch hat...).

Grundsätzlich habe ich immer mehr den Eindruck, dass eine InitFn() wie von noansi an anderer Stelle vorgeschlagen die elegantere Lösung wäre. Die zumindest in CUL_HM erforderlichen workarounds kommen mir jedenfalls unschön vor.
Titel: Antw:FHEM 6.1
Beitrag von: Adimarantis am 03 November 2021, 10:49:12
Grundsätzlich habe ich immer mehr den Eindruck, dass eine InitFn() wie von noansi an anderer Stelle vorgeschlagen die elegantere Lösung wäre. Die zumindest in CUL_HM erforderlichen workarounds kommen mir jedenfalls unschön vor.
Dem kann ich nur beipflichten. Habe gerade erst für ein Modul mit viel Debug-Output die Aufrufreihenfolge der einzelnen Funktionen und Events analysiert, damit ich entsprechende Init-Aktionen an der richtigen Stelle einpflegen kann. Eine definierte Funktion die aufgerufen wird, wenn alle Attribute und Readings soweit stehen, wäre durchaus hilfreich und ist oft der einzige Grund für eine NotifyFn.

Zum Thema MAINTAINER.txt ein Zwischenstand:
Hab mir dazu ein kleines Script geschrieben. Aktueller Output:
Missing maintainers:
# $Id: 00_Schellenberg.pm 22716 2020-09-02 19:37:55Z herrmannj $
# $Id: 00_SmartMeterP1.pm 14594 2017-06-29 06:03:03Z fhemmiv $
# $Id: 10_SchellenbergHandle.pm 22793 2020-09-19 13:54:36Z herrmannj $
# $Id: 23_ALL4027.pm 2076 2012-11-04 13:49:43Z rudolfkoenig $
#     $Id: 48_BlinkCamera.pm 24078 2021-03-24 20:31:34Z viegener $
# $Id: 59_GSI.pm 21380 2020-03-08 17:09:49Z herrmannj $
# $Id: 59_Netzfrequenz.pm 24654 2021-06-18 00:18:40Z herrmannj $
# $Id: 66_EseraAnalogInOut.pm 20592 2019-11-25 20:56:33Z pizmus $
#  $Id: 98_readingsWatcher.pm 25053 2021-10-07 07:39:29Z Wzut $
# $Id: 98_template.pm 13688 2017-03-12 18:16:38Z neubert $
# $Id: 98_uptime.pm 14706 2017-07-13 17:22:27Z betateilchen $
# $Id: myUtilsTemplate.pm 21509 2020-03-25 11:20:51Z rudolfkoenig $
# $Id: RTypes.pm 10476 2016-01-12 21:03:33Z borisneubert $
# $Id: WinService.pm 5819 2014-05-11 14:17:21Z rudolfkoenig $
# $Id: ZWLib.pm 17186 2018-08-20 20:10:55Z rudolfkoenig $
Mismatches:
FHEM/10_MQTT_BRIDGE
FHEM/66_EseraAnalogInIout
FHEM/88_HMCCURPC
FHEM/YahooWeatherAPI
Mismatches entstehen, wenn für Einträge in der MAINTAINER.txt nichts im FHEM Verzeichnis gefunden wird.
Es werden nur .pm Dateien betrachtet und Unterverzeichnisse ignoriert.

Auffällig ist in der Hauptsache:
# $Id: 00_SmartMeterP1.pm 14594 2017-06-29 06:03:03Z fhemmiv $
Der Author ist nicht im Forum registriert und hat auf eine Anfrage über seit über einem Jahr nicht reagiert. Letzter Post 2015
Titel: Antw:FHEM 6.1
Beitrag von: betateilchen am 03 November 2021, 12:18:54
Auffällig ist in der Hauptsache:
...
Der Author ist nicht im Forum registriert und hat auf eine Anfrage über seit über einem Jahr nicht reagiert. Letzter Post 2015

Da ist für mich erstmal nichts Auffälliges dabei. Wenn ein User sich länger als ein Jahr nicht im Forum anmeldet, verschwindet er automatisch aus der Benutzerliste. Warum er/sie/es sich so lange nicht angemeldet hat, wissen wir nicht. Hoffen wir mal nicht das Schlimmste.

# $Id: myUtilsTemplate.pm 21509 2020-03-25 11:20:51Z rudolfkoenig $
Das kannst Du abhaken, das ist keine echte Moduldatei, sondern nur eine Vorlage.
Titel: Antw:FHEM 6.1
Beitrag von: Dr. Boris Neubert am 04 November 2021, 13:12:14
Zum Thema MAINTAINER.txt ein Zwischenstand:
Hab mir dazu ein kleines Script geschrieben. Aktueller Output:
Missing maintainers:
# $Id: 00_Schellenberg.pm 22716 2020-09-02 19:37:55Z herrmannj $
# $Id: 00_SmartMeterP1.pm 14594 2017-06-29 06:03:03Z fhemmiv $
# $Id: 10_SchellenbergHandle.pm 22793 2020-09-19 13:54:36Z herrmannj $
# $Id: 23_ALL4027.pm 2076 2012-11-04 13:49:43Z rudolfkoenig $
#     $Id: 48_BlinkCamera.pm 24078 2021-03-24 20:31:34Z viegener $
# $Id: 59_GSI.pm 21380 2020-03-08 17:09:49Z herrmannj $
# $Id: 59_Netzfrequenz.pm 24654 2021-06-18 00:18:40Z herrmannj $
# $Id: 66_EseraAnalogInOut.pm 20592 2019-11-25 20:56:33Z pizmus $
#  $Id: 98_readingsWatcher.pm 25053 2021-10-07 07:39:29Z Wzut $
# $Id: 98_template.pm 13688 2017-03-12 18:16:38Z neubert $
# $Id: 98_uptime.pm 14706 2017-07-13 17:22:27Z betateilchen $
# $Id: myUtilsTemplate.pm 21509 2020-03-25 11:20:51Z rudolfkoenig $
# $Id: RTypes.pm 10476 2016-01-12 21:03:33Z borisneubert $
# $Id: WinService.pm 5819 2014-05-11 14:17:21Z rudolfkoenig $
# $Id: ZWLib.pm 17186 2018-08-20 20:10:55Z rudolfkoenig $
Mismatches:
FHEM/10_MQTT_BRIDGE
FHEM/66_EseraAnalogInIout
FHEM/88_HMCCURPC
FHEM/YahooWeatherAPI

Ich wollte gerade 98_template.pm nachtragen, da ist mir aufgefallen, dass die Umlaute in der Datei kaputt sind :-( und ich keine Lust habe, sie zu richten >:-/

Titel: Antw:FHEM 6.1
Beitrag von: Adimarantis am 04 November 2021, 13:40:25
Ich wollte gerade 98_template.pm nachtragen, da ist mir aufgefallen, dass die Umlaute in der Datei kaputt sind :-( und ich keine Lust habe, sie zu richten >:-/
Nachdem "kaputt" hier relativ ist (über http schaut es z.B. ok aus) würde ich vorschlagen Umlaute generell aus dieser Datei zu verbannen. Hiesse ohnehin wohl nur "Unterstützende Dienste" -> "Unterstuetzende Dienste" - oder hat das irgendeine Abhängigkeit?
Titel: Antw:FHEM 6.1
Beitrag von: Dr. Boris Neubert am 04 November 2021, 14:05:47
Nachdem "kaputt" hier relativ ist (über http schaut es z.B. ok aus) würde ich vorschlagen Umlaute generell aus dieser Datei zu verbannen. Hiesse ohnehin wohl nur "Unterstützende Dienste" -> "Unterstuetzende Dienste" - oder hat das irgendeine Abhängigkeit?

$ echo $TERM
xterm-256color
$ file MAINTAINER.txt
MAINTAINER.txt: ISO-8859 text
$ recode MAINTAINER.txt iso-8859..utf8
recode: Anfrage »MAINTAINER.txt« ist fehlerhaft

Auf der Linux-Konsole sind die üs kaputt (0xFC), Firefox und der Editor Kate zeigen sie richtig an, Visual Studio Code zeigt sie kaputt an.

In einer älteren Version von vor wenigen Wochen, in die ich meine Zeile eingetragen habe, war noch alles in Ordnung. Beim Einchecken gab es einen Konflikt, weil die daneben stehende Zeile die Kodierung von ü gewechselt hat, und da ist es mir aufgefallen.

Es muss doch im Jahre 2021 möglich sein, mit Umlauten in Textdateien zu arbeiten! Am besten stellen wir die Datei auf UTF8 mit BOM um und hoffen, dass alle Editoren, mit denen jemand da ran geht, damit richtig umgehen.

Nachdem ich mich wieder abgeregt habe: ich mache das später, wenn es keine Einwände gibt.
Titel: Antw:FHEM 6.1
Beitrag von: rudolfkoenig am 04 November 2021, 14:10:15
Zitat
Nachdem ich mich wieder abgeregt habe: ich mache das später, wenn es keine Einwände gibt.
Bitte :)
Titel: Antw:FHEM 6.1
Beitrag von: betateilchen am 04 November 2021, 14:44:34
Nachdem ich mich wieder abgeregt habe: ich mache das später, wenn es keine Einwände gibt.

Hallo Boris,

wenn Du die Datei schon bearbeitest - könntest Du bitte meine (fehlende) Datei 98_uptime.pm mit der Rubrik "Sonstiges" an der entsprechenden Stelle eintragen? Aktuell habe ich hier keine Möglichkeit, in FHEM etwas per svn zu tun.

Dankeschön!
Titel: Antw:FHEM 6.1
Beitrag von: Beta-User am 04 November 2021, 15:19:18
Vielleicht ergänzend zu den bereits erledigten "deprecated"-moves: In der MAINTAINER.txt steht zu 20_OWFS.pm und 21_OWTEMP.pm ausdrücklich schon drin, dass das "deprecated" sei, die Statistik (wie glaubhaft auch immer die sein mag) meldet jeweils keine Installation, die das verwendet.

Sollten wir das dann nicht auch gleich verschieben (bzw. der betr. Maintainer, falls noch aktiv?)? (Mache das gerne bei Gelegenheit auf Anfrage, bräuchte dann aber ggf. neben der Freigabe einen Schubs, was als "Ersatz" gelistet werden soll. Da das von einem owserver spricht, unterstelle ich OWServer+OWDevice? Oder OWX/OWTherm?)
Titel: Antw:FHEM 6.1
Beitrag von: Dr. Boris Neubert am 04 November 2021, 17:14:40
MAINTAINER.txt um template und uptime ergänzt, als UTF-8 mit BOM rekodiert und eingecheckt
Titel: Antw:FHEM 6.1
Beitrag von: Dr. Boris Neubert am 04 November 2021, 17:18:24
Sollten wir das dann nicht auch gleich verschieben (bzw. der betr. Maintainer, falls noch aktiv?)? (Mache das gerne bei Gelegenheit auf Anfrage, bräuchte dann aber ggf. neben der Freigabe einen Schubs, was als "Ersatz" gelistet werden soll. Da das von einem owserver spricht, unterstelle ich OWServer+OWDevice? Oder OWX/OWTherm?)

Maintainer ist Martin Fischer, der mit mir hernach OWServer/OWDevice entwickelt hat. Am besten Martin ansprechen.
Titel: Antw:FHEM 6.1
Beitrag von: rudolfkoenig am 04 November 2021, 17:56:59
Ich habe myUtilsTemplate.pm, ZWLib.pm und WinService.pm zu MAINTAINER.txt hinzugefuegt.
23_ALL4027.pm habe ich wohl geerbt, laut Statistik wird nicht verwendet, und ich waere fuer ein Verschieben ins contrib.
Gegenargumente?
Titel: Antw:FHEM 6.1
Beitrag von: Martin Fischer am 04 November 2021, 23:08:21
Maintainer ist Martin Fischer, der mit mir hernach OWServer/OWDevice entwickelt hat. Am besten Martin ansprechen.

Sorry, der Thread ist an mir vorbei gegangen... Kann getrost nach contrib verschoben bzw. archiviert werden.
Titel: Antw:FHEM 6.1
Beitrag von: Adimarantis am 06 November 2021, 18:52:15
Noch ein Gedanke zum Abgleich MAINTAINER.txt:
Könnte man die Datei im täglichen Batch auswerten und die jeweiligen Maintainer und Forenlink (sofern vorhanden) als Hyperlink in der FHEM Statistics Seite anzeigen? (also in die DB einspielen)
Dann hätte man alle relevanten Infos beinander (#Installationen und Maintainer eingetragen) und könnte auch komfortabel suchen. Alle "Lücken" bleiben dann leer oder werden als "unsupported" angezeigt.
Setzt natürlich vorraus, dass die Datei "sauber" bleibt (pre-commit?)
Titel: Antw:FHEM 6.1
Beitrag von: betateilchen am 07 November 2021, 20:46:39
Könnte man die Datei im täglichen Batch auswerten und die jeweiligen Maintainer und Forenlink (sofern vorhanden) als Hyperlink in der FHEM Statistics Seite anzeigen? (also in die DB einspielen)

Das ist nicht Sinn und Zweck der Statistikdatenbank.