Autor Thema: Meta.pm: Metadaten über FHEM Module  (Gelesen 2034 mal)

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Meta.pm: Metadaten über FHEM Module
« am: 19 Februar 2019, 11:43:50 »
Hi,

bei der Recherche zu externen Abhängigkeiten von FHEM Modulen ist mir mal wieder bewusst geworden, wie unterschiedlich das dokumentiert ist und wie schwer es für Nutzer und auch Entwickler ist, diese verlässlich zusammenzutragen oder gar maschinenlesbar auszuwerten. Jetzt, wo André und Co. eine ganze Reihe von Modulen neu bereitgestellt haben, die eine starke Abhängigkeit zu Node.js bzw. NPM Paketen haben, wollte ich das zum Anlass nehmen das ganze zu verbessern.

Für die Installation an sich habe ich als erstes Beispiel einmal das npmjs.pm Modul geschrieben, welches nun Node.js Pakete installieren/deinstallieren/aktualisieren kann. Andrés Module reagieren sogar darauf, wenn NPM was an den Node.js Pakete macht. Allerdings fehlt noch immer die maschinenlesbare Info, dass zum FHEM Modul "alexa" das Node.js Paket "alexa-fhem" gehört und dass beide nur zusammen funktionieren.

Meta.pm ermöglicht es nun, dass man Meta-Informationen als zusätzlichen Pod im JSON Format in eine Moduldatei mit ablegt. Das JSON Format folgt dabei der Spezifikation von CPAN::Meta::Spec und wurde um einige Custom Attribute (beginnend mit x_) für FHEM erweitert. Wenn ein Modul Meta.pm implementiert hat, dann gibt es im $modules{<PKG>}{META} Hash die entsprechenden Informationen über die Moduldatei.

Beispiel:

{
  'ORDER' => '42',
  'UndefFn' => 'FHEM::npmjs::Undef',
  'GetFn' => 'FHEM::npmjs::Get',
  'DefFn' => 'FHEM::npmjs::Define',
  'NotifyFn' => 'FHEM::npmjs::Notify',
  'NAME' => 'npmjs',
  'LOADED' => 1,
  'AttrFn' => 'FHEM::npmjs::Attr',
  'SetFn' => 'FHEM::npmjs::Set',
  'AttrList' => 'disable:1,0 disabledForIntervals updateListReading:1,0 npmglobal:1,0 event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading',
  'META' => {
              'description' => 'commandref.html#npmjs',
              'x_fhem_maintainer_github' => [
                                              'jpawlowski'
                                            ],
              'author' => [
                            'Julian Pawlowski <julian.pawlowski@gmail.com>'
                          ],
              'x_prereqs_os' => {
                                  'runtime' => {
                                                 'suggests' => {},
                                                 'requires' => {},
                                                 'recommends' => {
                                                                   'debian|ubuntu' => 0
                                                                 }
                                               }
                                },
              'x_prereqs_os_debian' => {
                                         'runtime' => {
                                                        'requires' => {},
                                                        'suggests' => {},
                                                        'recommends' => {
                                                                          'openssh-client' => 0
                                                                        }
                                                      }
                                       },
              'x_file' => [
                            './FHEM/42_npmjs.pm',
                            './FHEM/',
                            '42_npmjs.pm',
                            '42',
                            'npmjs',
                            'pm',
                            [
                              2049,
                              576456,
                              33188,
                              1,
                              6061,
                              6061,
                              0,
                              53269,
                              [
                                1550565749,
                                '2019-02-19 09:42:29',
                                '2019-02-19',
                                '2019',
                                '02',
                                '19',
                                '09:42:29',
                                '09',
                                '42',
                                '29'
                              ],
                              [
                                1550565676,
                                '2019-02-19 09:41:16',
                                '2019-02-19',
                                '2019',
                                '02',
                                '19',
                                '09:41:16',
                                '09',
                                '41',
                                '16'
                              ],
                              [
                                1550565746,
                                '2019-02-19 09:42:26',
                                '2019-02-19',
                                '2019',
                                '02',
                                '19',
                                '09:42:26',
                                '09',
                                '42',
                                '26'
                              ],
                              4096,
                              112
                            ],
                            'META.json',
                            undef
                          ],
              'x_prereqs_permissions_filemod' => {
                                                   'runtime' => {
                                                                  'recommends' => {},
                                                                  'requires' => {},
                                                                  'suggests' => {}
                                                                }
                                                 },
              'x_prereqs_permissions_fileown' => {
                                                   'runtime' => {
                                                                  'recommends' => {},
                                                                  'suggests' => {},
                                                                  'requires' => {}
                                                                }
                                                 },
              'resources' => {
                               'license' => [
                                              'https://fhem.de/#License'
                                            ],
                               'repository' => {
                                                 'x_branch_dev' => 'trunk',
                                                 'x_branch_master' => 'trunk',
                                                 'type' => 'svn',
                                                 'url' => 'https://svn.fhem.de/fhem/',
                                                 'web' => 'https://svn.fhem.de/'
                                               },
                               'bugtracker' => {
                                                 'x_web_title' => 'Sonstige Systeme',
                                                 'web' => 'https://forum.fhem.de/index.php/board,29.0.html'
                                               },
                               'homepage' => 'https://fhem.de/'
                             },
              'name' => 'FHEM::npmjs',
              'meta-spec' => {
                               'url' => 'https://metacpan.org/pod/CPAN::Meta::Spec',
                               'version' => 2
                             },
              'prereqs' => {
                             'runtime' => {
                                            'recommends' => {},
                                            'requires' => {
                                                            'perl' => '5.014',
                                                            'GPUtils qw(GP_Import)' => 0,
                                                            'Data::Dumper' => 0,
                                                            'JSON' => 0
                                                          },
                                            'suggests' => {}
                                          }
                           },
              'x_prereqs_binary_exec' => {
                                           'runtime' => {
                                                          'recommends' => {},
                                                          'requires' => {
                                                                          '/usr/bin/npm|/usr/local/bin/npm' => 0,
                                                                          '/usr/bin/node|/usr/local/bin/node' => 0
                                                                        },
                                                          'suggests' => {
                                                                          '/usr/bin/ssh|/usr/local/bin/ssh' => 0
                                                                        }
                                                        }
                                         },
              'keywords' => [
                              'fhem-core',
                              'fhem-mod',
                              'fhem-mod-device',
                              'nodejs',
                              'node',
                              'npm'
                            ],
              'dynamic_config' => 1,
              'x_lang' => {
                            'DE' => {
                                      'description' => '/./docs/commandref_DE.html#npmjs',
                                      'abstract' => 'Modul zur Bedienung der Node.js Paket Installation und Updates'
                                    },
                            'de' => {
                                      'description' => 'commandref.html#npmjs',
                                      'abstract' => 'Modul zur Bedienung der Node.js Installation und Updates'
                                    }
                          },
              'generated_by' => 'FHEM::Meta v0.0.1, 2019-02-19 09:42:29',
              'license' => 'GPL_3',
              'release_status' => 'stable',
              'x_prereqs_os_ubuntu' => {
                                         'runtime' => {
                                                        'suggests' => {},
                                                        'requires' => {},
                                                        'recommends' => {
                                                                          'openssh-client' => 0
                                                                        }
                                                      }
                                       },
              'x_fhem_maintainer' => [
                                       'loredo'
                                     ],
              'abstract' => 'Module to control Node.js package installation and update',
              'version' => 'v0.10.3',
              'x_prereqs_nodejs' => {
                                      'runtime' => {
                                                     'recommends' => {},
                                                     'suggests' => {},
                                                     'requires' => {
                                                                     'node' => '8',
                                                                     'npm' => 0
                                                                   }
                                                   }
                                    },
              'x_vcs' => [
                           '$Id: 42_npmjs.pm 18636 2019-02-19 02:26:02Z loredo $',
                           '42_npmjs.pm',
                           '42',
                           'npmjs',
                           'pm',
                           '18636',
                           '2019-02-19 02:26:02',
                           '2019-02-19',
                           2019,
                           '02',
                           '19',
                           '02:26:02',
                           '02',
                           '26',
                           '02',
                           'loredo',
                           1550543162
                         ],
              'x_prereqs_python' => {
                                      'runtime' => {
                                                     'suggests' => {},
                                                     'requires' => {},
                                                     'recommends' => {}
                                                   }
                                    },
              'x_prereqs_sudo' => {
                                    'runtime' => {
                                                   'suggests' => {
                                                                   'ALL=NOPASSWD: /usr/local/bin/npm install *' => 0,
                                                                   'ALL=NOPASSWD: /usr/bin/npm install *' => 0
                                                                 },
                                                   'requires' => {},
                                                   'recommends' => {
                                                                     'ALL=NOPASSWD: /usr/bin/npm update *' => 0,
                                                                     'ALL=NOPASSWD: /usr/local/bin/npm update *' => 0
                                                                   }
                                                 }
                                  },
              'x_version' => '42_npmjs.pm:v0.10.3-s18636/2019-02-19'
            }
}


Das npmjs.pm Modul nutzt Meta.pm einmal beispielhaft zur Anzeige der Versionsinformation als INTERNAL (siehe Screenshot anbei). Die Paketabhängigkeiten werden noch nicht ausgewertet, sollen aber in einem widerum separaten Installer Modul einmal dem Benutzer verfügbar gemacht werden, um idealerweise diese auch per Klick auflösen zu können.

Was man auch schon machen kann ist die Meta Informationen für alle Module zu laden, entweder für alle, die auch aktuell geladen sind oder auch für die, die derzeit nicht in der FHEM Instanz verwendet werden. Bei Modulen, die noch keinen META.json Pod haben, werden die Informationen so gut es geht aus anderen Quellen zusammengetragen (SVN Info, Dateiname, etc.).

André hat sich das ganze auch gewünscht, weil der für sein geplantes Discovery Modul ebenfalls die Möglichkeit braucht Informationen über ein Modul abzufragen, obwohl es noch nicht geladen wurde.

Das ganze ist jetzt mal eine erste Version, wahrscheinlich ändern sich Funktionsaufrufe nochmal hier und dort. Besser also nichts überstürzen :-)



Gruß
Julian
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #1 am: 20 Februar 2019, 08:57:00 »
In diesem Zusammenhang habe ich noch eine Frage an @Rudi:


Findet sich die aktuelle Major Versionsnummer von FHEM noch woanders als im Makefile, insbesondere in einer Datei, die auch über den Update Mechanismus aktualisiert wird?


Danke und Gruß
Julian
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20174
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #2 am: 20 Februar 2019, 09:03:35 »
Meinst du featurelevel?
"Major Versionsnummer" ist bei dem Entwicklungsmodell von FHEM wenig aussagekraeftig.

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #3 am: 20 Februar 2019, 09:08:43 »
Nein, ich meine nicht Feature Level.


Du hast mir schon einige Male erklärt, dass der Major Versionsstand nicht so aussagekräftig ist. Allerdings wird die Version ja trotzdem auf der Website und auch beim Namen des Debian Paketes genannt, sie spielt also trotzdem eine gewisse Rolle und Menschen (TM) sind halt daran gewöhnt, dass sie die Version, die sie auf der Website finden, dann auch irgendwo in der Software nachkontrollieren können. Zumindest mir leuchtet dann nach wie vor nicht ein, warum es dann überhaupt noch eine Version in diesem Format geben muss. Warum dann nicht sowas wie <2-stelliges Jahr>.<Releasemonat>? Oder eben komplett auf die Versionsnummer verzichten.


Aber solange die Versionsnummer irgendwo herumschwirrt, würde ich sie auch als Meta-Information verstehen und bereitstellen.
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18991
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #4 am: 20 Februar 2019, 09:11:25 »
Naja so wie ich das verstanden habe ist es ja gerade eben keine Versionsnummer, sondern ein Featurelevel. Sprich ab diesem Level gibt es einige "gravierende" Änderungen. Meistens im Standardverhalten von Funktionen in der fhem.pl


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #5 am: 20 Februar 2019, 09:21:32 »
Ok dann frage ich anders: Wo kann ich das aktuell höchste Feature Level auslesen, was der Benutzer einstellen kann?
Ist die Attributauswahl da verlässlich genug?
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline nils_

  • Hero Member
  • *****
  • Beiträge: 1056
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #6 am: 20 Februar 2019, 09:37:35 »
Ok dann frage ich anders: Wo kann ich das aktuell höchste Feature Level auslesen, was der Benutzer einstellen kann?
Ist die Attributauswahl da verlässlich genug?

https://forum.fhem.de/index.php/topic,97528.0.html

das höchste steht doch in $featurelevel, der user kann doch nur weniger einstellen. (spezialfall: 99.99)
so hab ich es verstanden.
viele Wege in FHEM es gibt!
Zustimmung Zustimmung x 1 Liste anzeigen

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18991
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #7 am: 20 Februar 2019, 09:43:56 »
Am besten ist Du liest die globale Variable $featurelevel aus.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #8 am: 20 Februar 2019, 09:47:36 »
Da sind wir genau bei dem Dilemma.
Die globale Variable $featurelevel gibt an, was der User eingestellt hat. Der Inhalt der Datei fhem.pl ist aber trotzdem nicht auf dem Stand von featurelevel 5.7 oder ähnliches.


Ich lese jetzt die Auswahlliste für featurelevel aus $modules{'Global'}{AttrList} aus. Ich wollte nur sicherstellen, dass diese Auswahlliste dann das einzig wahre Indiz dafür ist, welches der aktuellste Featurelevel ist und es dann richtig ist diesen als Major Version zu interpretieren.


Edit: Danke @nils_, den Beitrag kannte ich nicht. Dann macht das ganze jetzt auch Sinn für mich :-)
« Letzte Änderung: 20 Februar 2019, 09:49:08 von Loredo »
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline nils_

  • Hero Member
  • *****
  • Beiträge: 1056
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #9 am: 20 Februar 2019, 09:58:49 »
Edit: Danke @nils_, den Beitrag kannte ich nicht. Dann macht das ganze jetzt auch Sinn für mich :-)
es gibt in letzter zeit gehäuft fragen dazu (warum weiß ich auch nicht....), da hab ich mal einen der letzten beiträge dazu rausgesucht. und dann natürlich mit der hoffnung etwas licht ins dunkel zu bringen (hat ja anscheinend funktioniert :) )
viele Wege in FHEM es gibt!

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #10 am: 20 Februar 2019, 10:07:18 »
es gibt in letzter zeit gehäuft fragen dazu (warum weiß ich auch nicht....)


Meine Interpretation: Viele haben erkannt, dass FHEM inzwischen eine kritische Komponente ist und damit kommen Themen wie Backup und vor allem ein sauberer/einfacher/schneller Restore ins Spiel. Zwangsläufig wird man dann mit Fragen zur Versionierung konfrontiert und stößt dann auch darauf, wie man eigentlich damit bei FHEM umgeht. Bei anderen Projekten kann man einen komplett fixen Versionsstand adressieren und hat dann einen fest definierten Zustand. Das kriegt man bei FHEM derzeit leider nicht so einfach hin (siehe auch Diskussionen zum Docker Image).
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18991
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #11 am: 20 Februar 2019, 10:26:44 »
Daher ja auch mein neues backupME Perl Skript. Ich habe es endlich mal geschafft mein Bash Skript zum Sichern in ein schönes Perl Skipt zu gießen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15733
  • s/fhem\.cfg/configDB/g
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #12 am: 20 Februar 2019, 10:40:36 »
um auf die ursprüngliche Frage zurückzukommen:

Findet sich die aktuelle Major Versionsnummer von FHEM noch woanders als im Makefile, insbesondere in einer Datei, die auch über den Update Mechanismus aktualisiert wird?

Die "Versionsnummer" 5.9, die für die Erzeugung beispielsweise des Namens für das  Debian Paket verwendet wird, kommt ausschließlich aus dem Makefile.
Das Makefile selbst ist - wenn ich es richtig in Erinnerung habe - nicht Bestandteil der ausgelieferten Installationspakete und wird somit auch nicht per Update verteilt.

Du wirst also das Makefile auf einem typischen, aus einem Installationspaket stammenden FHEM System, gar nicht vorfinden.

Bei anderen Projekten kann man einen komplett fixen Versionsstand adressieren und hat dann einen fest definierten Zustand. Das kriegt man bei FHEM derzeit leider nicht so einfach hin (siehe auch Diskussionen zum Docker Image).

Einen fest definierten Zustand (ohne die Nutzung von svn) hast Du bei FHEM immer nur für den Zeitpunkt, an dem Rudi ein neues "Major Release" freigibt, also z.B. 5.8 oder 5.9. Im nightly build des Debian Paketes wird an die Versionsnummer 5.9 deshalb immer noch die svn Rev-Nummer angehängt, die in diesem nightly build enthalten ist.

Vor einer ähnlichen Frage wie der von Dir gestellten, standen Markus und ich im Rahmen des Neubaus der FHEM Statistik. "Wie bekommen wir raus, wie "alt" eine FHEM Installation beim Anwender ist?"

Die REV Id einer FHEM Installation befindet sich in der ersten Zeile der Datei /opt/fhem/controls_fhem.txt - und diese Datei wird per Update ausgeliefert!
Aus dieser Information kann man feststellen, wann die Installation zum letzten Mal ein Update erfahren hat, somit steht auch fest, welches "Major Release" die Installation hat.
« Letzte Änderung: 20 Februar 2019, 10:57:54 von betateilchen »
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof
Informativ Informativ x 1 Liste anzeigen

Offline nils_

  • Hero Member
  • *****
  • Beiträge: 1056
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #13 am: 20 Februar 2019, 11:14:38 »
Bei anderen Projekten kann man einen komplett fixen Versionsstand adressieren und hat dann einen fest definierten Zustand. Das kriegt man bei FHEM derzeit leider nicht so einfach hin (siehe auch Diskussionen zum Docker Image).
da kannste dich ja eigentlich nur auf die svn-revision beziehen, um einen definierten zustand aller dateien zu diesem zeitpunkt adressieren zu können.
viele Wege in FHEM es gibt!

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #14 am: 10 März 2019, 15:52:03 »
Ich habe das Meta.pm Paket jetzt denke ich in einem solchen Status, dass man damit etwas anfangen kann.
Als erster Showcase habe ich begonnen den FHEM Installer zu schreiben, mit dem man die Metadaten entsprechend auswerten kann.


@justme1968/André, wir könnten jetzt beispielsweise auch die Node.js Abhängigkeiten als Metadaten in deine Module hängen und entsprechend mit anzeigen. Das npmjs Modul kann dann entsprechend dynamisch die Installationsliste generieren anstatt wie bisher statisch über einen Hash, der bei mir im Modul liegt.
Außerdem kannst du glaube ich anfangen dein Service Discovery Modul hervorzukramen :-)


@Rudi @Jörg und andere: Mir erschien es sinnvoll auch einige Compliance Dinge mit anzuzeigen bzw. zu verlinken (z.B. Copyright, Datenschutzerklärung).
Natürlich kann man die Links ändern, aber derzeit gibt es z.B. keine dedizierte Datenschutzerklärung für FHEM als Software. Ggf. bitte einen gesonderten Thread für die inhaltliche Diskussion zu Compliance/Privacy/Legal Themen aufmachen, wenn ihr euch dabei angesprochen fühlt.




Gruß
Julian
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20174
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #15 am: 10 März 2019, 16:15:51 »
Zitat
derzeit gibt es z.B. keine dedizierte Datenschutzerklärung für FHEM als Software.
FHEM sammelt keine Daten im Auslieferungszustand, nur wenn man explizit "attr global sendStatistics" setzt.
Braucht man trotzdem eine Datenschutzerklaerung? Warum? Was muss drinstehen?
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #16 am: 10 März 2019, 23:23:37 »
FHEM sammelt keine Daten im Auslieferungszustand, nur wenn man explizit "attr global sendStatistics" setzt.
Braucht man trotzdem eine Datenschutzerklaerung? Warum? Was muss drinstehen?


Dann fällt die Erklärung wohl sehr kurz aus :-)
"Brauchen" - ich würde sagen ja, der Transparenz wegen. Ich vermute da genügen 3 Sätze, in denen erklärt wird, dass keinerlei Daten übermittelt werden.
Da wir das ganze pro Modul betrachten und Update schon ein eigenes Command-Modul ist, kann dort auch eine separate Datenschutzerklärung hinterlegt oder verlinkt werden. In der CommandRef ist zwar ein Hinweis, aber der ist nicht eindeutig unter dem Schlagwort Datenschutz/Privacy auffindbar. Auf der Modul-Infoseite vom Installer gäbe es dafür einen prominenten Platz. Du kannst die Daten auch selbst in 98_update.pm pflegen, indem du dort einen META.json Pod anlegst. Ich kann da gerne mal einen Vorschlag fabrizieren, den du übernehmen könntest.


Für fhem.pl pflege ich das gerade direkt in Meta.pm, aber auch dieser Pod könnte früher oder später nach fhem.pl, wenn gewünscht.
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18912
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #17 am: 11 März 2019, 20:38:01 »
habe eben angefangen das ganze für das alexa modul mal einzubauen.

wenn ich alles richtig verstehe brauche ich eigentlich nur return FHEM::Meta::InitMod( __FILE__, $hash ); am ende von Initialize und einen solchen block:               
=for :application/json;q=META.json 39_alexa.pm
{               
  "abstract": "Module to control the FHEM/Alexa integration",
  "x_lang": {   
    "de": {     
      "abstract": "Modul zur Konfiguration der FHEM/Alexa Integration"
    }           
  },           
  "keywords": [
    "fhem-mod",
    "fhem-mod-device",
    "alexa",
    "alexa-fhem",
    "nodejs",   
    "node"   
  ],           
  "release_status": "stable",
  "x_fhem_maintainer": [
    "justme1968"   
  ],           
  "x_fhem_maintainer_github": [
    "justme-1968"
  ],           
  "x_prereqs_nodejs": {
    "runtime": {     
      "requires": {   
        "node": 8.0, 
        "alexa-fhem": 0     
      },             
      "recommends": {
      },             
      "suggests": {   
      }               
    }                 
  }
}
=end :application/json;q=META.json
im pos teil.

richtig?

das scheint so weit zu funktionieren.

was mir aber auffällt: die svn version wird dann zum patchlevel der version: v0.0.18863. schöner wäre einfach nur v18863. oder vielleicht noch besser etwas in der art: vSVN-18863.

was auch noch etwas unhandlich ist: abstract und summary enthalten eigentlich das gleiche. lässt sich vermeiden das zwei mal hin zu schreiben?

das Installer modul zeigt die nodejs info noch nicht an. ist das korrekt?

wie soll mit den indirekten node abhängigkeiten umgegangen werden? ich habe ja oben nur alexa-fhem aufgeführt. das ist die einzige direkte abhängigkeit. ich denke das ist so gedacht?



das discovery modul kommt... aber das dauert noch etwas :)
« Letzte Änderung: 11 März 2019, 20:42:12 von justme1968 »
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #18 am: 11 März 2019, 22:07:46 »
habe eben angefangen das ganze für das alexa modul mal einzubauen.

wenn ich alles richtig verstehe brauche ich eigentlich nur return FHEM::Meta::InitMod( __FILE__, $hash ); am ende von Initialize und einen solchen block [...] im pos teil.

richtig?


Ja, das ist der essentielle Teil.




Edit: Du kannst (und solltest) noch den Pod
  =encoding utf8
am Anfang hinzufügen, wenn du im Text entsprechende Zeichen verwendest. Ansonsten wird Latin1 verwendet (so wie es FHEM an der Stelle selbst sonst auch tut).



Wenn man das Modul schon als Perl Package erstellt hat, kann man in DefFn außerdem die Modulversion aus den Metadaten setzen:


use version 0.77; our $VERSION = FHEM::Meta::Get( $hash, 'version' ); # seems it must be a one-liner


Dann kann standardkonform per MODULNAME->VERSION() die Version abgefragt werden. Soweit ich weiß nutzen das einige Perl Module. Eigentlich sollte damit auch die Angabe der Versionsnummer bei einem "use MODULNAME 1.234567" möglich sein, aber das scheint wohl nicht zu klappen. Bisher ist mir nichts anderes eingefallen, ohne dass man die Versionsnummer doppelt pflegen muss.


Außerdem kann man in DefFn noch



    return $@ unless ( FHEM::Meta::SetInternals($hash) );


einfügen. Derzeit bewirkt das, dass FVERSION als Internal gesetzt und auch bei einem Modul Reload aktualisiert wird. Darin stehen dann die essentiellen Infos zu einem Modul in der Form:


<Dateiname>:<Version>[-s|gCOMMIT]/<Release Date>


Also z.B.
98_Installer.pm:v0.0.1-s18855/2019-03-11


So ähnlich hat Rudi das auch bereits für fhem.pl im global Attribut "version" verwendet.
Die ergänzende Notation der Version ist an den Output von 'git describe --tags --dirty' angelehnt. "-s" steht dabei für Subversion, "-g" würde für Git stehen.
Das ist ein Standard, der einem inzwischen häufig so begegnet (Git sei Dank). Er findet auch beim Docker Image Anwendung.


was mir aber auffällt: die svn version wird dann zum patchlevel der version: v0.0.18863. schöner wäre einfach nur v18863. oder vielleicht noch besser etwas in der art: vSVN-18863.


Das verwendete Format ist hier spezifiziert:
https://metacpan.org/pod/CPAN::Meta::Spec#Version-Formats


Ich habe mich hier für die Dotted-integer Variante entschieden (also dem Semantic Versioning), weil es auch dem entspricht, was viele FHEM Modulentwickler intern in ihren Modulen bereits anwenden (und auch selbst in das Internal VERSION schreiben). Meta.pm extrahiert aus dem Sourcecode eine mögliche semantische Versionsnummer (Erfolgsquote geschätzt 99%). Die Art, wie die Version extrahiert wurde, ist in $modules{<TYPE>}{META}{x_file}[7] abrufbar.
Zur einfacheren Einsicht der Roh-Metainformationen habe ich gerade noch einen Getter zzGetMETA.json in den FHEM Installer eingebaut.

EDIT: Nachdem ich jetzt nochmal darüber nachgedacht habe, habe ich es jetzt hier wie folgt geändert:
Sofern der Modulautor keine semantische Version hinterlegt hat, wird eine Dezimalversion der Form 0.<COMMIT> generiert (also ohne "v" vorne und nur als Fließkommazahl). Der Modulautor kann entscheiden über META.json zusätzlich eine semantische Versionierung vorzunehmen, welche bei einem externen Repository zwingend erforderlich ist, da keine VCS Informationen aus $Id$ auslesbar sind. In diesem Fall wird die Version als "v1.2(.\d+)*" angelegt.
Die Dezimalversion als <COMMIT> oder <COMMIT>.0 darzustellen geht nicht, weil man ansonsten bei einem späteren Wechsel zur semantischen Versionierung nicht kompatibel sein kann (bzw. eine enorm hohe Major Version wie v18234.0.0 wählen müsste...).


was auch noch etwas unhandlich ist: abstract und summary enthalten eigentlich das gleiche. lässt sich vermeiden das zwei mal hin zu schreiben?


Summary ist im META.json nicht enthalten, die oben verlinkte Spezifikation sieht das Datenfeld 'abstract' für die Zusammenfassung vor. 'abstract' wird aus dem =summary Pod gefüllt, wenn es nicht vorhanden ist. Man kann es aber natürlich auch separat pflegen und befüllen. Für FHEM 3rd-Party Module, die nicht im Subversion gehostet sind, ist vorgesehen, dass alle Metadaten über das META.json angegeben werden können. Ob das mal für alle FHEM Module möglich sein soll, lasse ich offen.
Der Grundsatz ist: Meta.pm extrahiert alle Infos und nimmt diese, die im META.json fehlen. Ansonsten haben die Daten aus META.json Priorität.
Es kann aber sinnvoll sein, dass diejenigen Datenfelder, die die CPAN::Meta::Spec als zwingend erforderlich vorsieht, trotzdem immer im META.json Pod mit anzugeben, denn dann wäre das File als solches vollständig und Standard konform und muss nicht erst über (ein laufendes) FHEM generiert werden.


das Installer modul zeigt die nodejs info noch nicht an. ist das korrekt?


Du meinst die Prereqs? Ja, das ist richtig. Ich wollte mir die Arbeit erst machen, wenn ich nicht mehr der einzige bin, der daran arbeitet. Baue ich ein. Ich bin mir aber noch nicht sicher, wie ich die Brücke zum npmjs.pm Modul schlagen will, mal sehen.
Du kannst aber über den neuen Getter schon sehen, ob alles richtig drin ist.


wie soll mit den indirekten node abhängigkeiten umgegangen werden? ich habe ja oben nur alexa-fhem aufgeführt. das ist die einzige direkte abhängigkeit. ich denke das ist so gedacht?


Ja, das ist so gedacht. Es bleibt dir als Modulautor überlassen die richtigen Abhängigkeiten zu nennen. Der Installer wird natürlich bei jeder auf das Vorhandensein prüfen und später auch die Installation je nach Importance vornehmen oder vorschlagen. Da der npm Paketmanager aber ja alles andere erledigt, brauchst du nur alexa-fhem angeben und managt alle Node Abhängigkeiten lieber in deinem eigenen npm Paket.


das discovery modul kommt... aber das dauert noch etwas :)


Macht nichts, ich wollte dich nur etwas ermutigen  :)
Und natürlich wollte ich wissen, ob dein Anwendungsfall nun damit auch abgedeckt werden kann, oder ob noch etwas fehlt.
« Letzte Änderung: 12 März 2019, 09:43:48 von Loredo »
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18912
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #19 am: 13 März 2019, 11:00:53 »
so weit so gut. ich würde dann die nächste alexa modul version mit der meta info einchecken.


die änderung bei der version finde ich gut. aber ich glaube direkt die svn version zu verwenden geht schon :) :

- für 'normale' fhem module die im svn sind ist die svn version doch die einzig relevante. das so ein modul
  auf semver wechselt ist doch eher unwarscheinlich. d.h. es macht nichts wenn es zwei unterschiedliche systeme sind.

- ich möchte auf jeden fall vermeiden für die svn module noch mal eine zusätzlich version zu pflegen die von hand
  geändert werden muss. das wird früher oder später vergessen.


ich möchte ganz allgemein nur vermeiden irgend etwas an mehr als einer stelle einzugeben. das gibt früher oder später zweideutigkeiten.


Zitat
Du kannst aber über den neuen Getter schon sehen, ob alles richtig drin ist.
das get hat bei meinem ersten versuch nur die perl abhängigkeiten angezeigt. node noch nicht. oder war das da noch nicht drin?


für das discovery modul sollte das bei den default protokollen mit  einem eigenen eintrag im json so gehen. für die custom protokolle bei denen ein oder zwei funktionen deklariert werden müssen vermutlich auch. teste ich noch.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #20 am: 13 März 2019, 12:40:11 »
so weit so gut. ich würde dann die nächste alexa modul version mit der meta info einchecken.

Cool  8)

die änderung bei der version finde ich gut. aber ich glaube direkt die svn version zu verwenden geht schon :) :

- für 'normale' fhem module die im svn sind ist die svn version doch die einzig relevante. das so ein modul
  auf semver wechselt ist doch eher unwarscheinlich. d.h. es macht nichts wenn es zwei unterschiedliche systeme sind.

- ich möchte auf jeden fall vermeiden für die svn module noch mal eine zusätzlich version zu pflegen die von hand
  geändert werden muss. das wird früher oder später vergessen.

So wie es jetzt gerade ist, muss man keine Version manuell pflegen - aber man KANN ("Alles kann, nichts muss...").
Man kann jederzeit wechseln, wenn man sich irgendwelche Vorteile davon verspricht - die Gründe für semver haben ja einige Modulautoren für sich schon bewertet und andere bleiben eben dabei, dass die Revision der Version entspricht. Einzig wird die Version eben als 0.XXXX repräsentiert, aber damit kann man denke ich dann leben - man muss ja nix selbst machen.

ich möchte ganz allgemein nur vermeiden irgend etwas an mehr als einer stelle einzugeben. das gibt früher oder später zweideutigkeiten.

Wie gesagt, es ist alles optional, wenn man mit dem SVN arbeitet, nichts ändert sich, wenn man das nicht möchte.
Ich arbeite noch daran, dass man die in META.json/Prereq definierten Perl Abhängigkeiten auch direkt am Beginn des eigenen Moduls für den Import dieser Pakete verwenden kann, damit man dann auch hier nicht doppelt pflegen muss. Da würde sich dann nur der Ort ändern, wo man eben seine Perl Module inkludiert und gleichzeitig dokumentiert man da seine Abhängigkeiten. Aber auch hier: Wer das nicht will, für dessen Modul gibt es eben keine auswertbaren Abhängigkeiten und der User kann auf das automatische Analyseverfahren zurückgreifen. Was dann aber eben ungenau sein kann und auch natürlich Performance frisst - nicht unerheblich, wenn der Installer später einmal eine ganze fhem.cfg auswertet und prüft, was so alles fehlt. Da bleibt es dem Modulautor überlassen wie wichtig ihm die Performance an dieser Stelle ist (bzw. was er den Nutzern zumuten will).

Wäre dann wahrscheinlich auch für dein Discovery Modul relevant, weil du da ja wahrscheinlich dann auch alle Metadaten von allen Modulen vorladen möchtest, um anschließend zu schauen, welches Modul welches Protokoll unterstützt. Aber damit ein Modul die Discovery Funktion anbieten kann, muss der Modulautor ja dann ohnehin das META.json anlegen und die Hoffnung ist natürlich, dass man dann auch seine anderen Abhängigkeiten mit reinschreibt. Im Grunde ist das auch kein Hexenwerk, denn wenn man selbst nicht sicher ist, kann man auch einfach die Ausgabe von "get zzGetMETA.json" als Vorlage nehmen (abzüglich einiger Knoten darin, die eh überschrieben würden - z.B. x_file).

das get hat bei meinem ersten versuch nur die perl abhängigkeiten angezeigt. node noch nicht. oder war das da noch nicht drin?

Es ist alles mit im META.json drin, was du selbst im Pod hinterlegt hast - also dann auch deine Node Abhängigkeiten. Ich werte diese aber in 98_Installer noch nicht aus.
Du musst außerdem bedenken, dass die Metadaten zur Laufzeit aus Performancegründen nur ein einziges Mal eingelesen werden. Wenn du also Änderungen an den Metadaten machst, dann werden diese erst in FHEM verfügbar, wenn du FHEM neu gestartet hast. Aktuell habe ich noch keinen Reload-Mechanismus in 98_Installer eingebaut, aber es ist in Meta.pm schon entsprechend vorgesehen (du kannst also auch aus deinem eigenen Modul heraus deine eigenen Metadaten jederzeit neu laden, wenn es einen Grund für dich gibt).

für das discovery modul sollte das bei den default protokollen mit  einem eigenen eintrag im json so gehen. für die custom protokolle bei denen ein oder zwei funktionen deklariert werden müssen vermutlich auch. teste ich noch.

Ja, es ist ja nur ein weiterer Baum im META.json :-)
Namen kannst du da frei wählen, allerdings beachten, dass die Schreibweise immer klein ist und weil es nicht in CPAN::Meta::Spec spezifiziert ist, am obersten Baumende mit "x_" beginnen muss.
« Letzte Änderung: 13 März 2019, 12:58:06 von Loredo »
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3601
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #21 am: 13 März 2019, 22:37:30 »
Hallo Julian,

habe deine Entwicklung gespannt verfolgt und bin auch daran gegangen mich ein bisschen in die Problematik Packages und Meta.pm/Installer.pm einzuarbeiten.
Tolle Sache und ich bin gespannt was noch dabei herauskommt.  :)

Ich habe mal klein angefangen und ein Modul aus meinem contrib auf Package-Verwendung umgestellt und fit für Meta.pm gemacht. Funktioniert auch alles soweit und Installer.pm bringt auch die erwarteten Informationen.

Zwei Fragen habe ich aber.

Das Internal FVERSION wird nicht gesetzt obwohl    "version": "v1.2.3",  im pod eingetragen ist.  .FhemMetaInternals ist "1". Kann es sein, dass FVERSION erst dann gesetzt wird wenn das Modul eingecheckt ist bzw. es in der MAINTAINER.txt steht ?
Habe deinen Code versucht zu verstehen und bin deswegen auf die MAINTAINER.txt gekommen. Kann mich aber auch absolut irren  ;) ... deswegen diese Frage.

Dann hast du vlt. zu folgendem eine Idee.
Ich verwende in meinen Modulen einen für mich hilfreichen Mechanismus zur Versionsverwaltung über einen Hash:

# Versions History intern
our %SMAPortal_vNotesIntern = (
  "1.3.0"  => "13.03.2019  change module to use package name SMA-Portal ",
  "1.2.3"  => "12.03.2019  make ready for 98_Installer.pm ",
  "1.2.2"  => "11.03.2019  new Errormessage analyze added, make ready for Meta.pm ",
 .....

Über eine Funktion:

 $hash->{VERSION} = (SMAPortal_sortVersion("desc",keys %SMAPortal_vNotesIntern))[0];

setze ich dann das Internal VERSION. Das hat für mich den Charme, dass ich immer weiß was ich mit einer internen Version geändert habe, auch wenn diese Version nicht eingecheckt wurde sondern erst die übernächste etc.
Jetzt suche ich eine Möglichkeit nicht doppelt pflegen zu müssen und diesen Wert aus %SMAPortal_vNotesIntern irgendwie Installer.pm zur Verfügung zu stellen. Vllt. durch Überschreiben von "x-version" im META-Hash.
Siehst du evtl. eine Möglichkeit ?

Grüße
Heiko
« Letzte Änderung: 13 März 2019, 22:56:28 von DS_Starter »
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, Watches
Kaffeekasse: https://www.paypal.me/HMaaz

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #22 am: 13 März 2019, 23:26:05 »
Das Internal FVERSION wird nicht gesetzt obwohl    "version": "v1.2.3",  im pod eingetragen ist.  .FhemMetaInternals ist "1". Kann es sein, dass FVERSION erst dann gesetzt wird wenn das Modul eingecheckt ist bzw. es in der MAINTAINER.txt steht ?


Nein, FVERSION wird auch ohne MAINTAINER.txt gesetzt. Allerdings wird FVERSION aktuell nur auf zwei Arten gesetzt:


1. Durch den Installer, wenn er die Metadaten erzeugt. Bei Modulen, die in Verwendung sind, sofort, auch nach einem Neustart. Bei Modulen, die nicht in Verwendung sind, nur beim lesen der Metadaten.
2. Durch Aufruf von FHEM::Meta::SetInternals($hash) aus der DefFn, sprich auf expliziten Wunsch des Modulautors. Dabei wird auch das Internal .FhemMetaInternals=1 gesetzt. Es sorgt dafür, dass bei einem Reload des Moduls, bei dem fhem.pl ja dann X_Initialize() wieder aufruft und bei dem du dann ja FHEM::Meta::InitMod() aufrufst, dann auch FVERSION für alle Geräte entsprechend aktualisiert wird. Wenn du also selbstständig einfach nur .FhemMetaInternals=1 setzt, dann müsstest du anschließend auch deine Moduldatei neu laden. Macht aber nicht so viel Sinn, oder :-)
Meta.pm handhabt das für dich transparent. Für Module, die tatsächlich ein eigenständiges Package sind und die in ihrem eigenen Namespace auch ein "use FHEM::Meta" machen (zusätzlich zum "use FHEM::Meta" im main Context), könnte ich natürlich auch implizit für den Modulautor FHEM::Meta::SetInternals() aufrufen. Ich war mir aber a) nicht sicher, ob FVERSION dann gewollt ist und b) sind viele Module ja keine eigenen Packages bisher. Wenn der Benutzer den Installer benutzt, gehe ich einfach davon aus, dass er dann diese Funktion so will. Aber man kann Meta.pm natürlich auch ohne den Installer verwenden und da bleibt es aktuell dem Modulautor überlassen, was er damit anfängt:

1. Er könnte nur die META.json Daten hinterlegen. Die sind dann bei Bedarf auslesbar, sind aber nicht automatisch im Speicher (es sei denn der User verwendet den Installer).
2. Er könnte zusätzlich auch "use FHEM::Meta" ausführen und in X_Initialize() "return FHEM::Meta::InitMod( __FILE__, $modHash );" aufrufen, um beim laden des eigenen Moduls auch die Metadaten mit in den %modules Hash zu laden.
3. Er könnte zusätzlich entscheiden, dass FVERSION auch im Device Hash angezeigt werden soll, indem er in der DefFn FHEM::Meta::SetInternals($hash) aufruft.
4. Er könnte zusätzlich entscheiden, dass er im Falle eines echten Perl Packages auch "our $VERSION" setzt: "use version 0.77; our $VERSION = FHEM::Meta::Get( $hash, 'version' );", damit dann auch __PACKAGE__->VERSION() als Funktionsaufruf für sein Modul funktioniert.

Die FHEM Module npmjs.pm und Installer.pm machen das beide schon so, das FHEM Package Meta.pm (als Device-loses Modul sozusagen) macht es ebenfalls für sich selbst.

Ich verwende in meinen Modulen einen für mich hilfreichen Mechanismus zur Versionsverwaltung über einen Hash:

# Versions History intern
our %SMAPortal_vNotesIntern = (
  "1.3.0"  => "13.03.2019  change module to use package name SMA-Portal ",
  "1.2.3"  => "12.03.2019  make ready for 98_Installer.pm ",
  "1.2.2"  => "11.03.2019  new Errormessage analyze added, make ready for Meta.pm ",
 .....

Über eine Funktion:

 $hash->{VERSION} = (SMAPortal_sortVersion("desc",keys %SMAPortal_vNotesIntern))[0];

setze ich dann das Internal VERSION.


Wenn du FVERSION setzt, brauchst du VERSION nicht mehr selbst zu setzen, sofern du die Version dann über das META.json bereitstellst.


Es ist weiterhin angedacht, dass im META.json auch eine Änderungshistorie analog zu HISTORY und CHANGED hinterlegt werden kann. Das soll vor allem auch dazu verleiten, dass Modulautoren von er Unsitte abkommen, ihre Änderungen in irgendeiner Freitextform als Kommentarzeilen am Anfang der Datei zu pflegen ;-)
Dort gibt es einige Nasen, die z.B. die Historie chronologisch von oben nach unten geschrieben und dabei auch eine Versionsnummer angegeben haben, weshalb ich dann aber beim versuch diese auszulesen immer auf die allererste Version statt der letzten Version stoße (einige andere haben es hingegen besser gemacht und schreiben die neuste Änderung zuerst hin - immerhin).


Die genaue Notation muss ich mir noch überlegen, aber es wird ähnlich sein wie du dir deinen Hash auch gebaut hast, sprich einen unmittelbaren Bezug zu einer bestimmten Versionsnummer und evtl. ein Datum, etc. Klar ist dann aber auch, dass diese Daten dann tatsächlich eine Momentaufnahme darstellen und somit danach unveränderbar sein sollen. Soll heißen, die Versionsnummer wird im Attribut "version" weiter hochgezählt, aber im History Zweig muss die Version zusätzlich gepflegt werden, damit sie als Historie erhalten bleiben kann.
Das hat auch damit zu tun, dass die CPAN::Meta::Spec keine Vermischung zwischen eigentlicher Versionskontrolle und der Historie bzw. Dokumentation von Änderungen vorsieht. Ich würde diese auch nicht mischen wollen, denn wie auch bei FHEM's HISTORY oder CHANGE gibt es nicht immer einen Grund auch eine Änderung zu dokumentieren.


Ich denke also, dass dies deine Anforderung dann wird abdecken können. Im META.json hinterlegt ist es auch schnell, wenn man sich auf ein Datenformat verständigt hat. Die Anzeige im Installer ist dann noch eine andere Geschichte ;-)


----


Davon abgesehen gibt es noch einige weitere Gedanken im Bezug auf lokal veränderte Moduldateien, die neuer sind als die, die über das Update kommen.
Ich habe noch nicht fertig analysiert, wie das FHEM Update Kommando nun tatsächlich festlegt, ob eine Datei geändert wurde, oder nicht. Die selbe Logik soll aber hier dann auch dazu dienen, dass sowohl in FVERSION als auch im Installer deutlich auf eine lokale Änderung hingewiesen wird.
Es ist noch nicht ganz entschieden, ob ich den Update Mechanismus im Installer neu implementieren werde oder ganz/teilweise auf den althergebrachten Update Befehl zurückgreifen werde. Das Ausnahmehandling über das globale Attribut, dass lokale Änderungen nicht überschrieben werden, ist mir so zu umständlich und das soll der Installer anders machen.
« Letzte Änderung: 13 März 2019, 23:40:00 von Loredo »
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3601
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #23 am: 13 März 2019, 23:45:05 »
Danke Julian für deine Erläuterungen.
 "our $VERSION" habe ich auch schon gesetzt und funktioniert ... man kann im FHEMWEB  {SMAPortal->VERSION()} absetzen und bekommt die Version angezeigt. Klappt allerdings auch ohne "use version 0.77;" vorher.  Wozu braucht man das ?

 FHEM::Meta::SetInternals($hash)  werde ich mal implementieren und den Rest durcharbeiten.

LG,
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, Watches
Kaffeekasse: https://www.paypal.me/HMaaz

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #24 am: 13 März 2019, 23:55:01 »
Klappt allerdings auch ohne "use version 0.77;" vorher.  Wozu braucht man das ?


Naja, das klappt, weil dein Modul kein eigenes Perl Package ist und woanders im main Kontext schon "use version 0.77" aufgerufen wurde. Aber darauf solltest du dich eben nicht verlassen, da kommt es ja auch auf die Ladereihenfolge an und so ;-) Ein mehrfaches "use" macht aber nichts speichertechnisch, soweit ich weiß - einmal geladen ist geladen, es werden nur die vom Modul exportierten Subroutinen in den eigenen Kontext verlinkt (sofern noch nicht vorhanden).
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3601
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #25 am: 14 März 2019, 00:02:27 »
Hmm, kein eigenes Package sagst du.
Zugegeben, ich fange erst damit an mich etwas mit Packages zu üben, aber der nachfolgende Ausschnitt sollte doch für die Package Definition richtig sein (Läuft auch).

package main;
use strict;
use warnings;

###############################################################
#                  SMAPortal Initialize
# Da ich mit package arbeite müssen für die jeweiligen hashFn
# Funktionen der Funktionsname und davor mit :: getrennt der
# eigentliche package Name des Modules
###############################################################
sub SMAPortal_Initialize($) {
  my ($hash) = @_;

  $hash->{DefFn}     = "SMAPortal::SMAPortal_Define";
  $hash->{UndefFn}   = "SMAPortal::SMAPortal_Undefine";
  $hash->{DeleteFn}  = "SMAPortal::SMAPortal_Delete";
  $hash->{AttrFn}    = "SMAPortal::SMAPortal_Attr";
  $hash->{SetFn}     = "SMAPortal::SMAPortal_Set";
  $hash->{GetFn}     = "SMAPortal::SMAPortal_Get";
  $hash->{AttrList}  = "cookieLocation ".
                       "cookielifetime ".
                       "detailLevel:1,2,3,4 ".
                       "disable:0,1 ".
                       "getDataRetries:1,2,3,4,5,6,7,8,9,10 ".
                       "interval ".
                       "showPassInLog:1,0 ".
                       "timeout ".
                       "userAgent ".
                       $readingFnAttributes;

return FHEM::Meta::InitMod( __FILE__, $hash );           # für Meta.pm (https://forum.fhem.de/index.php/topic,97589.0.html)
}

###############################################################
#                    Begin Package
###############################################################
package SMAPortal;
use strict;
use warnings;
use GPUtils qw(:all);                   # wird für den Import der FHEM Funktionen aus der fhem.pl benötigt
use POSIX;
use FHEM::Meta;
use Data::Dumper;
use Blocking;
use Time::HiRes qw(gettimeofday);
use LWP::UserAgent;
use HTTP::Cookies;
use JSON qw(decode_json);
use MIME::Base64;

# Run before module compilation
BEGIN {
  # Import from main::
  GP_Import(
      qw(
          attr
          AttrVal
          addToDevAttrList
         ....

Habe bei Installer.pm und Cooltux gespickt  ;)
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, Watches
Kaffeekasse: https://www.paypal.me/HMaaz
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #26 am: 14 März 2019, 00:14:30 »
Jopps, da hast du ein eigenes Package - idealerweise nennst du es beim vollen Namen FHEM::SMAPortal, es soll sich doch zu FHEM dazugehörig fühlen und nicht so alleine  ;D
Voraussetzung ist, dass es auch in einem Verzeichnis mit dem selben Name (in diesem Fall "FHEM") liegt - ist ja hier der Fall dann.
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3601
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #27 am: 14 März 2019, 00:18:11 »
Jo, mach ich.
Wie gesagt ich übe an diesem Modul jetzt mal mit Packages und deinem Meta/Installer.  :D
Schaue morgen mal weiter.

Gute Nacht Julian ... feine Sache das  :)

Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, Watches
Kaffeekasse: https://www.paypal.me/HMaaz
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #28 am: 14 März 2019, 15:59:46 »
Bitte meine Emailadresse umgehend entfernen.
Ich weiss auch nicht, ob der Link auf dem Verein "rechtens" ist, abgestimmt ist es jedenfalls nicht.

Rudi,

genau diese Abstimmung geschieht in diesem Thread. Ich habe speziell dich explizit angesprochen und um Review gebeten und kann daher deinen verärgerten Unterton absolut nicht nachvollziehen.
Auch hatte ich hier ganz explizit gesagt, dass du als Maintainer der jeweiligen Datei selbstverständlich auch das META.json rüber kopieren kannst und ich es derzeit für fhem.pl lediglich deshalb pflege, weil es ansonsten die Entwicklung behindert. Lass mich wissen, wenn du die Daten übernommen hast und ich passe das entsprechend an.

Deine Email Adresse entferne ich mit dem nächsten Update der Datei Meta.pm.

Ich weiss auch nicht, ob der Link auf dem Verein "rechtens" ist, abgestimmt ist es jedenfalls nicht.

Ich habe explizit in oben bereits erwähntem Beitrag nachgefragt und sogar das Schlagwort "Copyright" erwähnt. Ich denke der Verein gehört zu FHEM jetzt dazu, so habt ihr euch entschieden. Warum man diesen in einer Art "Impressum" beim zentralen FHEM/Global Modul nicht erwähnen sollte, erschließt sich mir nicht. Kann man gerne entfernen, _ich_ habe da nichts davon das drin zu behalten.

Die Privacy Erklaerung ist fraglich: auf der verlinkten Seite geht es um die fhem.de Seiten, und nicht um FHEM als Software.

Ich verweise abermals auf oben genannten Beitrag, bei dem ich auch explizit neben dich auch Jörg als Datenschutzbeauftragten angesprochen habe. Für eine Nicht-Reaktion kann ich nichts, zumal du hinterher auch geantwortet hast und die Themen dann aber offenbar ignoriert hast. Für Ignoranz kann ich keine Verantwortung übernehmen, tut mir leid.

Und ob man diese Version von fhem.pl als "stable" bezeichnen kann, muss auch noch nachgewiesen werden.

Dieses Datenfeld gehört zur offiziellen CPAN::Meta::Spec und ist daher zu befüllen. Wenn du meinst, dass fhem.pl noch in die Kategorie "testing" oder "unstable" fällt, dann hinterlege ich das gerne in META.json für fhem.pl, sofern du den Pod nicht selbst pflegen möchtest.
Noch eine Bemerkung zur Deutung: Das Datenfeld gibt nicht zwangsläufig den tatsächlichen Stabilitätsgrad einer Software an, sondern den gewollten Zustand und ist teil des Lifecycle Managements zur Veröffentlichung von Software.
« Letzte Änderung: 14 März 2019, 16:07:54 von Loredo »
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20174
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #29 am: 14 März 2019, 17:02:21 »
Zitat
Für Ignoranz kann ich keine Verantwortung übernehmen, tut mir leid.
Nach meiner Erfahrung fuehrt "Opt-Out" haeufig zu Aerger. Ich frage mich, warum diese Angaben notwendig sind, und wieso ich ploetzllch eine Menge an Aufgaben bekomme.

Zitat
Dieses Datenfeld gehört zur offiziellen CPAN::Meta::Spec und ist daher zu befüllen.
Alternativ verwendet man das Modul nicht. fhem.pl ist weder stable noch unstable oder testing sondern wird per "continuous development" gebaut. Ich habe lange gegen Stable und Development branches gekaempft, und faende es nicht gut, wenn sie durch eine Hintertuer eingefuehrt werden.
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #30 am: 14 März 2019, 17:13:50 »
Nach meiner Erfahrung fuehrt "Opt-Out" haeufig zu Aerger. Ich frage mich, warum diese Angaben notwendig sind, und wieso ich ploetzllch eine Menge an Aufgaben bekomme.

Du hast überhaupt gar keine Aufgaben bekommen. Soweit ich weiß, bist du der eingetragene Maintainer für fhem.pl und in dieser Funktion habe ich dich darüber informiert, dass ein anderes Modul dessen Daten analysiert und deren Ergebnisse zur Kenntnis und Durchsprache vorgelegt. Du kannst da frei entscheiden, wie du deine Rolle als Maintainer definierst und wahrnimmst.
Dafür, dass ich offenbar bisher ungeklärte Fragestellungen des FHEM e.V. bei dir aufgeworfen habe, kann ich nichts. Ich nehme also zur Kenntnis, dass Transparenz und eine gewisse Rechtssicherheit für dich und den FHEM e.V. nicht von Bedeutung sind. Das ist absolut in Ordnung und hier ja nun auch dokumentiert.


Für mich bleibt aber die Frage: Wo ist denn dein "Continuous Development", wenn man nicht einen Arbeitsstand einchecken darf, um ihn dann stetig weiterzuentwickeln? Ich habe ja überhaupt nichts in Stein gemeißeltes getan und dich auch brav nach Rückmeldung gefragt. Sicherlich hätte ich auch hier einige Tausend Zeilen Quellcode hochladen können und dann nächstes Jahr nochmal nachfragen, ob sich das wer angesehen hat... ich handelte und handele nach bestem Wissen und Gewissen und wenn ich mich einmal getäuscht haben sollte, dann kann ich das ja im Rahmen des Continuous Development Gedanken jederzeit und direkt korrigieren.

Alternativ verwendet man das Modul nicht. fhem.pl ist weder stable noch unstable oder testing sondern wird per "continuous development" gebaut.


Korrekt. Niemand wird gezwungen Meta.pm in sein Modul einzubauen oder 98_Installer zu verwenden. Das habe ich immer betont.
Aber wie mir scheint hast du dich gar nicht über CPAN::Meta::Spec informiert. Sonst wüsstest du, dass das gar kein Modul ist, sondern eine Spezifikation (wie der Name am Ende schon vermuten lassen könnte...).


Ich habe lange gegen Stable und Development branches gekaempft, und faende es nicht gut, wenn sie durch eine Hintertuer eingefuehrt werden.


Ich lese nur, dass du etablierte Standards und Best Practices, nach denen andere arbeiten und auch gerne arbeiten möchten, nicht gut findest.
Und nach einer solchen Aussage wunderst du dich noch darüber, dass du meinst hier würde ein "Opt-Out" durchgeführt?  ::)
« Letzte Änderung: 14 März 2019, 17:19:13 von Loredo »
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18912
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #31 am: 14 März 2019, 17:18:37 »
bitte atmet doch beide mal tief durch und schaukelt euch nicht hoch.

es wäre schade wenn das hier wegen aneinander vorbei reden oder anderen missverständnissen  im sande verläuft.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH
Zustimmung Zustimmung x 1 Hilfreich Hilfreich x 1 Liste anzeigen

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #32 am: 14 März 2019, 17:20:55 »
bitte atmet doch beide mal tief durch und schaukelt euch nicht hoch.

es wäre schade wenn das hier wegen aneinander vorbei reden oder anderen missverständnissen  im sande verläuft.


Mich nervt einfach dieses unkonstruktive und respektlose Herumgemaule.
Dass es mich trotzdem wenig kratzt, sieht man ja daran, dass Rudi mich auch nach all den Jahren noch nicht vergrault hat.
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18991
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #33 am: 14 März 2019, 17:37:08 »
Hallo Julian, Hallo Rudi,

Eventuell hilft es Euch beiden wenn der Julian versucht kleinere Sprünge zu machen (nicht gleich email Adressen rein nehmen oder Verlinkungen zu machen zum Verein) und wartet bis sich der Verein oder Rudi auf explizite Anfragen gemeldet hat. Es ist nicht einfach alle Stimmberechtigten innerhalb von ein paar Tagen zu bekommen.

Und vielleicht mag Rudi einfach mal kurz erzählen was er von der derzeitigen Entwicklung der beiden Module hält und die Idee die Julian für die Zukunft hat. Er hat ja schon so einiges geschrieben. Die Nutzer finden es jedenfalls bis jetzt eine gute Entwicklung sagen sie.
Ich verstehe aber auch Rudi der nun Aufgaben bekommen hat (in Form von Anfragen und Bitten) aber anscheinend noch keine wirkliche Zeit gefunden hat dafür.
Julian Du stemmst da eine ziemlich große Sache und ich finde sie super, aber eshängt auch einiges an Entscheidungen von Rudi ab die Du vielleicht erstmal bitte abwartest, oder halt in Deinen Modulen vorerst verschiebst oder mit Dummys belegst. Es hilft weder dem wundervollen Projekt von Julian noch FHEM mit Rudi wenn das jetzt ausarten sollte. Daher wie Andre schon sagte bitte tief durchatmen und versuchen einen gemeinsamen Konzens zu finden.


Entspannte Grüße
Marko
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer
Gefällt mir Gefällt mir x 1 Zustimmung Zustimmung x 1 Liste anzeigen

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20174
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #34 am: 14 März 2019, 18:54:36 »
Zitat
Und vielleicht mag Rudi einfach mal kurz erzählen was er von der derzeitigen Entwicklung der beiden Module hält und die Idee die Julian für die Zukunft hat.
Ich habe jetzt versucht die beiden Themen durchzulesen, evtl. habe ich was uebersehen.

Ich sehe auch das Problem der externen Abhaengigkeiten, meine persoenliche Loesung ist diese soweit wie moeglich zu vermeiden, siehe FHEMWEB, MQTT2, usw.

Ein Modul zu schreiben, was die benoetigten Module oder Programme installiert, ist loeblich, das richtig zu machen ist viel Entwicklungsarbeit und noch mehr Supportaufwand. Ich verstehe, dass eine Kooperation der Module, die sowas brauchen, die Sache erleichtert, aber (noch?) nicht, wozu copyright, oder privacy-statements dabei notwendig sind, oder was Installer.pm mit fhem.pl anfangen will (installieren ja nicht).

Aber das ist ja auch egal, ich bin kein Visionaer, und lasse mich gerne ueberraschen, wenn ich dafuer nichts tun muss. Ich will nur meine Emailadresse nicht in einem mailto: Link sehen, ich kriege jetzt schon ausreichend Zuschriften der Sorte "Mein letztes FS20RSU ist kaputt, haben sie noch was auf dem Lager", und jetzt sind noch die ausgefiltert, die kein Copy&Paste beherrschen. Mit einem mailto: Link ist das auch keine Voraussetzung mehr.

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18991
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #35 am: 14 März 2019, 19:02:41 »
Danke Dir Rudi für Dein Statement. Ich denke auf Basis Deiner Aussage kann Julian seine Module weiter voran bringen und weiß nun erstmal wo er ganz auf Angaben verzichtet oder eben einfach noch mal nach fragt.

@Julian
Da ich nun auch festes FHEM e.V. Mitglied bin biete ich mich gerne als Vermittler bei weiteren Fragen an.
@ Rudi wäre das auch in Deinem Interesse?


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20174
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #36 am: 14 März 2019, 19:16:22 »
Zitat
Da ich nun auch festes FHEM e.V. Mitglied bin biete ich mich gerne als Vermittler bei weiteren Fragen an.
Gerne.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #37 am: 14 März 2019, 19:20:38 »
Danke sehr, Rudi. Diese Art der Formulierung ist die Art von Umgang, den ich mir wünsche und auch selbst pflegen möchte, wenn man ihn mir so entgegen bringt.


Von meiner Seite aus ist es lediglich ein Anreiz gewesen, auch nicht-technische Informationen mit anzuzeigen. Data Privacy bewegt eben viele und wenn man alle Informationen über den Anbieter (FHEM e.V., nach meinem Verständnis) sowie auch ein Statement zu Thema Datenschutz an einer zentralen Stelle (und so verstehe ich den Installer) finden kann, dann trägt das zur Transparenz bei. Meiner Meinung nach muss man sich da auch nicht viel Aufwand mit machen (außer dann vielleicht der Frage "wem gehört jetzt FHEM bzw. wer ist der Diensteanbieter für das Gesamtprodukt?"). Diese Fragen will und kann ich euch auch gar nicht beantworten, beruflich bedingt weiß ich aber, dass diese Dinge oft ein notwendiges Übel sein können. Da es bisher aber auch kein Thema für FHEM war, soll es nun auch dann dabei belassen sein. Modulautoren haben nach wie vor die Möglichkeit für ihre eigenen Module solche Informationen zu hinterlegen, wenn sie das für wichtig halten.


Zu der Frage, was der Installer mit fhem.pl tut: Der Installer bildet ein vollumfängliches Bild der Abhängigkeiten ab, FHEM intern wie extern und auch über Perl hinaus. Grundlage ist alles, was in %modules steht. Dort gibt es eben auch 'Global' als Modul, also ein Alias für fhem.pl. Ich fand bisher nicht, dass deine Arbeit am zentralen Herzstück nun weniger Aufmerksamkeit verdient hätte als alle anderen Module, deren Abhängigkeiten und Details angezeigt werden können.


Man muss aber natürlich auch sagen: Der Getter showModuleInfo ist jetzt natürlich das einzige Feature, was man sehen kann. Das bleibt aber ja nicht so und es ist keinesfalls der Dreh und Angelpunkt wenn es darum geht, einfach nur zu schauen, was fehlt und diese fehlenden Abhängigkeiten nachzuinstallieren. Da fhem.pl wahrscheilich niemals etwas fehlen wird, wird es auch eher unwahrscheinlich in der Liste mit fehlenden Abhängigkeiten auftauchen  ;)
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18912
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #38 am: 14 März 2019, 21:42:02 »
ich habe eben eine alexa version mit den ersten meta infos eingecheckt. du kannst also anfangen die node modul info auszuwerten und auch in npmjs einzubauen.

ich hatte versucht die perl version als v5.14.x anzugeben. dann gibt es aber einen fehler aus Meta.pm mit is not numeric.

FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #39 am: 15 März 2019, 08:38:39 »
ich habe eben eine alexa version mit den ersten meta infos eingecheckt. du kannst also anfangen die node modul info auszuwerten und auch in npmjs einzubauen.


Prima, mache ich! Wird dann aber erstmal noch ein Mix sein müssen, weil die anderen ja noch nachziehen müssen :-)


ich hatte versucht die perl version als v5.14.x anzugeben. dann gibt es aber einen fehler aus Meta.pm mit is not numeric.


Ja, das ist richtig. Du musst von semver auf nummerisch umrechnen. Das geht ganz einfach:


5 -> bleibt so
14 -> 014 (3-stellig machen)
x -> 00x (3-stellig machen)


Was du also angeben musst ist 5.01400x (ich weiß nicht, wofür x bei dir stehen sollte).




Gruß
Julian
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18912
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #40 am: 15 März 2019, 08:48:48 »
das x war nur ein platzhalter :)

wir haben doch computer. warum muss man dann etwas selber umrechnen? wäre toll wenn das modul das macht :).

FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #41 am: 15 März 2019, 09:20:16 »
das x war nur ein platzhalter :)

wir haben doch computer. warum muss man dann etwas selber umrechnen? wäre toll wenn das modul das macht :) .


Jaein, dann ist der META.json nicht mehr standard konform und kann von anderer Software nicht mehr ausgewertet werden.
Alle Datenfelder, die nicht mit x_ anfangen, sind schon vordefiniert in ihrem Datenformat und ich würde gerne zu der bestehenden CPAN Spezifikation kompatibel bleiben, ohne dass FHEM zwangsläufig gestartet werden muss.


Dass so viele Dinge von jedem anders gemacht werden, damit kämpfe ich ja gerade extrem beim zusammensammeln und harmonisieren aller Datenquellen. Da würde ich das nicht noch fördern wollen ;-)
« Letzte Änderung: 15 März 2019, 09:21:58 von Loredo »
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18912
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #42 am: 15 März 2019, 09:22:17 »
ok. trotzdem doof :)
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #43 am: 15 März 2019, 12:12:04 »
Ich hab dir da Quark erzählt.
Habe vergessen, dass später auch noch die Auswertung als ">=x.xx,<y.yy" und so weiter notwendig ist. Von daher baue ich eine Normalisierung ein, im generierten JSON wird dann immer der nummerische Wert hinterlegt, damit man ihn direkt für Vergleiche hernehmen kann. Für eine Anzeige im Userinterface rechnet man es dann bedarfsweise um oder nicht.
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3601
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #44 am: 15 März 2019, 16:29:17 »
Hi Julian,

ich hatte dir doch in #21 berichtet, dass das Internal FVERSION bei meinem Versuchen nicht gesetzt wurde.
Inzwischen habe ich mich intensiver damit und deinem Meta.pm befasst und nun klappt es.
Das Problem lag in der $Id - Zeile. Nur wenn sie komplett gefüllt ist, wie z.B.

  $Id: 76_SMAPortal.pm 00000 2019-03-14 22:03:37Z DS_Starter $

wird {x_version} gesetzt was dann ja mit FHEM::Meta::SetInternals auf das Internal abgebildet wird.
Da mein contrib-Modul nicht eingecheckt ist und diese Zeile nicht komplett gefüllt hatte, klappte das eben nicht.
Weiß nicht ob du für noch nicht eingecheckte Module diesbezüglich etwas ändern möchtest.
Das nur nochmal als Feedback, ansonsten klappte bisher alles super bei meinen Tests.  :)

Grüße,
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, Watches
Kaffeekasse: https://www.paypal.me/HMaaz

Offline Martin Fischer

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 1925
    • www.fischer-net.de/
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #45 am: 15 März 2019, 20:39:41 »
Hallo Zusammen,

ich bitte im Zusammenhang mit "Meta.pm" folgenden Sachverhalt zu prüfen:

Seit ~11 Jahren liegt meine "fhem.pl" unter "/usr/bin/fhem.pl". Entsprechend ist "attr global modpath /opt/fhem" gesetzt. Diese seit langem funktonierende Konstellation führt nun dazu, dass das System mit allen Modulen, die "use FHEM::Meta" beinhaltet, crashed ("Can't locate FHEM/Meta.pm in @INC").

In "fhem.pl" wird "@INC" gesetzt:
    my $modpath = "$val/FHEM";

    opendir(DH, $modpath) || return "Can't read $modpath: $!";
    push @INC, $modpath if(!grep(/\Q$modpath\E/, @INC));

"Meta.pm" wird via "use FHEM::Meta;" eingebunden, was insofern funktoniert, wenn "attr global modpath ." gesetzt ist und sich "fhem.pl" im selbigen Pfad wie "modpath" befindet. Das funktioniert, weil in "@INC" immer auch "." enthalten ist.

Da Perl davon ausgeht, dass das Modul relative zum "Hauptprogramm" ("fhem.pl") geladen werden soll, schaut Perl also unabhängig von "modpath" eben auch in das Verzeichnis wo "fhem.pl" liegt und findet dann auch "./FHEM/Meta.pm".

Das "use FHEM::Meta" funktioniert demnach nicht, wenn "fhem.pl" eben nicht mehr im selben Verzeichnis wie das Verzeichnis "FHEM" liegt. "@INC" wird in "fhem.pl" auf "$modpath = "$val/FHEM";" gesetzt. Jetzt sucht Perl per-se in "." (im obigen Fall "/usr/bin/") sowie den Standardsuchpfaden plus dem "modpath" aus "fhem.pl" (hier jetzt: "/opt/fhem/FHEM") und schon knallt es, da "use FHEM::Meta;" dann eigentlich "use Meta;" lauten müsste, analog zu anderen "Hilfsmodulen" wie "HttpUtils", "Blocking", "SetExtensions", etc.

Ich freue mich, wenn dies beim nächsten Update berücksichtigt wird.

Danke und viele Grüße
Martin

--
Gründungsmitglied des FHEM e.V.

mehrere produktive FHEM Instanzen mit mehr als 300 aktiven Aktoren / Sensoren (1wire, FHT, FS20, HMS, Homematic, Z-Wave, IPCam, JeeLink, KS300, LaCrosse, RFXtrx,  SqueezeBox, etc.)

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3601
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #46 am: 16 März 2019, 12:13:37 »
Hi Julian,

nach einem update heute ist mir der Eintrag

2019.03.16 11:50:40.674 3: FHEM::Meta::__GetMetadata WARNING: Unregistered core module or package:
  FHEM/57_ABFALL.pm has defined VCS data but is not registered in MAINTAINER.txt

im Log meines Systems aufgefallen.
Das Modul ABFALL ist aber kein eingechecktes Modul und hat in seinem Initialize auch nicht FHEM::Meta eingebunden.
Ich verwende es aber, d.h. durch Verwendung wird Meta veranlasst es auszuwerten.
Meiner Meinung nach dürfte aber dieser Log-Eintrag nicht kommen weil es keine {x_vcs} Daten gibt.

{
  'version' => '0.000000001',
  'name' => 'ABFALL',
  'generated_by' => 'FHEM::Meta v0.1.8, 2019-03-16 11:50:39',
  'dynamic_config' => 1,
  'license' => 'unknown',
  'x_prereqs_src' => 'scanner',
  'x_file' => [
                'FHEM/57_ABFALL.pm',
                'FHEM/',
                '57_ABFALL.pm',
                '57',
                'ABFALL',
                'pm',
                [
                  2049,
                  786693,
                  33279,
                  1,
                  999,
                  20,
                  0,
                  9873,
                  [
                    1552726674,
                    '2019-03-16 09:57:54',
                    '2019-03-16',
                    '2019',
                    '03',
                    '16',
                    '09:57:54',
                    '09',
                    '57',
                    '54'
                  ],
                  [
                    1548017748,
                    '2019-01-20 21:55:48',
                    '2019-01-20',
                    '2019',
                    '01',
                    '20',
                    '21:55:48',
                    '21',
                    '55',
                    '48'
                  ],
                  [
                    1552726661,
                    '2019-03-16 09:57:41',
                    '2019-03-16',
                    '2019',
                    '03',
                    '16',
                    '09:57:41',
                    '09',
                    '57',
                    '41'
                  ],
                  4096,
                  24
                ],
                'generated/blank',
                undef
              ],
  'meta-spec' => {
                   'version' => 2,
                   'url' => 'https://metacpan.org/pod/CPAN::Meta::Spec'
                 },
  'author' => [
                'unknown <>'
              ],
  'description' => 'n/a',
  'x_version' => '57_ABFALL.pm:?/2019-01-20 UNSTABLE',
  'prereqs' => {
                 'runtime' => {
                                'requires' => {
                                                'Time::Piece' => '0',
                                                'Time::Local' => '0',
                                                'ABFALL_setUpdate' => '0',
                                                'POSIX' => '0',
                                                'warnings' => '0',
                                                'strict' => '0'
                                              }
                              }
               },
  'release_status' => 'unstable'
}

Solltest vllt. nochmal checken.

LG,
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, Watches
Kaffeekasse: https://www.paypal.me/HMaaz

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3186
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #47 am: Gestern um 08:57:20 »
Das Problem lag in der $Id - Zeile. Nur wenn sie komplett gefüllt ist, wie z.B.

  $Id: 76_SMAPortal.pm 00000 2019-03-14 22:03:37Z DS_Starter $

wird {x_version} gesetzt was dann ja mit FHEM::Meta::SetInternals auf das Internal abgebildet wird.
Da mein contrib-Modul nicht eingecheckt ist und diese Zeile nicht komplett gefüllt hatte, klappte das eben nicht.
Weiß nicht ob du für noch nicht eingecheckte Module diesbezüglich etwas ändern möchtest.

Das Modul versucht in der Tat sehr streng zu unterscheiden, welche Module tatsächlich zu FHEM Core gehören und welche lokal sind.
Ich hatte die Auswertung der Update Daten noch nicht fertig, inzwischen sollte es jedoch kein Problem mehr sein lokale Module zu verwenden. Auch Module aus anderen Quellen, die über den Update Befehl geladen werden, werden unterschieden. Zu erkennen sollte das jeweils an den automatisch hinzugefügten Keywords "fhem-mod-local" bzw. "fhem-3rdparty" sein.

Das Modul ABFALL ist aber kein eingechecktes Modul und hat in seinem Initialize auch nicht FHEM::Meta eingebunden.
Ich verwende es aber, d.h. durch Verwendung wird Meta veranlasst es auszuwerten.
Meiner Meinung nach dürfte aber dieser Log-Eintrag nicht kommen weil es keine {x_vcs} Daten gibt.

Doch, die VCS Daten gibt es, sie wurden aber bis dato verworfen (nicht in den generierten META Hash verlinkt), weil eben die Integration der Update Files noch nicht fertig war. Inzwischen sollte das gehen, ich habe aber mit externen Modulen noch nicht viel probiert, nur mit lokalen und Kopien von FHEM Modulen. Bei letzteren werden auch absichtlich die VCS Daten ignoriert, weil sie nicht mit dem Dateinamen übereinstimmen. Was ich nun noch versuchen möchte ist irgendwie zu erkennen, ob man ein FHEM Modul lokal geändert hat, sprich ob es nicht mehr mit den Update Daten überein stimmt und ein neueres Änderungsdatum hat. Lokale Änderungen sollen dann auch im x_version Attribut bzw. FVERSION Internal deutlich angezeigt werden, wenn ein Modul über ein Repository verwaltet wird.

Seit ~11 Jahren liegt meine "fhem.pl" unter "/usr/bin/fhem.pl". Entsprechend ist "attr global modpath /opt/fhem" gesetzt. Diese seit langem funktonierende Konstellation führt nun dazu, dass das System mit allen Modulen, die "use FHEM::Meta" beinhaltet, crashed ("Can't locate FHEM/Meta.pm in @INC").

In "fhem.pl" wird "@INC" gesetzt:
    my $modpath = "$val/FHEM";

    opendir(DH, $modpath) || return "Can't read $modpath: $!";
    push @INC, $modpath if(!grep(/\Q$modpath\E/, @INC));

Eigentlich tendiere ich dazu zu sagen, dass in fhem.pl eine Reihe von Pfadangaben für @INC fehlen. Das sieht man auch in GPUtils.pm:

#add FHEM/lib to @INC if it's not allready included. Should rather be in fhem.pl than here though...
BEGIN {
  if (!grep(/FHEM\/lib$/,@INC)) {
    foreach my $inc (grep(/FHEM$/,@INC)) {
      push @INC,$inc."/lib";
    };
  };
};

Abgeleitet von $attr{global}{modpath} sollten deshalb folgende Pfade in @INC aufgenommen werden:

$attr{global}{modpath}
$attr{global}{modpath}.'/FHEM'
$attr{global}{modpath}.'/FHEM/lib'

Übrigens nutzt auch WinService.pm den Paketnamen FHEM::WinService.
@Rudi, siehst du eine Möglichkeit das in fhem.pl einzubauen?

@Martin, du kannst den INC Pfad auch über Systemvariablen steuern und an deine Umgebung anpassen. Versuch mal in ~/.profile des Nutzers, unter dem FHEM läuft, dies hier aufzunehmen:

export FHEM_DIR=/opt/fhem
export PERL5LIB=${FHEM_DIR}:${FHEM_DIR}/FHEM:${FHEM_DIR}/FHEM/lib:${FHEM_DIR}/local/lib/perl5:/usr/local/lib/perl5:$PERL5LIB






PS: @Martin
Mich würde der Use Case dahinter interessieren, weshalb man die fhem.pl separat von den anderen Dateien ablegt. Wo liegen denn dann die Config Files, im selben Verzeichnis wie fhem.cfg und kann man beim globalen configfile Attribut dann auch einen entsprechenden Pfad angeben? (ich vermute du hast deine Konfiguration nicht in /usr/bin liegen ;-)).
Wie machst du da ein Update, funktioniert der Update Befehl dann überhaupt?
« Letzte Änderung: Gestern um 11:12:53 von Loredo »
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

 

decade-submarginal