fhem.pl: CommandAttr

[RichardCZ]

Vielleicht könnte ich helfen CommandAttr ein wenig zu verbessern. Mangels Testsuite brauche ich aber Hilfe um zu wissen "wie was gedacht war".

Ich bin schonmal so weit gekommen um dann erstmal hart zu bremsen:

Code (perl) Auswählen Erweitern

    my $cl    = shift;  # whatever this is...
    my $param = shift;  # command attributes in string form - including optional flags

    my $mode;
    my $ret;
    my @a;

    # check if append or remove mode was given
    if ($param =~ s{\A-(a|r) \s+}{}xms) {
        $mode = $1;
    }

    @a = split(" ", $param, 3) if ($param);

    return "Usage: attr [-a|-r] <name> <attrname> [<attrvalue>]\n$namedef"
        if (@a && @a < 2);

CommandAttr behauptet ja

Usage: attr [-a|-r] <name> <attrname> [<attrvalue>]

aber das stimmt nicht. Mindestens gilt [-a -r|-a|-r] - ich vermute, gleichzeitig append und remove zu machen ist nicht so sinnvoll? Der Code macht das aber wenn man es ihm sagt.

Code Auswählen Erweitern

  my ($cl, $param) = @_;
  my ($ret, $append, $remove, @a);

  $append = ($param =~ s/^-a //);
  $remove = ($param =~ s/^-r //);
  @a = split(" ", $param, 3) if($param);

  return "Usage: attr [-a|-r] <name> <attrname> [<attrvalue>]\n$namedef"   # nope  [-a -r|-r|-a]
           if(@a && @a < 2);

...und später dann

    if($append && $attr{$sdev} && $attr{$sdev}{$attrName}) {
      $attrVal = $attr{$sdev}{$attrName} .
                        ($attrVal =~ m/^,/ ? $attrVal : " $attrVal");
    }
    if($remove && $attr{$sdev} && $attr{$sdev}{$attrName}) {
      my $v = $attr{$sdev}{$attrName};
      $v =~ s/\b$attrVal\b//;
      $attrVal = $v;
    }




Kann mir jemand sagen was gewollt ist? Exklusiv oder nicht? Sprich: Code oder Doku ändern?

Wenn exklusiv, mache ich unten eben ein if ($mode eq 'a' && ...) ... elsif ($mode eq 'r') ...

Die usage kommt auch nicht, wenn man z.B. nur CommandAttr(undef, '-r '); übergibt, dann weint sich $a1 = $a[1] aus - weil ja @a undefiniert ist etc. etc.
Aber eins nach dem anderen.

[rudolfkoenig]

$cl: Client Hash, zeigt ueber welchen Kanal das Befehl reingekommen ist, um Authorisierung, etc machen zu koennen.
-a und -r ist nicht so gedacht, dass man sie zusammen aufruft, und nach etwas nachdenken sollte das jedem normalen Benutzer einleuchten.
Wenn es doch gemacht wird, und was Unerwartetes passiert, ist mir eigentlich egal, ich bin nicht da, um Leute aus dem Fenster springen abzuhalten.

Es wird z.Zt. hier irre viel Energie auf Sachen aufgewendet, die fuer den Anwender keinen Nutzen haben. Das finde ich schade, es gibt naemlich auch viel zu tun, was konkret helfen wuerde. Im Zusammenhang mit Perl sind z.Bsp. diverse Speicherloecher zu erwaehnen, siehe unser Mega-Thread https://forum.fhem.de/index.php/topic,84372
Oder die vielen Module, die BlockingCall verwenden, anstatt sich in das globale select-loop einzuhaengen.
Usw, usf.

[RichardCZ]

$cl: Client Hash, zeigt ueber welchen Kanal das Befehl reingekommen ist, um Authorisierung, etc machen zu koennen.
-a und -r ist nicht so gedacht, dass man sie zusammen aufruft, und nach etwas nachdenken sollte das jedem normalen Benutzer einleuchten.
Wenn es doch gemacht wird, und was Unerwartetes passiert, ist mir eigentlich egal, ich bin nicht da, um Leute aus dem Fenster springen abzuhalten.

Es wird z.Zt. hier irre viel Energie auf Sachen aufgewendet, die fuer den Anwender keinen Nutzen haben. Das finde ich schade, es gibt naemlich auch viel zu tun, was konkret helfen wuerde. Im Zusammenhang mit Perl sind z.Bsp. diverse Speicherloecher zu erwaehnen, siehe unser Mega-Thread https://forum.fhem.de/index.php/topic,84372
Oder die vielen Module, die BlockingCall verwenden, anstatt sich in das globale select-loop einzuhaengen.
Usw, usf.

Ich weiß gar nicht, wo ich da anfangen soll. Vielleicht, dass ich das Geschriebene auch sehr schade bis traurig finde.

Ich finde es ja auch sehr schade, dass in Afrika Menschen an Malaria leiden. Aber deswegen investierte Energie in Malaria-Mittel oder Malariabekämpfung als "irre viel Energie, die für die Malariaopfer keinen konkreten Nutzen hat" zu deklarieren und am besten alle Malariaforscher dazu aufrufen, doch mal konkret nach Afrika zu fahren und dort den Malariaopfern Trost zu spenden...

Wie schon gesagt: traurig.

Was das Speicherproblem anbelangt: Diejenigen, die davon gebissen werden, sollen halt kein Perl 5.24 benutzen

Was BlockingCall verwendende Module anbelangt: "ist mir eigentlich egal, ich bin nicht da, um Leute aus dem Fenster springen abzuhalten."

[rudolfkoenig]

Was das Speicherproblem anbelangt: Diejenigen, die davon gebissen werden, sollen halt kein Perl 5.24 benutzen

Das ist nicht so einfach, das Problem kommt auch mit anderen Perl Versionen vor. Ich habe versucht den Speicherverbrauch der einzelnen Module zu messen oder zu lokalisieren, bin aber daran gescheitert. Sowohl mit "Eigenbau", wie auch mit CPAN-Modulen, die mit Segmentation-Fault abgestuerzt sind.

[RichardCZ]

Das ist nicht so einfach, das Problem kommt auch mit anderen Perl Versionen vor. Ich habe versucht den Speicherverbrauch der einzelnen Module zu messen oder zu lokalisieren, bin aber daran gescheitert. Sowohl mit "Eigenbau", wie auch mit CPAN-Modulen, die mit Segmentation-Fault abgestuerzt sind.

Kann ja sein, dass es mehrere Speicherlecks gibt. Devel::Size hat mir häufig geholfen (ich habe gesehen ist bekannt). Perl Debugger magst ja nicht. Ein gewisser Richard Foley hat da eine nette Referenz zu geschrieben: http://shop.oreilly.com/product/9780596005030.do

Kurzer Tipp aus dem Elfenbeinturm: Perl alloziert immer nur Speicher und gibt ihn nie frei - ans OS.
Perl wiederverwendet aber mal freigegebenen Speicher (also innerhalb des Prozesses).
Gut - hilft Dir jetzt vielleicht nicht viel, weil Speicherleck wie Speicherleck, Bedeutet jemand alloziert ständig.
Vermutlich wächst da ein hash oder Array ins Unendliche.

Ich könnte mich da ja umschauen, aber ich betreibe lieber Grundlagenforschung.

Wenn man sich anschaut, wieviele Fehler in den letzten Jahren in Perl geplättet wurden (perl-porters haben nämlich an Fahrt aufgenommen), dann will man da ein neues haben: https://perldoc.perl.org/index-history.html

Schaut euch nur die Perl 524x deltas an.  5.24.4 hat vermutlich auch kein Speicherleck mehr.

---

Unsere Vorgehensweisen unterscheiden sich halt beträchtlich. Ich sehe man hat den Code absolut nicht unter Kontrolle und es erstaunt mich nicht, dass er euch ab und zu auf die Füße fällt. Wenn ich Beispiele zeige wo der Code nicht unter Kontrolle ist, ernte ich von Dir zumeist ein "ist mir wurst". Kann man nur mit der Schulter zucken.

Ich würde ihn gerne unter Kontrolle bringen und es würde mir extrem helfen wenn ich einen Alteingesessenen gewisse Dinge fragen könnte bzw. gewisse Daten bekäme. Aber is halt nicht.

[rudolfkoenig]

Du redest von "nicht unter Kontrolle" und "auf die Fuesse fallen", aber die Sachen die du ansprichst haben mir in den letzten 10 Jahren keine Probleme gemacht.
Und das bedeutet nicht, dass ich keine habe.

Ich würde ihn gerne unter Kontrolle bringen und es würde mir extrem helfen wenn ich einen Alteingesessenen gewisse Dinge fragen könnte bzw. gewisse Daten bekäme. Aber is halt nicht.

Fragen darfst du ja, und ich beantworte auch alles nach meinem besten Wissen.

[herrmannj]

@richard: wenn ich mich zwischen einem fhem entscheiden muss welches bei critic glänzt und einem das über Jahre zuverlässig mein Zuhause steuert. ... Ich nehme letzteres.

Ein guter Plan heute ist besser als ein perfekter Morgen. Ich weiß deine Bemühungen zu schätzen! Denk aber dran: 80 Prozent machen ist besser als 100 Prozent wollen 

[Beta-User]

Zwischenruf vom kleinen DAM, der vermutlich nichts dazu beitragen kann, eventuelle Speicherlecks zu finden:

- Jeder darf selbst entscheiden, wie er seine Zeit einsetzt, ich habe auch noch ein paar FHEM-Hausaufgaben, die ich nicht vergessen habe...
- Über manches kann man denken, was man will (vor allem, wenn man wirklich weiß, was man tut - und das unterstelle ich den "Kern"-FHEM-Entwicklern rund um Rudi allen!), aber die Initiative rund um "besseres Perl" in FHEM erscheint mir durchaus sinnvoll, denn eine nicht ganz kleine Zahl der Maintainer scheinen nämlich eher meine "Qualität" zu haben - gut kopiert ist halb gecoded...
Vor letzterem Hintergrund: Und dass es ganz allgemein nicht schadet, älteren Codebestand mal wieder durchzusehen, ist wohl auch nicht ganz verkehrt. Das gilt in meinem Fall vor allem auch deswegen, weil es wie im Fall von WDT/RandomTimer so ist, dass ich grade eben "sowieso im Code" (und was er tun sollte) drin war und bei der Gelegenheit gerne checken wollte, ob das (v.a. WDT) eventuell irgendwelche programmiertechnischen Stolperfallen enthält, die ich in meinem "jugendlichen Leichtsinn" und begrenztem Horizont eventuell übersehen habe. Und die Diskussion rund um AnalyzePerlCommand/eval könnte so ein Punkt sein, wo es "lustig" wird, jedenfalls, wenn ich das richtig verstanden habe.

Wenn also der eine oder andere weitere Maintainer jetzt zwar auch sagt: k.A., wie man Speicherlöcher findet, aber mal einen automatisierten Check durchzuführen und vielleicht mal wieder nachzusehen, ob es nicht (zwischenzeitlich?) bessere Varianten gibt, wie mein Modul und fhem.pl zusammenarbeiten können, dann ist doch was gewonnen, oder?

@Richard:
Es ist hier in der Regel so, dass Dinge zumeist öffentlich diskutiert werden sollen und können. Wenn du den Eindruck hast, du könntest damit jemandem zu nahe treten: Frage ihn halt vorab direkt, die meisten kann man per pm oder email kontaktieren... (Das würde ich in Bezug auf deine Persönlichkeitsstruktur, auf die du an anderer Stelle hingewiesen hattest, im Zweifel auch empfehlen!
Dazu aber vielleicht noch eine OT-Anmerkung von einem, der hier gelegentlich auch für arrogant gehalten wird: Gerade weil du um diesen Zug weißt, ist es eigentlich keine geeignete Entschuldigung mehr... Schau' möglichst einfach alles nochmal durch die Brille eines virtuellen Dritten an, reduziere das Geschriebene um zwei Schärfegrade und du erreichst hier in unserem Rahmen (und ggf. auch anderswo) (noch) mehr .)

Ansonsten: Ich bin ein DAM, mich darfst du als solchen behandeln, aber andere wären für einen ihrem Level angemessenen Umgangston vermutlich dankbar...

[Martin Fischer]

Leute... mal im Ernst...

Worum geht es hier eigentlich? Geht es hier um ein Kräftemessen?

Auch mir geht die eine oder andere Formulierung von Richard auf den Sack ("nicht unter Kontrolle")... Aber die andere Seite sollte doch auch mal offensichtliche und nachvollziehbare Optimierungsvorschläge oder Code-Reviews sachlich betrachten.. auch wenn Richard nicht jedesmal diplomatisch formuliert...

Und wenn vermeintliche "Ungereimtheiten" in den letzten 10 Jahren keine Probleme bereitet haben, sind sie vielleicht die Summe der Nebeneffekte und führen dann vielleicht u.a. zu besagtem Speicherleck... Warum also nicht erst mal eine gute Basis schaffen um dann Stück für Stück tiefer zu gehen?

Was ich aber derzeit gefühlt erlebe ist, das sich Richard (manchmal aber eben nicht ausschliesslich "unvorteilhaft") einbringt, die andere Seite sich aber mehr mit dem "Wie er sich einbringt" als mit dem "Was er da macht" auseinander setzt.

Ich teile ebenfalls nicht die Meinung, das der bestehende Code "nicht unter Kontrolle" sei. Ich begrüße jedoch ein schrittweises Refactoring ausdrücklich.

Ich bin mir sicher, dass das in Summe die strukturellen Verbesserungen zu einem (noch) schlankeren, schnelleren, stabilen FHEM führen werden. Und dabei sollte das bestehende "Endergebnis", also das beim Anwender, möglichst ungestört bleiben.

Von den "alten Hasen" wird der Code gefühlt "im Sinne des zuverlässigen Hauses" und "der Community" verteidigt ohne mal über den Tellerrand zu schauen und sich Gedanken über Regelprozesse in der IT zu machen. Dazu gehört nämlich auch, "Lifecycles" kontinuierlich zu verbessern. Und das impliziert eben nicht, das sie zwangsläufig auch schlecht sind. Wenn aber Verbesserungen gefunden werden, dann sollten sie nach einer sachlichen Prüfung doch auch Einzug halten und nicht mit einem Fingerzeig abgewiesen werden. Find ich nicht ok!

Den einen oder anderen Tod muss man dann auch mal sterben. Und vorallem sollten sich beide Seiten mal die Hand reichen und überlegen, wie man hier gemeinsam an einem Strick ziehen kann!

my 2 cents...

[Martin Fischer]

Zwischenruf vom kleinen DAM, der vermutlich nichts dazu beitragen kann, eventuelle Speicherlecks zu finden:

Dein Beitrag hat meine vollste Zustimmung!

[herrmannj]

@Martin: interpretiere da nichts rein was nicht drin ist. Ich habe geschrieben "das weiß ich zu schätzen" und das meine ich genau so. Ich sehe das es angenommen wird und der geneigte Leser weiß das ich mich nicht immer zurückhalte wenn es um die Art geht wie einiges in der source von fhem geschrieben ist! 

- aber: wenn Rudi schreibt dass es läuft dann stimmt das! Ich habe gestern zum ersten mal wieder mein Produktiv anfassen müssen (jessie -> buster). up-time 2.5 Jahre. Auf die Füße fallen sieht anders aus.

Gibt es bei usern Probleme mit Speicherlecks ? Scheint so. Ist die Empfehlung, "geh halt auf 5.24" zielführend? Im verlinkten thread hilft's manchmal, aber nicht immer. Wo setzt man die Zeit ein? Wenn es ganz viel davon gibt dann sicher bei beidem. Ansonsten das wo es klemmt. Frag die user die an besagtem Speicherleck leiden doch mal.

Dies hier funktioniert recht zuverlässig auf vielen perl Varianten

Code Auswählen Erweitern

sub
test {
  my $a;
  my $b;

  $a->{b} = \$b;
  $a->{0} = [1..65535];
  $b->{a} = \$a;
  $b->{0} = [1..65535];
  return;
}
for (1..65535) {
  test();
}
for (1..65535) {
  test();
}


[Martin Fischer]

@Martin: interpretiere da nichts rein was nicht drin ist. Ich habe geschrieben "das weiß ich zu schätzen" und das meine ich genau so. Ich sehe das es angenommen wird und der geneigte Leser weiß das ich mich nicht immer zurückhalte wenn es um die Art geht wie einiges in der source von fhem geschrieben ist! 

Ich interpretiere dort nichts hinein, noch habe ich Interesse an einer Grundsatzdiskussion. Ich zitiere RichardCZ:

CommandAttr behauptet ja

Usage: attr [-a|-r] <name> <attrname> [<attrvalue>]

aber das stimmt nicht. Mindestens gilt [-a -r|-a|-r] - ich vermute, gleichzeitig append und remove zu machen ist nicht so sinnvoll? Der Code macht das aber wenn man es ihm sagt.

Rudi antwortet in den ersten 1.5 Sätzen sachlich und dann wird es polemisch und der Sache nicht dienlich:

...und nach etwas nachdenken sollte das jedem normalen Benutzer einleuchten.
Wenn es doch gemacht wird, und was Unerwartetes passiert, ist mir eigentlich egal, ich bin nicht da, um Leute aus dem Fenster springen abzuhalten.

Um dann sogleich noch darauf hinzuweisen, dass das alles vergebene Liebesmüh ist, da es viel, viel wichtigeres gibt:

Es wird z.Zt. hier irre viel Energie auf Sachen aufgewendet, die fuer den Anwender keinen Nutzen haben.

- aber: wenn Rudi schreibt dass es läuft dann stimmt das! Ich habe gestern zum ersten mal wieder mein Produktiv anfassen müssen (jessie -> buster). up-time 2.5 Jahre. Auf die Füße fallen sieht anders aus.

Ob das mal nicht zu kurz gesprungen ist? Schade, das hier so "eng" gedacht wird. Da wirken solch, sorry dafür, "Phrasen" wie "Ein guter Plan heute.." nicht gerade ermutigend. Da ich lange genug dabei bin, weiß ich, das es für FHEM keinen "Plan über heute hinaus gibt".

Auch ich könnte hier etliche Lobeshymnen auf FHEM (und vorallem die Entwickler) abfeuern. Ja, aber das hilft hier in Sache nicht weiter! Auch ich betreibe mehrere(!) vernetzte Produktivsysteme. Und sie laufen auch. Soll das jetzt die Begründung sein, dass wir hier ein "Codefreezing" a la "das lüppt, brauchen wa nicht anfassen..." zelebrieren?

Vor einigen Jahren hatte ich (u.a.) die neue Updateroutine zu FHEM beigesteuert. In dieser Zeit hatte ich externe Quellen für Module sowie Branches "stable", "devel" und "experimentel" (oder so) eingeführt. Da hättest Du (und andere, also auch ich) dann bei relevanten Systemen immer auf "stable" updaten können ohne, das man im Entwicklungszweig darauf hätte Rücksicht nehmen müssen. Die Diskussionen hierzu sind alle öffentlich und nachvollziehbar. Genau so wie "Internationalisierung", "Ticketsystem contra Google-Groups" (noch zu BerliOS), einheitliche Schreibweisen von Werten und Einheiten, etc., etc. Die Möglichkeit Branches zu nutzen, wurde dann nach einiger Zeit in einer "Nacht und Nebelaktion" von Rudi wieder ausgebaut, da nicht gewollt. So wie andere "Moderniesierungen" in den letzten rund 14 Jahren immer wieder mal gestartet und dann meist(!) (nicht immer) abgewiesen wurden. Die Erklärungen wiederholen sich. Wer es nicht glaubt: das FHEM Forum ist offen einsehbar.

Um es nochmal auf den Punkt zu bringen:
Es liegt mir fern, hier zu "richten". Ich möchte vermeiden, dass es zu einem Bruch kommt:
fhem.pl auf der einen Seite und hobo.pl auf der anderen. Der erste Schritt ist ja bereits getan:
https://gl.petatech.eu/root/HomeBot

Schon mal darüber nachgedacht, was das im Namen der Community (und der Maintainer) für FHEM bedeuten würde? Verlierer wären dann nämlich ALLE! Und hier hilft es dann wohl doch, auch einen "guten Plan" für Morgen (und nicht nur heute) zu haben. Keiner hat hier von "perfekt" geredet.

Abschliessend zitiere ich mich nochmal selbst:

...noch habe ich Interesse an einer Grundsatzdiskussion.

Ich will hier vereinen und nicht "Partei ergreifen".

Viele Grüße
Martin

[RichardCZ]

Martin, ich weiß nicht wie mein Text exakt bei Dir ankommt, aber Du solltest vorab wissen, dass ich Deine Sichtweise der Dinge (nicht nur in diesem Thread) für die ausgewogenste halte, die mir bislang im FHEM Forum begegnet ist.

Auch mir geht die eine oder andere Formulierung von Richard auf den Sack ("nicht unter Kontrolle")... Aber die andere Seite sollte doch auch mal offensichtliche und nachvollziehbare Optimierungsvorschläge oder Code-Reviews sachlich betrachten.. auch wenn Richard nicht jedesmal diplomatisch formuliert...

Ich weiß, man sollte auch Fakten diplomatisch formulieren, aber mir fällt nunmal für die folgenden Fakten keine diplomatischere Formulierung ein:

• Da wo FHEM heute hinsichtlich Development-Cycle ist (Versionskontrolle, CI/CD), war ich vor ca. 12 Jahren.
• Da wo FHEM heute hinsichtlich Codequalität ist (Code, Tests, Coverage), war ich vor ca. 18/19 Jahren.

Ich habe etliche viel diplomatischere Kollegen, die sicher  auf einem vergleichbaren Perl und Softwareengineering-Level sind, die FHEM kennen und passiv ignorieren "FHEM ist halt alt." (Thema beendet.) Oder aktiv ignorieren "Richard, tu Dir den Scheiss nicht an, das ist es nicht wert." (beides Reaktionen auf meine Vorschläge sie könnten doch mitmachen)

Wisst ihr wo der Hauptunterschied zwischen mir und diesen Kollegen ist? Ich bin a) oftmals bereit auch scheinbar hoffnungslose Schlachten aufzunehmen, b) wenn ich eine begründete Überzeugung habe, habe ich keine Scheu mich auch vor 1000 Leute zu stellen und zu sagen "Ihr liegt falsch".  Angenehm ist das nie, aber ich kann das ab.

Und genau deswegen ist hier keiner von den Kollegen aufgetaucht, sondern ich. Genau genommen ist auch offensichtlich keine bekannte Kapazität aus der Perl Community aufgetaucht, weil ab dem Augenblick ab dem er (oder sie - ein paar gibt es ja) erfahren hätte "CPAN - nehmen wir nicht, wir haben unsere tollen Cleanroom Implementierungen", wäre er/sie auf "Absatz kehrt" wieder entschwunden.

Das ist im übrigen - sollte das jemand nicht begriffen haben - 90% ein Seitenhieb auf die Perl Community und nur 10% auf die FHEM Community.

Was ich aber derzeit gefühlt erlebe ist, das sich Richard (manchmal aber eben nicht ausschliesslich "unvorteilhaft") einbringt, die andere Seite sich aber mehr mit dem "Wie er sich einbringt" als mit dem "Was er da macht" auseinander setzt.

Aber selbstverständlich. "Der Ton macht die Musik", "Es geht um das Wie, nicht um das Was."

Angeblich achtet man (nicht ich) nur zu 8% auf den Inhalt einer Präsentation und zu 92% darauf wie schön die Piecharts sind, wie angenehm der Vortragende auftritt und was er anhat. Irrsinn! Leute die das machen, werde ich weiter nach Kräften sabotieren. 

Ich teile ebenfalls nicht die Meinung, das der bestehende Code "nicht unter Kontrolle" sei. Ich begrüße jedoch ein schrittweises Refactoring ausdrücklich.

Ich bin bereit zu sagen, der Code ist teilweise unter Kontrolle, wenn wir bei der Testsuite eine Code Coverage von 40% hinbekommen. Das kann Dir jetzt auch auf den Sack gehen, aber die Code Coverage ist derzeit bei 0%. Das entspricht in etwa einem Blindflug bei Nacht und Nebel ohne Instrumente. Ich würde in so einem Fall nicht davon sprechen, das Flugzeug sei unter Kontrolle.

Klar, man kann einen erfahrenen Kapitän wie Rudolf haben, der dafür sorgt, dass nicht alle Passagiere sofort sterben und wie macht er das? Er sorgt dafür, dass sich am besten nix ändert. Gleiche Flughöhe, nix anfassen, alles bleibt wie es ist. Die Passagiere werden natürlich auch so sterben. Nämlich dann, wenn das Kerosin alle ist, aber bis dahin ist es noch lange hin. Heizung und Lüftung tut ja, ein paar Snacks sind auch noch da.

Ich sage auch nicht "Hey komm' Rudolf! Wer nicht wagt, der nicht gewinnt! Lass uns hier alles auf den Kopf stellen, wird schon irgendwie klappen." Das wäre nämlich jugendlicher Leichtsinn. Ich sage: "Lass uns versuchen ein Instrument nach dem anderen in Betrieb zu nehmen."

Ich würde mir wünschen darauf als Antwort nicht ein: "Wieso? Tut auch so." zu hören.

Gedanken über Regelprozesse in der IT zu machen. Dazu gehört nämlich auch, "Lifecycles" kontinuierlich zu verbessern. Und das impliziert eben nicht, das sie zwangsläufig auch schlecht sind. Wenn aber Verbesserungen gefunden werden, dann sollten sie nach einer sachlichen Prüfung doch auch Einzug halten und nicht mit einem Fingerzeig abgewiesen werden. Find ich nicht ok!

Dem kann ich nur zustimmen und sonst nix hinzufügen.

Den einen oder anderen Tod muss man dann auch mal sterben. Und vorallem sollten sich beide Seiten mal die Hand reichen und überlegen, wie man hier gemeinsam an einem Strick ziehen kann!

Wasch' mich aber mach mich nicht nass - davor sollte man sich hüten. Das geht nicht. zumindest weiß ich nicht wie.
Meine Hand reiche ich hier tagtäglich durch die "irrsinnige Energie" die ich hier reininvestiere. Das wird auch nicht ewig andauern (können).

[RichardCZ]

Und zu hobo.pl möchte ich sagen: Eine Abspaltung vom FHEM Projekt ist eigentlich das Letzte was ich möchte.
Derzeit ist das nix anderes als mein Playground.

Allerdings schneide ich da rigoros an Zöpfen herum und muss - aus Respekt vor dem FHEM Projekt - dem Kind einen anderen Namen geben (habe ich auch nicht großartig nachgedacht welchen - HomeBot war jetzt naheliegend), hobo ist eigentlich ein Witzchen: https://de.wikipedia.org/wiki/Hobo

Weil stellt euch vor, irgendjemand lädt hobo runter und schlägt dann hier auf und nervt mit Support.



Aber man muss auch offen sagen, dass es mir wohl leichter fallen würde meine Kollegen zu überzeugen bei hobo mitzumachen als bei fhem und auch ich bin nur ein Mensch. Wenn es hier vergebene Liebesmüh' sein sollte, dann kann ich ja - GPL sei dank - meine Schäufelchen in einen anderen Sandkasten tragen.

[Martin Fischer]

Martin, ich weiß nicht wie mein Text exakt bei Dir ankommt, aber Du solltest vorab wissen, dass ich Deine Sichtweise der Dinge (nicht nur in diesem Thread) für die ausgewogenste halte, die mir bislang im FHEM Forum begegnet ist.

Danke Richard, für die Ausführung..

Ich teile einige Deiner Ansichten und an dieser Stelle sind wir (nachweisbar) zu 100% seelenverwandt:

Ich bin a) oftmals bereit auch scheinbar hoffnungslose Schlachten aufzunehmen, b) wenn ich eine begründete Überzeugung habe, habe ich keine Scheu mich auch vor 1000 Leute zu stellen und zu sagen "Ihr liegt falsch".  Angenehm ist das nie, aber ich kann das ab.

Ich will hier aber nicht "Kommunikationstrainer" spielen... da wäre ich sicher komplett falsch... erlebe ich doch durch die gleiche Einstellung wie gerade zitiert, das ein oder andere Mal ähnliche Reaktionen... dies sind nun mal die Konsequenzen.. 

Dennoch erlaube ich mir eine Anmerkung: weniger "war ich vor ca. <xx> Jahren.", "Code nicht unter Kontrolle", etc. und es liest sich komplett anders. Dann steht nämlich die Sache wirklich im Vordergrund und nicht das von anscheinend vielen wahrgenommene "ich kann es besser".

Ich würde mir wünschen darauf als Antwort nicht ein: "Wieso? Tut auch so." zu hören.

Das teile ich zu 100%.

Meine Hand reiche ich hier tagtäglich durch die "irrsinnige Energie" die ich hier reininvestiere. Das wird auch nicht ewig andauern (können).

Streiche den Zusatz irrsinnige Energie, denn das ist wieder ein sidekick. Ansonsten nehme ich (und sicher auch andere) Deinen Einsatz (bezogen auf das "Was" ) wohlwollend wahr und befürchte aber letzteres.