Thermostat Balancing Exercise

Focus

How can I create a user-friendly home thermostat monitoring application?

• Everactive Environmental+ Eval Kit provided me with all of the critical information I needed.
• Grafana was able to manipulate and display the data provided into a clean user interface allowing for a quick view understanding of the current temperature balance of all rooms with sensors.
• The end user would be able to easily adjust their ventilation to obtain a consistent balance around the home using this technique.

The current evaluation kit provides an environmental sensor which can measure ambient temperature, relative humidity, and barometric pressure as well as be triggered by an “I have moved” event. This data is available to utilize for whatever application you may find interesting.

I decided to first start with a common application of temperature balancing the rooms within a home. Simply by leveraging the kit as is, I am able to stream the current temperature within each room. All of these results are available right out of the box on insights.everactive.com for your kit on each sensor page.

I wanted to design a more tailored view that I could glance at and see the current status of all my sensors along with where they were placed.

Platform

I’m utilizing our Everactive Evaluation Kit to show the types of features that you can leverage with our always on batteryless monitoring capabilities. Simply purchase a kit, follow the instructions to get the sensors connected, and start to stream data from our sensors under minimal harvesting conditions.

Setup

I leveraged one Everactive Eval Kit plus additional sensors to outfit every room within my home.

I leveraged the Grafana dashboard environment to develop a tailored dashboard with the panels I required.

Activity

I created three environment variables within Grafana. The first would allow me access to customer specific data sets. In my case, it would have all of the available sensors targeting “Ashleys Eval Kit”. The second would allow me to select which sensor was of interest to me for more of a deep dive view. The final variable was a text field allowing the user to input the setpoint for the thermostat which would be used for the delta calculations later on.

Here is a snapshot of the variable queries and settings:

With the variables set up, I then moved on to setting up the panels.

Main Overview Panel

The main view I desired was to see the current temperature of all active sensors in such a way that I could get a feel for how balanced things were without reading values. It would also let me know how far away each room was from the setpoint without having to do math in my head or read numbers.

To start off, I set up my sensors all around my home.

With data now flowing in, I decided to produce a table view. Each row would contain a single sensor, the temperature, a delta, and a timestamp.

As I started to work, I quickly realized that a gauge of some sort was in order for the temperatures. I made a bar gauge that was colored from blue to red and set the min / max values to levels that didn’t make sense for a home. You can quickly see if one of the bars is not in alignment with the others without reading any data. Perfect!

Next, I wanted to know how each sensor reading compared to the setpoint because in theory the whole system could be off by a few degrees. I did some simple math in my query to enable an absolute delta from the setpoint variable. The value was listed in the table with a solid background which was colored yellow if it was > 2 degrees off or red if it was > 3 degrees off. This proved very useful and easy to interpret.

While reading the data, though, I found that I couldn’t easily tell which sensor was in which room. I decided to map the sensor Mac Address values to the rooms each sensor was located in. This made it much simpler to glance at the chart and extrapolate what I desired.

Knowing that many people in industry prefer Celsius over Fahrenheit, I provided the same view for both options.

Finally, I added on relative humidity values as well as a timestamp of the sample being viewed. If something seems out of place, you can see if it happens to be an old sample enabled by too large of a sample window (say 24hrs vs the last 30min).

I’m sure there are far more elegant ways to do all of this, but since I’m a silicon/systems-based hardware engineer who loves hacking things together and as this is my first exploit into SQL, functionality was more important to me than elegant coding🙂 After you’re done rolling your eyes at me, please feel free to send me examples of how to do it better! Knowledge sharing is key to everyone’s advancement!

with sensor_last_readings as (
 select
 distinct on (sensor_last.sensor_mac_address) sensor_mac_address,
      sensor_last.ts,
      (reading->'temperatureMeasurements'->0->'value')::jsonb::text::numeric as temperature_0,
      (reading->'temperatureMeasurements'->1->'value')::jsonb::text::numeric as temperature_1,
      (reading->'humidityMeasurements'->0->'value')::jsonb::text::numeric as humidity,
      (reading->'pressureMeasurement')::jsonb::text::numeric as pressure,
      (reading->'vcap')::jsonb::text::numeric as vcap,
      (reading->'scap')::jsonb::text::numeric as scap,sensor_last.gateway_serial,
      sensor_last.reading
 from
      api_v2.packet_sensor_readings_last sensor_last
 where sensor_last.gateway_serial != '' AND (sensor_last.reading->'schema')::jsonb::text like '%environmental%' AND $__timeFilter(ts) 
 order by sensor_mac_address, ts desc, gateway_serial, reading desc
  )
 select
    sensor_last_readings.sensor_mac_address,
    (sensor_last_readings.temperature_0 - 273.15) * 9/5 + 32 as TemperatureF,
 case
 when ((sensor_last_readings.Temperature_0 - 273.15) * 9/5 + 32 > $Setpoint) then ((sensor_last_readings.Temperature_0 - 273.15) * 9/5 + 32 - $Setpoint)
 else ($Setpoint - ((sensor_last_readings.Temperature_0 - 273.15) * 9/5 + 32))
 end as deltaF,
    (sensor_last_readings.temperature_0 - 273.15) as TemperatureC,
 case
 when ((sensor_last_readings.Temperature_0 - 273.15) > (($Setpoint - 32) * 5/9)) then ((sensor_last_readings.Temperature_0 - 273.15) - (($Setpoint - 32) * 5/9))
 else ((($Setpoint - 32) * 5/9) - (sensor_last_readings.Temperature_0 - 273.15))
 end as deltaC,
    sensor_last_readings.humidity,
    sensor_last_readings.ts
 from 
    sensor_last_readings
 left join api_v2.sensors sensors on sensor_last_readings.sensor_mac_address::macaddr8 = sensors.mac_address::macaddr8
 join api_v2.gateways gateways on sensor_last_readings.gateway_serial = gateways.serial_number
 join api_v2.associations_current associations on gateways.gateway_id = associations.entity_id
 join api_v2.customers customers on associations.customer_id = customers.customer_id
 where customers.name IN ($customer)

Figure 6. Grafana Code for Dashboard in Figure 2

Figure 6 shows the dashboard I ended up with, but the first realization was, if something was off, I wanted more details! I then decided to add a couple panels at the bottom showing the temperature and humidity results over time. This would allow the user to see if there was an event that caused the discrepancy or if it slowly moved there over time.

I decided to add both a temperature and a humidity timeseries chart for a selected sensor.

with sensor_data as (
SELECT
  $__time(ts),
  (reading->'temperatureMeasurements'->0->'value')::jsonb::text::numeric as tempk
 FROM api_v2.packet_sensor_readings
 where sensor_mac_address = '$mac_address'::macaddr8 and $__timeFilter(ts)
 order by 1 desc
  )
select 
 time,
  (tempk - 273.15) * 9/5 + 32 as Temerature
 FROM sensor_data

Figure 8. Grafana query for temperature chart

You can see the effects of a room I was actively using during the week and then didn’t go into over the long weekend. The AC zone for that room was turned down all weekend to between 67-70F.

I was pretty happy with things except when sensors stopped reporting, I could see the last time stamp, but I couldn’t see what the harvesting looked like at the time. I decided to also add a chart showing the values of the VCAP and SCAP. The VCAP is the immediate use supply for the sensor. The SCAP is the backup storage super cap value. The two combine to give you a picture of the harvesting situation.

with sensor_data as (
SELECT
  -- Choose sensor statistics you want to plot in time
  $__time(ts),
  (reading->'vcap')::jsonb::text::float as vcap,
  (reading->'scap')::jsonb::text::float as scap
  FROM api_v2.packet_sensor_readings
 where sensor_mac_address = '$mac_address'::macaddr8 and $__timeFilter(ts)
 order by 1 desc
  )
SELECT
  time,
  scap,
  vcap
  FROM sensor_data

Figure 9. Grafana query for SCAP and VCAP chart

Findings

It was fairly simple to manipulate the data I desired into useful charts for my liking. The largest chunk of my time was spent getting more familiar with Grafana and the tools it provides along with the SQL query language. As I became more familiar with them, I started to move much faster.

There are still some items I’d like to improve. For example, I modified the Sensor Mac Address listings in the table to show the name of the room each sensor was deployed in. That was great until I wanted to dig deeper into one of the sensors. I wasn’t able to figure out how to have the unmapped Mac Addresses in a second column to use as a reference. If someone would like to share that with me, I’d appreciate it. In the meantime, I simply added a text box showing the mapping of names below. This worked for me, but it’s a little awkward because the text sort does not match the sort of the main table all of the time. Minor issues and areas to improve upon.

I hope you enjoyed this article! I sure enjoyed jumping into this project. I have many more on my plate using both our existing Dev Kits, as well as our future offerings coming out this year! Stay tuned and feel free to reach out to me in our developer Slack channel!

About the Author

My name is Ashley Glennon. This is the first of many posts from me demonstrating Everactive’s current technology and how it can be applied by developers within creative solutions to solve the problems of today. I have moved from my recent position as Director of the Systems Engineering Team here for the last 3 years at Everactive to this new position where I will be able to interact and collaborate with the fast-paced developer community to help get them excited to create new products leveraging our Everactive batteryless technology!