Unterstützung bei Aktualisierung von https://fhem.de/HOWTO_DE.html gesucht!

Begonnen von krikan, 06 Juni 2017, 12:05:45

Vorheriges Thema - Nächstes Thema

krikan

Zitat von: CoolTux am 09 März 2018, 14:41:28
Oh je bitte nicht. Du möchtest nicht wirklich einem Anfänger das Developer Dokument lesen lassen? Macht das nicht, das verwirt noch viel mehr und der Anfänger denkt man muß programmieren können um Grundlagen des FHEM zu verstehen.
Ich möchte nur eins: nicht den xten Definitionsversuch
Von mir aus auch sehr gerne keine Definition und keine Links. Bisher sind wir bei HOWTO ohne ausgekommen.

drhirn

Hihi, DOIF scheint echt ein rotes Tuch zu sein. Dabei hab ich's extra nach dem notify hingeschrieben. ;D

Ich hätt's praktisch gefunden, wenn die Begriffe irgendwo mit einem kurzen Satz erklärt werden. Kommt nämlich in den "Ersten Schritten" auch nicht so wirklich rüber. Aber ich bekomm auch keine Krise, wenn wir's weglassen.

krikan

Zitat von: drhirn am 09 März 2018, 14:55:09
Hihi, DOIF scheint echt ein rotes Tuch zu sein.
Nein.
Das ist nur so funktionsreich, dass ich es gerade für den Anfang und für das Verständnis unglücklich finde. Aber das ist nur meine Meinung...
Zitat
Ich hätt's praktisch gefunden, wenn die Begriffe irgendwo mit einem kurzen Satz erklärt werden. Kommt nämlich in den "Ersten Schritten" auch nicht so wirklich rüber.
Okok, wenn ihr es für wichtig haltet, dann versucht eine Begriffsdefinition abzuliefern. Vielleicht bin ich ja zu eingefahren.




Beta-User

So, habe zwischenzeitlich etwas rumeditiert und m.E. zu vielen Themen ganz ordentliche Kompromisse gefunden, indem ich Fußnoten benutzt habe. Das hält den eigentlichen Text kurz (teilweise sogar kürzer als bisher) und damit besser lesbar, man hat aber gleichzeitig eine schnelle Referenz woanders hin oder kann kurz erläutern, wo die FTDI-ID herkommt, die beispielhafte Angabe 1234 usw..

Die meisten Komemntare habe ich bei der Gelegenheit gelöscht, mir schien, die Richtung war zwischenzeitlich geklärt, wenn das falsch gewesen sein sollte, bitte "Aua" schreien.

Aber mit der Sch...-Formatierungssyntax komme ich überhaupt nicht klar!!! An der Stelle daher ein riesiges DANKE an drhirn, der da erst mal für ziemlich Ordnung geschaffen hat!

Und vergiss dieses Modul, wir haben es nicht erwähnt und brauchen auch nicht weiter drauf rumzureiten. Wir machen beim howto erst mal KISS, und das ist reine Zeit- _oder_ Ereignissteuerung.

Was die Frage angeht, ob es wirklich Definitionen der Begriffe braucht, hatte ich ja meine Meinung kundgetan. Für's Howto wäre die Frage, ob man FHEM-Begriffe, die man mit help aufrufen kann, irgendwie separat kennzeichnen kann bzw. will (als fetter kursiver code oder so). Aber wie gesagt, ich werde das vermutlich nicht mehr lernen, wie das geht...

Jetzt bin ich erst mal wieder betriebsblind, mit dem hinteren Teil geht's dann irgendwann weiter (bitte ggf. nochmal anstupsen, wenn's zu lange dauert...).

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Eisix

Hallo,

hätte noch eine Idee für das Howto. Bei "Schnittstellen zur realen Welt" könnte man Sachen zeigen die ohne irgendwelche USB-Sticks funktionieren. Einfach um eine schnelle Möglichkeit zu haben damit zu spielen. Als Appetithappen sozusagen.
z.B.:
- SYSMON
- DLNARenderer   (speak "Hallo Fhem User!")
- FRITZBOX

Passt vielleicht auch in "Erste Schritte" um die Leute anzufixen ;)

Gruß
Eisix



Beta-User

Hallo Eisix,

Danke für die Anregung.
Die Idee, das zwar (auch) konkret, aber hardwareunabhängig zu machen, ist an sich sehr gut und konstruktiv.

Neulich hatte ich auch schon kurz über den Punkt nachgedacht, das aber dann doch wieder verworfen. Konkret war mein erster gedanklicher Aufhänger "Weather" gewesen. Das hat ich mich allerdings dann recht unsanft daran erinnert, dass Yahoo gelegentlich mal seine Web-Schnittstelle geändert hat, und das jedes mal recht ärgerlich gewesen war. Das müßte man dann also auch in Howto jedesmal auch wieder aktualisieren. (Dazu habe ich persönlich keine Lust).

Kurz meine Meinung zu den von dir angeführten Modulen:
- SYSMON: Hatte ich eine Zeitlang installiert, v.a. um Prozessortemperaturen zu loggen. Ich habe einige Linux-Erfahrung (eher user), aber ich fand das nicht sooo einfach zu konfigurieren (was sind die richtigen Parameter oder soll ich einfach den Standard verwenden?!?) und es liefert sehr viele Readings. Wäre mir vom Eindruck her zu unübersichtlich
- DLNARenderer: Kenne ich nicht, ich mache keine Sprachausgabe und habe auch kein DNLA-fähiges Gerät (zumindest vermutlich nicht bzw. ich nutze es nicht als solches). Wenn man Audio-Devices konkigurieren muß, ist es sicher kein geeignetes Einstiegsdevice, aber nochmal: Ich kenne das Modul nicht.
- FRITZBOX: War auch eines der ersten Devices, das ich mit dem Einsteiger-Guide eingerichtet hatte. An sich sehr nett, aber mittlerweile sollte man wohl sehen, dass man das mit TR064 ans laufen bekommt. Das ist dann wieder was, was einiges an Attributen benötigt, dann benötigt man einige Perl-Module, und ob man jetzt Perl-telnet (?) auch braucht oder nicht ist völlig unklar. Und man muß Passwörter usw. setzen. Ist also nach meinem Eindruck auch eher sehr hoch als Einstiegshürde, zumal dazu auch ein längerer Wiki-Artikel existiert - vermutlich nicht ohne Grund.

Wäre nach meinem persönlichen Geschmack daher eher etwas für weiterführende Dokumente, nicht direkt im Howto (Ziel war doch weiterhin, das eher komprimiert zu halten, oder?).

Überhaupt Abhängigkeit von Modulen: Mind. FRITZBOX und SYSMON benötigen weitere Perl-Module; da sollte dann jeder user doch eher einigermaßen bewußt entscheiden, was er sich "reinziehen" möchte.

Andere Meinungen bzw. andere Modulvorschläge, die sich einfacher umsetzen ließen?

[OT]Da wir hier auch Befindlichkeiten diskutieren: Mir persönlich geht es nicht darum, jemandem "Einstiegsdrogen" zu liefern oder "anzufixen". Mir liegt zum einen daran, den hier zu Beginn geäußerten Wunsch verdienter "alter Hasen" nach Entlastung zu erfüllen und zum anderen intelligenten Menschen, die an FHEM grundsätzlich interessiert sind, eine nachvollziehbare Entscheidungshilfe zu bieten, ob FHEM der Baukasten ihrer Wahl werden soll oder nicht.

Mal wieder nix für ungut, ich weiß schon, dass das jeweils nicht böse gemeint war...[/OT]
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Zitat von: Beta-User am 09 März 2018, 15:15:20
So, habe zwischenzeitlich etwas rumeditiert und m.E. zu vielen Themen ganz ordentliche Kompromisse gefunden, indem ich Fußnoten benutzt habe. Das hält den eigentlichen Text kurz (teilweise sogar kürzer als bisher) und damit besser lesbar, man hat aber gleichzeitig eine schnelle Referenz woanders hin oder kann kurz erläutern, wo die FTDI-ID herkommt, die beispielhafte Angabe 1234 usw..

Das war eine ausgezeichnete Idee!

Zitat von: Beta-UserAber mit der Sch...-Formatierungssyntax komme ich überhaupt nicht klar!!!
Einfach fragen, wenn's Unklarheiten gibt. Ich schau immer da nach, wenn ich vergessen habe, wie etwas geht.

Zitat von: Beta-UserFür's Howto wäre die Frage, ob man FHEM-Begriffe, die man mit help aufrufen kann, irgendwie separat kennzeichnen kann bzw. will (als fetter kursiver code oder so).
Eigentlich auch eine gute Idee. Ein Text, der erscheint, wenn man den Mauszeiger drauflässt z.B. Muss ich mal schauen, ob's sowas schon gibt. Und sonst könnte man's mit einer Vorlage abbilden.

Beta-User

Zitat von: drhirn am 09 März 2018, 17:05:06
Das war eine ausgezeichnete Idee!
8) Sowas hört man doch gerne...
Zitat
Einfach fragen, wenn's Unklarheiten gibt. Ich schau immer da nach, wenn ich vergessen habe, wie etwas geht.
Na ja, das ganze erinnert mich halt an die guten alten Zeiten, als es noch ein WordPerfect 5.x für DOS gab. Aber da hatte man wenigstens die Option, die Formatierungszeichen im Ganzen zu löschen bzw. mit Funktionstasten einzufügen. Die auch noch selbst zu tippen ist nicht nur lästig und fehleranfällig, es ist auch sehr unübersichtlich - jedenfalls nach heutigen Maßstäben.
Ich mache halt c&p aus anderen Dokumenten, dann klappt das meistens ::) . Und wenn du dann hinterher drübergehst, kann man es auch ansehen.
Zitat
Eigentlich auch eine gute Idee. Ein Text, der erscheint, wenn man den Mauszeiger drauflässt z.B. Muss ich mal schauen, ob's sowas schon gibt. Und sonst könnte man's mit einer Vorlage abbilden.
War eine spontane Idee. Wenn es einfach ist und gut aussieht, dann: Klasse! wenn nicht: nicht so wichtig. Investiere die Zeit lieber in die Formatierung des gesamten Textes, ich versuche dann, es nicht wieder "zu kaputt" zu machen, wenn ich wieder was ändere ;)

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Zitat von: Beta-User am 09 März 2018, 17:30:52Die auch noch selbst zu tippen ist nicht nur lästig und fehleranfällig, es ist auch sehr unübersichtlich

Musst du eigentlich nicht. Gibt eh den Editor. Kann aber gut sein, dass der bei dir nicht aktiviert ist. Wenn ja, dann in den Einstellungen siehe Screenshot.

Beta-User

...Man lernt nie aus, Danke!

Habe jetzt auch den erweiterten Editor aktiviert :) . Ist zwar immer noch sehr zeichen-orientiert, aber man findet wenigstens schneller die wichtigsten Formatierungsbefehle usw..

Schön wäre noch, wenn man das "live" nebendran wyswyg verfolgen könnte, aber so ist es halt wie früher: Was wirklich ausgegeben wird, sieht man erst wirklich beim "Drucken" (bzw. nach dem Starten von Windo.* bzw. der Voransicht)... Na ja, werde wohl auch das überleben ;D .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Ein bisschen Herausforderung braucht der Mensch. Sonst wird's ja fad. Und die Spannung bis man sieht, was dabei herauskommt, ist ja auch nicht ohne. ;)

Beta-User

So.

Habe doch nochmal drübergesehen und bin "für's erste" eigentlich ganz zufrieden :) . Die Seite könnte nach meinem Geschmack eigentlich den "Baustellen"-Status wieder verlieren (was nicht heißt, dass weitere Vorschläge nicht willkommen wären).
(das ging an @krikan mdB. um Rückmeldung bzw. Umsetzung!)

Habe nur noch ein paar Befehle eingepflegt, überflüssiges gelöscht und am Ende auf einige Befehle@commandref verlinkt, die man (nach meiner persönlichen Meinung) mit Priorität ansehen sollte. Was ich bewußt auch was weggelassen habe, was andere vielleicht für das wichtigste überhaupt halten, könnt ihr euch denken; wer sich dafür revanchieren will, darf "sleep" und "cancel" löschen ;) .

Wenn das dann sowas ist wie eine allg. akzeptierte 1. Fassung, würde ich mich ggf. bei Gelegenheit mit meinen beschränkten Englisch-Kenntnissen mal an eine Übersetzung wagen. Wäre aber _überhaupt nicht_ böse, wenn sich da jemand finden würde, dem sowas leichter von der Hand geht ::) ...

So long erst mal,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Und zu guter Letzt für heute auch noch ein fettes Danke für die Erinnerung, dass ich da ja noch was erledigen wollte ;) .
Habe jetzt zwar noch nicht den großen Wurf mit Cluni's Rolladenlösung gemacht, aber ein einfacher Weekdaytimer mit einem Ausführungsteil, der "TYPE=CUL_HM:FILTER=model=HM-LC-Bl1PBU-FM:FILTER=automode=1" enthält, hat jetzt auch die restlichen Devices einer bestimmten Sorte aus meiner configDB gefegt.

Als Helferlein war "setreading" tätig, vielleicht sollte ich das noch in die Liste der Befehle aufnehmen, die man kennen sollte. Aber vermutlich übersehe ich an der Stelle irgendeine Nebenwirkung 8) , die diese Art des Vorgehens hat. userattr gibt es ja auch nicht umsonst. Mal schauen ::) .

Jetzt mache ich noch eine kleine ReadingsGroup dafür, dann kann auch jeder aus meiner Familie der Steuerung leicht beibringen, dass zu frühes automatisches Rolladenöffnen nicht erwünscht ist...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

curt

Mein Status zur Diskussion:
Ich habe mich eingemischt. Die Diskussion habe ich mit allen neuen Beiträgen gelesen. Den nun geänderten Stand des howto kenne ich nicht, das habe ich nicht gelesen.

Mein Status zum Forum:
Ich bin seit vielen Jahren im usenet und Foren unterwegs. Mit diesem Forum tue ich mich schwer: Oft erhalte ich an Stelle einer Antwort ein "Lies commandref". Danke Schlauberger, hab' ich schon. Ich habe es nicht verstanden, sonst würde ich doch nicht fragen. Inzwischen verlege ich meine Fragen oft auf PN, das wirkt mir zielführender.

Mein allgemeiner Status:
Ich bin ITler, dem UNIX-Konzepte und Perl nicht fremd sind. FHEM nutze ich seit gut einem halben Jahr, das ist gut gewachsen, da ist bei mir gut was los (ich muss mal meinen Footer anpassen). Gleichwohl bin ich Anfänger, viele FHEM-Konzepte kenne ich gar nicht, manche andere verstehe ich nicht.

Zur Sache, zur Diskussion:
Vorab möchte ich nochmals sagen, dass ich das alte howto überhaupt nicht kenne (was ein Vorteil sein mag), dass ich den neuen howto-Entwurf (gestern) kenne - und das ich vor allem niemandem auf die Zehen treten möchte: Wenn ich eins in diesem Forum lernte, dann das: Alle sehr sensibel.

Inzwischen scheint mir, dass die Zieldefinition noch gar nicht klar ist: Was soll das neue howto eigentlich bewirken, was ist das Ziel?

Anfangs verstand ich: Es geht um Sicherheit eines kompletten FHEM-Systems. Da werden ja Unmengen an verschiedensten Schnittstellen aufgemacht. Die kann man klassifizieren, danach kann man in ein howto schreiben, was bei jeder Klasse zu beachten ist. Das schrieb ich in meinem ersten Beitrag.

Später las ich in der Diskussion einen interessanten Einwurf, da ging es darum, dass es um Anfänger und einen ersten Überblick ginge - das fand ich einen interessanten Einwurf.

Und soeben las ich noch die Vokabel Glossar - auch dazu komme ich noch, natürlich alles aus meiner bescheidenen Sicht.

Ich fange an:
Ein grundsätzliches howto "FHEM-Sicherheit" halte ich für unabdingbar. Das hatte ich in #23 schon näher beleuchtet.

Den Gedanken "Anfänger mit UNIX-Kenntnissen will schnelle Ersterfolge" aufnehmend sollte/könnte es ein howto "Let's start" geben: Auf der Basis eines existierenden, betriebsbereiten RPi (noch ohne irgendwelche Antennendingser) wird eine schrittweise nachvollziehbare Arbeitsanleitung gegeben, wie man FHEM aufsetzt, wie man das im Browser aufruft, wie man irgend ein erstes Device (da fiele mir mangels Antennen Internet-Wetter, sagen wir Yahoo oder Unwetterwarnung ein) aufsetzt. Wie man das dann optisch schön macht, mit "da klicken" und mit "schöne Grafiken". Denn in dem Fall kann es nur um schnelle erste Erfolge gehen.

howto-Glossar - dazu will und muss ich etwas sagen. (Ok, howto und Glossar beißt sich.)
Mir fehlt ein Glossar für Anfänger. Es fehlt mir immerzu. Also wirklich für Anfänger. Wenige wichtige Einträge. Die dann aber in normalen Deutsch - Wiki und Forum kranken für Anfänger daran, dass da eine unerständliche FHEM-Sprache gesprochen wird.

Ich meine ein Glossar, in dem verständlich gesagt wird, was eigentlich eine Device ist, was ein Actor ist, was ein Attribut ist und wie das abgekürzt wird, was ein Reading ist, was eine readingsGroup ist.

Und wenn ich mich dann kritisch selbst betrachte, müsste in jedem Glossar-Eintrag stehen, wo es weiter geht. Ich erkläre genauer, an mir selbst: Bei den hier erwähnten Sachen wie DOIF oder notify ahne ich, was das sein könnte. Ich lese solche Vokabeln ja oft, also scheint das wichtig zu sein. Aber wo ist ein Glossar, wo mir nur die für Anfänger wichtigen Begriffe erklärt werden (gern mit Link auf commandref + wiki + nachvollziehbares Beispiel).

Man kann einwenden, dass ich das selbst rauskriegen kann. Klar, ich habe ja mal studiert, kein Problem. Aber da suchst Du immerzu Nadeln in Heuhaufen. Das dauert, das dauert richtig. Und ich muss ganz nebenbei arbeiten, habe Familie, Haus und Garten.

Wenn ich mich zu jedem einzelnen Punkt (das kann ich schon) druchkämpfe, habe ich anschließend Arbeit, Familie, Haus und Garten nicht mehr, Damit würde sich dann FHEM erübrigen: Was habe ich dann noch zu überwachen, zu steuern zu regeln?

Bitte nicht auf den Schlips getreten fühlen, Beitrag gern ignorieren: Ich bin der mit der Einzelmeinung.
RPI 4 - Jeelink HomeMatic Z-Wave

pcbastler

Zitat von: Beta-User am 09 März 2018, 16:41:21
Überhaupt Abhängigkeit von Modulen: Mind. FRITZBOX und SYSMON benötigen weitere Perl-Module; da sollte dann jeder user doch eher einigermaßen bewußt entscheiden, was er sich "reinziehen" möchte.

Andere Meinungen bzw. andere Modulvorschläge, die sich einfacher umsetzen ließen?

Das "Killer-Feature" von FHEM war für mich beim Einstieg die Anwesenheitserkennung (Handy im WLAN der Fritzbox). Das wäre evtl. für den Einstieg (ohne zusätzliche Hardware )auch ein interessanter Ansatz.