Logiken in KNX

[mumpf]

Hi Questioner,

auch wenn ich auch glaube, dass Du an einigen Stellen zu kompliziert denkst, so denkst Du an anderen Stellen zu einfach. Du brauchst praktische Erfahrung, am besten mit einem Testbrett. Deine ganzen Statusbetrachtungen und Zustandswechsel kommen aus der Programmierwelt (war bei mir auch so), aber beachten nicht ausreichend die realen Gegebenheiten . Ich meine im Speziellen Latenzen und multiple Zustände.

Beispiel für Latenzen: Du misst beim Beamer den Strom, ob er läuft. Nur weil Du aber den Beamer einschaltest, liefert der Strommessaktor nicht sofort ein EIN. Das dauert eine gewisse Zeit, bis die Messung durch ist und das Signal auf dem Bus ist. In dieser Zwischenzeit weißt Du nicht, ob der Beamer an oder aus ist. Für stabile und zuverlässige Automatisierung brauchst Du Geräte, die nativ über ein EIN oder AUS geschaltet werden können und nicht über eine Toggle-Funktion. Das ist kein KNX-Problem, sondern ein grundsätzliches.

Beispiel für multiple Zustände: Dein Beamer wird eventuell auch eine Nachlaufzeit für die Kühlung haben. Damit der Lüfter nach dem Ausschalten länger läuft und die Lichtquelle entsprechend kühlt. Damit hast Du nicht nur 2 Zustände für den Beamer, sondern mindestens 3. Man muss sich jeweils überlegen, ob der Zwischenzustand eher EIN oder AUS heißt. Und das muss man normalerweise Fall für Fall entscheiden. Weitere Beispiele für multiple Zustände:

• Rolladen: Nicht nur oben oder unten, sondern auch beliebig dazwischen
• Fenster: offen, zu, gekippt (bei Bedarf auch geschlossen/verschlossen)

Vor dem Hintergrund: Ich würde mir ein Testbrett bauen, ein paar Sachen ausprobieren und schauen, welche der theoretischen Überlegungen wirklich in der Praxis eine Rolle spielen.

Gruß, Waldemar

[hjk]

Du hast in den MDT Schaltaktoren bereits eine Logik, wo man z.B. nachts direkt die Klingel sperren kann. Dazu braucht man keine externe Logik. Du kannst alternativ mit Nacht auch den Binäreingnang (Klingelknopf) sperren.
Statt Server reicht bei dir auch z.B. ein MDT Logikmodul. Da gehen deine Logiken auch mit wenn - dann usw.
Da brauchst du auch keine Server lebt noch Überwachung oder sowas.

https://www.mdt.de/fileadmin/user_up...ikmodul_02.pdf

[GLT]

Wenn ein Fenster auf ist und es beginnt zu regnen, will ich ne Meldung

Dass es regnet oder vom Fenster?
Denn...

Wenn ein Fenster aufgemacht wird und es regnet bereits, brauche ich keine Meldung

was passiert, wenn es kurz aufhört u. wieder anfängt - doch eine Meldung oder nicht? Das wäre ein weiterer Fall oder dann doch Fall 1?

Man kann sich verkünsteln, aber baut sich somit auch Fallstricke ein.

[Saeldric]

Zitat von Saeldric Beitrag anzeigen
Das ist unwichtig. Du kannst „Ein“ so oft senden wie Du möchtest, mehr als einmal einschalten geht ja nicht.



Nein, sowohl Beamer, als auch Leinwand und PC haben Taster mit Toggle-Funktion und keine Schalter. Damit ist es nicht egal.

Ich bin davon ausgegangen Du möchtest die Geräte über KNX ein/ausschalten. Dann würde es stimmen.

[lopiuh]

Zum Thema "das Beste aus beiden Welten" (KNX und Server), also:

- dezentral: die Brot und Butter-Funktionen,
- Zentral (Server): das "schöne/nerdige nice to have".

Wie vorgehen, wenn ein und dieselbe Funktion in beiden Welten (in beiden Betriebsmodi) vorhanden sein soll? Beispiel: eine einfache Lüftersteuerung in KNX und eine komplexere per Server. Die dürfen nicht gleichzeitig laufen. Die KNX-Lösung soll aber wieder greifen, wenn der Server nicht regelmäßig sein Signal refreshed oder keep alive ausfällt ... wie vorgehen?

Gruß

lopiuh

[shaolinmaster]

Je nach Spieltrieb könntest du dich auch mit Home Assistant beschäftigen. Da kann man wohl auch Logiken basteln. Ich persönlich nehme den HS, ok..er ist nicht mehr Zeitgemäß, aber damit ist trotzdem fast alles möglich.

[sewi]

Ich fände es ja charmanter, wenn die Logik dann im Schaltaktor wäre, aber gut. Erkläre mal deiner Frau, dass die Klingellogik gerade nicht mehr geht, weil der PM kaputt ist... In meinen Augen holt man sich so noch mehr Fehlerquellen dazu. Ist aber ja mein grundsätzliches "Problem" mit der "Logik" in KNX

Naja oder du nimmst ein Logikmodul eben, dann sollte so schnell nicht ausfallen, und dann ist die Logik auch zentral.
Ich hab mich halt noch nicht durchringen zu können, ein Logikmodul zu kaufen, und verwend mal was ich hab (für Logiken im Raum schaue ich schon, dass ich bei KNX Geräten im jeweiligen Raum bleib)

Wobei ein dezidiertes Logikmodul ja mehr kann als nur UND und ODER.

Wäre es möglich, dass man irgendeinen ungenutzten Kanal irgendeines Gerätes (Schaltaktor, PM, etc.) als "Status" missbraucht, den man dann abfragen kann?

Ja das geht, du kannst auch einen Lichtkanal von einem Bewegungsmelder verwenden, dann schaltet kein Relais
Aber dann hast du wieder eine Logik in einem anderen Gerät, sauberer ist eben ein Logikmodul.

[mumpf]

Die KNX-Lösung soll aber wieder greifen, wenn der Server nicht regelmäßig sein Signal refreshed oder keep alive ausfällt ... wie vorgehen?

Die Grundidee ist einfach: Du sperrst die KNX-Lösung mit einem Treppenlicht. Wenn die Sperre aufgehoben wird, hat der Server das Treppenlicht zu lange nicht nachgetriggert.

Gruß, Waldemar

[maximilianeum]

Hallo,

interessantes Thema, ich finde es beleuchtet ein Grundproblem bzw. Verständnisproblem im Bezug auf KNX sehr gut. KNX ist nicht SMART, KNX ist nur ein Bus. Ich hatte anfangs ebenfalls fälschlicherweise angenommen, die Geräte bieten mehr Freiheiten. Der Idealzustand wäre meiner Meinung nach, wenn ausnahmslos alle Geräte mehrere frei konfigurierbare Kommunikationsobjekte (Typ, Eingang/Ausgang), sowie ein dahinterliegendes Skripting zur Verfügung stellen würden - ähnlich den OpenKNX Modulen.

Unterm Strich gibt es lediglich mehr oder weniger intelligente Geräte die diesen unSMARTen Bus nutzen:

• Sensoren
• Aktoren
• Sonstige (z.B. Logikmodule)

Wer mehr möchte, benötigt eine tatsächlich SMARTe Lösung. Loxone sei hier angemerkt. Hier im Forum wird oft über Loxone gemeckert und beispielsweise die Abhängigkeit zum zentralen Server bemängelt, unterm Strich haben aber die meisten KNX-System ebenfalls diesen einen Point of Failure, wenn sie nicht nur ein völlig unSMARTEs Haus steuern - wofür übrigens auch eine konventionelle Elektrik reicht. Ist ein KNX-basiertes SMART-Home intelligent umgesetzt, funktioniert im Gegensatz zu Loxone aber zumindest noch die Grundfunktionalität.

Ich handhabe es so, wie schon mehrfach beschrieben: Die Geräte zunächst nur als Sensoren und Aktoren betrachten und die Automatikfunktionen soweit möglich mittels Applikation der Geräte zu steuern. Alles was nicht über die Applikation machbar ist entfällt entweder ersatzlos oder wird im zentralen Server gelöst. Eine Dopplung sowohl nativ als auch im Server gibt es nicht.

Zur Inspiration was nativ möglich ist, folgende Dinge konnte ich bislang nur in den KNX-Geräten

• Präsenzmelder: Theben theMura P180 2,20 KNX im Innenbereich
• Präsenzmelder: Steinel sensIQ im Außenbereich
• Taster: Gira Tastsensor 4 Komfort
• Jalousieaktor: MDT JAL
• Dimmaktor: MDT AKD
• Schaltaktor: MDT AKS

umsetzen:

• Automatisches Schalten der Grundbeleuchtung in jedem Raum mittels Bewegungsmelder
• Einschalthelligkeit der Grundbeleuchtung abhängig von der Tageszeit
• Verschiedene Lichtszenen pro Raum abrufbar über Taster
  • Licht aus - wird aufgerufen wenn PM ausschaltet oder manuell ausgeschaltet wird, gibt die temporäre Sperre des PM frei
  • Licht Auto an - wird aufgerufen wenn der PM schaltet
  • Licht an - wird aufgerufen wenn manuell eingeschaltet wird, sperrt den PM temporär
  • Arbeiten - Grundbeleuchtung gedimmt, Schreibtischleuchte 100% und weiß, sperrt den PM temporär
  • Hell - Alle Leuchten 100% und weiß, sperrt den PM temporär
  • Ambiente 1 - Grundbeleuchtung gedimmt, Zusatzbeleuchtung gedimmt und farbig (raumabhängig), sperrt den PM temporär
  • Ambiente 2 - Grundbeleuchtung gedimmt, Zusatzbeleuchtung gedimmt und farbig (raumabhängig), sperrt den PM temporär
  • Nacht - PM Halbautomatik, gibt die temporäre Sperre des PM frei
  • Tag - PM Vollautomatik, gibt die temporäre Sperre des PM frei
  • Auf - Jalousie 0%/0%
  • Transparent - Jalousie 100%/50%
  • Beschattung - Jalousie 100%/75%
  • Ab - Jalousie 100%/100%
• Die temporäre Sperre des PMs wird entweder manuell durch das Ausschalten des Raums (Licht aus Szene) aufgehoben, oder aber nach einer längeren Abwesenheit (deutlich länger als die normale Nachlaufzeit im Automatikmodus). Angezeigt wird die temporäre Sperre am Tastsensor durch eine LED
• Jalousiesteuerung mit Lamellennachführung nach Sonnenstand
• Jalousiesteuerung Tag/Nacht in Abhängigkeit der Helligkeit im Außenbereich und des Tag/Nacht Zustands im Raum
• Lüftungsstellung der Jalousie bei Fensteröffnung inkl. Rückstellung bei Schließen des Fensters
• Manuelles Sperren aller Bewegungsmelder im Haus
• Manuelles Sperren der sonnenstandsgeführten Beschattung im Haus
• Anzeige der Temperatur und Feuchtigkeit je Raum

Die obigen Funktionen und Steuermöglichkeiten decken schon 95% des Familienbedarfs ab. Mehr Automatik führt schnell zu Unfrieden und Frust, weil es einfach zu viele Ausnahmen gibt. Stand heute haben wir nur noch selten Fehlfunktionen, wie ein Licht das fälschlicherweise ausgeht - meist wurde dann einfach vergessen eine Szene aufzurufen um den PM temporär zu sperren. Ab und an ist auch mal eine Übersteuerung der Jalousie nötig, die Kinder wollen z.B. im Dunkeln spielen oder die Sonne blendet doch durch einen Spalt.

Übergeordnet gibt es natürlich weitere hilfreiche aber auch verzichtbare Logiken, gesteuert durch einen Gira X1. Hier eine Auswahl:

• Zeit- und Sonnenauf- bzw. Sonnenuntergangsabhängige Steuerung der Aquariumbeleuchtung
• Wärmepumpenübersteuerung in Abhängigkeit des PV-Ertrags
• Informative Anzeigen wie die Zeitpunkte der letzten Präsenz oder der letzten Fensteröffnung im Raum
• Steuerung eines Velux-Dachfensters mit zeitlichem Rückfall
• Aufruf von TV an/aus Szenen, die Erkennung erfolgt durch Anmeldung des TVs im Heimnetz
• ...

Du solltest es als sportliche Herausforderung sehen die Funktionen durch langes Tüfteln nativ in KNX umzusetzen. Dafür gibt es ein paar Helfer:

• Logikkanäle (UND/ODER/XOR)
• Hörende Gruppenadressen - immer der Status des zuletzt empfangenen Telegrams wird übernommen
• Szenen (Abrufen und Speichern)

Viel Spaß und Erfolg weiterhin!

[willisurf]

Ein schöner Test, nachdem der erste Entwurf real umgesetzt ist:
Einfach mal den Logikserver runterfahren und 1-2 Tage ohne alles laufen lassen. Dann merkt man schon, wo es nicht nur Komfortfunktionen sind, die fehlen.

[gbglace]

Wer mehr möchte, benötigt eine tatsächlich SMARTe Lösung. Loxone sei hier angemerkt. Hier im Forum wird oft über Loxone gemeckert und beispielsweise die Abhängigkeit zum zentralen Server bemängelt, unterm Strich haben aber die meisten KNX-System ebenfalls diesen einen Point of Failure, wenn sie nicht nur ein völlig unSMARTEs Haus steuern - wofür übrigens auch eine konventionelle Elektrik reicht. Ist ein KNX-basiertes SMART-Home intelligent umgesetzt, funktioniert im Gegensatz zu Loxone aber zumindest noch die Grundfunktionalität.

Also den Satz solltest nochmal überarbeiten. Loxone als smarter darzustellen als KNX ist ja schon mehr als erklärungsbedürftig. Im Gleichen Satz aber auch anzumerken das eben bei Loxone ohne deren einzige smarte Komponente gar nichts mehr läuft ist ja schon der klare Widerspruch zur einleitenden Aussage in dem Absatz.

Ansonsten gilt nicht nur für KNX. Kein Bussystem der Welt ist smart, weder die alten KNX, Modbus noch die neuen Matter und Co. Es sind alles nur Kommunikationsprotokolle, was soll daran Smart im Sinne von Abwicklungen von Logiken/Abhängigkeiten sein?

Smart wird es eben nur wie die transportierten Informationen verstanden und bewertet werden. Ob das von den Geräten selbst oder von einem zentralen Kasten passiert. Das ist der eine wesentliche Unterscheid. Und dann enduserbezogen wie baut man in dem einen oder anderen solche smarten Abhängigkeiten. Mit WischWasch Handy Apps oder Skripten oder Parametern oder strengen Modulen der Schaltungselektronik.

Smart sind alle Sachen nur der eine kommt besser mit dem einen der andere kommt besser mit dem anderen klar.

Ansonsten aber gute Beispiele was man KNX nativ alles gut hinbekommt.

Aber ja entweder lässt man sich überraschen was man so nativ alles abwickeln kann
Oder man durchforstet vor dem Einkauf mal die Handbücher und ETS-Applikationen und Foren, bevor man einkaufen geht.

[Questioner]

Erstmal vielen Dank für eure ganzen Antworten!

Ich habe mich nun bewusst mal etwas rausgezogen und mir zum ersten Mal die ETS als Demo installiert. Da habe ich mir mal ein paar Applikationen der von unserem SI gewählten Komponenten angesehen und hatte mir erhofft ein etwas besseres Verständnis zu bekommen. Ich wollte auch ein bisschen mit KNX Virtual rumspielen, leider scheint das bei mir aber nicht zu funktionieren...
Nun ja: Ich bin noch immer auf dem Stand, dass man zwar viel machen kann, aber eben immer im Rahmen der vom Hersteller vorgesehenen Möglichkeiten.

Das mag sicher auch in 95% der Fälle soweit ausreichend sein und weitere 3% der Fälle wären vermutlich den Aufwand nicht wert, den man betreiben müsste.

Aber gerade als ehemaliger Anwendungsentwickler hatte ich mir hier mehr Freiheiten erhofft, mehr Spielwiese zum austoben und mehr "Selbstverwirklichung".

Für den Anfang werde ich mit dem "Bordmitteln" arbeiten (müssen), aber einen Server habe ich auf jeden Fall schon geplant.
Was mich aber immer noch fuchst, ist die Sperrung - in vielerlei Hinsicht...

Ich habe z.B. einen PM und schalte das Licht jetzt manuell aus. Also sperre ich den PM, damit das Licht nicht wieder eingeschaltet wird.
Wie kann ich nun den PM entsperren, wenn X Minuten keine Präsenz detektiert wurde? Ich habe mir dazu mal den MDT SCN-P360D4.02 angeschaut. Da stehen so kryptische Dinge wie "Zwangsführung", was ich mal so verstanden habe, dass der PM für eine vordefinierte Zeit einen vorgegeben Schaltzustand behält. Aber ich habe jetzt keine Einstellung gefunden "Entsperren nach X Minuten".

Die Grundidee ist einfach: Du sperrst die KNX-Lösung mit einem Treppenlicht. Wenn die Sperre aufgehoben wird, hat der Server das Treppenlicht zu lange nicht nachgetriggert.

Für die "Weiche" zwischen KNX-nativ und Server habe ich das jetzt für ein exemplarisches Beispiel so verstanden:
- Der Server sendet regelmäßiig die Gruppenadresse "ich Lebe" und ein KNX-Gerät mit Treppenlicht funktion hört darauf und Schaltet den Kanal "Server an" ein.

Nun drücke ich einen Taster:
Der Taster sendet eine Gruppenadresse "Licht an".
Zwei Logikbausteine (A und B) hören auf die Gruppenadresse "Licht an" und durchlaufen ihre Logik.
A: Wenn "Server an" = EIN, dann sende Gruppenadresse "Licht an Server".
B: Wenn "Server an" = AUS, dann sende Gruppenadresse "Licht an KNX".

Der Server hört auf die Gruppenadresse "Licht an Server" und ein Schaltaktor auf "Licht an KNX".

Ist das so korrekt?
Für einfache 1bit-Datenpunkte mag das so funktionieren, aber wie geht das z.B. mit Dimmwerten? Da müsste das Logikmodul ja den Wert in die gesendete Gruppenadresse übernehmen...

Nur weil Du aber den Beamer einschaltest, liefert der Strommessaktor nicht sofort ein EIN. Das dauert eine gewisse Zeit, bis die Messung durch ist und das Signal auf dem Bus ist.

Ok, das war mir tatsächlich so noch nicht bewusst, wie lange dauert das denn? Aber auch das könnte man ja wieder mit ein wenig eigengestrickter "Logik" abfangen, indem man den Taster nach einschalten für X Sekunden sperrt, bis sicher auch die Detektierung funktioniert.

Für stabile und zuverlässige Automatisierung brauchst Du Geräte, die nativ über ein EIN oder AUS geschaltet werden können und nicht über eine Toggle-Funktion. Das ist kein KNX-Problem, sondern ein grundsätzliches.

Naja, das sehe ich nicht ganz so. Ich muss nur den aktuellen Status kennen und entsprechend steuern. Ist beim Rollladen auch nicht anders. Der Aktor muss den Stand kennen, damit er weiß, wohin und wie weit die Reise gehen soll, wenn ich nicht ganz auf oder ganz zu fahren will.

Mein TV hat z.B. kann ich nur über die Web-API ausschalten, dann schaltet er das IP-Interface immer mit ab (doof). Zum Einschalten bekommt er also ein Signal vom AVR über HDMI und schaltet ein. Würde er im Betriebszustand nochmal ein Signal vom AVR bekommen, würde er auf HDMI wechseln. Also frage ich vorher an, ob der TV über TCP/IP antwortet und wenn nicht gibts das Signal vom AVR. Zum Ausschalten frage ich über TCP/IP an, ob er antwortet und falls ja, gibts den Ausschaltbefehl per Web-API. Ein Knopf auf der App zum Ein- und Ausschalten. Funktioniert seit 5 Jahren hervorragend und auch das IP-Interface braucht ein paar Sekunden, bis es nach dem Einschalten antwortet. Aber bis dahin "bootet" der TV eh noch und reagiert auch auf nichts anderes.

Dein Beamer wird eventuell auch eine Nachlaufzeit für die Kühlung haben. Damit der Lüfter nach dem Ausschalten länger läuft und die Lichtquelle entsprechend kühlt. Damit hast Du nicht nur 2 Zustände für den Beamer, sondern mindestens 3.

Naja, solange der Beamer nachkühlt, ist er nicht aus. Der Beamer ist auch kein Gerät, das man hochfrequent ein- und ausschaltet. Gerade das Einschalten während der Nachkühlphase soll erheblich auch die Lebenszeit gehen und wenn man das macht dröhnen so richtig die Lüfter. Den Beamer also nicht einzuschalten solang er nachkühlt, wäre wohl eher eine Lebensverlängernde Maßnahme.

Ich weiß aber schon worauf Du hinaus willst, aber wie war das bei der Hausautomation: Oft bedarf es eine Kombination mehrerer Sensorwerte um eine Situation korrekt abbilden zu können Zieht der Beamer noch etwas Strom (kann man nicht messen wie viel und daran den Status ermitteln?), reagiert aber nicht auf einen Ping, dann ist er weder an noch aus, so wie ein Rollladen weder oben noch unten.

was passiert, wenn es kurz aufhört u. wieder anfängt - doch eine Meldung oder nicht?

Nein, keine Meldung und kein neuer Fall. Wird das Fenster bei Regen geöffnet wird keine Meldung erzeugt, bis das Fenster wieder geschlossen wird.
Ich habe das Fenster im Regen bewusst geöffnet, kenne also die Situation. Man könnte sich noch Gedanken über mögliche Grenwerte machen, also dass z.B. immer eine Warnung kommen soll, wenn es so richtig Schüttet und/oder wenn der Wind in Richtung Fenster weht... Glaube aber auch nicht, dass ich das vordefinierten KNX-Applikationen abbilden könnte.

Je nach Spieltrieb könntest du dich auch mit Home Assistant beschäftigen.

Angedacht und (für später) eingeplant

Ich hab mich halt noch nicht durchringen zu können, ein Logikmodul zu kaufen, und verwend mal was ich hab (für Logiken im Raum schaue ich schon, dass ich bei KNX Geräten im jeweiligen Raum bleib)

Ist ja klar und sicher auch sinnvoll. Zumal die Dinger nicht gerade günstig sind, für das was sie da leisten können. Ein Smartphone mit deutlich mehr Funktionsumfang gibt's günstiger.

nteressantes Thema, ich finde es beleuchtet ein Grundproblem bzw. Verständnisproblem im Bezug auf KNX sehr gut. KNX ist nicht SMART, KNX ist nur ein Bus.

Ich denke es kommt darauf an, wie man KNX definiert bzw. was man alles dazuzählt. Wenn man KNX jetzt nur seine Technologie begrenzt, dann mag das stimmen und es kommt halt 'drauf an, was man damit macht. In seiner Gesamtheit, also mit den am Markt vorhandenen Komponenten, würde ich KNX dann schon als "smart" betrachten (wollen). Aber das ist wohl eher eine philosophische Frage.

Wer mehr möchte, benötigt eine tatsächlich SMARTe Lösung. Loxone sei hier angemerkt.

Jetzt musst Du mir aber erklären, warum Loxone, das auf dem "dummen" TCP-Protokoll aufbaut, smarter ist als KNX, das auf einem "dummen" KNX-Bus aufbaut.
In beiden Fällen steckt das "Smarte" in den Kommunikationsgeräten und nicht in der Technologie der Datenübertragung. KNX gibt's auch über Netzwerk. Ist es dann smarter?!
Loxone hat für mich gleich zwei erhebliche Nachteile:
1. Wie Du schon geschrieben hast den SPoF. Server weg, alles weg.
2. Es gibt nur den einen Hersteller. - Das sind gleich viele Nachteile zusammengefasst.
Aber darum soll es ja auch gar nicht gehen.

Die temporäre Sperre des PMs wird entweder manuell durch das Ausschalten des Raums (Licht aus Szene) aufgehoben, oder aber nach einer längeren Abwesenheit

Ok, da wird's für mich spannend - Wie hast Du das mit der Abwesenheit umgesetzt?

[gbglace]

Bei dem PM Beispiel musst Dir mal Applikationen zu verschiedenen Herstellern anschauen.

Sperre und Zwangsführung sind Techniken aus der Entstehungszeit des EIB/KNX, diverse Hersteller haben aber erkannt das 30 Jahre später der Bedarf an Funktionalität höher ist. Entsprechend wurden spezielle Funktionen zu manuellen Beeinflussung eingebaut. Bei Busch Jäger und MDT findest in den PM-Applikationen entsprechend passende KO.

Sofern der PM als solcher gut funktioniert ist das mit dem manuellen Taster AN oder AUS kein Thema, dann springt der immer in die Automatik zurück sowie die erfasste Bewegung/Präsenz beendet ist.

Es gibt auch Konzepte für länger anhaltenden manuellen Modus, das nutzt man dann da wo der PM bei der Überwachung selbst schwächelt und fälschlicherweise die Bewegung/Präsenz verliert.
Da lassen sich dann auch Von der Nachlaufzeit des PM Sensors unabhängige Rückfallzeiten in den Automatikmodus hinterlegen.

Bei den klassischen Sperren gehen auch einige Hersteller auf Rückfallzeiten und bieten auch eine Einstellung ob er was senden soll bei Sperre.
Bei MDT aber immer drauf achten was da gesperrt wird, der Sensor oder der genaue Ausgangskanal inkl. Aller interner weiterer Logiken/Abhängigkeiten.

Ich habe in jedem Raum PMs und einige Kanäle darauf laufend sind für die Lichtschaltung, aber davon unabhängig gibt es auch immer einen Kanal der Helligkeitsunabhängig arbeitet und für die Versorgung des Hauses über den Zustand Präsenz/Bewegung in XY. Solche parallele Kanäle mit abweichenden Nachlaufzeiten kann man auch für solche Sperren/Entsperrungem von den Lichtkanälen verwenden.



Die Stromerkennung kann schnell gehen, das kommt darauf an wie gut der Aktor ist und wie sich der StandbyVerbrauch vom Bootvorgang absetzt und wo Du da dann Schwellwerte definiert hast. Richtig deutlich wird es erstw wenn die Lampe brennt und/oder Lüfter anspringen.

Ein ordentlicher Beamer hat aber besser eh ein Interface und wird dann darüber bedient und dann kommt dessen AN/AUS und Funktionshauswahl vom KNX (Taster /Szenen / via Logikserver). Das ist dann die Drittsystemintegration in den KNX.

Das mit den Fenstern und Regen ist in der speziellen Funktion eh etwas für den Server, denn Du bekommst erstmal ein Wanrsinhmal aus den Applikationen, das kann man natürlich bis zum Weg zum Lautsprecher/ Bildschirm auch noch einmal verfeinern, das dann aber eben durch Den Logikserver. Das ist legitim. Und da geht auch nicht viel Funktion verloren wenn der mal ausgesziehen sein sollte. Dann gibt es halt ne Message mehr.

[maximilianeum]

Hallo,

Ok, da wird's für mich spannend - Wie hast Du das mit der Abwesenheit umgesetzt?

das Bedien- und Automatikkonzept hat im Wesentlichen zwei Komponenten. Die manuelle Steuerung und die automatische Steuerung.

Bevor man zur Lösung kommt muss das Problem genau verstanden sein - das Szenario der verlorenen Präsenz. Ab Werk gibt es eine einstellbare Nachlaufzeit im PM um diesem Problem zu begegnen. Die löst das Problem aber nur bedingt. Denn einerseits benötigt man eine lange Nachlaufzeit um auch Ruhephasen zuverlässig zu überbrücken, andererseits möchte man aber nicht, dass das Licht bei Abwesenheit unnötig lange in den Räumen brennt. Diese konkurrierenden Bedingungen lassen sich nicht mit einem einzigen Parameter steuern. Automatisch lassen sie sich tatsächlich gar nicht steuern, lediglich ein perfekter PM ohne diese "Lücke" würde das Problem eliminieren.

Daher muss es ein "Umschalten" zwischen diesen beiden Szenarien geben. Dieses Umschalten soll im Idealfall implizit geschehen, ein "normaler" Hausbewohner soll mit dem Konzept der beiden Szenarien nicht in Berührung kommen.

Mein Ansatz hierfür:
Wann immer jemand auf den Taster im Raum drückt um etwas an der Lichtsituation zu ändern, hat der PM zuvor nicht die Richtige Einstellung hergestellt (kann er auch nicht, woher soll ein PM wissen, dass die Person im Raum nun am Schreibtisch arbeiten möchte, statt nur kurz etwas aus dem Zimmer zu holen). Die Person löst also bewusst eine Handlung aus und damit einen Trigger. Diesen Träger nutze ich um vom Automatikmodus mit kurzer Nachlaufzeit in den Automatikmodus mit langer Laufzeit umzuschalten. Die Person schaltet also das Schreibtischlicht an und damit auch implizit die temporäre Sperre des PMs.

Meine PMs bieten verschiedene Schaltkanäle:

• Lichtkanal 1: Hat einen Ausgang (1 bit) und schaltet ein, wenn sowohl die Helligkeit zu gering ist als auch Bewegung erkannt wird. Ausschalten entsprechend.
• Lichtkanal 2: Ist gekoppelt an Lichtkanal 1, ich kann lediglich eine andere Helligkeitsschwelle hinterlegen, alle anderen Parameter wie Nachlaufzeit usw. werden von Lichtkanal 1 übernommen.
• Mehrere HKL-Kanäle: Sie reagieren helligkeitsunabhängig nur auf Präsenz und haben einstellbare Nachlaufzeiten.
• Einen Präsenzausgang: Dieser Kanal reagiert ebenfalls nur auf Präsenz und dient der Raumüberwachung inkl. Sabotagekontrolle.

Zudem hat der PM sechs Logikmodule mit jeweils 2-4 Eingängen. Die Logikmodule können am Ausgang verschiedene konfigurierbare Datentypen senden, pro Logikmodul sind maximal zwei Kommunikationsobjekte verfügbar. Alle Logikmodule können zudem separat gesperrt werden.

Der PM in jedem Raum fungiert als "Automatik-Controller" mit seinen eingebauten Logikmodulen - für Licht und für die Nachtsteuerung der Jalousie.

Da ich die Lichter per Szene schalte reicht mir das eine Bit des Schaltkanals 1 nicht aus. Daher leite ich das Signal über einen der Logikkanäle und löse entsprechend die EIN/AUS-Szenen aus.

Schalte ich das Licht manuell am Taster, so werden auch Szenen abgerufen und gleichzeitig der Logikkanal oben gesperrt. Schaltet der PM nun aus triggert er zwar seinen Lichtausgang aber das Logikmodul sendet nichts. Sobald ich manuell ausschalte werden die Lichter ausgeschaltet und auch der Logikkanal wieder freigegeben.

Wird nicht manuell ausgeschaltet löst nach einer konfigurierten deutlich längeren Abwesenheit einer der HKL-Kanäle die gleiche Szene aus, welche der Ausschalter am Taster nutzt. Damit werden die Lichter ausgeschaltet und der Logikkanal wieder freigegeben.

Zu Beginn hatte ich überlegt, die Freigabe des Logikkanals ausschließlich nach der langen Nachlaufzeit des HKL-Kanals durchzuführen. Damit wäre auch gewährleistet, dass das Licht ausbleibt wenn der Präsenzmelder im normalen Modus die Präsenz kurz verliert. Allerdings hat diese Lösung einen gravierenden Nachteil. Schaltet man beim Verlassen des Raums das Licht manuell aus, so muss man wirklich lange genug abwesend sein, damit es auch wieder einschaltet, wenn man den Raum betritt. Das ist im Alltag nicht praktikabel, weil die Räume eben oft betreten und verlassen werden und die Bewohner trotzdem die Lichter des Öfteren manuell ausschalten. Das Szenario, dass das Licht ausbleiben soll obwohl es der PM eigentlich aktivieren möchte, gibt es defakto nur theoretisch. Der einzig denkbar häufige Fall ist m.E. die Nachtruhe. Aber dafür gibt es den separaten Nachtmodus, der den PM in den Halbautomatikmodus versetzt

Bottom Line: Ein zweiter Präsenzkanal im PM kümmert sich um das Zurücksetzen der Sperre des Lichtkanals. Die Nachlaufzeit des HKL-Kanals ist deutlich länger als die des Lichtkanals.

Es gibt noch einige Kniffe, die ich beachten musste, aber die sind Geräte- und Anwendungsspezifisch. So konnte ich nicht einfach die "normale" Sperre des Lichtkanals nutzen, da beim Entsperren immer der aktuell Zustand gesendet wird. Damit würde bei Ausschalten und der damit verbundenen Freigabe das Licht sofort wieder anschalten (ist auch logisch korrekt). Ebenso musste ich durch weitere Logiken sicherstellen, dass das Anschalten einer beliebigen Leuchte im Raum dem Präsenzmelder am Eingang für den externen Schalter bekannt gemacht wird (auch wenn z.B. aufgedimmt wird und kein Einschalt-Bit gesetzt wurde), sonst würde er ja nie ausschalten.

Frickellösungen, wie die Erkennung eingeschalteter Geräte (PC, Kochfeld, Backofen, TV) sind zur Präsenzerkennung nicht praktikabel. Bei uns laufen die Arbeitsrechner den ganzen Tag, auch bei Abwesenheit. Ebenso beim Backofen. Der wird eingeschaltet und dann verlässt man schonmal die Küche und kommt erst zurück, wenn er fertig ist.

Viele Grüße

[Questioner]

Vielen Dank für eure sehr ausführliche Antworten! Es hat mir zumindest geholfen mich etwas aktiver damit zu beschäftgen.

Ich habe leider noch immer einen Knoten im Kopf und habe aktuell auch noch keine Ahnung, wie ich den gelöst bekomme bzw. welche Fragen ich stellen muss. Es scheint wirklich an den Grundlagen und teils auch an den Begrifflichkeiten zu hapern. Hätte ich so jetzt nicht erwartet

Leider kann ich es aktuell nicht in der Praxis testen, aber ich habe mir mal die Applikation des MDT SCN-P360D4.02 auseinandergesetzt, da ich davon ausgehe, dass wir sicher (auch) PMs von MDT verbauen werden.
Hier habe ich versucht genau das umzusetzen. Also bei manueller Übersteuerung die Rückführung zur Automation nach 10 Minuten Abwesenheit.
Die Idee:
- Lichtkanal1 einfach für E/A mit etwas Nachlaufzeit
- Wird manuell gesteuert sendet der Taster EIN an die Sperre von Lichtkanal 1.
- Lichtkanal2 sendet nur AUS an die Sperre von Lichtkanal 1 mit der Nachlaufzeit, nach der ohne Anwesenheit der Automatikmodus gestartet werden soll.

Würde das so gehen oder habe ich etwas nicht bedacht? Wenn ich es ausprobieren könnte, wäre ich ja schlauer, aber das ist... kompliziert...

Für was ich noch keine Lösung habe: Der Taster bzw. der Schaltvorgang kann ja nur eine Gruppenadresse feuern und sendet entweder EIN oder AUS. Für die Sperre müsste ich aber immer EIN schicken. Auch bei Werten abseits von 1bit (Dimmwerte, Jalousie, etc.) müsste der Taster neben dem Wert noch ein "EIN" an die Sperre schicken.

Ich denke wenn man das Konzept mal verstanden hat, klappts - aber da habe ich noch irgendwie ne Blockade