I'm trying to play with AWS IoT to communicate with multiple identical devices.
So far, so good, all my devices are connected to it, and the only difference between them could be a single device ID (like a mac address or a serial number)
Now I'd like to send a message to a single specific device using its device ID and I don't know if there is a good way to do that?
I could make each device to subscribe to a topic like /<DEVICE_ID>, however it doesn't seem like a good practice especially if I have thousands of devices.
Plus, AWS discourages it as stated in the AWS IoT documentation:
Note
We do not recommend using personally identifiable information in your
topics.
Is there a good way to handle this use case? Or is AWS IoT only useful to manage multiple devices at once?
Here is the best practice for creating an MQTT topic.
https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/
Talking about your specific case
Each device needs to have a unique identity to send a command to a particular device. In this case, you need to have device_id into your MQTT topic.
You can use the following pattern to send a message for a destination device
protocol_prefix / type_of_message / dest_id / message_id
hexaiot/controldevice/d12345/x123
Use wild card character at the time of device subscription to subscribe to the topic
Related
I have a need to poll for a close-to-real time reading from a serial device (using ESP32) from a web application. I am currently doing this using Particle Photons and the Particle Cloud API, and am wondering if there is a way to achieve similar using Google Cloud IoT.
From reading the documentation, it seems a common way to do this is via PubSub and then to publish to BigQuery via DataFlow or Firebase via Cloud Functions. However, to reduce pricing overhead, I am hoping to only trigger a data exchange(s) when the device receives an external request.
It looks like there is a way to send commands to the IoT device - am I on the right track with this? I can't seem to find the documentation here, but after receiving a command it would use PubSub to publish to a Topic, which can trigger a Cloud Function to update Firebase?
Lastly, it also looks like there is a way to do a GET request to the device's DeviceState, but this can only be updated once per second (which might also work, though it sounds like they generally discourage using state for this purpose).
If there is another low-latency, low-cost way to allow a client to poll for a real-time value from the IoT device that I've missed, please let me know. Thank you!
Espressif has integrated Google's Cloud IoT Device SDK which creates an authenticated bidirectional MQTT pipe between the device and IoT Core. As you've already discovered, you can send anything from the cloud to the device (it's called a "command" but it's just an MQTT payload so you can put almost anything you want in it) and vice versa (it's called "telemetry" but again it's just an MQTT payload). Once incoming messages from devices reach the cloud, pubsub can route them wherever you want. I don't know if I'd call it real-time, but latencies in a good WiFi network tend to be under a second.
I will have some thousands of NB-IOT devices connected to Azure IOT-HUB, they will send different alarm messages in case something is wrong where they are, like high temperature etc. Are there some dashboard or list overview I can connect the IOT-HUB to ? I would like to have a list with all alarming IOT devices, i.e. if no alarm message/ceased alarm, then they shall not be in the list. (I can see the messages in the visual studio so the MQTT messages set-up is done).
BR
The closest thing to an "out of the box" feature for this would be to use IoT Hub queries. You can use device twins to set the device status. The status could be "nominal/alarm", that way you can use the IoT Hub Query language to extract a list of devices currently in a certain state.
You would need to update your devices to have the device report updates to the device twin, or you need to write a piece of code that takes the messages and updates the twin from the backend.
You mentioned a dashboard, I'm not aware of any out of the box solution for this, but you could use PowerBI to create a dashboard based on a number of data sources. There are many Azure components you can store your telemetry in, and you can use PowerBI to create a list of devices whose last message was an alarm. Putting Stream Analytics in between would enable you to store just the alarms in a database.
In short: there are many ways of getting to the same result, as far as I know, none will be out of the box.
Upon using the Google Cloud IoT Core platform, it seems to be built around the idea of sending configurations down to the device and receiving states back from it.
Google's own documentation suggests using that approach instead of building around sending commands down (as a config) and getting responses back (as a state).
However in the very end of the documentation they show an example of exactly that.
I am struggling to understand how does one support both approaches? I can see the benefit of how it was designed but I am also struggling to understand how would one be able to talk to the device using such an idiom of values and results as the config.
Has anybody implemented a command/response flow? Is it possible to subscribe to the state topic to retrieve the state of the device in my own application?
Edit based on clarifying comment below:
We've got a beta feature we're calling "Commands" which will do the reboot you're talking about. So the combination of config messages (for persistent configuration that you want to send a device on startup/connect to IoT Core) and Commands for fire and forget like a reboot message can do what your'e talking about. Current state is a bit trickier, in that you could either have a callback mechanism where you send a command to ask, and listen on the events/ channel for a response, or have the device report state (/state/ MQTT topic) and just ask IoT Core's admin SDK rather than the device.
Commands just went open beta, you should have access to it now. If you're using the gcloud SDK from command line, you'll need to do a gcloud components update and then gcloud beta iot devices --help will show the commands group. If you're using the console, when you drill down to a single device, you should now see "Send Command" next to "Update Configuration" on the top bar.
Old Answer: As a stab at answering, it sounds like rather than using the state topic, you could/should just use the standard /events/ topic and subscribe to the Pub/Sub topic the devices go into instead?
It really depends on the volume and number of devices we're talking about in terms of keeping that state machine in sync.
Without knowing what specifically you're implementing, I'd probably do something like send configs down, respond from device on the /events/ topic, and have a Cloud Function that tracks the Pub/Sub topic and updates something like a Firestore instance with the state of the devices, rather than using the /state/ topic. Especially if you're doing something in response directly to the state reporting of the device.
Send command to device
To send a command to a device, you will need to use the sendCommandToDevice API call.
Receive command from device
To receive a command from a device, subscribe to the /devices/<your-device-d>/commands/# topic.
Full examples will eventually be published to the Google Cloud IoT Core samples repos:
Java
NodeJS
Python
I am trying to send chunks of a data by using MQTT to aws IoT and by rule engine, the data will be streamed to a web app in real time (or near to real time )manner.
I am trying to find a way by which I can get some kind of acknowledgement. the role of acknowledgement is important for my use case as I am trying to send some kind of medical equipment data (lets say blood pressure data during operation).
thus, In a nut shell, I need a quickest way to transfer data(just like MQTT) between the device and AWS IoT which should have some kind acknowledgement mechanism.
Also I would like to add that ,'if suppose the device or web server could not get the message sent by MQTT due to some internet issues, then it will be lost right. I need to add some sort of mechanism by which the mqtt messages could be buffered and queued for some time so that once the device or web app comes online it can get the queued data. I also know that there is something called device shadow but we have thought using it differently. can you suggest about it ?'
I am sure that some of you have faced this problem and also found an alternate of MQTT in data transferring to AWS IoT.
Kindly share your thoughts.
Thanks.
I have an app that subscribes and publishes to topics on aws IoT. I am wondering what the difference between the two classes "device" and "thingShadow" are. This library gives examples of both and they both seem to have similar functionalities.
The device class is used to subscribe to and publish messages on MQTT topics for telemetry and messaging purposes.
The thingShadow class is a wrapper around the device class, which provides additional methods such as .register, .update or delete which are designed to interact with a device shadow. This class also emits specific events associated with a shadow lifecycle such as status, delta or foreignStateChange.
[...] the thingShadow class allows devices to update, be notified of changes to, get the current state of, or delete Thing Shadows from AWS IoT.
So basically, if you're using device shadows use the thingShadow class, otherwise you can use the device class.
EDIT:
To expand a bit more on the basic principles of AWS IoT, you have two communication scheme between devices:
Since AWS IoT implements a standard MQTT interface, you can use topics to communicate with your devices using a pattern called publish-subscribe. Your apps can subscribe to a topic and wait for a device to publish a message on it. Similarly, your app can publish a message on a device topic and have the device receive it.
AWS IoT implements a second communication interface called the device shadow, which allows you to address a device even when it is disconnected, and keep a synchronized state between your app and the device itself. The AWS documentation explains it in clear terms.
A thing shadow (sometimes referred to as a device shadow) is a JSON
document that is used to store and retrieve current state information
for a thing (device, app, and so on). The Thing Shadows service
maintains a thing shadow for each thing you connect to AWS IoT. You
can use thing shadows to get and set the state of a thing over MQTT or
HTTP, regardless of whether the thing is connected to the Internet.
Each thing shadow is uniquely identified by its name.
The two interfaces can be addressed in the SDK using the device class for subscribing and publishing on MQTT topics, and the thing shadow class to retrieve, update or delete a device thing shadow document.