We developed an iOS application and configured the app to listen to all the messages published on a particular MQTT topic on AWS IoT.
All I want to know is, is there a way where I can pull a list of connected devices who are listening on that topic ? (I checked the cloudWatch logs and I couldn't find the detailed info like the MAC address of the device connected etc).
Also, I want to know if there is limit on the no. of devices that can be subscribed to a topic.
There is no limit to the number of devices on a single topic. One of the major pros for the service - it scales virtually infinitely. Here's a full list of all the AWS IoT Limits.
There's no easy way to query the number of devices connected directly from AWS IoT. But there is a way to detect when any device subscribes and unsubscribes from a topic using the message data from AWS Reserved Topics - specifically these topics below:
$aws/events/subscriptions/subscribed/{clientId}
$aws/events/subscriptions/unsubscribed/{clientId}
You could create an IoT rule to forward all subscribed and unsubscribed events from those reserved topics to S3, DynamoDB or RDS to be queryable. A simple Lambda function to increment on subscribes and decrement on unsubscribes within DynamoDB would work really well too. (DynamoDB Atomic Counter)
Also here's what the message body looks like - from Subscribe/Unsubscribe Events:
{
"clientId": "186b5",
"timestamp": 1460065214626,
"eventType": "subscribed" | "unsubscribed",
"sessionIdentifier": "00000000-0000-0000-0000-000000000000",
"principalIdentifier": "000000000000/ABCDEFGHIJKLMNOPQRSTU:some-user/ABCDEFGHIJKLMNOPQRSTU:some-user"
"topics" : \["foo/bar","device/data","dog/cat"\]
}
Related
I am trying to find the connected devices and according to the forums and was advised to subscribe to "$aws/events/presence/+".
I have created two clients where one subscribes to the "$aws/events/presence/+" topic and the other one sends the connect command.
I could not see any activity under the tab.
Could you please help me to resolve this?
There is a subtopic to the presence topic that you need to consider by either adding the subtopic or using the multi-level topic wildcard (# instead of +). This means you need to subscribe to $aws/events/presence/connected/+ (or $aws/events/presence/# to monitor both connections and disconnections).
This accounts for the connected and disconnected subtopics on the reserved topics $aws/events/presence/connected/clientId and $aws/events/presence/disconnected/clientId.
I set up an architect for my solution think that iot hub does the work of an mqtt broker, but when I started the implementation , I found that you cannot subscribe to a specific subject to retrieve messages published by another mqtt client, the notion of topic does not exist on iot hub.
I have read several articles about this subject but I have not found an appropriate alternative.
Iot hub has only two topics, and event hub endpoints are limited to 10 endpoints
Can you guide me or suggest a solution with a broker?
How can I subscribe to a specific topic?
I want a device to device communication with pub / sub
Example: a device publishes on a topic / home / room
another device subscribes to / home / room
using iot hub
I am open to all proposals
Thank you
Cloud development
IoT Hub has a limited MQTT broker implementation, because of that, you can't subscribe to device topics from other devices. You could use an Azure Function to catch all your messages and decide if it needs to send a Cloud to Device message. You could also leverage Stream Analytics to decide if a message needs to be sent before talking to that Function. This is probably your best bet if you want to play by Azure IoT Stack's rules.
No cloud development
If you really want your devices to listen to each other, there is an old blog post that describes a scenario where a device uses the service SDK to listen to messages sent to IoT Hub by a different device. It lists the pros and cons in the post.
Custom edge module
If your devices are on the same network, you could build an Edge Module that implements an MQTT broker. The devices would then connect to the edge device as they would in a normal gateway scenario, but also to your custom broker. In your routing, you would then send all the messages to your custom broker to be transmitted to any devices listening to that topic, while still sending the data to the cloud. I imagine their are a few security risks you want to look into if you go in this direction.
So in short: it's possible, probably in many other ways, but in the end you are leveraging a cloud platform that doesn't support this natively.
I am trying Google IOT and Google PubSub.
I am sending MQTT messages from device to a pubsub queue on which I have subribed (with something I will call "the server").
From the google cloud console, I update device setting and I get the setting message in device.
Everything in google tutorial work fine but I wonder if it is possible to set up a messaging it the other way : i.e. "the server" sending message to a pubsub queue subscribed by the device using MQTT.
The schema at the end of this page make me think that only the "config" mqtt queue (/devices/XXXX/config) can be used that way.
What I need is a 1to1 communication from "the server" to "the device" and I'm afraid that the only way is using the config
I am not an expert on Google IoT, but few days ago I got the same doubts about it. Apparently, although we can publish to /events, /config and /state topics, using MQTT protocol, only topic /config and, maybe, /state can work through subscriptions with the same protocol.
The conclusion I got, after reading many times the documentation, that is not so clear, and asking some questions here at stackoverflow is: you can not use MQTT to subscribe to any topic in order to receive those data sent to /events topic.
To accomplish this, you have to create a Pub/Sub topic associating it to your device:
On Google Cloud IoT Core Console, click on your registry ID;
Create a standard telemetry topic;
After topic created, click on the topic to see its details;
Its details will open on Google Cloud Pub/Sub panel;
In this panel, you can create a subscription to the created topic, by clicking on the "create subscription button".
Now that you have a "google cloud pub/sub topic" linked to "google cloud iot core /events telemetry MQTT topic" and a respective subscription, you can use the google pub/sub library to receive notifications through created subscription when data are sent to /events topic.
Maybe the following link can also help:
https://cloud.google.com/iot/docs/how-tos/devices#creating_a_device_registry_with_multiple_pubsub_topics
I hope this can help you. If I made any mistake in my answer, may someone edit it with some improvement or correction.
Today I got same issues. Seems you cannot get data by subscribe with MQTT. You need to create a pub/sub topic in Goolge iot pub.sub
Goal: Send messages to a group of Azure IoT Hub Devices that are connected via MQTT WebSocket.
Initial Idea: Have a group of IoT Hub Devices (group X) subscribe to messages with topic X.
Problem:
On the Communicate with your IoT hub using the MQTT protocol docs, I don't see a way to subscribe a device to additional topics. I only see examples of a subscription to a device specific endpoint devices/{device_id}/messages/devicebound/#.
The page goes on to say "IoT Hub is not a general purpose pub-sub messaging broker, it only supports the documented topic names and topic filters." I think those topics are
devices/{device_id}/messages/devicebound/
devices/{device_id}/messages/devicebound/#
My Conclusion: I can't have a group of IoT Hub Devices (group X) subscribe to messages with topic X.
Questions:
Is my conclusion correct?
If my conclusion is correct, is there another way I can send messages to a group of Azure IoT Hub Devices that are connected via MQTT WebSocket?
Your conclusion is correct. Azure IoT Hub is not an MQTT broker per se.
If you want to send messages to a group of devices connected to Azure IoT Hub (independently of the protocol they are connected with), you need to look into one of the Cloud 2 Device features of IoT Hub.
Depending on your scenario you can use one of the following: Cloud 2 Device messages, Twins or Methods. IoT Hub exposes APIs on the back-end side (easily used with the Service Client SDKs) allowing to use any of those.
C2D messages are used to send raw data to devices, meaning you implement your own "protocol" between cloud and device. C2D messages are also persistent in the Cloud as IoT Hub will retain them (for a certain time defined in settings) if the device is not connected.
Device Twins allows to synchronize a configuration of a device with the Cloud and allows for batch operations on devices (certainly one you want to look closer into).
Device Direct Methods allows to call a function running on a device from the cloud and like Twins supports batch operations.
MQTT is usually described in IoT scenarios where there are lots of publishers (e.g. field devices , sensors) and likely few subscribers (e.g. application servers).
I would like the application servers to be able to occasionally send messages to selected field devices. That would mean that application servers would be the publishers and field devices would be the subscribers.
Is MQTT designed to correctly flow info into this direction: From a few publishers to thousands of subscribers? Is the architecture and protocol designed to efficiently cope with such scenarios? If not, are there alternatives?
MQTT works fine in both directions.
If the field devices can be grouped then a topic per group would work, but equally fine for each device having it's own topic to send a message to a single device.