Autor Thema: neuer Maintainer für WeekdayTimer, Heating_Control, RandomTimer  (Gelesen 4889 mal)

Offline igami

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2687
  • RTFM
    • commandref
Hallo Forum,

da ich in momentan wenig Zeit habe unterstützt mich Beta-User als 2. Maintainer für die Module WeekdayTimer, Heating_Control, RandomTimer.

Grüße
igami
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im August 2019.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3749
  • ~ Challenging Innovation ~
Antw:neuer Maintainer für WeekdayTimer, Heating_Control, RandomTimer
« Antwort #1 am: 27 April 2019, 11:39:03 »
Bitte auch in MAINTAINER.txt eintragen, man kann da auch mit / oder , getrennt mehrere Maintainer eintragen, wobei der erste Name der "Hauptansprechpartner" ist :-)
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9292
  • eigentlich eher "user" wie "developer"
Antw:neuer Maintainer für WeekdayTimer, Heating_Control, RandomTimer
« Antwort #2 am: 28 April 2019, 08:03:56 »
Hallo zusammen,

habe gestern bzw. heute updates für WeekdayTimer und RandomTimer ins svn geladen. Damit sollte keine Änderung der Funktionalität verbunden sein, sondern lediglich die interne Abhängigkeit beider Module von Twilight beendet werden. (@jeschkec: für den Fall, dass du hier mitliest: Das scheinen die letzten Module gewesen zu sein, die die indirekt Funktionen aus Twilight genutzt haben).

Was die weitere Roadmap angeht, war die Idee, mittelfristig Abschied von Heating_Control zu nehmen. Dafür muß WeekdayTimer (aus dem sowieso die Mehrzahl der Funktionen "geborgt" sind) noch ein paar Erweiterungen bekommen, was aber nicht so schwierig sein sollte.
Da ich mit solchen Übergangsprozessen keine Erfahrung habe, wäre es nett, wenn mir da jemand die Richtung weisen könnte, was da genau zu machen wäre (Ankündigungen, timeline, nach contrib usw.). Außerdem bin ich nur "Gelegenheitscoder". Wäre daher  nett, wenn es Tester und kritische Begleiter zum Code gäbe, bevor ich in dem Zusammenhang irgendwas ganz verbiege ::) .

Bitte auch in MAINTAINER.txt eintragen [...]
Done.
Bei der Gelegenheit: Wenn bei den Modulen (bzw. ggf. auch bei denen zu MySensors) irgendwas sinnvolles in Richtung Kennzeichnung (für Meta.pm?) zu tun wäre, greife ich das gerne auf, allerdings wäre ich hier für einen entsprechenden patch sehr dankbar, für mich sind da viele Begrifflichkeiten terra incognita...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3149
Antw:neuer Maintainer für WeekdayTimer, Heating_Control, RandomTimer
« Antwort #3 am: 28 April 2019, 09:07:52 »
war die Idee, mittelfristig Abschied von Heating_Control zu nehmen.
--snipp--
wenn mir da jemand die Richtung weisen könnte, was da genau zu machen wäre (Ankündigungen, timeline, nach contrib usw.)
 
a. dachte ich mir schon, bei Fragen zu HC habe ich in meinen Antworten auch schon versucht die User darauf einzustimmen.
b. Ich würde zuerst  WeekdayTimer auf einen Stand bringen das man ein Heating_Control  Device 1:1 ohne Änderung auf WeekdayTimer umstellen kann.
Im nächsten Schritt in Heating_Control via Log Level1 beim Define den Hinweis ausgeben das dieses Modul veraltert ist und der User bitten auf WeekdayTimer umstellen möge. Ab da kannst es schon nach contrib verschieben. Schau dir die FHEM Stats dazu ab und an mal an um ein Gefühl dafür zu bekommen wievel Heating_Controsl bei den Usern noch exestieren.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3749
  • ~ Challenging Innovation ~
Antw:neuer Maintainer für WeekdayTimer, Heating_Control, RandomTimer
« Antwort #4 am: 28 April 2019, 09:53:53 »
Bei der Gelegenheit: Wenn bei den Modulen (bzw. ggf. auch bei denen zu MySensors) irgendwas sinnvolles in Richtung Kennzeichnung (für Meta.pm?) zu tun wäre, greife ich das gerne auf, allerdings wäre ich hier für einen entsprechenden patch sehr dankbar, für mich sind da viele Begrifflichkeiten terra incognita...


Das ist super einfach bei dieser Art von Modulen, habe dir zwei Patches angehängt.
Für Heating_Control lohnt es ja offenbar nicht mehr ;)




PS: Im Ankündigungs-Forum wirds jetzt grad leicht OT :D
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9292
  • eigentlich eher "user" wie "developer"
Hallo zusammen,

zur Info, wer ggf. Schritt eins (Erweiterung des WDT) austesten will/kann:
https://forum.fhem.de/index.php/topic,100179.msg936166.html#msg936166
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9292
  • eigentlich eher "user" wie "developer"
Zur Info:
eben habe ich die aktualisierten Versionen von HC und WDT im svn eingecheckt einschl. der Ankündigung, dass man von HC auf WDT umstellen sollte. Mal schauen, wie das mit dem Umstellen usw. dann klappt/vorangeht.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9292
  • eigentlich eher "user" wie "developer"
Antw:neuer Maintainer für WeekdayTimer, Heating_Control, RandomTimer
« Antwort #7 am: 28 Dezember 2019, 21:14:55 »
Hallo zusammen,

in Abstimmung mit igami habe ich jetzt die Maintainerschaft für WeekdayTimer, RandomTimer und Heating_Control übernommen, die letzten Monate gab es ja bereits einige updates.

Was Heating_Control angeht, würde ich das gerne vor FHEM 6.0 ausphasen/nach contrib verschieben. Statistics sagt, es gäbe aktuell noch 133 Installationen, die  das verwenden, soweit mir das in Erinnerung ist, waren das mal deutlich mehr.
Das Warn-Level ist seit einiger Zeit auch schon auf verbose 1, es gibt eine Umstellungsroutine, mit der man das meiste an Konvertierung von HC nach WDT automatisiert machen kann, einzig die Perl-Aufrufe muß man ggf. manuell noch umstellen. Das sollte also für die Betroffenen kein größeres Ding mehr sein, und mit der neuen Möglichkeit, WDT mit weekprofile anzusteuern, hat vielleicht der eine oder andere auch neue Möglichkeiten,  die den Umstieg erleichtern.

Wenn's geht, würde ich das (auch nach dieser Ankündigung hier) noch ein paar Wochen so laufen lassen und dann nach contrib verschieben. Bei der Verschiebe-Aktion wäre es nett, wenn mir jemand unter die Arme greifen würde, der damit Erfahrung hat... (Oder reicht es, wenn ich die Datei verschiebe, und der Rest geschieht nach/mit einem commit automatisch?)

Grüße, Beta-User
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16129
  • s/fhem\.cfg/configDB/g
Antw:neuer Maintainer für WeekdayTimer, Heating_Control, RandomTimer
« Antwort #8 am: 29 Dezember 2019, 11:51:07 »
Bei der Verschiebe-Aktion wäre es nett, wenn mir jemand unter die Arme greifen würde, der damit Erfahrung hat

  • Datei nach ./contrib einchecken und in svn mit ADD markieren
  • Datei in ./FHEM löschen und in svn mit DELETE markieren
  • danach ein commit

Melde Dich, wenn Du soweit bist und nicht klarkommst.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9292
  • eigentlich eher "user" wie "developer"
Antw:neuer Maintainer für WeekdayTimer, Heating_Control, RandomTimer
« Antwort #9 am: 12 Januar 2020, 21:38:27 »
Danke für die Anleitung, scheint soweit geklappt zu haben.

Bin mal gespannt, wie viele Klagen kommen...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}