MQTT Arduino Limits: Difference between revisions
No edit summary |
No edit summary |
||
| Line 13: | Line 13: | ||
==QoS 1 "At Least Once"== | ==QoS 1 "At Least Once"== | ||
The next mode provides a confirmation whether the message was received (QoS = 1). If the sender gets a confirmation it knows the message has been received. If it doesn't get a confirmation it does not know whether the confirmation got lost or the message was not received. In this case it probably sends the message again. Which may result in sending the same message twice (namely, when the message has been received the first time but the confirmation was lost). In case of ie. reporting the status of a light bulb (on/ off) would not hurt. | The next mode provides a confirmation whether the message was received (QoS = 1). If the sender gets a confirmation it knows the message has been received. If it doesn't get a confirmation it does not know whether the confirmation got lost or the message was not received. In this case it probably sends the message again. Which may result in sending the same message twice (namely, when the message has been received the first time but the confirmation was lost). In case of ie. reporting the status of a light bulb (on/ off) multiple reports probably would not hurt. | ||
This mode already requires keeping track of messages sent and responses received. "Keeping track" means using memory and code, and the Arduino has not much of both. It is possible to keep things simple by sending | This mode already requires keeping track of messages sent and responses received. "Keeping track" means using memory and code, and the Arduino has not much of both. In theory a number of messages could be sent out while confirmations trickle in, possibly out of order and not waiting for confirmation before sending out the next message. It is possible, though, to keep things simple by sending one message and waiting for confirmation before sending the next message. That said, yes, Arduino can support QoS 1 as well, within limits. | ||
==QoS 2 "Once and Only Once"== | ==QoS 2 "Once and Only Once"== | ||
The most advanced mode makes sure a confirmation is provided AND the message is sent at most once (QoS = 2). This now really requires keeping track of the conversational state. While is not | The most advanced mode makes sure a confirmation is provided AND the message is sent at most once (QoS = 2). This now really requires keeping track of the conversational state on both ends of the exchange. While it is not technically impossible for an Arduino to do this there just won't be much memory left for the application code. I would recommend to not insist on QoS 2 but to design the application in a way that the reception of duplicate messages won't do harm at the receiving end. | ||
to do this | |||
To be done: Is this mode tricky for the device or the broker or both? | |||
[[MQTT]] | [[MQTT]] | ||
Latest revision as of 14:01, 13 June 2018
MQTT-Limits of the Arduino Environment
MQTT supports three different modes of communication (Quality of Service or QoS). These modes put different demands on code and variable memory. As both types of memory are very limited in the Arduino environment: What is desirable? What can be done? Where are the limits?
QoS 0 "Fire and Forget"
The most simple mode is "fire and forget" (QoS = 0). The sender (a device or the broker) sends out a message and this is it. The sender won't ever know whether the message reached its target or not.
This mode is a nobrainer and does not require to memorize anything about the conversation.
QoS 1 "At Least Once"
The next mode provides a confirmation whether the message was received (QoS = 1). If the sender gets a confirmation it knows the message has been received. If it doesn't get a confirmation it does not know whether the confirmation got lost or the message was not received. In this case it probably sends the message again. Which may result in sending the same message twice (namely, when the message has been received the first time but the confirmation was lost). In case of ie. reporting the status of a light bulb (on/ off) multiple reports probably would not hurt.
This mode already requires keeping track of messages sent and responses received. "Keeping track" means using memory and code, and the Arduino has not much of both. In theory a number of messages could be sent out while confirmations trickle in, possibly out of order and not waiting for confirmation before sending out the next message. It is possible, though, to keep things simple by sending one message and waiting for confirmation before sending the next message. That said, yes, Arduino can support QoS 1 as well, within limits.
QoS 2 "Once and Only Once"
The most advanced mode makes sure a confirmation is provided AND the message is sent at most once (QoS = 2). This now really requires keeping track of the conversational state on both ends of the exchange. While it is not technically impossible for an Arduino to do this there just won't be much memory left for the application code. I would recommend to not insist on QoS 2 but to design the application in a way that the reception of duplicate messages won't do harm at the receiving end.
To be done: Is this mode tricky for the device or the broker or both?