KNX Device Definition - Beispiele

Vorwort

Hier soll mit eine Austausch von funktionierenden Beispielen aus dem KNX Bereich stattfinden. Es geht um die Definition, und um die Weiterverarbeitung mittels notify, doif, usw.

Viele Anfragen im Forum beziehen sich auf Probleme bei der Definition und "Weiterverarbeitung" von KNX-Geräten. Alle User sind eingeladen, mit weiteren Beispielen mitzuwirken. Im ersten Schritt werden einige Beispiele aus der Command-Ref hierher übertragen, auch um die Command-Ref (in einem zweiten Schritt) etwas kompakter zu gestalten.

Definition - Syntax

define <name> KNX <group>:<dpt>[:[gadName]:[set|get|listenonly]:[nosuffix]] [<group>:<dpt> ..] [<group>:<dpt> ..]

Wie in FHEM üblich, alles was hier zwischen <...> dargestellt ist, sind mandatory Angaben! Optionales wird zwischen [...] dargestellt.

Detaillierte Beschreibung: siehe cmd-ref.

Beispiele

Einfaches on/off Device

define Lampe KNX 0/10/11:dpt1

Einfachstes KNX-Device ohne Alias und Rückmeldung.

on/off Device mit Rückmeldung

define Lampe KNX 0/10/11:dpt1:EinAus 0/10/12:dpt1:Status:listenonly
attr Lampe webcmd EinAus-get
attr Lampe devStateIcon on::off off::on

Hier gibt es 2 GA-Addressen, eine zum Schalten und die 2te für die Rückmeldung vom Aktor (muß natürlich via ETS so programmiert sein!).

Zusätzlich hat jede GA-Addresse nun einen Alias (=gadName), z.B. EinAus, Status. Das Attr webcmd erzeugt ein Pulldown Menue die die jeweilige Funktion ausführen. DevStateIcon hat den Sinn, damit Icons den Zustand darstellen und beim draufklicken die jeweilige Funktion ausführen. Die listenonly Option verhindert, dass ein Set oder Get Cmd im FHEMWeb dargestellt wird. - Set oder Get sind auf diesen Alias dann nicht möglich!

Definition eines Sliders

define Slider_Test KNX 15/2/2:dpt5:Position
attr Slider_Test webCmd Position
attr Slider_Test widgetOverride Position-set:slider,0,5,100

Definition eines Sliders mit Rückmeldung

define Slider2_Test KNX 15/2/2:dpt5.001:Position:set:nosuffix 15/2/3:dpt5.001:PosStatus:get:nosuffix
attr Slider2_Test stateCmd { fhem "sleep 0.05 quiet;; setreading $name Position $state" if ($gadName eq 'PosStatus');; return $state;; }
attr Slider2_Test webCmd Position
attr Slider2_Test widgetOverride Position:slider,0,5,100

Das Attr stateCmd setzt den Wert der vom Aktor kommt - zusätzlich in das reading 'Position', damit der Slider immer auch die aktuelle Position anzeigt. Die doppelten semicolons sind aus parsing Gründen nötig. Falls man das Atrribut über Device-Detail-view setzt, sind nur einfache ; nötig!

Zeit und Datum

define timedev KNX 0/0/7:dpt10:time 0/0/8:dpt11:date 0/0/9:dpt19:datetime

Hier sind alle Varianten von Zeit / Datum dargestellt. Die Empfänger müssen den jeweilgen DPT natürlich unterstützen! die entsprechenden set-cmd's lauten:

# setze das Datum auf den Bus:
set timedev date now
set timedev date 01.11.2021

# setze die Zeit auf den Bus:
set timedev time now
set timedev time 18:33:44

# setze Datum und Zeit (gleichzeitig) auf den Bus:
set timedev datetime now
set timedev datetime 01.11.2020_18:33:44

DPT nicht unterstützt im KNX Modul ?

Im KNX-Modul sind (fast) alle DPT's unterstützt, die in den frei verfügbaren Standard-Dokumenten definiert sind. Hersteller definieren manchmal eigene sub-DPT's, die dann möglicherweise nicht unmittelbar unterstützt sind.

Im wesentlichen unterscheiden sich die sub-DPT's z.B. dpt9.020 von den "Haupt-DPT's" z.B. dpt9 durch die angefügte Einheit, den min/max Werte-Bereich, die Skalierung oder einen Offset. Falls also ein Gerät eine 2Byte-float Wert senden will, dann könnte das so aussehen:

define dpt9test KNX 0/4/6:dpt9
attr dpt9test format g/m³ # gramm / m³

und schon steht die richtige Einheit dahinter... Oder Skalierung - Watt -> kW:

attr dpt9test stateCmd { return sprintf("%.3f kW",$state / 1000); }

Falsch definierte DPT's (z.B: dpt5 statt dpt7) produzieren falsche Ergebnisse, sowohl in FHEM als auch im KNX Device!