Transcript
Page 1: More on Using Haystack + DASH7 with MQTT

More DASH7 with MQTT

Patrick Burns [email protected]

Page 2: More on Using Haystack + DASH7 with MQTT

DA

SH7 is the O

pposite of TCPDASH7’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

Page 3: More on Using Haystack + DASH7 with MQTT

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

UnsubscribedClient(s) Subscribed

Client(s)

1. Client publishes ontopic “X” to broker

1

23

4

2, 3, 4. Broker forwards Pub (1)to all clients subscribed to “X”,

… one at a time.

Page 4: More on Using Haystack + DASH7 with MQTT

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

Page 5: More on Using Haystack + DASH7 with MQTT

DASH7 is Like Peer-to-Peer MQTT on a LAN

5

Broker

UnsubscribedClient(s) Subscribed

Client(s)

1. Client publishes ontopic “X” to broker

1

23

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

Page 6: More on Using Haystack + DASH7 with MQTT

A Proxy Can Integrate it with Cloud MQTT

6

Broker

UnsubscribedClient(s) Subscribed

Client(s)

1. Client publishes ontopic “X” to broker

1

23

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.

Page 7: More on Using Haystack + DASH7 with MQTT

DASH7+MQTT 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 problems.

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)

Page 8: More on Using Haystack + DASH7 with MQTT

Example of MQTT-Tunneled DASH7 Query

8

1. Define topic that will address all the endpoints you want to query. This example looks for devices containing real-time temperature data. (note: we can set topics any way we want when we write the system specification).

2. Put a MQTT response params in the payload, with JSON or CBOR. The endpoints will publish-back their data on this topic & QoS.

3. Endpoints with rt/temp data available will publish it back. Data format is CBOR.

rt/temp

{ “topic”:”hub/rt/temp”, “qos”:1 }

CBOR examples:http://cbor.io/tools.html

Page 9: More on Using Haystack + DASH7 with MQTT

UDP Data Exchange Within MQTT

9

• DASH7 can Publish (and receive) data over MQTT in a variety of formats. ‣ ALP/NDEF

‣ CBOR

‣ Proprietary Application data

• In all cases, data is binary format. • ALP is the normal way to frame data. ‣ An ALP frame is shown to the right

‣ More info on specifics: http://www.indigresso.com/wiki/doku.php?id=opentag:alpapi

ALP frames are very simple: ‣ Flags (for message fragmentation) ‣ Payload Length (size of data in bytes) ‣ ALP-ID (maps to a UDP destination port) ‣ ALP-CMD (application dependent usage) ‣ Payload is UDP application data

DASH7 supports UDP applications as well as some UDP-like applications optimized for DASH7.

DASH7-optimized UDP protocols use ALP-CMD to define protocol functions. Native UDP protocols use ALP-CMD as the UDP source port number.

Page 10: More on Using Haystack + DASH7 with MQTT

UDP Data Exchange Within MQTT

10

• Some common UDP Apps ‣ Trivial File Transfer Protocol (TFTP)

‣ Network Time Protocol (NTP)

‣ Lightweight Directory Services Protocol (LDAP)

‣ Constrained Application Protocol (CoAP)

‣ MQTT itself also can work on UDP

• UDP Apps Unique to DASH7 ‣ Mode 2 Batch File Protocol

Point-to-Point and Point-to-Multipoint protocol for reading, writing, or querying data from the filesystem. (similar to cat & < / > operators in UNIX)

‣ Confit (i.e. “Configure It”)Point-to-Point and Point-to-Multipoint protocol for transferring bulk updates, such as Firmware Updates. Almost identical to TFTP, except it works at very low power on the device endpoint.

• All of these applications can be tunneled over MQTT, to DASH7! • You can use MQTT topics to achieve multicast addressing! • There is a file on the device for storing dynamic CBOR CDDL!


Top Related