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

[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.