Deep Hub 2021 R1, 1.2.1

  1. Corrected mismatch to spec: “provider_id must be null in case the event was triggered by a Trackable”

  2. Fix return code handling for consumption reporting

Deep Hub 2021 R1, 1.2.0

  1. Added filter and transform functionality to WebSocket subscriptions. Please refer to the WebSocket API documentation.

  2. Internal changes and improvements related to event processing.

  3. Added consumption and usage statistic API.

Deep Hub 2021 R1, 1.1.9

  1. Log IP address in HTTP and WebSocket handlers on error.

  2. Added /health API for health checking

  3. Added a new special role named guest. This role allows to bypass authorization when assigned to endpoint in the permissions settings (e.g., for the /health endpoint).

Deep Hub 2021 R1, 1.1.8

  1. Updated Zone and Fence API to include exit delay.

  2. Fixed TrackableMotion does contain a point geometry instead of a polygon in case the Trackable does not define a radius.

  3. Reject erroneous Trackable configurations with duplicate provider ID references.

  4. Added trackable_motions:geojson topic to subscribe to geojson encoded motion updates.

  5. Updated WebSocket session idle timeout configuration.


  1. Fixed an issue caused by an external library where the docker container might get into a startup loop.

  2. Fixed an issue where trackable motions did not get certain values assigned from the related trackable.


  1. IMPORTANT CHANGE: The /v1/zones API was adapted to the latest version of the omlox™ specification. Most importantly, proximity based positioning systems (RFID or iBeacon) require the position to be defined when creating a zone, while ground control points must not be set. The position was previously optional, which allowed to create invalid proximity zones. For other types of RTLS systems ground control points are still required, and the position is still optional.

  2. IMPORTANT CHANGE: The property collision_tolerance in the Trackable object has been renamed to exit_tolerance in the latest version of the specification, aligning property names between omlox™ Fences and omlox™ Trackables. This implementation of the Hub has been updated accordingly and may require to adapt the name of this property for client requests.

  3. Added REST endpoints for handling omlox™ proximity events at /v1/providers/proximities and /v1/providers/$providerId/proximity. Proximity events allow easier integrations of proximity based positioning systems (e.g. RFID or iBeacon). A proximity positioning system simply sends an omlox™ Proximity object and the Hub resolves the proximity information into a location by referring to the position defined for the zone which relates to the proximity positioning system.

  4. Added REST endpoints to request trackable motions at /v1/trackables/motions and /v1/trackables/$trackableId/motion.

  5. Added WebSocket pub/sub topic trackable_motions according to the omlox™ motion specification. This topic provides real-time updates for trackable movements, also considering the trackable’s shape.

  6. Added Hub configuration option persist_locations which enables to persist all location updates to the database. Previous locations will be loaded when the Hub starts. This option is now enabled by default. Please note that persisting locations affects overall performance.

  7. Updated several configuration options.

  8. Fixed an issue where a wrong crs was displayed in the location object for a certain API request.

  9. Updated parsing the elevation_ref parameter of an omlox™ Location object according to the specification.

  10. Fixed an issue where a trackable was not correctly removed from the spatial index after it was deleted.


  1. Updated RPC support. See RPC for documentation and usage.

  2. Updated the admin frontend, added new features.

  3. Updated trackable and collision API. See the api_draft folder with documentation and examples.

  4. Added query parameters to conveniently update and select location and fence objects in various projections (local coordinates related to a zone, GPS and UTM projections supported throughout the API).


  1. OpenID based authorization and Role Based Access Control (refer to Security

  2. Added admin frontend to /v1/web

  3. Flexible server configuration options (refer to Server

  4. Fixed: Provider type was always “unknown” instead of actual type.

  5. Added trackables array to location object. This allows to identify to which trackable(s) a location update belongs to for example for websocket location update subscriptions.

  6. Added properties field to trackable object. This allows to add custom information associated to a trackable.

  7. Improvements and fixes to the GeoFence engine.


  1. Support for customizable IoT Sensors data:

    • Added „sensors“ property. The content of the sensors data is application defined.

    • New API endpoints /providers/$id/sensors (GET/PUT) and /trackables/$id/sensors (GET, returning a data array from sensors of all providers belonging to that trackable)

  2. Added properties to allow fine grained event controls to the Fence object:

    • timeout: Timeout in milliseconds after which a FenceExit event should be triggered when no location updates are sent anymore. Infinite when 0 or null (default).

    • exit_tolerance: The distance tolerance to the geometry of a fence in meters before a fence exit event should be triggered when leaving the fence. Useful to avoid fluctuating entry / exit events due to positioning accuracy at the borders of a fence.

    • tolerance_timeout: Timeout in milliseconds after which a position outside of a fence, but still within exit_tolerance distance from the fence, should trigger an exit event when it’s not seeing any position update inside the fence.

  3. Added params member to Websocket Subscribe request object to allow for parameters related to websocket subscriptions (e.g. crs and geojson parameters, same as query params available for location and fence REST API).

  4. Basic Authentication and Security Support


  1. Advanced 3D fence events and general improvements to fence event API. Fence events can now also overlap.

  2. Added properties to Provider and Fence objects, allowing applications to set generic data.

  3. Forward properties with FenceEvent, allowing applications to act on associated events (e.g. easily build a relationship between a MES production step and a fence event).

  4. Fixed an issue when requesting GeoJson objects where the object might be invalid.


  1. Added Websocket publish / subscribe API /ws/socket for location updates and fence events. Available topics: location_updates, location_updates:geojson, fence_events, fence_events:geojson.

  2. Added parameter “crs” to all location APIs to query location data for a given projection (e.g. “EPSG:4326” or “local”).

  3. Extended /trackables API. You can now create a trackable and locate the most recent location(s) of any of it’s assigned location providers via /trackables/{trackableId}/location(s)

  4. Changed position type in Location object to use a GeoJson Point geometry. This simplifies the API and avoids use of differing geometry types in other parts of the API.

  5. Updated /providers API

  6. Improved data persistence

  7. Added HTTP DELETE method to all API resources to clear current data

  8. Added /zones/{zoneId}/transform and SimpleTransform object specification to allow easy zone setup workflows (useful for example for RFID zone setup to locate scanners)

  9. Added /fences/{fenceId}/events API to generate FenceEvents via API instead of location based fence event generation by omlox™ hub. This may be useful for RFID scanners or general applications where a 3rd party server may generate its own fence events. This allows to use foreign generated fence events with an omlox™ hub Fence to relate fence events to real world places.

  10. Added /zones/{zoneId}/createfence to allow easy creation from an approximated polygon of an existing zone definition.


  1. Fixed geometry type definition for the fence region in the OAS specification and updated example data accordingly. Also provided more detailed description of Position, GeographicPoint and GeographicPolygon types.

  2. Improved handling of invalid fence geometries and give more detailed error descriptions to a user for invalid geometry data.

  3. Fixed “fence_name” should be “name” in the OAS Fence object specification.


First public release