docu: fix typos in referenz (all files in subfolders)

doc/user/source/referenz/items/attributes_relative_referenzen.rst

@@ -137,7 +137,7 @@ Die Methode `expand_relativepathes()` hat die folgenden drei Parameter:
 +----------------+-------------------------------------------------------------------+
 | **Parameter**  | **Bedeutung**                                                     |
 +================+===================================================================+
-| attribute_name | Name des Attibutes, in dem die Referenzen aufgelöst werden sollen |
+| attribute_name | Name des Attributs, in dem die Referenzen aufgelöst werden sollen |
 +----------------+-------------------------------------------------------------------+
 | begin_tag      | Zeichen(kette), die den Beginn einer Item-Referenz kennzeichnet   |
 +----------------+-------------------------------------------------------------------+
@@ -196,4 +196,3 @@ Das **visu_smart_visu** Plugin unterstützt relative Item-Pfade in 4 Attributen.
         item.expand_relativepathes('sv_widget2', "'", "'")
         item.expand_relativepathes('sv_nav_aside', "'", "'")
         item.expand_relativepathes('sv_nav_aside2', "'", "'")
-

doc/user/source/referenz/items/item_zugriff.rst

@@ -159,7 +159,7 @@ Weitere Parameter Item Zugriff
 
 Außer den oben beschriebenen Parametern (``value``, ``index`` und ``key``), gibt es noch weitere Parameter.
 
-Der ineressanteste unter ihnen ist der Parameter ``caller``. Mit ihm wird beeinflusst, was bei einer Zuweisung zu
+Der interessanteste unter ihnen ist der Parameter ``caller``. Mit ihm wird beeinflusst, was bei einer Zuweisung zu
 einem Item als **Update durch** und **Änderung durch** zum Beispiel in der Admin GUI zu einem Item angezeigt wird.
 
 .. code-block:: python
@@ -212,11 +212,11 @@ normalen Zugriff auf Items - entsprechend gesetzt werden können.
     bzw. `dict`-Klassen identisch; das genaue Verhalten kann bei Bedarf in der
     Python-Dokumentation nachgelesen werden.
 
-    Ausnahmen sind die Methode `prepend` (existiert so in Python nicht) und 
+    Ausnahmen sind die Methode `prepend` (existiert so in Python nicht) und
     `delete`, welche das Verhalten von `del` nachbildet, aus Syntaxgründen aber
     anders benannt werden musste.
 
-    Analog zu den Python-Funktionen ist keine zusätzliche Fehlerbehandlung 
+    Analog zu den Python-Funktionen ist keine zusätzliche Fehlerbehandlung
     implementiert, so dass ungültige Indizes oder Keys nicht abgefangen werden.
     Die Behandlung dieser Fehler obliegt - wie beim normalen Umgang mit Listen
     und Dicts - dem Nutzer.
@@ -293,7 +293,7 @@ im dict nicht existiert, wird `None` oder der übergebene Default-Wert zurückge
 
     value2 = sh.Oma.Papa.Kind.dict.get('bar', 42)
 
-Die Methode `delete` entspricht dem Python-Befehl `del dict[key]` und lösche den 
+Die Methode `delete` entspricht dem Python-Befehl `del dict[key]` und lösche den
 angegebenen Key aus dem dict:
 
 ..code-block:: python

doc/user/source/referenz/items/methoden.rst

@@ -18,7 +18,7 @@ Die Nutzung des ``sh`` Objektes für Items wird nicht weitergeführt. Es ist bes
 .. note::
 
    Bei Ausführung einer Logik ist das ``items`` Objekt bereits initialisiert und kann ohne die oben beschriebene
-   Initialisierung dirket genutzt werden.
+   Initialisierung direkt genutzt werden.
 
 
 Mit dem ``items`` Objekt können nun die folgenden Funktionen verwendet werden:

doc/user/source/referenz/items/plugin_attribute.rst

@@ -55,7 +55,7 @@ plugin-spezifischen Attributen. Hierbei kann ein Attribut mit dem Wert eines Att
 übergeordneten Items belegt werden.
 
 Es kann der Wert eines Attributes aus einer übergeordneten Ebene (Eltern / Großeltern / Urgroßeltern)
-überommen (geerbt) werden. Dazu wird für das erbende Attribut ein Wert im Format :code:`<Ebene>:<Attribut>`
+übernommen (geerbt) werden. Dazu wird für das erbende Attribut ein Wert im Format :code:`<Ebene>:<Attribut>`
 angegeben.
 
 .. attention::
@@ -110,7 +110,7 @@ Zugriff auf Attribute anderer Items :bluesup:`update`
 
 Der Zugriff auf Attribute anderer Items ist als Erweiterung der Vererbung von Attributen implementiert.
 Hierzu muss im aktuellen Item ein Attribut definiert werden, welches den Wert aufnimmt. Es ist hierbei
-(wie bei der Vererbung) ist nur ein Zugriff auf Items oberhalb in der Item Hirarchie möglich.
+(wie bei der Vererbung) ist nur ein Zugriff auf Items oberhalb in der Item Hierarchie möglich.
 
 Der Unterschied liegt darin, dass ein Attributname angegeben werden kann.
 
@@ -141,7 +141,7 @@ findet standardmäßig keine Prüfung auf (und die Ersetzung von) Platzhalter(n)
 aktivieren, muss an den Namen des Attributes ein Unterstrich angefügt werden. Es muss also z.B. statt in
 der Konfigurationsdatei :code:`my_attribute: "Text"` zu schreiben, :code:`my_attribute_: "Text {..:my_value}"`
 angegeben werden. Im Zuge des Ladens wird beim Ersetzen der Platzhalter der Unterstrich entfernt. Das Attribut
-hal zur Laufzeit also den Namen **my_attribute** und nicht (wie man denken könnte) **my_attribute_**.
+hat zur Laufzeit also den Namen **my_attribute** und nicht (wie man denken könnte) **my_attribute_**.
 
 Platzhalter können (wie die Vererbung und die Nutzung anderer Attributwerte) **nur** bei
 plugin-spezifischen Attributen verwendet werden. Die einzige Ausnahme ist das Standard-Attribut **name**. Hier können
@@ -264,4 +264,3 @@ ergibt dann zur Laufzeit:
                 knx_send_: "3/4/7"
 
 |
-

doc/user/source/referenz/items/properties.rst

@@ -39,7 +39,7 @@ Werte für Properties, die auch geschrieben werden können (z.B. in Logiken), we
 +----------------------+------------+----------+------------------------------------------------------------------------------+
 | **Property**         | **Access** | **Type** | **Beschreibung**                                                             |
 +======================+============+==========+==============================================================================+
-| attributes           | r/o        | list     | Liefert die Namen der plugin-spezfischen Attribute als Liste                 |
+| attributes           | r/o        | list     | Liefert die Namen der plugin-spezifischen Attribute als Liste                 |
 |                      |            |          | Auf die Werte dieser Attribute kann über dynamische Properties zugegriffen   |
 |                      |            |          | werde. (Siehe Ende dieser Tabelle)                                           |
 +----------------------+------------+----------+------------------------------------------------------------------------------+

doc/user/source/referenz/items/standard_attribute/eval.rst

@@ -31,8 +31,8 @@ Das Item soll aber die Temperatur in °Celsius speichern.
        eval: (value - 32 ) * 5 / 9  # Aus 68°F werden somit 20°C
 
 Die Auswertung des **eval** Ausdrucks wird gestartet, wenn:
- - dem Item ein neuer Wert zugewiesen wird (siehe Erläuterug im ersten Absatz)
- - sich der Wert des oder der Items aus dem **eval_trigger** ändert (siehe Erläuterug weiter unten)
+ - dem Item ein neuer Wert zugewiesen wird (siehe Erläuterung im ersten Absatz)
+ - sich der Wert des oder der Items aus dem **eval_trigger** ändert (siehe Erläuterung weiter unten)
  - ein **timer** verwendet wird und die angegebene Zeit abgelaufen ist
  - ein **autotimer** verwendet wird und die angegebene Zeit abgelaufen ist
  - ein **crontab** definiert ist und die zeitlichen Angaben zutreffen

doc/user/source/referenz/items/standard_attribute/hysteresis.rst

@@ -61,7 +61,7 @@ Das Attribut **hysteresis_upper_threshold** definiert den oberen Schwellwert fü
 **Überschreitung** dieses Wertes im Item welches den zu überwachenden Eingabewert darstellt, wird dieses Item auf
 **True** gesetzt.
 
-Optional kann in diesem Attribut eine Dauer angegeben werden, welche die Überscheitung andauern muss, damit der Wert
+Optional kann in diesem Attribut eine Dauer angegeben werden, welche die Überschreitung andauern muss, damit der Wert
 des Items auf **True** gesetzt wird.
 
 Das Item, welches dieses Hysterese Attribut verwendet, muss als **bool** definiert sein.
@@ -81,7 +81,7 @@ Das Attribut **hysteresis_lower_threshold** definiert den unteren Schwellwert f
 **Unterschreitung** dieses Wertes im Item welches den zu überwachenden Eingabewert darstellt, wird dieses Item auf
 **False** gesetzt.
 
-Optional kann in diesem Attribut eine Dauer angegeben werden, welche die Unterscheitung andauern muss, damit der Wert
+Optional kann in diesem Attribut eine Dauer angegeben werden, welche die Unterschreitung andauern muss, damit der Wert
 des Items auf **False** gesetzt wird.
 
 Das Item, welches dieses Hysterese Attribut verwendet, muss als **bool** definiert sein.
@@ -186,4 +186,3 @@ zurück gegeben, der die folgenden Werte haben kann:
   "Stay (Off)",      "Der Wert des **hysteresis_input** Items liegt zwischen unterem und oberen Schwellwert und lag vorher unterhalb des unteren Schwellwertes"
   "Timer -> Off",    "Der Wert des **hysteresis_input** Items liegt zwar unterhalb des unteren Schwellwertes, aber der Timer für die Mindestdauer ist noch nicht abgelaufen"
   "Off",             "Der Wert des **hysteresis_input** Items liegt unterhalb des unteren Schwellwertes"
-

doc/user/source/referenz/items/standard_attribute/log_change.rst

@@ -109,7 +109,7 @@ Unterstützt werden folgende Variablen/Platzhalter:
 eval-Ausdrücke in log_text
 --------------------------
 
-Zusätzlich zu den Variaben, können in den Log Text auch eval Ausdrücke eingeschlossen werden. Der Syntax dazu ist
+Zusätzlich zu den Variablen, können in den Log Text auch eval Ausdrücke eingeschlossen werden. Der Syntax dazu ist
 folgender: ``{eval(<Ausdruck>)}``. Dabei muss sicher gestellt sein, dass der Ausdruck ein String ist. Wenn man
 zum Beispiel nur Zahlen addiert ``3+5``, muss dieser Ausdruck in **doppelte** Anführungszeichen (``"``) gesetzt werden:
 ``{eval("3+5")}``.
@@ -219,4 +219,3 @@ itemvalue
 
 ``itemvalue`` Der absolute oder relative Pfad zu einem Item, dessen Wert ausgelesen werden soll.
 Dies kann beispielsweise dazu genutzt werden, die Lognachricht zur Laufzeit anzupassen.
-

doc/user/source/referenz/items/standard_attribute/standard_attribute.rst

@@ -52,7 +52,7 @@ plugin-spezifischen Attribute ist in der Dokumentation des jeweiligen Plugins na
 |                            | Logik oder Eval-Funktion). Ab SmartHomeNG v1.3 wurden die                              |
 |                            | Konfigurationsmöglichkeiten erweitert  (siehe :doc:`cycle <./cycle>`).                 |
 +----------------------------+----------------------------------------------------------------------------------------+
-| description                | Eine optionale Beschreibung für das Item. Hier können zum Besipiel Bedeutungen der     |
+| description                | Eine optionale Beschreibung für das Item. Hier können zum Beispiel Bedeutungen der     |
 |                            | Werte des Items erläutert werden. Diese Beschreibung wird in der Admin GUI oberhalb    |
 |                            | des Item-Wertes angezeigt.                                                             |
 +----------------------------+----------------------------------------------------------------------------------------+
@@ -78,13 +78,13 @@ plugin-spezifischen Attribute ist in der Dokumentation des jeweiligen Plugins na
 +----------------------------+----------------------------------------------------------------------------------------+
 | hysteresis_upper_threshold | Oberer Schwellwert für die Hysterese. Bei der Überschreitung dieses Wertes im Item     |
 |                            | welches den zu überwachenden Eingabewert darstellt, wird dieses Item auf True gesetzt. |
-|                            | Optional kann in diesem Attribut eine Dauer angegeben werden, welche die Überscheitung |
+|                            | Optional kann in diesem Attribut eine Dauer angegeben werden, welche die Überschreitung|
 |                            | andauern muss, damit der Wert des Items auf True gesetzt wird.                         |
 +----------------------------+----------------------------------------------------------------------------------------+
 | hysteresis_lower_threshold | Unterer Schwellwert für die Hysterese. Bei der Unterschreitung dieses Wertes im Item   |
 |                            | welches den zu überwachenden Eingabewert darstellt, wird dieses Item auf False gesetzt.|
-|                            | Optional kann in diesem Attribut eine Dauer angegeben werden, welche die Unterscheitung|
-|                            | andauern muss, damit der Wert des Items auf False gesetzt wird.                        |
+|                            | Optional kann in diesem Attribut eine Dauer angegeben werden, welche die               |
+|                            | Unterschreitung andauern muss, damit der Wert des Items auf False gesetzt wird.        |
 +----------------------------+----------------------------------------------------------------------------------------+
 | initial_value,             | Ein optionaler Startwert für dieses Item. Es wird empfohlen **initial_value**          |
 | value                      | anstelle des bisherigen Attributnamens **value** zu verwenden.                         |
@@ -169,4 +169,3 @@ plugin-spezifischen Attribute ist in der Dokumentation des jeweiligen Plugins na
    on_update
    struct
    type
-

doc/user/source/referenz/logiken/logiken.rst

@@ -18,7 +18,7 @@ können. Logiken für SmartHomeNG sind Python Skripte. Zur Erstellung von Logike
 der Programmiersprache Python verfügen.
 
 In diesem Abschnitt wird die grundlegende Struktur einer Logik, sowie deren Konfiguration beschrieben. Weiterhin
-werden die definierten Objekte und Methoden, sowie die zur Verfügung stehenden Pythom Module erläutert. Im weiteren
+werden die definierten Objekte und Methoden, sowie die zur Verfügung stehenden Python Module erläutert. Im weiteren
 wird beschrieben, wie auf Items zugegriffen wird.
 
 Das mqtt Modul bietet einen Support für Logiken, der auch in diesem Abschnitt dokumentiert ist.
@@ -44,5 +44,3 @@ definiert hat).
    logiken_funktionen
    logiken_mqtt
    logiken_exceptions
-
-

doc/user/source/referenz/logiken/logiken_funktionen.rst

@@ -42,7 +42,7 @@ Dafür müssen Funktionen und Variablen der Funktion als Parameter übergeben we
 Übergabe für jede Variable/Funktion einzeln erfolgt oder sie können in einem Objekt übergeben werden (was die zu
 bevorzugende Methode ist.
 
-Dazu kann das Objekt **logic** genutzt werden, welches SmartHomeNG zur Verfüfung stellt um Variablen zu implementieren,
+Dazu kann das Objekt **logic** genutzt werden, welches SmartHomeNG zur Verfügung stellt um Variablen zu implementieren,
 die den Lauf der Logik "überleben" und beim nächsten Lauf dieser Logik wieder zur Verfügung stehen. Das **logic**
 Objekt ist privat. Das bedeutet, jede Logik hat ihr eigenes **logic** Objekt.
 
@@ -190,6 +190,6 @@ Zu beachten ist hierbei, dass das Weglassen der Zeile
 
     logic.triggervalue = triggervalue
 
-und das Ansprechen der Objektes ohne den Präfix ``logic.`` dazu führt, dass das Objekt nur während des Laufed
-der Logik existiert. Wird hingegen das Objekt im logic Objekt abgelegt, existert das Objekt mis zum Neustart
+und das Ansprechen der Objektes ohne den Präfix ``logic.`` dazu führt, dass das Objekt nur während des Laufens
+der Logik existiert. Wird hingegen das Objekt im logic Objekt abgelegt, existiert das Objekt mis zum Neustart
 von SmartHomeNG (Siehe dazu auch **Persistente Variablen**).

doc/user/source/referenz/logiken/logiken_grundstruktur.rst

@@ -12,7 +12,7 @@ Grundstruktur einer Logik
 =========================
 
 Eine Logik besteht aus einem Python Skript sowie einer Reihe von Parametern die den Aufruf (das Triggern) der Logik
-steuern. Eine Logik kan während der Laufzeit von SmartHomeNG geladen und entladen werden. Dadurch sind Veränderungen
+steuern. Eine Logik kann während der Laufzeit von SmartHomeNG geladen und entladen werden. Dadurch sind Veränderungen
 ein einer Logik möglich, ohne SmartHomeNG neu starten zu müssen.
 
 Das eigentliche Python Skript einer Logik muss im Verzeichnis ``../logics`` der SmartHomeNG Installation abgelegt
@@ -26,7 +26,7 @@ das Skript erstellt werden, as auch die Parameter zur Konfiguration erfasst werd
 im Anschluß das Laden einer neuen Logik.
 
 Einfache Logiken bestehen nur aus einer Hauptroutine. Es ist jedoch möglich, Funktionen und Klassen innerhalb einer
-Logik zu defninieren, um bei umfangreichen Logiken den Code verständlich und wartbar zu halten.
+Logik zu definieren, um bei umfangreichen Logiken den Code verständlich und wartbar zu halten.
 
 Eine einfache Logik, die das Wohnzimmerlicht einschaltet, wenn sie getriggert wird, kann zum Beispiel so aussehen:
 
@@ -39,4 +39,3 @@ Eine einfache Logik, die das Wohnzimmerlicht einschaltet, wenn sie getriggert wi
 
 Auf Items muß unter Nutzung von Klammern ``()`` zugegriffen werden, da es sich um eine Item Methode handelt und
 nicht um eine Variable.
-

doc/user/source/referenz/logiken/logiken_logging.rst

@@ -58,7 +58,7 @@ Für eine Logik mit dem Namen ``example``, sieht das beispielsweise folgenderma
 
 Als Handler wird dabei der bereits im Logger ``logics`` definierte Handler verwendet. Es können bei Bedarf im
 Logger der einzelnen Logik zusätzliche handler angegeben werden. Dabei muss darauf geachtet werden, dass der im
-Logger ``logics`` definierte Handler nicht erneut angegeben wird, sa sonst die Logausgaben doppelt erfolgen.
+Logger ``logics`` definierte Handler nicht erneut angegeben wird, da sonst die Logausgaben doppelt erfolgen.
 
 
 
@@ -82,4 +82,3 @@ heraus folgendermaßen Logeinträge erstellt werden:
 Zusätzlich zu den Logeinträgen die in der Logik explizit erzeugt werden, wird vor Aufruf der Logik ein Logeintrag
 erzeugt, der anzeigt, was die Ausführung der Logik getriggert hat. Dieser Logeintrag wird im Level DEBUG geschrieben.
 Er erscheint in den Logdateien also nur, wenn der Loglevel für die entsprechende Logik auf DEBUG gesetzt ist.
-

doc/user/source/referenz/logiken/logiken_logic_objekt.rst

@@ -56,7 +56,7 @@ Vordefinierte Attribute des Logikobjekts:
 |                                | in einem vorherigen Lauf dieser Logik persistieren Variabl                              |
 +--------------------------------+-----------------------------------------------------------------------------------------+
 
-Zusätzlich gibt es noch das Dictionary ``trigger``, welches Infromationen dazu enthält, wodurch der aktuelle Lauf
+Zusätzlich gibt es noch das Dictionary ``trigger``, welches Informationen dazu enthält, wodurch der aktuelle Lauf
 der Logik getriggert wurde.
 
 
@@ -82,7 +82,7 @@ Das Dictionary enthält folgende Informationen:
 +-------------------------------+--------------------------------------------------------------------------------------------------------+
 | ``trigger['source_details']`` | Falls eine Logik aus einem Item heraus getriggert wurde (also trigger['by'] == Item ist), enthält      |
 |                               | ``trigger['source_details']`` weitere Details zum Auslöser (Beispiel: 'knx:1.1.241:ga=3/3/5')          |
-|                               | Falls der Auslöser der Scheduler war, enthält ``trigger['source_details']`` die Zyklus Teit oder den   |
+|                               | Falls der Auslöser der Scheduler war, enthält ``trigger['source_details']`` die Zyklus Zeit oder den   |
 |                               | auslösenden ``crontab`` Eintrag.                                                                       |
 +-------------------------------+--------------------------------------------------------------------------------------------------------+
 | ``trigger['dest']``           |                                                                                                        |
@@ -120,4 +120,3 @@ Zugriff auf das Logics-API über das logics Objekt:
 
 Der vollständige Syntax der Methoden kann im Abschnitt :doc:`Entwicklung/APIs von SmartHomeNG </referenz/APIs>`
 dem **Logics-API** entnommen werden.
-