Skip to content
This repository has been archived by the owner on Sep 18, 2020. It is now read-only.


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

bigiot-bridge Greenkeeper badge Build Status

Bridge for providing data as offerings in the BIG IoT marketplace, using the Flowhub IoT platform with the NoFlo Flow-Based Programming runtime.


0.3: Production

  • Can expose multiple datasets as offerings in BigIoT marketplace
  • Example using the Deutche Bahn and City of Cologne public parking APIs is provided
  • A public service instance is running on since November 2017



Running locally


  • Docker is installed and daemon running
  • BigIot marketplace credentials (provider id+secret)
  • Redis database instance running. Can be locally, via a Docker image, or a cloud service


Create default settings files

cp .env-default .env

Edit .env to contain your provider id/secrets.


Start the service

docker-compose up

Checking that it works

The new offering(s) should now be available under My Offerings

To request data from the API without going through the marketplace, you will need an authentication token. Create it using:

export TOKEN=`node -e "console.log(require('jsonwebtoken').sign({}, Buffer.from(process.env.BIGIOT_PROVIDER_SECRET, 'base64'), {expiresIn:'1h'}))"`
curl -H "Authorization: Bearer $TOKEN" http://localhost:5000/txl

Configuring and adding new offerings

The offerings are set up as a NoFlo graph, a 'Data Provider'. This graph should use the Provider component, and:

  • Set up the BigIot offering description, send it to OFFERING port
  • Setup configuration and send it to CONFIG port
  • Connect to the REQUEST port. On data, perform requested query
  • Respond with the returned data by sending to RESPONSE port

Examples can be found in the "ParkingProvider" and "WeatherProvider" graphs, and the "Provider" and "ParkingProvider" tests.

Deploying to Heroku


  • An Heroku app with the Container stack enabled
  • Heroku Redis addon enabled for the app
  • Heroku CLI tools installed locally, logged into the Container registry using heroku container:login


docker-compose build
heroku container:push web

Best practices

Local caching

The data provider may look up the data in memory or local database, or fetch from external APIs. It is recommended for data that changes slowly that they are fetched periodically separately from the HTTP requests nd cached in a local database like Redis. The data provider in the HTTP request path then only queries the local Redis database. This is expecially for third-party APIs, which have an unknown amount of latency/uptime. The third-party APIs may also not support the desired querying methods, like geo-based queries.


  • 0.3.2 (February 21 2018)
    • Updated to latest BIG IoT JS library
    • Set the example data offerings to "FREE"
  • 0.3.1 (February 19 2018)
    • Fixed datatypes used in the parking offering example
  • 0.3.0 (February 9 2018)
  • 0.2.0 (December 12 2017)
    • Added a second data source for the ParkingProvider: parking spaces in Cologne


Bridge for providing BIG IoT offerings for Flowbub/MsgFlo users








No packages published