I try to design the topic structure for manage devices in factory
Should I create only one general topic and all devices need subscribe to. With this way, we must do some filter at device code to receive exactly message
Related
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 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.
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.
I'm implementing an XMPP Chat and I was wondering if there is any XEP regarding lists of conversations (like WhatsApp). With message archiving, the clients can retrieve the message history with a given user, but if they open the application for the first time, they doesn't know which users they've previously talked to.
I use ejabberd as my server.
Unfortunately, I do not know of such a XEP. Most XMPP systems assume you will have a roster. Then, it's easy to fetch chat history between you and a particular user just by querying the Message Archive (XEP-0313) with that user's JID.
That being said, I also believe a roster-agnostic Chat-partners XEP would be nice to have.
I am developing an App and I am using MQTT protocol supported by Paho library.
I am subscribing to 10 topics, and there will be a messgae(s) published for one at least one topic. now, when I get notified about the arrival of a new messae, how can i know to which topic it belongs?
Update:
The object that you get when the message arrives should have a destination field which will contain the topic.