MQTT protocol works on pub-sub concept. Client can subscribe and publish topic to the Broker. Clients who are sensor kind of thing can publish respective topics (temperature, humidity, switch on/off request etc) to Broker. Broker will send the respective data to the subscribed clients (display device, any device which can on and off).
Broker usually hosted on open internet.
I'm not getting the point how Broker will send the information to client device as the wifi connected device usually couldn't be reachable from open Internet as there will be no public IP assigned to such IoT devices. (I mean to say IP communication from Open internet to IoT device should not be successful)
The connection to the broker is established from the client to the broker, as this is an outbound connection as far as any home router/NAT device is concerned it will work just fine (in the same way a web browser would open a connection to a HTTP server).
The connection is also persistent, meaning the client opens it and keeps it open for the lifetime of the client. This means that the broker always has an open connection to forward messages to the client.
At no point does the broker try to connect to the client.
Related
I have two machines and am testing MQTT bridge connections with Sparkplug B payloads.
I have the bridges working as expected but when I simulate some failure points as annotated in the image below, things are not working as expected. My expectation is an NDEATH will be visible on the broker on Machine B when any of the three points in the image disconnect.
When I kill the publisher or the local MQTT Broker on Machine A, I do indeed see the NDEATH as expected when subscribed to the Machine B MQTT Broker, but when I pull the plug between Machine A & B as noted by #3 in the image, I do not see a NDEATH! I have waited for a long period to make sure the 60 second keep alive has had plenty of time to react which I understand to be 1.5x the keep alive typically.
The publisher and Broker on Machine A continue to operate and when the connection at point #3 is brought back online, all messages are delivered, but I was expecting with the bridge connection down, any nodes that had published a last will & testament (LWT) would see an NDEATH due to the connection loss at any point.
I have tested with mosquitto, vernemq and a little with hive-ce, however hive-ce is severely limited in functionality. Am I missing something with my understanding of MQTT bridging? Shouldn't NDEATH be sent in all three scenarios?
From the sparkplug spec:
A critical aspect for MQTT in a real-time SCADA/IIoT application is making sure that the primary MQTT SCADA/IIoT
Host Node can know the “STATE” of any EoN node in the infrastructure within the MQTT Keep Alive period (refer
to section 3.1.2.10 in the MQTT Specification). To implement the state a known Will Topic and Will Message is
defined and specified. The Will Topic and Will Message registered in the MQTT CONNECT session establishment,
collectively make up what we are calling the Death Certificate. Note that the delivery of the Death Certificate
upon any MQTT client going offline unexpectedly is part of the MQTT protocol specification, not part of this
Sparkplug™ specification (refer to section 3.1 CONNECT in the MQTT Specification for further details on how an
MQTT Session is established and maintained).
So, in MQTT terms, NDEATH is a 'Will' which, as mentioned above, is defined in section 3.1 of the the MQTT spec:
If the Will Flag is set to 1 this indicates that, if the Connect request is accepted, a Will Message MUST be stored on the Server and associated with the Network Connection. The Will Message MUST be published when the Network Connection is subsequently closed unless the Will Message has been deleted by the Server on receipt of a DISCONNECT Packet
In summary NDEATH creates a 'Will' which the MQTT broker publishes if it looses the connection with the publisher (unless a DISCONNECT is received first).
When you establish a bridge this relays messages published on whatever topic(s) the bridge is configured to relay. The bridge only communicates published messages; not information about what clients are connected (or any 'Will' they may have set) so when the bridged connection goes down subscribers will not receive the NDEATH.
Monitoring the connection status of bridges is not something covered by the spec so options vary from broker to broker. For example Mosquitto can (using a 'Will' on the bridge connection) provide a notification when the connection goes down (see notifications in mosquitto.conf). This may provide you with some options to get the information you need.
I was under the impression that in NB IoT world, if the client device enters PSM mode, it can actually retain both the IOT network registration and also the TCP IP connection session. so when it wake up from PSM, it can quickly send data and go back to sleep again. but in my case, it imitates disconnection of the PDP session before it enter PSM. Is this normal ??
Currently I am using a dev client system based on Qualcomm 9205 modem connect to LTE Cat-M1 network.
the client will wake up every 10min to send a small chunk of data (100byte) to the AWS IOT service, it uses MQTT as the messaging protocol .
ideally I prefer the device to initiate the MQTT connection with the server once, then after it goes to PSM sleep, the client side remembers the MQTT connection, so when it wake up, it can just send the data via MQTT without re-establish the MQTT connection again.
Unfortunately, I realise the real behaviour is: when I ask the modem to go to PSM sleep, it will drop the PDP connection (which means the TCP/IP session is lost, so does MQTT ), so when it wake up, it will take extra 5-10 seconds also to re-establish MQTT connection again before sending data. this is a waste of both time and additional data communication.
Any suggestions?
I have "server side" mqtt client which I use to monitor and manage remote mqtt clients. I would like to extend this server module to keep tabs on the connectivity of the remote clients.
During normal operation, the remote clients regularly PING the broker, as per the broker logs:
1532924170: Received PINGREQ from c51
1532924170: Sending PINGRESP to c51
and when a disconnection occurs, the broker logs show this too:
1532924976: Client c51 has exceeded timeout, disconnecting.
1532924976: Socket error on client c51, disconnecting.
as well as the subsequent re-connection:
1532924978: New client connected from X.X.X.X as c51 (c1, k30).
1532924978: Sending CONNACK to c51 (0, 0)
I would like to monitor these 3 events from the mqtt-client held by the server module. Is this possible? If not, what alternative approach to "health" monitoring can you recommend?
No, you can not read these from a connected client.
The only pure MQTT approach is to make use of the Last Will and Testament (LWT) feature. You have the client set up a LWT publish a retained message to a client specific topic that marks it as offline. Then as the client connects it should publish a retained message to show you are online. If you disconnect cleanly (not triggered by keep alive time out you should manually publish the LWT message as the last thing before disconnecting).
It's also worth pointing out that ping messages only get sent if no other messages have been sent between the client and the broker in the keep alive period.
According to MQTT Protocol 3.1.1, "A Client can only send the CONNECT Packet once over a Network Connection. The Server MUST process a second CONNECT Packet sent from a Client as a protocol violation and disconnect the Client". But it confuses me that the server MUST disconnect the previous one or the new one?
I tested it with MQTT, and I used two sessions to subsribe the same topic with the same Client ID. Does it mean that the same client sends CONNECT twice? If it's true, it really confuses me.
The new subscriber'll cause the server disconnect the old one. It's diffirent with the protocol. When they old one disconnected, it'll try to send CONNECT and wait CONNACT packet. Then it turns to the new Client, and the server disconnects the previous new subscriber.....
So what does the protocol mean? The Server MUST process a second CONNECT Packet sent from a Client as a protocol violation and disconnect the old Client or the new Client?
You are confusing 2 separate events here.
Firstly if a single client sends 2 connect packets on the same network connection then the broker will disconnect that client.
The second instance you mention is 2 clients with the same client id. This will be 2 separate network connections even if from the same host. Each of these clients will send a single connect packet but because there will be a client id clash the first of the clients to send the packet will be disconnect when the second arrives
I am new to MQTT protocol. I tested the MQTT broker which facilitates the publishing from my android phone and subscription of my IOT actuators(Motors). But I am confused, as how to enable actuators to work only from a particular publisher. In otherwords, I want to control my MotorA from my PhoneA and MotorB from PhoneB and so on... I don't know how to get started outside the localhost(LAN) to make my broker work with the help of internet.
I am using Mosquitto broker and ESP8266 as client. Please share your views on how to get started with Mosquitto broker hosted on internet.
Hosted MQTT (e.g. https://www.cloudmqtt.com/) is no different than your local Mosquitto broker except that's in the cloud.
As for how to route publishers you can do that either based on an attribute of the published message e.g. something like motorId or you can publish to different queues. Hence, phone A could publish to queue motor-a and phone B could publish to queue motor-b. The application on the ESP8266 would subscribe to both and act accordingly.