Toward the end of my time at Internet Crossroads, I was approached by a friend from my hometown with an
idea for a project. He explained the opportunity and I began to create some mockups for them. They liked
what I had come up with and working with them became my full time gig in short order. Before long, the business
offered to move me out to my hometown and we were fast on our way to version two.
This new venture into HVAC was an interesting marriage of my web development skill set and an entirely different
category. There are many forms of automated controls and many brands. Technically, the most ubiquitous standard
for this industry is BACnet, an open-source communication protocol that is ratified by ASHRAE, but I found out
quickly that different companies adhered to that standard in different ways. There is a core set of functionality that
each controller is required to have in order to call itself BACnet compliant, but there's also LonTalk, Modbus,
Allen-Bradley has their own network type, Zigbee has their own wireless standard, and many others.
This project entailed months of planning and development with many more months of fine tuning with
customer feedback. Even with many clients using the product, the company I was contracted from ended up
falling apart in early 2017. I was picked up as a full time employee of the company that had ordered
the software originally.
This video shows internal communication from myself and a work colleague explaining how
an end user might create an "HTTP Sender" with our current third party backend and have that match up
with a remote Optimize server, and have the information land in a Tile add Component model that ends up
showing data in the interface.
Even within BACnet, there is a two-wire network, BACnet over ethernet, and BACnet over IP.
As you could probably guess, there are many opportunities for inconsistency of setup and bottlenecks among slower
communication methods. Of these types, we eventually landed on BACnet over IP as our internal defacto standard,
as it ended up playing nicer with different IT groups at different locations. They weren't particularly keen
on allowing layer 2 traffic over their networks, and in some cases they were unable to route that
traffic over certain VLANs, so this seemed to be the best compromise of speed and compatibility.
I can't stress enough how much of a rapid prototyping environment this was developed in. We were growing
quickly and I had to make certain design concessions in order to get a product out.
At this point the company had acquired several additional clients, and they asked me to put together a promotional
video of the interface. The video shows a later stage of development that includes Trend Log graph views
of historic data, the export of that data, and the control of setpoints remotely. Unmute at your own risk...