Well, I was not aware of this: in July 2016 MQTT, already an OASIS standard, has been approved by the ISO as a standard for messaging.
Wednesday, September 21, 2016
Oracle IoT Cloud Service and MQTT support
MQTT Protocol Support for communication with devices
MQTT is a lightweight messaging protocol for device-to-cloud communication.It is based on the Publish-Subscribe model, making it ideal for applications that are sensitive to communication latency and unreliable networks.
Oracle Internet of Things Cloud Service rel. 16.3.3 has introduced support for ingesting data directly over the MQTT protocol (secure MQTT only) from devices and gateways using an MQTT bridge.
The important thing for developers is that this new protocol support does not introduce any additional client-side API changes. Existing device and gateway applications can switch to using MQTT by following a set of configuration steps to use MQTT instead of HTTP.
More information on how to set up MQTT support is available here.
Monday, September 12, 2016
Oracle IoT Cloud Service 16.3.3 now available
In the middle of August, when I was (finally) on holiday, a new version of Oracle IoT Cloud Service has been made available: vers. 16.3.3
As usual, many interesting new features have been made available:
A more complete list of the new features is available at:
As usual, many interesting new features have been made available:
- An Assett Monitoring and Tracking Application, that enables you to track even the Spatial location of your assets (things)
- Support for MQTT protocol
A more complete list of the new features is available at:
Thursday, September 8, 2016
Field gateway and AWS IoT Cloud
Very often devices are resource constrained.
For example, if you’re building a prototype using a (compatible) Arduino Uno, you have only few 100-kbs of memory to write your sketch.
This means that not always your devices are capable of supporting TLS and establishing a direct connection to an IoT Cloud Service.
In other cases, you don’t want a direct connection, for example for security reasons.
In this case, the recommended topology is based on the adoption of a “Field Gateway”. Your devices are directly connected to the gateway, they send messages to the gateway and the gateway forward these messages to the IoT Cloud Service.
If you’re using (and this is a good and one of the most commonly used approach) MQTT, then you can install a local MQTT broker on the gateway and use the “Bridge functionality” to relay messages from the local broker to the MQTT broker provided by the IoT Cloud Service.
If you plan to make use of Amazon AWS IoT Cloud, here you can find a well-made guide to configure the bridge. The local broker is Eclipse Mosquito.
For example, if you’re building a prototype using a (compatible) Arduino Uno, you have only few 100-kbs of memory to write your sketch.
This means that not always your devices are capable of supporting TLS and establishing a direct connection to an IoT Cloud Service.
In other cases, you don’t want a direct connection, for example for security reasons.
In this case, the recommended topology is based on the adoption of a “Field Gateway”. Your devices are directly connected to the gateway, they send messages to the gateway and the gateway forward these messages to the IoT Cloud Service.
If you’re using (and this is a good and one of the most commonly used approach) MQTT, then you can install a local MQTT broker on the gateway and use the “Bridge functionality” to relay messages from the local broker to the MQTT broker provided by the IoT Cloud Service.
If you plan to make use of Amazon AWS IoT Cloud, here you can find a well-made guide to configure the bridge. The local broker is Eclipse Mosquito.
https://aws.amazon.com/it/blogs/iot/how-to-bridge-mosquitto-mqtt-broker-to-aws-iot/
(updated on 30/12/2016).
Subscribe to:
Posts (Atom)