KNX Device Definition - Beispiele: Unterschied zwischen den Versionen
KKeine Bearbeitungszusammenfassung |
|||
Zeile 13: | Zeile 13: | ||
=== Beispiele === | === Beispiele === | ||
==== | ==== on/off Device - einfach ==== | ||
<syntaxhighlight lang="text"> | <syntaxhighlight lang="text"> | ||
define Lampe KNX 0/10/11:dpt1 | define Lampe KNX 0/10/11:dpt1 | ||
</syntaxhighlight>Einfachstes KNX-Device ohne Alias und Rückmeldung. | </syntaxhighlight>Einfachstes KNX-Device ohne Alias und Rückmeldung. | ||
==== on/off Device mit Rückmeldung ==== | ==== on/off Device - mit Rückmeldung ==== | ||
<syntaxhighlight lang="text"> | <syntaxhighlight lang="text"> | ||
define Lampe KNX 0/10/11:dpt1:EinAus 0/10/12:dpt1:Status:listenonly | define Lampe KNX 0/10/11:dpt1:EinAus 0/10/12:dpt1:Status:listenonly | ||
Zeile 27: | Zeile 27: | ||
Zusätzlich hat jede GA-Adresse nun einen Alias (=gadName), z.B. EinAus, Status. Das Attr webcmd erzeugt ein Pulldown Menü 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! | Zusätzlich hat jede GA-Adresse nun einen Alias (=gadName), z.B. EinAus, Status. Das Attr webcmd erzeugt ein Pulldown Menü 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! | ||
==== | ==== Slider - einfach ==== | ||
<syntaxhighlight lang="text"> | <syntaxhighlight lang="text"> | ||
define Slider_Test KNX 15/2/2:dpt5:Position | define Slider_Test KNX 15/2/2:dpt5:Position | ||
Zeile 34: | Zeile 34: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
==== | ==== Slider - mit Rückmeldung ==== | ||
<syntaxhighlight lang="text"> | <syntaxhighlight lang="text"> | ||
define Slider2_Test KNX 15/2/2:dpt5.001:Position:set:nosuffix 15/2/3:dpt5.001:PosStatus:get:nosuffix | define Slider2_Test KNX 15/2/2:dpt5.001:Position:set:nosuffix 15/2/3:dpt5.001:PosStatus:get:nosuffix | ||
Zeile 66: | Zeile 66: | ||
</syntaxhighlight>Die entsprechenden set-cmd's lauten:<syntaxhighlight lang="text"> | </syntaxhighlight>Die entsprechenden set-cmd's lauten:<syntaxhighlight lang="text"> | ||
set textdev txt AbCdEfGhIjkLmN # send text to Bus (max 14 Char.) | set textdev txt AbCdEfGhIjkLmN # send text to Bus (max 14 Char.) | ||
set textdev | set textdev txt >CLR< # delete text on the KNX display | ||
</syntaxhighlight> | </syntaxhighlight> | ||
==== Slider mit Rückmeldung '''und Wert Umrechnung''' ==== | ==== Slider - mit Rückmeldung '''und Wert Umrechnung''' ==== | ||
Ein komplexer Fall, wo ein Hersteller zwar den dpt5 verwendet, aber sein "eigenes Zahlen-Format" implementiert hat. Konkret geht's um eine Lüftungsanlage, | Ein komplexer Fall, wo ein Hersteller zwar den dpt5 verwendet, aber sein "eigenes Zahlen-Format" implementiert hat. Konkret geht's um eine Lüftungsanlage, die Stufen 0 (=Aus) bis 8 (=Maximum) verwendet. Am Bus kommen / werden erwartet die folgenden Werte:<syntaxhighlight lang="text"> | ||
0 (Aus)->0, 1->31, 2->63, 3->95, ... , 8->255 | 0 (Aus)->0, 1->31, 2->63, 3->95, ... , 8->255 | ||
</syntaxhighlight>Im FHEM-Web sollen aber die Stufen 0-8 verwendet werden.<syntaxhighlight lang="text"> | </syntaxhighlight>Im FHEM-Web sollen aber die Stufen 0-8 verwendet werden.<syntaxhighlight lang="text"> | ||
Zeile 94: | Zeile 94: | ||
attr KNXSlidertest webCmd Aus:Ein:StufeSoll | attr KNXSlidertest webCmd Aus:Ein:StufeSoll | ||
attr KNXSlidertest widgetOverride StufeSoll:slider,0,1,8 | attr KNXSlidertest widgetOverride StufeSoll:slider,0,1,8 | ||
</syntaxhighlight>Ankommende Messages (von Alias StufeIst) werden wie üblich im reading "StufeIst" (Werte: 0-255) gespeichert und '''zusätzlich''' umgerechnet und im reading "StufeSoll" (Wert: 0-8) gespeichert. Ein cmd vom User wird umgerechnet und auf den Bus gesendet. Zusätzlich gibt's noch die Schaltflächen "Ein" und "Aus" , diese Werde mittels | </syntaxhighlight>Ankommende Messages (von Alias StufeIst) werden wie üblich im reading "StufeIst" (Werte: 0-255) gespeichert und '''zusätzlich''' umgerechnet und im reading "StufeSoll" (Wert: 0-8) gespeichert. Ein cmd vom User (Werte: 0-8) wird umgerechnet und auf den Bus gesendet. Zusätzlich gibt's noch die Schaltflächen "Ein" und "Aus" , diese Werde mittels eventMap auf Stufe 3 bzw. Stufe 0(=off) umrechnet. | ||
==== DPT nicht unterstützt im KNX Modul ? ==== | ==== DPT nicht unterstützt im KNX Modul ? ==== | ||
Zeile 109: | Zeile 109: | ||
Die meisten dieser Beispiele sind mittels "exportdevice <name>" erstellt. Bei der Übernahme mit c&p in die FHEM- commandozeile (oder auch Telnet) gibt's Fallstricke...(Es müssen Semicolons u. Zeilenumbrüche maskiert werden). Um das zu umgehen, schlage ich folgenden Vorgangsweise vor: | Die meisten dieser Beispiele sind mittels "exportdevice <name>" erstellt. Bei der Übernahme mit c&p in die FHEM- commandozeile (oder auch Telnet) gibt's Fallstricke...(Es müssen Semicolons u. Zeilenumbrüche maskiert werden). Um das zu umgehen, schlage ich folgenden Vorgangsweise vor: | ||
Definiere | Definiere z.b. ein (kompliziertes) Attr stateCmd auf der FHEM-cmd Zeile:<syntaxhighlight lang="text"> | ||
attr meinDevice stateCmd {} | attr meinDevice stateCmd {} | ||
</syntaxhighlight>... also mit nichts drin! - Damit kann's auch keine syntax-Fehler geben! Danach geht man in den device-detail-View, klickt auf statecmd und mit c&p wird der code zwischen den (äussersten {} ) eingefügt. Selbes Vorgehen gilt auch für komplexe DevstateIcon, notifies, at,... Noch grössere code Teile sind | </syntaxhighlight>... also mit nichts drin! - Damit kann's auch keine syntax-Fehler geben! Danach geht man in den device-detail-View, klickt auf statecmd und mit c&p wird der code zwischen den (äussersten {} ) eingefügt. Selbes Vorgehen gilt auch für komplexe DevstateIcon, notifies, at,... Noch grössere code Teile sind sinnvoller in einer sub-routine in 99_myUtils.pm aufgehoben und werden z.b. im stateCmd aufgerufen:<syntaxhighlight lang="text"> | ||
attr <meinDevice> stateCmd { $state = meineAllerwichtigsteSubroutine(p1,p2,p3); } | attr <meinDevice> stateCmd { $state = meineAllerwichtigsteSubroutine(p1,p2,p3); } | ||
</syntaxhighlight> | </syntaxhighlight>Das hat dann auch den Vorteil, dass die sub-Routine von mehreren devices verwendet werden kann! | ||
[[Kategorie:Examples]] | [[Kategorie:Examples]] | ||
[[Kategorie:EIB/KNX]] | [[Kategorie:EIB/KNX]] |
Version vom 23. September 2021, 13:53 Uhr
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
on/off Device - einfach
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-Adressen, 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-Adresse nun einen Alias (=gadName), z.B. EinAus, Status. Das Attr webcmd erzeugt ein Pulldown Menü 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!
Slider - einfach
define Slider_Test KNX 15/2/2:dpt5:Position
attr Slider_Test webCmd Position
attr Slider_Test widgetOverride Position-set:slider,0,5,100
Slider - 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 Attribut ü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 jeweiligen 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
Text senden / empfangen
define textdev KNX 0/0/9:dpt16:txt
Die entsprechenden set-cmd's lauten:
set textdev txt AbCdEfGhIjkLmN # send text to Bus (max 14 Char.)
set textdev txt >CLR< # delete text on the KNX display
Slider - mit Rückmeldung und Wert Umrechnung
Ein komplexer Fall, wo ein Hersteller zwar den dpt5 verwendet, aber sein "eigenes Zahlen-Format" implementiert hat. Konkret geht's um eine Lüftungsanlage, die Stufen 0 (=Aus) bis 8 (=Maximum) verwendet. Am Bus kommen / werden erwartet die folgenden Werte:
0 (Aus)->0, 1->31, 2->63, 3->95, ... , 8->255
Im FHEM-Web sollen aber die Stufen 0-8 verwendet werden.
define KNXSlidertest KNX 11/1/18:dpt5:StufeSoll:set:nosuffix 11/1/20:dpt5:StufeIst:get:nosuffix
attr KNXSlidertest eventMap /StufeSoll 0:Aus/StufeSoll 3:Ein/
attr KNXSlidertest stateCmd { ($state,undef) = split(/\s/ix,$state);
if ($gadName eq 'StufeIst') {
$state = int(($state + 1) / 32);
fhem ("sleep 0.1;setreading $name StufeSoll $state");
}
if ($gadName eq 'StufeSoll') {
if (($state <= 8) && ($state > 0) ) {
my $cstate = ($state * 32) - 1;
fhem ("sleep 0.1;set $name StufeSoll $cstate");
fhem ("sleep 1.0;setreading $name StufeSoll $state");
}
else {
$state = int(($state + 1) / 32);
}
}
return $state;
}
attr KNXSlidertest webCmd Aus:Ein:StufeSoll
attr KNXSlidertest widgetOverride StufeSoll:slider,0,1,8
Ankommende Messages (von Alias StufeIst) werden wie üblich im reading "StufeIst" (Werte: 0-255) gespeichert und zusätzlich umgerechnet und im reading "StufeSoll" (Wert: 0-8) gespeichert. Ein cmd vom User (Werte: 0-8) wird umgerechnet und auf den Bus gesendet. Zusätzlich gibt's noch die Schaltflächen "Ein" und "Aus" , diese Werde mittels eventMap auf Stufe 3 bzw. Stufe 0(=off) umrechnet.
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!
Übernehmen dieser Beisiele in die eigene config
Die meisten dieser Beispiele sind mittels "exportdevice <name>" erstellt. Bei der Übernahme mit c&p in die FHEM- commandozeile (oder auch Telnet) gibt's Fallstricke...(Es müssen Semicolons u. Zeilenumbrüche maskiert werden). Um das zu umgehen, schlage ich folgenden Vorgangsweise vor:
Definiere z.b. ein (kompliziertes) Attr stateCmd auf der FHEM-cmd Zeile:
attr meinDevice stateCmd {}
... also mit nichts drin! - Damit kann's auch keine syntax-Fehler geben! Danach geht man in den device-detail-View, klickt auf statecmd und mit c&p wird der code zwischen den (äussersten {} ) eingefügt. Selbes Vorgehen gilt auch für komplexe DevstateIcon, notifies, at,... Noch grössere code Teile sind sinnvoller in einer sub-routine in 99_myUtils.pm aufgehoben und werden z.b. im stateCmd aufgerufen:
attr <meinDevice> stateCmd { $state = meineAllerwichtigsteSubroutine(p1,p2,p3); }
Das hat dann auch den Vorteil, dass die sub-Routine von mehreren devices verwendet werden kann!