Regardless of how patchwork a fabric our control systems may represent, the thread that binds them is an Ethernet connection, either directly or through some nature of hub, gateway, router, bridge or similar technology. Unlike contemporary home automation systems, our controllers do not communicate through a Cloud (jargon for a server at somebody else's address over which you have no control and which you cannot directly protect)and a handset is not what we consider a controller.
So where are our controllers? They may seem to be everywhere, but most of the control happens in an equipment rack located in a cupboard above the big desk in our bonus room, above the 3-car garage. A dedicated hardware firewall creates 2 control networks, one for the controller network and one for the surveillance cameras, neither of which is allowed any connection to the WAN (outside world).
We decided to build rather than buy the NVR (network video recorder) at the heart of the surveillance system; Blue Iris software affords it more features and more flexibility than most commercial NVR systems at a dramatically lower cost. This is a rack-mounted Windows PC and is the only device other than the firewall that connects to both the camera network and the controller network. A Silverstone chassis designed to fit in a 4U rack space houses it and allows our MegaRAID controller to create a very trustworthy RAID 6 array with as many as 8 drives. PNY provided a GeForce 960 graphics card to drive a big screen on the other side of the cabinet, and Accele provided a small flat-panel HDMI monitor that we attached to the front of the case.
That Sanus rack also houses an always-online sinewave UPS, a PDU (power distribution unit), the firewall, a Gigabit PoE switch for the surveillance camera connections, a Gigabit switch for the wired Ethernet controller connections, a Sanus rack drawer for the NVR keyboard and pointer, a TrippLite 5V PDU with 16 USB connections, each good for 2A or more, a bare PC PSU for DC feeds and a “Pi rack” shelf holding 10 Raspberry Pi Model 3 B controllers using homebrew angle bracket mounts. Up top, where the rack is less likely to reduce their radio range, we cap the rack with the hub for the Ecovent System, the Bluetooth Smart Mesh bridge and the gateway to the Synapse Wireless lighting control system.
In addition to the 10 units in the Pi rack, and the 30 in the CAP kits, other Raspberry Pi Model 3 B controllers live where they have work to do: at the apron of the driveway, in the garage, at the front door, near the irrigation controller, at the cooktop and so on.
A second Sanus rack, this one enclosed and on wheels, lives inside one of the ersatz lamppost pillars near the apron of the driveway, connected by optical fiber from the rack in the bonus room to an outdoor-qualified Microsemi PoE (Power over Ethernet) switch (shown at the right of the top paragraph). That rack houses a Falcon sinewave UPS, capable of extended-temperature operation, a Sanus DC supply with thermostat controller, top-mounted fans, a rack shelf that shares a Raspberry Pi with controllers for other devices and a winch interface - let us save that for later.
But our discussion of where controllers are located goes beyond their physical location.
Arduino in between, oh
A sensor in and of itself is not a controller and most cannot themselves communicate without a little endpoint intelligence, which is the role of the Arduino. (We may have several but we refuse to say Arduini). The same is true of many endpoint effectors (aka actuators). So if somewhere up the control chain needs to tell a relay to pull in, that may happen because the relay and an Arduino are at that location. While we could centralize a rack of relays and run power wiring to every ceiling fan, for example, the extra wiring is redundant and very confusing to troubleshoot. Likely Arduino applications include controls for the gas and water shutoff valves and the anemometer interface.
Raspberry Pi hither and nigh
We know that some information will need to be centrally stored and that we need to provide several ways of weaving together the various controller operations, including (please look them up since they will be tedious to make everybody read through here): JSON, MQTT, Bluetooth Smart Mesh, MySQL, NNTP, ONVIF, Bluetooth 4.0 LE, Bluetooth Beacon, XML, SMTP, http request (wget and curl), active HTML and Web page serving.
We have to (for logins to happen) name our controllers; here are ours:
Supporting the congregation
With most of the upstream (non-endpoint) controllers congregated in one place, we have the ability to add collective protections, including battery backup, surge protection, hot spares, an on-hand workstation for troubleshooting and more.
© Copyright 2016 Newstips, Lord Martin Winston and J2J Corporation; all rights reserved
This site needs a larger screen and is not optimized for phone or tablet viewing