I am running Mosquitto and nodered in the same raspberry, I send succesfully messages to a my MQTT Server and also have created an input node that connects succesfully. I am now trying to get, from the message received, the clientId info. Is there any way to get it?
Thanks
The MQTT protocol does not include any information about who published a message when it gets sent to a subscriber.
You would need to include this information in the topic string or payload the publisher sends.
Related
In my setup I have a mqtt.js client which publishes to a mosquitto broker (qos: 2). Now I have the problem that some messages are silently dropped by mosquitto because the client is unauthorized to publish to that specific topic. In this stackoverflow question it is said that it is not possible to recognize that as client because that would be a security issue. However it seems that mosquitto sends a "not-authorized" reason code in the PUBREC message. Wouldn't it be possible for the client to still get the info that it can not publish to that topic? What am I getting wrong?
You might be able to parse it out of the PUBREC packet yourself by registering an packetreceive callback
client.on('packetreceive', function(packet){
})
I read the MQTT-SN spec and I am unsure if it also can support the request-response pattern. Does anyone know ?
Trying to implement something like this...
http://www.steves-internet-guide.com/mqttv5-request-response/
Where the MQTT v5 publish command can specify the response-topic as seen in the MQTT v5 spec here:
https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
4.10.1 Basic Request Response (non-normative)
Request/Response interaction proceeds as follows:
An MQTT Client (the Requester) publishes a Request Message to a topic. A Request Message is an >Application Message with a Response Topic.
Another MQTT Client (the Responder) has subscribed to a Topic Filter which matches the Topic Name >used when the Request Message was published. As a result, it receives the Request Message. There could >be multiple Responders subscribed to this Topic Name or there could be none.
The Responder takes the appropriate action based on the Request Message, and then publishes a >Response Message to the Topic Name in the Response Topic property that was carried in the Request >Message.
In typical usage the Requester has subscribed to the Response Topic and thereby receives the >Response Message. However, some other Client might be subscribed to the Response Topic in which case the >Response Message will also be received and processed by that Client. As with the Request Message, the >topic on which the Response Message is sent could be subscribed to by multiple Clients, or by none.
The MQTT-SN spec is here
http://mqtt.org/new/wp-content/uploads/2009/06/MQTT-SN_spec_v1.2.pdf
It is just written differently and I cannot tell if this feature is supported.
Ultimately, for certain messages, I need to have a response which cannot be left to the pub/sub fire and forget pattern. MQTT-SN v1.2 is required for the connection since it goes over BLE and cannot support TCP/IP and so no regular MQTT v5.
I suppose I could just make up a "Response Topic" field to put into the payload of the request which the receiving client can process and respond to. But, does the MQTT-SN v1.2 spec already support it ?
No, MQTT-SN v1.2 does not include the features added to MQTT in v5.
As you said, there is nothing to stop you including your own response topic field in the message payload.
Im new in mqtt, i try to create something to authenticating publisher and subscriber only by their username password (so mqtt config for allowing anonymous is true). If both of them (publisher and subscriber) have the same username password, data form publisher will be sent to subscriber. By doing that, we didnt need to setting up new username password in our mqtt broker.
So, i need something that help me to get username and password of publisher and subscriber input.
Im working with linux and go languages. Help with these condition will be very helpful. Thanks
Mosquitto has an authentication plugin API which can be used to authenticate and authorise clients. You can use this to check username/passwords of users and also to store the ACL that controls which topics a user and publish/subscribe to.
That being said the normal MQTT authentication mechanism works by controlling access to topics. A given use can have read (subscriber) , write (publisher) or both access to a topic (or topic pattern).
This means that the ACL is applied at the time of subscription or publishing, not at the time of determining if a message should be passed to a specific client.
You can achieve what you want by prefixing any given topic with the username e.g.
user foo would always publish messages on foo/... and could subscribe to foo/#
The mosquitto ACL scheme has built in support for substituting the username into the topic pattern, so you can do things like:
pattern readwrite %u/#
I have a bot that I've built that's running on the Azure Bot Service with a Twilio Channel. I'm sending Proactive activities via my Twilio channel. Everything is working fine. I just got a request that a customer wants to have their own phone number. I would like to just have 1 bot service running but have multiple Twilio phone numbers go into this.
My thought was that I could setup an API service which would then be the incoming message call back / webhook from Twilio which then would use the Directline API to the Bot Framework. It would essentially just replace the https://sms.botframework.com/api/sms service. The problem is that I'm not sure I could still have the proactive messages working - it seems like the Directline 3.0 API works only when a conversation is started first with it.
Does anyone have any thoughts on this if this would work or have any other ideas?
Thanks
Yes, the approach which you mentioned above would be ideal. Each Web App Bot/Bot Channels Registration can only be associated with one Twilio number. I will elaborate on the steps which you mentioned above:
Create a server running the Twilio SMS API code which forwards the messages to the bot via the DirectLine API. The user sends a message to this server.
For every activity sent to the bot, make sure to include the number: Activity.ChannelData = new { fromNumber: <123-456-7890> }. The Server forwards the message to the bot.
You will need to re-attach the fromNumber to the bot's outgoing activity so that your Twilio API server knows where to send the outgoing message to. The Bot sends the reply to the server.
The Twilio API server sends Activity.Text to the user. The Server forwards message from bot to user.
For the proactive messages part, you can add a conversation property to the address param, and set the id to the user's phone number.
Example:
bot.beginDialog(
{
user: { id: '+1234567890' },
bot: { id: '+9876543210' },
conversation: { id: '+1234567890' },
channelId: 'sms',
serviceUrl: 'https://sms.botframework.com'
},
);
Hope this helps.
I am trying to build a local database storing Twilio SMS message events. There would be two tables: A Messages table with message info (To,From,Body,etc.), and a StatusRecords table containing status events (Status,ErrorCode,ErrorMessage, etc.). Both tables would be keyed on the MessageID.
I can get the MessageID and message info when I send a message (as a client) using the REST API in the returned response. That's fine.
I have a java servlet running that is called with status updates when Twilio updates the message delivery status. I then update the status in my database using the MessageID as the key. That's fine as well.
I have another servlet running that receives reply messages. I pick up the reply MessageID and add this to the database. This servlet also replies to the incomming message in the http GET response parameter using the TwilML API.
The problem is: How do I get the MessageID of the reply to the incomming message? The reply takes place as a result of a response to the http GET. I don't think I will hear from Twilio again after responding.
I assume that Twilio will update the status on the reply message as it is delivered or not delivered--and I will receive this update in my status update servlet. I could probably try to match the phone number of the status update to get the reply MessageID but this seems sort of crude.
Is there a more elegant way to do this?
Twilio evangelist here.
The <Message> verb takes an action parameter which lets you specify a URL for Twilio to request once it processes the Message noun. This request will include the Message SID.
If you wanted to associate the SID of the incoming message with the one sent by Twilio, you could pass the incoming message SID as part of the URL you set for the action parameter:
http://example.com/message?id=XXXXXXXXXX
Hope that helps.