Ausgangssituation:
Meine Rollladen funktionieren weitgehend vollautomatisch. Trotzdem hab ich eine Taste je Rollo um auch manuell steuern zu können.
Für alle Rollotasten gilt KNX-nativ:
- ein kurzer Druck fährt auf, bzw. stoppt eine Auf- oder Abfahrt
- ein langer Tastendruck fährt ab
Wenn der Server (eibpc2) aktiv ist wird das System etwas erweitert:
meine Rollos kennen u.a. die Zustände/Positionen (%-absteigend) offen, Beschattung, Zu (Schlitze offen), geschlossen (100% zu)
- wenn der Rollo nicht fährt führt ein langer Tastendruck (neben KNX-nativ) dazu dass die Beschattung freigegeben wird, und wenn die Position < Zu ist, dass die Zu-Position angesteuert wird. Das führt dann dazu dass bei langem Tastendruck die Beschattungsposition angefahren wird wenn Bedarf besteht, wenn nicht, dann wird die Zuposition angesteuert. Wenn der Rollo auf Zu-Position ist dann wird er ganz geschlossen, und wenn der Rollo ganz geschlossen ist dann wird wieder die Zuposition angesteuert. Ein langer Tastendruck wechselt quasi zwischen Zu und geschlossen.
- wenn der Rollo gerade verfährt und man drückt erneut lang, dann wird sofort 100% angesteuert.
Das mag jetzt erstmal kompliziert klingen, ist hier aber mittlerweile etabliert und intuitiv.
Zu Halloween letzten Jahres kam der Wunsch auf dass die Terrassenrollos abends aufbleiben sollen, auch wenn niemand im Haus ist, damit man von draußen die "Spuk-Beleuchtung" sehen kann. Normalerweis gingen die Rollos immer vollautomatisch runter. Für eine Sperrr-Funktion will ich jetzt aber keine Taste opfern, das Handy will ich auch nicht rauskramen.
Ich habe also kurzerhand die eine Rollo-Taste erweitert: Wenn der Rollo eh schon ganz oben ist, und ich drücke kurz (Auffahrt), dann macht das ja keinen Sinn. Diese Sinnlosigkeit hab ich als weitere Funktion vorgesehen. Ich habe also die Taste per eibpc erweitert:
- wenn der Rollo ganz oben ist und die Rollo-Taste wird kurz gedrückt, dann wird (zusätzlich zu KNX-nativ) die Sperre gesetzt. Die Sperre wird indiziert durch die LED an der Taste.
Die Sperre soll nur manuell entfernt werden können, die dient ja gerade dazu die Automatik zu sperren wenn niemand da ist, so dass der Rollo oben bleibt. Wenn jemand da ist kann er auch die Sperre wegnehmen
Die Sperre soll manuell weggenommen werden wenn
- erneut die Rollo-Taste kurz gedrückt wird und der Rollo gesperrt ist, oder
- wenn die Rollo-Taste lang gedrückt wird (Abfahrt)
das hat damals zu Halloween nicht so wirklich funktioniert, und ich habe damals auf die Schnelle eine Workaround programmiert und das würde ich jetzt gerne säubern.
Der Grund dass das damals nicht funktioniert war möglich ein
Bug im JAL-Aktor?
wie hier ersichtlich:
image.pngvor #7 war der Rollo ganz oben und ich hab die Rollo-Taste kurz gedrückt (Auffahrt). KNX-nativ schickt die Taste eine 0 an SingleObjectControl des Aktors. Da der bei 0% steht fährt er nicht weiter hoch und schickt bei
#7 seinen Status_Position 0%
#8 der eibPC stellt fest Rollo oben, Rollotaste kurz gedrückt, also setzt er die Sperre
#9 der Jal-Aktor sendet seinen Sperrstatus
jetzt drücke ich die Taste lang, will also eine Abfahrt im gesperrten Zustand machen. Die Taste_lang sendet eine 1 an "Abfahrt des JAL", da die Sperre sitzt macht der Aktor nix. Ist ja richtig so.
#15 der eibpc stellt fest Taste lang gedrückt, Sperre sitzt, also wird die Sperre zurückgenommen!
#16 der eibpc schickt eine Positionsansteuerung (Zu-Position, 75%) hinterher. Ich erwarte dass die Position angefahren wird, da ja zuvor die Sperre zurückgenommen wurde. Es passiert aber nichts!
#17 der JAL-Aktor schickt stattdessen seinen Status_Position 0% und
#18 den Status der Sperre (inaktiv)
Ist dieses Verhalten so gewollt? Es ist NICHT das Verhalten dass ich erwarte!
Meine Rollladen funktionieren weitgehend vollautomatisch. Trotzdem hab ich eine Taste je Rollo um auch manuell steuern zu können.
Für alle Rollotasten gilt KNX-nativ:
- ein kurzer Druck fährt auf, bzw. stoppt eine Auf- oder Abfahrt
- ein langer Tastendruck fährt ab
Wenn der Server (eibpc2) aktiv ist wird das System etwas erweitert:
meine Rollos kennen u.a. die Zustände/Positionen (%-absteigend) offen, Beschattung, Zu (Schlitze offen), geschlossen (100% zu)
- wenn der Rollo nicht fährt führt ein langer Tastendruck (neben KNX-nativ) dazu dass die Beschattung freigegeben wird, und wenn die Position < Zu ist, dass die Zu-Position angesteuert wird. Das führt dann dazu dass bei langem Tastendruck die Beschattungsposition angefahren wird wenn Bedarf besteht, wenn nicht, dann wird die Zuposition angesteuert. Wenn der Rollo auf Zu-Position ist dann wird er ganz geschlossen, und wenn der Rollo ganz geschlossen ist dann wird wieder die Zuposition angesteuert. Ein langer Tastendruck wechselt quasi zwischen Zu und geschlossen.
- wenn der Rollo gerade verfährt und man drückt erneut lang, dann wird sofort 100% angesteuert.
Das mag jetzt erstmal kompliziert klingen, ist hier aber mittlerweile etabliert und intuitiv.
Zu Halloween letzten Jahres kam der Wunsch auf dass die Terrassenrollos abends aufbleiben sollen, auch wenn niemand im Haus ist, damit man von draußen die "Spuk-Beleuchtung" sehen kann. Normalerweis gingen die Rollos immer vollautomatisch runter. Für eine Sperrr-Funktion will ich jetzt aber keine Taste opfern, das Handy will ich auch nicht rauskramen.
Ich habe also kurzerhand die eine Rollo-Taste erweitert: Wenn der Rollo eh schon ganz oben ist, und ich drücke kurz (Auffahrt), dann macht das ja keinen Sinn. Diese Sinnlosigkeit hab ich als weitere Funktion vorgesehen. Ich habe also die Taste per eibpc erweitert:
- wenn der Rollo ganz oben ist und die Rollo-Taste wird kurz gedrückt, dann wird (zusätzlich zu KNX-nativ) die Sperre gesetzt. Die Sperre wird indiziert durch die LED an der Taste.
Die Sperre soll nur manuell entfernt werden können, die dient ja gerade dazu die Automatik zu sperren wenn niemand da ist, so dass der Rollo oben bleibt. Wenn jemand da ist kann er auch die Sperre wegnehmen
Die Sperre soll manuell weggenommen werden wenn
- erneut die Rollo-Taste kurz gedrückt wird und der Rollo gesperrt ist, oder
- wenn die Rollo-Taste lang gedrückt wird (Abfahrt)
das hat damals zu Halloween nicht so wirklich funktioniert, und ich habe damals auf die Schnelle eine Workaround programmiert und das würde ich jetzt gerne säubern.
Der Grund dass das damals nicht funktioniert war möglich ein
Bug im JAL-Aktor?
wie hier ersichtlich:
image.pngvor #7 war der Rollo ganz oben und ich hab die Rollo-Taste kurz gedrückt (Auffahrt). KNX-nativ schickt die Taste eine 0 an SingleObjectControl des Aktors. Da der bei 0% steht fährt er nicht weiter hoch und schickt bei
#7 seinen Status_Position 0%
#8 der eibPC stellt fest Rollo oben, Rollotaste kurz gedrückt, also setzt er die Sperre
#9 der Jal-Aktor sendet seinen Sperrstatus
jetzt drücke ich die Taste lang, will also eine Abfahrt im gesperrten Zustand machen. Die Taste_lang sendet eine 1 an "Abfahrt des JAL", da die Sperre sitzt macht der Aktor nix. Ist ja richtig so.
#15 der eibpc stellt fest Taste lang gedrückt, Sperre sitzt, also wird die Sperre zurückgenommen!
#16 der eibpc schickt eine Positionsansteuerung (Zu-Position, 75%) hinterher. Ich erwarte dass die Position angefahren wird, da ja zuvor die Sperre zurückgenommen wurde. Es passiert aber nichts!
#17 der JAL-Aktor schickt stattdessen seinen Status_Position 0% und
#18 den Status der Sperre (inaktiv)
Ist dieses Verhalten so gewollt? Es ist NICHT das Verhalten dass ich erwarte!
Die Antwort ist vermutlich das die beiden Telegramme die internen Werte gesetzt haben aber die Logik des Aktors noch nicht gelaufen ist. Und wenn die Logik erst das PosKO und dann das SperrKO auswertet hätte man so ein verhalten.
.
Kommentar