Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

If needed, local API can be activated on your access point. After setting up your site, adopting access point and gateway(s) and importing devices, you can start using your local API.

Setting up local API

The local API is based on MQTT. MQTT use a broker to communicate on topics. In order to set up Glamox Connect local API you need to set up your broker, and pass the configuration to Glamox Connect.

After you have set up your broker, go to Settings → Site → Local API to enter the broker details.

This will connect your access point to the provided broker and it will start to listen to defined topics.

Topics

There are basically three different topic categories:

Discovery topic (config)

Topic where Connect can be asked to describe devices that are available. When a request is being made on discovery/search Connect will respond publishing all devices on topic discovery/<type>/<gateway-id>/<device-id>/config

State topics

As part of payload for discovered device (from discovery topic) is the state_topic for the device. When listening to this topic you will receive all updates for this device. The payload on this topic is only the delta, meaning that values that are NOT in the payload have unchanged value.

Let’s say you have a light where the state update is brightness: 100 and the next update is then color_temp: 400, the brightness is still 100.

Command topics

For devices who listen to commands you will also get a command_topic on which Connect will listen to commands sent to the device. This topic is part of the device’s config payload on the discovery topic. Changing an attributes value and sending it is as payload to this topic will relay a message to the device.

Device discovery and device types

There are different device types in Glamox Connect and each one of them has their own discovery topic. These are

  • light

  • sensor

  • binary_sensor

When a message has been sent to discovery/search, Connect will return the devices on discovery/<type>/<gateway-id>/<device-id>/config, for example discovery/sensor/00201232ab45/100234abc35/config.

You can also provide your own discovery prefix in the payload. Glamox Connect will then send the discovery/config messages using this prefix.

Example: If you send payload "discovery_prefix": "homeassistant" to discovery/search, Glamox Connect will return the previous example using the provided prefix: homeassistant/sensor/00201232ab45/100234abc35/config

Devices and entities

So we have mentioned device types. Technically this is what we call entities. A device can have one or more entities. That means that one device in Glamox Connect can send more than one entity on the discovery topics.

As an example, most of the devices in our Glamox Wireless Zigbee system will send you a light (luminaire), a sensor (lux sensor) as well as a binary_sensor (occupancy sensor). To signal that this is the same device all entities will have their parent device in the config payload.

Discovery payload

The payload returned on a discovery topic is a config message, describing the entity of the device. ALL entities will give your system essential information on

  • unique ID’s

  • which device it is part of

  • which state_topic it will use to send its state updates. The client will need to listen to this topic to get updates for the entity

  • which command_topic it will use to send its state updates, if the entity can be controlled. The client will need to send command messages to this topic to be able to change values for the entity

  • Friendly name

In addition the entities have some fields that are specific for the entity

Light

  • The max value for brightness is given as brightness_scale. I.e. 100 means that the scale is 0-100

  • If the light has a color_mode this is given as ‘true’ as well as listing the level of control in supported_color_modes

    • brightness - only brightness control according to brightness_scale

    • color_temp - color_temp in mired and color_temp_kelvin as kelvin in addition to brightness

    • color - color control in addition to brightness and color_temp

  • If you can activate effects on the light, this is given as effect: ‘true’

  • The effect_list will (if effect) contain a list of effects the light can perform, i.e. ‘identify’ to blink the light

Light config payload:

state_topic: connect/light/001fee00000053a6/17880107102b0c/state
schema: json
unique_id: 17880107102b0c_light
object_id: 17880107102b0c_light
device:
  identifiers:
    - 17880107102b0c
  name: 17880107102b0c
  manufacturer: Glamox Connect API
  model: Wireless Zigbee
  suggested_area: mysitename
  via_device: 001fee00000053a6
command_topic: connect/light/001fee00000053a6/17880107102b0c/set
name: Light_17880107102b0c
brightness_scale: 100
color_mode: 'true'
brightness: 'true'
supported_color_modes:
  - brightness
effect: 'true'
effect_list:
  - identify
platform: mqtt

Sensor and binary sensor

  • The device_class will tell you which kind of sensor the entity is

    • illuminance

    • temperature

  • For sensors, the unit_of_measurement is provided to indicate how to interpret the state.

    • This is NOT available for binary sensors as they are always ‘ON’/'OFF'

  • A value_template is also included for the integrating system to know what the value field of this sensor is given as. In the example below the state will be reported as "lux": 480 in the json payload.

Sensor config payload:

state_topic: connect/sensor/001fee00000053a6/17880107102b0c/state
schema: json
unique_id: 17880107102b0c_illuminance
object_id: 17880107102b0c_illuminance
device:
  identifiers:
    - 17880107102b0c
  name: 17880107102b0c
  manufacturer: Glamox Connect API
  model: Wireless Zigbee
  suggested_area: glamoxmoldetest
  via_device: 001fee00000053a6
name: Sensor/Illuminance_17880107102b0c
device_class: illuminance
unit_of_measurement: lx
value_template: '{{ value_json.lux }}'
platform: mqtt

Binary_sensor config payload:

state_topic: connect/binary_sensor/001fee00000053a6/17880107102b0c/state
schema: json
unique_id: 17880107102b0c_occupancy
object_id: 17880107102b0c_occupancy
device:
  identifiers:
    - 17880107102b0c
  name: 17880107102b0c
  manufacturer: Glamox Connect API
  model: Wireless Zigbee
  suggested_area: glamoxmoldetest
  via_device: 001fee00000053a6
name: Sensor/Occupancy_17880107102b0c
value_template: '{{ value_json.presence }}'
device_class: occupancy
platform: mqtt

Listening for device updates

As mentioned earlier, each entity will provide their state_topic in the config payload. This means that in order to get the updates for the devices/entities you want, you need to listen to the topics provided.

When an update to a device occur, Glamox Connect will then send the delta on the given state topic. This means that you will NOT get the full state of the entity, only the change.

Example:
Given a state for a light as following

{
  "brightness": 100,
  "color_temp": 200,
  "color_temp_kelvin": 5000,
  "state": ON
}

If we change the brightness of the light in the example to 80%, the state update sent on the state_topic will be as following

{
  "brightness": 80
}

Similar for sensors, typical status updates will look like this

{
  "lux": 670
}
{
  "temperature": 25.1
}
{
  "occupancy": ON
}

Sending commands

If you want to send commands to a device, you will need to send it to the entity on the command_topic provided in the config payload.

Lets look at the previously given config payload for a light. In the config payload we have the following line

command_topic: connect/light/001fee00000053a6/17880107102b0c/set

To change a value for this entity we need to send a valid json payload to the given topic

Turning the light off:

{
  "state": OFF
}

Changing brightness:

{
  "brightness": 80
}

  • No labels