KNX Venetian blind tilt using an outdoor lux sensor: rule design advice

Setup, Configuration and Use Scripts & Rules
1

Hi everyone,

I’m Brain from SIXINSMART, where I work on shading motors. I’m exploring an openHAB integration using our 35 mm KNX tubular motor, its external KNX control module and an outdoor illuminance sensor to adjust Venetian blind slats as daylight changes.

The aim is to control daylight admission through the slats while keeping movements infrequent enough to be comfortable for people in the room.

The proposed integration would use a KNX/IP interface and the openHAB KNX binding to read the sensor’s lux value. An openHAB rule would then select a shading state and send the appropriate commands to the motor module.

For the rule design, I’m considering:

  • Separate lux thresholds for increasing shading and returning towards a more open position.
  • A delay requiring the threshold condition to persist before an adjustment.
  • A minimum interval between movements.
  • Tracking the requested shading state so repeated sensor updates do not keep issuing the same movement.
  • A manual override that cancels pending adjustments and pauses automation until the user enables it again.

One detail matters with an outdoor sensor: adjusting an indoor blind will not directly reduce the outdoor lux reading. Once the intended shading state is reached, the controller should hold it until the conditions justify another change.

The motor command mapping and commissioning behaviour still need validation for this openHAB integration. Blind height and slat tilt need separate consideration, and the tilt commands must match the motor module’s ETS application. A motor travel percentage alone does not establish the physical slat angle.

I’ve written up the application concept, system diagrams and commissioning considerations on our website as background for this discussion.

For those using openHAB with KNX Venetian blinds, I would appreciate your experience with two points:

  1. How do you distinguish a manual KNX wall-switch command from feedback caused by an automatic movement, so the automation pauses at the right time?
  2. Where absolute slat-angle feedback is unavailable, how do you restore a reliable reference after manual operation or an openHAB restart?

Examples of how you organise the relevant Items and rules would be particularly useful.

2

Not KNX specific, but as of OH 5.1 or maybe 5.0 (I can’t remember which) every event in OH includes a trail of sources so you can trace the origination of the event back to what caused it. You can use that to distinguish between user initiated events, manual events (i.e. events that come from the device itself) and automation events (i.e. events that originate from rules).

I’ve seen described in the past where users will full open or fully close the blind to get back to a known state and then restore the previous state before the OH restart. To avoid drift, this action is taken every night again. That’s one approach.

As for your rule design, be aware that much of what you are after already exists off-the-shelf in OH so you don’t necessarily need to implement everything in the rule manually.

See:

In JS and I think also jRuby rules, there is a sendCommandIfDifferent() which only passes on the command if the Item’s state differs from the command.

3

in JRuby it’s ensure.

Example:

MyBlinds.ensure.down
#or
MyBlinds.ensure << DOWN
#or
MyBlinds.ensure.command(DOWN)

There’s a built in rule condition for this: