Data forwarding

All data the Teleport devices read out from your assets and instructions sent to Teleport devices can be forwarded to a destination in your own cloud. We support destinations like databases (eg. MySQL, MSSQL and Postgres), message brokers (eg. Kafka, RabbitMQ and Redis) and HTTPS endpoints. We can also forward data directly to existing monitoring and control solutions.

Forwarding process

As soon as data from and instructions to Teleport devices are received by our cloud, our forwarders will deliver it to your destination service. If that fails, for example because your destination service is temporarily offline, the forwarder will keep retrying. The delay between attempts is set at 2 ^ min(attempt, 8) seconds. Delivery of all subsequent messages is also paused until the issue is resolved. Data that is still not delivered after 2 weeks will be deleted.

At least once delivery

Messages are guaranteed to be delivered at least once, so duplicates can occur. In database systems this is overcome with unique indexes, that avoid duplicates being inserted. For HTTP and AMQP, you should deduplicate yourself. For messages from devices the combination of teleportHashId, assetIdentifier and measuredAt should be unique.

Reporting interval

Teleports are configured to a default reporting interval of 300 seconds.

When the Teleport loses connection to the Teleport Cloud for an extended period of time, messages are stored locally. The Teleport stores up to 100 MiB of messages, which will be sent to the Teleport Cloud when the connection is resumed. As the volume of saved messages gets larger, the Teleport begins to filter the messages it saves, to maximize the amount of time spanned by the storage limit. This frequency is decreased according to the following table.

Storage Size Threshold	Reporting frequency	Estimated Time¹
Up to 84.0 MiB	per second (flash)	24 hours
Up to 99.0 MiB	per minute	11 days
Up to 99.8 MiB	per hour	34 days
Up to 100.0 MiB	per day	204 days

Number of connections

By default, we keep two connections open at all times:

one for real-time data
one for deferred (backfill) data

If your destination or credentials allow only one active connection, let us know. In that case, we can either use a single connection or use separate credentials for each queue (recommended).

Backfilling delayed data

Data can become delayed when a Teleport temporarily loses internet connectivity or when a forwarding destination is unavailable. When the issue is resolved, a significant number of messages may be forwarded at once. To prevent this backfill traffic from delaying real-time data, we process messages in two queues: real-time and deferred.

The default deferred threshold is 30 minutes. Messages older than 30 minutes are treated as deferred. In most cases, a 30-minute backlog is processed within a few seconds, so impact on real-time delivery is minimal.

Real-time queue: Message order is preserved. For example, a report from 11:59 is always delivered before a report from 12:00.
Deferred queue: Order is not guaranteed. Deferred messages include isDeferred: true.

To cater to different use cases we have the following options:

Custom threshold; the threshold can be adjusted.
Drop all deferred messages instead of forwarding them.
Drop only flash messages which are deferred.
Deliver deferred messages to a different destination (required in case only one active connection per client is allowed).
Disable deferred queue and only use one queue.

Sign convention

Teleport follows the IEC 61850-7-520 Producer Reference Frame (generator sign convention) for active power, reactive power, and current.

When an asset:

Injects active power (generation, battery discharge, or EV discharge), the sign of active power is positive.
Absorbs active power (usage, battery charge, or EV charge), the sign of active power is negative.
Injects reactive power, the sign of reactive power is positive.
Absorbs reactive power, the sign of reactive power is negative.

When:

Active power control is set to a positive value, the asset is directed to inject active power.
Active power control is set to a negative value, the asset is directed to absorb active power.
Reactive power control is set to a positive value, the asset is directed to inject reactive power (to increase voltage).
Reactive power control is set to a negative value, the asset is directed to absorb reactive power (to reduce voltage).

Teleport uses a specific convention for power factor where the sign correlates directly with the excitation state:

When the power factor is set to a positive value (overexcited), the asset is directed to inject reactive power.
When the power factor is set to a negative value (underexcited), the asset is directed to absorb reactive power.

Versioning

When we make changes to the structure of the data we forward, we try to do so in a backwards compatible way. For example, by adding new properties to any object in the JSON-message of JSON based destinations without increasing the version (message type). We also provide migration scripts to help you migrate from older versions to newer ones.

Policy on breaking changes

When we introduce a breaking change:

we will communicate the change to the email addresses registered for each impacted destination
the old version will be supported for at least 6 months after communication, unless all impacted parties have migrated to the new version earlier
a reminder will be sent to parties that did not migrate a few weeks before support for the old version will be removed

Integrations

Integrations allow you to directly connect data from the Teleport to your favourite monitoring and control solution. Currently we have integrations with the following solutions:

This is an estimate, based on a single asset with an average report size of 1 KiB. When you connect multiple assets to the Teleport, the estimated time is decreased accordingly. Likewise, some asset types provide larger reports, which also affects the amount of time the Teleport will continue storing data at a given reporting frequency. ↩