Anfänger - wer nimmt mich ein wenig an die Hand? SNMP/MQTT

[Wernieman]

Sorry aber da höre ich etwas die "Arroganz" des professionellen Softwareentwicklers.

CPAN hört sich immer gut an, nur sind hier sind sehr viele Home-Administratoren unterwegs. Wenn die mal ein Betriebsystemupdate machen und dabei perl upgedatet wird, geht erstmal wenig ...  da vergessen wird, CPAN upzudaten. Als Folge wird kein Update mehr gefahren ... DIE Problematik sollte bekannt sein.

Es ist also besser, wenn ein Modul mit gängigen Bibliotheken der gängigen Betriebsysteme geht .. und erst, wenn das nicht geht auf CPAN auszuweichen.

Im Profiumfeld kann und muß man damit umgehen, aber im Home-Administrationsumfeld ....

[mahowi]

Ich sehe das Problem nicht. Es gibt ja einige Module, für die zusätzliche Perl-Module benötigt werden. Üblicherweise gibt man das z.B. in der commandref mit an, am besten mit Namen des entsprechenden Debian-Pakets, hier z.B. libnet-snmp-perl.

[RichardCZ]

Sorry aber da höre ich etwas die "Arroganz" des professionellen Softwareentwicklers.

Ja, das kann durchaus sein. Ist aber nicht der profi-Softwareentwickler, aber der INTJ. 

CPAN hört sich immer gut an, nur sind hier sind sehr viele Home-Administratoren unterwegs. Wenn die mal ein Betriebsystemupdate machen und dabei perl upgedatet wird, geht erstmal wenig ...  da vergessen wird, CPAN upzudaten. Als Folge wird kein Update mehr gefahren ... DIE Problematik sollte bekannt sein.

Klar. Da könnte man dann ja jemanden fragen, der sich damit auskennt. carton, perlbrew,...
Endziel sollte eigentlich sein, dass ein HomeAdmin im Webfrontend auf "update" klickt oder "update" in der Kommandozeile eingibt, dann wartet man eine Weile und dann ist ein neues FHEM da.

Rolling release. Da arbeite ich darauf zu.

Es ist also besser, wenn ein Modul mit gängigen Bibliotheken der gängigen Betriebsysteme geht .. und erst, wenn das nicht geht auf CPAN auszuweichen.

Nö - siehe oben. Das Update geht noch wesentlich luxuriöser als jetzt UND mit der geballten CPAN Power.
Man muss nur wissen wie und wollen.

Leute, die "euch" dabei helfen können dieses Ziel zu erreichen der "subjektiv empfundenen Arroganz" zu bezichtigen ist jetzt meiner Ansicht nach nicht so der Königsweg, aber jedem das Seine.

[Wernieman]

Tja .. FHEM Update <> Betriebsystem Update ...

[RichardCZ]

Tja .. FHEM Update <> Betriebsystem Update ...

Tja. perlbrew. Vielleicht erstmal die Begriffe nachschauen die ich so hinwerfe.

Edith:

Ok, ok, ... damit ich auch konkrete Infos gebe:

https://perlbrew.pl/

siehe "What is perlbrew", das Wichtigste in Kürze:

perlbrew is a tool to manage multiple perl installations in your $HOME directory. They are completely isolated perl universes. This approach has many benefits:

• No need to run sudo to install CPAN modules, any more.

...

• Test your production code against different perl versions. (Anm.: Für Entwickler)
• Leave vendor perl (the one that comes with OS) alone
  
  Vendor perl usually serves its own purposes, and it might be a bad idea to mess it up too much.
• Especially PITA when trying to upgrade system perl.
• Some vendors introduced their own perl bugs, twice!

Mit anderen Worten: Damit entkoppelt man die Perl Installation vom OS, gibt sie unter die Verfügungsgewalt des Users (bzw. des Prozesses, der mit User-Rechten läuft)

Mein FHEM läuft unter Perlbrew (5.30)

[herrmannj]

Ich sehe das Problem nicht. Es gibt ja einige Module, für die zusätzliche Perl-Module benötigt werden. Üblicherweise gibt man das z.B. in der commandref mit an, am besten mit Namen des entsprechenden Debian-Pakets, hier z.B. libnet-snmp-perl.

FHEM läuft auf vielen unterschiedlichen Systemen, darunter "Exoten" auf denen weder perlbrew noch CPAN zur Verfügung steht. Mit "libnet-snmp-perl" kann noch nicht einmal der Windows Anwender etwas anfangen. Deswegen auch "shall".

Die Verwendung von externen Abhängigkeiten schließt Benutzer aus oder verschlechtert die Benutzer Erfahrung. Das gilt zum Beispiel für ein FHEM Update. Das wird von einem Client aus via Browser angestoßen. Wenn jetzt CPAN Module erforderlich werden muss der Benutzer sich mit dem OS des Servers verbinden. Darüber dass dann nicht jeden CPAN xxx auch gleich problemlos funktioniert muss ich doch mit einem Profi nicht reden. Oder ?

aber bevor ich so schlechte Räder neu erfinde wie offensichtlich bereits geschehen, werde ich diese shall-Regel doch arg biegen.

Unsinn, Blödsinn und Arrogant, FHEM enthält unter anderen MQTT, Comet und Websocket Cleanroom Implementierungen die sehr gut sind.

Liefere Dein erstes Modul und beweise dass Du das auf Dauer und für verschiedene Systeme supporten kannst und möchtest.

[RichardCZ]

Unsinn, Blödsinn und Arrogant, FHEM enthält unter anderen MQTT, Comet und Websocket Cleanroom Implementierungen die sehr gut sind.

Ignorant. Damit ist die Diskussion für mich beendet. Dass es gute Implementierungen gibt habe ich nicht bestritten, ich habe nur gesagt, dass es einige gibt, die ziemlich scheisse sind. Namen muss ich jetzt keine nennen, könnte aber.

Liefere Dein erstes Modul und beweise dass Du das auf Dauer und für verschiedene Systeme supporten kannst und möchtest.

Kann ich nicht, will ich nicht. Kann definitiv nicht Windows supporten, da 0 Erfahrung mit dem OS.

[mahowi]

FHEM läuft auf vielen unterschiedlichen Systemen, darunter "Exoten" auf denen weder perlbrew noch CPAN zur Verfügung steht. Mit "libnet-snmp-perl" kann noch nicht einmal der Windows Anwender etwas anfangen. Deswegen auch "shall".

Die Verwendung von externen Abhängigkeiten schließt Benutzer aus oder verschlechtert die Benutzer Erfahrung. Das gilt zum Beispiel für ein FHEM Update. Das wird von einem Client aus via Browser angestoßen. Wenn jetzt CPAN Module erforderlich werden muss der Benutzer sich mit dem OS des Servers verbinden. Darüber dass dann nicht jeden CPAN xxx auch gleich problemlos funktioniert muss ich doch mit einem Profi nicht reden. Oder ?Unsinn, Blödsinn und Arrogant, FHEM enthält unter anderen MQTT, Comet und Websocket Cleanroom Implementierungen die sehr gut sind.

Dafür gibt's aber auch seit einiger Zeit das Modul Installer:

Installer - Module to update FHEM, install 3rd-party FHEM modules and manage system prerequisites

[herrmannj]

Kann ich nicht, will ich nicht. Kann definitiv nicht Windows supporten, da 0 Erfahrung mit dem OS.

Dann hör auf zu quengeln und streng Dich mehr an Mac OS, Einplatinen- und SOC Systeme gehören genauso wie unterschiedliche Perl Version zum Soll.

[Wzut]

@herrmannj, als guter Wille ja - aber mal Hand aufs Herz : welcher Modulautor hat wirklich den kompletten Hardware Zoo zum testen ?
Ich kann die Tests meiner Module auch nur auf Raspian und Ubuntu beschränken, dh. laut FHEM Stats sollte das für über 5000 Installationen dann passen (vs, 46 Win/MAC User) 

[herrmannj]

Ich schrieb auch nicht MUSS sondern SOLL und es geht auch nicht ums testen sondern darum dass beim coden zu berücksichtigen.

Wenn ich eben das Vorhandensein von perlbrew und CPAN (zieht einen compiler und wechselnde weitere libs pro modul nach sich) voraussetze oder syscalls verwende die systemspezifisch sind, dann schränke ich den Nutzer von vornherein ein.

Ein perl ist fast überall verfügbar und ein {print 'Hello world'} läuft auf dem mainframe und auf der Armbanduhr (da bin ich mir sicher obwohl ich beides nicht besitze:)). Dass es Gründe geben kann auf externe Abhängigkeiten zurückzugreifen  liegt auf der Hand. Die Frage die man sich stellen soll lautet "ginge es auch ohne".

[justme1968]

achtung: Net::SNMP ist blockierend und auch sonst nicht besonders schnell. ohne ein wenig 'drum rum' um es mit BlockingCall oder CoProcess oder was auch immer besser fhem tauglich zu machen. es kommt damit im normalen betrieb und abhängig von der gegenseite bis zu mehreren sekunden blockierung von fhem. es ist es nicht optimal um für den einstieg ein neues modul zu entwickeln.

die aktuelle verwendung in SYSSTAT ist eine 'jugendsünde', die neue version die leider nich nicht eingecheckt ist macht das mit einigen klimmzügen nicht blockierend und behindert fhem nicht mehr.

es gibt noch weitere probleme mit cpan modulen die man im auge behalten muss: nicht oder schwierig in die fhem mainloop integrierbar, das überschreiben von standart perl routinen, sich beenden im fehlerfall, ...

abgesehen davon: cpan module zu nutzen finde ich nicht schlimm. so lange man nicht mit ein klein wenig mehr aufwand eine besser integrierte lösung bauen kann, das ganze nicht wie wild nutzt ohne sich gedanken zu machen und sich idealer weise ausser für spezielle dinge auf eine kleine anzahl zentraler module beschränkt.

aber ein modul muss dann:
- drauf hinweisen das ein externes modul für eine bestimmte funktionalität nötig ist
- damit klar kommen wenn das externe modul nicht da ist, zumindest fhem nicht lahm legen
- den anwender drauf hinweisen
- ...

ps: mac ist normalerweise unproblematisch, das geht eigentlich einfach. windows sehe zumindest ich als völlig optional an und ist gerade bei den oben angesprochenen non-blocking geschichten tatsächlich speziell.

[Damu]

Hallo
Nur zur Info
Das ist auch ein "Modul" das über snmp spricht:
https://wiki.fhem.de/wiki/TCW120