blind control

Blind Controller

blind-control

Used to control a blind with many possibilities. This can be time-dependent and it can calculate the blind position based on the current position of the sun to limit the sun light To limit the sunlight on the floor of a window.

Table of contents

• Blind Controller
  • blind-control
    • Table of contents
    • The node
    • Node settings
      • general settings
      • blind settings
      • rule settings
      • overwrite settings
      • sun settings
        • maximize sunlight (Winter)
        • restrict sunlight (Summer)
        • sun position settings
      • special settings
    • Node Input
    • Node Output
    • Node Status
  • rules
    • rules execution in detail
    • rules example
    • time rules additional constraints
  • Advanced overwrite settings by incoming message
    • blind settings
    • default values and rule settings
    • sun control settings
      • window settings
      • sun control data
      • control about the minimum changes
    • other settings
  • Samples
    • Example 1
    • Example 2
    • Example 3 - testing rules and overrides
    • Example 4 - usage of message properties
  • Additional FAQ
    • Why is there no multi blind controller? (FAQ)
    • How to define a Temperature Overwrite? (FAQ)
    • How do I achieve that when opening a window the blind opens? (FAQ)
  • Other

The node

Thanks a lot alisdairjsmyth with its node node-red-contrib-blindcontroller. To be able to use the node node-red-contrib-blindcontroller, a lot of functions around the node would have been necessary. As a result, I landed at a new node. So this node originated in the style of node-red-contrib-blindcontroller but internally has become a complete new development. I did not make the decision easy as to whether this node should be developed as a standalone node or as part of that node collection. The decisive factor was that this node uses many of the existing functions of that node collection.

Depending on the use case, this node may be the more appropriate one or the node node-red-contrib-blindcontroller. The differences from this node to node-red-contrib-blindcontroller are:

• The output at the node-red-contrib-blindcontroller node is different to that node.
  • The node is designed to determine the degree of opening, so the higher number is open and the lower number is closed.
  • There is a statusObject.levelInverse output who will have the inverse value if needed.
  • The levels can be integer or floating point numbers. It is depending on the configuration of Open-level, closed-level and increment. This means the node can be configured to have 100=open, 0=closed with an increment of 1, but also 1=open, 0=closed with an increment of 0.01.
• This node is very flexible where information comes to the blind controller. So these do not always have to be part of the msg object, but can also come from environment variables or contexts.
• This node has the possibility for manual override with different importance. This can be used to differentiate between manual operation, fire alarm, window knob handle, etc. ...
• Various conditions for the absolute position are selectable, which unfortunately does not make the configuration easy. An example is if in the morning the blind should open depending on the position of the sun, but at the earliest at a defined time, which must be different between week and weekend.

Node settings

Name and Config settings

• Position Configuration connects to the central configuration node, which contains the current position, but also handles a lot of internal shared functions. Thus, this configuration is always needed, even if the sense does not always open up.
• name the name of the node
• id allows to setup an additional id of the node (ℹ️ for usage in SubFlow this can be set to an environement variable)

General settings

blind settings

• Increment defines the minimum degree the blind position can be controlled
• open position The value for maximum open degree of a blind.
• closed position The value for minimum close degree of a blind.

All values could be floating point values.

default settings

• default position The value which will be used if no other value given by condition, time or sun applies.
• default slat The slat value which will be used if no other value given by condition, time or sun applies.
• topic The default topic of any outgoing message will be set to this value, if no other value given by condition, time or sun applies. If no topic is defined at all, the topic of the ingoing message will be used.

overwrite settings

• expire the duration in minutes a manual setting will remain is place. If not defined, there will be no default expiring of overrides.

Time and Rule control

• If a rule with a absolute blind position applies, the blind position defined by the rule will be used.

  • sun control will then not be active

• If a rule has a condition, the rule only applies if the condition matches.

  • For some conditions a comparisons needs to be defined.
  • If the values of comparison comes from a message object and the value can not be determined, the value is taken at which the value could be determined last. If there is no previous value a error will be thrown otherwise only a log output. To thus the message property not needs to be available in all incoming messages.

• If a rule has a time limitation

  • until the first rule is taken, where the given time is greater than the current time.
  • from the last rule is taken, where the given time is less than the current time.

• For some time definitions an Offset could be added (or be reduced with a negative value)

• If for the blind position a value from a message object and the value can not be determined the defined default blind position will be used.

sun settings

Sun control is only active if no override and no rule with an absolute blind position applies!

If sun-control checkbox is not checked, the defined default position will be used.

The sun control (maximize or restrict sunlight) is only active, if no other rule (with an absolute blind position) or override matches.

• Requirements that should be valid with a higher priority should be set up as rules.

  • Example: if the blind should set to a level if a temperature threshold exceeded, this could be setup as rule

• topic if defined, the topic of the outgoing message which will be used if level is set by sun-control. If this topic is not defined (empty) the default topic will be used.

maximize sunlight (Winter)

In this mode if no override and no rule with an absolute blind position matches:

• If the sun is not in the window the blind will set to defined min position. (oversteer will be ignored)
• If the sun is in the window
  • If any oversteer data are setup and oversteer conditions are fulfilled the blind will set to the defined oversteer blind position.
  • otherwise the blind level is set to defined max position.

restrict sunlight (Summer)

In this mode if no override and no rule with an absolute blind position matches, the node calculates the appropriate blind position to restrict the amount of direct sunlight entering the room.

This calculation includes:

• Determination of whether direct sunlight is entering the room based on the orientation of the blind and the azimuth of the sun
• Dimensions of the window and the current altitude of the sun.
• consideration of weather conditions against defined thresholds

sun position settings

• start The azimuth (in degree) of the sun, when the sun start falls into the window.
• end The azimuth (in degree) of the sun, when the sun no longer falls into the window.

under the simplest assumption starting from the bearing representing the perpendicular of the window to geographical north:

• start = orientation - 90 degree
• end = orientation + 90 degree

• The units of length is measure agnostic, They must be all in the same unit, but it does not matter which unit is used. If as lengths are used meter all lengths must be in meter. If used centimeters, all must be in centimeter.
• top Measurement from the floor to top of the window covered by the blind.
• bottom Measurement from the floor to bottom of the window covered by the blind.
• length on the floor (optional) the extent to which direct sunlight is to be allowed into the room through the window, defined as a length on the floor.
• min altitude threshold This option is no longer available, please setup this as an oversteer.
• min position minimum blind position if the sun is in the window. The blind will not close more than this minimum value, even if the calculated value results in a lower position.
• max position maximum blind position if the sun is in the window. The blind will not open more than this maximum value, even if the calculated value results in a higher position.

• oversteer, oversteer Operator, Threshold allows to define a blind position which should be used in a given condition to be used instead of the calculated value by the sun. Typical use-case is a weather condition but it is not limited to that.

  • the value for Threshold can only be entered if needed by selected operator
  • Example: If the oversteer is a property which contains a numerical value representing the percentage of sky occluded by clouds and an operator greater than or equal is used with a Threshold a numerical value representing the maximum percentage of sky occluded by clouds. Then if the oversteer value exceeds the Threshold the blind position will be used instead of the position calculated by the sun.
  • If the values of oversteer or Threshold comes from a message object and the value can not be determined, the value is taken at which the value could be determined last. If there is no previous value a error will be thrown otherwise only a log output. To thus the message property not needs to be available in all incoming messages.
  • blind position the blind position which should be used instead of the calculated value by the sun if the defined expression for oversteer with operator (and maybe Threshold) is true.
  • can be used for overrides of sunPosition calculation by weather, cloud, temperature, UV-index, ... conditions

• oversteer2, oversteer2 Operator, Threshold equal to oversteer, but an additional oversteer possibility. Lower priority than oversteer

• oversteer3, oversteer3 Operator, Threshold equal to oversteer and oversteer2, but an additional oversteer possibility. Lower priority than oversteer2

• oversteer topic if defined, the topic of the outgoing message which will be used if level is set by sun-control. If this topic is not defined (empty) the default topic will be used.

Output and special settings

• output here can be the message send to the first output be configured. See Node Output for further details.
• auto trigger Typically the calculation will be triggered by an incoming message or by an expiring timeout from an override. Additionally the node can be configured to have an auto trigger time.
  • If such a time is configured the node will be trigger a new calculation automatically at the next possible time, taking the following times into account:
    • every 5 minutes if restrict sunlight is active and the sun is in the window
    • every 10 minutes if restrict sunlight is active and the sun will be next time shine in the window
    • a time for a rule or the next rule occurs or expires
    • the configured time span in the node
  • To thus in the most cases it makes no sense to enter a short period (less than 15min) of auto trigger time in the configuration, because the node automatically shortens the time if necessary.
  • Please note that the node cannot react to changes in times that are configured via a context. If for example times or offsets configured by using a flow or global context, the auto trigger would not change the next trigger time.
• start delay Sometimes on node-red start (or flow re deploy) the node should not send any output before the system has settled (contexts are set, incoming messages processed, ...). To thus it is possible to define a delay time. Setting a time will only block the node to send any output until the time has reached to the first output. All calculations still will be made.

Node Input

The Input is for triggering the calculation and for setting overwrites of the blind position.

• reset an incoming message with msg.reset is true or msg.payload.reset is true or where the msg.topic contains resetOverwrite and the value of msg.payload = true will reset any existing overrides.
  • importance (optional) when a importance is given the existing override will only reset if the importance of the message is equal or higher then the importance of the existing override. For a reset, the same applies to the importance as for the override (see below).
• position an incoming message with a numeric property of msg.blindPosition, msg.position, msg.level, msg.blindLevel, msg.payload.blindPosition, msg.payload.position, msg.payload.level, msg.payload.blindLevel or where the msg.topic contains manual or levelOverwrite and the value of msg.payload is a numeric value will override any of rule/sun/.. based level of the blind.
  • If an override is already active a new message changes the blind level if the importance of the existing override allows this.
    • The override could also limited if a property msg.ignoreSameValue, msg.payload.ignoreSameValue is set to true an existing override will only be changed if the position value differs from the active override position.
    • If a property msg.resetOnSameValue, msg.payload.resetOnSameValue is set to true an existing override will be reset if the position value is equal the active override position.
  • Except -1 the position must be a valid blind Position as defined in the node settings or otherwise it will throw an error.
  • The position of the special value of -1 will set the node in override mode without sending any message out until override position is changed, override is expired or reset.
    • Example: This could be useful if a blind is controlled by an external button, where not known the blind position after button press. In this case the Button-event can used to trigger the override-mode of the node without knowing the real position of the blind.
  • if the message has additional property msg.slat the slat position will be set to this value otherwise the default slat position will be used.
    • from version 2.0.1 alternatively the property can be msg.blindSlat or if the topic contains slatOverwrite the value of the property msg.payload will be used as slat position
    • It is not possible to just overwrite the slat position. From version 2.0.1, you can set up a rule that enables this.
• importance (optional) Enables to handles overrides of different importance's. Default value will be 0.
  • A message property msg.importance, msg.payload.importance, msg.privilege or msg.payload.privilege with a valid numeric value (due to backward compatibility also msg.priority, msg.payload.priority, msg.prio and msg.payload.prio is possible)
  • or when the msg.topic contains importa, significan, privilege or alarm and the value of msg.payload is a valid numeric value (due to backward compatibility also prio in the topic is possible)
  • A higher number is a higher importance. So importance 1 is the lowest importance.
  • If in the message a property msg.exactImportance, msg.payload.exactImportance, msg.exactPrivilege or msg.payload.exactPrivilege is set to true or when the msg.topic contains exactImporta, exactSignifican or exactPrivilege then the existing override will only reset if the absolute value of the importance of the message is equal then the importance of the existing override.
  • A boolean value true is considered as numeric 1
  • a higher number is a higher importance. So importance 1 is the lowest importance
• expire (optional) Enables to define an override as automatically expiring. As default value the value in the settings is be used.
  • A message property msg.expire or msg.payload.expire
  • or when the msg.topic contains expire and the value of msg.payload is a valid numeric value
  • The value must be a time in milliseconds which is greater than 0. Otherwise the override will be set to not expiring.
  • If an override is already active a new message with expire can change the existing expire behavior if the importance of the existing override allows this.

Useful to know:

• If a reset and a new override is set in the same message, any existing override will be reset and the new will be set afterwards. In this scenario no existing override importance will be considered.
• An already existing Override can only be changed if the importance of the existing is 0 (default - can always be changed) or the message object has a importance set with a value that is equal or greater than the existing override. If that is given the expire, importance or position can be changed.
  • if additional exactImportance is defined, then the message importance must be equal to the existing importance.
• an incoming message with msg.mode, msg.payload.mode or where the msg.topic contains setMode and the value of msg.payload is a valid number, will allow to set the mode of the sun control.
  • a value of 0 will deactivate sun control, 1 will set to maximize sunlight (Winter) 3 will set to minimize sunlight and 16 will set to restrict sunlight (Summer).
  • The maximum adjustable mode is influenced by the settings of the node. The mode can not be set to restrict sunlight (16) if in the settings is setup only maximize sunlight (1).
• A message where the topic contains triggerOnly or or with an property msg.trigger which is true can not act as override.

Node Output

The Node has always two outputs.

An output can be triggered by an incoming message, by an expiring timeout from an override or by auto trigger. If the trigger is a incoming message, the incoming message will be forwarded to the first output if the blind position has changed.

The incoming message is changed as following:

• msg.topic if a topic is defined this topic will be used, otherwise no change of the topic from the incoming message
• msg.payload the payload will be set to the new blind level (numeric value)

The first output will only send a message if the blind level, the slat or the topic has changed. (An output to the first output can be forced if the topic contains the text forceOutput.)

The second output will every time output a message, where the msg.payload property of the message object it set to the status object. The difference is also, that the second output will give this object every time a recalculation will is triggered, where the first output only send a message on blind position change.

The configurable Output properties for the first output. Special configurations are the following:

• blind level - the result level given as a number as defined.
• blind level inverse - the result level given as a number as defined, but as inverse. Example if Blind leel ia 0-100 and 100 is open, the inverse will be 0 open;
• blind slat - the value of the resulting slat position as defined
• topic - the resulting topic as defined, the string of the topic could have the same placeholders as string with placeholder.
• string with placeholder a string, which could have the following placeholders:
  • ${name} - name of the node
  • ${id} - ID of the node
  • ${path} - path of the node (Node-Red >=2.2; Node version >=2.0.8)
  • ${level} - level
  • ${levelInverse} - level, but inverse
  • ${slat} slat position
  • ${code} - statusObject.reason.code,
  • ${state} - statusObject.reason.state,
  • ${description} - statusObject.reason.description,
  • ${rule} - ID of the active rule (if rule was active)
  • ${mode} - current mode
  • ${topic} - msg.topic of the incoming (trigger) message (if available)
  • ${payload} - msg.payload of the incoming (trigger) message (if available)
• status object a object send as msg.payload on second output with the following properties:
  • statusObject.reason - object - for the reason of the current blind position
    • statusObject.reason.code - number - representing the reason for the blind position. The possible codes are
      • NaN - start delay is setup and node is in this time
      • -1 - the rules was not evaluated, maybe override is active
      • 1 - defined default blind position, because no other rule/condition/behavior
      • 2 - manual override
      • 3 - manual override - expiring
      • 4 - based blind position based by rule
      • 5 - calculated blind position by sun control is below defined minimum blind position (minimum blind position used)
      • 6 - calculated blind position by sun control is above defined maximum blind position (maximum blind position used)
      • 7 - Sun below altitude threshold
      • 8 - Sun is not in window, default blind position is used
      • 9 - blind position calculated by sun position
      • 10 - defined oversteer condition applies
      • 11 - blind position calculated by sun position was not used caused by smooth settings
      • 12 - sun is in window (maximize mode), max blind position used
      • 13 - sun is not in window (maximize mode), min blind position used
      • 14 - change is below defined minimum delta
      • 15 - blind position is below defined minimum blind position by rule
      • 16 - blind position is above defined maximum blind position by rule
    • statusObject.reason.state - string - short text representing the reason for the blind position (same as node status text)
    • statusObject.reason.description - string - describe the reason for the blind position
  • statusObject.level - number - the new blind level - equal to msg.payload of the first output message.
  • statusObject.levelInverse - number - if statusObject.blind.overwrite.active is true, the value of statusObject.levelInverse will be equal to the value of statusObject.level, otherwise it will be the inverse to statusObject.level. This means if statusObject.level indicates how much the blind is open, then statusObject.levelInverse indicates how much the blind is closed. So if statusObject.level is equal to min position, statusObject.levelInverse will be max position.
  • statusObject.blind - object - containing all blind settings, only the most interesting ones are explained here
    • statusObject.blind.overwrite - object
      • statusObject.blind.overwrite.active - boolean - is true when overwrite is active, otherwise false
      • statusObject.blind.overwrite.importance - number - the importance of the override
      • statusObject.blind.overwrite.expires - boolean - is true when overwrite expires [exists only if overwrite active]
      • statusObject.blind.overwrite.expireTs - number - a timestamp (UNIX) when overwrite expiring [exists only if overwrite expires]
      • statusObject.blind.overwrite.expireDate - string - a timestamp (String) when overwrite expiring [exists only if overwrite expires]
  • statusObject.rule - object - exists only if no override is active
    • statusObject.rule.active - boolean - true if a rule applies
    • statusObject.rule.id - number - id of the rule who applies (is -1 if no rule has applied)
    • statusObject.rule.level - number - the blind level defined by the rule if level type is absolute, otherwise the defined default blind position [exists only if a rule applies]
    • statusObject.rule.conditional - boolean - true if the rule has a condition [exists only if a rule applies]
    • statusObject.rule.timeLimited - boolean - true if the rule has a time [exists only if a rule applies]
    • statusObject.rule.conditon - object with additional data about the condition [exists only if statusObject.rule.conditional is true] - good for debugging purpose
    • statusObject.rule.time - object with additional data about the time [exists only if statusObject.rule.timeLimited is true] - good for debugging purpose
    • statusObject.rule.hasMinimum - boolean - is true if to the level of the rule an additional minimum rule will be active, otherwise false
    • statusObject.rule.levelMinimum - number - exists only if statusObject.rule.hasMinimum is true and then contains then the blind level defined by the rule
    • statusObject.rule.hasMaximum - boolean - is true if to the level of the rule an additional maximum rule will be active, otherwise false
    • statusObject.rule.levelMinimum - number - exists only if statusObject.rule.hasMaximum is true and then contains then the blind level defined by the rule
  • statusObject.sunPosition - object - calculated sub-position data - exists only if sun position is calculated
    • statusObject.sunPosition.InWindow - true if sun is in window, otherwise false
    • statusObject.sunPosition.oversteer - object - containing the active oversteer data
  • statusObject.autoTrigger - object - with additional data about the autoTrigger [exists only if auto trigger is enabled in the settings]
    • statusObject.autoTrigger.deaultTime - number - in milliseconds the auto trigger time of the settings
    • statusObject.autoTrigger.time - number - in milliseconds the next auto trigger time (could be less than the dined time in the settings)
    • statusObject.autoTrigger.type - number - the type of the next auto trigger
      • 0 - equal to defined statusObject.autoTrigger.deaultTime
      • 1 - by current rule end or statusObject.autoTrigger.deaultTime
      • 2 - by next rule or statusObject.autoTrigger.deaultTime
      • 3 - sun not on horizon (maybe it is night?)
      • 4 - sun not visible
      • 5 - sun before in window (auto trigger time will be at maximum every 10 minutes)
      • 6 - sun in window and smooth time is set (auto trigger time will be maximum the defined smooth time)
      • 7 - sun in window and no smooth time defined (auto trigger time will be at maximum every 5 minutes)
• random number (continously new) - allows to define a random number between 0 and the given number, the number will be recalculated every time/output
• Base-Functions#offset
• random number (once per day) - allows to define a random number between 0 and the given number, the number will be recalculated only once per day - Base-Functions#offset

Node Status

The node status representing the value of the statusObject.reason.state of the output. The color of the output is as following:

• red - any error or a start delay is set and node is currently in this time
• blue - override active
• grey - level by rule
• green - default value or sun not in window
• yellow - any other

The shape indicates whether the blind is fully closed or not.

rules

The rules are not easy to understand.

There are basically 4 generic types of rules:

• no time and no condition rule
  • a rule with no time and no condition will be always active if checked.
  • such rules are evaluated in the order of time until and time from rules
• a rule with a condition - conditional rule
  • a rule with a condition will only be active if the condition matches, otherwise the rule will be ignored
  • rules with only a condition are evaluated in the order of time until and time from rules
• a rule with a given time - time rule
  • time rules differ again in 2 ways
    • until time rules
      • rules will be active from Midnight until the given time
      • the first matching until rule with a time later than the current time will be selected
    • from time rules
      • rules will be active from given time to Midnight
      • the last matching from rule with a time earlier than the current time will be considered
      • from rules only considered if no until rule was selected
• a rule with a condition and a given time
  • these type of rules are a combination. The rules will only be considered if the condition matches and then it act as a normal time rule. Otherwise it will be ignored.

the blind level of a rule could have 5 options:

• absolute
  • If a rule with a blind level of type absolute matches, the level would be set to the level defined in the rule. No sun control will be active as long this rule is active.
• minimum (oversteer) / maximum (oversteer)
  • a rule of this type makes a limitation of the blind position possible. Other absolute rules still will be considered.
    • Please aware that a rule of this type will not considered if
      • it is of type until and comes after an active absolute until time rule
      • it is of type from and comes before an active absolute from time rule
• reset minimum / reset maximum
  • a rule of these type only clears a previous remembered minimum or maximum limitation during the rule evaluation. The rules when such a rule becomes active are the same as for minimum (oversteer) / maximum (oversteer) rules.

If there is a time where no rules matches, then as blind position the default defined blind position will be used or if sun control is active the blind position calculated by the sun will be used.

a typically easy ruleset could be setup in a way like:

• 1 until absolute time (e.g. early morning 6:00) blind will be closed (absolute)
• 2 until sun rise time (e.g. sunrise) blind will be closed (absolute)
  • The previous absolute until rule (rule 1) will consider that the blind is closed, even if the sun rise time (this rule 2) is earlier than the time of rule 1.
• 3 from sun set time (e.g. sunset) blind will be closed (absolute)
• 4 from absolute time (e.g. late night 22:00) blind will be closed (absolute)
  • This rule 4 will be consider that the blind is closed, even if the sun set time (rule 3) is later than this absolute time.
• In the time between the rule 2 (last until) and the rule 3 (first from rule) the blind will set to the default position which is setup normally to open. Only in this time the blind position can be controlled by sun.

rules execution in detail

The exact logic is as follows:

1. The system evaluates from the first rule starting to the last rule of type until in ascending order (or if there is no until rule, then to the last rule).
   • Rules whose condition does not apply or which not enabled will be skipped.
   • Rules of the time type from are skipped.
   • The first rule of level type absolute, which has no time constraint or whose time is greater than the current time, is chosen.
     • Subsequent rules are no longer considered, even if they have no time constraint.
2. If no rule was found under 1. (of type until), the system evaluates the rules of type from in descending order from the last rule.
   • Rules whose condition does not apply or which not enabled will be skipped.
   • Rules the time type until to are skipped.
   • The first rule of the level type absolute, which has no time constraint or whose time is smaller than the current time, is chosen.
     • Further rules are not evaluated, even if they have no time constraint.
3. If no rule was found with 1st and 2nd, the default value for the shutter control is taken and the sun control can be active.

The rules in the range between the last to rule and the first rule are evaluated only if no other rule is active. This can be used to allow special control during this time.

In addition to the rules of the level type absolute, there are also the rules of the type minimum, maximum and reset minimum, reset maximum. These rules are basically evaluated in the same way. If one of these rules applies, the system does not stop the evaluation of the rules, but remember the last rule of the respective kind (last minimum, last maximum). If one of the reset rules applies to the evaluation, the noted rule is discarded. The remaining minimum-type rule and the remaining maximum-type rule are applied. When applying these minimum / maximum rules, it does not matter what the shutter position (rule, sun position, default, ...) was determined. This can be used to set additional constraint on the next absolute rule or to the sun control based on other limitations, constraints, time settings or whatever. A typical application of this type of rule may be to ensure that a minimum shutter height is ensured when the window is open to guarantee ventilation or to ensure in heavy rain that no rain falls in the window.

rules example

first lets look at the until rules:

starting from midnight the following rule will be used:

• the rule 1 will results in a blind position of closed until civilDawn or but at the earliest until 6:30
  • the earliest (minimum) means if the time of civilDawn is early than 6:30, the time of 6:30 will be used.
• the rule 2 will results in a blind position of closed until civilDawn or but at the earliest until 7:30
  • but only if the condition global.dayInfo.isWeekendOrHoliday === true matches
  • and if the time of the second until rule is greater than the time of the first rule.

then lets look at the from rules:

starting from a defined time the following rule will be used:

• from civilDusk the rule 3 results in a blind position of closed but at latest until 22:35
  • the latest (maximum) means if the time of civilDusk is later than 22:35, the time of 22:35 will be used.
  • the rule will be only used, if the condition global.dayInfo.isWeekendOrHoliday === false matches
  • ans the rule will be only used if the resulting time is lower than a time of a following from rule
• from 23:15 until midnight the rule 4 results in a blind position of closed

There is a time between the until and the from rules, where no rules matches. In this time the default defined blind position will be used or if sun control is active the blind position calculated by the sun will be used.

time rules additional constraints

On a time rule additional constraints can be choose:

A rule is only executed if there are no restrictions.

That means:

• if the current day of the week is one of the selected days of the week
• if the current month is one of the selected months
• if only even is selected and the current day is an even day
• if only odd is selected and the current day is an odd day
• if the current day is in the time period as selected
  • For the time period settings the year is ignored.
    • Normal: the start day and month is less than the end day and month
      • the rule is only executed if the current month+day is greater than or equal the selected period start and less than the selected end month and day.
      • Example: This can be used To setup a period starting from 17th of March to 7th of May.
    • over the year: the start day and month is greater than the end day and month
      • the rule is only executed if the current month+day is greater than or equal the selected period start or less than the selected end month and day.
      • Example: This can be used To setup a period starting from 12th of November to 20th of February.

All constraints are additive. Pleas careful to that, that means it is possible to setup a rule which never would be used.

Advanced overwrite settings by incoming message

The most settings of the node could be set by a message with a specific topic. When the topic matches the value of the msg.payload will be used. ⚠️ This is only for advanced users, because there is no plausibility or valitation check of the values!

blind settings

if the topic matches one og the values the msg.payload must be a valid float number. ⚠️ There is no plausibility or valitation check of the values.

• Increment - msg.topic = setBlindSettingsIncrement defines the minimum degree the blind position can be controlled
• open position - msg.topic = setBlindSettingsTop - The value for maximum open degree of a blind.
• closed position - msg.topic = setBlindSettingsBottom - The value for minimum close degree of a blind.

default values and rule settings

• default position - msg.topic = setBlindSettingsLevel The value which will be used if no other value given by condition, time or sun applies.
• default topic - msg.topic = setSettingsTopic if defined, the default topic of any outgoing message will be set to this value, otherwise the topic of the ingoing message will be used

sun control settings

window settings

• msg.topic = setWindowSettingsTop
• msg.topic = setWindowSettingsBottom
• msg.topic = setWindowSettingsAzimuthStart
• msg.topic = setWindowSettingsAzimuthEnd

sun control data

• sun control topic msg.topic = setSunDataTopic - the topic wnich is used if blind position is set by sun control
• msg.topic = setSunDataFloorLength
• msg.topic = setSunDataMinAltitude

control about the minimum changes

• msg.topic = setSunDataMinDelta
• msg.topic = setSmoothTime

other settings

• msg.topic = setAutoTriggerTime
• msg.topic = setStoreName

Samples

The Examples can be imported in Node Red over the Import Menu:

Example 1

Example for a time-control to open blind on civilDawn, but not before 6 o'clock and close blind on civilDusk, but not later than 23:00 o clock:

Example 2

similar example with additional different times for weekend:

Example 3 - testing rules and overrides

The following example could be used for testing rules, overrides and sun-position. The function node with the start/stop inject will set msg.ts which will be used by the node as the current time. This time is increased every 2 seconds by 30 minutes (can be setup at the beginning of the function node). The given number by the inject will be used as the start hour for that time.

So this example is ideal for testing setup in previous.

Example 4 - usage of message properties

As an enhancement of example 3 the example 4. It shows how message instead of contexts could be used and how rule based overrides can be used.

Additional FAQ

Why is there no multi blind controller? (FAQ)

The approach is that there is a node for a blind. To reduce the setup overhead it is possible to create a sub-flow with the node per side of the house and thus only have to make the settings once. Settings such as overrides or times can still be configured individually, for example via sub-flow environment variables.

Maybe in this case node-red-contrib-blindcontroller is better suited here as well.

How to define a Temperature Overwrite? (FAQ)

To Overwrite the sun-.calculation by a temperature threshold can be archived by using a conditional rule.

How do I achieve that when opening a window the blind opens? (FAQ)

This can be archived in different ways:

• using override possibilities with different importance
• using conditional rules

Other

For bugs, questions and feature requests please use the GitHub Issues.