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.
Related
I want to post data to 2 different devices from same esp32. And I want to do it like posting all the data to one device and sharing its telemetries with the second device. Is that possible on thingsboard?
I achieved this via ESP32 but when I am posting data with two different token, I need to cut the wifi and reconnect the Thingsboard with the other devices token. This situation contributes to enormous battery consumption. When I examine the thingsboard library I could not see a function about cutting the network only with thingsboard. What can be done to overcome this situation?
Any idea will be appreciated.
Thanks
One way I could think of, would be using ThingsBoard Integrations. Where one input payload can have multiple outgoing payloads (works even for multiple target devices or assets):
https://thingsboard.io/docs/user-guide/integrations/#converter-output
But this requires ThingsBoard PE & an external MQTT Broker in between your ESP32 & TB.
Or you could try the MQTT Gateway API:
https://thingsboard.io/docs/reference/gateway-mqtt-api/
Just getting started with MQTT.
I'm building a desktop application to monitor and control a bunch of network-connected devices. Sometimes this will call for the publish/subscribe style of communication, but in many cases the user will want to select one device and issue commands to it or query it for some data.
Articles about MQTT usually stress the lack of direct connection (or even awareness) between nodes. But if you want to query and control a single device, obviously that's not going to hold. How do you select a single device and address it over MQTT? Publish a message that uses that device's unique identifier as a topic? Or is there some more elegant approach?
An example might be: Some of the devices on the network accumulate audio recordings and place them in files. I want to retrieve a list of the files on a particular device. A few seconds later I might want to tell that device to play back one of those files.
The ONLY addressing in MQTT is the topic names
So you have 2 options
Have each device subscribe to a topic that includes a unique identifier for the device.
Include the devices unique identifier in the message and only have the device the matches act on it.
The first option is of course far better as it vastly reduces both the bandwidth (as the message is only sent to the right device) and the complexity as you need much less conditional logic on the device.
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'm doing some network research, I want to find all the IoT devices (or at least devices that could be IoT) from .pcap files. Do IoT devices have some unique traffic characteristics, traffic pattern or identification (eg. protocols, ports, etc)? I can't find the answer. IoT devices are relatively new so there is not that much documentation about it.
Thanks!
This is an active area of research and may require some sort of ML algorithm. We (3 students at UC Berkeley) are also looking into it. Do you have any pcaps you can share?
There are many characteristics, but because this is a new field with insufficient standardization - there is no solution to find all devices, and you will have to use several different methods.
Watch the protocol - some devices use niche protocols that single them out (like SIP for VOIP devices)
Watch the urls devices are looking for via DNS - since most iot devices are not directly human controlled like normal computers, their communication is rather unique per device. They will contact the site of their vendors for updates, send and receive data that directly relates to their function and won't have much variance in their behavior.
Watch for service discovery protocols. Many protocols include the service that the device gives as field. Read about ssdp and mdns.
There are many more complex ways of using the fact that most of the communication is pre-defined. Devices have unique patterns of communication - like specific times between requests for example.
There really isn't. It's an internet device after all, and the manufacturer and the user through configuration will define its traffic pattern.
That said, there will be a traffic pattern for a particular type of IoT devices. Sine IoT devices always phones home for legit reasons, you can probably find your device types by the servers they connect to, and use that to refine your statistics/ML algorithm.
Now on a tangent, a lot of IoT devices (medical devices, OnStar, Tesla and etc) use cellular networks, both for mobility and for reliability. There are a set of protocols that show a lot more information.
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.