Zipato MQTTCloud
Zipato MQTTCloud
Table of contents
Table of contents
Box actions
Network topics
Device topics
Endpoint topics
ClusterEndpoint topics
Attribute topics
Attribute actions
Invoke interface
Available methods
Zipato Device Model introduction
Zipato device model is designed to be a generic abstraction layer that can be used to model
various communication protocols and devices.
The device model is a hierarchy of entities that represent various aspects of any given protocol
or device.
Zipato Device Model in general is comprised of several types of entities.
Each entity in the device model is uniquely identifiable with an UUID.
Here is a simple overview of the device model hierarchy:
● Network(s)
○ Device(s)
■ Endpoint(s)
● Cluster(s)
○ Attribute(s)
Network
Networks usually represent a particular protocol, like Z-Wave or Zigbee for example. Networks
can have one or more devices. Almost all networks have a few common actions, like adding a
device, removing a device or resetting a device. A network can also have network specific
actions.
Device
A device represents an actual physical device, a wall plug or a door sensor for example. A
device typically has one or more functions. Networks can have one or more devices.
Endpoint
Endpoints are used for “partitioning” various functions and features of a device according to its
features and limitations of the device model itself. There are no general rules on how endpoints
should be used or what should they represent. However, each device usually has at least one
endpoint, or several.
Cluster
A cluster represents a particular device function, like a reed sensor of a door sensor, or a relay
of a wall switch for example. An endpoint can contain one or more clusters that represent
functions of a particular device.
One important constraint of the device model is that an endpoint cannot contain more
than one cluster of a particular type.
For example, if a device has two relays, clusters representing these relays will of course be of
the same type. But they cannot be under the same endpoint, each has to be under its own
endpoint.
Attribute
Attributes represent one or several states or values of a particular device function.
For example, reed sensor state of a door sensor or relay state of a wall plug can be modelled
with a simple boolean value; Both can be either on or off.
That means that clusters that model these functions(simple binary sensor and simple binary
actuator in this example) will have a single attribute that holds the current state of these
functions.
Attributes can be readable, writable or both. For example an attribute of a cluster that models a
simple binary sensor will be readable, but not writable. It makes no sense to “write” the state of
a sensor device.
An attribute of a cluster that models simple binary actuators, like a relay of a wall plug, will be
both readable and writable; You can check its state and you can change state.
Attribute definitions
Attributes model, or “hold” so to speak, the current state or value of a particular function of a
device. Certain device functions have additional associated data.
For example, a wall plug might have a meter function, one that can measure current power
consumption and voltage.
Both of these functions have units that describe their values. An attribute definition is used to
hold additional data about a certain device function. Each attribute has an associated attribute
definition.
How to enable MQTT on Zipato controllers
MQTT Network can be enabled via online REST API.
Basepath: https://my.zipato.com/zipato-web/v2/networks
Parameter content type: application/json
Method: POST
Example payload:
{
"className": "com.zipato.network.mqtt.MqttNetwork",
"broker": "tcp://127.0.0.1",
"clientId": null,
"username": null,
"password": null,
"topicBase": null,
"topicPrefix"null
}
Payload property description:
● className - mandatory property, value MUST be
"com.zipato.network.mqtt.MqttNetwork"
● broker - broker address, with transport protocol
● clientId - if set to null, clientId will default to Zipato serial of the current box
● topicBase - if set to null, topicBase will default to “/”
● topicPrefix - if set to null topic Prefix will default to “clientId/”:
To change any of the above mentioned properties at a later time use the following REST api
call. Make sure to use proper network uuid.
Basepath: https://my.zipato.com/zipato-web/v2/networks/{uuid}/config
Parameter content type: application/json
Method: POST:
Example payload:
{
"broker": "tcp://192.168.1.1"
}
Box status topics
A successful inclusion is always followed by a secure inclusion procedure if the device supports
the SECURITY command class:
Secure inclusion procedure response object properties:
● type: “SECURE_INCLUSION”
● Network: “ZWAVE”
● Status:
○ DONE: Secure inclusion successful
○ FAILED: Secure inclusion failed, cause of failure set in message property
○ TIMEOUT: Secure inclusion timed out cause of timeout set in reason property
● reason/message: cause of timeout or failure
Secure inclusion may sometimes fail. The state of the device after that is mostly unknown. The
device might be fully operational or certain features might not work. It is advised to exclude the
device and include it again if secure inclusion fails.
Attribute topics
Get attribute data
Request Topic: request/attributes/UUID/info
Request Topic Payload: N/A
Response Topic: /local/ha/bridges/zipato/attributes/UUID/info
Response Type: JSON
Description: Retrieves attribute data.
Response example:
{
"uuid": "b0334f5b-572d-4bbf-851b-356c76161ca4",
"name": "VALVE_POSITION",
"attribute": "value",
"attributeId": 8,
"clusterUuid": "bef380ce-3fb6-4e8f-8518-3563c7252787",
"reported": true,
"unit": "%",
"precision": 0,
"scale": 1.0
}
Attribute values
Topic: /local/ha/bridges/zipato/attributes/UUID/attributeChangeEvents
Request Topic: N/A
Request Topic Payload: N/A
Response Topic: /local/ha/bridges/zipato/attributes/UUID/info
Response Type: JSON
Description: Unsolicited attribute change events.
Response example:
{
"className": "com.zipato.event.ThermostatSetpointValueEvent",
"clusterClass": "com.zipato.cluster.ThermostatSetpoint",
"attribute": "value1",
"value": 21.0,
"timestamp": 1459803817093,
"setpointType": "HEATING",
"source": "7a8c09b1-aa57-476d-9a8a-5610241e0755"
}
Attribute actions
Set attribute
Request Topic: request/attributes/UUID/textValue
Response/Result Topic: /local/ha/bridges/zipato/attributes/UUID/attributeChangeEvents
Request Topic Payload Type: String
Payload example: true, false (for binary switches for example)
Description: Set attribute state with plain strings
Set attribute
Request Topic: request/attributes/UUID/value
Response/Result Topic: /local/ha/bridges/zipato/attributes/UUID/attributeChangeEvents
Request Topic Payload Type: JSON
Payload example: (for binary switches for example)
{
"value": "true"
}
Description: Set attribute state with simple JSON objects
ALL_PURPOSE/GENERAL_ 156 49
PURPOSE
SMOKE 157 50
CO 158 51
CO2 159 52
HEAT 160 53
WATER 161 54
FREEZE 162 55
TAMPER 163 56
AUX 164 57
DOOR_WINDOW 165 58
TILT 166 59
MOTION 167 60
GLASS_BREAK 168 61
Invoke interface
Invoke interface is a simple JSON RPC mechanism which can be used to invoke methods of
certain objects. The invoke interface is available for the following object types:
● networks
● devices
● endpoints
● clusterEndpoints
Request topic:
request/OBJECT_TYPE/UUID/invoke
Response topic:
request/OBJECT_TYPE/UUID/messages
Request JSON payload properties:
● methodName - Self explanatory, the name of the method that needs to be invoked
● arg[1-9] - method arguments
setName
userCodeGet
Description: Retrieve specific door lock user code.
Method name: userCodeGet
Argument count: 1
Argument 1: User code slot
Argument 1 type: Integer
Target object: ZwaveUserCodeInput cluster
setIgnoreDeprecatedCc
Description: Disables handling of deprecated command classes for Z-Wave Plus devices.
Current list of deprecated command classes:
SENSOR_BINARY (replaced by NOTIFICATIONS command class)
ALARM_SENSOR (replaced by NOTIFICATIONS command class)
Method name: setIgnoreDeprecatedCc
Argument count: 1
Argument 1: true/false (false by default)
Argument 1 type: boolean
Target object: Zwave network
setAssociationPolicy
Description: set Z-Wave association policy for Z-Wave Plus devices. Current available
association policies:
LIFELINE_ONLY - Only associate with Lifeline association group
ALL_GROUPS - Associate with all association groups
Method name: setAssociationPolicy
Argument count: 1
Argument 1: name of association policy
Argument 1 type: String
Target object: Zwave network