Network Connection Overview


GridSpy shares your home or office internet connection so you can benefit from high resolution realtime data at an extremely low cost. This document outlines how this connection works so you can evaluate our technology and white-list the required hosts on your firewall.

Most businesses do not have a very strict firewall policy and they can access the entire web from computers on their network. If this situation describes your network, you can use Gridspy right now with no effort required.


There are only a few resources required for the Gridspy solution to function correctly. You simply need to ensure that your firewall does not explicitly block the following resources:

  • HTTPS allowed to - proxy possible. For access to dashboard.
  • HTTPS allowed to - no proxy support. Custom protocol, just for GridHubs.
  • DHCP - IP addresses with gateway information assigned to GridHub devices when they connect.
  • DNS - Access to standard DNS servers on the web (i.e to resolve

There are essentially three different types of communication between clients on your network and our web-servers.

  1. A normal HTTPS session which occurs when staff on your network access your power dashboard.
  2. Once that dashboard is loaded in their browser, the browser will often establish a long-lasting connection to our server to receive a live data feed. This uses technolgies such as websocket, flash sockets or HTTPS long polling depending on browser support.
  3. Each GridHub installed on your network makes a direct TCP/IP connection back to our servers to upload power usage data in real-time and to receive configuration. This connection is from the GridHub to the server so port forwarding is not required.

HTTPS for Dashboard

This is used for normal webpages delivered over HTTPS from

This content includes:

  • Dynamic web dashboard (can be password protected) - example
  • Content such as static data (.js, .css)
  • Data in CSV format for use by javascript in the browser - example
  • Configuration information in XML or JSON for use by javascript in the browser
  • Graphs created by server in .PNG or similar format - example

Live data feed from website

One of GridSpy’s key features is its ability to deliver a fresh sensor reading to your browser each second.

To do this, your browser connects back to our servers using either Comet ) or Websockets.

Comet connections are a series of normal HTTPS requests to The response to each one of these requests takes some time, a method called “long-polling.” When the server has some new data for the web-browser, that data is sent as the response to an outstanding connection that may have been open for up to 30 seconds. These connections should have no problem navigating through a standard HTTP proxy.

Websockets are a direct TCP/IP connection to a host at, we use port 443, so it acts like HTTPS from a firewall perspective.

GridHub Ethernet data concentrator

Long term TCP/IP link

The GridHub is the device on your network that communicates with your installed sensors via RF, RS232 or RS485 and then uploads the readings to our central servers. Shortly after it turns on it makes an outgoing TCP/IP connection to which it maintains for hours at a time as a two-way data uplink.

Outgoing only, no proxy

This outgoing TCP/IP connection does not require any special configuration on your firewall unless you restrict outgoing port 443 (HTTPS) access. It allows the GridSpy to provide live data and real-time configuration without requiring polling or other expensive constant communication. The live samples uploaded from the GridHub are then distributed to authorised users visiting your dashboard on the web.

If you decide to install an IO solution tied to your GridSpy system such as load shedding, light control or some form of BAS integration, the TCP/IP uplink allows you to push commands from the server to the GridHub instantly. This connection will also allow GridSpy to trigger SMS, Email and web alerts on interesting power conditions as these features become available.

No Operating system, invulnerable to existing viruses and worms

The GridHub is built on custom firmware without a 3rd party operating system (no Linux, Windows or other 3rd party kernel). This means that it is invulnerable to any existing worm or virus. Since the GridHub makes only an outgoing connection to a fixed IP you do not have to expose it to the wider web. It also does not need to be on the same subnet as your desktop machines. You can rest assured that the GridHub will not increase your exposure to security issues. Another benefit is extremely low power usage for the GridHub (< 2 watts)

Works on DMZ

Other than DHCP for IP config, the GridHub does not attempt to communicate with any device on your network besides your internet gateway. This makes it suitable for placement within your network’s “DMZ” if you so desire. You could also allocate it to its own subnet. Either of these measures would make it impossible for the GridHub to communicate with other computers within your network, but would not compromise its standard usage at all.

The GridHub uplink connection does not currently work through an HTTPS proxy, though this could be supported in the future if necessary for your installation. As mentioned above, the connections from the browser back to our servers DO work through a HTTPS proxy. Please drop us an email if this is an issue for you.

The GridHub follows this process to connect to our servers:

  • DHCP request using onboard fixed MAC address

    • Response to this request sets IP address, Gateway and subnet
    • DHCP failure results in retry after 30 seconds.
  • DNS request to resolve

    • Uses gateway server found during DHCP step
    • Requests IP from a range of pre-defined DNS servers, such as Google at,
    • Falls back on a static IP assignment should the DNS step fail.
  • Establishes ongoing TCP/IP connection with our backend

    • Drops connection only if it is disrupted by network issues

Further reading