Dokumentation einer FHEM-Installation

Begonnen von m0urs, 29 Juli 2017, 11:25:57

Vorheriges Thema - Nächstes Thema

m0urs

Hallo,

nachdem meine FHEM-Installation im Laufe der Zeit durch viel Try & Error ziemlich unübersichtlich geworden ist, wollte ich nun mal anfangen, diese ein wenig zu "entschlacken" und dabei auch gleich irgendwie dokumentieren, wie alles zusammenhängt etc. Meine Frage: Wie dokumentiert ihr denn Eure Installationen? Hat jemand vielleicht mal ein paar Beispiele?

Danke und Grüße
Michael

CoolTux

Was genau willst Du denn da Dokumentieren? Wie man es generell macht, also als Anleitung oder eine Übersichtsdoku über Dein System?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

m0urs

Eine Übersichtsdoku wie mein System aufgebaut ist, was wann wie getriggert wird usw.

CoolTux

Meine persönliche Meinung!
Ich würde es als für nicht nützlich empfinden. Wenn ich etwas an Info brauche kann ich jederzeit kurz ins FHEM schauen. So lange Du immer irgendein Ansatz zum suchen hast kann man mit Filter suche arbeiten. Weitergehende Infos hinterlege ich direkt in FHEM. Batteriewechsel, myUtils Routinen die über Notifys aufgerufen werden, userReadings wo Daten aus anderen Devices kommen und so weiter. Kann man alles als Attribut Comment hinterlegen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

m0urs

Ok, dann versuch ich es auch erst mal auf diesem Weg ;-)

Otto123

Hi,

ich dokumentiere mein FHEM System indem ich die Installation per Script mache und dieses aktuell halte und kommentiere.
Im Fehlerfall kann ich FHEM in kurzer Zeit neu installieren und ein Backup einspielen. Ich finde, das ist ziemlich wichtig.

Spezielle FHEM Lösungen schreibe ich mir einfach auf, damit ich später weiß warum ich das so gemacht habe. Die Logik des funktionierenden Systems findet man doch in FHEM selbst immer wieder  ;)

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

m0urs

Zitat von: Otto123 am 29 Juli 2017, 22:55:07
Die Logik des funktionierenden Systems findet man doch in FHEM selbst immer wieder  ;)

Schon richtig, aber ich finde das halt nicht wirklich übersichtlich. Mag vielleicht aber auch an mir liegen. Ich habe mit Null-Ahnung bei FHEM angefangen und mit Try & Error immer mehr Dinge eingebaut. Zwischendurch wird mal wieder was Neues ausprobiert und wieder verworfen usw. Dadurch ist es vermutlich nicht wirklich übersichtlich geworden ;-)

Am Anfang habe ich noch direkt in der FHEM.CFG editiert und dort Kommentare eingefügt. Aber da man doch besser über die Oberfläche editiere sollte, habe ich das irgendwann mal aufgegeben.

curt

Liegt mit Sicherheit nicht an Dir.

Mir geht es völlig identisch, Dein letzter Beitrag könnte von mir sein.
RPI 4 - Jeelink HomeMatic Z-Wave

JoWiemann

Na ja, vor Jahrzehnten habe ich noch gelernt, erst einen Programmablaufplan erstellen und dann umsetzen. Bei den komplexeren Sachen in Fhem mache ich das immer noch so und habe somit eine Unterlage, wenn mich mein Gedächtnis im Stich lässt.


Gesendet von iPhone mit Tapatalk

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Pfriemler

Ich habe eine Zeitlang parallel zur FHEM-Entwicklung mal eine Zeitlang einen Word-Text wie ein Tagebuch geführt. Irgendwann war die Hälfte der Einträge obsolet, weil ich die Lösungen verworfen und ersetzt hatte. Trotzdem bleibt dieser prosaische Text hoffentlich eine Einstiegshilfe für den Nachwuchs, falls ich vor der Zeit mal den Löffel abgeben sollte.
Ein nicht unwesentlicher Aspekt meines Smarthomes findet sich jedoch nicht einmal direkt in FHEM: die Registerprogrammierung von HomeMatic. Was ich da wie und warum verbogen habe, steht auch in diesem Text. Ist mühselig, aber schon beim Schreiben fallen einem manche Fehler oder Optimierungsmöglichkeiten auf...

In FHEM werden spezielle Einstellungen oder möglicherweise ungewöhnlich erscheinende Einstellungen strikt als "comment"-Attribut hinterlegt. DOIFs werden stets reichlich in der DEF kommentiert. Dies, zusammen mit dem segensreichen "Probably associated with" haben mich meine Konstrukte stets wiedererkennen lassen ...  8)

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Hollo

Ist vielleicht auch eine Frage der Zielgruppe; eine ähnliche Diskussion (ohne DIE Lösung) hatten wir schon mal bzgl. Dokumentation der Technik.

Selber kommt man mit mehr oder weniger Dokumentation sicher meist wieder dahinter, wieso man etwas so oder so gemacht hat bzw. warum das so umständlich geworden ist.
Aber wie sieht es mit der Familie aus, die das System NUTZT.
Da muss man ja auch ein wenig Grundwissen zu Funktion und Features vermitteln, damit das alles GANZ EINFACH UND SICHER erscheint;
sonst ist die Akzeptanz ruck zuck weg und damit auch die viele Zeit, die man damit gerne mal verbrät.   ;)

Ich habe wichtige Kommentare meist direkt in den (config-)Dateien hinterlegt (Gewohnheit vom Linux-Server);
für die allgemeine (und später vielleicht auch mal detailierte) Beschreibung denke ich noch über ein internes Blog oder Wiki nach.
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"