IoT Application Service
The function blocks included in this library communicate via MQTT protocol with the IBM Watson IoT Platform which acts as a broker. A secured connection (SSL/TLS) to the IBM IoT Platform is built by the client. The necessary parameters are defined in the device configuration. The objects are communicated as secured json strings.
Available Function Blocks
Application client state
Elements and functionality of the MQTT protocol
MQTT clients can be different devices or applications, which are able to send and receive MQTT messages. These clients are not interconnected, as they communicate over a broker with each other. Examples of such client devices are sensors, controllers, smartphones and other devices, which can run a MQTT library. In general, clients can be publisher and subscriber at the same time.
The broker is a central server, which receives the sent message of the publisher and forwards it to all receivers (subscribers) that have a subscription for this topic.
Example: If the broker receives a message with a temperature value from a temperature sensor in a building, it publishes the message to all receivers that subscribed to the topic with the temperature value.
The message contains the topic and the actual user data, and is sent from the publisher via broker to the subscriber.
Describes the sending of a message by a client, triggered by a certain event.
Describes the registration for the receiving of messages, which contain a certain topic.
NOTE: In general, the MQTT protocol allows the usage of wildcards (# und +) for the subscription of topics. However, the described function blocks in this document do NOT support this feature.
The topic is a text that represents a hierarchy, using a slash (/) as a separator. It stands for the subject of the message: Normally the structure looks like that:
However, such hierarchy is NOT applicable for function blocks in connection with the IBM Watson IoT Platform.
|Quality of Service (QoS)
QoS contains 3 Levels.
If events cannot be published (interrupted connection), they are buffered. That is accomplished by following two steps:
- If the connection is re-established during the defined “keepAlive” cycle, the events which were kept in the memory are published as quickly as possible.
- If the connection is interrupted longer than with the defined period of the “keepAlive” cycle, the events are buffered in a database. If the connection is established again, the content of the database is published as quickly as possible.