I am using MQTT on a SIM7500 LTE modem. I can connect to some mqtt broker after sending a bunch of AT and MQTT commands.
The thing I didn't expect to happen, is when I publish a topic from my modem, I loose the subscription I had open. Regardless of the topic name I subscribed to. After a publish from my modem, my modem no longer receives bytes when I publish on any subscribed topic on the broker.
I checked the documentation on the modem again, I can't find any reference to this behavior.
Anybody with knowledge on AT/CMQTT can explain if this is "expected behavior"? I can't imagine it's a bug in the modem. So either I am using things in the wrong way, or there is a reason for this.
A screenshot which shows the commands being sent/received:
In text:
startup commands left out for convenience (atz, ate0, at+cgatt=1, at+cgact=1,1)
MCU ==> Modem MCU <== Modem
AT+CMQTTCONNECT=0,"someipaddress:port,90,1
+CMQTTCONNECT: 0,0
AT+CMQTTSUBTOPIC=0,5,2
>
stm32
OK
AT+CMQTTSUB=0
OK
from this moment on, I have a live subscription, I published 2 messages on that topic which are received and passed through to my MCU
MCU ==> Modem MCU <== Modem
hello
hello
AT+CMQTTTOPIC=0,17
>
t/867584034403399
OK
AT+CMQTTPAYLOAD=0,5
>
hello
OK
from this point onwards, the subscription is lost. Whatever I publish on 'stm32', it no longer is received on my uart connected to my modem.
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.
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.
How to know the remote device is online using mqtt (as a device simulator I am using MQTTfx). After publishing to a topic I am not getting any acknowledgement message and in the callbacks I am getting the same payload data that is published.
You can not find out is another MQTT client is online at a protocol level, in fact at a Pub/Sub pattern level a publishing client should not care is 0 or an infinite number of other clients are subscribed to the topic that message is published on.
The callbacks are only an indication that the message has been successfully delivered to the broker not to any of the subscribers. There is no end to end delivery notification (because there may be no subscribers to a given topic).
If you need to know the status of devices then you need to implement this yourself, the usual pattern is to use a status topic with a retained message and the LWT to clear this if the client crashes and setting it manually when it starts up or shuts down cleanly.
I've bought a Wireless IBeacon Receiver BLE 4.0 WI-FI Sniffer here installed Node Red on my Synology DS414j. I've been able to configure the sniffer to use my local WLAN and I can access the webpages on the sniffer. So far so good.
Now I'm trying to connect MQTT node from Node Red to the device. Maybe I'm not understanding thing correctly but I would have expected this to work.
There is a Wiki here but that does not contain a lot of information. I tried signing on the forum but the confirmation mails never arrives.
Configuration of the sniffer:
I've added my SSID, security token for my WLAN. That works.
Device mode is configured to 'Station'
MQTT is configured to the IP of the NAS port 1883. With credentials. Topic is set to '/beacons'.
Node Red node is configured to IP of device port 1883, with credentials.
Questions:
Does it work the way I think this should work. Is it possible to have the MQTT Node Red node to connect to the device or do I need something else?
The sniffer can be put into 3 modes. Station, P2P and Access Point. I've now configured it at Station. Does anyone know what this setting means?
Node Red says 'connecting' but never connects. I've also installed a MQTT Dashboard on my Samsung Phone. It says 'connection failed'. What am I doing wrong? Do I need SSL/TLS? to be activated?
By the sound of things you have not installed a MQTT broker.
MQTT is not Point to Point you need a broker that the clients all connect to.
Node-RED does NOT contain a MQTT broker (there is node to add one, but it's not really the best approach), it is just another MQTT client.
I want to subscribe a topic from my mqtt broker using a GSM Modem. I am new to GSM modem, Please guide me to implement this.
Based on my under standing, I need to follow these steps.
Prepare modem using Basic AT commands
Start TCP connection to MQTT broker using ATcommands ( Say: AT+ CIPSTART="TCP","MQTT BROKER","MQTT PORT"
Send Subscribe message to MQTT broker ( AT + CIPSEND and remaining steps )
Then In a loop continuously read serial buffer data. If connection closed reconnect.
Please confirm my understandings are correct.