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