Adding IoT Flare to a Hot Springs and Spa Business

hot springs

As the folks at Bozeman Hot Springs usher their hot springs and spa into the 21st century with new technology and pools, they are thinking about new ways to delight their customers and stay top of mind. One recurring request, no doubt from the avid skiing community, is the ability to read current pool temperatures online, in the same way ski resorts publish current snow conditions. This project makes that dream a reality by integrating with the existing standalone pool temperature controllers and publishing temperature data over the internet using an easily consumed API.

The Problem

There are three newly constructed outside pools that use the latest and greatest equipment and controllers from Honeywell to maintain temperature, specifically the Honeywell T755M. The problem is, the temperature data used by the controllers is trapped on the controllers themselves. There's no way to publish these temperature readings over the network without additional hardware.

The Solution

There needs to be a middle man to make sense of the data provided by the standalone temperature controllers and then publish said data over the network. Enter the TS-7680 with its four analog to digital inputs, wireless network interface and low cost plastic enclosure with DIN mount. For future expansion, the TS-7680 supports the TS-1700 Modbus peripheral that enables eight more temperature sensors for other pools.

Advantages

With several hot spring resorts in the area, there is a competitive advantage to being able to publish pool temperatures in real time. Not only are customers able to inform themselves and plan a trip accordingly, they'll also keep checking back daily, keeping Bozeman Hot Springs top of mind, while they dream of their next trip. There are also advantages on the business end for pool maintenance, like being able to collect, store and chart out pool temperatures over time and even get email or SMS alerts for when temperatures drastically change. A system like this also lays a foundation for other high-tech improvements, such as displaying live pool data on a wall-mounted LCD screen for visitors to see.

Hardware Requirements

The Honeywell T775M standalone controllers are a crucial component we must be able to interface with. They are already reading from temperature sensors installed in the pool's supply pipe and outputting commands to adjust hot or cold water flow. Luckily, there are two outputs, MOD1 (used) and MOD2 (spare), and each are configurable to read from a specific sensor input and output a 2–10 VDC value based on programmable variables. So, to gather temperature data from all three of the controllers, we'll need a system with at least three analog to digital inputs.

For networking, a wireless repeater already has been installed in the same room as the Honeywell controllers. Luckily, a networking rack with switches is also installed nearby, but wireless is convenient so we don't have to run cable to the rack.

While technically we could run our own sensors and bypass the Honeywell controllers, it's very nice to have a single sensor to deal with, especially since the cabling has already been routed nicely through metal conduit. Not to mention there is a slight cost savings and less maintenance worries.

The T755M controllers are mounted on a piece of plywood attached to a concrete wall. This setup is perfect for a simple DIN rail on which to mount our external system.

Periodically, filter and pump maintenance will be performed in the same room as the controller and external system, which makes for a high-humidity environment, so we'll need to have our system enclosed for protection.

Future expansion to the other six pools not hooked up to a Honeywell controller would be good to consider. A system that has spare analog to digital inputs and expansion options is necessary.

All considerations taken into account, the TS-7680 is a perfect match. It has four ADC (0–10 VDC) inputs, DIN mountable enclosure, wireless 802.11a/b/g module and Modbus port for expansion (TS-1700 8x Temperature Sensor Peripheral).

Software Requirements

Software-wise, we'll need to read from the ADC inputs of the TS-7680 and then serve them. To read the ADC inputs, we'll build upon example C code provided by Technologic Systems. When serving this data, we want to make it as easy as possible for our website or other systems to consume. This is accomplished using a REST API, a commonly used and understood API for those working in the Internet of Things (IoT) or Web of Things (WoT) domain. For this, we'll reach for node.js and pm2, which makes it pretty easy to set up a simple, easy-to-consume REST API server without the need to involve heavyweights like Apache. For even faster development, we'll reach for the node.js module restify.

Planning

This is where the fun stuff starts happening! The entire planning phase started with a trip to Bozeman Hot Springs to get a tour of the facilities and how they operate. This is where we were first introduced to the Honeywell T775M controllers and saw where temperature data is collected. Cracking open the enclosure of the T775M, we found some clearly marked screw terminal connectors, of which the most interesting was the MOD1 and MOD2 outputs. MOD1 already was taken in order to control the water valves to maintain temperature of the pool, but MOD2 was free for the taking. Not only that, but a quick reference to the manual showed it supported 2–10 VDC output. Perfect!

We contacted Honeywell and asked if there was a way that we could use MOD2 to output the data from Sensor A, which is directly connected to the pool's intake pipe. Once confirmed, we decided to use the TS-7680 and started to work!

Controller Configuration and Wiring

We started with a wiring diagram of how we were going to connect the TS-7680 with the three T775M controllers. Only two wires were necessary from each unit. The ground wires were all connected together and hooked up to the bottom screw terminal (Pin 1). The VDC output wires were connected to AN0, AN1 and AN2 analog inputs of the same screw terminal connector (Pin 2, 3 and 4, respectively).

In order to output the current temperature data from MOD2, we had to configure it as follows:

  • TYPE = 2-10 V

  • SENSOR = Sensor A

  • SETPOINT = 100

  • THROTTLING RANGE = 40

  • INTEGRAL = 0 (Requires power cycle!)

  • HEAT/COOL = HEAT

The throttling range brackets the setpoint, giving us a temperature range of 80°F to 120°F. When we read 10 VDC from MOD2, it represents 80°F. Similarly, 2 VDC represents 120°F and in between, 6 VDC represents 100°F. If this seems backward to you, it's because we are in the heating mode. The controller is designed to control a valve in order to heat or cool the pool when it reaches our threshold. We're sort of cheating here to get a linear temperature model. Plugging our x (temperature) and y (voltage in mV) values it into a slope intercept form (y = mx + b), so we end up with the formula y = -200x + 26000. Solving for our temperature (x), we get x = (y - 26000) / -200, which is the same formula you'll find in the source code. With our work on setting up the controllers complete, it's time to move on to the software side of things.

Fetch ADC Input Data and Prototype

After downloading the given mx28adcctl sample code from Technologic Systems onto our TS-7680 board, we started modifying the main() function to accept a single argument of which analog input pin to read from. For example, to read the voltage on AN0, we simply run ./getadc 0, and we'll have a return value in mV. For prototyping, AN0 and AN2 were hooked up to constant 3.3 VDC, while AN1 was hooked up to a variable trimpot (0–3.3 VDC).

Pro Tip: In order to call this function as a non-root user, you'll need to run chown root:root getadc and chmod 4755 getadc to make root the owner of the binary and turn on the SUID permissions bit. The included Makefile does this for you.

Although unnecessary, we wanted to see at least some status indicator for when the temperatures were being read, so we could see if the unit is active. The TS-7680 enclosure has a yellow LED marked "Activity", tied to GPIO #58, so we took advantage of that in our getadc program. When the program fetches data, the activity LED will flash. Again, example code for dealing with GPIO using the sysfs interface provided by Technologic Systems made quick work of this. For more information about using the sysfs interface, take a look at our article "Robust C Library and Utility for GPIO sysfs Interface in Linux".

Develop the REST API

Now that we can read voltages, we begin on coding our API. There are several resources available for creating a REST API using Restify, so it was easy to create a couple of routes (API endpoints) for integrations to use.

Specifically:

  • GET /temperatures — returns a JSON array with all three pool temperature data objects.

  • GET /temperatures/:pool_id — returns JSON object with :pool_id temperature data where :pool_id is between 0 and 2.

Example response from GET /temperatures:


[
   {
      "id":0,
      "vdcin":"5151",
      "temperature":"73.4",
      "temperatureUnit":"F",
      "error":null
   },
   {
      "id":1,
      "vdcin":"4915",
      "temperature":"64.9",
      "temperatureUnit":"F",
      "error":null
   },
   {
      "id":2,
      "vdcin":"5143",
      "temperature":"73.1",
      "temperatureUnit":"F",
      "error":null
   }
]

This should be all that the foundation needs for now, since we are going to be reading only temperature data. In the future, we might add pressure sensor data for maintenance purposes, but that's a ways off. The only tricky part of developing the node.js app was the asynchronous nature of node.js. Making the system call and then dealing with the callbacks and whatnot was a little challenging to get the brain wrapped around. So, JavaScript promises were used to make the logic easier to understand. Other modules to help deal with synchronous calls exist, but the author was familiar with JavaScript promises, so we went with those.

Note: as a nice little bonus, the code was also ported to Python, which can be seen in the bhs-api code repository. Why? Mostly born out of frustration with dealing in asynchronous system calls in JavaScript, but also somewhat for the fun of it.

Also note: instructions for setting up the node.js app that powers our API can be found in the embeddedarm/bhs-api repository's README file.

Example Web Page Using API

A simple web page was created as a demonstration and proof of concept for advertising the temperature data online. It uses jQuery and AJAX to make a call to the REST API server and uses the returned JSON object to display data. This is done every 10 seconds to show off the capabilities of displaying "real-time" (quote-unquote) temperature data.

TS-7680 Installation

The last step of development was actually to install the TS-7680. A DIN rail was screwed to the plywood wall next to the T775M controllers, and the enclosed TS-7680 was mounted on it. As planned in the wiring diagram, hookup wires connected MOD2 of each controller to the screw terminal connector of the TS-7680. Power was applied to the TS-7680 using the PS-12VDC-REG-3PB power supply plugged in to a nearby wall outlet.

For networking, the TS-7680's wireless interface was configured to fetch an IP address via DHCP and associated with the SSID and password of the Bozeman Hot Springs wireless access point. The networking administrator was called in to assign a reserved IP address for the MAC address of the wireless interface and port forward 8080 to said reserved IP address. The website administrator was then called in to provide us with a subdomain for easy access to the newly installed TS-7680 API server, thus concluding our TS-7680 development and installation.

Results

The fruit of our labors is a nice-looking, prominently displayed widget showing off pool temperature data provided by our API server for customers to see. Time will tell if this has any impact on sales and business, but customers already have started to compliment the addition to the website in such a short time since going live.

Of course, this is just the start of what can now be accomplished. A maintenance dashboard can be developed to display historical temperature trends and send alerts for when the unexpected happens. Informing visitors of current pool temperatures using a digital screen instead of a dry-erase marker board can now be done. Future expansion to other pools, including those that are currently under construction, is an option, thanks to TS-1700 support. Other sensors can be added and reported on through the API server as well.

Overall, this project has provided Bozeman Hot Springs with a great foundation in bringing their pools into the 21st century and IoT domain. We're looking forward to working together in the future. In the meantime, we do hope this has inspired you in some way to develop your own IoT application using Technologic Systems' embedded products. If you're buzzing with anticipation, please reach out to our sales and engineering teams. They love hearing about new and exciting applications.

Materials List

Here's a quick bullet-point view of the parts and materials used in this project.

  • TS-7680 Single Board Computer with AC Power, Relays, and WiFi (TS-7680-256-4GF-I-DEV, KIT-7680, CB-ANT-TIWI, TS-ENC768-DIN, PS-12VDC-REG-3PB)

  • DIN Rail with mounting screws (hacksaw and file to cut to length)

  • Hook-up wire (22 AWG) in various colors

  • Honeywell T755M Standalone Temperature Controller (per pool)

  • Development workstation (Mac OSX, Linux, or Windows)

  • Linux Server with node.js and pm2 installed

Source Code: embeddedarm/bhs-api on GitHub.org.

This article is sponsored by Technologic Systems.

Load Disqus comments

Community Events

-
Austin, TX, USA
-
Austin, TX, USA
-
San Jose, CA, USA
-
San Jose, CA, USA
-
San Jose, CA, USA

Best Database?

Choices