The operating system for data based services on the internet.
With a B2B offer, we support service providers, manufacturers and developers to establish their own data-based products and services. For that reason, we develop and operate a universal, open and interoperable IoT platform for a semantic representation of all things.
The universal discription of the physical world.
Whenever we connect a remote domain entity like a humidity sensor or lamp, we translate it into our so called thing structure. This means connctd things may represent sensors, actors or even services with their corresponding states. Since these things are composed of reoccurring „building blocks" (namely components, properties and actions), a Philips Hue Lamp Thing for example will partially look the same as a Lifx Light Thing. Additionally things get enriched with semantics which makes it easier for app developers to incorporate our things into their apps as they are self-explanatory and developers no longer have to work with multiple, varying third party domain models.
Simple integration of third party technologies.
Whenever we talk about routines which hook up a remote technology and translate remote domain entities into things we call it "connector". You can either write your own connector (which is just an app) or you can make use of our connector service which already provides a couple of connectors like LIFX, OpenWeatherMap or Netatmo. Using the connector service is made as simple as possible: it takes care of technology specific setup procedures (like oauth2 flow) and allows the connector instantiation with only one single request.
We are transparent to your users.
We don't want any information about your users nor do they have to be registered on our platform. Whenever you send a request to our platform which is related to one of your app users, the request just needs to possess a user id within the header (X-External-Subject-Id). This id is generated by YOUR app and can be absolutely random.
Our device management will offer intuitive web UIs and apis, allowing hardware developers to accomplish these tasks.
The second scenario, which you can see on the right hand side of picture one, shows a hardware developer who wants hook up his or her hardware to a cloud solution in order to:
- receive data from remote devices
- manage new clients who want to make use of the hardware
- manage firmware updates
- monitor the devices
- remotely perform actions on the devices