Autor Thema: FHEM 6.1  (Gelesen 4335 mal)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24699
FHEM 6.1
« 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.
Gefällt mir Gefällt mir x 3 Liste anzeigen

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24699
Antw:FHEM 6.1
« Antwort #1 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.

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 622
Antw:FHEM 6.1
« Antwort #2 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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16327
Antw:FHEM 6.1
« Antwort #3 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.)
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 622
Antw:FHEM 6.1
« Antwort #4 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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16327
Antw:FHEM 6.1
« Antwort #5 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...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24699
Antw:FHEM 6.1
« Antwort #6 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.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17555
  • s/fhem\.cfg/configDB/g
Antw:FHEM 6.1
« Antwort #7 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.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24699
Antw:FHEM 6.1
« Antwort #8 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.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16327
Antw:FHEM 6.1
« Antwort #9 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"...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24699
Antw:FHEM 6.1
« Antwort #10 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.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17555
  • s/fhem\.cfg/configDB/g
Antw:FHEM 6.1
« Antwort #11 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.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Lesen gefährdet die Unwissenheit!
Zustimmung Zustimmung x 2 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16327
Antw:FHEM 6.1
« Antwort #12 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...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Adimarantis

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 512
Antw:FHEM 6.1
« Antwort #13 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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16327
Antw:FHEM 6.1
« Antwort #14 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.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}
Gefällt mir Gefällt mir x 2 Liste anzeigen

 

decade-submarginal