FHEM 6.1

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

Vorheriges Thema - Nächstes Thema

rudolfkoenig

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

Beta-User

#31
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.
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

Zitat von: Beta-User am 03 November 2021, 10:29:27
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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

betateilchen

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

Dr. Boris Neubert

Zitat von: Adimarantis am 03 November 2021, 10:49:12
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 >:-/

Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Adimarantis

Zitat von: Dr. Boris Neubert am 04 November 2021, 13:12:14
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?
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Dr. Boris Neubert

Zitat von: Adimarantis am 04 November 2021, 13:40:25
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.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

rudolfkoenig

ZitatNachdem ich mich wieder abgeregt habe: ich mache das später, wenn es keine Einwände gibt.
Bitte :)

betateilchen

Zitat von: Dr. Boris Neubert am 04 November 2021, 14:05:47
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!
-----------------------
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

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?)
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

Dr. Boris Neubert

MAINTAINER.txt um template und uptime ergänzt, als UTF-8 mit BOM rekodiert und eingecheckt
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Dr. Boris Neubert

Zitat von: Beta-User am 04 November 2021, 15:19:18
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.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

rudolfkoenig

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?

Martin Fischer

Zitat von: Dr. Boris Neubert am 04 November 2021, 17:18:24
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.
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

Adimarantis

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