An introduction to integrating MQTT with DASH7. Deploying MQTT over DASH7 is not too difficult and we show examples for getting started.

1. DASH7 with MQTT
[Application Note]

2. DASH7istheOppositeofTCP
DASH7’s networking technology is different than TCP/IP.
DASH7 is designed to handle small data, but lots of devices at the same time.
TCP/IP handles large data, but only between two devices.
2

3. MQTT Handles Connections “One at a Time”
3
• Client connects to MQTT server
(called a “Broker”)
• Client subscribes to some MQTT
“Topics” (these are like feeds).
• When Broker is supplied new
data on a given Topic, it forwards
to all subscribers, one at a time.
Broker
Unsubscribed
Client(s) Subscribed
Client(s)
1. Client publishes on
topic “X” to broker
1
2
3
4
2, 3, 4. Broker forwards Pub (1)
to all clients subscribed to “X”,
… one at a time.

4. DASH7 Handles Connections in Groups
4
• DASH7 devices can do peer-to-
peer, multicast publishing
without a broker.
• QoS is dictated by the manner in
which devices acknowledge
(ACK) the Publisher.
• It’s a lot like peer-to-peer MQTT.
1. Multicast
Publish
2, 3, 4. Synchronized ACKs
2
3
4

5. DASH7 is Like Peer-to-Peer MQTT on a LAN
5
Broker
Unsubscribed
Client(s) Subscribed
Client(s)
1. Client publishes on
topic “X” to broker
1
2
3
4
2, 3, 4. Broker forwards Pub (1)
to all clients subscribed to “X”,
… one at a time.
1. Multicast
Publish
2, 3, 4. Synchronized ACKs
2
3
4

6. A Proxy Can Integrate it with Cloud MQTT
6
Broker
Unsubscribed
Client(s) Subscribed
Client(s)
1. Client publishes on
topic “X” to broker
1
2
3
4
2, 3, 4. Broker forwards Pub (1)
to all clients subscribed to “X”,
… one at a time.
DASH7 WAN/LAN
Prox
• A DASH7-MQTT Proxy can be just an MQTT Client
that has a second interface on a DASH7 WAN or LAN.
• It forwards pub and sub messages.
• Additional sophistication can make it more efficient,
although Topic naming best practices makes a big
improvement with minimal sophistication.

7. Topic Naming Best Practices
7
Keep topic names below 16 chars.
‣ e.g. topic/this_is_too_long
‣ e.g. topic/titl — (ok)
DASH7 devices have limited communication
bandwidth and memory. Queries work fastest on
strings 16 characters or less.
Use Path separators to define hierarchies
based on data latency requirements.
‣ e.g. rt/temp
‣ e.g. noncrit/temp
Here, we have real-time and “non-critical” groups of
temperature sensors. This structure allows the
proxy to be more intelligent.
Wildcards are cool.
‣ e.g. rt/#
‣ e.g. #/temp — (not advisable for std MQTT)
DASH7 querying supports wildcards and other
search features. The second topic will bog down a
normal MQTT network, but a DASH7-MQTT proxy
can actually handle it without much drama.
The “ID/“ topic can be used for addressing
‣ e.g. ID/# — (broadcast)
‣ e.g. ID/0790 — (16bit LAN address)
‣ e.g. ID/DA5701A976B31F54 — (MAC)
This is a way to tunnel direct device addressing
through an MQTT proxy. (And yes, wildcards can
be used with partial addressing)