Realisierung von Status im KNX

[mode]

Hallo,

mein KNX Bus wird von Woche zu Woche smarter. Bisher konnte ich fast komplett auf zentrale Logik verzichten.
Nun bin ich an einem Punkt wo ich diese aber wohl benötigen werde.

Wenn ich das Haus verlasse, möchte ich z.B. das folgendes passiert:
- Check ob alle Fenster geschlossen sind
- Check ob PC im Arbeitszimmer aus ist
- Alle Lichter aus
- Rollläden in Abhänigikeit von Außenhelligkeit und im Winter ggfs sogar Temperatur steuern
- Heizung Nachtmodus
- Einige Steckdosen aus
- Benachrichtung auf Handy wenn Fenster in Abwesenheit geöffnet oder Präsenz im Haus erkannt wird
- /Liste beliebig weiterführbar/


Komme ich wieder nach Hause, so sollen ebenso einige Events wie oben beispielhaft beschrieben ausgeführt werden.

Vorerst wird Kommen und Gehen durch einen KNX Taster an der Tür - später durch einen Fingerprintsensor auf den Bus gesendet.

Meine Fragen.
Wie setzt ihr dieses Senden von Kommen, Gehen etc um?
Mit einer GA in der ja nach Event eine Szenennummer für Kommen und Gehen auf den Bus gesendet wird?
Oder mit je einer GA für kommen, einer für gehen etc (Taster sendet dann immer nur eine 1 bei Betätigung)

Und dann weiter, die Auswertung dieser Statusänderungen müssen dann von einer zentralen Instanz erkannt und verarbeitet werden, die dann Lichter schaltet, Heizung runterregelt etc.

Dafür hatte ich linknx im Auge. Oder gibt es da passendere Alternativen oder gar ganz andere Herangehensweisen?


VG

mode

[Dragonos2000]

Ich habe mir eine "Zustands"-GA für An-/Abweseneit definiert, die ich dann mit 0 oder 1 beschreibe. Dies geschieht entweder manuell über Taster als auch via PM.
In dieser Zustands-GA sind dann entweder die relevanten KO's der Aktoren oder es werden weitere Szenen- oder Schalttelegramme ausgelöst, um die Aktoren in die gewünschten Zustände zu bringen.
Weitere GAs für Zustände habe ich dann z.B. noch für "Sleepmode", "Tag/Nacht", usw.

[fireblade]

Ich habe das auch mit einer "Gehen"-GA gelöst, die ich manuell auf 1 setze (und auf 0 beim wiederkommen). Was beim Betätigen geschieht, realisiere ich mit einen eibPC.
Analoge GAs habe ich momentan auch für "Schlafen" oder "Duschen".

[gindler]

Hi,

In dieser Zustands-GA sind dann entweder die relevanten KO's der Aktoren oder es werden weitere Szenen- oder Schalttelegramme ausgelöst, um die Aktoren in die gewünschten Zustände zu bringen.

Wenn du "abwesend=1" mit z.B. Aktorkanal der Beleuchtung verbindest, musst du den Wert ja irgendwie invertieren, oder? Sonst schaltet die 1 die Leuchte ja ein statt aus. Machst du das dann über Szenen oder wie sonst?

[Dragonos2000]

Hi,

anfangs hab ich den Wert als "Anwesend" definiert, also Anwesend=1 und Abwesend=0. Mit wachsender Installation und Logik habe ich dann aber tatsächlich auch den ein oder anderen invertierten Wert gebraucht. Anfangs war der Bedarf nur bei Logik-Verknüpfungen, so dass ich dann einfach den Eingang der Logik entsprechend invertiert hab- irgendwann bekommst da aber nen Knoten ins Hirn
Inzwischen ist es so, dass ich in der Tat die Zustands GAs konsequent jeweils normal und als invertierte Version habe und die KOs dann entsprechend reinschiebe. Ist so viel übersichtlicher.

Die Bezeichnungen beinhalten auch die Definition:
0/0/2 = State Home (1) / Away (0)
0/0/3 = State Inverted Home (0) / Away (1)

[nbkhollow]

Hi,

Inzwischen ist es so, dass ich in der Tat die Zustands GAs konsequent jeweils normal und als invertierte Version habe und die KOs dann entsprechend reinschiebe. Ist so viel übersichtlicher.

Die Bezeichnungen beinhalten auch die Definition:
0/0/2 = State Home (1) / Away (0)
0/0/3 = State Inverted Home (0) / Away (1)

Hallo Zusammen,

verstehe ich das richtig, dass du dann eigentlich ohne Logik arbeitest und nur die entsprechenden KO´s in zu den GA´s für den aktuellen Zustand hinzufügst?

Gruß Andreas

[Dragonos2000]

Hi Andreas,

jaein Jetzt hol' ich mal etwas weiter aus:
Ich habe die Zustände definiert, um Komplexität aus der "Problemstellung" zu nehmen:
A) Ein Teil des Problems sind die Aktionen, die von den Zuständen ausgelöst werden.
B) Der andere Teil ist das setzen dieser Zustände.
Die Zustände selbst können auch manuell gesetzt werden, so daß A) unabhängig von B) angegangen werden kann.

Eine gewisse Basisfunktionalität ist über das Hinzufügen der KOs zu den Zuständen implementiert, sowie ein bischen Logik, die sich noch sinnvoll mit Logikgattern implementieren lässt- z.B:
- Wenn Terrassentür offen, dann Rolladen auffahren und sperren. Wenn gekippt keine Reaktion.
- Wenn Fernseher an und Sonne, dann Rolladen schließen
- etc.

Die invertierten GAs für die Zustände habe ich eingefügt, weil es dann einfacher "lesbar" wird. Denn bei Negierungen an Ein- und Ausgängen von KOs hab ich dann irgendwann keine Lust mehr drüber nachzudenken Dazu lassen es nicht alle Komponenten zu, wahr/falsch einfach per Parameter umzudrehen.

Die richtigen Komfortfunktionen verbergen sich dann im Wesentlichen im geschickten setzen und verknüpfen der Zustände. Das implementiere ich dann on Top mit ner richtigen Logikmaschine (derzeit im Aufbau mit Fhem, zukünftig EibPC).

Mit diesem Ansatz habe ich, wie gesagt, das Ganze in 2 Teilprobleme zerlegt, eine Grundfunktionalität mit einfacher Logik ist stets gegeben und durch manuelles ändern der Zustände kann, ohne viel nachzudenken, weitreichend eingegriffen werden.

Hoffe das war einigermaßen verständlich rübergebracht

Gruss
Jochen.

[nbkhollow]

Hi Andreas,

Hoffe das war einigermaßen verständlich rübergebracht

Ich glaube ich verstehe so einigermaßen was du meinst

Aber das wird in den nächsten Tagen besser, heute kommt mein Loxone und dann kann ich mich mit den ganzen sachen spielen...


Gruß

Andreas