We recently announced the general availability of Golioth Location, a comprehensive device positioning service. Less than two weeks later, we have expanded the service to support gateway-based positioning, making it possible to obtain the location of devices that do not have GNSS, cellular, or Wi-Fi capabilities. This is accomplished by resolving the location of an indirectly connected device by the known location of the gateway that delivered data to Golioth on its behalf.
Gateways and Devices
We previously defined the distinction between devices and gateways in The Taxonomy of Connected Device Networks. Gateways deliver data to Golioth, typically over cellular, Wi-Fi, or Ethernet, on behalf of other devices. This is enabled by pouch
, a custom protocol we developed that enables devices that can’t communicate directly with cloud services to deliver data via an intermediary (i.e. gateway). One of the most common use cases is Bluetooth Low Energy (BLE) devices, which can deliver encrypted “pouches” to a gateway, such as a mobile application on a user’s smartphone or an embedded Linux-based single-board computer (SBC), which can then be forwarded along to Golioth over Wi-Fi or cellular. Golioth customers in our Bluetooth-to-Cloud private access program are using this functionality today.
Gateways can leverage Golioth Location’s network-based positioning to resolve their location from scanned Wi-Fi access points or nearby cell towers, or, if they are equipped with GNSS capabilities, can obtain their own position and deliver it to Golioth Location for tracking. Because edge devices must be in relatively close proximity to a gateway in order to communicate through it, Golioth Location is able to approximate the location of the device over time based on the gateways that deliver data on its behalf, regardless of how the gateway obtained its own location.
Making Use of Pipelines
The same location
transformer that is used for network-based positioning in Pipelines can also be used for gateway-based positioning. If network information is provided in the message payload, it will first attempt to resolve using network-based positioning. If it is unsuccessful, or no network information is provided, the transformer will fallback to gateway-based positioning if the message was delivered via a gateway. If the position of the gateway is known, it will be returned as the position of the device.
For example, in the following Pipeline, an empty message sent from a device on the /.s/loc
path and delivered via a gateway could be routed to the location
transformer. The information about the gateway will be automatically passed from the Pipeline context to the transformer. Because no network information is provided, the transformer will look up the location of the gateway, and if known, will return it such that it can be passed along to the location
and lightdb-stream
destinations.
filter: path: "/loc" steps: - name: resolve-position transformer: type: location version: v1 - name: store-location destination: type: location version: v1 - name: stream-location destination: type: lightdb-stream version: v1
Because multiple Pipelines can process the same data, location resolution can be triggered as a side-effect to streaming any data, such as sensor readings or other application data. The content of the message will be discarded by the location
transformer if it does not contain network information. This effectively enables location tracking with zero-byte overhead, just by knowing what gateway a device communicated through.
Getting Started
Gateway-based positioning is available to all users in Pipelines today, but in order to start using gateways you must enroll in the Bluetooth-to-Cloud private access program. After doing so, you’ll be able to start tracking the location of your BLE devices without changing a single line of firmware. If you have any questions or feedback, feel free to reach out to us on the forum!
No comments yet! Start the discussion at forum.golioth.io