Frequently Asked Questions

See below for answers to our most frequently asked questions. Have other questions? Contact us to learn more!

Jetstream is a cloud based RFID data broker. It is built on the idea that global RFID implementations should be simple.
Example uses for Jetstream are remote RFID systems, mobile RFID systems and local RFID implementations. Jetstream allows you to combine not only your internal RFID data but the RFID data that is generated outside the four walls of your business.
Using Jetstream, your application does not have to worry about RFID device drivers, remote device communication, device management and normalizing of RFID events. Instead of focusing on the infrastructure of dealing with RFID and remote RFID devices Jetstream allows you to focus on writing your application to a single point in the cloud.
Jetstream works by exposing all device commands and application configuration functionality through a REST based web service API. Applications then receive their events using Get Events.
While Terso Solutions supports the EPC Global standards, they were written for local RFID implementations. The complexity of bringing multiple global RFID implementations to the cloud created the need for a proprietary API. We have tried to maintain as much vocabulary as possible from the EPC standards to allow for an easier transition from EPC to our proprietary API.
Most frameworks and standards for RFID are built with the requirement that you are not only deploying the RFID devices to a LAN but that you have 100% control of the LAN. Jetstream was built from the ground up for building remote RFID applications. Also, by requiring that all devices be Terso certified intelligent devices, the deployment of new remote locations doesn't require expensive RFID appliances, networking equipment and IT personnel.

Device commands are commands that will execute on a device physically located at a remote location. When an application sends a REST command request to Jetstream the device status is evaluated. If the device is online, the command is executed immediately. If the device is offline, it is queued for the device to execute. Once the device has executed the command a CommandCompletionEvent is published with any results of executing the command.

Not all device commands support immediate execution. Not all device commands may be queued for future execution. Not all device commands will return results immediately.

To support the ability to install a device on a network that is not controlled by your company all devices use internet friendly protocols and initiate all communication with Jetstream. Therefore Jetstream may not have the ability to directly contact the device and queues all device commands until the next time the device polls the command queue.

Some commands are only eligible to execute immediately. In the event that a command is ineligible for offline execution, an attempt to execute the command will result in a failure.

Jetstream will return a 401 HTTP status code and an error message indicating that the device does not support the command.
The exceptions will contain details on any issues that occured while attempting to complete a command.
The device has two hours to dequeue the command from Jetstream. If after four hours the command is still in the queue Jetstream will dequeue the command and publish a CommandCompletionEvent with an Exception indicating that the timeout to dequeue the command has passed.
A DeviceDefinition is a data structure defined by the composite key of a device's manufacturer, name and firmware version. It is used by Jetstream to determine the supported parameters, behavior and connection type.
To replace a physical device, your application will call Delete a Device for the existing device. Then you will need to call Create a Device for the new device.
Jetstream is built on top of industry-proven cloud computing environments. Therefore Jetstream has redundancy across multiple data centers and servers. Every logical component of Jetstream is able to run autonomous if a failure occurs in another component. Finally the Terso intelligent device certification requires that a device is able to store up to two weeks of data in case of a failure.
Yes, Jetstream makes no attempt to reorder out of order messages received from devices. Devices are required to store and forward events in a FIFO queue (the order in which they occurred).
Jetstream is able to support up to 20,000 intelligent devices per application. This roughly equates to ~25MB to ~50MB of event data per day, per device.
Jetstream is able to support up to 50 API calls per minute, per application. If your application has more extreme needs than this please contact us and we will work with you on a solution.
While Jetstream can queue up to 50 commands per minute, per application, each device will have a different execution commands based on its hardware. Most RFID devices on the market today are heavily resource constrained. Queuing more than a few messages will cause the devices to slow down. As a rule of thumb, your application should not queue up more than 3 commands per device at one time.
When your device has established an active connection to Jetstream via WebSockets, the device is said to be "online". When the device is online, eligible commands are delivered directly to the device. This allows for near real-time interaction with your device. In these instances, devices execute commands and reply in seconds (depending on the command). Sometimes communication channels can close though. In these instances the device is said to be "offline". When the device is offline, any issued commands are queued up until such time that the device comes online again. When the device re-establishes communications, any queued commands for the device are delivered and executed.

Some commands take a long time to execute. To maintain the responsive nature of Jetstream not all commands will return results immediately.

For example, the Get All RFID Tags may take more than a minute before the data is returned. In this case, the command will be executed, but the results will not be returned to the caller; they will be published to Get Events as if the device were offline.

Immediate results are returned to the calling system immediately. In these circumstances, the calling system will receive a CommandResponse as well as a CommandCompletionEvent.

Published results are published to Get Events for retrieval. In these circumstances, the calling system will receive a CommandResponse but the results will only be made available in the CommandCompletionEvent which (along with the CommandQueuedEvent) can be retrieved via Get Events.

Immediate and published results are returned to the calling system immediately as well as being published to Get Events for retrieval. In these circumstances, the calling system will receive a CommandResponse as well as a CommandCompletionEvent. Additionally, the CommandQueuedEvent and CommandCompletionEvent will be available in Get Events.

Events can be retrieved via the Get Events Jetstream API request for 14 days. After this period, events are deleted and are no longer retrievable. Once events are retrieved, it is recommended that they be deleted via Delete Events – this will help in sorting through what events have and haven’t been retrieved. Events that have been retrieved and not deleted via Delete Events, however, will be automatically deleted and no longer retrievable after 4 days.
Devices should be created in the Jetstream region that most closely reflects their geographic location. This enhances performance by reducing latency between the device and Jetstream.