[WIP] reloaded 2020: "Einsteiger-pdf" - Mitwirkende gesucht

[Beta-User]

Hallo zusammen,

2014 ist die letzte Version der "Heimautomatisierung mit fhem" erschienen. Seitdem ist nicht nur Zeit ins Land gegangen, es hat sich auch manches getan in "FHEM-Land"...

Uli Maaß hatte das Projekt bis Version 4 geschultert, eine riesige Leistung, für die ihm auch heute noch mein großer persönlicher Dank gilt - ohne "das pdf" hätte ich mich in FHEM-Land wohl nicht zurechtgefunden.

Zwar kann man zwischenzeitlich auch Literatur zu FHEM kaufen (insbesondere pah's Buch ist sehr zu empfehlen), aber zu einem Community-Projekt gehört jedenfalls nach meinem Geschmack auch eine einführende Doku aus der Community selbst, die die Zusammenhänge wenigstens halbwegs so darstellt, dass man sie als interessierter Einsteiger - ohne allzuviel IT-Hintergrundwissen - verstehen kann (nun ja: hoffentlich... ).

Im nächsten Post hier findet ihr daher ein pdf (und eine E-Book-Fassung) mit dem Versuch, das Thema anzupacken - das ist in weiten Teilen allerdings noch unvollständig. Teilweise ist es einfach noch nicht geschrieben, teilweise muß manches auch "außen vor" bleiben. Aufgrund der Fülle von Optionen, die es in FHEM gibt, muß man m.E. die Themen irgendwie begrenzen, und es liegt in der Natur der Sache, dass dabei manches unter den Tisch fällt, das vielleicht auch noch wichtig oder "nur" wünschenswert gewesen wäre.

Mein Plan ist, das im Lauf des Jahres vollends "irgendwie" zum Abschluß zu bringen, und je mehr ggf. bereit sind, an dem Projekt mitzuwirken, desto "besser" und vollständiger kann es werden. Was man bereits jetzt erkennen können sollte, ist

   
• in etwa das, was an Themen darin zu finden sein soll, (allerdings teils auch für die Zukunft nur kurz angerissen bzw. als Stichwort zum "woanders weiterlesen");
• die "Tonlage", in der ich das gerne gestalten will und
• der "Erwartungslevel" an das "Publikum", was die Übertragung von Beispielen auf die eigene Installation usw. angeht.

Wer mitwirken will, ist herzlich willkommen! Es sollte aber folgendes klar sein:

   
• Es soll in absehbarer Zeit auch "fertig" werden. Das bedeutet, dass notfalls jemand entscheiden muß, wie und was gemacht wird, was reingenommen wird, was nicht usw, usf.. Bis auf weiteres bin dieser "jemand" ich...
• Das Ergebnis gehört der Community!

Die files liegen heute schon auf dem Server des FHEM e.V.. Ich behalte mir vor, die zu eigenen Zwecken zu nutzen (v.a. die Teile, die ich am Ende selbst von A-Z machen mußte!), und jeder andere darf das - ganz im Sinne der GPL - auch tun, (nicht nur zitateweises) Kopieren zu kommerziellen Zwecken ist jedoch ausdrücklich nicht erlaubt.
Sollte ich irgendwann keine Lust mehr haben, den "jemand" in obigem Sinn zu machen, oder das aus anderen Gründen nicht mehr übernehmen können, kann der Vereinsvorstand jemand anderes benennen. Es würde mich in diesem Fall freuen, wenn es im begonnen Sinne weitergeführt wird, aber eine Auflage oder Bedingung ist das nicht.

Vorab jedenfalls mal: Viel Spaß beim Lesen!

Gruß,

Beta-User

[Beta-User]

In diesem Post findet ihr jeweils die aktuellen Fassungen.

Plan wäre, die ca. alle 1-2 Wochen (je nach Fortschritt) zu erneuern.

Statistic:
Downloads ca.:

pdf: 36
epub: 5
zip: 0

[Beta-User]

Das ganze ist ein größeres Projekt - leider habe ich aber keinen Plan, wie man sowas am besten organisiert... An der Stelle also erst mal ein paar Hintergrundinfos zu den verwendeten Tools und zu dem, was eigentlich rauskommen soll:

   
• Ich bin ein "analoger" Mensch, dem es hilft, wenn er ein "Handbuch" in Papier neben die Tastatur legen kann: Da kann man reinkritzeln, Zettel reinkleben, Ecken wegknicken und notfalls das Vesperbrot darauf deponieren... Ergo: Es muß eine druckbare Version geben, wichtigstes Zielformat ist damit "pdf". Dass es ein pdf sein soll, in dem (auch interne) Links in der elektronischen Fassung funktionieren, versteht sich von selbst...
• "eigentlich" wäre das auch gut im Wiki aufgehoben gewesen, aber: Es ist ziemlich steinig, aus mehreren Wiki-Artikeln ein hübsches pdf zu generieren (falls jetzt jemand schnell eine Suchmaschine anwerfen sollte, um dann auf welche Tools auch immer hinzuweisen: ja, die gibt es, aber man muß die auch bedienen können und das Ergebnis sollte "gut" sein; was ich bisher gesehen habe, hat mich nicht wirklich überzeugt, und bis auf weiteres ist mein Lernbedarf an derartigen Tools gedeckt... Will sagen: Wenn, dann bitte "mundgerchte" Alternativ-Vorschläge, die getestet sind! (PS: Das ist ausdrücklich keine Kritik an denen, die bis hierher Vorschläge und Hinweise gegeben haben!)).
• Kleinster gemeinsamer Nenner ist - jedenfalls nach bisherigem Stand der Erkenntnisse - "Markdown". Das ist sehr nah an dem, was Wiki-Autoren kennen, man hat z.B. mit Okular oder der Markdown-Viewer Extension für notepad++ bzw. Chrome auf allen Systemen Optionen beim Schreiben zu sehen, wie es so in etwa ausschaut, und - vor allem - man kann Markdown-Files recht einfach in - im Prinzip - beliebige Zielformate konvertieren. Neben der E-Book-Fassung (epub) sollte es also auch möglich sein, irgendwann eine Wiki-Fassung daraus zu generieren.

Im Moment gibt es für (fast) jedes Kapitel eine eigene .md-File.
Das Tool, über das - jedenfalls im Moment - die ganzen Umwandlungen laufen, heißt "pandoc", und mit den richtigen "tweaks" scheint die einzige ernsthafte Einschränkung die zu sein, dass man nicht einfach Bilder nach links oder rechts positionieren kann und den Text drumrum brechen (Falls jemand das in seinem Browser/Viewer anschaut, html-code verwendet und das nicht versteht: Ja, man kann Markdown generieren, der dann insbesondere in einem Browser das gewünschte Ergebnis liefert, aber man kann das afaik nicht in der Form in ein pdf drucken, weil insbesondere "class" von pandoc unterdrückt wird... Vermutlich kommt da auch manches Problemchen mit den Bildern in der E-Book-Fassung her.).

   
• Wiki: Wäre also dann mittelfristig auch ein wichtiges Zielformat.

Wer mitwirken will, darf sich bitte einfach melden, und wir finden dann schon einen Weg... Wie genau, wird wohl auch davon abhängen, wie viele es sind und wer was macht, im einfachsten Fall läuft das als Textfile-Anhang über das Forum.

Aber auch hier gilt: zielführende Vorschläge, die einfach und mit der bestehenden Infrastruktur umzusetzen sind: Gerne!




Hier noch ein kurzer Auszug, wie das im Markdown-Quelltext aussieht:

Code Auswählen Erweitern

# FHEM-Grundlagen

## Installation
Die Installation hatten wir ja eigentlich vorher schon gemacht: Es gibt entweder irgendwo einen Perl-Interpreter auf Deinem Windows-PC, oder Du hast ein Linux-System, auf dem die entpackten FHEM-Dateien liegen, oder einen Debian-basierten Server (ohne GUI!), auf den Du mit *ssh* zugreifen kannst, und auf dem Du entsprechend des *easy way* nach [https://debian.fhem.de](https://debian.fhem.de) FHEM installiert hast. 

## Systemüberblick
Schauen wir uns also FHEM mal gemeinsam an. Da es in einer leeren Installation wenig zu sehen gibt, nehmen wir dafür zunächst einmal die Demoversion. 
Um diese zu starten, muss - sofern Du FHEM mit dem Debian-Paket installiert hast - FHEM zunächst einmal beendet werden. Dazu tippst Du auf der Linux-Konsole `sudo service fhem stop` ein und gibst das Kommando frei, falls Du nach einem Passwort gefragt wirst. 
 
Dann wechselst Du in das Verzeichnis, in dem die Datei *fhem.pl* liegt. Nach einer Debian-Installation ist das */opt/fhem*, mit `cd /opt/fhem` kommst Du auf der Linux-Konsole direkt dort hin. Dann startest Du FHEM mit `perl fhem.pl fhem.cfg.demo`. 
 
Auf einem Windows-PC, bei dem FHEM im Verzeichnis `E:\fhem` liegt und der Perl-Interpreter in einem Unterverzeichnis `E:\fhem\perl\perl\bin\`, kann man - wieder aus dem FHEM-Verzeichnis `E:\fhem` heraus - FHEM so starten: `perl\perl\bin\perl fhem.pl fhem.cfg.demo` 

![FHEM-Start von der Windows-Kommandozeile][demostart_win] 

[Beta-User]

Diesen Post soll jeweils zu entnehmen sein, wer grade an was dran ist und (eventuell) für welche Themen grade jemand gesucht wird...

1. "pandoc" (oder Alternativen)

   
• md to pdf und Bilder:
  Wenn jemand damit wirklich Erfahrung hat: Interesse...!
• dto. für die Generierung der Wiki-Seiten - relative Links usw. passend setzen

2. E-Book-Fassungen
Das epub ist bisher nur ein Nebenprodukt, das sich recht einfach generieren läßt. Eventuell wird es aber "besser", wenn jemand den Quelltext daraufhin optimiert, der Erfahrung hat. V.a. die Darstellung/Positionierung der Bilder ist da ein Thema...

3. Ganz viele inhaltliche Themen:
Obwohl ich schon einiges gesehen habe, nutze ich insgesamt vieles doch nicht - angefangen bei Sprachsteuerung... Vor allem in diesen Teilen wäre Zuarbeit wirklich sinnvoll.

4. Homematic (CUL_HM)- Anhang des heutigen "Einsteiger-pdfs":
Ein sehr wertvolles Dokument, das aber mMn. besser je als eigenständiges Dokument in einem angepinnten Thread im Homematic-Bereich sowie (mittelfristig) getrennt im Wiki zu finden sein sollte.

5. "Artwork"

   
• Eine hübsche Titelseite wäre cool... (Und: Wie bindet man die jeweils am einfachsten ein?)
• Wir werden das eine oder andere Schaubild brauchen, z.B. für direkte vs. indirekte Verbindungen zwischen Geräten
• meine Screenshots sind so nebenbei entstanden, und "im Prinzip" ok, aber eben in vielen Details verbesserungsfähig. Schön wäre es, wenn sich da jemand um ein noch einheitlicheres Layout bemühen könnte, ggf. einheitliche Hinweispfeile auf das grade besprochene Element einfügen usw. usf...

Ihr seht also: viel zu tun...

[Schotty]

Dann hier nochmal 'offiziell' & für alle:
Ich habe mit den md-Dateien und einer anderen Konverterlösung rumgespielt, die ich auch für mein eigenes Handbuch (s. Signatur) nutze.
Das epub habe ich mittels eines Onlinekonverters erstellen lassen (btw: Kap02 wird mir bei deinem epub nicht angezeigt @Beta-User).
Sieht imho insgesamt schon etwas besser aus, allerdings sind teilweise nicht-funktionierende Links innerhalb des Textes noch ein Problem. Ich hatte diesbzgl in eigenem Interesse schonmal im Forum angefragt (https://forum.fhem.de/index.php/topic,106850.0.html), leider hatte niemand geantwortet. Aber vielleicht ist das FHEM-Einsteiger-PDF ja eine 'bessere' Motivation

Eingesetzte Konverter:
- md -> pdf: https://github.com/yakivmospan/github-wikito-converter
- das daraus erzeugte html -> epub: https://ebook.online-convert.com/de/umwandeln-in-epub

Wiki: Wäre also dann mittelfristig auch ein wichtiges Zielformat.

Just my 2ct:
Wie an anderer Stelle schonmal erwähnt wäre es meiner Meinung nach sinnvoll, die Wiki-Erstellung bzw Konvertierungsmöglichkeiten von md->mediawiki bereits jetzt am Anfang zu testen und idealerweise eine akzeptable Lösung zu finden. Wenn später erstmal zig Seiten Text formatiert vorliegen und man dann feststellt, dass gewisse Änderungen an der Formatierung oder md-Syntax nötig wären, um ein besseres Ergebnis zu erzielen, ist der Arbeitsaufwand sicherlich um Einiges höher. Dazu wäre es m.A.n. jedoch bereits jetzt schon notwendig, einen entspr Onlinezugang wie beim FHEM-Wiki zu schaffen, so dass die (Test-)Ergebnisse da dann auch begutachtet werden können.
Alternative:
Die 'Onlineversion' nicht als FHEM-Wiki, sondern rein mit den md-files als GitHub-Pages umsetzen und dann einen entspr. Link (bspw "epdf.fhem.de" oder sowas) setzen. So könnte man sich die ganze Konvertiererei nach mediawiki sparen und mit einer entspr Vorlage für die GitHub-Pages könnte man sicherlich auch einen gewissen 'Wiki-Look' erreichen, wenn's denn so sein soll.

Bzgl des Inhalts: Mal ganz doof gefragt - ist Ulli Maaß noch erreichbar/aktiv? Vielleicht könntest du gewisse Inhalte von ihm übernehmen und/oder anpassen? Dann müsste nicht alles komplett neu geschrieben werden..?

[Beta-User]

Hi Schotty,

vorab nochmal auch an dieser Stelle für die vielen Infos rund um md!
Ohne das "Muster" von deinem Handbuch wäre ich aufgeschmissen gewesen bzw. würde mich heute noch darüber wundern, wie seltsam sich LibreOffice gelegentlich verhält, wenn man versucht, da was mit vielen Bildern zu machen... (Man bekommt andere schöne Spielereien damit hin, aber das ist ein ganz anderes Thema.)

Vorab ein paar Worte noch zu Uli Maaß: Ich hatte ihn vor längerer Zeit mal angeschrieben, aber leider keine Antwort erhalten. Dem Hörensagen nach ging es auch anderen so, die auch früher schon versucht hatten, ihn zu kontaktieren. Seine letzte Anmeldung im Forum war Ende 2018, von daher hoffe ich, dass es ihm gut geht und er lediglich kein Interesse an FHEM mehr hat, aber sonst nichts schlimmeres ist.

Er hatte nicht nur "das pdf" erstellt, sondern auch die "ersten Schritte", und war bei beidem sehr darauf bedacht, dass keiner ohne seine Zustimmung etwas daran ändert bzw. den Quelltext für das pdf scheint er irgendwo privat abgespeichert zu haben. Ich werde das respektieren, und letztlich war es vermutlich gut, sich von der Vorlage ziemlich zu lösen, weil "mein pdf" erst mal viele Dinge "drumrum" behandelt, die "damals" noch gar keine Rolle gespielt hatten oder jedenfalls nicht im Fokus waren. Es wird natürlich trotzdem so sein, dass Gegenstand der Darstellung FHEM ist, und von daher wird es auch gewisse Überschneidungen geben, das sind aber nach meiner bisherigen Erfahrung tatsächlich eher kleinere Anteile.

Wie dem auch sei, diese Erfahrung, von neuem anfangen zu müssen, war mit einer der Gründe für die sehr klaren Statements im ersten Post: Es ist wichtig, dass jemand entscheidet, was wie am Ende dargestellt wird (sonst kann man "endlos" auch über "Kleinigkeiten" diskutieren), von daher kann ich Uli sehr gut verstehen, dass er "seine" Dokumente auch teils hart verteidigt hat (und eventuell genau deswegen auch nicht mehr hier aktiv ist?), es ist aber genauso wichtig, dass diese Dinge weiterleben können, selbst wenn der "jemand" die Verantwortung nicht mehr wahrnimmt - warum auch immer.
Und genau deswegen ist der Quelltext
- auf dem Server des Betreibers, der auch sonst für alles die Infrastruktur bereitstellt (=FHEM e.V.)
- einfach gehalten (relativ... Aber dass man schnell auch mit anderen Tools brauchbare Ergebnisse mit einem anderen - auch schönen Look! - hinbekommt, wenn man "nur" die files mit der wenigen Formatierung darin hat, hast du ja schön gezeigt!).

Welches Toolset am Ende genutzt wird, ist mir im Prinzip egal, ich will nur weder externe Infrastruktur verwenden, noch Kapazität von den Fachleuten, die sich damit auskennen (oder eben auch (noch) nicht...) mehr als nötig binden, die an anderer Stelle besser eingesetzt werden kann. Kurz: Wenn jemand, der sich mit der hier vorhandenen Serverinfrastruktur auskennt, einen Viewer einrichten kann und will, der die Files direkt rendert und die Verlinkung ins Wiki erlaubt, soll mir das genauso recht sein, wie wenn das ganze von svn in ein git käme oder ich gelegentlich die aktuelle Fassung nachbearbeiten und ins Wiki transferieren muß.

Dass jede Lösung immer irgendwelche Nachteile hat, ist klar, im Moment liegt mein persönlicher Schwerpunkt eher wieder beim "Texten".

Den Transfer nach Wikimedia hatte ich kurz angetestet, was da rauskam, war grundsätzlich ok, auch wenn viele features aus der Mediawiki-Sprache nicht funktionieren und Nacharbeit erforderlich ist. Mal schauen, was man da ggf. automatisieren kann, oft ist es schlicht so, dass man den richtigen "Knopf" finden muß...

Das mit Kap02 schaue ich mir noch an, auf dem Laptop scheint das zu funktionieren, vielleicht hatte ich versehentlich eine alte Fassung erwischt?
Das mit den Dokument-Übergreifenden relativen Links kann ich leider auch nicht lösen, bei der pandoc-Variante klappt das deswegen, weil das afaik erst alles in ein "Groß-Dokument" konvertiert, und dann erst rendert - selbst der scheinbar kapputte interne Link mit den Umlauten funktioniert, sieht aber halt im pdf nicht schön aus...

[CoolTux]

Wie genau ist das Quellfomat für das PDF und das epub?
Gibt es ein Dokument zum bearbeiten mit Änderungshistorie? Ich würde da OpenDocumentFormat vorschlagen. Würde das dann mit LibreOffice bearbeiten und dann kann man auch Änderungsverläufe sehen.


Grüße

[Beta-User]

Es ist Markdown, ein Beispiel, wie das konkret ausschaut, ist in Beitrag #3 zu finden.

EDIT: was da ggf. "seltsam aussieht ist ein indirekter Link auf ein Bild:

Code Auswählen Erweitern

![FHEM-Start von der Windows-Kommandozeile][demostart_win] 
@CoolTux, sorry für den Aufwand im Vorfeld, aber odt wäre m.E. ein Rücksschritt.
In dem odt-Format hatte ich angefangen, und da gab es ein paar schöne Effekte, die man damit erzeugen konnte. ABER: Das Teil ist dann gewachsen, und dann waren die Ergebnisse teils auch "nicht gut" (eigentlich: Schei..e), die ich lokal hatte, nachdem da die ersten paar Bilder drin  waren, und Übertragbarkeit nach Wiki stelle ich mir besser erst gar nicht vor. Es gibt sicher Möglichkeiten, das alles irgendwie zu lösen, aber im Moment fehlt mir dazu die Lust, mich in sowas wie Master-Dokumente oä. einzudenken; Markdown hat sich nach meinen bisherigen Erfahrungen als guter Kompromiß erwiesen.
Es wäre vermutlich sinnvoller, wenn dann weiter über die Frage des End-Renderings zu sprechen. Da ist "mit einer Prise Latex" vermutlich ganz viel möglich, weil das mit Variablen arbeiten kann und die Variablen für unterschiedliche Zielformate auch unterschiedlich auflösen.

Zur Technik an sich:
Im Moment liegen die files auf einem separaten svn-repo, die Änderungen sind also transparent, es gibt jedenfalls derzeit nur kein trac oä., auf dem man sich das anzeigen lassen könnte.

Wenn ich mir was wünschen darf, wäre das neben einem Mitwirkendem mit etwas Latex-Expertise eher ein Vorschlagssystem, bei dem Änderungsvorschläge ähnlich angezeigt werden wie wenn man im Wiki zwei Versionen vergleicht und das dann bearbeiten oder auch 1:1 annehmen kann. Das würde es allen Mitwirkenden (so es einfach zu bedienen ist...!) erleichtern. Keiner braucht sich mit riesen-Dokumenten rumschlagen, wenn es nur um Typos geht und ich sehe bei Änderungen, was eigentlich vorgeschlagen ist...

Markdown an sich ist einfach zu lernen, und m.E. für alle auch viel einfacher, als das ggf. unbekannte LibreOffice (ich kenne und schätze das). Je nachdem werde ich wohl eher hergehen und lokale diffs erstellen und die dann einarbeiten, wenn mir jemand was schickt... Und wie gezeigt: Das geht ohne weiteres auch hier im Forum. Entweder in Code-Tags packen, oder als txt-file in den Anhang und gut ist...

[CoolTux]

Es ist Markdown, ein Beispiel, wie das konkret ausschaut, ist in Beitrag #3 zu finden.

EDIT: was da ggf. "seltsam aussieht ist ein indirekter Link auf ein Bild:

Code Auswählen Erweitern

![FHEM-Start von der Windows-Kommandozeile][demostart_win] 
@CoolTux, sorry für den Aufwand im Vorfeld, aber odt wäre m.E. ein Rücksschritt.
In dem odt-Format hatte ich angefangen, und da gab es ein paar schöne Effekte, die man damit erzeugen konnte. ABER: Das Teil ist dann gewachsen, und dann waren die Ergebnisse teils auch "nicht gut" (eigentlich: Schei..e), die ich lokal hatte, nachdem da die ersten paar Bilder drin  waren, und Übertragbarkeit nach Wiki stelle ich mir besser erst gar nicht vor. Es gibt sicher Möglichkeiten, das alles irgendwie zu lösen, aber im Moment fehlt mir dazu die Lust, mich in sowas wie Master-Dokumente oä. einzudenken; Markdown hat sich nach meinen bisherigen Erfahrungen als guter Kompromiß erwiesen.
Es wäre vermutlich sinnvoller, wenn dann weiter über die Frage des End-Renderings zu sprechen. Da ist "mit einer Prise Latex" vermutlich ganz viel möglich, weil das mit Variablen arbeiten kann und die Variablen für unterschiedliche Zielformate auch unterschiedlich auflösen.

Zur Technik an sich:
Im Moment liegen die files auf einem separaten svn-repo, die Änderungen sind also transparent, es gibt jedenfalls derzeit nur kein trac oä., auf dem man sich das anzeigen lassen könnte.

Wenn ich mir was wünschen darf, wäre das neben einem Mitwirkendem mit etwas Latex-Expertise eher ein Vorschlagssystem, bei dem Änderungsvorschläge ähnlich angezeigt werden wie wenn man im Wiki zwei Versionen vergleicht und das dann bearbeiten oder auch 1:1 annehmen kann. Das würde es allen Mitwirkenden (so es einfach zu bedienen ist...!) erleichtern. Keiner braucht sich mit riesen-Dokumenten rumschlagen, wenn es nur um Typos geht und ich sehe bei Änderungen, was eigentlich vorgeschlagen ist...

Markdown an sich ist einfach zu lernen, und m.E. für alle auch viel einfacher, als das ggf. unbekannte LibreOffice (ich kenne und schätze das). Je nachdem werde ich wohl eher hergehen und lokale diffs erstellen und die dann einarbeiten, wenn mir jemand was schickt... Und wie gezeigt: Das geht ohne weiteres auch hier im Forum. Entweder in Code-Tags packen, oder als txt-file in den Anhang und gut ist...

Ok das ist doch auch eine gute Sache. Das beste daran ist das Du das Teil dann auch bei Bedarf über die FHEM e.V. Cloud weiter entwickeln kannst. Da müsste ich erstmal nichts weiter umstellen oder Office konfigurieren.
Also melde Dich einfach wenn Du das in die Cloud schupsen willst 

[Prof. Dr. Peter Henning]

Ich habe ja schon viele Seiten aus dem FHEM-Buch frei zur Verfügung gestellt, bin also gerne bereit, das Eine oder Andere beizutragen.

LG

pah

[xenos1984]

Zum Thema "Vorschlagssystem": Wie wäre es, die Markdown-Quellen z.B. auf GitHub o.ä. unterzubringen? Dann kann jemand, der dazu beitragen möchte, einen Pull-Request erstellen.

Zum Thema Markdown / LaTeX: Ich bin mit beiden recht versiert (benutze bei der Arbeit durchgehend LaTeX und für Notizen Markdown), und steuere auch gerne etwas bei, wenn ich kann. Zumindest so weit ich FHEM bisher beherrsche.

Ein Kollege von mir schwört auf Typora als Markdown Editor. Damit kann man sowohl den Quelltext bearbeiten, als auch in einen "WYSIWYG" Modus wechseln.

Von der Struktur her sieht es sehr gut aus. Eine Frage zum Inhalt: Soll DOIF auch behandelt werden, oder ist das schon zu fortgeschritten für einen Einsteiger-Leitfaden?

[CoolTux]

GitHub finde ich gut.
GitHub.com/fhem

Da könnte man ein Repo machen.

[Beta-User]

@all:

Danke schon mal für die viele Resonanz! 
Klingt danach, als könnte das was werden (auch wenn mir beim durchsehen dann auch schon wieder ein paar "Holprigkeiten" aufgefallen sind, und das ganze noch einiges Feintuning braucht ).

Ungefähr der Reihe nach:

Zum Thema "Vorschlagssystem": Wie wäre es, die Markdown-Quellen z.B. auf GitHub o.ä. unterzubringen? Dann kann jemand, der dazu beitragen möchte, einen Pull-Request erstellen.

Hatte ja geschrieben: Wünschenswert wäre es eventuell, das von der Form her in der Weise zu organisieren - aber:
- ich habe weder Erfahrung mit dem Akzeptieren von Vorschlägen in Git/Github und will mich eigentlich auch nicht auch noch dort einarbeiten;
- es ist m.E. zwingend, dass die files auf FHEM-eigenen Servern verbleiben, für eine Infrastruktur außerhalb sehe ich jedenfalls im Moment keine "schlagenden Gründe".

@CoolTux:
Bitte fangen wir diese Diskussion daher nicht hier und an dieser Stelle wieder an... Hier geht es um simplen Text, etwas css/tex/yaml und ein paar Screenshots, nicht um komplexen Perl-Code, bitte nicht vergessen!

Ganz grundsätzlich: Ich habe kein Problem mit einem lesenden Zugriff von wem auch immer. Ebensowenig mit diffs (-u, falls jemand es genauer wissen will) oder ganzen Neufassungen, wenn die hier oder anderswo eingehen, und ich werde mich auch bemühen, die abzuarbeiten oder Rückmeldung zu geben, wenn ich was nicht oder anders will. Wenn jemand Lust hat, das mit dem allg. Lesezugriff auf den FHEM-Servern möglich zu machen: gerne!
Aber es sollte für alle Beteiligten (einschl. derjenigen, die das dann von der infrastrukturellen Seite schlicht machen müßten!) mit "simple Tools" zu erschlagen sein...

Zum Thema Markdown / LaTeX: Ich bin mit beiden recht versiert (benutze bei der Arbeit durchgehend LaTeX und für Notizen Markdown), und steuere auch gerne etwas bei, wenn ich kann. Zumindest so weit ich FHEM bisher beherrsche.

Es würde mich sehr freuen, wenn du dir den Quelltext mal mit deinen "kundigen Augen" ansehen könntest und wir das eine oder andere ggf. auch mal bilateral besprechen könnten. Imo ist es von Vorteil, dass du nicht zu den "alten Hasen" gehörst, was FHEM-Nutzung angeht, du liest das noch mit ganz anderen Augen - ich bin schon betriebsblind, und gerade die "wieso"... Fragen bringen uns vermutlich bei dem Thema weiter...
Fachliche Korrektur folgt dann schon von meiner (soweit ich das selbst überblicke, ich weiß nämlich auch bei weitem nicht alles) oder von anderer Seite.

Ein Kollege von mir schwört auf Typora als Markdown Editor. Damit kann man sowohl den Quelltext bearbeiten, als auch in einen "WYSIWYG" Modus wechseln.

Schaue ich mir an, Danke. Aufgrund meiner bisherigen Wiki-Aktivitäten kann ich zwischenzeitlich schon recht gut abschätzen, wie das in etwa aussieht. (ich bin mit WordPerfect groß geworden: Tippen in der DOS-Version, dann Win 3.0 hochfahren, dort ansehen und ab auf den Nadeldrucker... Leidensfähig halt )

Von der Struktur her sieht es sehr gut aus. Eine Frage zum Inhalt: Soll DOIF auch behandelt werden, oder ist das schon zu fortgeschritten für einen Einsteiger-Leitfaden?

Danke für das Lob!
DOIF "kann" ich nicht, ich werde das daher auch nicht vertieft behandeln. Falls jemand was beisteuert, das vom Stil her dazupaßt und substantielle Erkenntnisse zur Funktionsweise des Moduls liefert, werde ich mir das wohlwollend ansehen, bin aber kritisch:
Die Syntax ist einfach eine ganz andere als sonst sehr häufig erforderlich, und in der einfachen Version bringt es kaum einen Vorteil gg. at bzw. notify (außer, dass man für denselben Effekt teilweise viel mehr Attribute braucht, über deren richtigen Einsatz sich teils die Experten nicht einig zu sein scheinen...), und komplexe Dinge sprengen sehr schnell den Rahmen.
Ich plane übrigens z.B. auch nicht, Value() oder "set magic" großen Raum zu geben - man muß das (wie DOIF) erwähnen, weil man es oft findet, aber für meine Einführung gilt im Prinzip "FHEM ist ein Perl Server...", und es macht imo wenig Sinn, auf die Frage "Muß ich mit Perl Programmieren lernen?" ausweichend zu antworten: Im Ergebnis programmiert man mit jedem "define" einen Teil seiner "Haus-firmware", und von daher finde ich persönlich, man sollte sich zuerst mehr mit den Basics beschäftigen und erst später mit "Abkürzungen" und "Vereinfachungen".

Just my2ct.

Ich habe ja schon viele Seiten aus dem FHEM-Buch frei zur Verfügung gestellt, bin also gerne bereit, das Eine oder Andere beizutragen.

Vielen lieben Dank! Mal schauen, wie und wo sich das dann ergibt.

[xenos1984]

- ich habe weder Erfahrung mit dem Akzeptieren von Vorschlägen in Git/Github und will mich eigentlich auch nicht auch noch dort einarbeiten;
- es ist m.E. zwingend, dass die files auf FHEM-eigenen Servern verbleiben, für eine Infrastruktur außerhalb sehe ich jedenfalls im Moment keine "schlagenden Gründe".

Ich persönlich habe mit GitHub durchweg positive Erfahrungen, zumal man viel automatisieren kann (z.B. das PDF oder andere Formate nach jedem Update automatisch erstellen), und auch Pull-Requests sind sehr einfach. Aber wenn sich eine ähnlich nützliche Funktionalität auf FHEM eigener Infrastruktur auch einrichten lässt - sicher, warum nicht.

Es würde mich sehr freuen, wenn du dir den Quelltext mal mit deinen "kundigen Augen" ansehen könntest und wir das eine oder andere ggf. auch mal bilateral besprechen könnten.

Sehr gerne - wenn ich denn wüsste, wo ich den finde Du hattest etwas vom FHEM Server geschrieben, aber ich muss zugeben, dass ich daraus nicht hinreichend schlau geworden bin, um die Dateien zu finden.

Schaue ich mir an, Danke. Aufgrund meiner bisherigen Wiki-Aktivitäten kann ich zwischenzeitlich schon recht gut abschätzen, wie das in etwa aussieht. (ich bin mit WordPerfect groß geworden: Tippen in der DOS-Version, dann Win 3.0 hochfahren, dort ansehen und ab auf den Nadeldrucker... Leidensfähig halt )

Ich bin auch eher für Quelltext zu haben. Mein bevorzugter Editor ist Vim, und für Markdown gibt es dafür ein Pandoc Plugin,

DOIF "kann" ich nicht, ich werde das daher auch nicht vertieft behandeln. Falls jemand was beisteuert, das vom Stil her dazupaßt und substantielle Erkenntnisse zur Funktionsweise des Moduls liefert, werde ich mir das wohlwollend ansehen, bin aber kritisch:
Die Syntax ist einfach eine ganz andere als sonst sehr häufig erforderlich, und in der einfachen Version bringt es kaum einen Vorteil gg. at bzw. notify (außer, dass man für denselben Effekt teilweise viel mehr Attribute braucht, über deren richtigen Einsatz sich teils die Experten nicht einig zu sein scheinen...), und komplexe Dinge sprengen sehr schnell den Rahmen.

Ich kann es versuchen, da ich manche Dinge mit DOIF recht komfortabel gelöst finde und es für manches auch einsetze (z.B. für verzögertes Ausschalten, eine einfache State Machine etc.), aber eben wirklich auf sehr einfachem Niveau.

[CoolTux]

Ich persönlich habe mit GitHub durchweg positive Erfahrungen, zumal man viel automatisieren kann (z.B. das PDF oder andere Formate nach jedem Update automatisch erstellen), und auch Pull-Requests sind sehr einfach. Aber wenn sich eine ähnlich nützliche Funktionalität auf FHEM eigener Infrastruktur auch einrichten lässt - sicher, warum nicht.

Leider ist mir da nichts dergleichen bekannt. Gerade pull request empfinde ich als große Erleichterung genau für so ein Projekt wie die Dokumentation.

[andies]

Noch eine Anmerkung. Mir hat mal ein Sprachwissenschaftler erzählt: "Bei jeder Sprache gibt es Leute die entscheiden, wie richtig gesprochen und geschrieben wird" und das wird hier nicht anders sein. Ich würde mich wohler fühlen, wenn wir (in Ruhe) vorab entscheiden, wer am Ende den Daumen hebt oder senkt. Denn wenn das nicht klar ist und einige Leute viel Energie hineinstecken, dann aber unklare Entscheidungsregeln bestehen und Sachen hin- und herschwanken, kann das sehr demotivierend sein. Ich bin einfach für eine klare Ansage, wer das letzte Wort hat und es wäre sicher hilfreich zu wissen, nach welchen Regeln derjenige vorgeht. Das kann eine Person sein, eine Gruppe, wer auch immer - nur eben kein hin und her.

[Schotty]

Wünschenswert wäre es eventuell, das von der Form her in der Weise zu organisieren - aber:
- ich habe weder Erfahrung mit dem Akzeptieren von Vorschlägen in Git/Github und will mich eigentlich auch nicht auch noch dort einarbeiten;
- es ist m.E. zwingend, dass die files auf FHEM-eigenen Servern verbleiben, für eine Infrastruktur außerhalb sehe ich jedenfalls im Moment keine "schlagenden Gründe".

Pull-Requests sind bei GitHub praktisch und gar nicht so kompliziert: du siehst dir die Änderungen/Änderungsvorschläge an und übernimmst sie entweder mit einem kurzen Klick oder eben nicht.

Der m.E. 'schlagende' Grund wäre eben die von mir anfangs erwähnte Möglichkeit, mit den md-files direkt die GitHub-Pages (also die 'Onlineversion') zu erstellen. So könnte die vermutlich notwendige Konvertierung in die mediawiki-Syntax entfallen, was unterm Strich sicherlich einiges an Arbeit sparen würde.
Die Files selbst könntest du ja zusätzlich ins FHEM-eigene SVN hochladen (quasi als 'Backup' und auch damit es in der 'echten' FHEM-Infrastruktur liegt).
Aber ich will hier auch keine Grundsatzdiskussion GitHub/SVN anfachen, ich wollte nur auf eine in meinen Augen komfortable Möglichkeit hinweisen..

[andies]

Ich bin einfach für eine klare Ansage, wer das letzte Wort hat...

Ich werde mal noch konkreter: Beta-User entscheidet endgültig. Findet das Zustimmung?

[Schotty]

Ich werde mal noch konkreter: Beta-User entscheidet endgültig. Findet das Zustimmung?

Das ist für mich persönlich derzeit sowieso Stand der Dinge, schließlich hat Beta-User ja schon mit dem Dok angefangen und in meinen Augen ist es somit erstmal primär 'sein Projekt'.

[Beta-User]

Hallo zusammen,

(ich komm mit dem Ändern gar nicht nach...)

Noch eine Anmerkung. Mir hat mal ein Sprachwissenschaftler erzählt: "Bei jeder Sprache gibt es Leute die entscheiden, wie richtig gesprochen und geschrieben wird" und das wird hier nicht anders sein. Ich würde mich wohler fühlen, wenn wir (in Ruhe) vorab entscheiden, wer am Ende den Daumen hebt oder senkt. Denn wenn das nicht klar ist und einige Leute viel Energie hineinstecken, dann aber unklare Entscheidungsregeln bestehen und Sachen hin- und herschwanken, kann das sehr demotivierend sein. Ich bin einfach für eine klare Ansage, wer das letzte Wort hat und es wäre sicher hilfreich zu wissen, nach welchen Regeln derjenige vorgeht. Das kann eine Person sein, eine Gruppe, wer auch immer - nur eben kein hin und her.

Verrätst du uns, wer "wir" ist?
(s.u.)

Ich habe kein Problem mit Diskussion über den richtigen Weg, wichtig ist mir nur, dass wir da irgendwie auch vorankommen. "Nur mit Wiki" war da in der Vergangenheit nach meinem Geschmack zu wenig Bewegung, was teilweise auch damit zu tun hat, dass Wiki "per Definition" eben "neutral" sein soll und weniger "Meinung" wiedergeben. Auf diese Weise entsteht aber mMn. kein Leitfaden und keine wirkliche Diskussionsgrundlage, sondern eher ein Irrgarten...

Ergo habe ich vor längerem begonnen, eben diesen Hut anzusehen, und irgendwann - nachdem auch Uli dazu schweigsam war - eben entschieden, mir den aufzusetzen. Es ist etwas schade, dass das jetzt zeitlich zu einer Zeit ein halbwegs präsentables Stadium erreicht hat, zu der wir auch an anderen Ecken eine teils sehr emotionale Diskussion sehen, aber auf den St.-Nimmerlein zu warten, macht andererseits ja auch keinen Sinn.

Daher ist es eben jetzt so wie es ist, und von daher hatte ich eingangs schon deutlich versucht zu signalisieren, dass notfalls eben ich entscheide, wie was gemacht wird, selbst wenn ich am Ende alles alleine machen muß (was ich nicht glaube). Weiter hatte ich auch versucht, zu einigen Fragen bereits soweit klar Stellung zu beziehen, dass jeder die Wahl hat, sich darauf einzulassen. Auch meine Denkweise zu bestimmten Dingen dürfte hinlänglich bekannt sein.

Ich werde mal noch konkreter: Beta-User entscheidet endgültig. Findet das Zustimmung?

Wer bessere und ebenfalls zielführende Vorschläge zum Vorgehen hat: Her damit!
Wer den Hut haben will: Melden!
Wer sachdienliche Beiträge hat: s.o.: ich will der Diskussion über welches Thema auch immer nicht aus dem Weg gehen.

Und: ich habe weder jetzt - und nach meinem derzeitigen Befinden auch nicht zu einem späteren Zeitpunkt - irgendein Problem damit, "das Baby" wieder aus der Hand zu geben! Es sollte nur - in welcher Form auch immer und einigermaßen zeitnah - ein "gutes" Ergebnis rauskommen.



Damit bestimmte Positionen von meiner Seite (als "Wahlprogramm") klar sind:

* DOIF
Das DOIF-Thema würde ich vorläufig gerne auf die Seite legen, ich sehe da neben den bereits genannten Dingen noch mind. an zwei Punkten erhebliche "Bauchschmerzen":
- Es sollte in Phase 3 auch eine englische Fassung geben. Aber ich glaube nicht, dass irgendjemand DOIF "richtig" zum laufen bekommt, wenn er es per englischer commandref versucht. Das ist imo ein "no go"! Damit ist aber auch klar, dass das wenn, dann nur in einem eigenen Abschnitt eine Rolle spielen kann, weil es jedenfalls in der englischen Fassung nichts verloren hat.
- Auch die deutsche Commandref kommt mir eher vor wie eine große Ansammlung von Beispielen. Das liegt evtl. in der Natur der Sache, aber es ist - jedenfalls für mich - völlig unübersichtlich.
+ Dafür gibt es viel eigenständige Doku und viele User, die einem helfen können, wenn man das will (ich kenne aber nicht eben wenige, die irgendwann für sich entschieden haben, das nicht zu wollen). Von daher ist es eigentlich _für eine Einführung_ ausreichend, wenn es an passender Stelle erwähnt wird.

(Bis vor kurzem hatten wir im svn auch einen weiteren "Generalisten" - MSwitch; das schien ähnliche Optionen zu bieten. Hier stellte sich auch bei den Entwürfen schon die Frage, mit welchem Recht nur das eine, nicht aber das andere... (beide User-Gruppen, die das jeweils (noch...) im Einsatz haben, scheinen damit jeweils ja sehr zufrieden zu sein.).

* GitHub
Als dauerhafte Lösung: No!
Die files bleiben auf der Server-Infrastruktur "unserer'" community.
(Nochmal: falls jemand was vergleichbares auf dieser Infrastruktur aufsetzen WILL: no problem, aber hier "nice to have", ich komme ohne aus.)
Es mag sein, dass man statt mit einem Floß auch mit dem A380 über den Ozean kommt, aber mMn. sind wir mindestens bei einem Raddampfer, was jedenfalls mir ausreicht; ich würde daher darum bitten, die Diskussion über "wünschenswert" einzustellen...

(Btw.: Wenn das ganze mal steht, könnte man auch den Weg des diff aus Wiki gehen und das halbwegs automatisieren... Dann kann jeder, der Wiki "kann" direkt "Vorschläge" machen...)

Meine Meinung: wir sollten erst mal einen neuen Pfad durch's Dickicht anlegen, alles andere wird dann schon .

[WIP] halt...


Damit das nicht untergeht:
Was den Weg md zu den diversen Zielformaten angeht, gibt's einen separaten Thread hier (der richtet sich derzeit vorrangig an Schotty und xenos1984).

[Schotty]

* GitHub
Als dauerhafte Lösung: No!
Die files bleiben auf der Server-Infrastruktur "unserer'" community.

Danke, das ist doch mal eine klare Ansage (ein klares "nein" ist mir lieber als gar keine Reaktion - dann weiß ich nämlich, dass mein Geschreibsel überhaupt gelesen und ggf auch durchdacht wurde ).

[andies]

Verrätst du uns, wer "wir" ist?

Jeder, der mitmacht, akzeptiert diese Regel.


Gesendet von iPhone mit Tapatalk Pro

[Prof. Dr. Peter Henning]

Semantisch falsch. Du meinst: Jemand der diese Regel nicht akzeptiert, darf nicht mitmachen.

Ich habe so meine Zweifel, ob das zielführend ist. Ich habe als Herausgeber schon Bücher mit bis zu 40 Autoren gemacht, weiß also, wovon ich rede. Wenn man so rigide Regeln aufstellt, zerstört das die Kreativität.

Ich schlage vor, das viel lockerer zu sehen, und das Gesamtwerk in einzelne Abschnitte aufzuspalten. Dann findet man erstens leichter Mitstreiter, und kann das zweitens besser aktualisieren.

LG

pah

[Schotty]

(...) Gesamtwerk in einzelne Abschnitte aufzuspalten. Dann findet man erstens leichter Mitstreiter, und kann das zweitens besser aktualisieren.

Sehe ich im Grunde auch so, daher hatte ich initial beim privaten Brainstormen mit Beta-User auch Markdown und die Aufsplittung in einzelne Files (derzeit: ein md-file pro Hauptkapitel) vorgeschlagen.
Die PDFs etc, die wir in den ersten Beiträgen eingestellt hatten, sind bereits das Ergebnis der Zusammenfassung&Umwandlung der einzelnen md-files.

[Beta-User]

Jeder, der mitmacht, akzeptiert diese Regel.

Das klingt - mit den Einschränkungen, auf die pah zurecht hingewiesen hat - gut!

Fehlt noch Rückmeldung zu der Frage hier?

sicher hilfreich zu wissen, nach welchen Regeln derjenige vorgeht.

oder darf ich dazu einstweilen schlicht auf das hier verweisen:

Mein Plan ist, das im Lauf des Jahres vollends "irgendwie" zum Abschluß zu bringen, und je mehr ggf. bereit sind, an dem Projekt mitzuwirken, desto "besser" und vollständiger kann es werden. Was man bereits jetzt erkennen können sollte, ist

   
• in etwa das, was an Themen darin zu finden sein soll, (allerdings teils auch für die Zukunft nur kurz angerissen bzw. als Stichwort zum "woanders weiterlesen");
• die "Tonlage", in der ich das gerne gestalten will und
• der "Erwartungslevel" an das "Publikum", was die Übertragung von Beispielen auf die eigene Installation usw. angeht.

Vielleicht sollte ich eines noch anmerken:
Gerade im Mittelteil sind ganz viele Platzhalter. Falls das den Eindruck erweckt, dass das zu allen diesen Themen ausführlich werden muß oder soll: Vermutlich nicht.

Vielleicht nochmal eine etwas andere Variante: Der geneigte Leser soll
- einen ersten Pfad durch das Dickicht "abgehen" können, und dabei (eher indirekt) gleich einen Eindruck davon bekommen, dass er praktisch alles auf seine Bedürfnisse anpassen kann und darüber hinaus häufig eben eine "gewisse" Transferleistung erforderlich ist, deren Erbringung (oder wenigstens Willen zur Erbingung) wir als Erwartung an ihn stellen;
- so in etwa "die Größe des Grundstücks" erkennen können;
- wissen, wo wichtige Eckpfeiler stehen (angefangen bei der commandref, in die viele Neulinge scheinbar nicht mehr schauen...)
- den einen oder anderen hilfreichen Trick mit auf den Weg bekommen;
- vielleicht beim einen oder anderen Thema einen ersten Einstieg finden (v.a. Heizungsregelung, Lichtsteuerung, Rollläden).

Bestimmt kommt da noch das eine oder andere dazu oder entfällt auch, je nachdem...

Ich schlage vor, das viel lockerer zu sehen, und das Gesamtwerk in einzelne Abschnitte aufzuspalten. Dann findet man erstens leichter Mitstreiter, und kann das zweitens besser aktualisieren.

Bin grundsätzlich für zielführende Vorschläge zu haben, das ganze ist - auch derzeit schon - nicht monolitisch aufgebaut, sondern es gibt für jedes Kapitel eine Markdown, wie Schotty auch schon geschrieben hat. Das kann man auch weiter aufdröseln, kein grundsätzliches Problem damit von meiner Seite.

Die files werdet ihr voraussichtlich auch bald hier finden, ich werde nur noch etwas Zeit brauchen, um das eine oder andere noch umzuorganisieren, man sieht z.B. an Schotty's Version, dass die Nummerierung der .md-Files nicht mit den jetzigen Kapitelnummern übereinstimmt und ähnliches mehr. Dann will ich die Screenshots noch vorab ins Wiki bringen, was das ganze noch weiter vereinfachen sollte (auch was die "Zuspielung" besserer Bilder angeht ) und gewisse zentrale Formatierungen noch vom eigentlichen Text trennen (weitestgehend jedenfalls).

Ich bitte daher um etwas Geduld!

Vorab wollte ich aber wenigstens denjenigen, die ggf. über die Ostertage etwas Ruhe haben ein wenig zu schmökern Gelegenheit geben, genau das zu tun: Lesen, sich eine Meinung bilden, ggf. mal kreativ hirnen, was ok ist, was gut, was weniger, was zu viel und was zu wenig .

Es wird aber trotzdem so sein, dass es sowas wie "einen Herausgeber" geben muß bzw. einen Gesamtverantwortlichen. Andererseits werde ich überlegen, ob es nicht Sinn macht, einzelne Teile aus dem Wiki 1:1 zu übernehmen (speziell notify hätte ich da im Moment im Auge) bzw. diese so zu überarbeiten, dass das paßt.

(Wenn "man" am Ende kein pdf braucht/will, sondern im Wiki einen "Grundkurs" durchklicken kann und sich die einzelnen Teile ausdrucken oder lokal runterladen: Mir auch recht ). Dto, wenn jemand (zusätzlich, daraus) "zielführende" Video-Tutorials machen will: gerne.
Wichtig ist vor allem, dass wir auf einen aktuellen Stand kommen, FHEM denjenigen schmackhaft machen, für die es etwas ist und den anderen klarmachen, warum es ggf. für sie besser ist, wenn sie eine andere grüne Wiese nehmen .

That's all...

Have fun! (oder sagt's wenn nicht, gerne mit konkretem Verbesserungsvorschlag...)

[Prof. Dr. Peter Henning]

"Durchklicken" ist ein Wort. Wenn wir wirklich ein Lernmodul haben wollen (sagen wir, im SCORM-Format): 2012-2015 haben wir in einem großen EU-Projekt unter meiner Leitung Software entwickelt, die aus einem Semantic MediaWiki Lenrmodule generieren kann.

LG

pah

[Schotty]

@pah: Klingt interessant - generell kostenlos und frei verfügbar ist sie nicht zufällig, oder? Das wäre sicherlich nicht nur für die hier angedachten Zwecke und die daran Beteiligten ein feines Ostergeschenk 

[Prof. Dr. Peter Henning]

generell kostenlos und frei verfügbar ist sie nicht zufällig, oder?

Nicht zufällig, sondern bewusst. Ich muss das nur noch irgendwo ausgraben...

LG

pah

[Beta-User]

"Durchklicken" ist ein Wort.

Hatte eher an ein paar ganz simple Buttons auf ein paar Web-Pages gedacht, aber vom Raddampfer auf Mondgleiter umsteigen? Warum nicht...?


Meine ersten Assoziationen dazu:
Au ja! Forumzugang ab jetzt nur noch mit Führerschein .
Niemanden mehr mit RTFM traktieren müssen (geht ohne Seitenzahlen auch schlecht...)
Alle wissen alles und finden das wenige, das sie nicht wissen mit wenigen Klicks .

Ein Traum...
(Ironiefrei: Wenn ich was beitragen kann - Gerne!)


Wie dem auch sei, im Anhang zu Post 2 hier gibt's jetzt wie versprochen ein zip mit den Quelltexten und dem Latex-etc-Beiwerk. Die screenshots sind nun in der Wiki-Infrastruktur zu finden und auch im Quelltext (soweit erkennbar vollständig) dahin verlinkt.

Da ich bei der Gelegenheit sowieso nochmal über den ganzen Text drübermusste, habe ich einige Kleinigkeiten noch "nebenbei" geändert, daher gibt es auch neue pdf- und epub-Fassungen.

Wer pandoc austesten will (hier: Version 2.9.2.1):

Code Auswählen Erweitern

pandoc --toc -s -H formating_simple.tex intro.md kap*.md refs_pdf.md metadata.yaml --pdf-engine=xelatex -o pdf2020.pdf -f "markdown+yaml_metadata_block+implicit_figures+table_captions+footnotes+smart+pipe_tables+raw_html+emoji+mmd_link_attributes+inline_code_attributes" --number-section -V subparagraph --dpi=300 --include-before-body=frontpage.md --email-obfuscation=javascript

## epub erstellen

pandoc --toc -s intro.md kap*.md refs_pdf.md metadata.yaml -f "markdown+yaml_metadata_block+implicit_figures+table_captions+footnotes+smart+pipe_tables+raw_html+emoji+mmd_link_attributes+inline_code_attributes" --number-section -V subparagraph --dpi=300 -o epub2020.epub --epub-cover-image=./pics/epdf_Firstlook_demo.png --email-obfuscation=javascript
(kann aber sein, dass ihr ziemlich viel Latex nachrüsten müßt...)

Da im epub das Ausgangsformat der Bilder wohl eine Rolle spielt, könnte man die vom Wiki auch "vorrendern" (verkleinern) lassen. Dann würde es Sinn machen, die Datei "refs_pdf.md" noch weiter aufzusplitten und für die epbub-Version einfach auf die verkleinerten Fassungen verlinken (oder das via html-Anweisungen versuchen). War mir aber für den Moment too much.

Es sind noch nicht alle Links zentral zusammengefasst, aber wenn man das so macht, wäre auch die Verlinkerei für eine englische Fassung relativ einfach zu machen, weil man das (im Text) nicht von überall her  zusammensuchen muß.

Schönen Feiertag zusammen,

Beta-User

[Beta-User]

Hallo zusammen,

da teils direkt und indirekt die Frage gestellt wurde "wie kann ich helfen?", an der Stelle mal, was ich an nächsten Arbeitspaketen sähe bzw. anzubieten hätte:

   
• Korrekturen/Verbesserungen an bestehenden Teilen.

Da geht es darum, so zu tun, als hätte man keine Ahnung und würde den Text als "DAU" lesen. Ziel wäre es
-- die Lesbarkeit zu erhöhen und die "Benutzerführung" zu verbessern;
-- logische Lücken und Brüche aufzudecken;
-- eventuell mißverständliche Formulierungen möglichst auszumerzen;
-- Schreibfehler dabei möglichst auch noch zu beseitigen.
Beispiele:
--- Die "Kommandozeile" ist erst in Abschnitt 2.3.3 bebildert, aber eigentlich wäre das beim "define" (2.3.1) besser aufgehoben.
--- Beim Abschnitt beginnend mit "Dazu klickst du auf das leere Feld neben "room" " könnte man ein paar Pfeile einfügen, die jeweils auf das Element zeigen, auf das man klicken muß bzw. irgendwas eingeben. Was in https://wiki.fhem.de/wiki/Datei:GotoRAW-Import_firststeps.PNG zu finden ist, finde ich fast etwas "überdeutlich", eine etwas schlankere Variante wie in https://wiki.fhem.de/wiki/Datei:Tasmota_mqtt_config.png würde mir insgesamt besser gefallen. Aber auch da gilt: Wer den ersten sinnvollen Vorschlag macht, bestimmt letztendlich die Richtung (für Bilder daher eine Bitte: immer eine unbearbeitete und eine bearbeitete Version bereitstellen)...
--- ebenfalls bei der Raum-Geschichte steht "Menü jetzt nicht mehr "Unsorted" grün". Nun ja, eigentlich ist ja der Hintergrund auch irgendwie "grün".  Es ist halt ein "etwas dunkleres Grün", oder "farblich hervorgehoben" usw..
--- Abb. 11 hat zu viele Elemente, weil ich da grade kein "sauberes" Testsystem zur Hand hatte.

Hoffe, das ist jetzt etwas klarer?

Diesen Teil würde ich ggf. in zwei "Pakete" aufteilen:
a) Einleitung + Hardware
b) Teil 2 (erst mal noch ohne den fehlenden "Rundgang").
(Schotty, xenos1986 und andies): Darf ich euch an der Stelle konkret ansprechen?)

   
• "Rundgang" (durch die Hauptinstanz):

Das könnte jemand (bisher: 3 Namen, 2 Tasks?, aber auch gerne jemand anderes) aufgreifen und nochmal die Begriffe auflisten/wiederholen - ein Bild dazu, das ähnlich wie bei dem Tasmota entsprechende Nummern enthält, damit man das gut zuordnen kann. $motd erläutern (und bitte nicht ausblenden...).

   
• global

Da wäre "der Spur nach" das zu finden, was im pdf enthalten ist (z.B. longitude, language), allerdings würde ich tendenzielle die Verbindung zu fhem.pl mehr betonen, h2we kurz erwähnen bzw. nach hinten zu $we und IsWe() verlinken (das ist insgesamt etwas schwieriger, da man da meine Gedanken zur Gesamtstruktur erraten müßte).

   
• autocreate

Da könnte ich mir vorstellen, dass das jemand wieder auch bereits zum jetzigen Zeitpunkt ganz gut übernehmen könnte:
Gedanklich ist das im Moment der Ort, an dem MQTT2_SERVER und der Shelly ins Spiel kämen und als 2. Beispiel ein Signalduino@USB (gleich mit "by-id"  "für später").
(Bzgl. des Shelly steht da jemanden vor meinem geistigen Auge - an der Stelle würde es aber m.E. für's erste genügen, wenn derjenige die "Artwork" und RAW zur Verfügung stellen würde und zu einem späteren Zeitpunkt logs für das monotonic-userReading.)

   
• Daten aufzeichnen und darstellen

Das wäre der gedanklich nächste Themenkreis.
- FileLog-Gerät als Eventhandler erläutern;
- Exkurs für den Spezialfall Energiemessung: userReading "monotonic" (=> TRIGGER!)
- KURZ auf DBLog eingehen (ich würde dazu tendieren, Anfängern ohne DB-Erfahrung davon abzuraten, DB-Logging zu machen! Und das Stichwort "Grafana" noch ergänzen/verlinken für die, die wissen, was sie tun.)
- Das Log vom Shelly-pm erläutern (oder was ähnliches).
- Schön wäre, wenn wir eine generalisierte gplot irgendwo hätten, auf die wir verweisen können, um uns dann an der Stelle etwas intensiver um plotReplace zu kümmern.
(Falls derjenige mitliest (noch jemand anderes als die vorherigen!), den ich hier konkret im Kopf habe: Das wäre super, wenn du dich angesprochen fühlen würdest!) Da gehört m.E. etwas "Umfeldarbeit" (im Wiki) mit dazu...
Eine generelle Anmerkung zu praktisch allen gplot-Files: Die sind "old-scool-style", und deswegen teils schwer auf ähnliche Sachverhalte zu transferieren. Vielleicht liest der eine oder andere Developer hier mit und nimmt sich jeweils der Sache an...?

   
• Transfer ins Wiki u.ä.
  

Ich selbst würde mich tendenziell dann erst mal um die offene Frage kümmern, wie man das ggf. ins Wiki-Format bekommt und - so das via pandoc erfolgreich ist - weitere LaTeX (?) und css-Tweaks bzw. falls nicht erfolgreich - würde ich die anderen vorgeschlagenen Tools mal näher beleuchten.
(Und dann habe ich noch ein paar andere FHEM-Baustellen, die ich auch gerne zum Abschluß bringen würde...).
(epub ist an der Stelle nicht so wichtig; das war nur ein "Nebenprodukt", aber ganz gut um rauszufinden, wie pandoc intern "tickt". Wenn das irgendwie doch klappt, ist gut, wenn nicht, ist es kein Drama).

Bitte melden, falls das aus eurer Sicht so nicht funktionieren kann oder was wichtiges an Info fehlt, ansonsten würde es mich SEHR freuen, wenn die Leute sich melden würden, an die ich konkret gedacht hatte. Wenn nicht: Es stehen mit Absicht nur sehr wenige Namen da... Es ist definitiv eine Bitte, bei der man "Nein" sagen darf (z.B. durch Schweigen). Und selbstredend: Falls jemand anderes sich angesprochen fühlen sollte: Ebenfalls SEHR GERNE!

Schöne Ostern!

Beta-User

[Schotty]

• Korrekturen/Verbesserungen an bestehenden Teilen.

Da geht es darum, so zu tun, als hätte man keine Ahnung und würde den Text als "DAU" lesen.

Passt - da muss ich mich gar nicht mal groß anstrengen um so zu tun 

-- Schreibfehler dabei möglichst auch noch zu beseitigen.

Dann auch hier nochmal 'offiziell' nachgefragt: "du" oder "Du"? Also nach 'neuer' deutscher Rechtschreibung klein geschrieben oder nicht?
 

(Schotty, xenos1986 und andies): Darf ich euch an der Stelle konkret ansprechen?)

Also was mich betrifft: Klar darfst du

(Und dann habe ich noch ein paar andere FHEM-Baustellen, die ich auch gerne zum Abschluß bringen würde...).

Das geht leider nicht nur dir so
Abgesehen davon fordern auch andere Projekte und vor allem die Außenbaustellen nach Aufmerksamkeit - wenn ich also 'saisonal' nicht relativ umgehend antworte, nicht nervös werden

Wünsche ebenfalls frohe Ostern!

[xenos1984]

(Schotty, xenos1986 und andies): Darf ich euch an der Stelle konkret ansprechen?)

Klar, ich gehe bei Gelegenheit gerne mal mit kritischem Blick durch. Dafür wäre es gut, wenn wir bis dahin eine Plattform hätten, wo sich etwas einfacher gemeinschaftlich bearbeiten / Änderungen einpflegen ließe als z.B. über Anhänge hier im Forum.

Transfer ins Wiki u.ä.

Ich denke, mit der richtigen Konverter-Technik sollte das relativ einfach machbar sein.

(Und dann habe ich noch ein paar andere FHEM-Baustellen, die ich auch gerne zum Abschluß bringen würde...).

Geht mir ähnlich, und ich bin eine ganze Weile nicht dazu gekommen...

[andies]

Ich schreibe schon mal erste Eindrücke auf:

• Allererster Eindruck: Toller Text, ein Haufen Arbeit!
• Mir sind es zu viele Anführungszeichen. Ich würde die fast alle weglassen, der Text liest sich auch so professionell und gut.
• Ich finde in der PDF den Zeilendurchschuss zu gering. Ich würde größeren Abstand lassen, dann ist das Gesamtbild in meinen Augen besser.
• Im Text wird KISS genannt, ich würde an dieser Stelle die Worte "Keep it simple" explizit erwähnen, sonst muss nach nachschauen.
• Bei der ersten Erwähnung eines FHEM-Befehls sollte den Leuten gesagt werden, dass ab jetzt Groß- und Kleinschreibung relevant ist. Wer aus linux kommt, ahnt das nicht sofort.
• Bei der ersten Bezeichnung des Receivers sollte auch angemerkt werden, dass der Name des Devices beliebig ist, aber zB keine Leerzeichen enthalten darf.

Du kannst ruhig direkt Arbeit verteilen und ich schaue dann, ob und wie ich das hinbekomme. Nur zu!

[Beta-User]

Ich schreibe schon mal erste Eindrücke auf:Allererster Eindruck: Toller Text, ein Haufen Arbeit!

Danke!

Mir sind es zu viele Anführungszeichen. Ich würde die fast alle weglassen, der Text liest sich auch so professionell und gut.

Völlig berechtigter Hinweis; die allermeisten stammen noch aus der Zeit, in der das Ding gar keine Formatierung hatte, heute wäre wohl in der Regel eine (nur) kursive Schrift ausreichend.

Ich finde in der PDF den Zeilendurchschuss zu gering. Ich würde größeren Abstand lassen, dann ist das Gesamtbild in meinen Augen besser.

(siehe anderen Thread; wie gesagt: Details in der Optik hatte ich erst mal zurückgestellt, um überhaupt mal hier anfangen zu können...)

Im Text wird KISS genannt, ich würde an dieser Stelle die Worte "Keep it simple" explizit erwähnen, sonst muss nach nachschauen.

Hier an dieser Stelle würde ich dir recht geben; allerdings ist das "und jetzt mußt du eben mal nachschauen, um was es geht", durchaus als methodischer "Kniff" gewollt (macht aber eben an anderen Stellen mehr Sinn).

Bei der ersten Erwähnung eines FHEM-Befehls sollte den Leuten gesagt werden, dass ab jetzt Groß- und Kleinschreibung relevant ist. Wer aus linux kommt, ahnt das nicht sofort.

Gemeint ist wohl eher: Wer _nicht_ aus Linux kommt. Auch dieser Hinweis ist (überwiegend...) berechtigt. (teilweise klappt in der Kommandozeile aber auch eine eigentlich falsche Schreibweise(?)).

Bei der ersten Bezeichnung des Receivers sollte auch angemerkt werden, dass der Name des Devices beliebig ist, aber zB keine Leerzeichen enthalten darf.

An sich berechtigt, die Frage ist halt immer, wie viel Info an welcher Stelle (v.a. deswegen folgt relativ schnell das mit dem alias, bei dem dann etwas näher erklärt ist, was alles nicht geht...). Aber im Ergebnis bin ich da offen, _kann_ man auch anders machen. Das möge bitte für den Moment der entscheiden, der diesen Abschnitt nochmal gegenliest?

Du kannst ruhig direkt Arbeit verteilen und ich schaue dann, ob und wie ich das hinbekomme. Nur zu!

... ungewohnte Rolle...
Hatte eigentlich gedacht, ich mach' mal einigermaßen abgrenzbare "Häufchen", und wer zuerst "sein" Etikett draufklebt, bekommt den Zuschlag...

Dann würde ich im ersten Angang mal so verteilen:
- xenos1986 schaut nach der AsciiDoc-Konvertierung, wenn was auffällt wie das mit den überflüssigen Anführungszeichen, darf das auch gleich weg...?
- andies versucht mal das mit dem Rundgang? (Teil 2 erläutere ich unten)
- Schotty wirft nochmal einen kritischen Blick auf den Text. Falls ich beim letzten Durchgang die großen "du"&Co nicht 100% erwischt habe, darf das auch gern auf den "letzten Stand der Dinge" aktualisiert werden . (Wenn sonst jemandem was auffällt, darf das trotzdem melden!)

Rundgang Teil 2:
Die Hauptinstanz ist ja erst mal relativ witzlos, wesentlich spannender ist das Demo-System. Da sind 3 Dinge drin, die mMn. am einfachsten damit zu erläutern sind:
- Wetter (nu ja, da bricht grade die API weg, aber dazu könnte ich selbst aus eigener Anschauung was sagen...);
- RESIDENTS&Co: Nutze ich selbst bisher nicht. Wenn du (@andies) das im Einsatz hast, wäre es m.E. klasse, wenn du dazu erst mal einen "Fahrplan" als Stichwortsammlung (+ Linkliste in's Wiki?) machen könntest und ggf. den einen oder anderen Screenshot schon mal ins Wiki packen (die bisherigen sind alle mit "epdf_"-Präfix versehen)?
Dann wäre zu entscheiden, wieviel "Residents" denn überhaupt in die Einführung kommen soll (mir persönlich fehlt da etwas die "systematische Klammer" um das ganze, aber evtl. steht das schon irgendwo?)
Dann wäre das das "eigentliche" Arbeitspaket, auch mit dem "Andocken" im Wiki?
- für Lightscene gilt fast dasselbe (das könnte auch jemand anderes machen, und das ist mMn. deutlich einfacher)

Paßt das erst mal so?

[xenos1984]

... ungewohnte Rolle...

Man gewöhnt sich - erfahrungsgemäß - (zu) schnell daran

Hatte eigentlich gedacht, ich mach' mal einigermaßen abgrenzbare "Häufchen", und wer zuerst "sein" Etikett draufklebt, bekommt den Zuschlag...

So gehe ich eigentlich auch am liebsten vor, und bin froh, wenn es so klappt. Manchmal bleiben dann leider "unetikettierte Häufchen" liegen, und dann muss ich doch wieder selbst Hand anlegen

Dann würde ich im ersten Angang mal so verteilen:
- xenos1986 schaut nach der AsciiDoc-Konvertierung, wenn was auffällt wie das mit den überflüssigen Anführungszeichen, darf das auch gleich weg...?
- andies versucht mal das mit dem Rundgang? (Teil 2 erläutere ich unten)
- Schotty wirft nochmal einen kritischen Blick auf den Text. Falls ich beim letzten Durchgang die großen "du"&Co nicht 100% erwischt habe, darf das auch gern auf den "letzten Stand der Dinge" aktualisiert werden . (Wenn sonst jemandem was auffällt, darf das trotzdem melden!)

Da bin ich dabei. Allerdings noch mal die Frage, wie wir die Bearbeitungen koordinieren wollen, bzw. was für eine Plattform wir benutzen. Wenn jeder eine Kopie der Dateien runterlädt, der eine macht hier Korrekturen, der andere wandelt in AsciiDoc um etc. haben wir hinterher ein Chaos auf vielen Versionen. Also entweder arbeiten wir nacheinander und sprechen und ab, wer wann die "Kontrolle" hat, oder wir benutzen etwas wie GIT. Auch hier wieder ein paar Worte aus meiner Erfahrung, zusammen mit anderen einen Text zu schreiben: bisher habe ich beide Methoden benutzt und sie funktionieren gut, wobei man am besten aufteilt, wer wann woran arbeitet, also z.B. einer an der Einleitung, ein anderer an Kapitel X etc. um Überschneidungen zu vermeiden.

[PeMue]

Hallo zusammen,

ich habe mir mal die drei Seiten des aktuellen Threads durchgelesen - erstmal Hut ab für Beta-User: das ist m.E. eine ziemliche Aufgabe, aber ich denke, es wird sich lohnen.

Ich kann gerne mit der Brille des DAUs über die einzelnen Kapitel drüberlesen (bzw. auch das ein oder andere Kapitel übernehmen). Allerdings ist mir die Vorgehensweise nicht so ganz klar.

Was ich meine, verstanden zu haben:
- Die einzelnen Kapitel werden als .md Dateien erstellt und dann (irgendwie intelligent) zu einem PDF bzw. epub gewandelt. Die Diskussion wie das am Besten geht, ist in einem separaten Thread.
- Die einzelnen Kapitel werden verteilt und bearbeitet.
- Beta-User hat die Entscheidungshoheit über den Inhalt und führt die Dinge zusammen.

Soweit, so gut.  Was mir nicht klar ist:
- Wo befinden sich die aktuellen Daten (github war in Diskussion, mit Dateianhängen in irgendwelchen Posts kann man m.E. vermutlich nicht wirklich gut arbeiten)?
- Wer entscheidet, ob bzw. wann welches Kapitel fertig/korrekturgelesen/veröffentlichbar ist (ich meine sowohl die inhaltliche als auch die sprachliche Korrektur)?
- Wo findet die entsprechende Diskussion der Korrektur statt (als Beispiel: bei Dokumenten, die ich von Kollegen korrekturlese (WinWord) schalte ich die Nachverfolgung an und ändere - in der begleitenden Mail gebe ich zu manchen Dingen meinen Kommentar ab - der Kollege entscheidet (als Autor), was er übernimmt bzw. was nicht)?

Das war's erst mal von meiner Seite aus.

Viele Grüße an alle und noch einen schönen Ostermontag.

Peter

[Beta-User]

Hi Peter,

dann sage ich mal: herzlich willkommen an Bord!

Ich hoffe auch, dass sich das lohnt, bin aber ziemlich optimistisch...

Also: Je Kapitel gab es eine Markdown-Datei (.md), zwischenzeitlich habe ich mich überzeugen lassen, dass AsiiDoc für unsere Zwecke besser ist, weil es etwas mehr Formatierung erlaubt. Links sind im Nachbarthread zu finden.
Die Quelltexte sind nunmehr auch über trac einsehbar, ein Link zum Repo ist in diesem Betrag zu finden.

AsciiDoc ist (ähnlich wie Markdown) eine sehr einfaches Textformat, bei dem die Formatierungen durch einfache Zeichen dargestellt werden (kursiv einschalten => einfaches ', kursiv ausschalten => wieder ein ', that's all; bin auch erst noch am einarbeiten, aber z.B. hier wäre ein "Cheatsheet" zu finden: https://powerman.name/doc/asciidoc).

Also: Man nehme einen beliebigen Editor (kate, vim, notepad++, LibreOffice, MS-Word ...), schreibe seinen Text, versuche, das halbwegs (nach dem vorhandenen Muster, jetzt: kap01.txt) zu formatieren und fertig die Laube...

Wer sich freiwillig meldet, darf die Aufgabe wählen bzw. ich versuche das, halbwegs sinnstiftend zu steuern, so dass wir am Ende eben ein "pdf" haben, das vor allem dazu dienen soll, dass ein "Neuling" sich in FHEM-Land zurechtfinden kann und wir als Helfer im Forum wieder etwas haben, das wir als eine Art "Basiswissen" voraussetzen können.
Optimalerweise bleibt der Text aus sich heraus verständlich, und verzweigt dann an die richtigen Stellen im Wiki und Forum, damit "man" (ggf. wir selbst?!?) auch wieder weiß, wo man sinnvollerweise anfängt, sich einzuarbeiten oder Beispiele findet, wie etwas gehen kann.

Da das ganze simpelster .txt-Quellcode ist, wird es hoffentlich nicht allzu schwierig, das alles per simplem diff (diff -u) nach und nach einzuarbeiten, was so eintrudelt, und man kann die Änderungen dann auch im trac gut nachvollziehen/sich jeweils die aktuellen Versionen holen oder ggf. ein svn diff dagegen laufen lassen. Etwas ungewohnt für "normales Text-Editieren", aber so kann man im Prinzip recht einfach beliebig große oder kleine Pakete basteln/beitragen. Was verteilt ist, bekommt erst mal kein anderer, und weil es modular ist, kann man auch Teil-Dokumente einfach rauskopieren und bearbeiten und das ganze dann wieder (z.B. von meiner Seite) zusammenführen...

Konkrete Frage an dich:
Ich hätte zwei Optionen anzubieten.
Einmal das Thema "Heizungssteuerung" (auch da weiß ich noch nicht, wie viel da eigentlich in das pdf soll, ich würde eher weniger machen und das ganze als kleine Einführung sehen, nach dem Motto: Wichtiges Thema, aber stark von den konkreten Gegebenheiten abhängig (Neubau: nur vorausschauende Regelung, nicht mehr heizen, wenn sowieso auch außen war wird bis hin zum schlecht isolierten Altbau: Steuern einzelner Räume nach Anwesenheit (als Konzept). Hauptarbeit wäre im Wiki (Rahmenartikel mit Verlinkung zu diversen Selberbauprojekten; es gibt ja diverse Platinen... )

Andere Variante: Steuern mit devSpec&Co.
Schwerpunkt würde ich da auf Musterbeispiele für sinnvolle Namensvergaben sehen, dazu einige Hinweise zu "Sonderproblemen" wie sich kreuzender Funkverkehr/Interferenzen (=>structure als Alternative).

Interesse?
(Andere Ideen)

Generell&@all: Interessante Selberbauprojekte als Linkliste (ggf. auch bzw und vielleicht besser direkt im Wiki) wäre auch so ein Meta-Thema...

[andies]

- RESIDENTS&Co: Nutze ich selbst bisher nicht. Wenn du (@andies) das im Einsatz hast, wäre es m.E. klasse, wenn du dazu erst mal einen "Fahrplan" als Stichwortsammlung (+ Linkliste in's Wiki?) machen könntest und ggf. den einen oder anderen Screenshot schon mal ins Wiki packen (die bisherigen sind alle mit "epdf_"-Präfix versehen)?

Passt alles. RESIDENTS nutze ich nicht, aber ich habe über zwei Dinge nachgedacht und kann da sicher etwas einbringen: Ich habe eine Art hydraulischen Abgleich meiner Heizung gemacht, da kann ich berichten. Ich habe weiter eine Meldung, wenn sich mein Handy ins Heimnetz einwählt, das kann ich erzählen.

[Beta-User]

Passt alles. RESIDENTS nutze ich nicht, aber ich habe über zwei Dinge nachgedacht und kann da sicher etwas einbringen: Ich habe eine Art hydraulischen Abgleich meiner Heizung gemacht, da kann ich berichten. Ich habe weiter eine Meldung, wenn sich mein Handy ins Heimnetz einwählt, das kann ich erzählen.

Das mit dem hydraulischen Abgleich habe ich in ähnlicher Form auch durchexerziert. Ist evtl. ein gutes Stichwort im Zusammenhang mit dem Großthema Heizungssteuerung, führt aber im Detail im Rahmen des pdf mMn. sehr schnell zu weit. Aber an sich meine ich, dass für sowas auch der Wiki-Artikel https://wiki.fhem.de/wiki/Grundlagen_der_Heizungssteuerung, eine ganz gute Anlaufstelle wäre, um diese ganzen Themen vorzustrukturieren?
(Es gab noch so einen Grundlagenartikel dazu, der aber verwoben war mit vielen konkreten Gerätschaften und daher schwer zu transferieren auf andere, ähnlich gelagerte Fälle).

Das mit der Handy-Meldung habe ich nicht so ganz verstanden. Ein paar Worte zum Hintergrund: Wenn ich "Meldung" höre, werde ich unruhig, ist ähnlich wie bei "Dummy". Nach meinem Geschmack wird das an zu vielen Stellen eingesetzt, was letztlich dazu führt, dass man der einzelnen Meldung keine große Bedeutung beimißt. Wenn mein Handy sich ins WLAN einbucht, bin ich (Dummy...) anwesend, das macht bei mir ein notify (eines für alle Handys...), gehen unsere Kids und kommen nicht binnen einiger Stunden zurück, wird die Heizung in ihren Zimmern runtergeregelt (ein zentrales notify+je ein eigenes at)  (bzw. hoch beim Einbuchen). Sicher auch eine Lösung, die der eine oder andere interessant findet. Ist nur (mMn.) noch nicht zuende entwickelt, aber (und darum gings hier:) es kommt völlig ohne Meldungen an mich aus. Den Status der Bewohner-Dummy's sehe ich ggf. zentral in einem bestimmten Abschnitt einer Raumansicht, die at sind in "unsorted" (das sonst praktisch leer bzw. nicht existent ist), das reicht mir eigentlich schon. Entsprechendes gilt für "abwesende" MySensors-Nodes oder Batterie-Geräte; da habe ich readingsGroups für... Aber vielleicht führt mich das Stichwort "Meldung" auch in die Irre?

Generell vielleicht: das "pdf" sollte eher Fragen der allgemeinen Konzeption klären und Grundlagenkenntnisse vermitteln und "nebenbei" dann geeignete Anlaufstellen zur weiteren Vertiefung liefern. Wäre denn das mit der "Meldung" als "Grundlagenkenntnis" zu verstehen?

[RichardCZ]

Linux mag für dich - wie für viele Einsteiger in die Welt der Hausautomatisierung - völliges Neuland sein, um das du gerne rumkommen würdest. Du kannst FHEM - im Unterschied zu vielen anderen HA-Lösungen - auch auf einem Windows-Rechner laufen lassen. Das hat aber zumindest einen großen Nachteil: Die meisten anderen User tun genau das nicht. Die verwenden zu >95% ein Debian-basiertes Linux. Bei manchen Fragen kann dann von diesen 95% keiner helfen...;

Ich würde in der Doku vehementer von Windows abraten. Nach Durchsicht des Code würde ich meinen, dass nochmal gut 30% der Module gar nicht unter Windows laufen (silent failure - ohne das irgendwo zu testen). Text2Speech, smartmon, sysmon, systemd_watchdog, npmjs, hyperion, presence, nmap, doorbird (win support nur nach Codeänderung), ...

Mit anderen Worten "Du kannst einen kleinen Teil von FHEM..."

Ich weiß nicht, ob man sich mit dem Label "im Gegensatz zu anderen ... Windows Support" und der damit verbundenen Erwartungshaltung mit anschliessender Enttäuschung einen Gefallen tut.

PS: Bei HA-Lösungen denke ich eigentlich sofort an Hochverfügbarkeit, high-availability (cluster). Und nicht nur ich, Tante Google ist der gleichen Ansicht
https://www.google.com/search?q=HA+L%C3%B6sung

[Beta-User]

Ich würde in der Doku vehementer von Windows abraten. Nach Durchsicht des Code würde ich meinen, dass nochmal gut 30% der Module gar nicht unter Windows laufen (silent failure - ohne das irgendwo zu testen). Text2Speech, smartmon, sysmon, systemd_watchdog, npmjs, hyperion, presence, nmap, doorbird (win support nur nach Codeänderung), ...

Mit anderen Worten "Du kannst einen kleinen Teil von FHEM..."

Ich weiß nicht, ob man sich mit dem Label "im Gegensatz zu anderen ... Windows Support" und der damit verbundenen Erwartungshaltung mit anschliessender Enttäuschung einen Gefallen tut.

Bin da sehr zwiespältig. Bin "Linuxer aus Gewohnheit" und bekomme immer die Krätze, wenn ich versuchen muß ein Win-System zu verstehen. Von daher käme ich gar nicht auf den Gedanken, FHEM unter diesem Spionagesystem laufen zu lassen und muß immer meinen allgemeinen Abwehrimpuls unterdrücken, wenn ich höre, dass es jemand macht/versucht.

ABER: Eine nicht ganz kleine Minderheit (afaik auch unter den Developern!) hat das wirklich und ernsthaft unter Windo.* am werkeln . Ergo: Es geht, und wer "nur mal kurz testen" will, kann das auch auf diesem Weg tun (ich konnte das auch nicht so recht glauben und hab's ausprobiert. Die Basisdinge laufen auch unter Win, und viele der o.g. Tools machen nur unter Linux Sinn; die als Argument heranzuziehen, ist nicht die feine Art...). Und wer nur "den kleinen Teil" haben will/braucht, soll das von mir aus auch langfristig so halten, auch wenn ich selbst das nie verstehen werde...

Du hast jedoch recht: Der Einsteiger sollte wissen, dass es nicht nur die relativ kleine Nutzerbasis ist, über die er stolpern wird, wenn er ernsthaft den Versuch unternimmt, kein *nix als Basis zu nehmen. Das ist definitiv zu eng gefaßt.

PS: Bei HA-Lösungen denke ich eigentlich sofort an Hochverfügbarkeit, high-availability (cluster). Und nicht nur ich, Tante Google ist der gleichen Ansicht
https://www.google.com/search?q=HA+L%C3%B6sung

Danke für den Hinweis, werd's ändern (und hoffe, bei der nächsten Interation nichts zu übersehen, falls das nicht nur da auftaucht...)

[RichardCZ]

und viele der o.g. Tools machen nur unter Linux Sinn; die als Argument heranzuziehen, ist nicht die feine Art...).

Ich habe echt Probleme mit dem was hier als "feine Art" definiert ist.

Denn den Text habe ich hier nur geschrieben, weil ich bei Text2Speech über /usr/bin/mplayer gestolpert bin. Wer mich kennt, weiß, dass dann ein grep '/usr/bin' nicht weit weg ist. Aber wenn TTS nur unter Linux Sinn macht... Ich bin da schmerzfrei.

[andies]

Sorry, ich hatte beruflich und privat etwas Stress und war daher länger offline. Ich bin heute endlich mal dazu gekommen, etwas zu Residents zu schreiben. Ich hoffe, dass man damit etwas anfangen kann und dass es vor allem in dem richtigen Format gegeben ist. Hier mein Text:

Code Auswählen Erweitern

## Anwesenheitserkennung in FHEM
Viele Funktionen im Smarthome haben mit einer Anwesenheitserkennung zu tun: Die Alarmanlage soll scharf geschaltet werden, sobald man das Haus verlässt; der Wecker geht nur an, wenn man morgens im Haus ist und das Warmwasser wird nur dann erhitzt, wenn jemand vor Ort weilt. Es gibt viele Wege, eine solche Anwesenheitserkennung in FHEM zu installieren. Der typische Ansatz setzt dabei die Antwort auf folgende Fragen voraus:
* Durch welches Gerät soll die Anwesenheit erkannt werden? Hier greift man fast immer auf das Smartphone der Person zurück, dessen Daten also verfügbar sein müssen.
* Wie soll das Gerät erkannt werden? Hier sind mehrere Möglichkeiten denkbar. So kann sich das Gerät beispielsweise durch Bluetooth, Pings, geofancing, WLAN oder ein anderes Protokoll zu erkennen geben. Welches Protokoll man hier wählt, hängt von den Gegebenheiten vor Ort, deren Zuverlässigkeit, der Batterielaufzeit und der vorhandenen Hardware ab.
* Zuletzt muss man sich klarmachen, wie man die Anwesenheitserkennung und deren Folgen in FHEM sinnvoll umsetzt. Hier bieten sich vorgefertigte Module an, die einfach einzusetzen sind.

Im Folgenden soll näher erläutert werden wie vorzugehen ist, wenn man ein Smartphone verwendet, sich dieses via WLAN ins hauseigene Netz einloggt und diese Erkennung von RESIDENTS verwaltet werden soll. Dann sind mehrere Schritte notwendig. Zuerst müssen wir die Erkennung der Person von der logischen Handhabung in FHEM trennen. Daher ist ein Device anzulegen, welches alle Personen später erfasst und deren Eigenschaften speichern wird
`define <FreierNameDesDevices> RESIDENTS`
Alle Personen im Haus werden nun in diesem Device verwaltet. Dabei wird unterschieden zwischen Mitbewohnern (ROMMATE) und Gästen (GUEST). Jede Person wird durch einen entsprechenden Befehl hinzugefügt. Für einen Mitbewohner mit dem Namen Julian ist einzugeben
`set  <FreierNameDesDevices> addRoommate Julian`
Nach diesem Befehl legt RESIDENTS automatisch ein weiteres Device für Julian an. Es bekommt einen vorgegebenen Namen, der sich aus dem Vornamen und einem Präfix ableitet: `rr_Julian`.

Wie installiert man nun die Anwesenheitserkennung für Julian, bei der die WLAN-Erkennung ausgenutzt wird? Hier benötigt man Kenntnisse des eigenen WLANs. Wir wollen zwei Möglichkeiten vorstellen: Eine beruht auf einem WLAN, das von einer Fritzbox aufgespannt wird. Die andere Möglichkeit basiert auf einem WLAN, das mit einem Unifi-Controller bereitgestellt wird.

###Anwesenheitserkennung mit Fritzbox
Mit Hilfe der Fritzbox können verbundene Geräte ebenfalls erkannt werden. Hierbei gibt es die Möglichkeit, die WLAN-Funktion der Fritzbox zu verwenden und zu prüfen, inwieweit sich das iPhone von Julian eingeloggt hat. Wir wollen hier jedoch auf eine andere Technologie zurückgreifen, da wir die WLAN-Erkennung im nächsten Abschnitt mit Hilfe von Unifi-Geräten beschreiben wollen. Die Fritzbox besitzt ebenfalls eine Funktion, mit der verbundenen Geräten IP-Nummern zugewiesen werden und dies kann man ebenfalls ausnutzen um zu prüfen, ob Julian zu Hause ist.

Hierzu verwendet man das vorhandene Gerät
`defmod FritzBox FRITZBOX <ip>`
`attr FritzBox boxUser <user>`
welches die im Heimnetz vorhandene Fritzbox repräsentiert.  Hierzu muss man wissen, unter welcher IP die Box erreichbar ist und mit welchem Nutzer man die Daten auslesen kann. Zudem ist noch das entsprechende Passwort einzugeben, das von FHEM intern (also nicht im device) gespeichert werden wird.

Sind all diese Angaben erfolgt, dann werden in den Readings die mit der Fritzbox verbundenen Geräte und deren MAC-Nummern angezeigt. Wenn Julians iPhone eingeloggt ist, erkennen wir dies beispielsweise an dem Eintrag
`mac_D0_11_22_33_44_55 iPhone-von-Julian 2020-05-09 17:00:00`
und wissen damit, dass das iPhone und vermutlich auch Julian vor Ort ist.

Aufbauend auf diesem Reading kann man nun den ROMMATE rr_Julian steuern. Dazu muss man mitteilen, dass Julian zu Hause ist. Dies geschieht, indem in RESIDENTS der Status von Julian geändert wird
`set rr_Julian state home/absent`
(Das Modul erlaubt noch mehr Stati, auf die wir hier nicht eingehen werden.) Ein notify muss nun noch dafür sorgen, dass aus der ausgelesen Verbindung des iPhones von Julian automatisch der Status auf home oder absent gesetzt wird.
<Da stehe ich nun auf dem Schlauch, weil ich so was nicht umgesetzt habe>


###Anwesenheitserkennung mit Unifi-Controller
Wer Unifi-Controller verwendet, kann auf das Gerät Unifi zurückgreifen. Dieses Gerät wird, abhängig von der eigenen Unifi-Installation, wie folgt (minimal) definiert
`define <DeviceName> Unifi <ip> <port> <username> <password>`
Hierbei muss man also die IP-Adresse des Controllers, den Nutzernamen für den Zugriff und das Passwort kennen. Die beiden letzten Angaben werden von FHEM verschlüsselt gespeichert. Das Gerät liest in regelmäßigem Rhythmus die mit dem Controller verbundenen Geräte aus und gibt sie in den Readings an. Hat Julian beispielsweise ein iPhone und trägt dies auch seinen Namen, so kann man das iPhone in den Readings erkennen, wenn Julian vor Ort ist
`iPhone-von-Julian connected 2020-05-09 17:00:00`
Erkennbar ist, dass Julian am 9. Mai mit dem WLAN verbunden war und damit anwesend sein sollte (wenn der das Handy nicht zu Hause vergessen hat).

Wieder muss jetzt mit einem notify umgesetzt werden, dass die Angaben in ROMMATE aktualisiert werden. Eine andere Möglichkeit besteht darin, diese Verbindung mit dem Modul PRESENCE von FHEM zu arrangieren. Hierzu definiert man sich ein Gerät, das auf das Event vom Controller reagiert und für das Anwesenheits- und Abwesenheitsereignisse definiert werden. Wenn das Unifi-Device den Namen Unifi hat und das iPhone von Julian wie oben ausgelesen wird, verwenden wir die so genannten magic quotes
`defmod Julian_presence PRESENCE event Unifi:iPhone-von-Julian:.disconnected Unifi:iPhone-von-Julian:.connected`
Durch die event-Steuerung erkennt FHEM anhand der Readings in Unifi, welches Gerät es beachten muss (nämlich iPhone-von-Julian) und woran es die Abwesenheit (erster Eintrag mit disconnected) oder die Anwesenheit (zweiter Eintrag mit connected) feststellt. Die beiden Einträge sind formal Events in FHEM.



[Beta-User]

Vorab mal Danke für den Teil, das ist schon mal eine sehr gute Grundlage und - vor allem! - ein guter und nachvollziehbarer Einstieg. Fritzbox habe ich selber im Einsatz, allerdings in einer "generalisierten" Variante, bei der jeder Fritzbox-MAC-Event ausgewertet wird und mit getKeyValue gecheckt wird, ob es einen Bewohner gibt (das sind noch Dummys ohne RESIDENTS-Verknüpfung). Das bietet sich ggf. an, dann in den Grundzügen als 2. Variante zu erläutern.

In die Einleitung werde ich noch ein paar Hinweise auf andere Varianten reinnehmen (Taster/Dashbutton/Schlüsselbrett), geofancy (?) und Bluetooth-Tag (dazu gibt es ein Modul oder man nimmt OpenMQTTGateway@ESP32).

(Was mich in dem Zusammenhang noch längerfristig beschäftigen wird: Mein Bauchgefühl sagt, dass man eigentlich mehrere Infos auswerten sollte und nicht nur "die eine", um eine zuverlässigere Aussage über Anwesenheiten machen zu können. Das wird aber sehr schnell sehr komplex, weil man das (ggf. je nach individueller Nutzergewohnheit "personalisiert" ...) irgendwie "priorisieren" muß und ggf. das Alter der jeweiligen Teilinfo mit verarbeiten.)

Bin selbst leider auch mit dem Texten praktisch nicht vorwärtsgekommen und hinke gewaltig hinter meinen eigenen Vorstellungen her, aber "andere Dinge" waren eben mMn. dann doch wichtiger...

Bin aber optimistisch, dass es jetzt bald wieder weitergeht!

[andies]

@andies: RFM96 hätte dir übrigens mit großer Sicherheit das Einarbeiten in die Antennentechnik "erspart" (da war doch was mit einem Wasserzähler weit entfernt vom Haus, der "unbedingt" in MomeMatic-BidCoS sein "mußte" ...). Aber man weiß ja nie, für was erweiterte Kenntnisse gut sind .
(Falls jemand in einem größeren Mehrparteien-Haus wohnt und was für den Keller sucht, das so weit funkt: here you are, take RFM96-LoRa... Aber schon mit einem "guten nRF24L+" (die ungeschirmte 1.100m-Variante hatte ich hier mal auf Reichweiten getestet. Ich kam auf  jenseits 100m in einem lose überbauten Wohngebiet, also im Freien ohne ganz direkte Sichtverbindung, das GW innerhalb meiner Hütte. Mit der geschirmten 2.300m (?)-Variante geht da bestimmt noch mehr.)

Je mehr ich solche Dinge aus meiner Verdrängung hervorhole, desto klarer wird mir, dass wir in der Einsteiger-PDF bereits auf diese verschiedenen Hardwareformate und ihre Vor- und Nachteile eingehen müssen.

[Beta-User]

MMn. geht das zu weit. Meine Erfahrung mit Einsteigern hier (und durchaus auch mit erfahreneren Usern) ist eher die, dass da die Neigung besteht, solche Tipps in den Wind zu schießen und in der Nähe von "Spinnereien" zu sehen. Das ist ganz normal, wenn mir einer vor 6 Jahren prophezeit hätte, dass ich mal funktionierenden Code für eine MCU selbst zusammenschustern könnte, wenn man mir ein paar funktionierende libs vor die Füße wirft, hätte ich vermutlich auch erst mal ganz laut gelacht.... Außerdem wird das dann definitiv uferlos, mal ganz davon abgesehen, dass das Risiko dann noch größer wird, dass es "at the time of writing" schon veraltet ist.

Das sollte man ggf. in der Systemübersicht noch etwas intensiver beleuchten, aber da findet sich z.B. bei "MySensors" schon der unscheinbare Hinweis "auch LoRa möglich" - man muß ggf. nur wissen, was sich hinter dem Kürzel verbirgt... Aber da kommt man eben schnell von Höcksken auf Stöcksken (wie auch immer man das korrekt schreibt).

[andies]

OK, und meinst Du dass es Sinn ergibt, so eine Zusammenstellung überhaupt mal zu machen? Zumindest jetzt würde ich mir das mal wünschen. Apropos lachen: Das habe ich bis vor kurzem über LoRa 

[Beta-User]

Es macht auf alle Fälle Sinn, das was vorhanden ist mal durchzusehen, ob es "verständlich" ist und ggf. nachzulegen. Aber das birgt immer auch die Gefahr, dass es "mehr" wird und damit unübersichtlich (= schlechter "as is"!).

An sich wäre sowas wie "typische Problemstellungen (lösbar für Fortgeschrittene)" eventuell eine Idee für eine "Sammelseite", aber ich vermute, dass dann pah zurecht hier mit dem Stichwort "semantic Wiki" aufschlägt. Sowas ist einer "natürlichen Alterung" unterworfen und unterliegt daher dem dringenden Verdacht, direkt zu veralten. Beispiel: Früher war unter dem Stichwort "Arduino" im Wiki NUR dargestellt, wie man das jetzt als Beispiel aufgeführte Dingens nutzt - und schon sind wir mitten im Thema: es wird ein ENC28J60-Shield verwendet, was afaik (2020) die _schlechteste verfügbare_ Variante für den Versuch ist, einen Arduino ans LAN zu bringen. (Aber da ich das nur vom Hörensagen her weiß: Seite ändern? Das Beispiel raus? MySensors oder Firmata stattdessen rein?!?). 

Im Moment halte ich diesen Problemkreis für halbwegs gelöst: Es ist bei einer ausreichenden Zahl von aktiven Nutzern bekannt, _dass_ es einen bunten Strauß an Optionen gibt. Wer also ein konkretes Problem hat, kann fragen und sollte dann eben ein paar mehr valide Anworten bekommen als nur "nimm' einen ESP8266"...

Zu LoRa: gibt's dazu mehr an Geschichte als nur meinen freundlichen Hinweis, dass MySensors das seit längerem einigermaßen stressfrei kann?

[andies]

Zu LoRa: gibt's dazu mehr an Geschichte als nur meinen freundlichen Hinweis, dass MySensors das seit längerem einigermaßen stressfrei kann?

Jein, bis auf die übliche Besserwisserei ("lass ihn reden"): Ich sitze schon wieder an diesem Wasserzähler-Empfänger, Wemos geht nicht mehr und ich probiere erneut, eine serielle Schnittstelle aufzubauen. Dazu noch Corona und Homeoffice und drei homegeschoolte Kinder, super gerade.

[Beta-User]

Nachtrag noch zu dem Arduino-Thema:

MMn. wäre es am besten, wenn sich jemand fände, der das Thema "keyValueProtocol" aufgreifen würde und dann da zwei Varianten beisteuern könnte:
Eine über USB und einem mit einem aktuellen WIZNet-Shield (5100 bzw. 5500).

FALLS die eine Person, an die ich konkret denke (da war was mit einem sehr speziellen Zähler!) mitliest: Zumindest ohne den Netzwerk-Teil wäre das doch machbar, oder? (Für den Rest findet sich dann bestimmt auch jemand, der das um den Teil ergänzen kann).
Meine bevorzugten Beispiele wären der Taster und ein "einfacher" Zähler, der nur Pulse liest und z.B. alle zwei Minuten an FHEM schubst (ich weiß, es gibt den fertigen Arducounter, der das noch viel besser kann; hier soll aber das Prinzip erläutert werden, daher darf der Sketch nicht zu komplex werden...)

@andies: Zu der Wasserzähler-Geschichte: wenn du mir per pm deine Adresse schickst, kann ich mal schauen, ob ich die 1.100m-Variante noch als Paar hier rumliegen habe (und passende Sockel). Gäbe es für "aktive Contributer" gratis und du könntest ohne lange Lock-down-Wartezeit testen... (und dann reden wir immer noch nicht über LoRa . Habe ich auch daliegen, weil ich damit mal ~5km machen wollte - was ohne spezielle Antennenabstimmung selbstredend nur schiefgehen konnte - die will ich aber nicht hergeben, brauche ich vielleicht nochmal zum testen ).

[DL8EI Ralph]

Moin,
habe mir pah-s Buch gekauft, weil ich meine verkorkste Installation neu machen wollte.
Bin aber schon gleich gescheitert, weil es den ersten Installationslink schon nicht mehr gibt.
Das Buch selbst ja gut und verständlich. Es fehlt ein Topf, in welchem Neuerungen und Updates behandelt werden, etwa Kapitel das, Seite die, funktioniert jetzt so: Beschreibung.
Der Verweis auf Foreneinträge ist - für mich - wegen der vielen Diskussionen nicht hilfreich.

Ich würde mich als Dumm-Leser (kapiere ich / kapiere ich nicht) beteiligen und den Level runterziehen.

[rudolfkoenig]

Bin aber schon gleich gescheitert, weil es den ersten Installationslink schon nicht mehr gibt.

Um welchen Link geht es?

[DL8EI Ralph]

Um welchen Link geht es?

Kapitel 2, Seite 11, im Kasten
https://www.joerg-lohrer.de/2018/05/24/einrichtung-eines-neuen-raspberry-pi-headless

Mir fehlt auch der Installationsteil debmatic für Homematic

[CoolTux]

@Rudi Ralph meint einen Link im Buch vom Peter.

[enno]

Moin Ralph,

würde dir diese Seite helfen: http://web.archive.org/web/20190318024934/https://www.joerg-lohrer.de/2018/05/24/einrichtung-eines-neuen-raspberry-pi-headless/

Gruss
  Enno

[rudolfkoenig]

Falls es ein "fhem.de" Link war, dann haette ich womoeglich was reparieren koennen.

[DL8EI Ralph]

Danke an Enno.

Dank auch an Rudi, es war ein Mistverständnis.
Ich schrieb oben, dass ich das Buch von "pah" kaufte, darin genannter Link.

[rudolfkoenig]

Ich schrieb oben, dass ich das Buch von "pah" kaufte, darin genannter Link.

Das ist mir klar. Wenn der Link eine Datei auf fhem.de referenziert haette, was inzwischen geloescht/umbenannt wurde, haette ich es reparieren koennen.