Geschätzte Freunde der KNX-Beschattungssteuerung,
ich bin, im Zusammenhang mit einer sehr minimalischen Umsetzung eines Hitzeschutzes, über ein mich mich unerwartetes Verhalten vom MDT Rolladenaktor gestolpert.
Eigentlich sollte es ganz einfach sein: Der letzte Befehl gewinnt, wie in KNX üblich. Auf dieser Basis sollte eine möglichst effiziente und fehlertolerante statische Beschattung umgesetzt werden. Wenn beim morgendlichen Hochfahren (relativer Fahrbefehl „aufwärts“) die Bedingung (Temperaturschwelle) für einen heißen Tag erfüllt ist, so wird unmittelbar ein absoluter Fahrbefehl (im Beispiel mit Position 80%) nachgesendet. Der nachgesendete Fahrbefehl ist i.d.R. schon das nächste Telegramm auf dem Bus, kommt also lange vor erreichen der neuen Zielposition; manuell nachgestellt mit größerer Verzögerung zeigt allerdings das selbe Verhalten.
Es soll also entweder die obere Endposition (=0%) oder eine feste Beschattungsposition (=80%) angefahren werden. Das funktioniert auch, aber bei nachgesendeter Position erfolgt zunächst eine komplette Aufwärtsfahrt, Umkehrpause und erst danach wird die Position 80% angefahren. Genau dieser Umweg sollte eigentlich vermieden werden und dürfte nach meiner Erwartung nicht auftreten.
Zur besseren Übersicht habe ich das mal in tabellarischer und grafischer Form zusammengestellt:
Verhalten_Rolladen_Aktor__bei_kombinierten_relativen_und_absoluten_Fahrbefehlen.png
Im Handbuch habe ich keine Hinweis auf da beobachtete Verhalten gefunden, wobei ich nicht ausschließen kann ggf. nach den falschen Stichwörtern gesucht zu haben. Mit dem MDT-Support hatte ich schon zwei mal kurz telefonischen Kontakt. Hatte zuerst den Hinweis bekommen, dass die Zentralsteuerung eine höhere Priorität hätte (das relative Fahren erfolgte zentral, die absolute Position individuell) und darauf hin auf die Nutzung der zentralen Objekte verzichtet. Konnte hier jedoch keinen Unterschied festmachen. Beim zweiten Kontakt wurde darauf hingewiesen, dass das Verhalten der Rolladenaktoren durch die integrierte Beschattungssteuerung „kompliziert“ ist und sich evtl. das Vorhaben auch direkt mit der – bislang ungenutzten – Funktion zur Automatischen Beschattung umsetzen ließe. Basierend auf der Dokumentation ist für mich jedoch nicht klar, wie sich eine solches einfaches Szenario umsetzen lässt. Es soll keine automatisches Verfahren stattfinden und je nach Umgebungsbedingungen entweder direkt auf 0% oder 80% gefahren werden, auch wenn die externe Bedingung Hitzetag ja/nein nicht eingeht. Da ich das ganze für eine schriftliche Anfrage sowieso auch noch mal genauer beschreiben müsste, stelle ich es nun erst mal hier zur Diskussion.
Vielen Dank fürs Lesen und erst mal ein schönes Wochenende
ich bin, im Zusammenhang mit einer sehr minimalischen Umsetzung eines Hitzeschutzes, über ein mich mich unerwartetes Verhalten vom MDT Rolladenaktor gestolpert.
Eigentlich sollte es ganz einfach sein: Der letzte Befehl gewinnt, wie in KNX üblich. Auf dieser Basis sollte eine möglichst effiziente und fehlertolerante statische Beschattung umgesetzt werden. Wenn beim morgendlichen Hochfahren (relativer Fahrbefehl „aufwärts“) die Bedingung (Temperaturschwelle) für einen heißen Tag erfüllt ist, so wird unmittelbar ein absoluter Fahrbefehl (im Beispiel mit Position 80%) nachgesendet. Der nachgesendete Fahrbefehl ist i.d.R. schon das nächste Telegramm auf dem Bus, kommt also lange vor erreichen der neuen Zielposition; manuell nachgestellt mit größerer Verzögerung zeigt allerdings das selbe Verhalten.
Es soll also entweder die obere Endposition (=0%) oder eine feste Beschattungsposition (=80%) angefahren werden. Das funktioniert auch, aber bei nachgesendeter Position erfolgt zunächst eine komplette Aufwärtsfahrt, Umkehrpause und erst danach wird die Position 80% angefahren. Genau dieser Umweg sollte eigentlich vermieden werden und dürfte nach meiner Erwartung nicht auftreten.
Zur besseren Übersicht habe ich das mal in tabellarischer und grafischer Form zusammengestellt:
| Ablauf ohne Hitzeschutz | Verhalten Aktor ohne Hitzeschutz |
Abweichung bei Hitzeschutz | Verhalten Aktor mit Hitzeschutz (SOLL) |
Verhalten Aktor mit Hitzeschutz (IST) |
| vorher: Position == 100% | ||||
| Befehl := Verfahren hoch |
||||
| Befehl := Pos 80% anfahren |
||||
| Zustandsänderung: Position == 100% .. 0% (monton fallend!) |
Zustandsänderung: Position == 100% .. 80% (monton fallend!) |
Zustandsänderung: Position == 100% .. 0% (monton fallend) |
||
| Umkehrpause | ||||
| Zustandsänderung: Position == 0% .. 80% (monton steigend) |
||||
| nachher: Position == 0% | nachher: Position == 80% | nachher: Position == 80% |
Im Handbuch habe ich keine Hinweis auf da beobachtete Verhalten gefunden, wobei ich nicht ausschließen kann ggf. nach den falschen Stichwörtern gesucht zu haben. Mit dem MDT-Support hatte ich schon zwei mal kurz telefonischen Kontakt. Hatte zuerst den Hinweis bekommen, dass die Zentralsteuerung eine höhere Priorität hätte (das relative Fahren erfolgte zentral, die absolute Position individuell) und darauf hin auf die Nutzung der zentralen Objekte verzichtet. Konnte hier jedoch keinen Unterschied festmachen. Beim zweiten Kontakt wurde darauf hingewiesen, dass das Verhalten der Rolladenaktoren durch die integrierte Beschattungssteuerung „kompliziert“ ist und sich evtl. das Vorhaben auch direkt mit der – bislang ungenutzten – Funktion zur Automatischen Beschattung umsetzen ließe. Basierend auf der Dokumentation ist für mich jedoch nicht klar, wie sich eine solches einfaches Szenario umsetzen lässt. Es soll keine automatisches Verfahren stattfinden und je nach Umgebungsbedingungen entweder direkt auf 0% oder 80% gefahren werden, auch wenn die externe Bedingung Hitzetag ja/nein nicht eingeht. Da ich das ganze für eine schriftliche Anfrage sowieso auch noch mal genauer beschreiben müsste, stelle ich es nun erst mal hier zur Diskussion.
- Bin ich zu Recht von diesem Verhalten überrascht?
- Welche Alternativen gäbe es noch zur (robusten) Umsetzung? Umstellung des automatischen täglichen Hoch-/Herunterfahrens auf 0%/100% ist nicht so ohne weiteres möglich...
Vielen Dank fürs Lesen und erst mal ein schönes Wochenende
Kommentar