Diskussion:Erste Schritte in FHEM: Unterschied zwischen den Versionen

Aus FHEMWiki
Zur Navigation springen Zur Suche springen
Zeile 111: Zeile 111:
::ich habe die Bedenken hinsichtlich einer Ergänzung des Einsteigerartikels in meiner Naivität unterschätzt.
::ich habe die Bedenken hinsichtlich einer Ergänzung des Einsteigerartikels in meiner Naivität unterschätzt.
::Gegen die Abstimmung einer Ergänzung habe ich selbstverständlich nichts einzuwenden.
::Gegen die Abstimmung einer Ergänzung habe ich selbstverständlich nichts einzuwenden.
::Ich stehe voll hinter Deinem Ansatz "Einfachheit durch weglassen". Deshalb schlage ich vor, die Beispiele, die  at und notify verwenden durch DOIF zu ersetzen, dann wird dem Einsteiger nur ein Modul zugemutet. Das ist möglich weil durch DOIF die Angabe generischer Auslöser vereinfacht und harmonisiert wurde. DOIF funktioniert ohne Kenntnis "regulärer Ausdrücke" <code>Angabe eines Auslösers [<name>:<reading>] vs. <name>:<reading>.*</code>, <code>Angabe eines Zeitpunktes [HH:MM:SS] vs. HH:MM:SS</code> und <code>Angabe einer Zeitspanne [HH:MM:SS-HH:MM:SS] vs. <hier müsste jetzt ein at-Experte etwas schreiben></code>. Diese wegweisende, von Dir als properitär bezeichnete Syntax, hat den Set-Befehl beeinflusst, bekannt als ''set magic'' <code>set <name> [<gerät>:<reading>]</code>.
::Ich stehe voll hinter Deinem Ansatz "Einfachheit durch weglassen". Deshalb schlage ich vor, die Beispiele, die  at und notify verwenden durch DOIF zu ersetzen, dann wird dem Einsteiger nur ein Modul zugemutet. Das ist möglich weil durch DOIF die Angabe generischer Auslöser vereinfacht und harmonisiert wurde. DOIF funktioniert ohne Kenntnis "regulärer Ausdrücke" <code>Angabe eines Auslösers [<name>:<reading>] vs. <name>:<reading>.*</code>, <code>Angabe eines Zeitpunktes [HH:MM:SS] vs. HH:MM:SS</code> und <code>Angabe einer Zeitspanne [HH:MM:SS-HH:MM:SS] vs. <hier müsste jetzt ein at-Experte etwas schreiben></code>.


::Wenn Du die Regexp-Syntax im DOIF als properitärer bezeichnest, dann trifft das auch auf die Syntax von at und notify, beim notify werden z.B. intern die Begrenzungszeichen ^ und $ gesetzt, ohne es in der Befehlereferenz zu erwähnen.
::Diese wegweisende, von Dir als properitär bezeichnete Syntax, hat den Set-Befehl beeinflusst, bekannt als ''set magic'' <code>set <name> [<gerät>:<reading>]</code>.
::====Beispiel====
 
::Wenn Du die Regexp-Syntax im DOIF als properitär bezeichnest, dann trifft das vielmehr auch auf die Syntax von at und notify, beim notify werden z.B. intern die Begrenzungszeichen ^ und $ gesetzt, ohne es in der Befehlereferenz zu erwähnen.
::<u>Beispiel</u>
::Ausgehend von den Events
::Ausgehend von den Events
<pre>
<pre>

Version vom 21. Februar 2017, 20:33 Uhr

Die Sache mit dem doppelten Semikolon

Gerade für den Anfänger an den sich dieses Dokument richtet, wäre es sehr wichtig zu verstehen, warum das Semikolon verdoppelt werden muss und was damit geschieht (es wird nur einfach in DEF gespeichert). Das wird hier nur anhand des daraus resultierenden Symptoms erklärt: "Sofort ausführen oder später". Aber das warum wäre m.E. gerade hier für das Verständnis beim Einstieg wichtig. Ansonsten ist es auch schwer nachzuvollziehen, warum man den gleichen Befehl den notify ausführen soll auf der Kommandozeile mit verdoppeltem Semikolon und beim editieren des Internals DEF dann wieder ohne Verdoppelung schreiben muss. Drei Überlegungen dazu:

  1. Könnte man das Beispiel mit der Verdoppelung noch um das Editieren des Internals DEF erweitern und dabei genau das erläutern. Ohne diese Erkenntnis ist die Tücke dieses Konstrukts schwer verständlich und der Anfänger wundert sich warum seine Lampe auf den Status on; define a1 at +00:01 set myLampe1,myLampe2 off o.Ä. gesetzt wird.
  2. Gibt es überhaupt sinnvolle Fälle, in denen ein verdoppeltes Semikolon im DEF benötigt wird. Spätestens bei dem hier benötigten vierfach Semikolon sollte man wissen was damit wann geschieht.
  3. Gibt es sinnvolle Zustände die ein Semikolon enthalten? Wäre da eine Warnung möglich?

Viele Grüße --MGu (Diskussion) 18:10, 17. Apr. 2016 (CEST)

Falsche und indirekte negative Darstellung von notify/at im Vergleich zu DOIF

Hallo!

Die bewertende Aussage "Bei der Kombination von Ereignis (Bewegungsmelder meldet eine Bewegung) und Zeitangaben werden die stärken des DOIF deutlich. Es ist nur eine Definition (Gerät) notwendig. Wollte man dies durch die Verwendung von at und notify lösen, wären mehrere Definitionen notwendig oder ausreichende Perl-Kenntnisse." insbesondere im Zusammenhang mit dem Beispiel halte ich für falsch und bringt Einsteiger auf eine vollkommen falsche Spur/Sichtweise.

Die nur zeitweise Ausführung eines notify bzw. at erreicht man durch Setzen des Attributes disabledForIntervals. Damit muss man für die Umsetzung des Beispiels beim notify nur das passende Zeitintervall im genannten Attribut setzen. Es sind keine weiteren Definitionen notwendig.

Wenn der DOIF-Abschnitt erhalten bleiben soll und meine Aussage richtig ist, dann bitte ich um kurzfristige Entfernung der Wertung und auch Darstellung der Lösung des erweiterten Beispiels mit einem notify und dem Attribut disabledForIntervals. Das Wiki sollte nach Möglichkeit eine neutrale Sichtweise vermitteln, wenn es nicht eindeutige Vor- oder Nachteile gibt, die ich hier nicht erkenne.

Da es sich um einen wichtigen Artikel handelt, werde ich spätestens morgen selbst Änderungen vornehmen, um nicht Einsteigern falsche Sichtweisen zu vermitteln.

Gruß, --Christian (Diskussion) 09:43, 12. Feb. 2017 (CET)


Bin auch für "rückgängig machen", insbesondere auch, da diese Seite auf dem Einsteigerdokument von Uli Maass basiert und nur mit seinem Einverständnis ins Wiki übernommen wurde. Darüber hinaus ist die DOIF-Ergänzung sicherlich als redaktionelle Erweiterung anzusehen und allein aus diesem Gesichtspunkt schon mit Uli abzustimmen. --Peter (Diskussion) 09:20, 13. Feb. 2017 (CET)

Jep, war auch mein erster Gedanke --Drhirn (Diskussion) 09:27, 13. Feb. 2017 (CET)

Habe die Änderungen komplett zurückgesetzt.
Begründung:
  • die vergleichenden Aussagen sind falsch
  • ein Einverständnis der redaktionellen Änderung liegt afaik nicht vor und die Änderung wurde hier nicht vorab diskutiert. (den Hinweis darauf im Vorspann des Artikels hatte ich zuvor übersehen)
Wiedereinbau ist nach Abstimmung mit Uli und mit korrekter Darstellung nach Review grundsätzlich möglich. Dazu Änderungsvorschläge hier auf der Diskussionsseite einstellen.
--Christian (Diskussion) 09:48, 13. Feb. 2017 (CET)

Ist der Abstimmungsvorbehalt nicht unzulässig? Oder gilt der Hinweis über dem Speichern-Button nicht für Alle Wiki-Benutzer "Falls du nicht möchtest, dass deine Arbeit hier von anderen verändert und verbreitet wird, dann klicke nicht auf „Seite speichern“."

Die vergleichenden Passagen werde ich ändern.

--Trelle (Diskussion) 12:10, 13. Feb. 2017 (CET)


Hmm, diese Seite ist einfach ein Sonderfall. Uli Maas hat da ursprünglich ein PDF-Dokument erstellt, das lange als Einstiegslektüre zu FHEM gehandelt wurde. Ich habe nur damals nach Rücksprache mit ihm die Erlaubnis bekommen, das PDF ins Wiki zu übernehmen. Die "Rechte" liegen aber sozusagen immer noch bei Uli. Deswegen habe ich das extra in der Einleitung erwähnt. Sowie auch diesen Punkt: "Redaktionelle Änderungen und Erweiterungen aber bitte mit dem Autor (z.B. auf der zugehörigen Diskussionsseite) abstimmen."
Wie gesagt, ein Sonderfall. Bitte nicht persönlich nehmen.
--Drhirn (Diskussion) 12:52, 13. Feb. 2017 (CET)

Hallo!
Abstimmungsvorbehalt liest sich hart :-) . Es ist eine Bitte, die Du wahrscheinlich übersehen hast, und die in diesem Fall (Artikel) ihre Begründung hat. Das ist ein wichtiger Grundlagenartikel der überall verlinkt wird und darum richtig und objektiv sein soll. Der Inhalt wurde zuvor von mehreren Personen reviewed. Änderungen sollten daher vorher abgesprochen und besprochen werden, damit sie auch richtig sind.
Hätte ich den Artikel nicht auf der oberen Beobachtungsprioriät, wäre vielleicht falsches Wissen verbreitet worden und das ist für niemanden sinnvoll. Genau darum habe ich auch die schnelle Reaktion angekündigt und umgesetzt.
Das Problem der Änderung durch jedermann ist auch ein Aspekt, warum das Einsteiger-PDF nicht im Wiki steht.
Ich persönlich denke, dass man gewisse Bitten respektieren sollte. Genauso habe ich damals Damians Bitte respektiert, dass im Wiki die Anwendungsbeispiele zu DOIF entfernt werden und das umgesetzt. Er stand DOIF-Artikeln im Wiki insgesamt kritisch gegenüber. Deine Artikel zu DOIF wurden auch intern beratschlagt, ob sie im Sinne von Damian "zulässig" sind. Angesichts der sehr guten Qualität und auch Eurer engen Zusammenarbeit bei der Fortentwicklung von DOIF haben wir das als gegeben hingenommen.
Insgesamt setzen wir im Wiki auf einen großzügiges Rechtesystem ohne Review vor Freigabe. Zudem darf jeder fast jede Seite ändern und anpassen. Bei Besonderheiten -wie hier- werden bisher entsprechende Bitten/Hinweise ausgesprochen, die man einhalten sollte.
Gruß, --Christian (Diskussion) 13:49, 13. Feb. 2017 (CET)

Hallo, ich bin gerne bereit hier einen Entwurf zum Review einzustellen, damit die Qualität des Artikels gewährleistet bleibt. DOIF gehört als grundlegendes Automatisierungselement in ein Einstiegsdokument, da stimmst Du mir sicherlich zu.

Wenn Abweichungen zu den Wiki-Lizenzbedingungen mit einzelnen Autoren von euch vereinbart werden, solltet Ihr nicht deren Klärung, Abstimmung u. Einhaltung auf die Benutzer abwälzen, sondern nach dem Verursacherprinzip selbst durchführen. Zumal dem Benutzer nicht ohne Weiteres bekannt ist, unter welchem Avatar er den Autor findet.

Diese Forderung: "und auch Darstellung der Lösung des erweiterten Beispiels mit einem notify und dem Attribut disabledForIntervals." halte ich für pure Willkür, denn das gilt ja nur für mich, solange die anderen Beispiele nicht mit DOIF-Beispielen ergänzt werden. Sie ist sicherlich ähnlich entstanden, wie meine vergleichenden Textpassagen.

Den Absimmungsvorbehalt habe ich so verstanden, als Vorbehalt und ich habe ihn nicht über sehen, sondern ignoriert. Aber nicht ohne auf die Seite von Uli zu schauen, wo Du seit 16:26, 2. Okt. 2015 auf eine Antwort wartest.

Hier mein Vorschlag zum Review:

Zeit- und Eventsteuerung, DOIF vereint at und notify

Aufgabenstellung: Ein Treppenhauslicht soll durch einen Bewegungsmelder eingeschaltet werden, aber nur zwischen 18 Uhr und 8 Uhr.

Bei der Kombination von Ereignis (Bewegungsmelder meldet eine Bewegung) und Zeitangaben werden die Stärken des DOIF deutlich.

Zeitangaben erfolgen im DOIF in eckigen Klammern [HH:MM] für einen Zeitpunkt und [HH:MM-HH:MM] für eine Zeitspanne.

Hier ist vorausgesetzt, dass der Bewegungsmelder als Gerät mit dem Namen BM definiert wurde und er ein Reading mit dem Namen motion besitzt. Das Reading motion nimmt bei erkannter Bewegung den Wert on an und nach Verschwinden der Bewegung den Wert off. Auf die Statusänderung des Bewegungsmelders wird auch wieder über Angaben in eckigen Klammern [gerätename:readingname] zugegriffen.

Bei erkannter Bewegung soll geschaltet werden, also wenn der Status des BM auf on wechselt. Dies wird geprüft durch einen vergleichenden Operator eq (equal). Die Zeitangaben und der Ereignisvergleich werden durch den logischen Operator and verknüpft. Der set-Befehl wird ausgeführt, wenn die ganze Bedingung logisch wahr wird, das ist nur der Fall, wenn zwischen 18 Uhr und 8 Uhr eine Bewegung erkannt wird.

Die Definition des DOIF ist einfach:

define treppenhaus_di DOIF ([18:00-08:00] and [BM:motion] eq "on") (set th_Licht on-for-timer 60)

Es sind natürlich auch flexible Zeitangaben möglich, die sich auf den Sonnenauf u. -untergang beziehen.

define treppenhaus_di DOIF ([{sunset}-{sunrise}] and [BM:motion] eq "on") (set th_Licht on-for-timer 60)

Es können auch Zeiten angegeben werden, die in Readings des DOIF-Gerätes selbst stehen und über das WEB-Frontend verändert werden können.

define treppenhaus_di DOIF ([[$SELF:Beginn]-[$SELF:Ende]] and [BM:motion] eq "on") (set th_Licht on-for-timer [$SELF:Dauer])

ErsteSchritte DOIF.png

Weitere Ausführungen zum DOIF würden den Rahmen der ersten Schritte sprengen. Wenn das Interesse an DOIF geweckt wurde, gibt es im DOIF Labor ausführbare Beispiele zum Importieren über Raw definition.

und die Ergänzung in: Sie haben nun kennengelernt:

  • DOIF: Zusammenfassen von Ereignissteuerung (notify) und Zeitsteuerung (at)

--Trelle (Diskussion) 16:39, 13. Feb. 2017 (CET)

Ich habe eine Selbstrevision durchgeführt und den obigen Text überarbeitet.

--Trelle (Diskussion) 18:30, 13. Feb. 2017 (CET)


Hallo allerseits,
vielen Dank für die rege Diskussion zu diesem Artikel.
In der Tat wär's mir wie geschrieben lieb, wenn redaktionelle Änderungen vor dem Einfügen mit mir abgesprochen würden.
Bezgl. DOIF: ich kenne das Modul aus Posts und Diskussionen im Forum, nutze es aber selbst nicht und konnte/kann deshalb auch nix dazu schreiben. Insofern vielen Dank für die Zulieferung eines neuen Abschnitts.
Da diese Anleitung sich speziell an den Einsteiger wendet, der vielleicht das erste mal nen Blick auf FHEM wirft, hab ich mit dem Einbinden des DOIF-Beispiels 2 Sorten Bauchschmerzen:
1. es zeigt dem Neuling gleich beim allerersten Kontakt mit FHEM mehrere Alternativen für denselben Sachverhalt auf, das hallte ich für verwirrend.
2. DOIF verwendet eine proprietäre Syntax in regexp - auch diese hat zumindest in der Anfangszeit das Potential, den Neuling zu verwirren.
Mein Ansatz ist "Einfachheit durch weglassen" - das würde möchte ich auch auf diese Diskussion und mithin DOIF anwenden.
Vorschlag: aus diesem Artikel rauslassen, aber in die nächste Version des Einsteiger-pdf aufnehmen - das ist ja wesentlich umfangreicher und versucht, möglichst viele hilfreiche Module vorzustellen und z.T. auch zu erklären - dort wäre so ein DOIF-Artikel m.E. wesentlich besser aufgehoben.
Wenn ich endlich mal zur besagten nächsten Version komme, melde ich mich wieder mit der Bitte um input.
Gruß und schönen Tag allerseits, Uli
--Uli (Diskussion) 09:12, 19. Feb. 2017 (CET)

Hallo Uli,
ich habe die Bedenken hinsichtlich einer Ergänzung des Einsteigerartikels in meiner Naivität unterschätzt.
Gegen die Abstimmung einer Ergänzung habe ich selbstverständlich nichts einzuwenden.
Ich stehe voll hinter Deinem Ansatz "Einfachheit durch weglassen". Deshalb schlage ich vor, die Beispiele, die at und notify verwenden durch DOIF zu ersetzen, dann wird dem Einsteiger nur ein Modul zugemutet. Das ist möglich weil durch DOIF die Angabe generischer Auslöser vereinfacht und harmonisiert wurde. DOIF funktioniert ohne Kenntnis "regulärer Ausdrücke" Angabe eines Auslösers [<name>:<reading>] vs. <name>:<reading>.*, Angabe eines Zeitpunktes [HH:MM:SS] vs. HH:MM:SS und Angabe einer Zeitspanne [HH:MM:SS-HH:MM:SS] vs. <hier müsste jetzt ein at-Experte etwas schreiben>.
Diese wegweisende, von Dir als properitär bezeichnete Syntax, hat den Set-Befehl beeinflusst, bekannt als set magic set <name> [<gerät>:<reading>].
Wenn Du die Regexp-Syntax im DOIF als properitär bezeichnest, dann trifft das vielmehr auch auf die Syntax von at und notify, beim notify werden z.B. intern die Begrenzungszeichen ^ und $ gesetzt, ohne es in der Befehlereferenz zu erwähnen.
Beispiel
Ausgehend von den Events
2017-02-21 19:25:09 dummy du3 B: off
2017-02-21 19:25:10 dummy du3 B: on
würde ich eine exakte Regexp so formulieren ^du3$:^B: (on|off)$. Das funktioniert im notify nicht, im DOIF schon, also nur mal zum Thema "properitäre Syntax".


Hier mein Gegenvorschlag: DOIF statt at und notify in die "ersten Schritte" aufnehmen.


Dieser Vorschlag folgt Deinem Ansatz "Einfachheit durch weglassen" zielführend, daher bitte ich Dich diesen Vorschlag anzunehmen.
DOIF ins Einsteiger-pdf aufzunehmen ist eine gute Idee, aber das kann ja noch dauern, wie Du selbst andeutest.
LG Trelle
--Trelle (Diskussion) 20:22, 21. Feb. 2017 (CET)