Diskussion:Erste Schritte in FHEM: Unterschied zwischen den Versionen

Version vom 20. Mai 2017, 17:52 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:

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.
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.
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])

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>.*, eine einfache Readingsangabe reicht im DOIF
Angabe eines Zeitpunktes: [HH:MM:SS] vs. *HH:MM:SS,
und Angabe einer Zeitspanne, die einen Neustart überlebt: [HH:MM:SS-HH:MM:SS] vs. *HH:MM:SS ...;;define at *HH:MM:SS ...

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 zu, 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)

Hallo an alle Beteiligten der Disskussion Erste Schritte,

die Antwortzeiten sind hier ja recht lang, da hatte ich Gelegenheit meinen Vorschlag für die Erweiterung der "Ersten Schritte" noch einmal gründlich zu überarbeiten. Es sollte jetzt keine Formulierungen mehr geben, die den Verdacht aufkeimen lassen könnten, dass at und notify nicht gleichberechtigte Partner-Module zu DOIF sein könnten. Damit sind dann auch DOIF, die Befehlsreferenz und dieser Vorschlag harmonisiert.

Hier nun der überarbeitete Vorschlag:

Zeit- und Ereignissteuerung mit DOIF

DOIF (ausgeprochen: du if, übersetzt: tue wenn) ist ein universelles Modul, welches ereignis- und zeitgesteuert in Abhängigkeit definierter Bedingungen Anweisungen ausführt.

In einer Hausautomatisation geht es immer wieder um die Ausführung von Befehlen abhängig von einem Ereignis. Oft reicht aber eine einfache Abfrage der Art: "wenn Ereignis eintritt, dann Befehl ausführen" nicht aus. Ebenso häufig möchte man eine Aktion nicht nur von einem einzelnen Ereignis abhängig ausführen, sondern abhängig von mehreren Bedingungen, z. B. "schalte Außenlicht ein, wenn es dunkel wird, aber nicht vor 18:00 Uhr" oder "schalte die Warmwasserzirkulation ein, wenn die Rücklauftemperatur unter 38 Grad fällt und jemand zuhause ist". In solchen Fällen muss man mehrere Bedingung logisch miteinander verknüpfen. Ebenso muss sowohl auf Ereignisse wie auch auf Zeittrigger gleichermaßen reagiert werden.

An dieser Stelle setzt das Modul DOIF an. Es stellt eine eigene Benutzer-Schnittstelle zur Verfügung ohne Programmierkenntnisse in Perl unmittelbar vorauszusetzen. Mit diesem Modul ist es möglich, sowohl Ereignis- als auch Zeitsteuerung mit Hilfe logischer Abfragen miteinander zu kombinieren. Damit können komplexere Problemstellungen innerhalb eines DOIF-Moduls gelöst werden, ohne Perlcode in Kombination mit anderen Modulen programmieren zu müssen.

Das DOIF-Modul bedient sich selbst des Perlinterpreters, damit sind beliebige logische Abfragen möglich. Logische Abfragen werden in DOIF/DOELSEIF-Bedingungen vornehmlich mit Hilfe von and/or-Operatoren erstellt. Diese werden mit Angaben von Stati, Readings, Internals, Events oder Zeiten kombiniert. Sie werden grundsätzlich in eckigen Klammern angegeben und führen zur Triggerung des Moduls und damit zur Auswertung der dazugehörigen Bedingung. Zusätzlich können in einer Bedingung Perl-Funktionen angegeben werden, die in FHEM definiert sind. Wenn eine Bedingung wahr wird, so werden die dazugehörigen Befehle ausgeführt.

Die vollständige Dokumentation mit zahlreichen Beispielen ist in der deutschsprachigen Befehlsreferenz zum DOIF zu finden.

Zusätzliche, ausführbare Beispiele zum Import in FHEM, gibt es im DOIF Labor

Ereignissteuerung

Hinweis: Verwendung von

[<Gerätename>:"<Ereignis>"] zur Abfrage eines Ereignisses von einem Gerät
DOELSE das Schlüsselwort leitet einen Befehlszweig ohne explizite Bedingung ein. Dieser Zweig wird ausgeführt, wenn keine geprüfte Bedingung wahr ist.
devStateIcon zum direkten Ausführen eines Befehls im DOIF und zur Anzeige von Icons

Aufgabenstellung: Eine Fernbedienung soll einen Fernseher einschalten, der über eine Funkstekdose angeschlossen ist.

Das Gerät Fernbedienung wird durch den Dummy remotecontrol dargestellt. In der Realität könnte es die Definition eines Empfängers für eine Infrarot-Fernbedienung sein.

Das Gerät Funksteckdose TV wird durch den Dummy tv dargestellt. In der Realität könnte es die Definition einer Intertechno-Funkstekdose aus dem Baumarkt sein.

Die Signale von remotecontrol werden über das DOIF di_rc_tv alias Steuerlogik in einen Befehl für die Funksteckdose tv umgesetzt.

Das Signal ist als Ereignis im Event-Monitor sichtbar 2017-02-28 09:07:03 dummy tv on

Das DOIF reagiert durch die Angabe von [remotecontrol:"on"] in der Schaltbedingung. Weil on als Wert in dem Ereignis enthalten ist, wird die Bedingung wahr. Das bewirkt das Ausführen des Befehls set tv on. Danach nimmt das DOIF den Status cmd_1 an.

Falls off im Ereignis enthalten ist wird die Bedingung nicht wahr, daher wird der Befehl set tv off des DOELSE-Zweiges des DOIF ausgeführt und DOIF nimmt den Status cmd_2 an.

Definition:

define di_rc_tv DOIF ([remotecontol:"on"]) (set tv on) DOELSE (set tv off)

Über das Attribut devStateIcon können die Befehle des DOIF direkt ausgeführt werden.

attr di_rc_tv devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1

Das erste Tripel cmd_1:general_an:cmd_2 hat die Bedeutung aktueller Status:Icon-Name:Status nach Betätigung des Icons. Also, wenn der Status cmd_2 ist, dann zeige das Icon general_an und wenn das Icon betätigt wird, dann führe den Befehl aus, der zu cmd_1 gehört.

Das zweite Tripel hat die gleiche Funktion, jedoch wird in diesem Fall das Icon general_aus angezeigt, wenn der Status des DOIF cmd_1 ist oder initialized.

Die nachstehende, komplette Definition für die Gruppe A) kann über Raw definition in FHEM importiert werden.

defmod di_rc_tv DOIF ([remotecontrol:"on"]) (set tv on) DOELSE (set tv off)
attr di_rc_tv alias Steuerlogik
attr di_rc_tv devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1
attr di_rc_tv group A) Fernbedienung (Ereignissteuerung)
attr di_rc_tv icon helper_doif
attr di_rc_tv room Schulungsraum

defmod remotecontrol dummy
attr remotecontrol alias Fernbedienung
attr remotecontrol devStateIcon .*:noIcon
attr remotecontrol group A) Fernbedienung (Ereignissteuerung)
attr remotecontrol icon it_remote
attr remotecontrol room Schulungsraum
attr remotecontrol webCmd on:off

defmod tv dummy
attr tv alias Funksteckdose TV
attr tv devStateIcon on:it_television@red off:it_television@blue
attr tv group A) Fernbedienung (Ereignissteuerung)
attr tv icon it_television
attr tv room Schulungsraum
save

Zeitsteuerung

Hinweis: Verwendung von

[<Zeitpunkt>|<Wochentagangabe>] zur Angabe eines Zeitpunktes mit Wochentagbeschränkung (8 ≙ werktags, 7 ≙ Wochenende).
DOELSEIF das Schlüsselwort leitet einen Bedingungszweig ein und muss eine Bedingung enthalten. Dieser Zweig wird ausgeführt, wenn eine Bedingung geprüft wird und sie wahr ist.
devStateIcon zum direkten Ausführen eines Befehls im DOIF und zur Anzeige von Icons

Aufgabenstellung: Ein Radio soll werktags und am Wochenende zu unterschiedlichen Zeiten ein- u. ausgeschaltet werden.

Das Gerät Funksteckdose Radio wird durch den Dummy radio dargestellt. In der Realität könnte es die Definition einer Intertechno-Funkstekdose aus dem Baumarkt sein.

Wenn die Uhrzeit mit einem Schaltzeitpunkt übereinstimmt, wird die Zeitpunktangabe wahr. Wird dann auch die gesamte Bedingung wahr, dann wird der zu diesem Bedingungszweig gehörende Befehl ausgeführt. Das DOIF di_clock_radio alias Zeitschaltuhr setzt dann einen Befehl zum Schalten der Funksteckdose radio ab.

Das Zeitereignis ist im Event-Monitor nicht sichtbar.

Die Zeitpunkte eines Bedingungszweiges sind or(oder) verknüpft. Im ersten Bedingungszweig steht die Einschaltbedingung, im Zweiten (DOELSEIF) die Auschaltbedingung.

Definition:

define di_clock_radio DOIF ([06:30|8] or [08:30|7]) (set radio on) DOELSEIF ([08:00|8] or [09:30|7]) (set radio off)

Über das Attribut devStateIcon können die Befehle des DOIF über das WEB-Frontend unabhängig von den Schaltzeitpunkten ausgeführt werden.

attr ddi_clock_radio devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1

Die nachstehende, komplette Definition für die Gruppe B) kann über Raw definition in FHEM importiert werden.

defmod di_clock_radio DOIF ([06:30|8] or [08:30|7]) (set radio on) DOELSEIF ([08:00|8] or [09:30|7]) (set radio off)
attr di_clock_radio alias Zeitschaltuhr
attr di_clock_radio devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1
attr di_clock_radio group B) Zeitschaltuhr (Zeitsteuerung)
attr di_clock_radio icon helper_doif
attr di_clock_radio room Schulungsraum

defmod radio dummy
attr radio alias Funksteckdose Radio
attr radio devStateIcon on:it_radio@red off:it_radio@blue
attr radio group B) Zeitschaltuhr (Zeitsteuerung)
attr radio icon it_radio
attr radio room Schulungsraum
save

Kombinierte Ereignis- und Zeitsteuerung

Hinweis: Verwendung von

[<Beginzeitpunkt>-<Endzeitpunkt>] zur Angabe einer Zeitspanne.
[<Gerätename>:<Reading-Name>] zur Abfrage eines Reading-Inhaltes.
< , eines numerischen Vergleichsoperators und Vergleich mit einer Konstanten (40).
DOELSE das Schlüsselwort leitet einen Befehlszweig ohne explizite Bedingung ein. Dieser Zweig wird ausgeführt, wenn keine geprüfte Bedingung wahr ist.
devStateIcon zum direkten Ausführen eines Befehls im DOIF und zur Anzeige von Icons
readingList, setList und webCmd zur Erzeugung eines Eingabeelementes im Frontend
stateFormat um einen benutzerdefinierten Status zu erzeugen.

Aufgabenstellung: Eine Lampe soll in einer Zeispanne eingeschaltet werden, wenn die Helligkeit einen bestimmten Wert unterschreitet.

Das Gerät Lampe wird durch den Dummy lamp dargestellt. In der Realität könnte es die Definition einer funkgesteuerten Lampenfassung sein.

Das Gerät Helligkeitssensor wird durch den Dummy sensor dargestellt. In der Realität könnte es die Definition eines Homematic Funk-Lichtsensor sein oder ein selbstgebauter Helligkeitssensor mit TSL2561-Chip.

Wenn die aktuelle Uhrzeit in der angegebenen Zeitspanne liegt, ist die Zeitspanne wahr. Wenn dann auch die Helligkeit unter 40 sinkt, wird die gesamte Bedingung wahr, weil Zeitspanne und Hellikeitsvergleich and(und) verknupft sind. Der zu diesem Bedingungszweig gehörende Befehl wird dann ausgeführt. Das DOIF di_lamp alias Lampenlogik setzt dann einen Befehl zum Schalten der Lampe lamp ab. Der DOELSE-Zweig wird ausgeführt, wenn die Bedingung im ersten Zweig unwahr wird.

Definition:

define di_lamp DOIF ([06:00-19:00] and [sensor:brightness] < 40) (set lamp on) DOELSE (set lamp off)

Über das Attribut devStateIcon können die Befehle des DOIF über das WEB-Frontend unabhängig von den Schaltzeitpunkten ausgeführt werden.

attr di_lamp devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1

Das Attribut setList zusammen mit readingList und webCmd realisiert im Gerät sensor für das Reading brightness einen Schieberegler, mit dem eine Helligkeit zwischen 0 und 100 in in Schritten von 1 simuliert werden kann und der im Frontend angezeigt wird.

attr sensor readingList brightness
attr sensor setList brightness:slider,0,1,100
attr sensor webCmd brightness

Mit dem Attribut stateFormat wird im Gerät sensor das Reading brightness in den Status geschrieben. Damit wird der Helligkeitswert auch im Frontend sichtbar.

attr sensor stateFormat brightness

Die nachstehende, komplette Definition für die Gruppe C) kann über Raw definition in FHEM importiert werden.

defmod di_lamp DOIF ([06:00-19:00] and [sensor:brightness] < 40) (set lamp on) DOELSE (set lamp off)
attr di_lamp alias Lampenlogik
attr di_lamp devStateIcon cmd_1:general_an:cmd_2 cmd_2|initialized:general_aus:cmd_1
attr di_lamp group C) Kombinierte Ereignis- und Zeitsteuerung
attr di_lamp icon helper_doif
attr di_lamp room Schulungsraum

defmod lamp dummy
attr lamp alias Lampe
attr lamp group C) Kombinierte Ereignis- und Zeitsteuerung
attr lamp icon light_light
attr lamp room Schulungsraum

defmod sensor dummy
attr sensor alias Helligkeitssensor
attr sensor group C) Kombinierte Ereignis- und Zeitsteuerung
attr sensor icon message_light_intensity
attr sensor readingList brightness
attr sensor room Schulungsraum
attr sensor setList brightness:slider,0,1,100
attr sensor stateFormat brightness
attr sensor webCmd brightness
save

Ansicht der Gruppen A) bis C) im Frontend

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

DOIF: Ereignis-und Zeitsteuerung

LG --Trelle (Diskussion) 19:16, 1. Mär. 2017 (CET)

Hi Trelle,

die langen Antwortzeiten liegen im Wesentlichen daran, dass ich keine Mailbenachrichtigung kriege, wenn hier was geschrieben wird. (vielen Dank an Christian für den Hinweis)

Mach doch aus der DOIF-Ausarbeitung eine separate Wiki-Seite. Am Ende der Erste-Schritte-Abschnitte zu notify und at können wir dann nen Hinweis einfügen à la: "Hinweis: Als Alternative zu den Befehlen <at|notify> gibt es auch das Modul DOIF, mit dem vor allem komplexere Bedingungen einfacher abzubilden sind."

Gruß und schönen Tag, Uli

--Uli (Diskussion) 09:12, 19. Feb. 2017 (CET)

Hallo Uli,

Es geht nicht darum, dass im Wiki etwas über DOIF geschrieben wird, da gibt es schon eine Menge.

Es geht darum, Einsteigern beim Erstkontakt über die "Ersten Schritte ..." eine ernstzunehmende Möglichkeit der Zeit- und Eventverarbeitung nicht vorzuenthalten, sondern Sie auf Augenhöhe anzubieten.

Das Verschweigen dieser Möglichkeit lässt Einsteiger nicht Ihren besten Weg finden und kommt einer Bevormundung gleich.

Die Disskussion um at, notify und DOIF lässt 3 Gruppierungen erkennen at/notify bzw. DOIF Puristen und die Mischer. Es gibt keinen Grund anzunehmen, dass diese Vorlieben nicht auch bei Einsteigern angelegt sind.

Gerade als Marketing Verantwortlicher des Vereins solltest Du ein Interesse haben, allen Gruppen einen leichten Einstieg zu ermöglichen, auch mit Blick auf die sich ankündigende Verbreitungsoffensive (FHEM-Livesystem und Showcases, usw.)

Du kennst DOIF, nicht hast Du erwähnt, dass sollte Dich nicht abhalten es dennoch ernstzunehmen und von eigenen Vorlieben unabhängig zu betrachten, um den Mehrwert für FHEM erkennen zu können.

Zur Verkürzung der Antwortzeiten könnten wir die Disskussion auch ins Forum verlagern. Was hältst Du davon?

LG --Trelle (Diskussion) 12:27, 4. Mär. 2017 (CET)

Hallo Trelle,

offengestanden hab ich gar keine Lust auf diese Diskussion.

Offenbar haben wir hier unterschiedliche Ansichten. Ich respektiere Deine, respektiere Du bitte meine.

Einen Link auf eine DOIF-Seite können wir wie oben vorgeschlagen gerne einbauen, mehr Veränderung möchte ich an diesem Artikel nicht vornehmen.

Gruß, Uli

PS: Mit meiner Rolle im Verein hat das nix zu tun, es geht ja nicht um ein Vereinsthema.

--Uli (Diskussion) 09:12, 19. Feb. 2017 (CET)

Hallo Uli,

nachstehend 2 Vorschläge, wie ich einen Verweis auf die Zeit- und Eventsteuerung mit DOIF einbauen möchte.

Welchen Vorschlag bevorzugst Du?

LG --Trelle (Diskussion) 18:55, 16. Mär. 2017 (CET)

Vorschlag 1

... Da das ja doch recht sperrig ist, gibt es noch eine etwas einfachere Alternative:

define n_th_Schalter_on notify th_Schalter:on set th_Licht on;;sleep 60;;set th_Licht off

Manche Hardwaresysteme bieten auch den Befehl on-for-timer, mit dem man alternativ schreiben kann

define n_th_Schalter_on notify th_Schalter:on set th_Licht on-for-timer 60

Zeit- und Ereignissteuerung mit DOIF

Seit erscheinen des ursprünglichen Artikels Anfang 2014, ist eine neue Möglichkeit der Zeit- und Ereignissteuerung eingeführt worden.

Siehe: Erste Schritte mit DOIF: Zeit- und Ereignissteuerung

Der Autor des usprünglichen Artikel hat freundlicherweise zugestimmt den Artikel mit einem Link zu ergänzen.

Wie geht es weiter?

...

Vorschlag 2

Timer bei einem Event starten - notify und at

Zeit- und Ereignissteuerung mit DOIF

Seit erscheinen des ursprünglichen Artikels Anfang 2014, ist eine neue Möglichkeit der Zeit- und Ereignissteuerung eingeführt worden.

Siehe: Erste Schritte mit DOIF: Zeit- und Ereignissteuerung

Der Autor des usprünglichen Artikels hat freundlicherweise zugestimmt den Artikel mit einem Link zu ergänzen.

Als letzte Übung wollen wir ein notify und ein at verbinden. Der Timer soll nun nicht starten, wenn Sie den Befehl in das Kommandofeld eingeben, sondern wenn ein Event eintritt.

Dazu basteln wir uns ein Treppenhaus: Legen Sie dafür die Dummy-Devices th_Schalter und th_Licht im Raum Treppenhaus an. Zum Anlegen des Raums Treppenhaus ordnen Sie dem ersten Device den Raum über das Kommandofeld zu, alle weiteren Attribute dann durch Klicken im Detail-Bildschirm:

define th_Schalter dummy
attr   th_Schalter room Treppenhaus
attr   th_Schalter webCmd on
define th_Licht dummy
attr   th_Licht room Treppenhaus

...

Für mich sind beide Varianten ok. Wobei ich nicht sicher bin, ob eine Platzierung unter "Wie geht es weiter?" der Universalität von DOIF nicht gerechter würde. Unter "Timer bei einem Event starten..." wird die Bedeutung mMn ein wenig reduziert. Gruß, --Christian (Diskussion) 12:04, 29. Mär. 2017 (CEST)

Änderungen am Artikel "Erste Schritte in FHEM"

Betrifft folgende Änderungen des Users Andies: https://wiki.fhem.de/w/index.php?title=Erste_Schritte_in_FHEM&type=revision&diff=21496&oldid=21488

Diskussion wurde nachträglich zur besseren Nachvollziehbarkeit von Benutzer_Diskussion:Andies hierin verlagert. --Christian (Diskussion) 10:41, 12. Mai 2017 (CEST)

Hallo!

Zunächst danke für Deine Mitarbeit am Wiki und bei FHEM. Aber -wie so oft im Leben- gibt es nur Rückmeldungen bei "Problemen" ;-) :

Hast Du Deine Änderungen am Artikel Erste Schritte in FHEM, so wie im Vorwort zum Artikel erbeten, mit dem Verfasser Uli abgestimmt?

Die Änderungen widersprechen deutlich der Intention und dem Konzept des Artikels. Der Artikel soll nur einen kurzen Einstieg in FHEM geben; quasi einen "Vorgeschmack" auf FHEM liefern und nicht das Einsteiger-Pdf ersetzen.

Gruß, --Christian (Diskussion) 13:51, 9. Mai 2017 (CEST)

Ja, habe ich abgestimmt. Ich hatte ihm vor einer Woche eine Mail geschrieben und er hat daraufhin OK gesagt, aber darum gebeten, es möglichst kurz zu halten. Kurze Nachfrage: Was genau ist der deutliche Widerspruch zur Intention?

--Benutzer:andies 14:09, 9. Mai 2017

Hallo andies!

Erste_Schritte_in_FHEM#Grundbegriffe:_Device_und_Internal.2C_Attribut.2C_Reading geht meiner Meinung nach viel zu sehr in die Tiefe und ist gerade für einen groben Überblick nicht notwendig. Finde das persönlich eher verwirrend als hilfreich. Was interessiert mich bspw. beim ersten Kontakt mit FHEM, warum 98 vor einem Modul steht? Wofür muss man das für den schnellen Überblick wissen? Variablen, Zeichenketten, STATE, Readings, Internal, Attribut im "Vorwort" als Grundbegriffe schrecken mich ab. Das kommt doch im Artikelverlauf von selbst und muss man nicht schon im Vorhinein lesen. Der "device"-Erläuterung kann ich hingegen eine gewisse Notwendigkeit abgewinnen.

Inhaltlich bin ich nicht im Detail eingestiegen, aber "Readings sollen während der Laufzeit vom Anwender" halte ich als Aussage für sehr gefährlich.

Erlaube mir mal eine Gegenfrage: Hast Du beim Einstieg das Einsteiger-Pdf gelesen? Oder wie bist Du vorgegangen?

Wenn Du die Änderungen mit Uli abgestimmt hast, ist das Ok und ich bin ruhig :-).

Gruß, --Christian (Diskussion) 15:28, 9. Mai 2017 (CEST)

Danke für die konstruktive Antwort; dann lass uns diskutieren! Ich erzähle mal, wieso ich das geschrieben habe und dann schauen wir, was wir am Ende daraus machen. Das wird jetzt aber ein längerer Text (Wir können das auch im Forum diskutieren, wäre das besser? Wenn ja, dann nimm einfach den Link, den ich da angegeben habe: https://forum.fhem.de/index.php/topic,71397.0.html). Ich habe mit FHEM angefangen, weil ich ein ganz konkretes Problem hatte, dass ich mit anderen Servern nicht habe lösen können (Garage übers Internet schalten, Rolladen auch) und ich glaube, dass das typisch ist - jedenfalls war das der Eindruck, den ich von einem Treffen in Berlin hatte. Dann habe ich die Einsteiger-PDF gelesen und hatte "irgendwie" Ahnung, wie das geht. Dann habe ich meine Rolladen in Griff gehabt und eigentlich wäre dann alles gut gewesen. Wäre ich da stehen geblieben, hätte ich den Wiki-Eintrag nicht verändert.

Der nächste Schritt war dann, dass ich (wie wahrscheinlich einige hier) Blut geleckt hatte. Nun sollte also auch noch der Stromverbrauch erfasst werden etc. Und auf einmal fingen die Probleme an. Ich habe zum Beispiel aus dem Wiki-Eintrag nicht verstanden, was überhaupt ein Attribut ist. Ständig wollte ich mit ReadingsVal die Werte der Attribute auslesen und bekam auch mal den Anpfiff: "Lies mal die commandref". Wenn man aber noch nie mit Perl programmiert hat, kapiert man das auch nach dem zehnten Lesen nicht. Hinzu kommt, dass einige Dinge so erklärt sind, dass für einen Anfänger ein Verständnis nahezu unmöglich wird; einige Wiki-Einträge sind ja wirklich verwaist. Also habe ich überlegt: Warum kapiere ich das nicht? Dann wurde mir klar, weil zum einen recht viele kleine Schusselfehler in der Einleitung stehen (zum Beispiel "Reading 'STATE'", wo es doch ein Internal ist oder man das Reading 'state' meint etc pp - so etwas verwirrt einen Anfänger total!) und zum anderen weil mehrere Grundbegriffe nicht vernünftig erklärt sind (zum Beispiel: "Nur Readings können von Menschen gelesen werden" - Internals auch!). Hinzu kommt, dass in der Einleitung zwar steht, was man genau tun soll ("tipp mal attr XY room sowieso" ein und dann siehst du was), aber nicht erklärt wird, was man da eigentlich macht - nämlich ein Attribut setzen und einen Wert zuweisen. Deshalb habe ich mich dran gesetzt und überlegt, was für mich wichtig gewesen wäre.

Nun zur Debatte. Was für mich wichtig ist, kann für andere verwirrend sein. Sehe ich sofort ein. Also lass uns im Detail diskutieren, was am Text verändert wird (nochmal: eventuell im Forum?). Das mit der Zeichenkette verstehe ich, das mit den Definitionen der Grundbegriffe finde ich aber wesentlich. Wir sollten vielleicht so debattieren: Was wollen wir beim Anfänger erreichen? Welches Vorwissen müssen wir voraussetzen, was nicht? Ich gehe davon aus, dass der typische Anwender mit einem ganz konkreten Problem zu FHEM stößt und zuerst das gelöst haben will. Dass er wenige Programmierkenntnisse besitzt und auch bereit ist, gewisses Leid in Kauf zu nehmen. Wir können aber nicht voraussetzen (auch wenn das der eine oder andere meint), dass er die gesamte Einsteiger-PDF verstanden, die commandref gelesen und verstanden hat und außerdem mit RegEx problemlos umgehen kann. Wenn wir uns bei der Beschreibung der Person, die den Wiki-Eintrag liest, einig sind, sollte sich ein besserer Text ergeben. Das man dabei sinnvollerweise vermeidet, bereits in der Einleitung eine Debatte zum Sinn und Unsinn von DOIF zu haben, ist auch mir Anfänger klar.

Zum Diskussionsort: Mir ist es letztlich gleich. Hier wird es vmtl. nur ruhiger und mit weniger Beteiligung als im Forum zu gehen.

Also bist Du zum Einstieg mit dem Artikel "Erste Schritte in FHEM" problemlos klargekommen; erst als es weiter in die Tiefe ging, kamen die weiteren Probleme!? Daraus schließe ich zunächst einmal frech, dass der Artikel seinen Zweck erfüllt hat: Ein "Appetitanreger" auf FHEM, der erste Erfolgserlebnisse und erstes Verständniss schafft. Mehr soll er meiner Meinung nach auch nicht. Der Einsteiger soll sich in kurzer Zeit einen Überblick verschaffen (Zeitbedarf max. 60 Minuten): Ist FHEM etwas für mich? Wie geht das grundlegend? Wenn man neugierig geworden ist, dann weiterlernen.

Tippfehler und Co. (state vs. STATE) sollten im Artikel natürlich behoben werden. Mit Deinen weiterführenden Erläuterungen insb. Grundbegriffe, die Du nach den ersten Erfolgserlebnissen vermisst hast, steigt der Zeitbedarf für die Durcharbeitung und auch die Komplexität des Artikels deutlich. Er verliert damit eben seine eigentliche Intention. Das, was unter Grundbegriffe steht braucht man zum Einstieg nicht und verwirrt. Er entwickelt sich mMn dadurch in Richtung universellen Einsteiger-PDF Ersatz. Weitergehende Informationen könnte man aus dem Artikel ja verlinken statt sie darin aufzunehmen; aber selbst dabei bin ich zweifelnd, da es schnell zum Verzetteln in Details führt.

Auch Deine Definition der Grundbegriffe ist, wie Du im Forum liest, nicht unumstritten. Und die Bedenken kommen nicht von irgendjemanden, sondern von einem der Kern-Developer. Einen Punkt hatte ich gestern auch schon herausgepickt (Readings), den ich persönlich für gefährlich oder eher sogar falsch halte. Zudem existieren schon Definitionen der Begriffe im Wiki, die man verlinken könnte. Warum sollten wir 2 Definitionen im Wiki pflegen? Das ist zu pflegeaufwendig. Das ist aber auch eine Macke von mir: [1] würde ich z.B. nicht so ausführlich machen, sondern auf Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden verlinken. Dadurch sind Fehler/Änderungen nur an einer Stelle zu berücksichtigen.

Wo steht eigentlich: "Nur Readings können von Menschen gelesen werden" ?

Was für Dich wichtig ist, liegt doch an Deinem Wissensstand. Zunächst hat der Einsteiger-Artikel gereicht. Dann ist man weiter und liest das Pdf. Und dann kommen Fragen und noch mehr Fragen. Damit bin ich wieder beim Ausgangspunkt, dass Deine Erläuterungen schon für Fortgeschrittenere sind und nicht in den genannten Artikel sollten ;-).

Was ich voraussetze? Nichts außer Lernbereitschaft. Dazu gehört auch, dass man sich zumindest mal Grundzüge von Perl anschaut. (Bin selbst kein Entwickler und werde keiner, sondern nur Anwender) Ohne Regex und Co. ist FHEM schwer "verdaulich". Das z.B. tritt mir mittlerweile zu sehr in den Hintergrund.

Mir persönlich wäre es am Liebsten den Einsteiger-Artikel in die Kurzform zurückzubringen und Deine Überlegungen möglichst redudanzfrei in weiterführende Artikel zu packen oder in Ulis Einsteiger-Pdf einzubringen, falls er Hilfe mag. Was ich nicht möchte ist: Dich entmutigen und von der Mitarbeit abbringen, das wird nämmlich schnell so aufgefasst. Und meine Meinung muss auch nicht die Richtige sein, wenn es die überhaut gibt.

Gruß, --Christian (Diskussion) 11:14, 10. Mai 2017 (CEST)

PS: (Langfristiges) Ziel ist bspw. FHEM_Installation_Windows und Erste Schritte in FHEM so zu gestalten, dass als Einsteiger ein Test von FHEM angefangen bei Installation bis zum Ende der ersten Experimente in ca. 90 Minuten möglich ist.

Was ist davon zu halten, wenn wir den Grundbegriffe-Artikel zu einem Absatz mit ein, zwei Sätzen zusammenkürzen und den Inhalt auf weiterführende Seiten verschieben? Das wäre dann, in schlechtem Deutsch von der Idee her so: "Also wir legen jetzt mal los und wir brauchen dazu Attribute und Readings (was das ist, kannst du HIER nachlesen), aber erst einmal reicht <XYZ>"? Das können wir bei den anderen Abschnitten, bei denen Du Probleme hast, auch machen. Ich würde mir dann mal was überlegen und das hier vorstellen? Es wäre aber wegen der reparierten Schreibfehler vermutlich einfacher, wenn wir diesen Abschnitt _bearbeiten_ und _nicht_ zurückstellen, denn ich weiß nicht mehr, welche Fehler ich genau geändert habe.

Ich mache nichts einfach rückgängig, wir diskutieren doch: Ändere es einfach einmal so ab, wie Du es dann machen würdest. Im Übrigen bin ich nicht der Nabel der Welt, aber habe ein Meinung :-) . Am meisten stören mich die "Grundbegriffe". --Christian (Diskussion) 16:08, 10. Mai 2017 (CEST)

PS Aus dem Wiki: "Daten, welche von einem Gerät gelesen werden und in FHEM in einer für Menschen verständlichen Form zur Verfügung gestellt werden können, werden Readings genannt". Der Logiker schließt daraus, dass Internals für Menschen nicht verständlich sind (jedenfalls habe ich mich das wirklich gefragt: gilt etwa Readings = UTF-8, Internals = binär o.Ä?!)

Halte ich für eine erhebliche Überinterpretation der Aussage. Es wird doch nirgends eine Verbindung oder gar Vergleich zwischen Internals und Readings hergestellt und schon gar nicht, in welcher ihrer Merkmale/Eigenschaften aus Anwendersicht ein Gegensatz besteht. Eine klare und eindeutige Definition der Begriffe ist nicht so einfach und letztlich auch im Fluß. Zudem versuchst Du Begrifflichkeiten, die mMn eher aus Entwicklersicht entstanden sind, in ein Schema der Anwendersicht zu pressen. Ein bedeutendes Gegenbeispiel Deiner Definition finde ich beispielsweise auf die Schnelle noch bei Internals. Du schreibst: "Internals sollen vom Nutzer nicht direkt verändert werden". Das ist so vereinfacht in einem wesentlichen Punkt falsch. Das DEF in den Internals soll gerade von Einsteigern genutzt werden und nicht die manuelle Editierei in der fhem.cfg (siehe bspw. Konfiguration#Objektdetails). Die Nutzung des DEF wollen wir gerade den Einsteigern krampfhaft vermitteln; jetzt verbieten wir es aber bereits in der Definition im "Vorwort" des Einsteiger-Artikels. Das verwirrt sicherlich. Wenn Du das dann gerade ziehen willst, musst Du noch mehr erklären. Das führt zu mehr Verwirrung. Darum eben besser Definitionen weglassen. --Christian (Diskussion) 16:08, 10. Mai 2017 (CEST)

Ich habe jetzt erst einmal Änderungen vorgenommen, wie sie hier oben besprochen wurden. Genauer habe ich folgendes gemacht: Ich habe den separaten Abschnitt "Grundbegriffe" entfernt und Teile davon, die nicht technisch sind, in den fortlaufenden Text integriert. Das mit den Zeichenketten habe ich weggelassen. Ansonsten habe ich bei den ersten beiden Befehlen in FHEM etwas mehr Wert darauf gelegt, was man genau da eigentlich eingibt und welche Teile dieser Befehlszeile Syntax sind und wo man (mehr oder weniger) schreiben kann, was man will. --Andreas (Diskussion) 18:51, 20. Mai 2017 (CEST)

@@ Zeile 480: / Zeile 480: @@
 <HR>
 :::::Halte ich für eine erhebliche Überinterpretation der Aussage. Es wird doch nirgends eine Verbindung oder gar Vergleich zwischen Internals und Readings hergestellt und schon gar nicht, in welcher ihrer Merkmale/Eigenschaften aus Anwendersicht ein Gegensatz besteht. Eine klare und eindeutige Definition der Begriffe ist nicht so einfach und letztlich auch im Fluß. Zudem versuchst Du Begrifflichkeiten, die mMn eher aus Entwicklersicht entstanden sind, in ein Schema der Anwendersicht zu pressen. Ein bedeutendes Gegenbeispiel Deiner Definition finde ich beispielsweise auf die Schnelle noch bei Internals. Du schreibst: "Internals sollen vom Nutzer nicht direkt verändert werden". Das ist so vereinfacht in einem wesentlichen Punkt falsch. Das DEF in den Internals soll gerade von Einsteigern genutzt werden und nicht die manuelle Editierei in der fhem.cfg (siehe bspw. [[Konfiguration#Objektdetails]]). Die Nutzung des DEF wollen wir gerade den Einsteigern krampfhaft vermitteln; jetzt verbieten wir es aber bereits in der Definition im "Vorwort" des Einsteiger-Artikels. Das verwirrt sicherlich. Wenn Du das dann gerade ziehen willst, musst Du noch mehr erklären. Das führt zu mehr Verwirrung. Darum eben besser Definitionen weglassen. --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 16:08, 10. Mai 2017 (CEST)
+<HR>
+::::::Ich habe jetzt erst einmal Änderungen vorgenommen, wie sie hier oben besprochen wurden. Genauer habe ich folgendes gemacht: Ich habe den separaten Abschnitt "Grundbegriffe" entfernt und Teile davon, die nicht technisch sind, in den fortlaufenden Text integriert. Das mit den Zeichenketten habe ich weggelassen.  Ansonsten habe ich bei den ersten beiden Befehlen in FHEM etwas mehr Wert darauf gelegt, was man genau da eigentlich eingibt und welche Teile dieser Befehlszeile Syntax sind und wo man (mehr oder weniger) schreiben kann, was man will.  --[[Benutzer:andies|Andreas]] ([[Benutzer Diskussion:andies|Diskussion]]) 18:51, 20. Mai 2017 (CEST)