The major impetus for creating this software was that there were a number of unaddressable
concerns with the third party backend we were utilizing with Optimize in order to pull BACnet and other communication
protocol's data into our system. One of these concerns was that if there was a "stale" piece of data, or
an unresponsive controller device, we wouldn't know it until a month later when we saw a long trendlog of
the same value for a particular object. In order to correct this one thing, an entire redesign including
a C-based open-sourced library that enabled me to have more finite control of the information flow was
necessary.
While I was using Vuejs for real-time data messaging client-side, this time I was using a Websocket (using Redis,
Socket.io, and Nodejs) to do the communicating rather than Event Source. Similarly, since we were
no longer using our previous backend software, I was now gathering this information via a makeshift API that
I created to interact with the command line toolkit mentioned previously. So now, anytime I needed to update a value,
I could simply write $object->readProperty(85); 85 being the BACnet array value for "present_value."
I was so excited when I successfully had the Websocket server accepting values and updating the database and client
browser that I actually documented it. The right side triggered the "get new values" action reflected in the command line,
and the left browser updates with new values. The image popping up is a result of Vuejs Class Binding.
One of the big advantages of using our new system is that I could design completely independent System Status Boards
for each location. This allowed the client to view data with updates at least every five minutes, but in most cases
it was pushed via the BACnet's Subscription COV server update. This was injested by running the BACnet server
process in Symfony's Process Component. Basically it ran in the background, and read each line every two seconds. All new
information was sent over to be updated in the database, and Laravel was set up to run an update job that sent the websocket
update anytime the model was updated.
Likewise, when I came across jobs that wouldn't run (basically the device wasn't responding), I had to exclude them
from future read-property requests or it would really gum up the job update queues. And, unfortunately for me, this was before Laravel
Horizon was out, so I was stuck with just viewing keys in Redis as quickly as possible. So, anytime a value failed to update,
I made the device "offline," and changed all values to "N/A" to make it obvious to the client's engineers that something was
amiss with that physical piece of equipment, or the connection to it.
This was one of many thrown together solutions to satisfy a client request. In any case, it's a great look at the system
in action, updating dynamically, with the command line BACnet stack verifying the value along the way. If you're
wondering why it says "Optimize" everywhere still, the rebranding hadn't yet taken effect, as they couldn't come up
with a different name quickly enough, and I had to start with something.
I actually had to pore over some C code and change the output of the Subscription COV event in the BACnet
stack library and recompile, which I was NOT comfortable doing! But it worked out. This allowed us to get those subscription
events pushed from the controller device instead of just manually asking for all updates.
This is a picture of the 4k Displays prominently featured in Sam's Town's engineering shop. There were visual
alarms set up with Vuejs Style Binding to alert the engineers if any area was over a specific temperature.
After about a year we realized that the BACnet Stack we were using was slowing us down, and the desired amount of updates per second
just didn't cut it for a commercial product. We began talks with SoftDel which didn't pan out, and were in the midst
of striking a deal with Polarsoft, one of the original BACnet vendors, when AOG ran into some money issues. I was really
excited to replace the current BACnet stack with different command line solution that would handle most of the controller
updates, and communicate in JSON rather than STDIN/STDOUT.
At Green Valley Ranch they had displays in the Central Plant, the Engineering Shop (shown), and in two other offices on 4k monitors.
At our peak, we had this system installed in about fifteen locations, with some of the more notable locations being
Fiesta Henderson Casino, Green Valley Ranch, Town Square, Sam's Town, and the Aliante Casino. I personally configured
every server with Ubuntu 16.04 LTS, configured the web server (NGINX) for use with Laravel, and provided the custom networking
setup that each different IT department required in order to give remote access to the system.
There were HVAC techs on our team, but I was the only developer for this project.
One of the Displays as shown on a mobile device. Most of the directors wanted a way to view their central plant from home!