KNX und FHEM / Statusrückmeldungen

[jksd]

Hallo
mir ist bewusst, dass pro GA nur ein KO senden kann, jedoch mehrere GA hören können. Folgende Frage ist trotz Lesen diverser Forenbeiträge verblieben:

Szenario: Schalter und FHEM schalten Lichtaktor, Heizungsaktor oder Rolladenaktor.
Hintergrund: SmartVisu ist an FHEM angebunden und steuert parallel zu den KNX-Glastastern von MDT.
Auslösen der Aktion: Sowohl FHEM, als auch jeder einzelne Schalter verwenden als Sender jeweils eine eigene GA zu Ansteuerung des Aktorkanals.

Frage: Wie sieht es jetzt mir der Status-Rückmeldung des Autors aus ? Gilt hier dasselbe, dass in diesem Falle nur eine GA für die Statusrückmeldung angelegt werden darf, auf die dann die Taster, als auch FHEM lauschen (Aktor in diesem Fall als Sender der Status-Rückmeldung) ? Anders ausgedrückt: Nur genau eine GA pro Status-Rückmeldung eines Autor-Kanals ?

Danke für Eure Hilfe !

[mumpf]

Hi,

Nur genau eine GA pro Status-Rückmeldung eines Autor-Kanals ?

einfache Antwort: Ja!

Aber diese Aussage ist falsch:

mir ist bewusst, dass pro GA nur ein KO senden kann

Richtig ist, dass ein KO nur auf die erste GA senden kann.
Ich kann aber durchaus die gleiche GA mehreren KO als erste GA zuordnen, dann senden mehrere KO über die gleiche GA.

Gruß, Waldemar

[Kaffeetrinker]

Hi,
warum verwendet FHEM eine andere GA wie der Taster. Das ist nicht nötig.
Und für die Heizung sendest du doch auch nur den Sollwert oder. Du schaltest ja nicht direkt den Heizungsaktor. Bei mir sieht das so aus

[Kaffeetrinker]

[jksd]

Danke für das erste Feedback.

In folgendem Szenario denke ich, ist es durchaus sinnvoll, unterschiedliche GAs anzulegen:

Schalter 1: 1.1.1 Taste 1: Lampe 1 ein/aus
Taste 2: Alle Lampen ein/aus

Schalter 2: 1.1.2 Taste 1: Lampe 2 ein/aus
Taste 2: Alle Lampen ein/aus

Schaltaktor: 1.1.101 Kanal A: Lampe 1 ein/aus
Kanal B: Lampe 2 ein/aus


GA: 3/0/1: 1.1.1 Taste 1 --> 1.1.101 Kanal A
GA: 3/0/2: 1.1.2 Taste 1 --> 1.1.101 Kanal B

GA: 3/0/10: 1.1.1 Taste 2 --> 1.1.101 Kanal A und
--> 1.1.101 Kanal B

GA: 3/0/20: 1.1.2 Taste 2 --> 1.1.101 Kanal A und
--> 1.1.101 Kanal B

GA: 3/1/1: 1.1.101 Status A --> 1.1.1 Taste 1 Status
GA: 3/1/2: 1.1.101 Status B --> 1.1.2 Taste 1 Status

Die folgende Konstellation (Aktor-zentriert) würde nur für den jeweils ersten Schalter einer KO funktionieren:
GA: 3/0/1: 1.1.1 Taste 1 --> 1.1.101 Kanal A
1.1.1 Taste 2 --> 1.1.101 Kanal A
1.1.2 Taste 2 --> 1.1.101 Kanal A
GA: 3/0/2: 1.1.2 Taste 1 --> 1.1.101 Kanal B
1.1.2 Taste 2 --> 1.1.101 Kanal B
1.1.1 Taste 2 --> 1.1.101 Kanal B

Wenn ich Sender-zentriert modelliere (GA vom Telegramm-Sender ausgehend angelegt), passiert das nicht, da immer nur einer sendet (L-Flag).

=> Das passt zu o.g Antwort zur Status-GA (nur eine GA für die Statusrückmeldung).
=> FHEM würde ich als Sensor/Sender genauso modellieren (obwohl das aus FHEM-Sicht vermutlich nicht notwendig wäre).

Schalter FHEM: 1.1.230

GA: 3/0/11: 1.1.230 Bit 1 --> 1.1.101 Kanal A
GA: 3/0/12: 1.1.230 Bit 1 --> 1.1.101 Kanal B

GA: 3/0/20: 1.1.230 Bit 1 --> 1.1.101 Kanal A und (alle schalten)
--> 1.1.101 Kanal B

Status-Rückmeldungen erweitert (für gemeinsames Schalten hier nicht dargestellt, zus. Logik notwendig):
GA: 3/1/1: 1.1.101 Status A --> 1.1.1 Taste 1 Status
--> 1.1.230 FHEM (1) Status

GA: 3/1/2: 1.1.101 Status B --> 1.1.2 Taste 1 Status
--> 1.1.230 FHEM (2) Status


Spricht etwas dagegen ?

[mumpf]

Hi,

Du modellierst weder Sender-Zentriert (was eigentlich Sensor-Zentriert heißen müsste) noch Aktor-Zentriert, sondern nach der Semantik der Information (also GA-Zentriert).

Um bei Deinem Beispiel zu bleiben: Die 3/0/20 brauchst Du nicht, die ist semantisch gleich der 3/0/10. Die Taste 2 beider Taster bekommt die GA 3/0/10 zugewiesen.


Dein Schalter FHEM: 1.1.230 sieht dann so aus:

GA: 3/0/1: 1.1.230 Bit 1 --> 1.1.101 Kanal A
GA: 3/0/2: 1.1.230 Bit 1 --> 1.1.101 Kanal B

GA: 3/0/10: 1.1.230 Bit 1 --> 1.1.101 Kanal A und (alle schalten)
--> 1.1.101 Kanal B

Status-Rückmeldungen erweitert (für gemeinsames Schalten hier nicht dargestellt, zus. Logik notwendig):
GA: 3/1/1: 1.1.101 Status A --> 1.1.1 Taste 1 Status
--> 1.1.230 FHEM (1) Status

GA: 3/1/2: 1.1.101 Status B --> 1.1.2 Taste 1 Status
--> 1.1.230 FHEM (2) Status

Also 5 GA statt 8, da 3/0/1 = 3/0/11, 3/0/2 = 3/0/12 und 3/0/10 = 3/0/20.

Gruß, Waldemar

[Kaffeetrinker]

Jo.
FHEM hat doch gar keine Physikalische Adresse

[jksd]

Vielen Dank für Eure Rückmeldungen. Hat zum klareren Verständnis sehr beigetragen. Insbesondere die Tatsache, dass FHEM natürlich gar nicht auf irgendwelche Flags reagieren kann und auch mehr als eine GA zum Senden halten kann, hat das Bild viel klarer gemacht.

Die GA 3/0/20 wird trotzdem noch benötigt für den Glastaster 1.1.2 Taste 2 (s.o.).
Bei GA 3/0/11 und 3/0/12 stimme ich zu. Die dienen eher der Dokumentation und sind technischen nicht notwendig - Schaden aber auch nicht.


Grüße !

[mumpf]

Ich kann mich nur selbst zitieren:

Die Taste 2 beider Taster bekommt die GA 3/0/10 zugewiesen.

Irgendwas hast Du noch nicht verstanden, falls Du das anders siehst... Begründe doch mal, warum Du das denkst, dann kommen wir drauf, inwiefern Du anders denkst.

Natürlich kannst Du beliebig viele überflüssige GA definieren und verwenden, macht das Ganze allerdings nicht verständlicher bzw. übersichtlicher. Insofern schaden sie doch.

Gruß, Waldemar

[gbglace]

In ganz kurz jede GA repräsentiert eine Funktion, keinen Aktor keinen Taster, was soll jetzt 3/0/10 für eine andere Funktion sein als 3/0/20, beide machen alle Lampen aus.

Und da beliebige Geräte diese Funktion auslösen können (Taster / PM / Visu / Logik), genügt es auch allen Geräten die diese Funktion auslösen sollen eine GA z.B. 3/0/10 zu verlinken und gut ist es.

Wenn Du auswerten möchtest welches Gerät nun diese Funktion ausgelöst hat dann schaust auf die PA des Senders. Das muss man nun überhaupt nicht in GA's abbilden.

Wie willst Du da noch ne vernünftgie GA Struktur aufbauen und warten wenn jede lampe mit den so üblichen 5 GA's mal von nur einem Taster mal in Anlehnung einer klassischen Kreuzschaltung von 3 Tastern aus bedient werden sollen. Legst dann für jede Lampe 15 GA's an? Bei Dir wären ja mindestens immer 10 notwendig weil ja die Visu immer dein zweiter Taster für alles ist. ( OK die 2 Status GA's von den 5 müssen nicht gedoppelt werden weil das Aktor KO nur auf eine GA den Status senden kann also 11 bzw. 8 in meinen Beispielen).

[jksd]

@Waldemar: Du hast natürlich Recht. War wohl schon zu müde gestern. Danke.
@gbglace: Vielen Dank für deinen Albert Einstein. Du machst hoffentlich nie Fehler in deinem Leben ;-) Trotzdem Danke für den Erklärungsversuch.

[bjoernhim]

jksd zu Erklärung, gbglace hat den Spruch von Einstein in seiner Signatur,
die Signatur kommt bei jedem seiner Beiträge automatisch

[mumpf]

Hi,

nur aus Interesse: Verwendest Du FHEM aus historischen Gründen? Weil Du Dich bereits damit auskennst? Oder weil Du auch viele andere Geräte, für die es bereits eine FHEM-Anbindung gibt, in Dein System integrieren willst?

Ich frage nur, weil meinem Empfinden nach die Integration von KNX in FHEM denkbar schlecht ist, verglichen mit allen anderen FHEM-Devices. Jede GA als FHEM-Objekt zu führen macht die Verwaltung nicht unbedingt einfacher. Die anderen FHEM-Objekte haben wenigstens ihre Attribute, bei der KNX-Anbindung gibt es da nichts. Zumindest war es so, als ich vor ca. 4 Jahren von FHEM weg bin. Ist das neuerdings besser geworden?

Wenn Du den Großteil Deiner Automatisierung über KNX erledigen willst (also das KNX-System das führende ist), würde ich Dir sonst empfehlen, dass Du Dir andere Server-Plattformen anschaust, die KNX besser einbinden.

Gruß, Waldemar

[jksd]

Hallo Waldemar,

ich verwende FHEM seit einigen Jahren mit Homematic, FS20, Sonos, Logitech Hub, Geofencing, AMAD/Text2Speak, .... Bevor ich vor ca 1,5 Jahren mit der Visu auf Smartvisu umgestiegen bin, hatte ich auch FHEM noch einmal infrage gestellt - mit dem Ergebnis, dass es sehr universell nutzbar ist und auch KNX unterstützen wird (-> Neubau im Entstehen).

Ich weiß nicht, wie die FHEM/KNX-Integration früher war - der aktuelle Stand ist (mit Ausnahme der Doku) sehr gut.

Beispiel:

define KNX250 TUL knxd:localhost 1.1.250
attr KNX250 group knxd: KNX-Adresse 1.1.250
attr KNX250 room KNX

# Beispiel: Dimmer
define KNX_DIMM_EG_KUECHE_LICHT_DECKE1 KNX 0/3/5:dpt5.001:dim-val 0/4/5:dpt5.001:dim-status
attr KNX_DIMM_EG_KUECHE_LICHT_DECKE1 IODev KNX250
attr KNX_DIMM_EG_KUECHE_LICHT_DECKE1 group Licht-EG-Kueche
attr KNX_DIMM_EG_KUECHE_LICHT_DECKE1 room KNX
attr KNX_DIMM_EG_KUECHE_LICHT_DECKE1 slider 0,1,100
attr KNX_DIMM_EG_KUECHE_LICHT_DECKE1 webCmd value

################################################## ###########################################
#
# KNX Fensterkontakte
#
# Zwei-flügeliges Fenster:
# =========================
# li-offen-get (true/false): linker Fensterflügel offen (nicht gekippt)
# re-offen-get (true/false): rechter Fensterflügel offen (nicht gekippt)
# li-kipp-get (true/false): linker Fensterflügel gekippt
# re-kipp-get (true/false): rechter Fensterflügel gekippt
# li-status (offen/gekippt/geschlossen): Status linker Fensterflügel als Text
# re-status (offen/gekippt/geschlossen): Status rechter Fensterflügel als Text
# status (offen/gekippt/geschlossen): Höherwertigster Status beider Flügel (Offen->gekippt->geschlossen)
# icon (c|o|t).(c|o|t): Linker und rechter Flügel durch Punkt getrennt (closed, open, tilted). Für Smartvisu-Icon.
#
################################################## ################################################## ##############

define KNX_Fenster_EG_Buero KNX 7/1/4:dpt1.002:li-offen 7/1/5:dpt1.002:li-kipp 7/1/6:dpt1.002:re-offen 7/1/7:dpt1.002:re-kipp
attr KNX_Fenster_EG_Buero IODev KNX250
attr KNX_Fenster_EG_Buero event-on-change-reading li-offen,li-kipp,re-offen,re-kipp,li-status,re-status,status,icon
attr KNX_Fenster_EG_Buero group 'Fenster EG Buero'
attr KNX_Fenster_EG_Buero room KNX
attr KNX_Fenster_EG_Buero userReadings myType {"Window"},\
myFloor {"EG"},\
myTtsName {"Büro-Fenster"},\
li-status { my $myOffen=ReadingsVal("KNX_Fenster_EG_Buero","li-offen-get","ERR");;\
my $myKipp=ReadingsVal("KNX_Fenster_EG_Buero","li-kipp-get","ERR");;\
if ( "$myKipp" eq "true") {"gekippt"} \
elsif ( "$myOffen" eq "true") {"offen"} \
elsif ( "$myOffen" eq "false" && "$myKipp" == "false") {"geschlossen"} \
else { "ERR" }}, \
re-status { my $myOffen=ReadingsVal("KNX_Fenster_EG_Buero","re-offen-get","ERR");;\
my $myKipp=ReadingsVal("KNX_Fenster_EG_Buero","re-kipp-get","ERR");;\
if ( "$myKipp" eq "true") {"gekippt"} \
elsif ( "$myOffen" eq "true") {"offen"} \
elsif ( "$myOffen" eq "false" && "$myKipp" == "false") {"geschlossen"} \
else { "ERR" }}, \
status { my $myLiStatus=ReadingsVal("KNX_Fenster_EG_Buero","li-status","ERR");;\
my $myReStatus=ReadingsVal("KNX_Fenster_EG_Buero","re-status","ERR");;\
if ( "$myLiStatus" eq "offen" || "$myReStatus" eq "offen" ) {"offen"} \
elsif ( "$myLiStatus" eq "gekippt" || "$myReStatus" eq "gekippt" ) {"gekippt"} \
elsif ( "$myLiStatus" eq "geschlossen" && "$myReStatus" eq "geschlossen") {"geschlossen"} \
else { "ERR" }},\
icon { my $string = ReadingsVal("KNX_Fenster_EG_Buero","li-status","ERR") . "." . ReadingsVal("KNX_Fenster_EG_Buero","re-status","ERR");; \
$string =~ s/offen/o/g;; $string =~ s/geschlossen/c/g;; $string =~ s/gekippt/t/g;; return $string }


# myType, myFloor, myTtsName dienen der automatisierten Selektion von Geräten, wie auch der Sprachausgabe.
# In Perl offene Fenster einfach gefiltert in Array überführen mit:
@myDevsO = devspec2array("TYPE=KNX:FILTER=myFloor=$myFloor:FI LTER=myType=$myType:FILTER=status=offen");
$myNumDevsO = scalar @myDevsO;

Gerade die zusätzliche Erweiterung um Perl-Funktionen schafft einen echten günstigen HomeServer. InVerbindung mit einem 24" Wandpanel top.
Wenn Du mehr Beispiele haben möchtest, gerne.

Grüße
Jörk