Skip to content

Update API spec about Mqtt usage #114

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 12 additions & 1 deletion gateway_to_backend/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -157,6 +157,11 @@ Depending on the quality of the connection between gateway and Backends,
it can create duplicates that will have to be filtered by the backends.
To ease this filtering, each event contains a unique identifier (random
64 bits value) in its header.
However, some broker are not 100% MQTT compliant and do not support some
of the QoS values. So nothing is enforced for the QoS values. Even if it is
recommended to use QoS2 in some places (like with downlink traffic) the broker
may limit this usage.


### Gateway status module

Expand All @@ -173,12 +178,18 @@ backends. It also allows the backends to monitor the gateways status.
> **content:**
> [GenericMessage][message_GenericMessage].[WirepasMessage][message_WirepasMessage].[StatusEvent][message_StatusEvent]

The message must have the retained flag set to true to allow a new
The message must have the retain flag set to true to allow a new
backend to immediately be noticed of all the available gateways when
subscribing to this topic.

Once connected to the MQTT broker, status must be set to *ONLINE*.

As some broker do not support the retain flag, sending periodically the status
of the gateway can be implemented instead of only once with the retained flag.
Consequently, backends will have to wait for a period time after the subscribing to
this topic before being noticed of all gateway status.
A period of 30s is a good tradeoff between loading the broker and reactivity for backends.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

30 seconds period might be too dense if backend needs to handle thousands of gateways. Maybe 30s - 5min would be better range. This should be configurable value.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why can we have it as:

  • backends will pull it when needed
  • GW will publish it on change

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would change the API, not just the implementation


#### Last will message

Same message with a status set to *OFFLINE* must be set by the gateway as
Expand Down