my question is regarding the configuration of the RSMB using MQTT topic names and MQTT-SN topic ids over a MQTT-SN gateway.
Using the "Getting started with the Really Small Message Broker" information is very useful to figure out how to configure topic name mapping in the case of connecting two Really Small Message Brokers together.
Regarding to the MQTT-SN specification v1.2 in section "6.10 Gateway's Publish Procedure", the gateway (in my case a gateway included in the RSMB, using the broker_mqtts implementation) may send a REGISTER message to inform the client about the topic name and its assigned topic ID value. Now, I would like to configure the mapping of MQTT topic names to pre-defined MQTT-SN topic IDs.
Is it possible to configure a mapping in the RSMB broker.cfg configuration to tell a MQTT-SN client the pre-defined topic ID after a successful connection to the RSMB?
Unfortunately no.
RSMB does not support predefined topics at the moment.
However you can register topics from client side.
Or you can subscribe on real topics.
I found RSMB nowhere near production ready. You can experiment with it, but it has a LOT of bugs.
I was facing same problem with RSMB. Then I decided to fork original Git project on Github and add this feature myself. It is available on https://github.com/MichalFoksa/rsmb. Feature is documented in Getting started.
It supports:
Dynamic pre-defined topic name, where place-holder [ClientId] is replace by replaced by actual value of client Id. For example a message published by a client called "Sensorduino" sent to a pre-defined topic name sensor/[ClientId]/meter will be published on topic: sensor/ Sensorduino/meter.
Client specific configuration. It is topic name to topic Id mapping specific only for a particular client.
Hope it helps and it is not too late.
Michal
A more advanced fork of #michal-foksa RSMB supports predefined topic in a config file.
https://github.com/tonnenpinguin/rsmb
Related
When subscribing to a wildcard and a topic that overlaps that wildcard, the client receives twice the messages because of this overlapping behavior.
Example:
Client-A:
subscribe{aaa/bbb/+/ddd, aaa/bbb/ccc/ddd}
Then, if I publish something on the wildcard topic, Client-A will receive only one:
Client-B:
Publish{aaa/bbb/www/ddd, "blablabla"}
Client-A:
Received{aaa/bbb/www/ddd, "blablabla"}
But, if I publish on the specific topic, Client-A receives twice:
Client-B:
Publish{aaa/bbb/ccc/ddd, "blablabla"}
Client-A:
Received{aaa/bbb/ccc/ddd, "blablabla"}
Received{aaa/bbb/ccc/ddd, "blablabla"}
Checking the MQTT specification, it states this (source, page 36, section 3.3.5 Actions):
When Clients make subscriptions with Topic Filters that include wildcards, it is possible for a Client’s subscriptions to overlap so that a published message might match multiple filters. In this case the Server MUST deliver the message to the Client respecting the maximum QoS of all the matching subscriptions [MQTT-3.3.5-1]. In addition, the Server MAY deliver further copies of the message, one for each additional matching subscription and respecting the subscription’s QoS in each case.
If I use the Paho MQTT-SN Gateway (Server), then the server sends only once. But if I use the Eclipse Public Server, then I receive twice. The behavior is not consistent, or, at least, I cannot expect which behavior will be until I test it.
The question is: is it possible to set the specific behavior for the wildcard overlap to send only once? Or it depends on server-to-server implementation?
As the specification says that either behaviour is correct it becomes a choice for the broker implementers and likewise adding a configuration option to change the behaviour one way or the other would be a choice.
You will have to test any broker you are using and then consult their documentation to see if it is possible to change the behaviour.
There is no generic answer to this question.
How can I tell mosquitto MQTT what to do in case multiple persistent subscribers attempt to connect with the same client ID?
I accidentally ran into this situation when misconfiguring different testing environments which subscribed to the same broker. The result was that both subscribers got only part of the messages and the mosquitto log was spammed with "New connection from xxx" messages. Preferably the second subscriber would be rejected to make such a mistake apparent immediately.
I found a similar question for Solace and it seems to offer the option to either replace the older subscriber with the new one or reject the new one.
However when checking the available options for mosquitto.conf I could not see a similar option.
You don't.
The MQTT Spec says that client ids have to be unique and the correct behaviour is to kick the oldest one off and replace it with the new one.
I am trying to subscribe to multiple topic levels in the configuration file and the aim is whenever I launch the MQTT, the broker has those topics, after which when I enter a wild card it string compare and checks if the topic is on the broker and if yes it extracts the data and if not it jumps to the next branch level
I have tried to write a level topic tree but dont know how to subscribe in the config file, as I am most sure if mosquitto.subscribe will work there or not
Below shows the snippet of the topic tree,
tree is the root node,
sub_branch = tree/sub_branch;
sub_branch_1 = tree/sub_branch_1;
branch_1 = tree/branch/branch_1;
branch_2 = tree/branch/branch_2;
After launch, the topics are on the broker and I use wildcard
tree/#;
this should give me data for all the branches
and if topic = tree/ranch; its an error(wrong topic) and ask for the next one
Any help is much much appreciated!
You do NOT configure topics on the broker, the broker has no knowledge of what topics a client might publish messages to or what topics a client might subscribe to (apart from in any Access Control Lists).
As far as the broker is concerned topics don't exist until a client publishes a message, at which point it does the following things in order:
Checks the ACL for that user/client if one exists to see if there is a pattern matching the incoming topic and accepts or discards the message if there is a match
Assuming it accepts the message it then searches the list of topic patterns for all subscribed clients.
If there is a match for a client it checks that client's/user's ACL to see if there is a match and if allowed sends that message to the client.
Each event has various properties associated with it. These are translated into AMQP 0-9-1 data encoding and inserted in the message headers. The message body is always blank.link
I use the python library paho-mqtt, and there are no headers on the on_message callback and the payload is of course blank. My question is how can I know which client/queue/exchange produce the event I receive?
If this plugin can't provide the feature that I want, is there any replacement solution exists? Such as a system topic, which can provide more details about concerned event.
Update:
Sorry for my confusing question.
Since I just want to get notification when a MQTT client changes online/offline status. Now I find the interface of MQTT Client "will_set" which meets my need.
I will remove the tag "rebbitmq".
You should be using an AMQP client like Pika. There's no need to use MQTT.
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.
I am using the mosquitto MQTT Broker.
Also, I have multiple (currently 10, but the number will increase) clients that publish some sensor data periodically to topic A. These clients are technically identical, but do have a unique identifier (serial number).
I also have a client that subscribes topic A in order to receive the published messages and persist the sensor valus in a database.
I certainly need to know which Sensor (i.e. client) has sent a particular value.
As a solution, one could just append some Sensor ID to the payload of each published message. But since the sensors access the broker via GSM, I need to keep the traffic low, so I am trying to avoid that.
I assume, the Broker itself knows which message comes from which client, especially when using perisistent connections, i.e. clean_session=False. Is that correct?
If yes, is there any chance that the subscribing clients can obtain the client_id when receiving the message?
Can it be configured in mosquitto? Or is it default behavior and I am missing something?
I am using paho-mqtt 1.3.1 for all clients.
No, the client id is not part of a published message. It is only used to identify the client to the broker when the connection is established in order to determine if stored messages and persistent subscriptions should be honoured.
The easiest solution is to use a separate topic for each sensor but with a shared root. e.g.
sensor 1 publishes to A/1
sensor 2 published to A/2
The client would then subscribe to A/+ this would then receive all the messages and can use the second half of the topic to determine which sensor it came from.
The other options is as you suggested which is to include the id in the payload.
Sending the client-id with payload(message) is possible. But you need to use delimiters in payload(message) at publisher side . Example: Publisher sends the payload as "client-ID=3 - temperature = 29 " . At the subscriber side , you remove the delimiters using strtok() .
There is no configuration available at broker side.
Per my experience with mosquitto, I don't think there is an option for mosquitto to change either the topic or the payload when re-publishing a received message.
However, I think it is just an implementation issue.
Theoretically, I think it is OK and good to support such kind of feature, since it does not violate MQTT specification at all.
(http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd02/mqtt-v3.1.1-csprd02.html#_Toc385349773, Section 3.3.2.1)
However, since the Server is permitted to override the Topic Name,
it might not be the same as the Topic Name in the original PUBLISH Packet.
The pratical solution for your current problem is, as pointed by #hardillb, either publishing using different topics but receiving using a topic with wildcard (+ or #), or, containing publisher information in payload.