Hallo,
wir machen uns das Leben schon wieder schwer mit
Commit failed (details follow):
Commit blocked by pre-commit hook (exit code 1) with output:
*** trunk/fhem/FHEM/lib/OWNet-3.2p4.pm: file has no SVN Id as comment
svnlook: E200017: Property 'svn:keywords' not found on path '/trunk/fhem/FHEM/lib/OWNet-3.2p4.pm' in transaction 30414-nl7
*** trunk/fhem/FHEM/lib/OWNet-3.2p4.pm: Id property not set in svn:keywords
Ich will die aktuelle OWNet-Version einspielen, natürlich unverändert, und bekomme sie nicht rein, wegen fehlender SVN Id.
Was nun?
Viele Grüße
Boris
ZitatIch will die aktuelle OWNet-Version einspielen, natürlich unverändert, und bekomme sie nicht rein, wegen fehlender SVN Id.
Wir haben vor paar Jahren (ich meine das war im frankfurter CCC Buero) beschlossen, dass externe Bibliotheken nicht mit FHEM ausgeliefert werden (wg. Lizenzproblemen, Pflegeaufwand, etc).
Wir wollten nicht alles sofort rausschmeissen, es sollte aber nach und nach passieren.
Wenn weitere Entwickler sich fuer Ausnahmen oder gar Abkehr von dieser Vereinbarung aussprechen, dann kann ich das im SVN Hook umsetzen, ich brauche aber (auch fuer zukuenftige Beschwerden) Argumente fuer die Aenderung.
Wie aufwändig wäre es denn für die User sich diese Library über den normalen Weg zu besorgen? Ich habe jetzt nicht geschaut aber kann man sie über Debian direkt installieren oder wegen meiner über cpan?
Zitat von: CoolTux am 19 Oktober 2025, 11:11:06kann man sie über Debian direkt installieren oder wegen meiner über cpan?
Man kann...
apt install libownet-perlhttps://packages.debian.org/stable/libownet-perl
Zitat von: Dr. Boris Neubert am 18 Oktober 2025, 17:32:23wir machen uns das Leben schon wieder schwer mit
Nicht alles, was sich verändert, hat automatisch etwas mit "Leben schwer machen" zu tun :-\
Also das sollte doch jedem User zu zumuten sein. Hinweis in der commandref und gut ist denke ich.
Zitat von: CoolTux am 20 Oktober 2025, 14:27:43Also das sollte doch jedem User zu zumuten sein.
Sehe ich auch so, das Nachinstallieren von zusätzlich benötigten perl-Modulen funktioniert ja bei unzähligen anderen Modulen auch seit langem weitgehend problemlos, insbesondere, wenn sie sogar über die Paketverwaltung verfügbar sind und man sich nicht mit CPAN rumärgern muss.
Ich erinnere mich an die Diskussion hier, und nein, niemand will CPAN komplett mit FHEM ausliefern.
Der Grund, handverlesene OWNet-Module mitzuliefern, war, ich erinnere mich nicht mehr genau, dass die Distributionen nicht zusammenpassende oder veraltete libownet-perl und owserver ausgeliefert haben bzw. manche owserver nicht funktionierten. Die Maßgabe an den Anwender war dann, sich die funktionierende owserver-Version als Paket zu besorgen (bisher 2.8p17 und 3.1p5), und die Version dann explizit beim define mitzugeben, so dass das Modul das passende OWNet.pm lädt. Im Code steht dazu
# this must be the latest OWNet from
# http://owfs.cvs.sourceforge.net/viewvc/owfs/owfs/module/ownet/perl5/OWNet/lib/OWNet.pm
# the version at CPAN is outdated and malfunctioning as at 2012-12-19
Ja, das ist von 2012. Ich habe keine 1-Wire-Geräte mehr im Einsatz und freue mich, dass am Wochenende ein Anwender eine zur aktuellen Version passende OWNet zur Verfügung gestellt hat.
Klar kann man dem Anwender zumuten wollen, sich die passenden Versionen zusammenzufrickeln, aber vielleicht wandert der dann lieber zur Konkurrenz.
Sowohl bookworm als auch trixie liefern libownet-perl in der Version 3.2-4 als fertiges Paket aus.
Das ist doch genau die Version, die Du einchecken wolltest.
Zitat von: Dr. Boris Neubert am 20 Oktober 2025, 20:32:22Klar kann man dem Anwender zumuten wollen, sich die passenden Versionen zusammenzufrickeln, aber vielleicht wandert der dann lieber zur Konkurrenz.
Wenn sowas der Grund ist, von FHEM woanders hin zu wechseln, dann ist das halt so. Übrigens betrachte ich andere Hausautomationslösungen nicht als "Konkurrenz", sondern finde die Vielfalt durchaus spannend. Wir stehen hier ja nicht in einem wirtschaftlichen Marktwettbewerb.
[OT]
Ich war 2007 der zeitlich Erste, der neben Rudi Code zu FHEM (was damals noch nicht so hieß) beitrug, und bin etwas länger auch schon Anwender.
Aus der Anwenderperspektive heraus baue ich gerade nach meinem Umzug zum vierten Mal eine Hausautomation von Null an neu mit FHEM auf, nicht eingerechnet die früheren Änderungen an bestehender Hausautomation aufgrund Technologiewechseln oder -ergänzungen.
Bei allen Vorzügen, die FHEM besitzt, gehört übermäßige Anwenderfreundlichkeit nicht dazu. Ich bin nicht der Klickibunti-Typ, und ich kann mich auch geduldig durch Doku fressen. Aber neulich kam mir in den letzten zwei Jahren zum zweiten Mal der Gedanke, ob ich mir nicht mal HomeAssistant anschauen sollte. Ich bin beim Aufbau wieder einmal in Fallen gelaufen, habe mir das Hirn bei tollen (ehrlich!) Modulen mit superkomplexen Möglichkeiten und ebensolcher Konfiguration verrenkt, und habe wieder mehr Zeit investiert, als ich eigentlich mit fast 20 Jahren Erfahrung dachte investieren zu müssen. Hausautomation ist nur das Sahnehäubchen beim Bezug eines Hauses, und daneben habe ich noch hunderttausend andere Dinge zu erledigen, die meine Zeit beanspruchen.
Vor diesem Hintergrund ist es mein Anspruch, dass meine Module so einfach wie möglich einzusetzen sind, sowohl bzgl. Konfiguration/Fehlertoleranz als auch bzgl. Anwenderdokumentation.
[/OT]
Bei der Entwicklung von OWServer/OWDevice ab 2012 (zusammen mit Martin Fischer) musste ich zahlreiche Hürden überwinden durch nicht zusammenpassende Software im Stack, und nachdem ich herausgefunden hatte, wie damit umzugehen ist, habe ich Erleichterungen eingebaut wie z.B. das Mitliefern der richtigen Perl-Module zur jeweiligen owserver-Version, damit der Anwender nicht noch auf anderen Webseiten danach kramen muss.
Mittlerweile setze ich keine 1-wire-Geräte mehr ein, habe keine Testmöglichkeiten und auch keine Zeit und kaum Interesse bis auf Erhaltungswartung (Stichwort: smartmatch is deprecated) an diesen Modulen zu arbeiten.
Mit der Zurverfügungstellung von OWNet direkt aus FHEM heraus in einer aktuellen Version wäre dem nächsten Anwender wieder etwas Denk- und Konfigurationsarbeit erspart worden.
@Boris: kann ich fast alles nachvollziehen, nur Dein beschriebenes Anspruchsdenken nicht.
Und um auf 2007 zurückzukommen: damals gab es noch keine 500 Module mit zusätzlichen Anforderungen an benötigten perl-Modulen.
Wie groß würde FHEM werden, wenn jedes Modul seine Abhängigkeiten mitbrächte, und das auch noch zwangsweise für jeden Nutzer, egal ob er ein Modul überhaupt nutzt oder nicht?
Zitat von: betateilchen am 31 Oktober 2025, 09:22:13Wie groß würde FHEM werden, wenn jedes Modul seine Abhängigkeiten mitbrächte, und das auch noch zwangsweise für jeden Nutzer, egal ob er ein Modul überhaupt nutzt oder nicht?
Es ist weder sinnvoll noch notwendig, bei allen Modulen alle Abhängigkeiten mitzuliefern. Das habe ich oben bereits verneint. Wenn es mit
apt-get install libblubb-perl geht, ist das dem Anwender zuzumuten. Es geht hier aber um einen Fall, dass die Installation per Paketmanager nichtfunktionierende Dateien installiert und sich der Anwender die richtige Datei "irgendwo" im Internet beschaffen muss. Geht natürlich auch. Aber anwenderfreundlich geht aus meiner Sicht anders.
Ich kann nicht beurteilen, ob noch alte Installationen von owserver im Feld sind, ob es bei aktuellen Distributionen noch zu diesen Problemen kommt, und ich werde auch das Modul OWServer nicht anpassen, weil ich keine 1-Wire-Installation (mehr) habe.
Ich muss und werde mich auch nicht weiter mit dieser Thematik auseinandersetzen, weil es meine Freizeit ist, die ich hier verbrate. Ich gebe das Modul einfach auf.