Developer Portal


The Service Delivery Platform (SDP) offers an online virtualisation of the physical world of devices in the internet of things. Interactions in the physical world are turned into online events, that can be logged, monitored and acted upon via the online SDP. Alternatively, by sending commands via the SDP, users can control their physical devices.

The developer site serves as a guide to the web service interface of the SDP that allows developers to define and implement their own end-user services and front-end applications. It also serves as a rough requirements document for a client-side SDK for mobile apps.


Most devices have a limited set of programmable attributes, such as on/off, open/close, start/stop, volume, temperature, etc. Rather than making these devices smarter, the future of the industry is in connecting these devices to a local hub, that is making the device controlling functions accessible via apps.

The N2G architecture is based on the concept that the hub, the SmartBridge, is providing the physical service and is kept lean and secure with minimal business logic. In Zigbee terminology, a device like the SmartBridge is called a Zigbee Gateway Device (ZGD).

The business logic is in the virtualisation layer in the Cloud, allowing manageability, scalability and flexibility of services. N2G is combining these functions in the Service Delivery Platform (SDP).


Apps can access most N2G's SmartBridge functions locally via WiFi and via the SDP cloud, both via a REST interface.

    This API allows for monitoring and local access, even when there is no connection to the Internet. The SmartBridge has a local storage facility to accommodate this. However, normal operation is that the SmartBridge is connected through the Internet to the SDP cloud, to allow e.g. remote management outside the home environment, statistics and firmware upgrades.
  • Cloud APIs
    The NET2GRID SDP has two cloud interfaces:
    • WAN API
      All functions that are directly related to ZGD and devices that can be performed without virtualization are in the Access API. This API stays close to particular IoT standards, such as Zigbee and Z-Wave.
    • SDP API
      Functions that need virtualization concepts to abstract from the IoT standard and concepts to make tasks and devices easier to understand and visualize, are in the SDP API. The SDP API can have add-ons and/or SDKs for even more ease of use for App development

WiFi enabled devices can connect via a proxy to the SDP cloud, without being connected to the SmartBridge. Through the proxy N2G supports an OAuth 2.0 authenticated connection with the WiFi device for control and measurement via the SDP. A good example of such a WiFi device is the Nest thermostat. Parameters like humidity, inside, outside and target temperature are stored with the preferred resolution in the SDP. WiFi devices without an OAuth 2.0 cloud API can still be managed by the ZGD. Through the SDP, there is access to other devices on the LAN via a REST API,, thus allowing App developers access to devices that are on the same LAN as the ZGD.


The current implementation of the N2G SDP supports the ZigBee protocol in a dual stack implementation. The ZGD supports the Home Automation 1.2 profile as a coordinator on Network 0 and either Smart Energy 1.x or Light Link 1.x as a Sleepy end device on Network 1. Other protocols like Thread can be supported through a firmware upgrade.

The SDP and ZGD architecture however allows for abstraction of other radios like Z-Wave, 915, 868 or 433 by adding additional radios either on board or through the USB extension slot of the ZGD.

Technical Architecture

NET2GRID has adopted the ZigBee Gateway IP specification for its Connected Home Service Delivery Platform (SDP). This is an official Zigbee specification of a light-weight communication protocol that can be used both over TCP and UDP. There is a stream of data from the sensor network gateway to the back-office to report new sensordata (referred to as Reports). There is also a stream from the back-office to the sensor networks, used for actuation and ad-hoc requests, these are called RPCs (Remote Procedure Calls). Reports and RPCs are placed in the message queues in the back-office, and these message queues serve as integration points to the rest of the system.

There are three main components of the system. First every sensor network has a Zigbee Gateway Device (ZGD). On the back-office there runs an IP Host Application (IPHA) maintaining connections to the ZGDs and using Message Queues for communication with the rest of the back-office services.