Develop device firmware
To integrate devices with the Bosch IoT Suite you have to use existing firmware or develop a custom device firmware.
The device will send data to our cloud services, and will need to handle remote control operations, sent from your business applications via our cloud services to your connected devices.
Table of contents:
How to execute
Decide about connectivity pattern and protocol
See Concepts to decide whether you can connect the edge devices directly to the cloud services, or if you prefer connecting them via gateway.
Choose a communication protocol that matches this pattern and your further requirements, e.g. HTTP, MQTT, ZigBee, Bluetooth.
Further, consider what bandwidth can be consumed, requirements regarding bi-directional communication, energy consumption, security, etc.
Select a device/firmware software stack
Depending on the type of device, the hardware platform of the device, and the selected connectivity pattern and protocol, you should select the appropriate device/firmware software stack to develop your firmware.
The device/firmware software stack normally covers the level of the (real-time) operation system, hardware abstraction, and communication support.
Examples for embedded software stacks are: Mbed, Arduino, FreeRTOS, or Embedded Linux distributions.
Define scope and type of information exchanged with the cloud
Think about structure of data, direction, data types, distinction of properties updates vs. events and update interval.
Prepare message payloads
You generally have two options regarding message payloads when you send messages:
You can either use a predefined payload format, that the Bosch IoT Suite supports directly.
Or you can send data in a native format, that is either already provided by the device, or that best matches the requirements on device side.
The Bosch IoT Suite supports to accept message payloads that match the Eclipse Ditto format. The Protocol specification and examples are open.
When sending native format, you can use a payload mapping functionality provided by the Bosch IoT Suite to transform incoming and outgoing messages to this expected format.
See Payload mapping documentation for details.
After preparing message payloads you can send them to the cloud.
Choose the right communication pattern based on your communication protocol and your requirements regarding the quality of service.
See Device Communication Patterns in the Bosch IoT Hub documentation.
Leverage the network/communication libraries provided by your device/firmware software stack to develop the code that applies the communication establishment (incl. authentication) and actually sends the messages.
Process remote control operations
For remote control scenarios you need to implement code that processes such operations. Messages for such operations either represent requested properties updates on a device, or represent invocations for functions on a device.
These messages are - again - defined using the Eclipse Ditto protocol, or can be based on a custom protocol, and need additionally to be transformed form this protocol to the custom protocol using payload mapping as described in the section above.
In order to receive remote control messages, your device has to follow one of the command&control patterns defined by the Bosch IoT Hub.
See Command & Control for a description of these patterns.
Create a model for your device
To enable simplified provisioning of your device, create a semantic model in the Eclipse Vorto GitHub repository. Refer to the Eclipse Vorto documentation on Github on how to create models.
While developing firmware for your devices, please make use of the best practices listed at General retry and reconnect guidelines for applications and devices.