KNX Shutters: how to tell not only shutter position but also blade position

I have KNX actuators for rollershutters and I am using this item:

Rollershutter Shutter_EG_EssZi_Sued	"Jalousien Esszimmer Süd [%d %%]" 	(EG_WoZi, Shutters)	[ "Switchable" ]	{knx="4/1/10, 4/1/11, 4/1/12+4/1/16", autoupdate="false"}


  • 4/1/10 is KNX “UP/DOWN”
  • 4/1/11 is KNX “STOP/MOVE”
  • 4/1/12 is KNX position (of the shutter itself)
  • 4/1/16 is KNX blade position (meaning how the blades are positioned)

Is there a possibility to tell in a rule, that the shutter should go to 60% shutter Position and 50% blade position?
Shutter_EG_EssZi_Sued.sendCommand(60) just moves the shutter to 60%, but I can’t influence the blade position: If the shutter was at <60%, then the blade position is 0%, if the blade was > 60%, the blade position will be 100%. I tried some, but got Errors:

  • Shutter_EG_EssZi_Sued.sendCommand(60:50)
  • Shutter_EG_EssZi_Sued.sendCommand(60>50)

I could use Scenes and use them, as I can configure position and blade in a scene - but it’s getting complicated in my case… :wink: To use both commands in a rule would ease my rules extremely.

I don’t think Rollershutter can accept a command like that. You will probably have to issue two commands to two Items or use scenes.

1 Like

afaik you have to define a second item for the lamella angle.
Further, there are two group addresses missing. You have to use both set position and get position as well as set angle and get angle

  • 4/1/13 is position state and
  • 4/1/17 is angle state
    then the items should look like
Rollershutter Shutter_EG_EssZi_Sued  "Jalousien Esszimmer Süd [%d %%]"         (EG_WoZi, Shutters) [ "Switchable" ] {knx="4/1/10, 4/1/11, 4/1/12+<4/1/13", autoupdate="false"}
Number Shutter_EG_EssZi_Sued_Lamelle "Jalousien Esszimmer Süd Lamelle [%d %%]" (EG_WoZi, Shutters) [ "Switchable" ] {knx="5.001:4/1/16+<5.001:4/1/17", autoupdate="false"}
  • < —> openHAB will request a read when starting up. Therefor the actor has to be set to answer read requests, so in ETS set the R-flag (in german it’s the L-flag :wink: )

I’m pretty sure you’ll have to wait for updating the angle until the shutters stopped. In a rule I would do something like:

rule "shutter"
    Time cron "0 30 8 * * ?" //8:30 am every day
    if(!(Shutter_EG_EssZi_Sued.state instanceof DecimalType))    //should not be
        Shutter_EG_EssZi_Sued.postUpdate(0)                      //needed at all :)
    while ((Shutter_EG_EssZi_Sued.state as DecimalType) != 60) { //wait for state 
        Thread::sleep(100)                                       //update

This sounds reasonable! I’ll try it in the afternoon!


Working since the beginning with my setup. I can send two commands to the rollershutters (i think you mean “raffstore”) and the shutters move to the position and after that move the angle.

I have sliders for some shutters in addition to the rollershutter buttons. Working great.

Here are my items for rollershutters and for raffstore (with lamellas):
For rollershutter you need 4 knx adresses, for raffstore you need 6 knx adresses.

Rollershutter Rollo_KG_Buero            "KG Büro [%d %%]"                  	(Rollos)       { knx="3/2/1, 3/1/1, 3/6/1+<3/3/1" }

Rollershutter Rollo_EG_Wohnzimmer       "EG Jalousie Wohnzimmer [%d %%]"   	  (Jalousien)  { knx="3/2/4, 3/1/4, 3/6/4+<3/3/4" }
Rollershutter Lamelle_EG_Wohnzimmer	"EG Jalousie Wohnzimmer Lamelle [%d %%]"  (Lamellen)   { knx="3/2/4, 3/1/4, 3/7/4+<3/5/4" }

ok. I’m trying to get this straight using the english vocabulary.
Disclosure: I use GIRA actuators - perhaps other vendors have different names

GAs Esszimmer Süd Jalousie / Rollershutter_EG_EssZi_Sued:
4/1/10 = Langzeitbetrieb / long time operation
4/1/11 = Kurzzeitbetrieb / short time operation
4/1/12 = Position Jalousie / position
4/1/13 = Position Lamelle / slat position
4/1/14 = Sonne - Beschattung Fassade / sun - shading facade
4/1/15 = Rückmeldung Antriebsbewegung / drive movement feedback
4/1/16 = Rückmeldung Jalousieposition / position feedback
4/1/17 = Rückmeldung Lamellenposition / slat position feedback
4/1/18 = Rückmeldung ungültige Position / invalid position Feedback

Now, that I have understood the concept behind the “Rollershutter”-item, I also configured two items:

Rollershutter	Shutter_EG_EssZi_Sued 	"Jalousien Esszimmer Süd [%d %%]"	(EG_WoZi, Shutters) [ "Switchable" ] {knx="4/1/10, 4/1/11, 4/1/12+<4/1/16", autoupdate="false"}
Dimmer		Slat_EG_EssZi_Sued	"Lamellen Esszimmer Süd [%d %%]"	(EG_WoZi, Shutters) [ "Switchable" ] {knx="5.001:4/1/13+<5.001:4/1/17", autoupdate="false"}

note the feedback GAs are different than those of Udos example - the rest is the same and I used “Dimmer” as item-type, so I have an slider in the UI.

so, in my rule (which is a bit more complex), I use the example-code from Udo. If you’re sending the slat position, the shutter will immediately stop and apply the slat position. So you have to wait for the shutter movement and then you can apply the slats. At present I use the percentage of the shutter with the slat position also, I’ll have to see, how this works out. (my rollershutters are southbound, and in my rule depending on sun, outside and inside temperature the shutter will move way down, providing more or less shade.)

if (Shutter_EG_EssZi_Sued.state != newShutterPos) { 
	while ((Shutter_EG_EssZi_Sued.state as DecimalType) != newShutterPos) { 
		// wait for state update
		// you could also use drive movement Feedback, which could be better, if the end position is for some reason not exactly met

I use rollershutter item for lamellas too (no dimmer), and i can control them with slider or with buttons, this depends on my settings in the sitemap, not in the items file.

And i can send the commands for shutters and lamellas in one without any sleep-time between.
First shutters, then directly followed by lamellas. So it moves in the right shutter position and after that the lamellas move to the right position.

1 Like

oh. I just tried this in a rule and sending both commands at once also resulted in the intended result. I tried it first in the console and it had the described behaviour. So, it looks like, this is different… :wink:
Thanks for the tip!