Busware CC1101 wird nicht erkannt

[curt]

Der Magnetsensor hat heute erstmals nicht gemerkt, dass ich das Fenster aufmachte ... das fängt ja gut an ...

Oha - böse Falle.

Es geht um den magnetischen Fensterkontakt Homematic.

Ich habe einen Statusraum - mit meinen zwei harmlosen Meldern. In Statusraum steht, dass das Fenster closed sei. Ich denke bei mir: Ob ich das Fenster zu schnell öffnete?

Dann gucke in in den Raum mit den Logs - und bin erstaunt: Im Log wurde die Fensteröffnung akkurat erkannt.

Gna - was halte ich denn davon?

[rudolfkoenig]

* Mir fehlt bei den schicken Seiten immer der Knopf "START" - und anschließend die neue Seite "hat funktioniert!". Das ist (für mich) fröhliches Rätselraten: Hat? Hat nicht? Oft hat nicht.

Auf der FHEMWEB Detailseiten habe ich versucht die FHEM Befehle abzubilden, also man klickt sowas wie "attr devicename attrName attrVal" zusammen, wobei man nach dem Auswahl der Optionen fuer attrName/AttrVal auf attr klicken muss. Diese Zeile kann man genauso eintippen oder in einem notify/etc verwenden. Ein Start-Knopf (bzw jeweils eines fuer set/get/attr) finde ich unintuitiv, und eine Rueckmeldung, dass das Attribut in FHEM jetzt wirklich gesetzt ist auch, da die Werte auf der FHEMWEB-Seite entweder aktualisiert werden, oder eine neue Seite mit dem neuen Attribut geladen wird. Fuer Vergessliche gibt es zusaetzlich den roten Fragezeichen neben save.

Ich wehre mich aber nicht dagegen, wenn jemand ein besseres Frontend fuer die Konfiguration baut. Die meisten existierenden Alternativ-Frontends konzentrieren sich auf die Anzeige bzw. Schalten von Elementen.

* Ansich wäre ja wirklich schön, wenn auf der jeweiligen Seite ein Link auf den passenden Wiki-Artikel wäre, das würde vieles einfacher machen.

Die verpflichtende und auf der FHEMWEB-Detailseite verlinkte Doku ist der commandref Eintrag zum Modul. Die Wiki-Seiten sollten nach meiner Auffassung von einem Benutzer geschrieben werden, damit man auch eine weniger technische Sicht auf die Dinge hat, sie gibt es nicht zwingend zu jedem Modul.

** Http-Referer als Sicherheitsproblem: Ich kann ein kleines Script beisteuern, welches die Ausgangsseite de-referenziert.

Vor der Loesung wuerde ich gerne das Problem verstehen.

und etwas Grusel, weil das via Perl-Modul abgefackelt wird.

Ich verstehe die Abneigung gegen Perl nicht: mit jeder Programmiersprache kann man guten und schlechten Code schreiben. In FHEM existiert sowas sogar parallel nebeneinander. Das verwendete IO::Socket:SSL Perl-Modul ist (soweit ich es verstehe) ein relativ duenner Wrapper ueber openssl, was in C geschrieben ist.

Als Erstes scheiterte ich an https://wiki.fhem.de/wiki/Raspberry_Pi_%26_HTTPS -

Referenz ist mAn der commandref Eintrag fuer das HTTPS Attribut (https://fhem.de/commandref.html#HTTPS)

Enable HTTPS connections. This feature requires the perl module IO::Socket::SSL, to be installed with cpan -i IO::Socket::SSL or apt-get install libio-socket-ssl-perl; OSX and the FritzBox-7390 already have this module.
A local certificate has to be generated into a directory called certs, this directory must be in the modpath directory, at the same level as the FHEM directory.

   
• mkdir certs
  cd certs
  openssl req -new -x509 -nodes -out server-cert.pem -days 3650 -keyout server-key.pem

Wenn das missverstaendlich oder falsch ist, dann korrigiere ich es als Modulautor gerne.

Was bitte sind FHEM-Clients?

Ich meinte damit die anderen Web-Frontends und Programme auf Mobilgeraeten, siehe https://fhem.de/#Screenshots

Der CUL-Jargon ist eins meiner größen Probleme: HA-Protokoll, culfw, 8.000 weitere derartige Vokabeln ... eine höchst zeitaufwändige Sache, die oft mit Rumstochern im Nebel verbunden ist, was ja nicht ungefährlich ist.

Ich fuerchte das ist die Realitaet in der HeimAutomatisierungs (aka HA) -Szene, und wir werden es als ein kleiner Haufen von Freiwilligen auch nicht aendern. Leider kenne ich keine Alternativen, die alle Anforderungen (sicher und einfach, kein cloud) wesentlich besser als FHEM erfuellen.

[curt]

Hallo allerseits,

ich bin ein wenig in Eile, das bitte zu entschuldigen. Ich antworte daher nur kurz.

Als erstes ist festzuhalten, dass ICH hier der newbie bin. ICH muss lernen. Ich habe nicht die Aufgabe, irgendwem Ratschläge zu erteilen. Nachdem das geklärt ist:

Ja, ich habe große Probleme mit dem Interface: Ich hatte beispielsweise nicht verstanden, dass ich NACH den Einstellungen auf ATTR klicken muss - ich klickte immer vorher, weil ich dachte, dass sich da vielleicht was tut.

Ich bin nun wirklich seit dem ersten Tag dabei (bei diesem Internetz). Ich habe alles erlebt. Und ich habe eins gelernt: "Von Google lernen - heißt siegen lernen": Immer aus Nutzersicht denken, immer so einfach wie irgend möglich.

Ja, mir ist der Widerspruch zur Entwicklersicht sehr deutlich klar.

Nein, ich kann kein anderes Nutzer-Interface schreiben. Ich bin doch heilfroh, dass ich nun ansatzweise verstehe, wie das hier funktioniert. Frage mich in einem Jahr bitte nochmals.

Der Bezug PERL war missverständlich: Ich finde Perl (wenn es gut geschrieben ist) ausgezeichnet. Ich habe lediglich keinerlei Erfahrung mit dem konkreten Modul. An dem Befehlsstring im Wiki-Eintrag ist nichts auszusetzen unter der Bedingung, dass die neueste Betriebssystemversion und alle Updates vorliegen. Aus meiner Sicht ist der Hinweis auf Gegenprüfung (erwähntes Browser-Plugin) zu ergänzen.

Die "commandref" Hinweise erschließen sich mir nicht. Ich habe da mal geklickt, war erschlagen und habe dann beschlossen, da nie wieder zu klicken.

Als Nutzer brauche ich doch was ganz anderes: Ich bin auf einer Config-Seite, habe ein Ziel, sehe aber zig Schalter und hunderte "klick mal runter". Ich habe mein Ziel immer noch - aber nun noch weniger Plan. Ideal wäre aus meiner bescheidenen Sicht, wenn dieser ganz konkrete commandref-Eintrag auf der ganz konkreten Einstellungsseite auch als Link vorhanden ist. Und falls es eine Wiki-Seite gibt: Die natürlich auch.

Hierzu: "(aka HA) -Szene"
Genau da ist das Problem.

Jede Berufsgruppe tarnt sich und täuscht Wichtigkeit gegenüber Außenstehenden vor. Zig hundert Vokabeln, die kein Außenstehender versteht. Man kennt das von Ärzten, Anwälten und aus der eigenen Berufsgruppe auch.

Ich darf da wieder auf Google verweisen, ich mag die nicht sooo sehr. Faierweise muss man sagen, dass sie genau dieses aufbrachen. Und davon können wir (vermutlich darf ich noch nicht "wir" sagen) lernen.

Lieber Rudi (falls ich Dich so ansprechen darf),
ich pisse nicht ans Bein, selbst wenn es auf den ersten Blick so aussehen mag. Ich bin neugieriger Newbie. Der sich erstmals in seiner knappen Freizeit mit dem Projekt rumschlägt. Erfolge, Rückschläge, immer wieder.

Ich hatte in einem anderen Forum mehrere Empfehlungen für mehrere ähnliche Projekte. FHEM fand ich (auch wegen Perl) das interessanteste. Darum bin ich hier.

Freundliche Grüße an alle.

[RaspiLED]

Hi,
Kurz weil unterwegs:
Es gibt einen Link auf die Commandref in jedem Device unten rechts auf das richtige Detailmodul!
Ansonsten Willkommen Verbesserungen umzusetzen wird noch lieber gesehen als Lösungen zu beschreiben und das alles ist besser als nur Kritik [emoji41]
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[rudolfkoenig]

Ich bin neugieriger Newbie. Der sich erstmals in seiner knappen Freizeit mit dem Projekt rumschlägt. Erfolge, Rückschläge, immer wieder.

Das habe ich schon erkannt, ich sehe sowas nicht zum ersten mal. Viele der Newbies sind der Ansicht, dass "wir" (die FHEM-Entwickler / -Tester / -Supporter) unsere (im Gententeil zu diesen Newbies unendliche) Zeit dafuer einsetzen wollen, Anfaengern das Leben leicht zu machen, wir wissen nur nicht, wie. Und die Sache kann kann ja nicht schwer sein, man muss ja nur das an der richtigen Stelle dokumentieren, was dieser Newbie gerade erreichen will, was er ja schliesslich auch selbst als Newbie nach lange Suche und Nachfrage gefunden hat.

Ich kann nicht fuer die Anderen sprechen, aber das ist nicht meine hoechste Prioritaet. Ich helfe gerne mit FHEM-Framework, Vorgaben, etc, falls jemand FHEM einsteigerfreundlich zu machen federfuehrend uebernimmt. An dem commandref Beispiel sieht man gut, wer _meine_ Prioritaet ist: Entwickler, und Leute mit Geduld, sich mit FHEM zu beschaeftigen.

Dein Vergleich mit google hinkt: ich habe nicht vor, FHEM als _die_ HA Loesung fuer die Masse zu etablieren, damit ich daraus Geld mache, und reich werde. Ich ueberlasse die Masse gerne Google & co, mit Ignoranten in der Freizeit zu diskutieren muss nicht sein.

ich pisse nicht ans Bein, selbst wenn es auf den ersten Blick so aussehen mag.

Das habe ich nicht so empfunden, sonst haette ich nicht geantwortet.

[curt]

Es gibt einen Link auf die Commandref in jedem Device unten rechts auf das richtige Detailmodul!

Danke für den Hinweis, das hatte ich tatsächlich übersehen. Sehr schön.

Ansonsten Willkommen Verbesserungen umzusetzen wird noch lieber gesehen als Lösungen zu beschreiben und das alles ist besser als nur Kritik [emoji41]

Natürlich werde ich mich aktiv einbringen. Ganz realistisch: Davon bin ich fachlich momentan weit entfernt.

Das habe ich schon erkannt, ich sehe sowas nicht zum ersten mal. Viele der Newbies sind der Ansicht, dass "wir" (die FHEM-Entwickler / -Tester / -Supporter) unsere (im Gententeil zu diesen Newbies unendliche) Zeit dafuer einsetzen wollen, Anfaengern das Leben leicht zu machen, wir wissen nur nicht, wie.

Ich hatte da sicher sehr unglücklich formuliert, das ist mir schon klar. Ich hatte versucht zu beschreiben, wo meine größten Hürden sind, waren. Ich meine, dass ich sinngemäß schrieb, dass das primäre Interface sicher aus guten Gründen so sei. Falls ich jemandem auf die Füße getreten sein sollte: Das war nicht meine Absicht, ich bitte um Entschuldigung.

Ich habe noch etwas fachliches:
Nun wollte ich mein neu erworbenes Wissen gleich einsetzen - und scheiterte schon wieder: https://192.168.x.y:8083/fhem?detail=WEBphone - den Port kann ich da offenbar nicht ändern - oder habe ich mich da zu dumm angestellt? Ich habe den dann (was ich ja nicht mehr darf) direkt in fhem.cfg geändert.

Bitte noch eine Frage:
Ich suche mir die Finger nach einem weblog / access.log wund. So etwas ähnliches scheint es zu geben, siehe https://forum.fhem.de/index.php?topic=71710.0

Im FHEM-log ist bei mir nichts. Auch unter /var/log finde ich nichts. Ich habe im Wiki gesucht (schwierig, weil da zig verschiedene Logs erörtert werden, ich dachte, dass ich das vielleicht unter https://192.168.x.y:8083/fhem?detail=WEBphone für den POrt 8083 einschalten könnte.

Kurz und gut - ich scheitere. Was mache ich denn nun schon wieder falsch?

Ich möchte mich herzlich für die großartige Unterstützung bedanken und wünsche ein schönes Wochenende.

[krikan]

Ich habe noch etwas fachliches:
Nun wollte ich mein neu erworbenes Wissen gleich einsetzen - und scheiterte schon wieder: https://192.168.x.y:8083/fhem?detail=WEBphone - den Port kann ich da offenbar nicht ändern - oder habe ich mich da zu dumm angestellt? Ich habe den dann (was ich ja nicht mehr darf) direkt in fhem.cfg geändert.

https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM oder https://fhem.de/Heimautomatisierung-mit-fhem.pdf (z.B. Seite 28) lesen, die überall auf den FHEM-Webseiten und im Forum als Einsteigerlektüren angepriesen werden, dann braucht man auch nicht direkt in der fhem.cfg editieren (-> Klick auf DEF in der Device-Detailansicht hilft)  .

Gruß, Christian

[curt]

Waaaa ...
Ich schiebe es auf meine soeben erfundene Schwarz-Grün-Schwäche: Ich habe selektiv nur auf PORT geschaut und auf die Device specific help.

Bleibt nur noch das Problem mit dem (bei mir?) nicht vorhandenen Weblog.

Herzlichen Dank, Christian!

[RaspiLED]

Hi,
was ist ein Weblog? Meinst Du das /opt/fhem/log/fhem*.log
Welches Du im Menu links unter Logfile ansehen kannst? Oder meinst Du die Extralogs pro Device? Die stehen unter dem Device als probably associated...
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[curt]

was ist ein Weblog? Meinst Du das /opt/fhem/log/fhem*.log

Negativ.

Oder meinst Du die Extralogs pro Device? Die stehen unter dem Device als probably associated...

Bin nicht sicher, vermutlich negativ. Zwar ist Webphone auch ein Device - aber da finde ich nichts.

Ich meine folgendes:
Mit FHEMWEB ist faktisch ein Webserver am Werkeln. Webserver schreiben normalerweise für jeden Port einzeln ein access-log und ein error-log - jeweils also zwei Dateien je Port. Das typische eingeführte Format für access-log sieht so aus (nur ein access als Beispiel):

141.8.141.141 - - [16/Jun/2017:21:21:31 +0200] "GET /robots.txt HTTP/1.1" 200 312 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)"

Das (und eben in diesem Format) zu haben wäre der Traum - weil darauf weitere Tools aufsetzen.

Es scheint in FHEM etwas anderes zu geben bzw. gegeben zu haben, ich fand einen Forenbeitrag in einem untypischen Logformat. Da ist der Ablageort nicht klar, möglicherweise /opt/fhem/log/fhem*.log . Aber dort finde ich keine diesbezüglichen Einträge.

[rudolfkoenig]

Mit FHEMWEB ist faktisch ein Webserver am Werkeln.

Ja, aber einer, dessen eigentliche Aufgabe ein Web-Frontend fuer FHEM zu implementieren ist. Vom Protokoll ist nur das implementiert, was fuer diese Aufgabe benoetigt wird.

Webserver schreiben normalerweise für jeden Port einzeln ein access-log und ein error-log - jeweils also zwei Dateien je Port.

Das gibts fuer FHEMWEB so nicht, du kannst etwas mehr Info im gemeinsamen FHEM-Log schreiben, wenn du verbose fuer die in Frage kommende FHEM-Instanz erhoehst. Eine Ausgabe in einer separaten Datei in apache-log Format habe ich nicht vor, es sei denn irgendwer ueberzeugt mich, dass dadurch spannende Sachen moeglich werden.

FHEMWEB ist als CGI-Skript fuer Apache geboren. Da ich es aber auch auf dem Fritzbox 7170 laufen lassen wollte, der keinen CGI-faehigen Webserver hatte, habe ich den Webserver-Teil dazugebaut. Die CGI-Version hat Boris noch 'ne Weile parallel weitergepflegt, das ist aber auch laenger her. Da es fuer den durchschnittlichen FHEM-Benutzer deutlich einfacher ist, FHEM so zu betreiben, habe ich auch nicht vor, den Webserver aufzugeben. Das Web-Frontend koennte aber in JavaScript implementiert werden, und FHEMWEB damit zu einen reinen Webserver degradiert werden.

[curt]

Ich erzähle als Newbie erstmal, wie es bei mir weiterging:
Inzwischen habe ich weitere Magnet-Fenster-Sensoren, Temperatur-Sensoren und Steckdosen geordert: Wenn meine Frau die Rechnungen sieht, wird es wohl Ärger der gehobenen Klasse geben: Sportliche Preise ...

Den Port für Webphone habe ich verändert, hochgelegt. Portforwarding an, alles von außen getestet. Das sieht richtig gut aus. Das Ganze dann live auf Wochenendausflug.

Und erstmal unabhängig von FHEM muss ich mir einen Rasenmäh-Roboter anschaffen, aus verschiedenen Gründen wird es wohl ein
Husqvarna Automower. Und siehe da - für dessen Automation gibt es eine Community und ein Modul: https://technikblog.ch/2016/08/husqvarna-automower-mit-wlan-modul-robonect-nachruesten/ und http://robonect.de/index.php . Auch FHEM wird dort erwähnt. Im hiesigen Forum aber nicht - da lauert also Arbeit.

Ja, aber einer, dessen eigentliche Aufgabe ein Web-Frontend fuer FHEM zu implementieren ist. Vom Protokoll ist nur das implementiert, was fuer diese Aufgabe benoetigt wird.

Mir gefällt das.

Da es fuer den durchschnittlichen FHEM-Benutzer deutlich einfacher ist, FHEM so zu betreiben, habe ich auch nicht vor, den Webserver aufzugeben.

Es gibt auch keinen für mich erkennbaren Grund dafür.

Das Web-Frontend koennte aber in JavaScript implementiert werden, und FHEMWEB damit zu einen reinen Webserver degradiert werden.

Davon halte ich nun gar nichts. Absolut nichts.

Das gibts fuer FHEMWEB so nicht, du kannst etwas mehr Info im gemeinsamen FHEM-Log schreiben, wenn du verbose fuer die in Frage kommende FHEM-Instanz erhoehst.

Auf 5 gestellt - und gesehen, dass das was anderes macht.

Eine Ausgabe in einer separaten Datei in apache-log Format habe ich nicht vor, es sei denn irgendwer ueberzeugt mich, dass dadurch spannende Sachen moeglich werden.

Dann wollen wir mal:

Zuerst: Es ist nicht "das Apache-Format", sondern das Common Log Format, siehe https://en.wikipedia.org/wiki/Common_Log_Format - es ist allgemein für Webserver akzeptiert. Zig Auswertungstools, Alarmtools usw, setzen da an, nutzen das als Input.

Es ist die Frage, welche Seite man betrachten will:
"verbose 5 " liefert die allgemeine Innensicht, wohl gut nutzbar für Debugging. Hier ist der Webserver ein Aktor (ist das so richtig im Sprachraum?) des Gesamtprojekts. Insoweit sind auch die verschiedenen zeitlichen Stati nur eines Requests auf ganz verschiedene Zeilen verteilt. Für den Debuggingfall notwendig und hilfreich.

Die Außensicht auf einen Webserver [¹] ist (u.a.) die Sicherheitssicht:
Da will ich in nur einer Zeile den kompletten Request sehen: Wer wann was wieso (Referer) und mit welchem Ergebnis. Und wenn ein Status 4xx oder 5xx auftaucht, kommt das zusätzlich in error-log.

Und da hat wirklich jeder Request aufzutauchen, Konstruktionen wie

    my $re = "^(127|192.168|172.(1[6-9]|2[0-9]|3[01])|10|169.254)\\.|".

halte ich für ein Webserver-Log für fragwürdig.

Das Ganze passiert in TcpServerUtils.pm und ansich scheint alle da, was man dafür bräuchte.

Habe ich es geschafft, Dich zu überzeugen? Komm, sag schon ja.

Eine Frage noch:
Spräche denn etwas dagegen, dass langfristig der komplette Log-Kram (also wirklich alles) nach /var/log/ umzieht? Dort würde das alles ja standardkonform hingehören.

Ich bin schon wieder leise - in dieser Woche kommen die neuen Sensoren, ich hab dann gut zu tun. Ich wollte aber antworten. Nicht böse sein, ich bin Newbie. Ich lerne fleißig.

[¹] Das Grundprojekt hat in dieser Sichtweise drei Webserver: WEB, WEBphone, WEBtablet

[amenomade]

Eine Frage noch:
Spräche denn etwas dagegen, dass langfristig der komplette Log-Kram (also wirklich alles) nach /var/log/ umzieht? Dort würde das alles ja standardkonform hingehören.

Ich hab lieber die Logs im Verzeichnis von Fhem.

Aber das kannst Du beliebig in deiner Konfiguration modifizieren. Du musst nur die Definition der entspr. Filelogs ändern. Und Du kannst auch das Attribute logdir im global nutzen.

[rudolfkoenig]

Im hiesigen Forum aber nicht - da lauert also Arbeit.

Es gibt ein FHEM/86_Robonect.pm. Das Aufsteckmodul habe ich auch seit ein paar Monaten im Einsatz: Einbau trivial, und bisher keine Probleme. Arbeit war das kaum

Davon halte ich nun gar nichts. Absolut nichts.

Und die Begruendung? JavaScript-Allergie?

halte ich für ein Webserver-Log für fragwürdig.

Das hat auch nichts mit dem Log an sich zu tun, sondern ist eine Pruefung, ob das Frontend ungeschuetzt im freien Internet haengt. Will naemlich nicht als Negativbeispiel in PlusMinus oder Co landen.  Wenn du eine Alternative hast...

Habe ich es geschafft, Dich zu überzeugen? Komm, sag schon ja. (https://forum.fhem.de/Smileys/default/wink.gif)

Nein, ich habe noch keine Begruendung, sondern nur Allgemeinplaetze gehoert.

Spräche denn etwas dagegen, dass langfristig der komplette Log-Kram (also wirklich alles) nach /var/log/ umzieht? Dort würde das alles ja standardkonform hingehören.

Ja, das war am Anfang so (deblint konform), ich habe es aber wegen der gesunkenen Admin-Faehigkeit des durchscnittlichen FHEM-Users geaendert. Weitere Vorteile: Umzug auf anderes OS oder Backup ist trivial. Das betrifft aber nur die Voreinstellung, die deblint konforme Konfiguration habe ich nicht mit Absicht zerstoert, nur seit laengerem nicht mehr getestet. Siehe auch den Anfang der Makefile.

Nicht böse sein, ich bin Newbie. Ich lerne fleißig.

Bin nicht boese, sonst wuerde ich nicht antworten. Und bitte meine Ablehnung nicht als Feindseligkeit betrachten. Ich habe kein Problem mit Neuerungen, muss aber auch die bisherigen Benutzer, die sich an etwas gewohnt haben, beruecksichtigen, und auch die Gruende, warum etwas so ist, wie ist, nicht vergessen. Tanker und so.

[curt]

Es gibt ein FHEM/86_Robonect.pm. Das Aufsteckmodul habe ich auch seit ein paar Monaten im Einsatz:

Sehr-sehr schön- Und das Du selbst so ein Teil im Einsatz hast ist ja für mich der Traum ansich. Ich wusste schon, warum ich genau FHEM wählte.

Leider konnte ich das weder mit der Forum-Suche erkennen und im Wiki gleich gar nicht: Da liest es sich so, als ob im Grunde nichts ginge: https://wiki.fhem.de/wiki/M%C3%A4hroboter_%C3%BCberwachen

Einbau trivial, und bisher keine Probleme. Arbeit war das kaum

Ich habe das ja noch nicht, der Besichtigungstermin ist erst noch. Wenn das alles steht, werde ich den Fachbetrieb fragen, ob er mir das einbaut.

Und die Begruendung? JavaScript-Allergie?

Ja. Und zwar begründete ... ich könnte Dir Sachen erzählen. Schon von daher finde ich den "altmodischen" prozessorientierten Ansatz via Perl so gut. Das war ja der Grund, mich für FHEM zu entscheiden.

Nein, ich habe noch keine Begruendung, sondern nur Allgemeinplaetze gehoert.

Dann wird das jetzt gestempelt, gesiegelt und abverfügt zum Archiv. Unten nochmals ganz kurz dazu.

Ja, das war am Anfang so (deblint konform), ich habe es aber wegen der gesunkenen Admin-Faehigkeit des durchscnittlichen FHEM-Users geaendert. Weitere Vorteile: Umzug auf anderes OS oder Backup ist trivial.

Ansich ist das auch logisch. Lediglich bei den Logs greift die nicht. Bzw. sie greift nur dann, wenn nach Umzug unter /var/log/ Zugriffsrechte zum erstellen fehlen. Aber ich habe ja von @amenomade gelernt, dass ich das im Falle des Falles allein bewerkstelligen könnte.

Bin nicht boese, sonst wuerde ich nicht antworten. Und bitte meine Ablehnung nicht als Feindseligkeit betrachten.

Selbstverständlich nicht. Ich bin Dir dankbar.

Ich habe kein Problem mit Neuerungen, muss aber auch die bisherigen Benutzer, die sich an etwas gewohnt haben, beruecksichtigen, und auch die Gruende, warum etwas so ist, wie ist, nicht vergessen. Tanker und so.

Ja, überhaupt keine Frage.

Vielleicht gibt es doch ein Missverständnis. Denn ich habe derart gar nicht angeregt. Was mit heutigen Stand wo geloggt wird, dass soll überhaupt nicht angefasst werden - das soll so bleiben.

Das Logfile (pro Webserver) im Common Log Format war in meinem Denken zusätzlich gedacht.

Nun ist erstmal Ruhe von meiner Seite: Ich erwarte einige Lieferungen. Und dann muss noch der MähBot her, die Wiese sieht wild aus.