GEN 2 - Master - EEPROM Pages

This page explains the Eeprom layout and which byte means what.

The Master controller inside the Gateway has a 8pin DIL eeprom (25LC512) that is used to keep all relevant data like modules on the bus, their address, button configuration, thermostat configuration, programmed names, programmed timings, programmed Basic Actions, special actions etc. The full configuration of the Master controller is kept in eeprom which is easily removable in other words, just by changing the eeprom from one gateway to the other, the full configuration is moved.

When the Master controller is started, values from eeprom are copied into RAM for performance reasons so when changing values in eeprom by using CLI instruction eeprom write, this won't have any effect until the Master controller is restarted by CLI instruction reset or when all values are copied from eeprom to RAM by using CLI instruction eeprom activate. Please be careful when direct writing is done into eeprom, this can make your system malfunction or stop working normally. A good practice, before making any changes in eeprom, is to make a backup into the Renson Smart Living cloud.

The used eeprom has 256 (0-255) pages of each 256 (0-255) bytes. Each page is used for a certain goal and the full explanation of each of those bytes used can be found below.

General Configuration Bytes (Page 0)

Page 0 -> Controller specific data

Number of input modules: This byte specifies the number of input (input, temperature, oled ...) modules known by the Master controller on the RS485 bus.

Number of output modules: This byte specifies the number of output (output, dim control, shutter/curtain ...) modules known by the Master controller on the RS485 bus.

Number of Roller/shutter modules: This byte specifies the number of Roller/Shutters that can be found back in the Large Installation List when Large Installation is enabled (see also Page 0/byte 27).

When the Large Installation mode is enabled and a new Roller/shutter module is added, this module will be added in the Large Installation List. The number of modules that are activated in the Large Installation List can be found back in the Master Eeprom:

RS485 Wait time: This byte specifies the time (RS485 wait time * 6,5ms) that Master will wait for a slave module to respond. Default value = 4 when programmed value = 0 or = 255. When having errors on the Bus, you can slightly increase this value to give the modules more time to respond. A higher value will also means a slower bus, especially when modules are non-responding.

Minimum light Level for Dimmed modules. Dimmers work with dim values from 0 (off) to 63 (max light). When dimming down, the minimum level (between 0-63) can be set in this byte so when dimming down, the dimmers will never go below the programmed value in this byte.

Dim Step (minimum 1, maximum 3): Every cycle, when dimming up or down, will be performed with the dim step. For example: -> dim down: current dim value – dim step until minimum light level is achieved. This is usefull when the user wants faster dimming when the button remains pressed. When the value programmed is not in range, dim step will be set at 1.

Wait cycles before dimming. This value specifies the number of scanning of the input before dimming is started. For example: Byte7=8. If the time the button is pressed is less than 8 scanning cycles, then the light will be switched on (if it was off) or switched off (when the light was on). When the button is pressed more than 8 scanning cycles, the light will start dimming or become brighter. The value wait cycles before dimming is close related with byte 22. Value between 2 and 63. If a non accepted value (255 for example) is programmed, the default value (15) is taken.

In this byte, the dimmer memory value will be stored. When this byte has value 0, the light will always switch on at full intensity (when not used in special function), when this byte is higher than 0, the last value in memory will be used in other words, if the light was dimmed at a certain level and the light is switched ON again, it will be at the last used dim level.

Automatic response byte: When the system is in API mode, every time an output changes, the system reports through his serial connection these changes. When the automatic response byte<255, the “automatic send” instruction “RO” will be sent for all the output modules initialized. For more information on the instructions “RO”, please see API Reference Guide. Please note that a second and third automatic send exists, please see byte 18 and 28 (page 0).

Echo On byte: This byte will indicate if characters received by the Master controller on his RS232 connection will be echoed or not. If Byte12=0 -> characters are not echoed, if Byte12>0 -> characters are echoed.

CLI/API byte: This byte will indicate if the system will start (cold or hot) up in API mode (<>255) or CLI mode (=255).

In this byte, the thermostat mode is kept so the system knows, after a power failure in which mode the the thermostats was. See Thermostat Mode for more information.

Temperature module enable/disable: The system supports the connection of the older 16 ports temperature module (produced in 2007-2011). If byte15=255, this module is disabled. When byte15<255, this 16 ports temperature module is enabled. When a recent 8 ports temperature module is used, this byte must be at 255.

The built-in thermostat system can be enabled/disabled depending on the outside temperature. In this byte, the sensor nr (0-29) of the outside temperature probe will be stored. If the value stored in this memory location is higher than 31, the system will take sensor 0 as outside sensor.

The built-in thermostat system can be enabled/disabled depending on the outside temperature. In this byte, the threshold temperature (below this temperature -> switch on thermostats, above this temperature-> switch off temperature) will be stored. The temperature in this byte is stored as System Value.

Automatic response byte OL: When the system is in API mode, every time an output changes, the system reports through his serial connection these changes. When the automatic response byte OL<255, the “automatic send” instruction “OL” will be sent and will report all outputs that are ON.. For more information on the instructions “OL”, please see API Reference Guide. Please note that a second and third automatic send exists, please see byte 11 and 28 (Page 0).

Pump delay parameter: Because some valves takes additional time before they go open, an additional delay can be programmed so first the valves get activated before the pumps. This parameter will program a delay (0-248 seconds) between the opening of the valves and the activation of the pumps. When this byte>248 -> Pump delay= 0 seconds.

Automatic response byte IL: When the system is in API mode, every time an input is pressed, instruction “IL” will be sent. When byte<255, “IL” will be sent when input is pressed, when =255, no “IL” will be sent.

Individual Temp byte: Every thermostat has a day1/day2 temperature which is configurable for every day of the week (Temp byte=255). If users wants to have the same Day1 temperature per thermoostat for every day of the week and the same for Day2 temperature, this can be done by making the Individual Temp Byte=0.

Wait time (value*20us) between different scans of input modules (value 0-254, if value=255 then value=3). Too fast scans can result in increased number of errors on the bus.

Wait time (value*20us) between different scans of output modules (value 0-254, if value=255 then value=3). Too fast scans can result in increased number of errors on the bus.

Thermostat auto update setpoints: When the thermostat system is in automatic mode and byte24=255, every 10 minutes, the temperature setpoints are being set again even when the setpoints are manually changed by the user. When byte24<>255, the setpoint temperature are only being set at the start and end of day/night period and not every 10 minutes.

Remote Modules Received bytes: The message size that a remote module sends back to the Master controller can vary depending on the module and the used firmware. Some older firmware (firmware released 2005-2012) uses short messages that can be interpreted by the Master controller as “Too short to be correct”. To correct this problem with older Firmware, the message size can be set. When Byte25=255 then the normal size frame (14 bytes) is used. When older modules are used and many errors occur, please change the setting to Byte25=6. A reset of the Master controller (Cold or hot) is needed to activate the changes made in this byte.

Catch All Byte: When older and newer modules are combined, newer modules that are using the normal size frame (14 bytes) so putting the frame size (byte 25) on 6 can make the newer modules to malfunction. The Catch all function will also make the older modules work but will slightly slow down the communication so please use this byte only when really necessary. Byte 26=255 -> Catch all functionality disabled, Byte 26<>255 -> Catch all enabled and Byte 26 will give the number of bytes for catch all. For example, a timeout occurred and not enough bytes came in, Byte 26 will be the number of bytes in which the catch all will be kicked in. Example: Byte25=255 so 14 bytes must be received to be a correct message. In the event less than 14 bytes are received (from an older module) and byte26=6, when 6 or more bytes are received, interpretation of the message will still occur. Please note that Byte 25 must be higher than byte 26 in order the catch all functionality to work.

Large Installation Mode: This byte specifies if the Large Installation mode is enabled (byte<255) or disabled (byte=255).

Note: When a Larger number of Roller/Shutter modules are expected, please enable the Large Installation mode before adding any modules to the system. Also, when you want to make use of the special basic actions (100-107), you must enable the Large Installation mode before adding any Roller/Shutter modules to the system.

Automatic response byte SO: When the system is in API mode, every time an output configured as Roller/Shutter in Large Installation mode changes, the system reports through his serial connection these changes. When the automatic response byte SO<255, the “automatic send” instruction “SO” will be sent and will report the output status of that Roller/Shutter module. For more information on the instructions “SO”, please see API Reference Guide. Please note that a second and third automatic send exists, please see byte 11 and 18 (Page 0).

Maximum number of Errors before a module is taken offline: In this byte, you can store the number of Errors (x100) the module must have before the system will take the module offline. When a module is missing, the Master will try to restore connectivity which makes the bus slow and other modules will respond much slower. When the number of errors is equal to the the eeprom value (x100), the the module will be put offline. The module can be put online again by resetting the errors (CLI instruction error clear or Basic Action 8). Please note that the value used by the system is the eeprom value multiplied by 100. When the eeprom value=0, the module will never be taken offline. This function works for Input and Output modules except for the modules that are part of the Large Installation mode.

To see if a module is taken offline, open Maintenance mode in the Renson Smart Living Portal and perform instruction error list, the result will be as below:

error list

output:

00 I 066.244.122.189 0 No Errors

01 I 066.030.015.135 0 No Errors

02 T 066.047.023.139 0 # of Errors: 44

03 I 073.062.031.015 1 # of Errors: 100

04 I 073.212.106.053 0 No Errors

05 B 066.040.148.074 0 No Errors

00 O 079.083.041.148 0 No Errors

01 D 068.151.047.095 0 No Errors

02 D 068.190.124.249 0 No Errors

03 O 079.243.231.207 0 No Errors

The first value indicate the module number, the letter is the module type, the four following values are the module address followed by the Offline modus (0 or 1) which indicated if the module is offline (=1) or not (=0). In the above example, Input module 3 is offline since in this example, eeprom value of page0/byte29=1.

If you make changes to Page0/Byte29, please always use the CLI instruction eeprom activate or the appropriate API instruction to make the changes active.

This function is available from firmware version 3.141.21

Temperature sensor correction: In this byte, you can indicate if temperature sensor correction must be applied. to avoid wrong temperatures, you can force the system to only accept temperatures between 5 and 45 degree Celsius. If a temperature is received outside this range, the system will indicate that sensor as being "Not Connected". This function will never be applied on any sensor that's being programmed as the outside sensor. When the temperature sensor correction byte is > 0, then the temperature correction will be applied. When the temperature correction byte = 0, then the correction will never be applied

This function is available from firmware version 3.141.34

CAN led Minimum brightness: The NIKO CAN button and the CAN Micro have 6 leds that can be programmed. With this byte, you program the minimum brightness of the led in other words, the led will always have the minimum brightness as programmed in this byte. The brightness value is between 0 and 255 but the maximum brightness that can be programmed is 127. Values >127 will be considered as 0 (led fully switched off).

This value is the startup value used when the system is booted. When BA actions are used to set the Minimum/Maximum brightness, these eeprom values will be ignored until the system reboots.

CAN led Maximum brightness: The NIKO CAN button and the CAN Micro have 6 leds that can be programmed. With this byte, you program the maximum brightness of the led in other words, the leds will have a maximum brightness as programmed in this byte. The brightness value is between 0 and 255 but the minimum brightness should be higher then 50.

This value is the startup value used when the system is booted. When BA actions are used to set the Minimum/Maximum brightness, these eeprom values will be ignored until the system reboots.

Nr of Output Repeats: This value indicates the number of output repeats towards output modules. When eeprom value = 255 (standard eeprom value) -> Nr of Repeats = 1

Temperature upper limit: For sensors linked to thermostats, temperature limits are set to avoid sensor errors to activate heating. In this eeprom value, the maximum acceptable temperature (programmed in system value) coming from a sensor which will be seen as acceptable values, values above this will be ignored. When the default value is still in the eeprom (255), the upper limit is set to 154 (=45 degree Celsius).

Temperature lower limit: For sensors linked to thermostats, temperature limits are set to avoid sensor errors to activate heating. In this eeprom value, the minimum acceptable temperature (programmed in system value) coming from a sensor which will be seen as acceptable values, values below this will be ignored. When the default value is still in the eeprom (255), the lower limit is set to 74 (=5 degree Celsius).

Functional in Firmware V3.143.60 and higher

This byte will indicate the log start byte in page 255 with the logging information of the last startup

Functional in Firmware V3.143.60 and higher

This word (Byte 37->MSB, Byte 38->LSB) will indicate the number of times the master has passed midnight (starts with V3.143.60)

Functional in Firmware V3.143.78 and higher

This bytes will indicate if the Roller/shutters are locked or if these are in normal mode. Roller/shutters can be locked to perform maintenance or to perform cleaning activities. If x>0 -> Roller/shutter is in normal mode. If x=0 -> Roller/shutter is in lock mode.

General Thermostat function enable/disable: This byte will enable or disable the full thermostat function of the master. When byte40=255, then the thermostat function is enabled, when byte40<255, then the thermostat function is disabled.

Wait time Dali (*1.6ms): This is the maximum wait time between 2 Dali messages (when no Dali feedback is received). When Eeprom wait time byte>50 then wait time = 20 (default value-> 20*1,6ms). Max wait time = 50 (*1,6ms).

Every input can be disabled/enabled by using Basic Actions. This byte will enable/disable this function. When byte==255 -> inputs can be disabled, when byte<255 -> inputs are always enabled even when BA's should disable an input.

This byte will give feedback if the RTC (Real Time Clock) was running (byte=255) of stopped (byte=0, battery empty for example) after the last reset. Please note that this byte is only reliable after a power reset (when doing a soft reset, the power remains on the hardware and the clock won't be stopped if for example the battery is empty).

Functional in Firmware CAN Control V3.1.35 and higher

Maximum number of tries before a sensor is taken offline: The CAN control will request sensor information from the uCAN. This value will indicate the number of tries the CAN control will perform before the sensor will be displayed as disconnected. Minimum value is 2, maximum is 254. When Value 0, 1 or 255 is programmed in Eeprom, the standard value of 2 will be used.

Functional in Firmware V3.143.18 and higher

Maximum number of thermostats: A standard installation has a maximum of 24 thermostats. This can be increased to maximum 32 thermostats. The value that can be write in this byte is between 24 and 32 (24 and 32 included).

The thermostat API instructions "AR", "AW", "pL", "SL", "ml", "tl" and "TL" will have a variable number of bytes depending on the maximum number of thermostats defined in this eeprom value. See API Reference Guide.

When the Eeprom value=255 then the standard 24 thermostats are configured. Values below 24 and higher then 32 are considered as a standard installation with a maximum of 24 thermostats.

Changing this value will only have effect after performing the CLI instruction "eeprom activate" or the corresponding API instruction.

Temperature Offset: Every temperature sensor (0-31) has a temperature offset that can be programmed. Every offset value has 8 bits, the first 4 (LSB) bits contain the offset temperature, the last (MSB) bit contains the sign (1=-, 0=+). When for example the offset[x] is 7 and the sign is 1 (BIN 10000111, DEC 135), 3.5 degree Celsius will be deducted from the sensor[x] temperature. The maximum offset is +/-15 (+/-7.5 degree Celsius). When the offset is 255, the offset will be ignored.

Input Filter Value (1-254): When an input controller checks his input, the filter value indicates the number of times an input check has to be the same value before accepted. Typical value is 10 (when eeprom is at standard value 255, 10 will be used), when putting at 100 for example, the input has to be hold longer before the system will see it as a button change.

Byte93: Force CRC: Communication with input modules can be done with or without CRC. Modules with newer firmware (2.1.8 and higher) have CRC checks included. When byte93<255 then CRC check is enabled (when enabled, modules with older firmware will not work and will give error 27). When byte93=255, CRC is disabled.

Byte94: Enable Bootload debug information for the CAN Control module: The boatload in the CAN Control has a built-in boot loader that can output debug information on the RS232 port on the CAN Control. It's however possible to connect other equipment on the RS232 port so at that moment you don't want the boot loader to output debug information. When byte94=255 then the Bootloader debug output on all the connected CAN Controls are disabled, when byte94=0 then the boot loader debug output will be enabled.

Note: Changing settings in the eeprom of the Master must be synchronised with the eeprom of the CAN Control. This synchronisation process is an automatic proces but this can take multiple minutes before this setting is active.

CAN Control Health Check: These 2 bytes (word) represents the Maximum CAN Control errors before the Master will power reset the RS485 Bus. Byte 95 -> MSB, Byte 96 -> LSB. The check will be performed every 10 minutes, when the CAN Control errors are higher than this Eeprom word, the RS485 Bus will get a power reset. If Byte 95 and 96 are = 255, the default value (150) is used. See also Byte 97.

CAN Control Health Check: This byte represents the maximum number of power resets that can be performed by the CAN Control health check routine during a period of 24 hours. When this byte=255, the default value (1) will be used.

CAN Control Health Check: This byte represents the number of RS485 power resets that have happened due to CAN Control Health Check. This byte is written by the Master and should not be programmed using CLI or API. When this byte is equal to 255 or 0, no power resets.

These 128 bytes are reserved to be used by the Oled controller. The Oled controller is an input module that can be added on the Bus. When one or more Oled controllers are added, the Oled controllers will sync their eeprom with the master eeprom so all data available in the master is also available at the remote Oled displays. The Full eeprom is synced except the last 128 bytes of page 0 since these 128 bytes are used for the local Oled controller settings and data.

Byte 128: Mod_NE (indicates if new “N” or existing “E” Oled module)

Byte 129: Mod_ID0 (first of the 4 network ID numbers)

Byte 130: Mod_ID1

Byte 131: Mod_ID2

Byte 132: Mod_ID3

Byte133: Enable/Disable Touch screen byte: When touch screen byte=0 -> Touch screen is not active and will not respond to any touches on the screen, when touch screen byte>0 -> Touch screen is active and can be used. This byte can be set by using basic action 233.

Display time out Byte (1-255): This byte will set the time (Display Time out byte x 1,2s) for the display to switch off when no touch screen action occurred. When the Display time byte =0, the display time out byte will be set to 255 (5 minutes). This byte can be set by using basic action 232.

On the input modules, Pulse counters can be connected to measure consumption of water, gas, electricity etc. A maximum of 24 pulsecounter devices can be connected on any input on any input module that is available in your Renson Smart Living system. Which Pulsecounter is linked to which input can be found below:

Byte 160: Pulsecounter input for Pulsecounter 0

Byte 161: Pulsecounter input for Pulsecounter 1

Byte 162: Pulsecounter input for Pulsecounter 2

...

Byte 183: Pulsecounter input for Pulsecounter 23

Startup Page (Page 1)

Page 1 -> Start up page

In this page, all the Basic Actions (see Action Types) that need to be performed at startup of the Master Controller can be found back in this page. In total, 100 (0-99) Basic Actions can be defined.

Each “start up” Basic Action is defined by 2 bytes:

• Action Type Byte

• Action Number Byte

Total of 100 startup actions can be defined

Byte0-1: Startup action 0 (Action type + action number)

Byte2-3: Startup action 1 (Action type + action number)

Byte4-5: startup action 2 (Action type + action number)

…

Byte 198-199: startup action 99 (Action type + action number)

Data input modules

input data (Page 2-31)

Page 2 - 31 -> Contains data of the input modules (30 modules maximum (0-29), 0 – 239 inputs)

The input data can be found back from page 2 till page 32. These Pages that contains active data depending on Page0/Byte1.

Every input Module has its own input page:

This page is entirely used for input module 0.

This page is entirely used for input module 1.

This page is entirely used for input module 2.

...

This page is entirely used for input module 29.

Every input page has following structure

The below bytes contains the ID of the Input module

Byte 0: Type device (ASCII integer, virtual modules are with a lower case, physical modules are upper case)

• 105 → i → virtual input module

• 73 → I → physical input module

Byte 1: ID1 (Byte 0 and ID1, 2, 3 gives the unique ID of each remote device connected to the Microcontroller main board)

Byte 2: ID2

Byte 3: ID3

Input Link byte: Each input device has maximum 8 inputs (byte 4 -> input link byte for input 0, byte 5 -> input link byte for input 1, ... , byte 11 -> input link byte for input 7). When an input is activated (button is pressed), the master controller will check the input link byte for that input. When the input link byte is below 240 (0-239 are valid outputs), toggle function is activated of the output written in the input link byte. Each input has a list of 15 Basic actions that can be activated when the button is pressed or input is activated. When the input link byte of that input = 240, the list of Basic actions linked to that input will be activated.

Example1: Page3/byte9 = 10, when input 5 of input device 1 is activated (button pressed), output 10 (output device 1 output 2) will toggle.

Example2: Page3/byte9 = 240, when input 5 of input device 1 is activated (button pressed), input 5 intelligent action will be activated. When byte = 241, all outputs will be switched off (Special group action list all off).

Each input can activate 15 intelligent Basic Actions (when the input link byte = 240). Each Basic Action (see Action Types) is defined in 2 bytes: action type and action number. Action type will define what type of action needs to be performed like switch ON light, change thermostat mode, IF THEN ELSE action etc.

If the input toggling byte = 240, then the intelligent action in the following bytes will be called. For input 0 the 15 (maximum) intelligent actions will be defined from byte 12 to 41. Every intelligent function is defined in 2 bytes (action type and action number). Byte 12 (action type) and byte 13 (action number) will define the first action for input 0, byte 14 (action type) and byte 15 (action number) will define the second action for input 0 etc

Below, more details can be found around the 15 Basic action per input.

define maximum 15 intelligent action for input 0

define maximum 15 intelligent action for input 1

define maximum 15 intelligent action for input 2

define maximum 15 intelligent action for input 3

define maximum 15 intelligent action for input 4

define maximum 15 intelligent action for input 5

define maximum 15 intelligent action for input 6

define maximum 15 intelligent action for input 7

Input modules can be created as normal input modules or by using a CAN control. When using a CAN control, a number of input modules are created in the Master (of the Gateway). To know the difference between normal input modules and input modules created by a CAN control, this byte is used. When this byte contains the value 67 ("C"), then the input module has been created by a CAN control, any other value means it has been created by an input module.

This byte is used as of F3.142.19

This is not yet implemented

Byte 253: Firmware Version F1 (Major)

Byte 254: Firmware Version F2 (Minor)

Byte 255: Firmware Version F3 (Built)

Inverted input data (Page 32)

Page 32 -> Inverted status of the inputs

On the different inputs of the Renson Smart Living system, both NC (normally close) and NO (normally open) switches can be connected. In this page, you can program for each input if the input is NO or NC. Standard, all inputs are programmed as NO (invert byte = 255).

Indicates the invert status of input 0. If Byte=255 then the input acts as a NO input. When Byte<255 then the input acts as NC input.

Indicates the invert status of input 1. If Byte=255 then the input acts as a NO input. When Byte<255 then the input acts as NC input.

…

Indicates the invert status of input 239. If Byte=255 then the input acts as a NO input. When Byte<255 then the input acts as NC input.

Input switch type (Page 97)

Page 97 -> Switch type used

On the different inputs of the Renson Smart Living system, both push buttons or toggle switches can be connected. In this page, you can program for each input which type of switch is connected. As a standard value, all inputs are programmed as Push Button switch (switch type byte = 255).

Note: In normal circumstances, any type of push button can be used. However, when a toggle switch is used, that switch will have less functionality (no dim function for that switch and no long press functionality)

Indicates the switch type of input 0. If Byte=255 then the input is programmed as push button. When Byte<255 then the input is programmed as a toggle switch.

Indicates the switch type of input 1. If Byte=255 then the input is programmed as push button. When Byte<255 then the input is programmed as a toggle switch.

…

Indicates the switch type of input 239. If Byte=255 then the input is programmed as push button. When Byte<255 then the input is programmed as a toggle switch.

Input Follow Function (Page 230)

Page 230 -> Indicates if input follow function is activated.

The Input Follow Function will enable the system that an Output follows an input in other words, when the input is switched on, the output will be switched on, when the input of off, the output will be off. The input follow function will only work when the switch type is programmed as toggle switch (see Page 97)

To enable this function and to do this via the CLI (as an example, we will enable input 10 as input follow function that will switch output 20):

• Link the input with an output: "input link write 10 20"

• Program the input as a Toggle switch: "eeprom write 97 10 0"

• Enable the input Follow Function: "eeprom write 230 10 0"

• Copy eeprom values in to RAM: "eeprom activate"

• If the behaviour is inverted (Input ON -> Output OFF), you can change the input by using instruction "eeprom write 32 10 0" which will configure input 10 as NC, "eeprom write 32 10 255" will configure input 10 as NO (standard setting). "eeprom activate" needs to be done after a change.

• Make sure the outputs used in the above configuration have no timer set. Use following CLI instruction to switch off the timer (for example output 20): "output timer write 20 0"

Indicates the input Follow Function of input 0. If Byte=255 then the input Follow Function is disabled, when Byte<255 then the Input Follow Function is enabled.

Indicates the input Follow Function of input 1. If Byte=255 then the input Follow Function is disabled, when Byte<255 then the Input Follow Function is enabled.

…

Indicates the input Follow Function of input 239. If Byte=255 then the input Follow Function is disabled, when Byte<255 then the Input Follow Function is enabled.

ascii names inputs (Page 115-122)

Page 115 – 122: ascii names of inputs

The Master can store an 8 bytes ascii name for every possible input (0-239). Those names are stored in the built-in eeprom of the Master controller.

ascii name of input 0

ascii name of input 1

…

ascii name of input 31

ascii names of input 32-63

ascii names of input 64-95

ascii names of input 96-127

ascii names of input 128-159

ascii names of input 160-191

ascii names of input 192-223

ascii names of input 224-239

Pulse counter names (Page 98-99)

Page 98 - 99: Pulse Counter Name

Every input module has a Pulse Counter integrated so Power meters, Gas meters and water meters based on pulses can be easily connected to the Renson Smart Living system.

Maximum 24 pulse counters (spread over all your input modules) can be configured. In the current firmware versions, the pulse counters are not yet available for micro CAN modules.

Byte 0 – 15 -> ascii name of Pulse Counter 0

Byte 16 - 31 -> ascii name of Pulse Counter 1

...

Byte 240 - 255 -> ascii name of Pulse Counter 15

Byte 0 – 15 -> ascii name of Pulse Counter 16

Byte 16 - 31 -> ascii name of Pulse Counter 17

...

Byte 240 - 255 -> ascii name of Pulse Counter 31

Notes:

• Every Pulse counter has an input linked, these inputs are stored at Page0 Byte 160-183

• Earlier Firmware versions then F3.141.18 used page 195 (for pulsecounter name) and only 8 Pulsecounters were allowed

• Firmware versions F3.141.18 and higher can use up to 24 Pulse counters and the page for pulsecounter names are pages 98 and 99

• The number of names that can be defined is 32 but only 24 are used.

Data output modules

Page 33 – 62 -> Contains data of the output modules (30 modules maximum, 0 – 239 outputs)

The output data can be found back from page 33 till page 62. These Pages that contains active data depending on Page0/Byte2 and Page0/Byte3.

The Roller/Shutter data for Large Installation can also be found back from page 33 till page 62. These Pages contains active data which entirely depends on the number of Roller/Shutter modules defined in Page0/Byte3.

Please Note that the Normal Output data and the Large Installation data are written in the same pages. The data for the Normal outputs ranges from byte 0 to 172, the Large Installation data starts at byte 173. The data of the normal outputs and the data of the Large installation are not related to each other and are different modules.

Every output Module has its own output page which contains the normal output data and the Large installation data of the Roller/Shutter modules:

This page is entirely used for output module 0.

This page is entirely used for output module 1.

This page is entirely used for output module 2.

...

This page is entirely used for output module 29.

Every output page has following structure

Output data (Page 33-62)

Byte 0: Type device (ASCII integer, virtual modules are with a lower case, physical modules are upper case)

• 111 → o → virtual output module

• 79 → O → physical output module

• 114 → r → virtual shutter module

• 82 → R → physical shutter module

• 100 → d → virtual dimmer module

• 68 → D → physical dimmer module

Byte 1: ID1 (ID1, 2, 3 gives the unique ID of the device)

Byte 2: ID2

Byte 3: ID3

Standard Timer values for an output to be used. Each timer value has a word format and is programmed in 2 bytes (first byte LSB). When timer word = 0: Timer is not activated.

Byte 4 (LSB) and 5 (MSB) will specify the timer value for output 0

Byte 6 (LSB) and 7 (MSB) will specify the timer value for output 1

...

Byte 18 (LSB) and 19 (MSB) will specify the timer value for output 7

ascii Names outputs (Page 33-62)

Byte 20 – 35: ascii name of the first output of this module (16 characters)

Byte 36 – 51: ascii name of the second output of this module (16 characters)

…

Byte 132 – 147: ascii name of the last output (16 characters)

Additional Output data (Page 33-62)

Byte 149: Output type byte output0 (0-127: standard output, 128-255: Light output)

Byte 150: Output Type byte output1 (0-127: standard output, 128-255: Light output)

…

Byte 156: Output Type byte output7 (0-127: standard output, 128-255: Light output)

Output Type byte will indicate if the indicated output is a light or not. When specific instruction (by using action type 163 for example) to switch off a light will be used, only lights (and not outputs) will be switched off.

Byte 157: Floor Level of output 0 (=0: main floor, =1: first floor, =2: second floor, =3: third floor etc =255: function not used)

Byte 158: Floor Level of output 1

…

Byte 164: Floor Level of output 7

Floor level is been used to group lights of a certain floor level and to switch them off together (by using action type 171 for example). To be able to do this, those lights needs to be in the same group and needs to have the Output type Byte>0.

Byte 165: Menu Position of output 0 (which position will this output get in the pronto menus/PC menus, 255-> no position)

Byte 166: Menu Position of output 1

…

Byte 172: Menu Position of output 7

Roller/Shutter Module ID in Large Installation mode (Page 33-62)

Byte 173: Type device (Should be always “R”)

Byte 174: ID1 (ID1, 2, 3 gives the unique ID of the device)

Byte 175: ID2

Byte 176: ID3

Up/Down Timer settings of an individual Roller/Shutter in Large Installation mode (Page 33-62)

Byte 177: Up Timer for Roller/Shutter 0

Byte 178: Down Timer for Roller/Shutter 0

Byte 179: Up Timer for Roller/Shutter 1

Byte 180: Down Timer for Roller/Shutter 1

…

Byte 183: Up Timer for Roller/Shutter 3

Byte 184: Down Timer for Roller/Shutter 3

Note: When the timer setting is 255, the Master controller will set the default timer setting which is 249 seconds. Timer setting 250-254 cannot be used.

Roller/Shutter config byte in Large Installation mode (Page 33-62)

Byte 185: config byte for Roller/Shutter0.

• BIT0 (Least significant): UP/DOWN config BIT: If BIT0=1 then the first output of the 2 outputs will be the UP direction (and the other output will be the DOWN direction), if BIT0=0 then the second output will be the UP direction

• BIT1: Not used yet

• BIT2: Not used yet

• BIT3: Not used yet

• BIT4: Not used yet

• BIT5: Not used yet

• BIT6: Not used yet

• BIT7 (Most significant): Not used yet

Byte 186: config byte for Roller/Shutter1.

• BIT0 (Least significant): UP/DOWN config BIT: If BIT0=1 then the first output of the 2 outputs will be the UP direction (and the other output will be the DOWN direction), if BIT0=0 then the second output will be the UP direction

• BIT1: Not used yet

• BIT2: Not used yet

• BIT3: Not used yet

• BIT4: Not used yet

• BIT5: Not used yet

• BIT6: Not used yet

• BIT7 (Most significant): Not used yet

Byte 187: config byte for Roller/Shutter2.

• BIT0 (Least significant): UP/DOWN config BIT: If BIT0=1 then the first output of the 2 outputs will be the UP direction (and the other output will be the DOWN direction), if BIT0=0 then the second output will be the UP direction

• BIT1: Not used yet

• BIT2: Not used yet

• BIT3: Not used yet

• BIT4: Not used yet

• BIT5: Not used yet

• BIT6: Not used yet

• BIT7 (Most significant): Not used yet

Byte 188: config byte for Roller/Shutter3.

• BIT0 (Least significant): UP/DOWN config BIT: If BIT0=1 then the first output of the 2 outputs will be the UP direction (and the other output will be the DOWN direction), if BIT0=0 then the second output will be the UP direction

• BIT1: Not used yet

• BIT2: Not used yet

• BIT3: Not used yet

• BIT4: Not used yet

• BIT5: Not used yet

• BIT6: Not used yet

• BIT7 (Most significant): Not used yet

ascii name for each Roller/Shutter in Large Installation mode (Page 33-62)

Byte 189-204: ascii name of Roller/Shutter0

Byte 205-220: ascii name of Roller/Shutter1

Byte 221-236: ascii name of Roller/Shutter2

Byte 237-252: ascii name of Roller/Shutter3

Group page in Large Installation mode (Page 63)

Each Roller/Shutter in a Large Installation can be part of a group (0-29). When a Roller/shutter group action (104-107) is executed, all Roller/shutters that contain to that group will be activated.

Byte 0: First group assignment for Roller/Shutter 0

Byte 1: Second group assignment for Roller/Shutter 0

Byte 2: First group assignment for Roller/Shutter 1

Byte 3: Second group assignment for Roller/Shutter 1

Byte 4: First group assignment for Roller/Shutter 2

Byte 5: Second group assignment for Roller/Shutter 2

Byte 6: First group assignment for Roller/Shutter 3

Byte 7: Second group assignment for Roller/Shutter 3

…

Up/Down Timer settings of a group of Roller/Shutters in Large Installation mode (Page 64)

When Basic Action 104-107 is used, the group of Roller/shutters will use the below timer values.

Byte 0: Group 0 Timer up value (0-249s)

Byte 1: Group 0 Timer down value (0-249s)

Byte 2: Group 1 Timer up value (0-249s)

Byte 3: Group 1 Timer down value (0-249s)

Byte 4: Group 2 Timer up value (0-249s)

Byte 5: Group 2 Timer down value (0-249s)

Byte 6: Group 3 Timer up value (0-249s)

Byte 7: Group 3 Timer down value (0-249s)

…

Note: When the timer setting is 255, the Master controller will set the default timer setting which is 249 seconds. Timer setting 250-254 cannot be used.

Dimmer follow output (Page 65)

For outputs that need to follow another output, the Renson Smart Living system allows you to program a "follow" function (1 output that follows the other). An example is a 0-10V dimmer: Some dimmers on the market don't switch off completely meaning that you need to put the dimmer on a relay output as well. At that moment, the dimmer output will be leading and the relay output will follow. Another example is that you've 2 outputs for the same light or output so 1 output needs to follow the other (if the first output goes on, the "follow" output will follow, the same when the output or light goes off).

Byte 0: Following Output Nr for Output 0

Byte 1: Following Output Nr for Output 1

Byte 2: Following Output Nr for Output 2

Byte 3: Following Output Nr for Output 3

Byte 4: Following Output Nr for Output 4

Byte 5: Following Output Nr for Output 5

Byte 6: Following Output Nr for Output 6

Byte 7: Following Output Nr for Output 7

…

Byte 239: Following Output Nr for Output 239

Example: When a dimmer on output 7 can be completely switched off, so it's attached on a relay on output nr 32, the system can be configured that output 32 follows output 7 by setting byte 7 to 32. (eeprom write 65 7 32)

Note: The same can also be accomplished by using Basic Actions

Group action follow output (Page 66)

A group action can be defined that will be executed on output change in other words, a group action can follow an individual output. One group action can be defined for every output, that same group action will be executed on every output change.

Byte 0: Group Nr for Output 0

Byte 1: Group Nr for Output 1

Byte 2: Group Nr for Output 2

Byte 3: Group Nr for Output 3

Byte 4: Group Nr for Output 4

Byte 5: Group Nr for Output 5

Byte 6: Group Nr for Output 6

Byte 7: Group Nr for Output 7

…

Byte 239: Group Nr for Output 239

CAN LED follow output (Page 221-228)

Available in Firmware Version V3.142.13 and higher

Each output can trigger up to 4 CAN led functions in other words the LED will follow the behavior of the output.

On the CAN button module, leds can be used to perform different indications. For example: A led must go ON when a light in the bathroom is ON. The different functions and different possible led indications (led and led brightness, flashing etc) are programmed on the following pages. The system can have maximum 240 CAN leds. Each output (normal or virtual) can trigger up to 4 led functions.

Each function is described in 2 bytes:

• Led nr: Each CAN switch has a Led linked to it. The input number is the same as the Led nr.

• Led function: This byte will represent what the leds needs to do at what brightness. See Led function for all details.

Interested to know how to use the CAN Gateway? See the CAN Gateway install pages.

For more information regarding the Can Controller Release notes see CAN Controller Release Notes

8 pages are used to cover the 4 functions of all 240 outputs

Byte 0 -> Function 1: Led Nr (0-239) for Output 0

Byte 1 -> Function 1: Led function for Output 0

Byte 2 -> Function 2: Led Nr (0-239) for Output 0

Byte 3 -> Function 2: Led function for Output 0

...

Byte 6 -> Function 4: Led Nr (0-239) for Output 0

Byte 7 -> Function 4: Led function for Output 0

Byte 8 -> Function 1: Led Nr (0-239) for Output 1

Byte 9 -> Function 1: Led function for Output 1

Byte 10 -> Function 2: Led Nr (0-239) for Output 1

Byte 11 -> Function 2: Led function for Output 1

...

Byte 14 -> Function 4: Led Nr (0-239) for Output 1

Byte 15 -> Function 4: Led function for Output 1

...

Byte 248 -> Function 1: Led Nr (0-239) for Output 31

Byte 249 -> Function 1: Led function for Output 31

Byte 250 -> Function 2: Led Nr (0-239) for Output 31

Byte 251 -> Function 2: Led function for Output 31

...

Byte 254 -> Function 4: Led Nr (0-239) for Output 31

Byte 255 -> Function 4: Led function for Output 31

Byte 0 -> Function 1: Led Nr (0-239) for Output 32

Byte 1 -> Function 1: Led function for Output 32

Byte 2 -> Function 2: Led Nr (0-239) for Output 32

Byte 3 -> Function 2: Led function for Output 32

...

Byte 6 -> Function 4: Led Nr (0-239) for Output 32

Byte 7 -> Function 4: Led function for Output 32

...

CAN LED depending on the Number of outputs/lights ON (Page 229)

Available in Firmware Version V3.142.13 and higher

The leds can also behave depending on the number of outputs and/or lights that are ON. This is useful, for example, before leaving the house to know if some of the lights are still on.

An other example: When more than 3 lights are ON, let one of the leds flicker slowly, when more then 5 lights are ON, let if flicker faster, when more than 7 lights are ON, let it flicker fast.

Every output can be configured to be a light or output (see Eeprom Page 33-62 byte 149-156). When an output is ON, it will be added to the NrOfOutputs that are ON. When a lights is ON, it will be added to the NrOfLights that are ON.

Different conditions can be programmed which are related to the NrOfLights and the NrOfOutputs that are ON. Each condition can switch ON/OFF up to 4 leds.

Each function is described in 2 bytes:

• Led nr: Each CAN switch has a Led linked to it. The input number is the same as the Led nr.

• Led condition function: This byte will represent the functionality and the brightness of the led. See Led condition function for all details.

Important Note: When you for example switch ON a led when all lights are off by programming page 229 byte 0-7, this led will not be switched off when the number of lights are >0 unless you explicitly program this by for example programming Page 229 byte 8-15 with a Led condition function = 128.

Interested to know how to use the CAN Gateway? See the CAN Gateway install pages.

For more information regarding the Can Controller Release notes see CAN Controller Release Notes

When the NrOfLights=0 then execute below

Byte 0 -> Function 1: Led Nr (0-239)

Byte 1 -> Function 1: Led condition function

Byte 2 -> Function 2: Led Nr (0-239)

Byte 3 -> Function 2: Led condition function

...

Byte 6 -> Function 4: Led Nr (0-239)

Byte 7 -> Function 4: Led condition function

When the NrOfLights>0 then execute below

Byte 8 -> Function 1: Led Nr (0-239)

Byte 9 -> Function 1: Led condition function

Byte 10 -> Function 2: Led Nr (0-239)

Byte 11 -> Function 2: Led condition function

...

Byte 14 -> Function 4: Led Nr (0-239)

Byte 15 -> Function 4: Led condition function

When the NrOfLights>1 then execute below

Byte 16 -> Function 1: Led Nr (0-239)

Byte 17 -> Function 1: Led condition function

Byte 18 -> Function 2: Led Nr (0-239)

Byte 19 -> Function 2: Led condition function

...

Byte 22 -> Function 4: Led Nr (0-239)

Byte 23 -> Function 4: Led condition function

When the NrOfLights>2 then execute below

Byte 24 -> Function 1: Led Nr (0-239)

Byte 25 -> Function 1: Led condition function

Byte 26 -> Function 2: Led Nr (0-239)

Byte 27 -> Function 2: Led condition function

...

Byte 30 -> Function 4: Led Nr (0-239)

Byte 31 -> Function 4: Led condition function

When the NrOfLights>3 then execute below

Byte 32 -> Function 1: Led Nr (0-239)

Byte 33 -> Function 1: Led condition function

Byte 34 -> Function 2: Led Nr (0-239)

Byte 35 -> Function 2: Led condition function

...

Byte 38 -> Function 4: Led Nr (0-239)

Byte 39 -> Function 4: Led condition function

...

When the NrOfLights>14 then execute below

Byte 120 -> Function 1: Led Nr (0-239)

Byte 121 -> Function 1: Led condition function

Byte 122 -> Function 2: Led Nr (0-239)

Byte 123 -> Function 2: Led condition function

...

Byte 126 -> Function 4: Led Nr (0-239)

Byte 127 -> Function 4: Led condition function

When the NrOfOutputs=0 then execute below

Byte 128 -> Function 1: Led Nr (0-239)

Byte 129 -> Function 1: Led condition function

Byte 130 -> Function 2: Led Nr (0-239)

Byte 131 -> Function 2: Led condition function

...

Byte 134 -> Function 4: Led Nr (0-239)

Byte 135 -> Function 4: Led condition function

When the NrOfOutputs>0 then execute below

Byte 136 -> Function 1: Led Nr (0-239)

Byte 137 -> Function 1: Led condition function

Byte 138 -> Function 2: Led Nr (0-239)

Byte 139 -> Function 2: Led condition function

...

Byte 142 -> Function 4: Led Nr (0-239)

Byte 143 -> Function 4: Led condition function

When the NrOfOutputs>1 then execute below

Byte 144 -> Function 1: Led Nr (0-239)

Byte 145 -> Function 1: Led condition function

Byte 146 -> Function 2: Led Nr (0-239)

Byte 147 -> Function 2: Led condition function

...

Byte 150 -> Function 4: Led Nr (0-239)

Byte 151 -> Function 4: Led condition function

When the NrOfOutputs>2 then execute below

Byte 152 -> Function 1: Led Nr (0-239)

Byte 153 -> Function 1: Led condition function

Byte 154 -> Function 2: Led Nr (0-239)

Byte 155 -> Function 2: Led condition function

...

Byte 158 -> Function 4: Led Nr (0-239)

Byte 159 -> Function 4: Led condition function

When the NrOfOutputs>3 then execute below

Byte 160 -> Function 1: Led Nr (0-239)

Byte 161 -> Function 1: Led condition function

Byte 162 -> Function 2: Led Nr (0-239)

Byte 163 -> Function 2: Led condition function

...

Byte 166 -> Function 4: Led Nr (0-239)

Byte 167 -> Function 4: Led condition function

...

When the NrOfOutputs>14 then execute below

Byte 248 -> Function 1: Led Nr (0-239)

Byte 249 -> Function 1: Led condition function

Byte 250 -> Function 2: Led Nr (0-239)

Byte 251 -> Function 2: Led condition function

...

Byte 254 -> Function 4: Led Nr (0-239)

Byte 255 -> Function 4: Led condition function

DALI pages (Page 100-103)

The Renson Smart Living system supports the use of DALI equipment. For more information, please see DALI Installation Guide

The CAN Control is used as DALI gateway and has all the logic inside to drive dimmers and different kind of ballasts. The CAN Control cannot directly be connected to the DALI bus since a RS232 DALI convertor is needed (as well as a DALI power supply which you always need when building a DALI bus).

We use the RS232 convertor from Lunatone called the SCI. The SCI is connected to the RS232 connection of the CAN control. The CAN functionality as well as DALI functionality can be used simultaneously.

Every DALI bus can have up to 64 devices. 1 CAN Control can handle 1 DALI bus of 64 devices. Every DALI device has an ID between 0 and 63. The ID’s are assigned by using the Lunatone cockpit software which will be described further in detail in a later section.

Every CAN control can also be linked to Dali inputs (like motion sensor) with address (0-63). When the Dali Motion sensor detects motion, the linked input will be triggered. Lunatone and Helvar inputs are supported. In the below page, the Dali inputs (Max. 16 per CAN control) can be programmed, the linking between Dali input and CAN Control input is done automatically.

Once the ID’s are assigned by using Lunatone Cockpit software, the ID’s are entered in the Gateway eeprom.

Since maximum 4 CAN Controls can be connected to 1 gateway (Maximum 240 DALI devices), 4 Eeprom pages are used to program the DALI ID’s. Part of each page are used to program the Relay DALI ballast, the other part of the eeprom page is used to program the ballast with dim functionality.

In every page, Byte 0-63 is used to program the ballast with switch only capacity (like a relay), byte 64-127 is used to program ballasts with dim functionality, byte 128-143 for Lunatone/Helvar Inputs (Max. 16)

Byte 0 -> DALI ID (0-63) of switched DALI output 0 of first DALI network (first CAN Control initialised)

Byte 1 -> DALI ID (0-63) of switched DALI output 1 of first DALI network (first CAN Control initialised)

Byte 2 -> DALI ID (0-63) of switched DALI output 2 of first DALI network (first CAN Control initialised)

Byte 3 -> DALI ID (0-63) of switched DALI output 3 of first DALI network (first CAN Control initialised)

...

Byte 62 -> DALI ID (0-63) of switched DALI output 62 of first DALI network (first CAN Control initialised)

Byte 63 -> DALI ID (0-63) of switched DALI output 63 of first DALI network (first CAN Control initialised)

Byte 64 -> DALI ID (0-63) of Dimmed DALI output 0 of first DALI network (first CAN Control initialised)

Byte 65 -> DALI ID (0-63) of Dimmed DALI output 1 of first DALI network (first CAN Control initialised)

Byte 66 -> DALI ID (0-63) of Dimmed DALI output 2 of first DALI network (first CAN Control initialised)

Byte 67 -> DALI ID (0-63) of Dimmed DALI output 3 of first DALI network (first CAN Control initialised)

...

Byte 126 -> DALI ID (0-63) of Dimmed DALI output 62 of first DALI network (first CAN Control initialised)

Byte 127 -> DALI ID (0-63) of Dimmed DALI output 63 of first DALI network (first CAN Control initialised)

Byte 128: Contains Dali ID x of Lunatone first input (when x<64) or with Dali ID x-64 of Helvar input (when x>63 and x<128)

Byte 129: Contains Dali ID x of Lunatone second input (when x<64) or with Dali ID x-64 of Helvar input (when x>63 and x<128)

…

Byte 143: Contains Dali ID x of Lunatone last input (when x<64) or with Dali ID x-64 of Helvar input (when x>63 and x<128)

Byte 0 -> DALI ID (0-63) of switched DALI output 0 of second DALI network (second CAN Control initialised)

Byte 1 -> DALI ID (0-63) of switched DALI output 1 of second DALI network (second CAN Control initialised)

Byte 2 -> DALI ID (0-63) of switched DALI output 2 of second DALI network (second CAN Control initialised)

Byte 3 -> DALI ID (0-63) of switched DALI output 3 of second DALI network (second CAN Control initialised)

...

Byte 62 -> DALI ID (0-63) of switched DALI output 62 of second DALI network (second CAN Control initialised)

Byte 63 -> DALI ID (0-63) of switched DALI output 63 of second DALI network (second CAN Control initialised)

Byte 64 -> DALI ID (0-63) of Dimmed DALI output 0 of second DALI network (second CAN Control initialised)

Byte 65 -> DALI ID (0-63) of Dimmed DALI output 1 of second DALI network (second CAN Control initialised)

Byte 66 -> DALI ID (0-63) of Dimmed DALI output 2 of second DALI network (second CAN Control initialised)

Byte 67 -> DALI ID (0-63) of Dimmed DALI output 3 of second DALI network (second CAN Control initialised)

...

Byte 126 -> DALI ID (0-63) of Dimmed DALI output 62 of second DALI network (second CAN Control initialised)

Byte 127 -> DALI ID (0-63) of Dimmed DALI output 63 of second DALI network (second CAN Control initialised)

Byte 128: Contains Dali ID x of Lunatone first input (when x<64) or with Dali ID x-64 of Helvar input (when x>63 and x<128)

Byte 129: Contains Dali ID x of Lunatone second input (when x<64) or with Dali ID x-64 of Helvar input (when x>63 and x<128)

…

Byte 143: Contains Dali ID x of Lunatone last input (when x<64) or with Dali ID x-64 of Helvar input (when x>63 and x<128)

Byte 0 -> DALI ID (0-63) of switched DALI output 0 of third DALI network (third CAN Control initialised)

Byte 1 -> DALI ID (0-63) of switched DALI output 1 of third DALI network (third CAN Control initialised)

Byte 2 -> DALI ID (0-63) of switched DALI output 2 of third DALI network (third CAN Control initialised)

Byte 3 -> DALI ID (0-63) of switched DALI output 3 of third DALI network (third CAN Control initialised)

...

Byte 62 -> DALI ID (0-63) of switched DALI output 62 of third DALI network (third CAN Control initialised)

Byte 63 -> DALI ID (0-63) of switched DALI output 63 of third DALI network (third CAN Control initialised)

Byte 64 -> DALI ID (0-63) of Dimmed DALI output 0 of third DALI network (third CAN Control initialised)

Byte 65 -> DALI ID (0-63) of Dimmed DALI output 1 of third DALI network (third CAN Control initialised)

Byte 66 -> DALI ID (0-63) of Dimmed DALI output 2 of third DALI network (third CAN Control initialised)

Byte 67 -> DALI ID (0-63) of Dimmed DALI output 3 of third DALI network (third CAN Control initialised)

...

Byte 126 -> DALI ID (0-63) of Dimmed DALI output 62 of third DALI network (third CAN Control initialised)

Byte 127 -> DALI ID (0-63) of Dimmed DALI output 63 of third DALI network (third CAN Control initialised)

Byte 128: Contains Dali ID x of Lunatone first input (when x<64) or with Dali ID x-64 of Helvar input (when x>63 and x<128)

Byte 129: Contains Dali ID x of Lunatone second input (when x<64) or with Dali ID x-64 of Helvar input (when x>63 and x<128)

…

Byte 143: Contains Dali ID x of Lunatone last input (when x<64) or with Dali ID x-64 of Helvar input (when x>63 and x<128)

Byte 0 -> DALI ID (0-63) of switched DALI output 0 of fourth DALI network (fourth CAN Control initialised)

Byte 1 -> DALI ID (0-63) of switched DALI output 1 of fourth DALI network (fourth CAN Control initialised)

Byte 2 -> DALI ID (0-63) of switched DALI output 2 of fourth DALI network (fourth CAN Control initialised)

Byte 3 -> DALI ID (0-63) of switched DALI output 3 of fourth DALI network (fourth CAN Control initialised)

...

Byte 62 -> DALI ID (0-63) of switched DALI output 62 of fourth DALI network (fourth CAN Control initialised)

Byte 63 -> DALI ID (0-63) of switched DALI output 63 of fourth DALI network (fourthCAN Control initialised)

Byte 64 -> DALI ID (0-63) of Dimmed DALI output 0 of fourth DALI network (fourth CAN Control initialised)

Byte 65 -> DALI ID (0-63) of Dimmed DALI output 1 of fourth DALI network (fourth CAN Control initialised)

Byte 66 -> DALI ID (0-63) of Dimmed DALI output 2 of fourth DALI network (fourth CAN Control initialised)

Byte 67 -> DALI ID (0-63) of Dimmed DALI output 3 of fourth DALI network (fourth CAN Control initialised)

...

Byte 126 -> DALI ID (0-63) of Dimmed DALI output 62 of fourth DALI network (fourth CAN Control initialised)

Byte 127 -> DALI ID (0-63) of Dimmed DALI output 63 of fourth DALI network (fourth CAN Control initialised)

Byte 128: Contains Dali ID x of Lunatone first input (when x<64) or with Dali ID x-64 of Helvar input (when x>63 and x<128)

Byte 129: Contains Dali ID x of Lunatone second input (when x<64) or with Dali ID x-64 of Helvar input (when x>63 and x<128)

…

Byte 143: Contains Dali ID x of Lunatone last input (when x<64) or with Dali ID x-64 of Helvar input (when x>63 and x<128)

Note: Please program your DALI ID’s starting at Byte 0 (for output modules) and Byte 64 (for Dim Control modules) and leave no places open between 2 DALI ID’s in other words, if you’ve for example 5 output ID’s, program them in Byte 0 to 4. Also note that, if using multiple DALI networks and thus multiple CAN controls, the same DALI ID’s can be used in the different DALI networks.

Light Group pages (Page 104-111)

Outputs Dimmed and non-dimmed (including Dali devices) can be programmed to take part of a light group. Instructions like Basic Action 73 and 74 can be used to switch ON and OFF entire groups of lights/outputs including DALI devices (over different CAN controls).

32 (0-31) Light groups can be programmed, each light group has a maximum of 64 outputs.

For more information, see Light Groups

Note: Since DALI devices are programmed using the Lunatone Cockpit software, the gateway doesn't know which DALI output corresponds to which DALI group. The eeprom pages below are used to program the corresponding outputs (not DALI ID's) of each DALI group.

Byte 0 -> Output Nr of Light Group 0

Byte 1 -> Output Nr of Light Group 0

Byte 2 -> Output Nr of Light Group 0

Byte 3 -> Output Nr of Light Group 0

...

Byte 62 -> Output Nr of Light Group 0

Byte 63 -> Output Nr of Light Group 0

Byte 64 -> Output Nr of Light Group 1

Byte 65 -> Output Nr of Light Group 1

Byte 66 -> Output Nr of Light Group 1

Byte 67 -> Output Nr of Light Group 1

...

Byte 126 -> Output Nr of Light Group 1

Byte 127 -> Output Nr of Light Group 1

Byte 128 -> Output Nr of Light Group 2

Byte 129 -> Output Nr of Light Group 2

Byte 130 -> Output Nr of Light Group 2

Byte 131 -> Output Nr of Light Group 2

...

Byte 190 -> Output Nr of Light Group 2

Byte 191 -> Output Nr of Light Group 2

Byte 192 -> Output Nr of Light Group 3

Byte 193 -> Output Nr of Light Group 3

Byte 194 -> Output Nr of Light Group 3

Byte 195 -> Output Nr of Light Group 3

...

Byte 254 -> Output Nr of Light Group 3

Byte 255 -> Output Nr of Light Group 3

Byte 0 -> Output Nr of Light Group 4

Byte 1 -> Output Nr of Light Group 4

Byte 2 -> Output Nr of Light Group 4

Byte 3 -> Output Nr of Light Group 4

...

Byte 62 -> Output Nr of Light Group 4

Byte 63 -> Output Nr of Light Group 4

...

Byte 192 -> Output Nr of Light Group 31

Byte 193 -> Output Nr of Light Group 31

Byte 194 -> Output Nr of Light Group 31

Byte 195 -> Output Nr of Light Group 31

...

Byte 254 -> Output Nr of Light Group 31

Byte 255 -> Output Nr of Light Group 31

Notes:

• The output NR (0-239) is different than the DALI ID (0-63). To program the groups in the above pages for DALI Outputs, the Output Nr (and not the DALI ID) is used so you have to keep track of the link between the DALI ID and the Output Nr.

• When using different DALI networks (and thus different CAN Controls), the same groups (0-15) can be programmed in the different DALI Networks. When for example you switch ON group 5 (Basic Action 73 5), it will activate group 5 on all DALI networks connected.

• When the Output Nr's are programmed for a certain group, start at the first place (for group 1 for example at byte 64) and program the rest at the following eeprom places, do not leave places open and then program an output Nr. When the system checks the eeprom, it will stop checking when an empty place (with value >239) is found.

• The DALI group can be used for DALI and non-DALI outputs. When, together with the DALI outputs, other outputs must be switched as well, you just add the Outputs Nr to the eeprom places of the corresponding group.

• Basic action 73 and 74 can be used to switch ON and OFF the DALI groups

Light/DALI group follow Output (Page 112)

A Virtual Output can execute a Light Group. For example, you have 4 individual dimmed outputs that should be switched ON/OFF and be dimmed in group. It should be however also possible to individually switch and dim them. This can be easily done by creating a Light Groups, link the Light Group to the Virtual Output. This page will create the link between the Virtual Output and the Light Group. For more information, see Light Groups.

Byte 0 -> Output Group Nr x linked to Output 0

Byte 1 -> Output Group Nr x linked to Output 1

Byte 2 -> Output Group Nr x linked to Output 2

Byte 3 -> Output Group Nr x linked to Output 3

...

Byte 238 -> Output Group Nr x linked to Output 238

Byte 239 -> Output Group Nr x linked to Output 239

Dimmer Value Page (Page 232)

This page contains the last dimmer value of each dimmer output.

Byte 0 -> Dimmer value Output 0

Byte 1 -> Dimmer value Output 1

Byte 2 -> Dimmer value Output 2

Byte 3 -> Dimmer value Output 3

...

Byte 238 -> Dimmer value Output 238

Byte 239 -> Dimmer value Output 239

Roller/Shutter Direction Page (Page 233)

This page contains the last direction of each individual Roller/Shutter.

Byte 0 -> Direction (0=DOWN,1=UP) of Roller/Shutter 0

Byte 1 -> Direction (0=DOWN,1=UP) of Roller/Shutter 1

Byte 2 -> Direction (0=DOWN,1=UP) of Roller/Shutter 2

...

Byte 119 -> Direction (0=DOWN,1=UP) of Roller/Shutter 119

Roller/Shutter Group Direction Page (Page 234)

This page contains the last direction of each Roller/Shutter Group.

Byte 0 -> Direction (0=DOWN,1=UP) of Roller/Shutter Group 0

Byte 1 -> Direction (0=DOWN,1=UP) of Roller/Shutter Group 1

Byte 2 -> Direction (0=DOWN,1=UP) of Roller/Shutter Group 2

...

Byte 29 -> Direction (0=DOWN,1=UP) of Roller/Shutter Group 29

Group Action pages

Group data (Page 67-86)

Page 67 – 86: Contains of the Group Actions (160 group actions)

The Group Actions are defined on 20 pages of the eeprom. Every Group Action consists of 16x2 bytes. Each Group Action can contain 16 Basic Actions. Each Basic Action is defined in 2 bytes. In total 160 (0-159) Group Actions can be defined with each 16 Basic Actions. The group action number (0-159) will be used to call the Group Action.

Definition of the 2 bytes used (for each group action, max 16x2 bytes are possible):

1. Byte 0,2,4,6,8,10,12,14 … 30: Action Type byte of the Basic Action

2. Byte 1,3,5,7,9,11,13,15 … 31: Action number byte of the Basic Action

Page 67/Byte 0 – 31 -> group action 0

Page 67/Byte 32 – 63 -> group action 1

...

Page 67/Byte 224 – 255 -> group action 7

Group action 8 – 15

Group action 16 – 23

Group action 24 – 31

Group action 32 – 39

Group action 40 – 47

...

Group action 152 – 159

ascii names Group (Page 158-167)

Page 158 – 167: accii names of Group Actions

The Master can store a 16 bytes ascii name for every group action. Those names are stored in the built-in eeprom of the Master controller.

Byte 0 – 15 -> ascii name of group action 0

Byte 16 - 31 -> ascii name of group action 1

Byte 32 - 47 -> ascii name of group action 2

...

Byte 240 - 255 -> ascii name of group action 15

Byte 0 - 15: ascii name of group action 16

...

Block Output Function (Page 231)

Page 231 -> Indicates if an output needs to check a validation bit before switching ON.

In certain circumstances, an output needs to be blocked. For example, during the day, it shouldn't be possible to switch ON the outside lights.

Each byte is linked to an output in other words, byte0 is linked to output 0, byte1 is linked to output 1 etc. The content of each byte represents the validation bit the system needs to check before switching ON an output. When the linked validation bit=1, the output is blocked, when the linked validation bit=0 then the Output can be switched ON.

Also known as output lock

remarks:

• The block function will only block the output for switching ON. An output can always be switched OFF even when a validation bit is programmed and is set at 1.

• When the programmed eeprom value is equal to 255, no block function is active

Indicates the validation bit nr for output 0. When this byte=255, no block function is active.

Indicates the validation bit nr for output 1. When this byte=255, no block function is active.

…

Indicates the validation bit nr for output 239. When this byte=255, no block function is active.

Simple Decision pages

Simple decision data (Page 87-92)

Page 87 – 92: Contains data of the Simple Decisions (192 simple decisions)

All Simple Decisions are spread over 6 pages (87-92). Each Simple Decision contains 8 bytes and each page has 32 Simple Decisions.

Simple Decision 0 – 31

Simple Decision 32 – 63

Simple Decision 64 – 95

Simple Decision 96 – 127

Simple Decision 128 – 159

Simple Decision 160 – 191

ascii names Simple decision (Page 168-179)

Page 168 – 179: ascii names of Simple Decisions

The Master can store a 16 bytes ascii name for every simple decision. Those names are stored in the built-in eeprom of the Master.

Byte 0 – 15 -> ascii name of simple decision 0

Byte 16 - 31 -> ascii name of simple decision 1

Byte 32 - 47 -> ascii name of simple decision 2

...

Byte 240 - 255 -> ascii name of simple decision 15

Byte 0 - 15 -> ascii name of simple decision 16

...

Simple Action Pages

Simple action data (Page 93-96)

Page 93 – 96: Contains data of the Simple Actions (204 simple actions)

Please note that Simple Action are quite complicated and rarely used. Other and simpler alternatives exist to accomplish the same so first check the available Basic Actions before using the Simple Actions.

The simple actions are defined on 4 pages (204 actions (0-203)). Every action consists of 5 bytes (see Simple Action)

Page 93 Byte 0 - 254: Simple Action 0 – 50

Page 94 Byte 0 - 254: Simple Action 51 – 101

Page 95 Byte 0 - 254: Simple Action 102 – 152

Page 96 Byte 0 - 254: Simple Action 153-203

ascii names Simple Actions (Page 145-257)

Page 145 – 157: ascii names of Simple Actions

The Master can store a 16 bytes ascii name for every simple action. Those names are stored in the built-in eeprom of the Master controller.

Byte 0 – 15 -> ascii name of simple action 0

Byte 16 - 31 -> ascii name of simple action 1

Byte 32 - 47 -> ascii name of simple action 2

...

Byte 240 - 255 -> ascii name of simple action 15

Byte 0 - 15 -> ascii name of simple action 16

...

Scheduled Action pages

Schedules action data (Page 113-114)

Page 113 - 114: Contains data of the Scheduled Actions

The Master controller has a built-in functionality that performs intelligent actions at a given time. For example: Let all the stores go up during the week at 8am, during the weekend at 9am. Let them go down at 8pm in the evening every day. A maximum of 102 (0-101) scheduled actions can be defined.

A scheduled action is defined in 5 bytes (see Scheduled Action page)

Scheduled Action 0

Scheduled Action 1

...

Scheduled action 0 – 50

Scheduled action 51 – 101

ascii names Scheduled action (Page 180-186)

Page 180 – 186: ascii names of Scheduled Actions

The Master can store a 16 bytes ascii name for every scheduled action. Those names are stored in the built-in eeprom of the Master controller.

Byte 0 – 15 -> ascii name of scheduled action 0

Byte 16 - 31 -> ascii name of scheduled action 1

Byte 32 - 47 -> ascii name of scheduled action 2

...

Byte 240 - 255 -> ascii name of scheduled action 15

Byte 0 - 15 -> ascii name of scheduled action 16

...

Thermostat pages

General Thermostat Configuration & Multi tenancy (Page 199)

For more information about the Thermostat principles, see the Thermostat page.

For more information about the Multi tenant possibilities, see the Thermostat Multi Tenant page.

For more information about the PID principles, see the PID page.

For more information how Cooling and Heating works, see Heating/Cooling

Note: In the pages below, you'll see some eeprom values with indication of C and H. When for example page H141/C200 is used which means that both pages have the same structure but page 141 has all the Heating parameters (when the system is in Heating mode) and page 200 has all the Cooling parameters (when the system is in Cooling mode)

When Cooling or Heating are enabled, outputs can be programmed to put your heat pump for example in cooling mode. Every mode (Heating as well as Cooling) has 4 outputs that can be set:

This part sets the 4 defined outputs when the heating is ON.

Byte0 -> Output number of the first output to be set

Byte1 -> Output value (dimmer value 0-63) of the first output to be set

Byte2 -> Output number of the second output to be set

Byte3 -> Output value (dimmer value 0-63) of the second output to be set

Byte4 -> Output number of the third output to be set

Byte5 -> Output value (dimmer value 0-63) of the third output to be set

Byte6 -> Output number of the fourth output to be set

Byte7 -> Output value (dimmer value 0-63) of the fourth output to be set

Note1: Outputs can be switched on or off. When the output value is 0, the output is switched off.

Note2: When a normal output module with relays is used and the output value>0, the relay will be switched on.

This part sets the 4 defined outputs when the cooling is enabled.

Byte8 -> Output number of the first output to be set

Byte9 -> Output value (dimmer value 0-63) of the first output to be set

Byte10 -> Output number of the second output to be set

Byte11 -> Output value (dimmer value 0-63) of the second output to be set

Byte12 -> Output number of the third output to be set

Byte13 -> Output value (dimmer value 0-63) of the third output to be set

Byte14 -> Output number of the fourth output to be set

Byte15 -> Output value (dimmer value 0-63) of the fourth output to be set

Note1: Outputs can be switched on or off. When the output value is 0, the output is switched off.

Note2: When a normal output module with relays is used and the output value>0, the relay will be switched on.

This range of bytes sets the thermostat configuration when the thermostat system is set in multi-tenancy mode (see Thermostat Multi Tenant pages).

Byte32 -> Multi-tenant configuration byte for Thermostat 0

Byte33 -> Multi-tenant configuration byte for Thermostat 1

Byte34 -> Multi-tenant configuration byte for Thermostat 2

Byte35 -> Multi-tenant configuration byte for Thermostat 3

Byte36 -> Multi-tenant configuration byte for Thermostat 4

...

Byte63 -> Multi-tenant configuration byte for Thermostat 31

The Multi-Tenant configuration byte is being set up as follows:

• BIT3

** =1: Individual thermostat is in automatic mode

** =0: Individual thermostat is in manual mode -> scheduled thermostat actions will be ignored, thermostat is or in Party, Away or Vacation mode

• BIT2,1,0

** =0,1,1 -> Individual thermostat is in Away mode

** =1,0,0 -> Individual thermostat is in Vacation mode

** =1,0,1 -> Individual thermostat is in Party mode

• All the other BITS are ignored and not in use

Multi-tenancy can be enabled by setting BIT6 of the Thermostat Mode byte.

The current setpoint of each thermostat will be programmed in the below eeprom locations. The value is programmed in system value.

Byte64 -> Current setpoint for Thermostat 0

Byte65 -> Current setpoint for Thermostat 1

Byte66 -> Current setpoint for Thermostat 2

Byte67 -> Current setpoint for Thermostat 3

Byte68 -> Current setpoint for Thermostat 4

...

Byte91 -> Current setpoint for Thermostat 31

Heating/Cooling Pages (Page H141-144, C200-203)

Page H141 - H144, C200 – C203: Thermostat pages

The Master controller can be programmed with 24 (0-23) thermostats. These thermostats will control preprogrammed outputs (0-10V heating/cooling valves or 230V valves for example). Each of those thermostats has their own PID algorithm to effectively control every individual room. The system can use 1 of the possible 32 sensors to measure the temperature. Any dimmer output or relay output can be used as the thermostat output. Each thermostat will be linked to an output (1 or 2) and a temperature sensor. A thermostat is only active when an output and a temperature sensor is linked to the thermostat.

Each Thermostat will get a temperature setpoint. This setpoint is the temperature that the room must achieve (heating as well cooling). Each thermostat can has 6 preprogrammed setpoints (0-5).

In the firmware, the number of thermostats has been set to 24 (0-23), however, it is possible to increase this to 32. For this reason, eeprom memory allocation is already been set for 32 thermostats (0-31).

Byte0 -> Gain P (of PID controllers) of thermostat 0

Byte1 -> Gain I (of PID controllers) of thermostat 0

Byte2 -> Gain D (of PID controllers) of thermostat 0

Byte3 -> Integral threshold of thermostat 0

Byte4 -> Gain P (of PID controllers) of thermostat 1

Byte5 -> Gain I (of PID controllers) of thermostat 1

Byte6 -> Gain D (of PID controllers) of thermostat 1

Byte7 -> Integral threshold of thermostat 1

...

Byte124 -> Gain P (of PID controllers) of thermostat 31

Byte125 -> Gain I (of PID controllers) of thermostat 31

Byte126 -> Gain D (of PID controllers) of thermostat 31

Byte127 -> Integral threshold of thermostat 31

Byte0: First Output Nr for Thermostat0

Byte1: First Output Nr for Thermostat1

...

Byte31: First Output Nr for Thermostat31

Byte32 -> Temperature Setpoint0 for thermostat0

Byte33 -> Temperature Setpoint0 for thermostat1

...

Byte63 -> Temperature Setpoint0 for thermostat31

Byte64 -> Temperature Setpoint1 for thermostat0

Byte65 -> Temperature Setpoint1 for thermostat1

...

Byte95 -> Temperature Setpoint1 for thermostat31

Byte96 -> Temperature Setpoint2 for thermostat0

Byte97 -> Temperature Setpoint2 for thermostat1

...

Byte127 -> Temperature Setpoint2 for thermostat31

Byte128 -> Temperature Setpoint3 for thermostat0

Byte129 -> Temperature Setpoint3 for thermostat1

...

Byte159 -> Temperature Setpoint3 for thermostat31

Byte160 -> Temperature Setpoint4 for thermostat0

Byte161 -> Temperature Setpoint4 for thermostat1

...

Byte191 -> Temperature Setpoint4 for thermostat31

Byte192 -> Temperature Setpoint5 for thermostat0

Byte193 -> Temperature Setpoint5 for thermostat1

...

Byte223 -> Temperature Setpoint5 for thermostat31

Every thermostat can be programmed with a second output that will be switched on when the first output doesn’t perform enough. Example: Floor heating is used, when the floor heating is not able to heat up the room enough (or fast enough), heating of a conventional convector can be added until the room reaches his setpoint.

Byte224 -> Second Output Nr for Thermostat0

Byte225 -> Second Output Nr for Thermostat1

...

Byte255 -> Second Output Nr for Thermostat31

The system has the possibility to define 8 (0-7) pump groups. Each pump group has a list of outputs. These outputs can for example be the list of heating valves of the first floor of a house. On each pump group is an output linked called “pump output”. When at least 1 output of the pump group is activated, the pump output will be on. When all outputs of a group are off, the pump output will also be off. Each pump group can have maximum 32 (0-31) outputs. Maximum of 8 (0-7) groups can be defined.

Byte0 -> output line 0 for pump group 0

Byte1 -> output line 1 for pump group 0

...

Byte 31 -> output line 31 for pump group 0

Byte32 -> output line 0 for pump group 1

Byte33 -> output line 1 for pump group 1

...

Byte 63 -> output line 31 for pump group 1

...

Byte224 -> output line 0 for pump group 7

Byte225 -> output line 1 for pump group 7

...

Byte 255 -> output line 31 for pump group 7

Byte 0 -> pump output for group 0

Byte 1 -> pump output for group 1

...

Byte 7 -> pump output for group 7

Byte 8 -> Temperature Sensor number for Thermostat 0

Byte 9 -> Temperature Sensor number for Thermostat 1

...

Byte 39 -> Temperature Sensor number for Thermostat 31

ascii names thermostats (Page H187-188, C204-205)

Page H187 – H188/C204 – C205: ascii names of thermostat

The Master can store a 16 bytes ascii name for every thermostat. Those names are stored in the built-in eeprom of the Master.

Byte 0 – 15 -> ascii name of thermostat 0

Byte 16 - 31 -> ascii name of thermostat 1

Byte 32 - 47 -> ascii name of thermostat 2

...

Byte 240 - 255 -> ascii name of thermostat 15

Byte 0 - 15 -> ascii name of thermostat 16

...

programmed timings thermostats (Page H189-192, C206-209)

Page H189 – H192/C206 – C209: scheduled thermostat actions

The Master controller has the possibility to program 2 timings a day for which each individual thermostat of every room needs to switch on and off (Between day and night temperature). For example: the living thermostat needs to switch on at 7am in the morning on a Monday, go back to night regime at 8h30, switch on again at 18h and go back to night regime at 22h30.

Additionally, Time based switching (TBS) can be done. This is a feature that uses the below timings to switch on/off an output but without taking into account the temperature sensor input. A typical example is the boiler of a house: The boiler must be activated during the day and switched off during the night. The TBS functionality will be activated by putting 240 in the Sensor Nr field. From that moment, the below timing of this thermostat will be used to perform TBS on the first output. The second output is not used in the case of TBS.

Note: When TBS functions are programmed in the thermostat for Heating and the system is switched over to Cooling, the TBS must be created in cooling or order to continue to work. Example: TBS is used for ventilation or hot water, these TBS thermostats must be created in Heating thermostats as well as in cooling thermostats.

The time in eeprom is being written in a special format which fit in 1 byte: Time -> Special time format that fits in 1 byte

• 00h00 -> 0

• 00h10 -> 1

• 00h20 -> 2

...

• 01h00 -> 6

...

• 12h00 -> 72

...

• 23h50 -> 143

• 23h50 -> 144

Special time format >144 will be ignored.

4 pages in eeprom are used: H189 – H192/C206 – C209. Each page is split in 2: the lower (0-127) and the higher section (128-255). 1 section is used for every day.

Byte0 -> Start time 0 for thermostat 0 for day1 (Monday)

Byte1 -> Stop time 0 for thermostat 0 for day1

Byte2 -> Start time 1 for thermostat 0 for day1

Byte3 -> Stop time 1 for thermostat 0 for day1

Byte4 -> Start time 0 for thermostat 1 for day1

Byte5 -> Stop time 0 for thermostat 1 for day1

Byte6 -> Start time 1 for thermostat 1 for day1

Byte7 -> Stop time 1 for thermostat 1 for day1

...

Byte128 -> Start time 0 for thermostat 0 for day2

Byte129 -> Stop time 0 for thermostat 0 for day2

Byte130 -> Start time 1 for thermostat 0 for day2

Byte131 -> Stop time 1 for thermostat 0 for day2

Byte132 -> Start time 0 for thermostat 1 for day2

Byte133 -> Stop time 0 for thermostat 1 for day2

Byte134 -> Start time 1 for thermostat 1 for day2

Byte135 -> Stop time 1 for thermostat 1 for day2

...

Byte0 -> Start time 0 for thermostat 0 for day7

Byte1 -> Stop time 0 for thermostat 0 for day7

Byte2 -> Start time 1 for thermostat 0 for day7

Byte3 -> Stop time 1 for thermostat 0 for day7

Byte4 -> Start time 0 for thermostat 1 for day7

Byte5 -> Stop time 0 for thermostat 1 for day7

Byte6 -> Start time 1 for thermostat 1 for day7

Byte7 -> Stop time 1 for thermostat 1 for day7

ascii names Sensors (Page 193-194)

Page 193 – 194: ascii names of sensors

The Master can store a 16 bytes ascii name for every sensor. Those names are stored in the built-in eeprom of the Master.

Byte 0 – 15 -> ascii name of sensor 0

Byte 16 - 31 -> ascii name of sensor 1

Byte 32 - 47 -> ascii name of sensor 2

...

Byte 240 - 255 -> ascii name of sensor 15

Byte 0 - 15 -> ascii name of sensor 16

...

Virtual Sensors & Thermostats (Page 195)

Page 195: Virtual Sensors

As of Firmware Version F3.142.1 and higher, the master allows virtual sensors. A good example is the NEST thermostat which measures temperature and humidity as well. If you want to use the NEST temperature and/or Humidity in Renson Smart Living, a virtual senor must be configured. For more information regarding Virtual sensors, see Virtual Sensors. When a virtual sensor is enabled on one of the sensor ports, the master will only update the sensor data through the virtual sensor API even when a Renson Smart Living sensor is connected on that port.

Byte 0 -> Virtual sensor 0 enabled/disabled (255-> Virtual sensor disabled, <255-> Virtual sensor enabled)

Byte 1 -> Virtual sensor 1 enabled/disabled (255-> Virtual sensor disabled, <255-> Virtual sensor enabled)

...

Byte 31 -> Virtual sensor 31 enabled/disabled (255-> Virtual sensor disabled, <255-> Virtual sensor enabled)

As of Firmware Version F3.142.2 and higher, the master also supports thermostats like Nest and other smart thermostats. It is however important that the scheduled timings and setpoints programmed in Renson Smart Living doesn't conflict the timings/setpoints written in for example the Nest thermostat (it's important to choose who's the master). To allow this, you can configure your Renson Smart Living thermostat to be in permanent manual mode all the time and never change the setpoint by a programmed setpoint in other words, the programmed setpoints in Auto, Away, Vacation and party mode will be ignored when a thermostat is in permanent manual mode. The Nest plugin for example will sync the setpoint with the Renson Smart Living cloud and the setpoint (including the current temperature) can be read and set in the Renson Smart Living portal as well as in the Nest app, the programmed NEST settings/intelligence will be leading.

Byte 32 -> Thermostat 0 in permanent manual mode (Heating mode) when <255, in normal mode when =255

Byte 33 -> Thermostat 1 in permanent manual mode (Heating mode) when <255, in normal mode when =255

...

Byte 63 -> Thermostat 31 in permanent manual mode (Heating mode) when <255, in normal mode when =255

Byte 64 -> Thermostat 0 in permanent manual mode (Cooling mode) when <255, in normal mode when =255

Byte 64 -> Thermostat 1 in permanent manual mode (Cooling mode) when <255, in normal mode when =255

...

Byte 95 -> Thermostat 31 in permanent manual mode (Cooling mode) when <255, in normal mode when =255

Note: The change in Permanent Manual mode is done by using Basic Action 82 (set) and 83 (Clear). When BA 82 or 83 is performed, the API instruction "pL" is automatically sent. The "pL" will always sent the list of it's currently active mode (cooling or heating) in other words, when your system for example is in Heating mode and you make a change of a Cooling thermostat, the "pL" instruction will contain the Heating parameters.

Thermostat programmed setpoints (Page H196-198, C210-212)

Page H196 – H198/C210 – C212: Thermostat setpoints

Each Thermostat will get a temperature setpoint. This setpoint is the temperature that the room must achieve. Each thermostat can have 3 preprogrammed setpoints (day1, day2 and night) per day. The below programmed temperatures will only be used when the Individual Temp Byte (Page0/Byte21) =255.

Day1

Byte0 -> Temperature Setpoint Day 1 Monday for thermostat0

Byte1 -> Temperature Setpoint Day 1 Monday for thermostat1

...

Byte31 -> Temperature Setpoint Day 1 Monday for thermostat31

Byte32 -> Temperature Setpoint Day 1 Tuesday for thermostat0

...

Byte63 -> Temperature Setpoint Day 1 Tuesday for thermostat31

Byte64 -> Temperature Setpoint Day 1 Wednesday for thermostat0

...

Byte95 -> Temperature Setpoint Day 1 Wednesday for thermostat31

Byte96 -> Temperature Setpoint Day 1 Thursday for thermostat0

...

Byte127 -> Temperature Setpoint Day 1 Thursday for thermostat31

Byte128 -> Temperature Setpoint Day 1 Friday for thermostat0

...

Byte159 -> Temperature Setpoint Day 1 Friday for thermostat31

Byte160 -> Temperature Setpoint Day 1 Saturday for thermostat0

...

Byte191 -> Temperature Setpoint Day 1 Saturday for thermostat31

Byte192 -> Temperature Setpoint Day 1 Sunday for thermostat0

...

Byte223 -> Temperature Setpoint Day 1 Sunday for thermostat31

Day2

Byte0 -> Temperature Setpoint Day 2 Monday for thermostat0

Byte1 -> Temperature Setpoint Day 2 Monday for thermostat1

...

Byte31 -> Temperature Setpoint Day 2 Monday for thermostat31

Byte32 -> Temperature Setpoint Day 2 Tuesday for thermostat0

...

Byte63 -> Temperature Setpoint Day 2 Tuesday for thermostat31

Byte64 -> Temperature Setpoint Day 2 Wednesday for thermostat0

...

Byte95 -> Temperature Setpoint Day 2 Wednesday for thermostat31

Byte96 -> Temperature Setpoint Day 2 Thursday for thermostat0

...

Byte127 -> Temperature Setpoint Day 2 Thursday for thermostat31

Byte128 -> Temperature Setpoint Day 2 Friday for thermostat0

...

Byte159 -> Temperature Setpoint Day 2 Friday for thermostat31

Byte160 -> Temperature Setpoint Day 2 Saturday for thermostat0

...

Byte191 -> Temperature Setpoint Day 2 Saturday for thermostat31

Byte192 -> Temperature Setpoint Day 2 Sunday for thermostat0

...

Byte223 -> Temperature Setpoint Day 2 Sunday for thermostat31

Night

Byte0 -> Temperature Setpoint Night Monday for thermostat0

Byte1 -> Temperature Setpoint Night Monday for thermostat1

...

Byte31 -> Temperature Setpoint Night Monday for thermostat31

Byte32 -> Temperature Setpoint Night Tuesday for thermostat0

...