It is very common in connected product deployments to have edge devices communicating over a local network (via BTLE, NFC, Zigbee, 6loWPAN, Ant+, Dash7, etc). Low-power gateway technologies use simple, efficient radio communication to pass their information to other, higher-powered bases that will handle the communication with the internet.
In some cases, the gateway device for a product is a user's bluetooth-enabled phone; while more commonly, edge devices will communicate with an ethernet-connected base station which will facilitate their communication to the web.
Best practices in this area are as follows:
- It is often advantageous to model each end device in Xively so that their unique metadata and messages can be stored and tracked. Set up each edge device as a
devicein Xively using a template that describes them. For example, a Light Bulb device template could be defined which has custom fields to store its on/off state, install date, and model number; and channels for on/off, diagnostic logs ( more on logs here ), and saturation.
- Then, model each gateway device as a different device template. For example, a Hub device template could be defined with custom fields for model number and web connection style (if the hubs come with ethernet/wifi/3g adaptors, for example).
- To manage permissions properly, group the edge devices and the gateway device together in a group (organization). Because devices in the same group are authorized to PUB and SUB to each other's channels, the gateway device can handle local communication with the edge devices (more on this below), and then represent their states and messages by publishing, subscribing, and updating their custom fields on Xively on their behalf. This lets other entities that are only interested in particular devices see only the information relevant to them.
Locally networked devices come with a variety of considerations:
- At the protocol level, whether industrial protocols (e.g. BACnet for HVAC systems) are going to be used by gateways to control older equipment that requires a gateway to translate.
- At the application layer, whether the edge devices might wish to communicate over MQTT themselves, or CoAP, or HTTP to the gateway. Also, whether they might wish to broadcast their capabilities via the emerging standard of Weave. Devices that use MQTT at the edge can take advantage of the Xively Client's ability to operate as a local MQTT broker.
- At the networking level, what flavour of Personal Area Networks might be used. These can include those based on 802.15.4 like ZigBee and the 6LoWPAN-based Thread; Bluetooth; Near-field communication (NFC) devices and more.
These considerations guide your choice for how to translate edge device communication into the structure you want to send to Xively.