Product Description

The Remoticom CloudGate Zhaga 150  series are the most advanced products in our Zhaga Smart Controller family. The controller comes standard with an NB-IoT cellular modem with GPS, a LUX sensor, a tilt sensor and uses the Dali 2.0 specification to communicate with the luminaire driver. The CloudGate Zhaga 150 is equipped with a nano SIM card holder, or optionally with an eSIM, offering the customer the flexibility to select their preferred NB-IoT network provider.

Note! it's important to share the NB-IoT network operator details with us in advance as the network connection credentials need to be embedded in the CloudGate Zhaga 150
firmware! Please share this information with your Remoticom point of contact.

The CloudGate Zhaga 150 can be controlled using an API that connects to the devices over MQTT protocol. The same API can be used to monitor the current status in real time and to schedule a daily/weekly calendar and/or dimming profile.

The CloudGate Zhaga 150 is equipped with several sensors, after an error detection, a notification will be sent automatically. The CloudGate Zhaga 150 is controlled by user-selectable portal/data management system via API. The API connection can also be used for data exchange with other existing data or management systems. Because the device firmware includes a holiday and exception calendar, different dimming profiles and working times can be set compared to the usual daily and weekly regimes.

An emergency function can also be set, whereby the dim level is immediately set to 100%. 

The built-in tilt detection can be used to monitor the angle of the column. In case of a tilt of more than 5 degrees, an error message will be given. The CloudGate Zhaga 150 creates its own tilt zero point after 48 hours of operation.

CloudGate Zhaga 150 Solution Architecture

In the drawing above you can find a reference solution architecture with ZSC150 devices in the field. The solution consists out of multiple parts.

• Each CloudGate Zhaga 150 communicates over a APN/VPN "End-to-End" secured NB-IoT network via MQTT. This way the highest security is offered by segregating the data from/to the devices from the public network. Please reach out to your Remoticom point-of-contact in case you need assistance in setting up the APN/VPN connection with your Mobile Network Operator of preference.
• The MQTT Broker is used to orchestrate all the communication from/to the devices and the application server.
• An optional TFTP server can be installed to provide firmware-Over-The-air-upgrades to the devices.
• The application server is used to configure, control and monitor the devices, using the CloudGate Zhaga 150 API.

Device Modes

The CloudGate Zhaga 150 can operate in 5 different modes, fully configurable via API.

• In mains mode the device will follow the dim planning when powered on.
• In static mode the device will operate with a fixed dim level when powered on.
• In astro mode it is considered day or night depending on the GPS location and the local time. This method is also known as astro sunrise.
• In lux mode it is considered night when the lux sensor measures a value lower than 18 for 5 minutes or longer. If the sensor measures a value greater than 36 for 5 minutes or longer it is considered day. (In astro and lux mode the device will follow the dim planning when it is considered night. Otherwise the device will turn the light off.)
• In emergency mode the LED will be turned on (100%) for a variable amount of time (emergency duration). After the emergency mode times out, it will go back to its previous mode. The device remains in emergency mode until the mode times out.

LED Description

The Green LED indicates the heartbeat of the device. During device boot, the LED is on permanently. During normal operation the LED will blink every 1 second.

The Blue LED indicates the connection to the NB-IoT network. On means connected, off means there is no connection.

The Red LED indicates if there is an error. the Red LED will blink for 10 seconds before the device reboots.

Installation QuickStart Guide

The installation guide (English) can be found at the bottom of this page.

CloudGate Zhaga 150 API documentation

In the world of Internet of Things, it is important to be able to send messages in a suitable manner, with maximum usage of limited bandwidth. Therefore, there are a few points to consider.

• Number of messages to be sent and the size of each message.
• Flexibility.
• Data Overhead.
• Easiness of use / understanding.
• Compatibility.

Based on the above points Remoticom developed the OAB protocol, which is based on the IPSO1, Internet Protocol Smart Objects, standard. As the name suggests, IPSO uses smart objects to manage the device’s data. These smart objects represent sensor data or device states, for example. They are flexible, stackable and have only a small overhead. 

In combination with the CloudGate Zhaga 150 API document, you can find the detailed description of the OAB protocol here below as well. 

Please note both documents are essential information in order to be able to communicate with your ZSC150 devices!

CloudGate Zhaga 150 schedule example

Say we want to set the DIM-schedule for every day of the week to the following:
from 00:00 to 04:00 => dimming 50
from 04:00 to 06:30 => dimming 100
from 06:30 to 20:00 => dimming 0
from 20:00 to 21:00 => dimming 100
from 21:00 to 00:00 => dimming 70

The dim scheduling starts with a byte indicating the number of dim steps:

5 * 7 = 35 (5 steps per day, 7 days per week)

Then follow the steps with the Unix timestamp from January 5, 1970 00:00:00 which equals 345600 seconds.
Convert 345600 seconds into HEX and you will get the start date/time:

00 05 46 00

Add the OAB protocol information (see OAB-Protocol.pdf) and the other dim steps and you get the following:

Concatenate this HEX code above into one long string and you will get:

2B 00 00 00 00 00 00 00 00 00 00 00 11 00 00 32 0D 0F 00 68 26 00 2B 05 00 05 46 00 00 00 00 32 00 05 7E 40 00 00 00 64 00 05 A1 68 00 00 00 00 00 06 5F 40 00 00 00 64 00 06 6D 50 00 00 00 46 00 2D

A detailed explanation of each part in the string above can be found here below:

Convert this HEX string into Ascii85 and you will get the final message that you need to send to the MQTT Broker:

d/YLH00000000005Dz!^4g-CLcibL100L*(0000O00N*p0001f00P6f0000000V^}0001f00Wpp0000*04!

Product Pictures

Product Datasheet

English, French, German and Dutch versions of the datasheet/specsheet can be found here below.