FHEM 6.1

Begonnen von rudolfkoenig, 15 September 2021, 17:36:44

Vorheriges Thema - Nächstes Thema

rudolfkoenig

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.

rudolfkoenig

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.

erwin

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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Beta-User

Zitat von: rudolfkoenig am 23 Oktober 2021, 12:22:44
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.)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

erwin

@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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Beta-User

Zitat 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!
...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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

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.

betateilchen

Zitat von: Beta-User am 24 Oktober 2021, 08:43:40
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.

Zitat von: rudolfkoenig am 24 Oktober 2021, 10:19:04
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

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.

Beta-User

Zitat von: betateilchen am 24 Oktober 2021, 21:11:30
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...?)

Zitat 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.
Da (und in UPDATE) hatte ich es vermerkt, nur MAINTAINER.txt ist mir erst durchgerutscht.

Zitat von: betateilchen am 24 Oktober 2021, 21:11:30
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"...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatFü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.

betateilchen

Zitat von: rudolfkoenig am 25 Oktober 2021, 10:42:53
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Zitat von: betateilchen am 25 Oktober 2021, 11:20:42
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 ;) .

Zitat von: Beta-User am 25 Oktober 2021, 10:19:23
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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Adimarantis

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files