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

Beta-User

@curt:

Danke für deinen Einwurf.

Es würde mich sehr freuen, wenn du die jetzige Fassung des HOWTO wenigstens kurz überfliegen würdest.

Du hast natürlich völlig damit recht, dass das Thema Sicherheit an sich einer umfassenden und aktuellen Darstellung bedarf. Dem wird die jetzige Fassung sicher nicht gerecht. Zu unser aller Verteidigung: das war  auch nicht die ursprüngliche Zielrichtung des Howto. Dieses war allerdings im dort noch "Sicherheit" genannten Punkt seit der Einführung des "allowed" völlig veraltet, was nach meinem Eindruck der Anlaß für diesen Hilferuf war.

Die jetzige Fassung ist (nach meinem zugegebenermaßen ziemlich betriebsblinden) Verständnis jetzt wieder sehr viel besser geeignet, Leuten, wie du vor einigen Moinaten noch warst, den Einstieg etwas zu erleichtern. Wenn das gelungen ist, bin ich persönlich an der Stelle halbwegs zufriedend - besser machen geht selbstredend immer.

Gerne können wir auch aus deinem vorherigen Beitrag so etwas machen wie eine allgemeine Einführung in zu beachtende Sicherheitsaspekte - mir gehen nämlich die unbedarften Neulinge auch ziemlich gegen den Strich, die irgendwann verstehen, dass InterTechno-Befehle auch ihr Nachbar senden kann und WLAN recht einfach zu stören ist (und die ESPEasy-firmware Sicherheitslücken aufweist), nur weil ihnen das keiner rechtzeitig beigebogen hat.

Aber nochmal: es gibt Überschneidungen, aber eigentlich ist es ein Thema für ein weiteres Buch.

Und da meine Rollandensteuerung jetzt provisorisch (hoffentlich) funktioniert, wie sie soll, unterstütze ich diese Initiative auch wieder gern (wenn gewünscht). Ich gebe nur vorab zu Bedenken: Ich bin weder IT'ler noch beruflich da "irgendwie" reingerutscht. MaW: ich verstehe von diesen Dingen kaum was und versuche nur ports zu öffnen, von denen ich glaube, dass ich sie dauerhaft kontrollieren kann.

Und neben dem Überfliegen hätte ich eine weitere Bitte: Vielleicht hast du weitere Ideen, wie man das ganze noch _etwas_ besser gestaltet, indem man - ggf mit Fußnoten oder so - noch _kurze_ Erläuterungen zu den FHEM-Begrifflichkeiten einfügt, damit auch "Normalos" verstehen, was jeweils gemeint ist.

Ach und noch was: Wir sind zu zweit! Ich bin auch sehr oft der mit der etwas abweichenden Einzelmeinung ;) . Manchmal schaffe ich es, andere zum Nachdenken zu bringen, das freut mich dann sehr. Oft liege ich auch falsch. Ist weniger erfreulich, wird aber durch die anderen Erlebnisse aufgewogen ::) .

You are welcome! (Jedenfalls von meiner Seite)

Zitat von: pcbastler am 09 März 2018, 21:22:48
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.
Hmmm, (sorry für die doofe Frage, ich habe da bisher auch einen Bogen drum gemacht): Da geht es um presence, also eigentlich um ein einfaches pingen, oder? Das könnte in der Tat ein guter Ansatz sein. Scheint auch nicht zu verdächtig zu sein, FHEM lahmzulegen (was leider bei vielen Web-Themen der Fall zu sein scheint). Man kann das dann zwar nicht schalten, aber das ist m.E. an der Stelle nicht so wichtig, wie die Einführung dazu, wie FHEM an Infos kommt.

Hättest du einen kurzen Textvorschlag zu diesem Teil?

Andere Meinungen?
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

Zitat von: pcbastler am 09 März 2018, 21:22:48
Das "Killer-Feature" von FHEM war für mich [...]

Es wäre ein interessanter Ansatz, bei neuen Nutzern (kleiner ein Jahr) mal zusammenzutragen, was die Motivation war.

Diese Teildiskussion zerstört vermutlich den Lesefluss der eigentlichen Diskussion, vielleicht kann ein Moderator diese Teildiskussion auslagern.

Das "Killer-Feature" von FHEM war für mich:
Ein Fenster stand offen. Das Alter, der Stress, man kennt das ja: Es ist früh, es regnet, es ist kalt, man muss schnell los, hastig-hastig. Mehrfach stand ein Fenster sehr einladend offen.

Da wäre doch sehr schön, wenn ich ganz kurz mit dem Handy aus der Ferne ... aber bitte ohne Cloud, ohne Drittanbieter, ohne Datenabfluss. So kam ich zu FHEM. Der oft sehr wirren Diskussion der Heise-Foren sei dank.
RPI 4 - Jeelink HomeMatic Z-Wave

Beta-User

@curt: Du kannst gerne (passend vermutlich in Off-Topic) einen Thread dazu anfangen und auch von hier dahin verlinken, die OT-Diskussion ist noch nicht so groß, als dass das wirklich störend wäre.

[OT]Ich wollte nur nicht im Haus rumrennen und Rolläden hoch- und runtermachen, also wurden die bei der Renovierung elektrisch. Da es mir aber auch nicht gefallen hätte, alle 6 Monate die Uhr an irgendwelchen einzelnen Zeitschaltuhren von Sommer- auf Winterzeit umzustellen und umgekehrt (so mache ich das im Haus meiner Schwiegermutter), wollte ich das zentral erledigen können.

"Damals" wurde FHEM noch als einfach zu installierende Lösung "beworben", für die man nicht mehr wie eine Fritte und einen CUL braucht. Dann hat AVM den Deal gekündigt, und ich hatte Mühe, ohne Windo.*-Rechner die Fritte nach dem Umzug auf einen Pi wieder so zu säubern, dass automatische updates laufen...

Vielleicht versteht ihr jetzt besser, warum ich latent  angepisst bin, wenn jemand sagt, ein FHEM zu betreiben sei einfach >:( .
Na ja, mittlerweile kann ich das ja - jedenfalls zu meiner eigenen Zufriedenheit 8) . [/OT]

EDIT: Natürlich wollte ich auch in der Platzierung der Schalter etwas freier sein, und sicher fällt mir dann noch mehr ein.
Ich wollte euch aber auch nicht vorenthalten, dass ich jetzt meine readingsGroup dann auch soweit habe. Geht sicher noch hübscher, aber es ist ein Anfang:
defmod rg_Rollaeden readingsGroup <Gerät>,<Offen>,<automode>,<Offen-Pos.>,<Gekippt-Pos.>,<Jalousie>,<On-Hold> (Rolladen_.*|Jalousie_.*)..:level,automode,?WindowContactOpenMaxClosed,?WindowContactTiltedMaxClosed,?JalousieTurnLevel,?WindowContactOnHoldState,
attr rg_Rollaeden commands {'level' => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100','automode' => 'automode:0,1,2,3,4,5','WindowContactOpenMaxClosed' => 'WindowContactOpenMaxClosed:10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100','WindowContactTiltedMaxClosed' => 'WindowContactTiltedMaxClosed:10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',}
attr rg_Rollaeden room Steuerung
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

Zitat von: Beta-User am 09 März 2018, 21:47:26
Es würde mich sehr freuen, wenn du die jetzige Fassung des HOWTO wenigstens kurz überfliegen würdest.

Nicht in dieser Sekunde. Weil:
Mir ist die ganz grundsätzliche Intention noch nicht ganz klar. Es mag sein, dass die nur mir nicht klar sind. Aber vielleicht sind sie grundsätzlich nicht klar - in dem Fall wäre erstmal sehr klar zu definieren, was überhaupt das Ziel der Veranstaltung ist.

Für mich ist ein howto ein Kochrezept für gebildete Doofe: Linke Hand an linken Griff. Rechten Fuß auf die erste Stufe. Linken Fuß auf die ... Beispielfoto.

Das meinte ich mit einem Absatz "wir setzen mal auf bestehendem RPi ein FHEM auf, bauen eine Device, machen zwei Attribute [Foto], machen etwas Formatierung [Foto]. Und dann freuen wir uns gemeinsam am Ersterfolg (Stichwort menschliches Belohnungssystem).

Zitat von: Beta-User am 09 März 2018, 21:47:26
Zu unser aller Verteidigung:

Es gibt nichts zu verteidigen: Es lag kein Angriff vor.

Das ist das komische, das völlig ungewohnte in diesem Forum. Ansich bin ich gewohnt, ohne Schnörkel präzise zu fragen. Das funktioniert in technischen Foren (Beispiel: ubuntuusers). Genau das funktioniert in diesem Forum nicht. Ansich kannst Du einen Bot schreiben, der auf jeden Beitrag mit einem Fragezeichen als Antwort "Lies commandref" rausrotzt, damit hast Du dann das Forum aus Sicht eines Anfängers umfänglich umschrieben.

Zitat von: Beta-User am 09 März 2018, 21:47:26
Dieses war allerdings im dort noch "Sicherheit" genannten Punkt seit der Einführung des "allowed" völlig veraltet, was nach meinem Eindruck der Anlaß für diesen Hilferuf war.

Das Thema "Sicherheit" ist im eigentlichen Sinne gar kein Thema, was sich für ein howto eignet. Ansich müsste "Sicherheit" ein Artikel im Wiki werden, der dann ausschließlich die Schnittstellen nach Klassen (siehe mein Eingangsartikel) beleuchtet. Ich halte das für wirklich wichtig, da brennt im Grunde die Hütte.

Zitat von: Beta-User am 09 März 2018, 21:47:26
Die jetzige Fassung ist (nach meinem zugegebenermaßen ziemlich betriebsblinden) Verständnis

Da trifft sich "betriebsblind" mit "naiv": Ich bin im Sinne der Sache naiv. Da Naivität nicht zwingend mit Dummheit gleichzusetzen ist, hat das auch Betrachtungsvorteile.

Zitat von: Beta-User am 09 März 2018, 21:47:26
Gerne können wir auch aus deinem vorherigen Beitrag so etwas machen wie eine allgemeine Einführung in zu beachtende Sicherheitsaspekte - mir gehen nämlich die unbedarften Neulinge auch ziemlich gegen den Strich

Ja - siehe oben.
Allerdings denke ich da wirklich an einen eher kurzen Überblicksartikel, der (wie in meinem ersten Beitrag beschrieben) lediglich Server, FHEM, Schnittstellen nennt. Und all diese lediglich verständlich diskutiert. Jeder Unterpunkt hat dann je einen Link auf genauere Betrachtung (erstmal Stubs). Wiki-Syntax kann ich. Anmelden werde ich wohl auch schaffen. Die Frage ist eher: Was passiert, wenn ich einen rohen Artikel schreibe und dann noch fünf Stubs anlage - und das Ganze ohne Kenntnis der dort geltenden informellen Regeln? Ich schreibe eher ungern für die Tonne.

Zitat von: Beta-User am 09 März 2018, 21:47:26
Aber nochmal: es gibt Überschneidungen, aber eigentlich ist es ein Thema für ein weiteres Buch.

Dafür wären ja Links da.
Im Grunde würden wir einen weiteren Namensraum im Wiki schaffen, einen ganz neuen Mikrokosmos. Dazu hätte ich allerdings eine Idee: Wikipedia kennt ja das Kategoriekonzept. Keine Ahnung ob das hier goutiert wird. Aber das würde uns die Möglichkeit schaffen, eine Kategorie "Für Beginner" zu schaffen. Die vielleicht in der allerersten Zeit auch Welpenschutz hat.

Zitat von: Beta-User am 09 März 2018, 21:47:26
Und neben dem Überfliegen hätte ich eine weitere Bitte: Vielleicht hast du weitere Ideen, wie man das ganze noch _etwas_ besser gestaltet, indem man - ggf mit Fußnoten oder so - noch _kurze_ Erläuterungen zu den FHEM-Begrifflichkeiten einfügt, damit auch "Normalos" verstehen, was jeweils gemeint ist.

Ich würde das andersrum angehen - dazu muss ich leider ausholen:
Ich rede mir ja ein, dass ich die Fachsprache "wir reden IT" wirklich beherrsche. Aber (und das ist bis heute mein Problem) bei FHEM ist alles anders. Da gibt es unendlich viele Vokabeln, unendlich viele Abkürzungen, da träumt ja der Militär von. Und die haben schon eine tolle Geheimsprache, die auch irgendwie deutsch klingt. Hinzu kommt, dass in FHEM Vokabeln überdefiniert werden. Was ein Device ist, ist ansich in der IT wohldefiniert. Es mag historisch gewachsen und dadurch bedingt sein: In FHEM liegt die Wahrscheinlichkeit, dass eine Device nun wirklich im IT-Sinne eine Device ist, bei höchstens 10%. Das muss man erstmal verstehen ...

Also ich würde das von mir vorgeschlagene allgemeine Glossar befürworten. Erklärungsbedürftige Vokabeln, die dort nicht vorhanden sind, als Fußnote im Artikel.

P.S: Ich schreibe das alles irgendwie auch aus Eigennutz. Ich finde das Projekt dermaßen geil, habe unendlich viele Ideen für meinkleinHäuschen. commandref hilft mir nicht, wiki hilft mir nicht, Forensuche fördert Threads mit 80 Seiten zu Tage - soll ich jede Seite wirklich lesen? Aber im Grunde wäre es so einfach - ich lerne am besten an Beispielen.

PP.S: Beispiel: https://forum.fhem.de/index.php?action=dlattach;topic=37378.0;attach=69879;image
Boah, issja geil. Haben will! Das will ich bauen, ich muss da nichtmal das allerletzte Attribut verstehen. Es muss dann halt tun. Wo ist das howto dazu?
RPI 4 - Jeelink HomeMatic Z-Wave

Eisix

Hallo Curt,

Zitat
PP.S: Beispiel: https://forum.fhem.de/index.php?action=dlattach;topic=37378.0;attach=69879;image
Boah, issja geil. Haben will! Das will ich bauen, ich muss da nichtmal das allerletzte Attribut verstehen. Es muss dann halt tun. Wo ist das howto dazu?

Ist meins. Kann dir die aktuellen sourcen schicken und die devices dahinter erklären. Hast aber nie danach gefragt! Ist mühsam sich das ganze aus einem 80 Seiten Thread rauszuholen. Bastelt sich halt jeder was für sich zusammen und schreibt nicht noch eine Doku dazu die veröffentlicht wird.

Gruß
Eisix

curt

OT
Beziehungsweise nur teilweise offtopic - es wird aber auch wider ontopic.

Zitat von: Eisix am 09 März 2018, 23:19:19
Ist meins. Kann dir die aktuellen sourcen schicken und die devices dahinter erklären. Hast aber nie danach gefragt! Ist mühsam sich das ganze aus einem 80 Seiten Thread rauszuholen.

Hallo Eisix,

ich weiß nicht mehr, was ich im Forum suchte. Jedenfalls stolperte ich Anfänger über Deinen Beitrag und den (von mir verlinkten) Screenshot. Und ich dachte mir: Das muss ich mir unbedingt speichern, wenn ich mal groß bin, will ich sowas geiles haben.

Dein Angebot nehme ich sehr-sehr gern an. Erkläre mir bitte, wie man sowas wunderschönes macht. Aber bitte nicht in dem 80-Seiten-Thread! Da findet das doch niemand. Ich habe doch nichtmal geschafft, Dein Posting dort zu finden, ich hatte nur den Screenshot als Bookmark gespeichert.

Ich nehme herzlich gern Dein Angebot wahr: Kannst Du mir das Vorgehen bitte in einem völlig neuen Thread erklären? So, dass ich das schrittweise dann auch bei mir habe?

Damit sind wir wieder ontopic: Denn das wäre ja ein howto.
Ich habe ein ganz geiles, viel gelobtes Dings - und ich gebe euch jetzt das Kochrezept. Wenn ihr euch an mein Kochrezept haltet, habt ihr das auch auf dem eigenen Tisch.

Zitat von: Eisix am 09 März 2018, 23:19:19
Bastelt sich halt jeder was für sich zusammen und schreibt nicht noch eine Doku dazu die veröffentlicht wird.

Daran krankt es - aus meiner Anfängersicht.

Ich hatte übrigens nicht erwartet, dass der Ersteller/Konstrukteur/Designer/Coder sich meldet. Das war von mir nur als Beispiel gedacht. Um so mehr freue ich mich, dass Du Dich gemeldet hast.
RPI 4 - Jeelink HomeMatic Z-Wave

Beta-User

Witzig, wie klein die Welt manchmal ist. Irgendwie auch bezeichnend, dass ihr euch gerade hier in diesem Thread  "wiedergefunden" habt.

Was den grundsätzlichen Einwand von curt angeht: Mittlerweile sehe ich das auch kritisch, ob "HOWTO" die richtige Etikette ist. Das war ja auch die Irritation, die andere z.B. unter dem Stichwort "instructables" geäußert hatten.

Ich persönlich hätte keinerlei Problem damit, die Etikette zu ändern. Gibt es Einwände von "höherer Stelle" dazu? Vorschläge? Schnellschüsse meinerseits: "Schnelleinstieg", "Kurzreferenz"

Dass wir "Neuen" uns alle ziemlich unwohl fühlen mit der vorhandenen Doku zeigen ja auch Otto's und mein erster Post hier (und wer mag, kann ja meine User-Vorstellung "Meine Hausaufgaben"  mal nachlesen, da sieht man, wie lange mich das Thema schon umtreibt). Als "Kochrezept für Doofe" würde ich  übrigens das Einsteiger-pdf ansehen, da ist wirklich vieles einfach zum Nachkochen drin. Leider ist es an manchen Stellen veraltet und FS20 bzw. HM-lastig.
Was also wieder fehlt, ist auch nach meinem Eindruck ein schlüssiges Gesamtkonzept, das einen interessierten Starter wirklich zu einem funktionierenden "Basis-FHEM" einschließlich einer ansprechenden ersten Seite (defaultRoom mit der einen oder anderen readingsGroup, _nicht_ aber ein konkretes anderes Frontend) leitet und dann auch an die anderen Schnittstellen sauber weiter verzweigt (Floorplan, FTUI usw.).

Und meine Beobachtung ist die: Es passiert was, aber wenig. Am ehesten wird noch daran gearbeitet, wenn man "einfach mal loslegt" und die Dinge dann eben der Kritik öffentlich aussetzt, wie krikan das ja auch angeregt hat. Wir sollten nur aufpassen, dass nicht wieder jemand in 5 Jahren kommt und zurecht kritisiert, dass "unsere" Art der Darstellung völlig ... (was auch immer) war und leichter zu aktualisieren ist wie das pdf.

Zu den übrigen Stichworten:
Es gab zum wiki bisher nicht so richtige Vorgaben, außer der, dass die Darstellung neutral zu sein hat (so hatte ich das jedenfalls frei interpretiert). Ich würde das ergänzen mit: Wer was anfängt, sollte es in einem erträglichen Zustand hinterlassen...

Kategorisieren geht im Wiki, ich finde sowas wie ein "Für Beginner"-Label  übrigens eine ausgezeichnete Idee! (Sowas in die Richtung steckte auch hinter dem wine-Hinweis mit "bronce, silver & gold").

Mit dem "Einsteiger" oder "Basis" oder "...."-Label würde ich übrigens noch die Stichworte defaultRoom, readingsGroup, WeekdayTimer, readingsProxy, THRESHOLD bekleben wollen.

Just my2ct
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

@krikan:
Du bist ja immer noch der owner dieses Threads. Bitte um Rückmeldung, wenn das hier "zu bunt" wird.

Was ich zur Auslagerung vorschlagen würde, wäre die Sache mit den Kategorien, das ist ja etwas, was das Wiki allgemein betreffen würde. Bevor ich da aber eine Lawine mit einer Umfrage oder so lostrete: Macht sowas überhaupt Sinn, oder wäre das ein nutzloser Schnellschuß?

EDIT: Ich sehe grade, dass es hier eine etwas anders gelagerte, aber teilweise verwandte Diskussion gibt. Müßte man ggf. dann noch abstimmen, wie das mit dem folgenden zueinander paßt.

@all
Wenn ja, wären weitere (welche?) Level sinnvoll?

Meine Tendenz wäre: nicht zu viele und jeweils eine Erläuterung wäre vermutlich auch hilfreich. Ich würde spontan nur englische Begrifflichkeiten bevorzugen und diese Richtung andenken:

Starter: Dinge, die man schnell kennen lernen sollte, um ein funktionsfähiges FHEM zu haben
Basis: Dinge, die jeder kennen sollte. Grundlagenwissen. In Perl gedacht: if-Abfrage
Advanced: Schwieriger zu konfigurieren, benötigt ggf. etwas Perl (Umgang mit einfachen Variablen und Schleifen)
Expert: Besser erst ansehen, wenn man ca. eine Handvoll "Advanced"-Themen erfolgreich gelöst hat

[OT]Der auf Automatik eingestellte Teil meiner Rolläden machte heute morgen genau dann das, was er sollte. Das bedeutet: Mein WeekdayTimer-Provisorium funktioniert definitiv heute schon besser als die mehrfach erfolglos verschlimmbesserte vorherige Lösung ;D [/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

Jetzt interessiert mich dann aber langsam schon, was du mit deinen Rolläden angestellt hast, dass du dich so drüber freust ;).

Ansonsten wäre ich dafür, dass wir zuerst das HOWTO (oder wie auch immer man es nennen mag) zweisprachig zu Ende führen, bevor wir uns von anderen Ideen ablenken lassen. Oberstes Ziel muss sein, eine kurze Dokumentation für Einsteiger zu schaffen.

Aber jetzt bin ich vorläufig mal ruhig, bis ich den heutigen Kater überstanden habe. Also bis übermorgen ;D

krikan

Zitat von: Beta-User am 10 März 2018, 11:06:54
Was ich zur Auslagerung vorschlagen würde, wäre die Sache mit den Kategorien, das ist ja etwas, was das Wiki allgemein betreffen würde. Bevor ich da aber eine Lawine mit einer Umfrage oder so lostrete: Macht sowas überhaupt Sinn, oder wäre das ein nutzloser Schnellschuß?

EDIT: Ich sehe grade, dass es hier eine etwas anders gelagerte, aber teilweise verwandte Diskussion gibt. Müßte man ggf. dann noch abstimmen, wie das mit dem folgenden zueinander paßt.
Löst bei mir aus: Angst
Warum: Gerade das Thema Kategorien wurde schon x-mal angegangen. Es endete immer wieder in einem unstrukturierten Kategorien-Durcheinander im Wiki, weil es nicht zu Ende geführt/gedacht und dauerhaft gepflegt wurde. Anschließend musste dann jemand anderes das wieder aufräumen und dem fehlt die Zeit für den eigentlichen Inhalt. Da es nur sehr wenige aktive Wiki-Schreiber gibt, die dauerhaft über ihren "eigenen" Artikel hinaus mitarbeiten (keine Kritik!), bleibt das immer an den Gleichen hängen.
Zum Vorschlag: Schwierigkeitsgrad. Wer bestimmt die Einstufung? Das ist mMn für jeden anders und daher schwer pflegbar.
Bitte auf jeden Fall den Vorschlag mit Peter (ph1959de) abstimmen und am besten in einen separaten Thread auslagern.

Ob der Artikel in alter Tradition "HOWTO" heißt oder einen anderen sinnvollen Namen hat, ist mir persönlich gleichgültig. Entscheiden dürfen die, die die Arbeit gemacht haben (ihr).
Ansonsten stimme ich drhirns obigen Satz mit "Ansonsten..." zu.  :)
Besser Schritt für Schritt als eierlegende Wollmilichsau.

Beta-User

OK, Danke für die klare Rückmeldung!

Dann bleibt also vorerst noch:
- Wie taufen wir das Kind? Vorschläge? (sollte wohl am Ende dann krikan umsetzen)
- Braucht es noch ein hardwareloses Device? (M.E. eher nicht, und wenn, dann eher in dem jetzigen Anmerkungskasten rechts)
- Device erklären? (Wäre dafür, nicht wesentlich mehr als: Kann, muß aber nicht zwingend ein physisches Gerät sein. Device bei FHEM ist schlicht alles, für das eine "define ..."-Anweisung existiert bzw. eingegeben wurde/wird/werden kann.

[OT]Zu meinen Rolläden:
Hatte ich unten ja kurz angerissen. Einfach mit setreading ein Reading mit Namen "automode" an alle Rolladenaktoren verteilt (FILTER s.u.) und mit "0" vorbelegt. Jetzt kann ich die, die ich automatisch fahren will, damit beliebig kennzeichnen (habe mal an bis zu 5 Gruppen gedacht, im Moment sind die schlicht auf "1", Einstellung via notify für Urlaub, Gäste in best. Räumen+readingsGroup). Dazu kommt ein einfacher Weekdaytimer mit einem Ausführungsteil, der "TYPE=CUL_HM:FILTER=model=HM-LC-Bl1PBU-FM:FILTER=automode=1" enthält:

defmod Timer_Rolladen_Automode_1 WeekdayTimer TYPE=CUL_HM:FILTER=model=HM-LC-Bl1PBU-FM:FILTER=automode=1 !$we|06:45|on $we|08:40|on 22:30|off {fhem ("set $NAME:FILTER=STATE!=$EVENT $EVENT")}
attr Timer_Rolladen_Automode_1 commandTemplate set $NAME  $EVENT
attr Timer_Rolladen_Automode_1 group Türen und Fenster
attr Timer_Rolladen_Automode_1 icon fts_shutter_automatic
attr Timer_Rolladen_Automode_1 room Steuerung

Wenn ich dann noch lustig bin, mache ich noch ein notify, dass ggf. vor dem Endezeitraum auf hereinbrechende Dunkelheit reagiert (mit disableForIntervals), dann habe ich das auch "wie früher". Oder ich nutze (zusätzlich) sunrise&co...
[/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

Eisix

[OT]
@curt schau Mal in dein Postfach und gib mir Rückmeldung ob du damit was anfangen kannst.
[\OT]

drhirn

Habe noch ein paar kleine Änderungen vorgenommen. Da stand z.B., man solle was in die fhem.cfg eintragen ;)

Kann bitte jemand den Abschnitt "Daten aufzeichnen und darstellen" überarbeiten? Ich glaube, der ist nicht verständlich.

Und sollen wir am Schluss vielleicht noch auf die anderen Dokumente (PDF, Erste Schritte, etc.) verweisen?

Beta-User

So, anbei auch noch ein erster Wurf der englischen Übersetzung (ohne den vermutlich zurecht kritisierten Teil zu Daten aufzeichnen usw., das ggf. der Überarbeitung bedarf; Basis war die noch nicht überarbeitete deutsche Fassung, sollte also ggf. auch dahingehend nochmal geprüft werden, wobei das mit dem "Eintrag in die fhem.cfg" da schon raus ist).

Das pdf und die ersten Schritte sind ja im Text schon aufgeführt, das wäre also ggf. eine Doppelung.

Was die "ersten Schritte" angeht, geht es mir zwischenzeitlich wie anderen mit "Howto" - ich empfinde das nicht mehr ganz als zutreffende Begrifflichkeit. Das klingt so, als müsse man diese gehen. Einen besseren Vorschlag habe ich aber grade auch nicht. Dafür fände ich es keine schlechte Idee, dort ggf. statt eines der Dummy's ein presence-Device vorzustellen und damit zu schalten (nur aus dem Kopf, ich habe mir das nicht im Detail angesehen), und das ist beides hier ja auch nicht das Thema.

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

Christoph Morrison

Zitat von: Beta-User am 12 März 2018, 15:01:45
So, anbei auch noch ein erster Wurf der englischen Übersetzung (ohne den vermutlich zurecht kritisierten Teil zu Daten aufzeichnen usw., das ggf. der Überarbeitung bedarf; Basis war die noch nicht überarbeitete deutsche Fassung, sollte also ggf. auch dahingehend nochmal geprüft werden, wobei das mit dem "Eintrag in die fhem.cfg" da schon raus ist).

Ich lese den gerade Korrektur.