Auffindbarkeit von Informationen zu FHEM

Begonnen von martinschm, 07 Februar 2014, 14:26:30

Vorheriges Thema - Nächstes Thema

martinschm

Hi,

da ich kein anderes Forum gefunden habe, poste ich mal hier.

Bitte diesen Post nicht als Kritik verstehen. Ich finde es super das die vielen Freiwilligen hier ihre Freizeit investieren und auch Neulingen wie mir immer in sehr kurzer Zeit mit Rat und Tat zur Seite stehen.

Da ich sehr neu beim Thema FHEM bin, bin ich viel auf der Suche nach Informationen wie Sachen rund um FHEM funktionieren. Mir ist dabei aufgefallen, das die Informationen häufig schon existieren, aber über viele Stellen verstreut sind.

Es gibt zum einen eine Seite mit Doku zu den Modulen (commandref), dann gibt es ein Wiki mit Detailinformationen und How-tos (einige Seiten sind leider nur über Deeplinks zu finden), es gibt ein sehr umfangreiches PDF und sehr sehr viel Informationen steckt in den Foren.

Würde es nicht Sinn machen die Informationen mehr zu zentralisieren?

Wenn der Zugang zum Thema einfacher wird, kann es nur helfen das die FHEM Community wächst und in den Foren werden vielleicht weniger Fragen zu den gleichen Themen gefragt. Und statt den Neulingen wie mir zu erklären wie man gewisse Sachen umsetzen kann, könnten die FHEM Profis an ihren Projekten arbeiten oder vielleicht Zeit finden einige ihrer fortgeschritteneren Lösungen vorzustellen und damit noch mehr Community Mitgliedern zu helfen.

Wie gesagt, versteht dies bitte nicht als Kritik sondern lediglich als Anregung.

ciao
Martin

hexenmeister

Hallo Martin,

die Kritik ist schon in Ordnung, es wäre auch gut, alles zentral und schnell auffindbar zu haben...
Das ist jedoch keine einfache Aufgabe... Und sehr arbeitsintensiv obendrein...
Hättest Du einen konkretten Vorschlag?
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

martinschm

Hi,

mein erster Ansatz wäre zB die commandref und das PDF Dokument ins Wiki zu überführen.
Vorteil:
- Ein Ort für die Informationen
- Das PDF verlinkt an einigen Stellen eh direkt ins Wiki
- Bessere Auffindbarkeit von Informationen über Suchmaschinen

Beim Wiki wäre es hilfreich, wenn es im ersten Schritt eine Gesamtübersicht aller Seiten gäbe.

Der schwierigste Schritt ist sicherlich die Informationen die sich aus einer Diskussion im Forum ergeben in eine strukturierte Wiki Seite zu überführen. Da habe ich noch keine Idee, vielleicht finden wir hier gemeinsam eine Lösung.

ciao
Martin

rudolfkoenig

#3
Das commandref hat seine Berechtigung: es wird vom Modulautor gepflegt in der gleichen Datei wie sein Code. Es muss genau und vollstaendig sein. Diese Dokumentation ist Voraussetzung fuer ein "richtiges" FHEM-Modul, und dabei bleibt es auch.

Das Wiki sollte von den Anwendern gepflegt werden: sie haben eine andere Sicht, die Artikel muessen auch nicht modulspezifisch sein, und auch nicht alle Attribute/etc in Detail beschreiben. Ich sehe z.Zt. die Aufgabe hier, die Informationen aus dem Forum ins Wiki zu uebertragen, die Artikel dort zu aktualisieren und die Information besser zu strukturieren.

Die ideale Reihenfolge fuer Anfaenger waere Ulis Heimautomatisierung-mit-fhem.pdf um eine erste Vorstellung von FHEM zu haben, dann spezielle fhemwiki Artikel, und fuer Details das commandref.

Rince

Ich denke, von Hand ist das eine ziemlich langwierige Sache.

Also Info aus Forum in Wiki. Weniger wegen der Schreibarbeit, mehr um überhaupt die Infos im Forum zu finden. Da mich grade meine Gesundheit seit Weihnachten fast dauernd ans Bett fesselt, hatte ich die vergangenen Wochen viel viel Zeit um im Forum jede Menge Threads einfach zum Zeitvertreib zu lesen ;)

Oft werden Lösungen gefunden, ohne diese dann nochmal darzulegen. Wenn wieder wer mit dem Problem da steht, hilft es nicht zu wissen, dass jemand das erfolgreich vor 4 Monaten gelöst hat.
Weiterhin ergeben sich, oft in längeren Threads, klevere Lösungen für andere Wehwechen.

Ich gehe voll mit Rudi, wir bräuchten redaktionell aufbereitete HowTo's

Jeder verstreichende Tag läßt mehr wertvolles Wissen in den Tiefen der Informationsflut des Forums unter gehen. (schöne Metapher, gell ;) )



Ich wünsche mir daher ein Beitrags Rating. Beitrag - nicht Thread oder User!

Ein Knopf mit dem Titel:
Das ist eine Lösung (so in der Art)

Am besten noch mit eintragbaren Schlagwörtern.

Und zwar von jedem User eintragbar.

Ziel:
Wenn wer über eine, in seinen Augen clevere, Lösung stolpert, kann er den Beitrag markieren und verschlagworten.

Wenn jetzt jemand anders unter akuter Langeweile leidet, könnter er einfach mal das Forum nach hilfreichen Beiträgen durchsuchen, diese aufbereiten und ins Wiki packen.

Am besten meldet er das dann einem dafür eingerichteten Moderator, also Beitragslink und Wikilink, und dieser fügt dann unten am Beitrag ein Sätzchen ein wie:
"Dieser Beitrag ist im Wiki aufbereitet, LINK"


Mods zum Beitragsrating gibt es für das SMF. Das Wiki haben wir schon, engagierte User auch.
Fehlt noch ein Moderator, der für das reineditieren der Links zuständig ist.
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

marvin78

Wichtig wäre auch, dass die Forensuche zuverlässiger wird. Es kommt (zumindest bei mir) immer häufiger vor, dass man einen Suchbegriff eingibt und bei der ersten Suche nichts gefunden wird. Erst wenn man noch einmal nach dem gleichen Begriff oder Ausdruck sucht, wird dann etwas gefunden. Das ist mir zwar nun bewusst und stört mich nicht weiter, erschwert aber Neulingen das Suchen und Finden.

martinschm

Hi,

@rudolf: Ich will das commandref ja nicht abschaffen. Ich will auch hier nicht die Sinnfrage für einzelne Dokumente stellen, das maße ich mir nicht an. Es geht mir ja lediglich darum die Informationen besser auffindbar zu machen.

In anderen Open Source Projekten wie zB Joomla http://www.joomla.org/about-joomla/the-project/project-teams.html haben sich verschiedene Projekt-Gruppen gebildet, die sich zB dann um einzelne Bereiche wie Organisation der Dokumentation kümmern.

Ich habe die FHEM Community als sehr engagiert erlebt, vielleicht bedarf es nur eines kleinen Anstosses um so etwas zu initiieren.

ciao
Martin

rudolfkoenig

Zitatvielleicht bedarf es nur eines kleinen Anstosses um so etwas zu initiieren.

So funktioniert das nicht. Es bedarf jemanden, der sagt, das stoert mich, ich fange jetzt an das zu verbessern, und der Rest soll das bitte auch machen. Wenn die Idee nicht abstrus ist, dann folgen auch einige, die Loewenarbeit bleibt aber beim Initiator.

Zu sagen, ich vermisse was, und das ist noch nicht gut, reicht nicht, um Andere zum Arbeit in deinem Sinne zu motivieren. Es sei den Du kratzt geschickt an dem Ego eines Modulautors, aber das ist nicht der Fall bei Doku-Organisieren.

Rince

Ich versuche das grade schon.

Eine unterhaltsame Sammlung an Codebeispielen mit steigendem Schwierigkeitsgrad und verschiedenen Anwendungsfällen.
Ist aber bis jetzt nicht wirklich spruchreif, bin erst langsam mit dem 1. Kapitel durch.



Wer wirklich nen Blick riskieren will, kann mir ne PM mit seiner eMail schicken, dann gibts Zugriff via Google Docs.
Als Gegenleistung hätte ich gerne ein kurzes Feedback, sowie mindestens 1 Verbesserungs / Themenvorschlag ;)
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

martinschm

Hi Rudolf,

bitte nicht falsch verstehen, es sollte kein Aufruf a la "mich stört das, macht ihr mal bitte sein". Ich wollte das ganze mal zur Diskussion stellen und schauen ob es anderen auch noch so geht wie mir.

Falls dies der Fall ist, kann man gemeinsam überlegen was wir anstellen können um es zu verbessern.

ciao
Martin

hexenmeister

Ich bin auch der Meinung, der commandref gehört so, wie es ist. Ist ja Modull-Doku und kann eigentlich bei jeder Installation unterschiedlich sein. Die Qualtät der Doku ist jedoch sehr durchwachsen. Manche Module sind sehr ausführlich beschrieben, manche so gut wie garnicht. Leider ist das deutsche Teil fast nicht vorhanden. Aber alles in allem schon sehr nützlich und i.d.R. ausreichend.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

martinschm

Dann fassen wir das commandref halt nicht an.
@hexenmeister: vielleicht macht es Sinn einen Standard oder Template als Orientierungshilfe zu haben.

BeamterAD

Ich kann mich da nur anschließen,ich war auch schon mal dran und wollte im Wiki einige Artikel zusammenfassendie ich schon mal gelesen hatte und die alle zusammengehören,aber ich habe sie teilweise nicht wiedergefunden teilweise haben sich die Artikel  überschnitten,teilweise funktioniert der Code gar nicht mehr ,weil die Module mittlerweile überarbeitet worden sind usw.
Meine Idee:Erst einmal eine Struktur reinbringen
Dann Inhalte prüfen,zusammenführen und dann fehlende Informationen aus dem Forum einfügen.
Um keine bestehenden Infos zu verlieren wäre es besser ein 2.Wiki aufzusetzen und erst bei Fertigstellung einzuspielen.
ICH BIN DABEI!

hexenmeister

Zitatvielleicht macht es Sinn einen Standard oder Template als Orientierungshilfe zu haben.
Für commandref gibt es sie ja. Es ist jedoch ein Unterschied, ob man eine ausführliche Doku schreibt., mit Beispielen etc, oder bloß einen kurzen Satz. Die Struktur ist wichtig, aber alleine nicht ausreichend.
Andererseits habe ich schon 'professionel' entwicklete Software gesehen, die wesentlich schlechter dokumentiert war ;)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

martinschm


Franz Tenbrock

#15
Hallo , bin seit 8 Monaten dabei,
am Anfang mit dem Einsteiger PDF die ersten Steckdosen definiert, dann die Rolladen dann EM1000
Ich denke viele Anfänger machen am Anfang immer das gleiche, und da ist das Einsteiger PDF super.
Für Dummys geschrieben.
Dann kommt man auf den Geschmack und will einfach mehr,
Da hab ich immer wieder die Probleme mit der nciht so einfachen Syntax gehabt also immer wieder im Einsteiger pdf gelesen und Fragen gestellt.

kurzum

ich hab dann auch meinen ersten Wiki Beitrag geschrieben und hoffe das der eine oder andere das gebrauchen kann und dann auch besser versteht wie man was machen kann. zisterne Füllstandsanzeige mit Ultraschallsensor.
Sicher nicht perfekt, aber das kann man ja noch verbessern.

So kommt ev auch ein anderer Anfänger in den Genuß das selber umzusetzen.

Es wäre einfach shcön wenn ein Problem gelöst ist das dann ein Wiki Eintrag verfasst wird. Dabei wäre es ev gar nciht verkehrt wenn ein Anfänger der das gemacht hat ( und im Forum Hilfe bekommen hat ) den Artikel schriebt und ein Pate ( erfahrener User ) das gegenliest.
Der Anfänger wird sicher zu dem einen oder anderen etwas merh schreiben und erklären, das ist sicher aber nciht schlecht da sicher alle Anfänger dei gleichen Probleme haben

Ich hab jetzt eine schöne Markisensteuerung die werde ich wohl als nächstes in Wiki stellen, denn nun weiß ich ja wie es geht

cubi3, Cul 868, ESA2000WZ, EM1000GZ,  FS20, dashboard, 1-Wire, Max Thermos, Max Wandthermo, Max Lan, Fritzbox callmonitor, , nanocul, HM Led16, HM Bewegungsmelder, HM Schalter, RPi, banana, ESP8266, DoorPi

P.A.Trick

Also ich habe jetzt auch drei Wiki Artikel geschrueben, aber nur weil ich auch etwas geben wollte und nicht nur nehmen! Ich bin dafür, dass die Anwender das übernehmen wie Rudi schon sagte. Also los geht es ich bin dabei :-)
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

tinyfhem

#17
Ich hatte und habe auch Schwierigkeiten, die richtigen Informationen zu finden. Habe eben heute zusammenfassend einen "Erfahrungsbericht" aus den ersten 3 Monaten mit FHEM hier ins Forum gestellt. Ich kann mich Franz' Antwort (#15) in allen Punkten anschliessen.

ich denke die command ref, insbesonders die Englische Version, sollte so bleiben wie sie ist, also zumindest konzeptionell, so dass jeder module owner die aus seinem source code heraus erstellt und pflegt.

Das Wiki erscheint mir das geeignete Medium zu sein um zusammen, als team engagierter user die notwenidgen Inhalte in geeigneter Form verfuegbar zu machen und ich wuerde mich daran auch gerne beteiligen. An wen muss ich mich wenden um mitmachen zu duerfen?
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

martinschm

Hi tiny
Im Wiki auf der Startseite verlinkt findest du die Kontaktdaten der Admins. Von denen bekommst du ein Account. Eine irgendwie organisierte Dokugruppe gibt es noch nicht. Bisher dokumentiert jeder wie er Zeit findet.

Ciao
Martin

hexenmeister

Zitat von: tinyfhem am 09 April 2014, 13:09:53
...
An wen muss ich mich wenden um mitmachen zu duerfen?

fhemwiki, Hauptseite:

ZitatAdministratives zum Wiki

Allgemeine Aktivitäten:   
  • Registrierung zur Mitarbeit: wende Dich bitte an einen Administrator
  • ...

;)

http://www.fhemwiki.de/wiki/Benutzer:Soulman
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy