Zennio ZCL-MCC User manual

MCC
Multiroom Climate Controller
ZCL-MCC
USER MANUAL
Application program version: [2.0]
User manual edition: [2.0]_a
www.zennio.com

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
2
CONTENTS
Contents........................................................................................................................................ 2
Document Updates ....................................................................................................................... 3
1 Introduction .......................................................................................................................... 4
1.1 MCC (Multiroom Climate Controller)............................................................................ 4
1.2 Installation..................................................................................................................... 5
2 Functionality.......................................................................................................................... 7
2.1 Configuration Check...................................................................................................... 7
2.2 Operation Roles............................................................................................................. 9
2.2.1 Master ............................................................................................................... 9
2.2.2 Slave ................................................................................................................ 11
2.3 Master/Slave Role Selection ....................................................................................... 14
2.4 LED Notifications......................................................................................................... 15
2.5 Initial States................................................................................................................. 16
3 Configuration....................................................................................................................... 18
3.1 General........................................................................................................................ 18
3.2 Hospitality Thermostat................................................................................................ 20
ANNEX I. Communication Objects............................................................................................... 21

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
3
DOCUMENT UPDATES
Version
Changes
Page(s)
[2.0]_a
Changes in the application program:
•Update of the Hospitality Thermostat function to
version 1.0.0 (corresponding user manual: 1.0_a).
•Number of thermostats available: 13.
-
[1.5]_a
Changes in the application program:
•Update of the Hospitality Thermostat function to
version 0.5.3 (corresponding user manual: 0.5_a).
-
[1.4]_a
Changes in the application program:
•Update of the Hospitality Thermostat function to
version 0.4.6 (corresponding user manual: 0.4_a).
-
[1.3]_a
Changes in the application program:
•Update of the Hospitality Thermostat function to
version 0.3.6 (corresponding user manual: 0.3_a).
-
[1.2]_b
Changes in the application program:
•Update of the Hospitality Thermostat function to
version 0.2.4 (corresponding user manual: 0.2_b).
-

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
4
1INTRODUCTION
1.1 MCC (MULTIROOM CLIMATE CONTROLLER)
MCC (Multiroom Climate Controller) from Zennio is an in-line controller aimed at
managing and controlling the climate of multiple hotel rooms (or any other type of guest
rooms, e.g., residential or hospital rooms). To that end, it is possible to enable up to
thirteen thermostats independently.
Given how critical it is that a single device controls the climate of several rooms, it is
possible to have two exactly alike MCCs (and with the same configuration) working in
the same system, one of them as a master and the other as a slave. Thus, the
master device will operate normally while the slave remains on standby to take control
if the master fails.
The most outstanding features of MCC are:
System configuration for operation with a single device or two devices with
Master-Slave roles.
Up to 13 independent Hospitality thermostats.
Communication objects and LEDs indicators of master/slave role, slave
error and configuration error.

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
5
1.2 INSTALLATION
MCC connects to the KNX bus through the on-board KNX connector. Once the device
is provided with power from the KNX bus, both the individual address and the
associated application program can be downloaded.
Figure 1. MCC - Element Diagram.
The main elements of the device are described next.
Test/Prog. Pushbutton (1): a short press on this button sets the device into
the programming mode, making the associated LED (2) light in red.
Note: if this button is held while plugging the device into the KNX bus, the
device will enter into safe mode. In such case, the LED will blink in red.
Master Status LED (3): LED indicator that lights up when the device is
running as a master.
Slave Status LED (4): LED indicator that lights up when the device is running
as a slave.
Missing Slave LED (5): LED indicator that lights up when no slave MCC is
found in the installation. Note that this does not prevent the master MCC from
running normally.
7
1
2
3
4
5
6
1. Prog./Test Button.
2. Prog./Test LED.
3. Slave Status LED.
4. Master Status LED.
5. Missing Slave LED.
6. Configuration Error LED.
7. KNX Connector.

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
6
Configuration Error LED (6): LED indicator that will blink in red if, although
one master MCC and one slave MCC have been found in the installation,
their configurations do not match.
To get detailed information about the technical features of the device, as well as on the
installation and security procedures, please refer to the corresponding Datasheet,
bundled with the original package of the device and also available at www.zennio.com

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
7
2FUNCTIONALITY
As indicated in the introduction, the aim of this device is performing an in-line climate
control of multiple hotel rooms (or any other guestrooms, such as residential rooms
or hospital rooms), where it is necessary to ensure that the system keeps running
despite of occasional device faults.
The following sections describe the different roles that the device can assume and all
the checks and notifications performed during the process.
2.1 CONFIGURATION CHECK
MCC is designed to operate in pairs: two MCCs with the same configuration are
recommended to simultaneously work together in the same installation. Device
redundancy is justified by how critical a fault in one of them would be, as the climate
system of several rooms depends on it. However, it is not mandatory to install two
MCCs to make the system work and it is possible to configure it to act as a single
device.
To have two devices working together properly it is necessary to configure them
identically: same parameters, group addresses and associations. It is recommended to
first configure a device and, after validating the configuration, making an exact copy
in the ETS project, keeping the group addresses.
The device will check that its configuration matches that of its analogue. Therefore,
after each reboot both will exchange a checksum value, which depends on:
Number and application program version.
Parameters.
Table of communication objects (flags and size of the communication
objects).
Group address table.
Associations table.

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
8
Every time the master and the slave send the bus a master / slave role confirmation
notification (see sections 2.2.1 and 2.2.2), they both will also re-send their checksum
values through a communication object with the writing and transmission flags
enabled, in order to transmit and receive information through it. If the received
checksum is different from the one sent (i.e., the one calculated internally):
Everything related to the thermostatic control will stop working: no more
sendings will take place, even if the device is working as a master (see
section 2.2.1).
The role notification sending will stop (master / slave).
The “Configuration error” communication object will be transmitted with
value ‘1’ every 30 seconds.
The checksum calculated internally will be transmitted with a one-second
delay, to make it possible to check at any time whether the two configurations
still do not match.
All LEDs will turn off except the configuration error LED, which will bink
every one second.
The device will remain in the above state until the expected checksum value is
received (i.e., a value that matches with the one internally calculated), after which the
device will reboot as if it had just been programmed.
Once the device reboots, it will operate as if it had never detected the wrong
configuration, thus, maintaining the same state it had before the configuration error
detection. Then, it will apply everything specified in section 2.5.
After a restart, the object “Configuration error” is always transmitted with value ‘0’.

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
9
2.2 OPERATION ROLES
MCC may be operating as a master, as a slave or under an “undefined” state:
The master aims at actually controlling the room climate.
The slave remains waiting for a failure in the master, to take over the climate
control.
A device is operating as “undefined” when it has not been determined yet
whether it must operate as a master or as a slave.
The device role will be notified via communication object (this process is detailed in
following sections) and by two LEDs specifically included for this purpose: the LED
corresponding to the current role lights up (master LED indicator or slave LED
indicator); if there is no role assigned yet (see section 2.3), both LEDs remain off.
The integrated thermostats do not start operating until the device has a role assigned.
When the device adopts a role, it will start performing the thermostat actions as if a
restart had just taken place. Moreover, on the first execution, the thermostat actions
that may apply after an ETS download will also take place.
The following sections describe the master and slave operating modes.
2.2.1 MASTER
The master handles the climate control by sending the control orders and states
(communication objects) when required.
While the device is operating as a master, the master LED indicator is on.
2.2.1.1 COMMUNICATION OBJECT NOTIFICATIONS
Periodically (time set by parameter), the master device sends a ‘1’ through the master
notification communication object, and afterwards its internal checksum value.
If a master device receives any value through the master notification object,
automatically switches to slave mode (and sends the corresponding slave notification).

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
10
Figure 2 Master notification.
In order to avoid message collision, if a master notification is received (from another
device) no later than 100 ms after sending a master notification, the device switches to
the “undefined” state and it will start the role selection process (see section 2.3).
2.2.1.2 SLAVE NOTIFICATION RECEPTION
The master expects to receive periodically (through the slave notification object) a
confirmation that the slave device is operating properly. If it doesn’t receive any value
through this object during two times and a half the slave notification time (set by
parameter), the ‘missing slave’LED indicator will turn on. And once any value is
received through the communication object, the LED will turn off.
Figure 3 No-slave detection by the master.
Master
Master Notif.
Checksum
Master Notif.
Checksum
Master Notif.
Checksum
Master Notif.
Slave Notif.
Checksum
t
t
master
Master
Slave Notif.
t
t
slave
Slave Notif.
Slave Notif.
2.5 x t
slave
LED on

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
11
Note: the time to wait before reporting the ‘missing slave’notification starts counting on
the last reception of a slave notification (the first time, the count begins once the device
adopts the master role).
2.2.2 SLAVE
When MCC operates as a slave, its internal thermostats listen to the communication
objects being written to the KNX bus, and update their states and communication
objects. The main difference is that a slave MCC doesn’t send any communication
objects (related to thermostats) to the bus. Thus, master thermostats and slave
thermostats will always have the same state (at least after a certain time, in case both
MCCs were not put in operation simultaneously).
While the device is operating as a slave, the slave LED indicator is on.
2.2.2.1 SENDING READ REQUESTS
After a reboot, as long as MCC is operating as a slave (i.e., when the device state is
not “master”nor “undefined”), the device may send requests to read certain objects
in order to update the statuses of its thermostats, provided that such requests have
been enabled by parameter. Specifically, the following communication objects are read:
Transition Time: comfort to default mode
Transition Time: standby to economy
Comfort Setpoint Reset Time
User Setpoint Control (Cooling and Heating)
Comfort Setpoint (Cooling)
Standby Setpoint (Cooling)
Economy Setpoint (Cooling)
Protection Setpoint (Cooling)
Comfort Setpoint (Heating)
Standby Setpoint (Heating)
Economy Setpoint (Heating)
Protection Setpoint (Heating)

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
12
Comfort Lower Limit
Comfort Upper Limit
Hidden Offset Value
Eco Mode: Lower Limit (Cooling)
Eco Mode: Upper Limit (Heating)
High Humidity Alarm Threshold
Dehumidification Control
Enable Apparent Temperature
These requests only apply to the enabled thermostats and to the linked objects.
Notes:
These read requests are sent gradually, to prevent the saturation of the KNX
bus.
To obtain the expected behaviour, the communication objects that are read-
requested must have the Writing, Transmission and Update flags
enabled.
If a role change occurs while performing the read requests, the remaining
responses will not be affected, as they will be sent as if the role change had
not taken place.
2.2.2.2 OBJECT COMMUNICATION NOTIFICATIONS
Periodically (time set by parameter), the slave device sends a ‘1’ through the slave
notification communication object.
The reception of any value through the slave notification object will be ignored.
2.2.2.3 MASTER FAILURE DETECTION
In the slave role, the device permanently listens for the master notifications. After two
and a half times the transmission time without receiving any master notification, the
slave device switches to the master role and notifies it by sending a “1” through

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
13
the master notification communication object (the role change notification object is
also sent, with value ‘1’).
Thereafter the device will send the master notification periodically according to the
configured cycle time.
Figure 4 Master error detection by the slave.
Slave
Master Notif.
t
t
master
Master Notif.
Master Notif.
2.5 x t
master
Master Notif.

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
14
2.3 MASTER/SLAVE ROLE SELECTION
The device role is automatically assigned. When a device is under the “undefined”
state, it starts the role selection algorithm:
1. A random wait time is calculated, greater enough than the master notification
sending time.
2. The device remains waiting during the above time.
a. If nothing is received, it adopts the master role and starts sending the
master notification object.
b. If before the end of the time count any value is received through the
master notification object, the device adopts the slave role and starts
sending the slave notification object.
Figure 5 Role selection.
Device 1
Device 2
t
t
Download
t
selection
t
selection
Download

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
15
2.4 LED NOTIFICATIONS
The following table sums up the different LED notifications, which have been explained
in the previous sections:
LED
Function
Description
Master
Notifying that the
device is operating as a
master.
It remains on since the device adopts the
master role, and off in any other
situation.
Slave
Notifying that the
device is operating as a
slave.
It remains on since the device adopts the
slave role, and off in any other situation.
Configuration
Error
Notifying that the pair
MCC has a different
configuration.
It starts blinking every one second if the
checksum value received from the bus
does not match the expected value.
Slave
Missing
Notifying the absence
of a slave MCC.
Will turn on after a certain time without
receiving slave notifications, to indicate
the absence of the slave MCC.
Table 1 LED notifications.

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
16
2.5 INITIAL STATES
When MCC has just been programmed, it always starts under the “undefined state”. At
that point, the selection algorithm (see section 2.3) begins, the result of which will
determine whether the device switches to master or to slave.
Note: as stated in section 2.3, MCC may return to the “undefined” if a master
notification is received from the bus immediately after having sent an analogous
notification. To prevent collisions between two MCCs opting to behave as masters, the
“undefined” state will be adopted and the role selection algorithm will start.
Should a bus power failure take place before the selection algorithm has concluded,
MCC will retry the role selection once it recovers from the power failure.
On the other hand, if a bus failure takes place once MCC had a role already assigned:
If it was working as a slave, it will reboot as such and operate normally.
If it was working as a master, it will reboot as such but will first ensure that no
other master notifications are received during 1.5 times the master notification
period.
The following table and graphs sum up all the above:
Initial Mode
Event
Next Mode
Actions to perform
Undefined
Download
Undefined
Beginning of the selection algorithm.
Reboot
Slave
Download
Reboot
Slave
Slave notification and normal operation.
Master
Download
Undefined
Beginning of the selection algorithm.
Reboot
Master
Wait for 1.5x the master notification time.
- Master notifications received switch to
slave (and notify it1).
- No master notification received remain
as master (and notify it).
Table 2 Initial states after ETS download or reboot (power failure).
1
READ requests will also be transmitted, if configured.

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
17
Figure 6 State after ETS download.
Figure 7 State after reboot (as slave).
Figure 8 State after reboot (as master).
Master
or
Slave
t
Download
Selection Algorithm
Slave
t
Reboot
Slave Notif.
Slave Notif.
Slave Notif.
Master
t
Reboot
Master Notif.
1.5 x t
master
Master Notif.
Master
t
Reboot
Master Notif.
Slave Notif.
Slave Notif.
1.5 x t
master

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
18
3CONFIGURATION
3.1 GENERAL
ETS PARAMETERISATION
After importing the corresponding database in ETS and adding the device into the
topology of the desired project, the configuration process begins by entering the
Parameters tab of the device.
The “General” parameter screen is the only shown by default.
Figure 9. General.
It contains the following parameters:

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
19
➢System Configuration [Master-Slave
2
/ Only one device]: sets whether
the system comprises two MCCs, one operating as a master and the other
as a slave or if it consists of just one device.
When selecting the “Master-Slave”configuration, the following parameters show up:
Master Notification Time [1...4…255]: sets the sending period of the master
notifications, through which MCC informs (when applicable) that it is working
in the master mode.
Slave Notification Time [1…10…255]: sets the sending period of the slave
notifications, through which MCC informs (when applicable) that it is working
in the slave mode.
Send read requests after a reboot (only for slave mode)
[enabled/disabled]: enables the sending of read requests of certain objects by
the slave after a reboot so it can update its state to match that of the master.
In this case, the default communication objects are:
“Master”: one-bit object which is sent periodically (according to parameter
“Master Notification Time”) to indicate the device is operating in master
mode.
“Slave”: one-bit object which is sent periodically (according to parameter
“Slave Notification Time”) to indicate the device is operating in slave mode.
“Role Switch”: one-bit object which is sent (with the value ‘1’) when a role
change occurs.
“Checksum”: two-byte object through which the internal checksum value is
sent. The analogous value from the additional MCC is also expected to be
received through this object (to ensure their configurations match).
“Configuration Error”: one-bit object which is sent (periodically) with the
value ‘1’when the master and the slave do not share the same configuration
(checksum mismatch). Once solved, it will be sent with the value ‘0’.
2
The default values of each parameter will be highlighted in blue in this document, as follows:
[default/rest of options].

MCC
http://www.zennio.com Technical Support: http://support.zennio.com
20
When selecting “Only one device” system configuration, the following parameters show
up (Figure 10):
Figure 10 General –System Configuration: Only one device.
Operating Notification Time [1...4…255]: sets the sending period of the
operating notifications, which indicate that the device is working.
In this case, the default communication objects are:
“Operating Notification”: one-bit object through which the above
notifications are periodically sent.
On the other hand, as shown in Figure 9, thirteen checkboxes (one per each
Hospitality thermostat) are provided to let the integrator select how many of the thirteen
thermostats are required. Additional entries to configure them will be included in the tab
menu on the left depending on the number of active thermostats.
3.2 HOSPITALITY THERMOSTAT
As described in previous sections, MCC includes thirteen instances of the
Hospitality Thermostat, which can be enabled and customised independently.
Please refer to the specific manual “Hospitality Thermostat in MCC” (available at the
Zennio homepage, www.zennio.com) for detailed information about the functionality
and the configuration of the involved parameters.