I wanted to make use of Shared Subscription feature of MQTT v5. But currently I am using AKKA MQTT client which doesn't support MQTT v5 client. Can I still use v3 MQTT paho client and use Shared Subscription feature?
That should not be a problem as from the viewpoint of an MQTT v3 client a shared subscription is just like any subscription.
The broker has to do all the work regarding shared subscription logic.
The only hindrances I can see are:
that an MQTT broker might support v5 but not v3/v3.1.1
the broker doesn't support shared subscriptions in general (yes they exist)
the broker supports all MQTT versions but handles them as two different protocols (not sure if this is a thing)
Using paho client write an app(ensure that this will use MQTT v5) that will have two clients.
Client_v3 will subscribe to the topics from the source i.e. from the app that sends MQTT v3
Client_v5 will publish the received topics as it is received in the above step.
In your application where you want to use shared subscription(again ensure it uses MQTT v5) alter the topics $share/<topic> and make it to get the topics from the client_v5 publish
In simple word: make you paho client code to act as a broker between v3 and v5 apps.
Related
I would like to know if it is possible in a standard MQTT bridge configuration with Mosquitto the dynamic subscription of topics from the MQTT clients to the remote broker.
That is, only if a client requests the subscription to a certain topic, it is Mosquitto who requests to the remote broker the subscription to that topic.
From what I have seen in the configuration it is possible to set it statically when starting the Mosquitto service but not dynamically according to the requirements of the MQTT clients who can decide at runtime to which topics they want to subscribe.
Is it possible in a Mosquitto bridge, a dynamic subscription scenario in which the subscription request of the clients is forwarded to the remote broker?
It is not possible, the broker does not support dynamically changing the bridge subscription.
It's also doing dynamic subscription forwarding won't work well in a situation where usernames/password and ACLs are implemented because the bridge connection acts as any other client connection. This means that the bridge connection can only subscribe/publish to topics allowed by the user assigned to the bridge.
Both brokers are likely to have very different sets of users and ACLs in place
There are 2 clients (A and B) that are connected to the ActiveMQ Artemis broker. The protocol we are using is MQTT. Both clients have different topic templates that they subscribe. For example client A has subscription topic template of school/readings/# and client B has subscription topic template of Domestic/readings/#.
There will be our server that subscribes all the topics with their respective template.
If client B decides to read all the incoming messages to the broker by subscribing with topic (# or school/#) then there could be a data leak. The requirement here is only our server should subscribe all the topics and other client should have restrictions in topic subscription.
Is there any way to restrict clients subscription or is there any way to avoid this type of data leak?
Both the clients should have the privilege to publish and subscribe to the broker, but one client should not subscribe to another client's topics.
There is no data leak, unless you configured authorization rules and they are not being enforced or you find a way to get unauthorized access when security is enabled (in that case open a bug here). Please, find out here the documentation on how to use security-settings to configure the authorization rules for your use case.
I'm struggling with the IOT Central SDK to send reported properties to my IOT Central but so far I haven't found any way to do it.
Have anyone managed to perform this very task? I have no problem sending properties or events / telemetries but I've been struggling with this for a while with no results.
The Device Twins features are supported for devices with the MQTT or AMQP protocols to the Azure IoT Central (Azure IoT Hub).
For your requirement such as using a device in the iOS Application, I do recommend using the MQTT protocol directly to the Azure IoT Central (Azure IoT Hub) and some iOS MQTT client library, for example MQTT-Client-Framework.
For test purposes of the features how to use the MQTT protocol directly, you can use any MQTT client tools such as MQTTBox, MQTT.fx, etc.
The following screen snippets show an example of using the MQTT protocol directly to the Azure IoT Central, where the MQTTBox client updated a device1 reported property (name battery):
Does the Paho Java client has any callback function called when a new client connection is established? Within that function I want to validate user and if failed refuse connection.
When a new client connect from javascript or any client I should be able to allow or refuse new client.
This is not possible to do from a client, the MQTT protocol has no support for anything other than passing authentication information from a single client to the broker, not the other way round.
You have to do it from within the broker. Different brokers all implement authentication differently so it will depend entirely on which broker you are using.
Mosquitto has an API to write authentication plugins. e.g. https://github.com/jpmens/mosquitto-auth-plug
HiveMQ Also has an API http://www.hivemq.com/blog/mqtt-security-fundamentals-advanced-authentication-mechanisms
Mosca - https://github.com/mcollina/mosca/wiki/Authentication-&-Authorization
I am working on a device management solution for an IoT device. The device will host an LWM2M client. A gateway device (currently an Intel Galileo board), will host an OMA-DM client and a LWM2M server.
The general scenario is that the nodes should be able to be managed by any OMA-DM or LWM2M compliant device management server.
In case of an OMA-DM server, the commands will be sent to the gateway where they will be received by an OMA-DM client and passed on to the nodes directly as LWM2M commands or the client will use the APIs of the LWM2M server to create and send the message/command.
As such I wanted to know if there is any solution currently available that can help with this.
OR
Are there any guides or papers or any information of any kind to help me implement this solution?
OMA has something called the LwM2M gateway which interfaces an OMA-DM server to an LwM2M Server. So check out the MAI (Mobile Application Interface) gateway specs (which I don't think are finalized yet).