diff --git a/doc/user/source/referenz/items/attributes_relative_referenzen.rst b/doc/user/source/referenz/items/attributes_relative_referenzen.rst index 883be74113..591e7c516c 100644 --- a/doc/user/source/referenz/items/attributes_relative_referenzen.rst +++ b/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', "'", "'") - diff --git a/doc/user/source/referenz/items/item_zugriff.rst b/doc/user/source/referenz/items/item_zugriff.rst index 3d530fe7d1..20113ad899 100644 --- a/doc/user/source/referenz/items/item_zugriff.rst +++ b/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 diff --git a/doc/user/source/referenz/items/methoden.rst b/doc/user/source/referenz/items/methoden.rst index e31d009c8d..ae73b7ce2d 100644 --- a/doc/user/source/referenz/items/methoden.rst +++ b/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: diff --git a/doc/user/source/referenz/items/plugin_attribute.rst b/doc/user/source/referenz/items/plugin_attribute.rst index 6c294ce274..a204e48c0a 100644 --- a/doc/user/source/referenz/items/plugin_attribute.rst +++ b/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:`:` +übernommen (geerbt) werden. Dazu wird für das erbende Attribut ein Wert im Format :code:`:` 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" | - diff --git a/doc/user/source/referenz/items/properties.rst b/doc/user/source/referenz/items/properties.rst index dc6a8bab15..7ca37f4b7b 100644 --- a/doc/user/source/referenz/items/properties.rst +++ b/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) | +----------------------+------------+----------+------------------------------------------------------------------------------+ diff --git a/doc/user/source/referenz/items/standard_attribute/eval.rst b/doc/user/source/referenz/items/standard_attribute/eval.rst index 1719921ac1..c434706c3e 100644 --- a/doc/user/source/referenz/items/standard_attribute/eval.rst +++ b/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 diff --git a/doc/user/source/referenz/items/standard_attribute/hysteresis.rst b/doc/user/source/referenz/items/standard_attribute/hysteresis.rst index 1bad22768d..024588ead9 100644 --- a/doc/user/source/referenz/items/standard_attribute/hysteresis.rst +++ b/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" - diff --git a/doc/user/source/referenz/items/standard_attribute/log_change.rst b/doc/user/source/referenz/items/standard_attribute/log_change.rst index fa048cc645..9ec75ee288 100644 --- a/doc/user/source/referenz/items/standard_attribute/log_change.rst +++ b/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()}``. 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. - diff --git a/doc/user/source/referenz/items/standard_attribute/standard_attribute.rst b/doc/user/source/referenz/items/standard_attribute/standard_attribute.rst index 413bc35d35..0835631c61 100644 --- a/doc/user/source/referenz/items/standard_attribute/standard_attribute.rst +++ b/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 - diff --git a/doc/user/source/referenz/logiken/logiken.rst b/doc/user/source/referenz/logiken/logiken.rst index e07aac5b9d..b035eeeb32 100644 --- a/doc/user/source/referenz/logiken/logiken.rst +++ b/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 - - diff --git a/doc/user/source/referenz/logiken/logiken_funktionen.rst b/doc/user/source/referenz/logiken/logiken_funktionen.rst index 0130123e7c..42582f3282 100644 --- a/doc/user/source/referenz/logiken/logiken_funktionen.rst +++ b/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**). diff --git a/doc/user/source/referenz/logiken/logiken_grundstruktur.rst b/doc/user/source/referenz/logiken/logiken_grundstruktur.rst index a53959e536..42b4a5d489 100644 --- a/doc/user/source/referenz/logiken/logiken_grundstruktur.rst +++ b/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. - diff --git a/doc/user/source/referenz/logiken/logiken_logging.rst b/doc/user/source/referenz/logiken/logiken_logging.rst index 6aa118e0da..358821aecf 100644 --- a/doc/user/source/referenz/logiken/logiken_logging.rst +++ b/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. - diff --git a/doc/user/source/referenz/logiken/logiken_logic_objekt.rst b/doc/user/source/referenz/logiken/logiken_logic_objekt.rst index 1c2edc5911..9c27aa4067 100644 --- a/doc/user/source/referenz/logiken/logiken_logic_objekt.rst +++ b/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 ` dem **Logics-API** entnommen werden. - diff --git a/doc/user/source/referenz/logiken/logiken_mqtt.rst b/doc/user/source/referenz/logiken/logiken_mqtt.rst index 2d9640a4f7..1bb911f5ef 100644 --- a/doc/user/source/referenz/logiken/logiken_mqtt.rst +++ b/doc/user/source/referenz/logiken/logiken_mqtt.rst @@ -71,7 +71,7 @@ Messages die ein bestimmtes MQTT Topic enthalten, können folgendermaßen abonni | source_logic | Name der Logik, welche die Funktion **subscribe_topic** aufruft. Hier kann einfach die Variable | | | **logic.name** genutzt werden. | +-------------------------+------------------------------------------------------------------------------------------------------+ -| topic | Topic welches aboniert werden soll. | +| topic | Topic welches abonniert werden soll. | +-------------------------+------------------------------------------------------------------------------------------------------+ | callback | Name der Logik, welche bei Empfang des abonnierten Topics getriggert werden soll. Das kann die | | | aufrufende Logik sein oder eine andere Logik. Wenn die aufrufende Logik getriggert werden soll, kann | @@ -93,7 +93,7 @@ Messages die ein bestimmtes MQTT Topic enthalten, können folgendermaßen abonni Wenn eine als **callback** angegebene Logik getriggert wird, ist das **trigger** dict mit folgenden Werten belegt: - **trigger['source']** - 'mqtt' - Konstante -- **trigger['by']** - - Dadurch kann bestimmt werden, wie die payload zu behandeln ist, falls eine Logik die Callbacks mehrer topics erhält +- **trigger['by']** - - Dadurch kann bestimmt werden, wie die payload zu behandeln ist, falls eine Logik die Callbacks mehrerer topics erhält - **trigger['value']** - , wobei der Datentyp der payload dem entspricht, was in mqtt.subscribe_topic() als payload_type angegeben wurde Es können mehrere Logiken das selbe Topic abonnieren. Alle Logiken die das Topic abonniert haben, werden beim Eintreffen @@ -156,7 +156,7 @@ Hier ist eine Beispiel Logik, die sowohl Subscriptions ausführt, als auch die C logger.info("MQTT received topic '{}': payload = '{}' - type(payload) = {})".format(topic, payload, type(payload))) else: mydict = {'txt': 'Test payload 2', 'num': 5} - # logger, mqtt and logic are handed over to functions, because only this way they are accessable in a logic's function + # logger, mqtt and logic are handed over to functions, because only this way they are accessible in a logic's function logic_publish_topic(logger, mqtt, logic, 'test_mqtt/topic', 'Test payload') logic_publish_topic(logger, mqtt, logic, 'test_mqtt/topic2', mydict) logic_subscribe_topic(logger, mqtt, logic, 'test_mqtt/sub') @@ -168,4 +168,3 @@ Hier ist eine Beispiel Logik, die sowohl Subscriptions ausführt, als auch die C Den **logger** müsste man nicht unbedingt an die Funktionen in der Logik übergeben, aber dann würden im Log die Einträge aus Funktionen innerhalb der Logik im Logfile als Modul nicht **logics.mqtt_demo** angeben, sondern **scheduler**. - diff --git a/doc/user/source/referenz/logiken/logiken_persistente_vars.rst b/doc/user/source/referenz/logiken/logiken_persistente_vars.rst index d9e4a633a5..c2996b2b20 100644 --- a/doc/user/source/referenz/logiken/logiken_persistente_vars.rst +++ b/doc/user/source/referenz/logiken/logiken_persistente_vars.rst @@ -98,7 +98,7 @@ Neustart von SmartHomeNG verloren. Einrichtung (Logik übergreifend) ================================ -Statt eine persistende lokale Variable einzurichten: +Statt eine persistente lokale Variable einzurichten: .. code-block:: python @@ -137,4 +137,3 @@ zum Neustart von SmartHomeNG. Da die Logik-übergreifende Variable ihren Wert auch behält, wenn die Logik die sie initialisiert hat neu geladen wird, kann es zu unerwarteten Ergebnissen kommen, da sich die Logik nun evtl. bei einem Neustart der Logik anders verhält, als beim Neustart von SmartHomeNG! - diff --git a/doc/user/source/referenz/logiken/logiken_plugin_funktionen.rst b/doc/user/source/referenz/logiken/logiken_plugin_funktionen.rst index ab11a1b05d..36864de761 100644 --- a/doc/user/source/referenz/logiken/logiken_plugin_funktionen.rst +++ b/doc/user/source/referenz/logiken/logiken_plugin_funktionen.rst @@ -25,7 +25,7 @@ Um die Dokumentation der Funktionen eins Plugins zu finden, bzw. herauszufinden, Funktionen anbietet, klickt man in der Navigation der Anwender Dokumentation auf **Plugins** und anschließend auf den Unterpunkt für den Plugin Typ (für das **knx** Plugin auf **Gateway Plugins**). In der angezeigten Tabelle von Plugins klickt man anschließend in der Spalte **Plugin** auf den Namen (also **knx**). Dadurch wird die -Konfigurations-Dokuemntation (Parameter, Item Attribute, etc.) des Plugins angezeigt. +Konfigurations-Dokumentation (Parameter, Item Attribute, etc.) des Plugins angezeigt. Auf der Seite den Abschnitt **Plugins Functions** suchen. Für das **knx** Plugin sind hier mehrere Funktionen aufgeführt, unter anderem auch die Funktion ``groupwrite(ga, data, dpt)`` mit der Beschreibung ihrer Parameter. @@ -59,5 +59,3 @@ der Pluginfunktion so: .. code-block:: python sh.local_knxd.groupwrite('1/2/1', 123, 5) - - diff --git a/doc/user/source/referenz/logiken/logiken_standardparameter.rst b/doc/user/source/referenz/logiken/logiken_standardparameter.rst index 4d26171c68..27c752a18f 100644 --- a/doc/user/source/referenz/logiken/logiken_standardparameter.rst +++ b/doc/user/source/referenz/logiken/logiken_standardparameter.rst @@ -32,7 +32,7 @@ Die folgenden Parameter können für eine Logik in der Konfigurationsdatei im Ve | | :ref:`hier ` . | +------------------+-----------------------------------------------------------------------------------------------+ | prio | **Optional**: Angabe einer Priorität für die Logik. Die Priorität kommt nur bei Logiken zum | -| | Einsatz, die ein Schedule haben, bei denen also der Paramter **crontab** oder **cycle** | +| | Einsatz, die ein Schedule haben, bei denen also der Parameter **crontab** oder **cycle** | | | angegeben wurde. Die Priorität sollte zwischen **1** und **5** liegen. Falls der Parameter | | | nicht angegeben wird, wird die Standardpriorität **3** verwendet. | +------------------+-----------------------------------------------------------------------------------------------+ @@ -51,4 +51,3 @@ Die folgenden Parameter können für eine Logik in der Konfigurationsdatei im Ve Falls keiner der optionalen Parameter **crontab**, **watch_item** oder **cycle** angegeben wird, wird die Logik nicht automatisiert ausgeführt. Sie kann dann nur aus Plugins oder (falls konfiguriert) über eine Visualisierung ausgelöst werden. - diff --git a/doc/user/source/referenz/metadata/module_global.rst b/doc/user/source/referenz/metadata/module_global.rst index 0051760d72..18cd69a922 100644 --- a/doc/user/source/referenz/metadata/module_global.rst +++ b/doc/user/source/referenz/metadata/module_global.rst @@ -30,15 +30,14 @@ Der globale Metadaten Abschnitt ``module:`` kennt die folgenden Schlüsselbegrif Beschreibung der Schlüsselbegriffe im Abschnitt ``module:`` - ``classname:`` Name der Python Klasse die das Modul implementiert un die zum Start des Moduls initialisiert wird - - ``version:`` VersionsNumber des Moduls. Sie wird beim Laden mit der Versionsnummer die im Code definierert ist verglichen. - - ``sh_minversion:`` Minimale SmartHomeNG Version mit der das Modul kmpatibel ist. Falls `sh_minversion`` leer ist, nimmt SmartHomeNG an, dass das Modul mit jeder älteren Version von SmartHomeNG kompatibel ist. - - ``sh_maxversion:`` Maximale SmartHomeNG Version mit der das Modul kmpatibel ist. Falls `sh_maxversion`` leer ist, nimmt SmartHomeNG an, dass das Modul mit jeder neueren Version von SmartHomeNG kompatibel ist. - - ``py_minversion:`` Minimale Python Version mit der das Modul kmpatibel ist. Falls `py_minversion`` leer ist, nimmt SmartHomeNG an, dass das Modul mit jeder älteren Python Version komatibel ist die von SmartHomeNG unterstützt wird. - - ``py_maxversion:`` Maximale Python Version mit der das Modul kmpatibel ist. Falls `py_maxversion`` leer ist, nimmt SmartHomeNG an, dass das Modul mit jeder neueren Python Version komatibel ist die von SmartHomeNG unterstützt wird. + - ``version:`` VersionsNumber des Moduls. Sie wird beim Laden mit der Versionsnummer die im Code definiert ist verglichen. + - ``sh_minversion:`` Minimale SmartHomeNG Version mit der das Modul kompatibel ist. Falls `sh_minversion`` leer ist, nimmt SmartHomeNG an, dass das Modul mit jeder älteren Version von SmartHomeNG kompatibel ist. + - ``sh_maxversion:`` Maximale SmartHomeNG Version mit der das Modul kompatibel ist. Falls `sh_maxversion`` leer ist, nimmt SmartHomeNG an, dass das Modul mit jeder neueren Version von SmartHomeNG kompatibel ist. + - ``py_minversion:`` Minimale Python Version mit der das Modul kompatibel ist. Falls `py_minversion`` leer ist, nimmt SmartHomeNG an, dass das Modul mit jeder älteren Python Version komatibel ist die von SmartHomeNG unterstützt wird. + - ``py_maxversion:`` Maximale Python Version mit der das Modul kompatibel ist. Falls `py_maxversion`` leer ist, nimmt SmartHomeNG an, dass das Modul mit jeder neueren Python Version komatibel ist die von SmartHomeNG unterstützt wird. - ``description:`` Mehrsprachiger Text, der die Funktion das Plugins beschreibt. Die Beschreibung wird bei der Generierung des Dokumentations-Seiten des Plugins verwendet - Die Texte in den verschiedenen Sprachen werden als Unter-Einträge in der Form : erfasst. Zur Identifikation der Sprache werden die 2-stelligen Länder-Kürzel verwendet (``de``, ``en``, ``fr``, ``pl``, ...) ``de`` und ``en`` müssen angegeben werden. Weitere Sprachen sind optional. - diff --git a/doc/user/source/referenz/metadata/parameter_keys.rst b/doc/user/source/referenz/metadata/parameter_keys.rst index eb3dde79a4..221e9720d3 100644 --- a/doc/user/source/referenz/metadata/parameter_keys.rst +++ b/doc/user/source/referenz/metadata/parameter_keys.rst @@ -58,7 +58,7 @@ Beschreibung der Schlüssel im Abschnitt für einen Parameter bzw. ein Attribut: - ``valid_list_ci:`` Optional: Liste der erlaubten Werte für den Parameter (nicht case sensitive) Der Wert wird dem Plugin/Modul in lower case übergeben. - Falls ``valid_list_ci`` angegeben ist, wird eine evtl spezifizierte ``valid_list`` ignoriert. + Falls ``valid_list_ci`` angegeben ist, wird eine evtl. spezifizierte ``valid_list`` ignoriert. - ``valid_list_description:`` Optional: Beschreibung der Werte, die in ``valid_list:`` bzw. ``valid_list_ci:`` spezifiziert sind. @@ -75,4 +75,3 @@ Beschreibung der Schlüssel im Abschnitt für einen Parameter bzw. ein Attribut: - ``mandatory:`` Optional: Falls auf ``True`` gesetzt, muss dieser Wert konfiguriert werden, damit das Plugin/Modul geladen/initialisiert wird. Diese Einschränkung ist wirkungslos, falls ein Wert für ``default:`` definiert ist. - diff --git a/doc/user/source/referenz/metadata/plugin_functions.rst b/doc/user/source/referenz/metadata/plugin_functions.rst index 22ff819dd4..35a19b94a7 100644 --- a/doc/user/source/referenz/metadata/plugin_functions.rst +++ b/doc/user/source/referenz/metadata/plugin_functions.rst @@ -10,10 +10,10 @@ plugin_functions Dieser Abschnitt beschreibt die öffentlichen Funktionen, die in einem Plugin implementiert sind. -``plugin_functions:`` enthält einen Abschnitt für jede implementierte Funktion, die öffenlich (also von außerhalb +``plugin_functions:`` enthält einen Abschnitt für jede implementierte Funktion, die öffentlich (also von außerhalb des Plugins aufrufbar) sein soll. Der Name des Abschnitts ist der Name der Funktion. -Jede Funktionsdefinition enhält einen Abschnitt ``parameters:``, welcher die Parameter der Funktion im Detail +Jede Funktionsdefinition enthält einen Abschnitt ``parameters:``, welcher die Parameter der Funktion im Detail beschreibt. Die Definitionen im Abschnitt ``plugin_functions:`` werden für die Erstellung der Dokumentation genutzt. In der @@ -70,6 +70,6 @@ Falls eine Plugin-Funktion keine Parameter hat, darf der Eintrag ``parameters:`` Aufruf von Funktionen ~~~~~~~~~~~~~~~~~~~~~ -Wenn Plugin-Funktionen in einer Logik verwendet werden sollen, kann dies in der folgenden Form erfolgen: +Wenn Plugin-Funktionen in einer Logik verwendet werden sollen, kann dies in der folgenden Form erfolgen: ``result = sh.plugins.return_plugin("").()`` diff --git a/doc/user/source/referenz/metadata/plugin_global.rst b/doc/user/source/referenz/metadata/plugin_global.rst index dd356cefe0..100039725f 100644 --- a/doc/user/source/referenz/metadata/plugin_global.rst +++ b/doc/user/source/referenz/metadata/plugin_global.rst @@ -65,24 +65,24 @@ Beschreibung der Schlüsselbegriffe im Abschnitt ``plugin:`` user_doc.rst oder die veraltete README.md gemeint) - ``support:`` url die auf einen Support Thread oder ein Support Forum verweist - - ``version:`` VersionsNumber des Plugins. Sie wird beim Laden mit der Versionsnummer die im Code definierert ist + - ``version:`` VersionsNumber des Plugins. Sie wird beim Laden mit der Versionsnummer die im Code definiert ist verglichen. - - ``sh_minversion:`` Minimale SmartHomeNG Version mit der das Plugin kmpatibel ist. Falls `sh_minversion`` leer + - ``sh_minversion:`` Minimale SmartHomeNG Version mit der das Plugin kompatibel ist. Falls `sh_minversion`` leer ist, nimmt SmartHomeNG an, dass das Plugin mit jeder älteren Version von SmartHomeNG kompatibel ist. - - ``sh_maxversion:`` Maximale SmartHomeNG Version mit der das Plugin kmpatibel ist. Falls `sh_maxversion`` leer + - ``sh_maxversion:`` Maximale SmartHomeNG Version mit der das Plugin kompatibel ist. Falls `sh_maxversion`` leer ist, nimmt SmartHomeNG an, dass das Plugin mit jeder neueren Version von SmartHomeNG kompatibel ist. - - ``py_minversion:`` Minimale Python Version mit der das Plugin kmpatibel ist. Falls `py_minversion`` leer ist, - nimmt SmartHomeNG an, dass das Plugin mit jeder älteren Python Version komatibel ist die von SmartHomeNG + - ``py_minversion:`` Minimale Python Version mit der das Plugin kompatibel ist. Falls `py_minversion`` leer ist, + nimmt SmartHomeNG an, dass das Plugin mit jeder älteren Python Version kompatibel ist die von SmartHomeNG unterstützt wird. - - ``py_maxversion:`` Maximale Python Version mit der das Plugin kmpatibel ist. Falls `py_maxversion`` leer ist, - nimmt SmartHomeNG an, dass das Plugin mit jeder neueren Python Version komatibel ist die von SmartHomeNG + - ``py_maxversion:`` Maximale Python Version mit der das Plugin kompatibel ist. Falls `py_maxversion`` leer ist, + nimmt SmartHomeNG an, dass das Plugin mit jeder neueren Python Version kompatibel ist die von SmartHomeNG unterstützt wird. - ``multi_instance:`` Ist das Plugin in der Lage in mehreren Instanzen gestartet zu werden? (``True``, ``False``) - ``configuration_needed:`` Normalerweise wird in der Admin GUI ein Plugin im Status disabled hinzugefügt und muss erst konfiguriert werden. Wenn dieser Parameter auf ``False`` gesetzt wird, wird das Plugin im Status ``enabled`` hinzugefügt. Das ist sinnvoll bei Plugins, die ohne Konfiguration lauffähig sind. (``True``, ``False``) - - ``restartable:`` Is the Plugin Restart bzw. Reload fählg? (gültige Werte: ``True``, ``False``, ``unknown``) + - ``restartable:`` Is the Plugin Restart bzw. Reload fähig? (gültige Werte: ``True``, ``False``, ``unknown``) - ``startorder`` Dieser Parameter darf nur bei speziellen Plugins gesetzt werden, die besondere Anforderungen an die Startreihenfolge haben (wie z.B. das database Plugin). Gültige Werte sind ``early``, ``normal`` und ``late``. Plugins mit ``startorder`` ``early`` werden vor den anderen Plugins gestartet (und beim @@ -91,4 +91,3 @@ Beschreibung der Schlüsselbegriffe im Abschnitt ``plugin:`` wird. - ``classpath:`` **Wird normalerweise nicht angegeben** - Nur angeben, wenn das Plugin außerhalb des ``/plugins`` Verzeichnisses gespeichert ist, - diff --git a/doc/user/source/referenz/netzwerk.rst b/doc/user/source/referenz/netzwerk.rst index 857f89cd3f..04af02c7ec 100644 --- a/doc/user/source/referenz/netzwerk.rst +++ b/doc/user/source/referenz/netzwerk.rst @@ -19,7 +19,7 @@ SmartHomeNG nutzt bisher IP v4. Es ist noch nicht durchgängig IP v6 fähig. Ports ===== -Folgende Ports werden durch SmartHomeNG auf dem System geöffnet. Aufgelistst sind die Standard Ports. Alle Ports +Folgende Ports werden durch SmartHomeNG auf dem System geöffnet. Aufgelistet sind die Standard Ports. Alle Ports können frei konfiguriert werden. .. csv-table:: Port Nutzung durch SmartHomeNG @@ -37,7 +37,7 @@ können frei konfiguriert werden. Die folgenden Dienste können auf dem System auf dem SmartHomeNG läuft installiert sein oder auf anderen Rechnern. Falls diese Dienste auch auf dem SmartHomeNG System installiert/gestartet sind, sind zusätzlich folgende Ports -geöffenet: +geöffnet: .. csv-table:: Port Nutzung durch weitere Dienste :header: "Port", "Prozess", "Software", "Verwendung" @@ -48,4 +48,3 @@ geöffenet: "6600", "mpd", "Music Player Daemon", "Wiedergabe von Musik über Audio Peripherie eines Linux Systems" "6720", "knxd", "KNX Daemon", "Kommunikation zu KNX Interface oder KNX Router" "8883", "Mosquitto", "MQTT Broker", "Secure MQTT über TCP (falls konfiguriert)" - diff --git a/doc/user/source/referenz/plugins/asyncio_support.rst b/doc/user/source/referenz/plugins/asyncio_support.rst index 0d4eae8c14..618a3635fa 100644 --- a/doc/user/source/referenz/plugins/asyncio_support.rst +++ b/doc/user/source/referenz/plugins/asyncio_support.rst @@ -15,7 +15,7 @@ asyncio Unterstützung in Plugins :redsup:`Neu` Python Packages zur Ansteuerung von Peripherie werden zunehmend unter Verwendung von asyncio erstellt. Um diese Packages in Plugins nutzen zu können, muss das jeweilige Plugin asyncio unterstützen. Die Implementierung hiervon -ist nicht tirvial und die ersten Plugins die asyncio implementiert haben, tun das sehr unterschiedlich und unter +ist nicht trivial und die ersten Plugins die asyncio implementiert haben, tun das sehr unterschiedlich und unter Nutzung der Low-Level Funktionen von asyncio (was ein erhebliches Error-Handling im Plugin voraussetzt). Um die Nutzung von asyncio zu vereinfachen und in den Plugins zu standardisieren, unterstützt SmartHomeNG ab @@ -37,4 +37,3 @@ Im folgenden sind die Methoden beschrieben, die zur asyncio Unterstützung zur S :undoc-members: :show-inheritance: :member-order: bysource - diff --git a/doc/user/source/referenz/plugins/plugin_metadata.rst b/doc/user/source/referenz/plugins/plugin_metadata.rst index 11a2c89e36..e4ca4cedf8 100644 --- a/doc/user/source/referenz/plugins/plugin_metadata.rst +++ b/doc/user/source/referenz/plugins/plugin_metadata.rst @@ -27,7 +27,7 @@ Abschnitte, die im folgenden beschrieben sind. benutzt werden können - ``item_attributes:`` - Definition der Item Attribute, die durch das Plugin genutzt/unterstützt werden - ``item_structs:`` - Definition von Item Strukturen, welche im Zusammenhang mit dem Plugin genutzt werden können -- ``item_attribute_prefixes:`` - Definition von Item Attributen elche nur einen genmeinsamen Namens-Beginn haben +- ``item_attribute_prefixes:`` - Definition von Item Attributen welche nur einen gemeinsamen Namens-Beginn haben - ``logic_parameters:`` - Definition von Parameters welche steuern wie Logiken durch das Plugin genutzt/getriggert werden können - ``plugin_functions:`` - Beschreibung öffentlicher Funktionen des Plugins, die durch Logiken oder andere Plugins @@ -50,5 +50,3 @@ Für Plugins werden die folgenden Abschnitte in der Metadaten Datei ``plugin.yam /referenz/metadata/plugin_functions | - - diff --git a/doc/user/source/referenz/plugins/plugin_typen/smartdeviceplugin.rst b/doc/user/source/referenz/plugins/plugin_typen/smartdeviceplugin.rst index e429384d60..c8b0a0ed45 100644 --- a/doc/user/source/referenz/plugins/plugin_typen/smartdeviceplugin.rst +++ b/doc/user/source/referenz/plugins/plugin_typen/smartdeviceplugin.rst @@ -156,7 +156,7 @@ in der plugin.yaml entsprechend angepasst wird. Zum Lieferumfang gehörten die Verbindungsklassen `SDPConnection` (keine Funktion, Basisklasse, kann zum Testen verwendet werde), `SDPConnectionNetTcpRequest` (Netzwerkverbindung mit HTTP-Requests und -Antworten über TCP), `SDPConnectionNetTcpClient` (direkte TCP-Verbindung mit persistenter Sendeverbindung und Listener zum -asnychronen Datenempfang), `SDPConnectionNetUdpRequest` (wie SDPConnectionNetTcpRequest, aber mit zusätzlichem +asynchronen Datenempfang), `SDPConnectionNetUdpRequest` (wie SDPConnectionNetTcpRequest, aber mit zusätzlichem UDP-Listener, z.B. für Multicast), `SDPConnectionSerial` (Anfrage-Antwort-Verbindung über serielle Schnittstelle) sowie `SDPConnectionSerialAsync` (serielle Verbindung mit Listener, der eingehende Daten unabhängig von gesendeten Kommandos empfangen kann). @@ -190,4 +190,3 @@ verwendet werden soll. Die abgeleiteten Klassen umfassen `SDPCommandStr` für Ko (z.B. HTTP oder Textprotokolle), `SDPCommandParseStr` mit zusätzlichen Möglichkeiten zur Text- und Datenextraktion, SDPCommandJSON für JSON-RPC-Kommunikation sowie SDPCommandViessmann für die binären Datenformate der Viessmann-Heizungen. - diff --git a/doc/user/source/referenz/plugins/plugin_user_doc.rst b/doc/user/source/referenz/plugins/plugin_user_doc.rst index 959b41ae41..869ae7fcb6 100644 --- a/doc/user/source/referenz/plugins/plugin_user_doc.rst +++ b/doc/user/source/referenz/plugins/plugin_user_doc.rst @@ -28,7 +28,7 @@ Case sensitive!) .. important:: - Im folgenden Template sind die Einträge in sptzen Klammern jeweils durch den gewünschten Inhalt zu ersetzen oder + Im folgenden Template sind die Einträge in spitzen Klammern jeweils durch den gewünschten Inhalt zu ersetzen oder zu entfernen. Die erste Überschrift der Dokumentationsdatei ``user_doc`` MUSS dem Kurznamen des Plugins in Kleinbuchstaben entsprechen. diff --git a/doc/user/source/referenz/python/python_installation.rst b/doc/user/source/referenz/python/python_installation.rst index 8bb19dffef..d68f8678e5 100644 --- a/doc/user/source/referenz/python/python_installation.rst +++ b/doc/user/source/referenz/python/python_installation.rst @@ -40,7 +40,7 @@ Download des Source Codes ========================= Auf der website **python.org** unter **Downloads/Source Code** die gewünschte Version suchen und die das entsprechende -Archiv (XZ compressed source tarball) herunter laden. Die Datei träget den Namen **Python-3.10.12.tar.xz**. +Archiv (XZ compressed source tarball) herunter laden. Die Datei trägt den Namen **Python-3.10.12.tar.xz**. Anschließend diese Datei auf dem SmartHomeNG-System in das Verzeichnis **/usr/local/src** kopieren. (Aufgrund der Verzeichnisrechte muss das evtl. mit sudo geschehen) @@ -96,4 +96,3 @@ Dieses kann mit python3.10 --version überprüft werden. Als Ausgabe sollte **Python 3.10.12** angezeigt werden. - diff --git a/doc/user/source/referenz/python/support_skripte.rst b/doc/user/source/referenz/python/support_skripte.rst index 79d1870f4e..ccd36c1cf4 100644 --- a/doc/user/source/referenz/python/support_skripte.rst +++ b/doc/user/source/referenz/python/support_skripte.rst @@ -56,8 +56,8 @@ act Skript Das Skript **act** dient zum Aktivieren von vorher erzeugten virtuellen Python Umgebungen. Es wird mit einem Parameter aufgerufen. Der Parameter ist der Name des Environments. Dem Aufruf des Skriptes muss ``source`` -vorangestellt werden, damit die Ergebisse des Skripts auf die aktuelle Shell wirken. Wird ``source`` vergessen, -gibt das skript eine Fehlermeldung aus. +vorangestellt werden, damit die Ergebnisse des Skripts auf die aktuelle Shell wirken. Wird ``source`` vergessen, +gibt das Skript eine Fehlermeldung aus. Um zum Beispiel das Environment für Python 3.8 zu aktivieren, kann einfach der folgende Befehl eingegeben werden: @@ -80,4 +80,3 @@ Ein aktives virtuelles Environment wird mit dem Befehl **deactivate** verlassen: | - diff --git a/doc/user/source/referenz/python/virtual_environments.rst b/doc/user/source/referenz/python/virtual_environments.rst index e91f8b2864..622136e697 100644 --- a/doc/user/source/referenz/python/virtual_environments.rst +++ b/doc/user/source/referenz/python/virtual_environments.rst @@ -19,7 +19,7 @@ schaffen, die unter unterschiedlichen Python Versionen laufen. Dieses ist besond Entwicklung von SmartHomeNG oder von Plugins testen möchte, wie sich SmartHomeNG (bzw. das Plugin) unter verschiedenen Python Versionen verhält. -Es gibt eine Reihe von Tools, um virtuelle Environments zu erstellen. Die verbreitetesten Tools sind **virtualenv** +Es gibt eine Reihe von Tools, um virtuelle Environments zu erstellen. Die am meisten verbreiteten Tools sind **virtualenv** und **venv**. **venv** gibt es seit Python 3.3. Es ist Bestandteil der Python Installation. Allerdings ist es in @@ -36,7 +36,7 @@ Folgenden wird auch nur vom Einsatz von **venv** ausgegangen. | Die virtuellen Environments werden standardmäßig im Unterverzeichnis ``venvs`` des SmartHomeNG Basisverzeichnises -gespeichert. Außer den virtuallen Environments enthält das Verzeichnis auch Skripte zur Verwaltung der +gespeichert. Außer den virtuellen Environments enthält das Verzeichnis auch Skripte zur Verwaltung der virtuellen Environments. Das postinstall Skript der SmartHomeNG Installation nimmt dieses Verzeichnis in den Pfad auf, so dass die Skripte @@ -72,7 +72,7 @@ Jetzt kann mit dem folgenden Befehl ein virtual Environment erstellt werden, wel $ make_env 3.10 -Während der Anlage wird das Environment aktiviert, um einige norwendige Python Packages in das Environment zu +Während der Anlage wird das Environment aktiviert, um einige notwendige Python Packages in das Environment zu installieren bzw. zu aktualisieren. | @@ -110,7 +110,7 @@ eingegeben werden. Löschen eines virtuellen Environment ==================================== -Wenn ein virtuelles Environment nicht mehr benötigt wird, wird einfach das entsprechende Verzeichnis rekirsiv gelöscht. +Wenn ein virtuelles Environment nicht mehr benötigt wird, wird einfach das entsprechende Verzeichnis rekursiv gelöscht. Bitte darauf achten, dass das Environment nicht aktiv ist. Bei Bedarf vor dem Löschen mit dem Befehl ``deactivate`` deaktivieren. @@ -121,7 +121,7 @@ deaktivieren. | -.. index:: Virtuelle Environements als Dienst +.. index:: Virtuelle Environments als Dienst Virtuelle Environements als Dienst ================================== diff --git a/doc/user/source/referenz/referenz.rst b/doc/user/source/referenz/referenz.rst index 304952f137..893793f160 100644 --- a/doc/user/source/referenz/referenz.rst +++ b/doc/user/source/referenz/referenz.rst @@ -10,7 +10,7 @@ Referenz :greensup:`Update` =========================== -Hier entsteht nach und nach eine Referenz in der Details zu einzelnenen Themen von SmartHomeNG nachgelesen werden +Hier entsteht nach und nach eine Referenz in der Details zu einzelnen Themen von SmartHomeNG nachgelesen werden können. diff --git a/doc/user/source/referenz/smarthomeng/ablauf_startup.rst b/doc/user/source/referenz/smarthomeng/ablauf_startup.rst index 49bced6389..a29acbbd4a 100644 --- a/doc/user/source/referenz/smarthomeng/ablauf_startup.rst +++ b/doc/user/source/referenz/smarthomeng/ablauf_startup.rst @@ -20,7 +20,7 @@ evtl. nicht mal die Konfigurationsdateien lesen), werden die unbedingt benötigt SmartHomeNG wird neu gestartet. (In diesem Stadium erfolgen die Log Ausgaben noch auf den Bildschirm) Anschließend werden Kommandozeilen Parameter ausgewertet, falls welche angegeben wurden. -Danach wird das smarthome Objekt erzeugt und wie im Folgenden beschrieben initialisert. +Danach wird das smarthome Objekt erzeugt und wie im Folgenden beschrieben initialisiert. Initialisierung des smarthome Objektes @@ -50,7 +50,7 @@ initialisiert. 1 - Initialisierung: Logging initialisiert ------------------------------------------ -Dis initialisierung des Logging ist abgeschlossen (ab nun erfolgen die Log Ausgaben in die konfigurieten Log-Dateien) +Die Initialisierung des Logging ist abgeschlossen (ab nun erfolgen die Log Ausgaben in die konfigurierten Log-Dateien) SmartHomeNG wird "daemonized", läuft ab jetzt also im Hintergrund. Anschließend wird der initiale Log Eintrag mit Versionsinformationen geschrieben. @@ -129,7 +129,7 @@ wurden. Es wird für alle geladenen Items Scheduler gestartet, falls für das Item das Attribut **crontab:** oder **cycle:** gesetzt wurde. -Es wird für alle geladenen Items bei denen eval-Ausdrücke **und** eval-Trigger definiert sind, die Berechungen +Es wird für alle geladenen Items bei denen eval-Ausdrücke **und** eval-Trigger definiert sind, die Berechnungen des eval-Ausdrucks ausgelöst. @@ -212,4 +212,3 @@ nicht im Begriff ist sich zu beenden, kann abgefragt werden, ob der Status-Code if self._sh.shng_status['code'] == 20: ... - diff --git a/doc/user/source/referenz/smarthomeng/feiertage_datum_zeit.rst b/doc/user/source/referenz/smarthomeng/feiertage_datum_zeit.rst index a283c561c4..5326869b82 100644 --- a/doc/user/source/referenz/smarthomeng/feiertage_datum_zeit.rst +++ b/doc/user/source/referenz/smarthomeng/feiertage_datum_zeit.rst @@ -47,9 +47,9 @@ Die Funktionen für Feiertags- und Wochenend-Handling sind folgende: +------------------------------------------------+----------------------------------------------------------------------------+ | shtime.is_public_holiday(date) | Liefert **True**, falls das Datum ein gesetzlicher Feiertag ist | +------------------------------------------------+----------------------------------------------------------------------------+ -| shtime.holiday_name(date, as_list=False) | Liefert den Namen des Feiertags, falls das Datum ein Feriertag ist. | +| shtime.holiday_name(date, as_list=False) | Liefert den Namen des Feiertags, falls das Datum ein Ferientag ist. | | | Wenn mehrere Feiertage auf das selbe Datum fallen, werden sie Komma- | -| | getrennt zurück geleifert. Falls **as_list** auf **True** gesetzt wird, | +| | getrennt zurück geliefert. Falls **as_list** auf **True** gesetzt wird, | | | ist das Ergebnis kein String, sondern eine Liste mit den Feiertagsnamen. | +------------------------------------------------+----------------------------------------------------------------------------+ | shtime.holiday_list(year) | Liefert eine Liste aller Feiertage für ein Jahr | @@ -203,4 +203,3 @@ Die Funktionen für das Zeit-Handling sind folgende: +---------------------------------+----------------------------------------------------------------------------------------+ | shtime.runtime() | Liefert die Laufzeit von SmartHomeNG, seit SmartHomeNG das letzte mal gestartet wurde. | +---------------------------------+----------------------------------------------------------------------------------------+ - diff --git a/doc/user/source/referenz/smarthomeng/kommandozeilen_optionen.rst b/doc/user/source/referenz/smarthomeng/kommandozeilen_optionen.rst index b8d4dbe13f..243d82f536 100644 --- a/doc/user/source/referenz/smarthomeng/kommandozeilen_optionen.rst +++ b/doc/user/source/referenz/smarthomeng/kommandozeilen_optionen.rst @@ -7,10 +7,10 @@ smarthome.py kann mit folgenden Kommandozeilen Optionen gestartet werden: +------------+----------------------+--------------------------------------------------------------------------------+ | **Option** | **Option (lang)** | **Beschreibung** | +------------+----------------------+--------------------------------------------------------------------------------+ -| -p | --pip3_command | Setzt den Pfad des pip3 Kommandos (notwendig falls es nicht autmatisch | +| -p | --pip3_command | Setzt den Pfad des pip3 Kommandos (notwendig falls es nicht automatisch | | | | gefunden wird) | +------------+----------------------+--------------------------------------------------------------------------------+ -| -i | --interactive | Eine interactive Shell öffen (mit Tab Vervollständigung und ausführlichem | +| -i | --interactive | Eine interactive Shell öffnen (mit Tab Vervollständigung und ausführlichem | | | | Logging) | +------------+----------------------+--------------------------------------------------------------------------------+ | -l | --logics | Alle Logiken neu laden | @@ -48,5 +48,3 @@ smarthome.py kann mit folgenden Kommandozeilen Optionen gestartet werden: +------------+----------------------+--------------------------------------------------------------------------------+ Die als DEPRECATED gekennzeichneten Optionen werden in einem der nächsten Releases entfernt werden. - - diff --git a/doc/user/source/referenz/smarthomeng/methoden_sonne_mond.rst b/doc/user/source/referenz/smarthomeng/methoden_sonne_mond.rst index 0e03260a48..9a1b244f4c 100644 --- a/doc/user/source/referenz/smarthomeng/methoden_sonne_mond.rst +++ b/doc/user/source/referenz/smarthomeng/methoden_sonne_mond.rst @@ -24,7 +24,7 @@ Die Methode ``sh.sun.pos()`` liefert die Position der Sonne und hat zwei optiona # sh.sun.pos(offset) hierbei gibt offset die Differenz in Zeit-Minuten zur aktuellen Zeit an - azimut, altitude = sh.sun.pos() # liefert die aktuelle Position der Sonne, Ergbnis im Bogenmaß + azimut, altitude = sh.sun.pos() # liefert die aktuelle Position der Sonne, Ergebnis im Bogenmaß azimut, altitude = sh.sun.pos(30) # liefert die Position, welche die Sonne in 30 Minuten haben wird im Bogenmaß azimut, altitude = sh.sun.pos(degree=True) # liefert die aktuelle Position der Sonne in Grad @@ -94,7 +94,7 @@ Die Methode ``sh.moon.pos()`` liefert die Position des Mondes und hat zwei optio # sh.moon.pos(offset) hierbei gibt offset die Differenz in Zeit-Minuten zur aktuellen Zeit an - azimut, altitude = sh.moon.pos() # liefert die aktuelle Position des Mondes, Ergbnis im Bogenmaß + azimut, altitude = sh.moon.pos() # liefert die aktuelle Position des Mondes, Ergebnis im Bogenmaß azimut, altitude = sh.moon.pos(30) # liefert die Position, welche der Mond in 30 Minuten haben wird im Bogenmaß azimut, altitude = sh.moon.pos(degree=True) # liefert die aktuelle Position des Mondes in Grad @@ -151,4 +151,3 @@ sh.moon.phase() ``sh.moon.phase(offset)`` gibt die Mondphase als ganze Zahl (0 bis 7) zurück, wobei: 0 = Neumond, 4 = Vollmond, 6 = abnehmender Halbmond - diff --git a/doc/user/source/referenz/userfunctions/userfunctions.rst b/doc/user/source/referenz/userfunctions/userfunctions.rst index a7ff84374a..cae38bc6c5 100644 --- a/doc/user/source/referenz/userfunctions/userfunctions.rst +++ b/doc/user/source/referenz/userfunctions/userfunctions.rst @@ -77,7 +77,7 @@ Funktion **zweiundvierzig** ist also als ``uf.anhalter.zweiundvierzig()`` aufzur .. image:: /referenz/assets/uf_eval_checker1.jpg :class: screenshot -Analog können die Funtionen in **eval** Attributen in Item Definitionen und in Logiken aufgerufen werden. +Analog können die Funktionen in **eval** Attributen in Item Definitionen und in Logiken aufgerufen werden. Logging aus Userfunctions @@ -126,7 +126,7 @@ Damit aus Funktionen ein Logging mit Leveln kleiner als WARNING erfolgt, muss in Nutzung von Item Werten ======================= -Für die Berechungen in den Userfunctions werden häufig die aktuellen Werte von Items benötigt. Um diese Werte in +Für die Berechnungen in den Userfunctions werden häufig die aktuellen Werte von Items benötigt. Um diese Werte in den Userfunctions zu erhalten, gibt es zwei Möglichkeiten. @@ -171,7 +171,7 @@ Falls eine größere Zahl an Item Werten übergeben werden soll und eine Weiterg kann die Userfunction so geschrieben werden, dass sie die Item Struktur kennt und voraussetzt. Statt mehrere Items als einzelne Parameter zu übergeben, braucht dann nur das Smarthome-Objekt übergeben zu werden. -Das folgende Beispiel zeigt beide Varianten (übergabe der Item Werte und Referenzierung über das Smarthome-Objekt). +Das folgende Beispiel zeigt beide Varianten (Übergabe der Item Werte und Referenzierung über das Smarthome-Objekt). .. code:: yaml @@ -241,7 +241,7 @@ Reload von Userfunctions ======================== Benutzerdefinierte Funktionen können während der Laufzeit von SmartHomeNG verändert und neu geladen werden. Dabei -können einzelne Module mit Userfunctions neu geladen werden oder alle Module mit Usewrfunctions auf einmal. +können einzelne Module mit Userfunctions neu geladen werden oder alle Module mit Userfunctions auf einmal. In der Admin GUI erfolgt das auf der Seite mit dem Editor für Userfunctions. Alternativ können die Module über den **eval Syntax Checker** neu geladen werden. Um die Datei des obigen Beispiels neu zu laden, muss