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:
There are essentially three different types of communication between clients on your network and our web-servers.
This is used for normal webpages delivered over HTTPS from gridspy.com.
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 gridspy.com. 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 gridspy.com, we use port 443, so it acts like HTTPS from a firewall perspective.
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 v2.gridspy.com:443 which it maintains for hours at a time as a two-way data uplink.
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.
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)
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.
DHCP request using onboard fixed MAC address
DNS request to resolve v2.gridspy.com
Establishes ongoing TCP/IP connection with our backend