more on using haystack + dash7 with mqtt
Embed Size (px)
TRANSCRIPT
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
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.
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
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
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.
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)
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
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.
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!