Does anybody have any cool graphs or analytics using Sense data - Please share!


#1

Hi folks,
Now that we have official download capabilities in the v4 web app, I think it would be fun to share our graphs and analytics, as well as how they were created, as a chance to show innovation and share ideas. To start, I’ll volunteer my first graph with the new download data.

The following shows our daily usage and production of electricity over each hour of the day from a statistically aggregated perspective. The boxes represent the 1st quartile through 3rd quartile of usage, the line in the center the median usage, with the whiskers representing the roughly 2.7 sigma points on the distribution of usage/production. The dots are outliers beyond.

From this graph, one can see several interesting things:

  • Car charging is an easy to see outlier - any point above 10kWh is pretty much certain to include an EV charging session. One can also see that our two thirstiest EVs are set to start charging most of the time at 1am.
  • Solar production is very predictable, though seasonal here in northern California. Only a few cloudy outliers near zero. And yes - a few bad data points.
  • Time of Usage - in general, it looks like we’re doing OK on matching our usage to our Time of Usage rate plan. Solar is generally well-matched to our daytime usage, but we might be a good candidate for some level of battery storage to carry into the evening.

This graph was created straight from the downloaded hourly data in just a few lines of R using the readr and ggplot2 packages in RStudio.

library(readr)
library(ggplot2)

# Read in Sense download data
DownloadEnergy <- DownloadEnergy <- read_csv("~/Documents/Energy Analysis/1-hour data from Jan 01, 2018 to Jan 01, 2019.csv", col_types = cols(DateTime = col_datetime(format = "%m/%d/%y %H:%M")), skip = 1)
# Rename Solar Production so it's easy to use the word Total to select Usage and Solar
DownloadEnergy$Name[DownloadEnergy$Name == "Solar Production"] <- "Total Solar"
# Use DateTime as string
DownloadEnergy$DateTime <- as.character(DownloadEnergy$DateTime)
# Break out Time separately as string for easier graphing
DownloadEnergy$Time <- substr(DownloadEnergy$DateTime,12,21)
# Plot Total Usage and Solar to makes sure things make sense
ggplot(DownloadEnergy[grepl('Total', DownloadEnergy$Name),], aes(x=Time, y=abs(kWh),color=Name)) + geom_boxplot() + ggtitle("Energy Usage", subtitle = "") + xlab("Time of Day") + ylab("kWh") + theme_bw()

Conceptual view of the boxplot below, for those of you who have never seen one:


Disappointed in device discovery
For TOU billing users, do you change your habits to minimise your bills?
Usage Accuracy
Direct power flow from solar to load
Total kwh accuracy?
#2

I would love to see these use cases, and I’m sure the Product and Dev teams would be ecstatic as well.


#3

The first thing many people ask when they first install their Sense is “How accurate is Sense vs. my utility monitoring?” We can now begin to answer that, at least in the case where one’s utility allows them to download usage data. I’m going to walk through my accuracy analysis process for all the existing data I have for 2018.

In my case, I have solar, so I have two utility data sources:

  • An hourly net meter energy reading from my electric utility, PG&E, via their “Green Button”. Unlike some solar installs, I don’t have a second meter looking at my total house usage - I’ll only be able to compare Sense net usage vs. the net usage from my PG&E meter.
  • An hourly solar energy reading from my SolarEdge inverter. The data is downloaded via my SolarCity / Tesla portal. Unlike PG&E and Sense, the SolarCity download capability only allows hour resolution downloads a day at a time. I had to write a little script to download all 224 days in 2018 I was interested in, then merge them all together.

Once the data was in, I did a little processing in R,

  • Converting the vertical narrow Sense data format into a wide time vs. device format and extracting only the Total Usage and Solar Production columns
  • Calculating my Sense net usage (Sense Total Usage + Solar Production, since Solar Production is negative)
  • Calculating the difference (Diff) between PG&E net usage - Sense net usage
  • Calculating the percentage difference (PerDiff) between PG&E net usage - Sense net usage
  • Aggregating the data into daily data so I could also compare that.

An example of wide Sense data below - Note all the NAs (not available) for hours where there was no energy value available in the Sense export for those devices.

Here are the initial results for Sense net usage vs. PG&E net usage in a scatter plot. A high percentage of the data correlates quite well. The slope of the line is almost exactly 1 at both the hourly and daily level. But there are a significant number of outlier data points, especially at the hourly level, where the Sense power values are well below the PG&E values. And based on color, the furthest outliers occurs in March and June. There also seems to be a peculiar upward curving tail in the negative end of the hourly curve. I’ll investigate both of those in depth a little later.


One more look at the accuracy - If I look at a histogram of my net PG&E usage minus Sense net-usage difference, two things become apparent.

  • There’s a long, but very thin “error tail” on the positive side, where the PG&E net is much greater than the Sense net.

  • But huge majority of the differences are within a very narrow band around zero. Based on my histograms, I’m only going to look in detail at the 217 hourly mismatches (out of 5421 total) greater than 200W to start with.

Hourly difference is less than 500W

Hourly difference is less than 200W


Usage Accuracy
Always On Blips
#4

The next thing to do is to compare Sense against the other data source, our hourly feed from SolarCity, showing production from our 4.2kW solar system that uses a 2013 vintage SolarEdge inverter. All the data is going to be negative (energy consumption is positive, production is negative), so this might also give a little more insight into the negative tail of the net usage correlation scatter plots earlier.

My first scatter plot of the hourly solar data, with coloring set to the month was little confusing. The “line” was more of an ellipse. And the coloring really didn’t offer any clues as to why.

But shifting to coloring based on time of day showed a discernible pattern. Sense gave higher readings than SolarCIty in the morning, SolarCity gave higher readings in the afternoon - a systemic error. But why ?

Looking at the aggregated daily data, the ellipse goes away, indicating the the error cancels itself out on a daily basis. Note that I have gone back to coloring by month for the daily plot.

A few things we can see from the daily plot.

  • There is good correlation between Sense solar data and SolarCity, though the slope of the correlation line is slightly less than one. I’m not going to calculate it by regression until I remove erroneous outliers for which I can find a measurement issue, but the slope differential bears out a 4% SolarCity/SolarEdge inverter over-optimism saw with earlier measurements.
  • The hourly measurement ellipse is gone. That indicates there were offsetting measurement differences between Sense and SolarCity, that cancel out when aggregated on a daily basis. I suspect that there is an interval assignment difference between the two measurements of 15-30min. Perhaps the SolarCity measurement is for hour centered around the timestamp, while Sense measurement is for the hour following the timestamp. That would explain the ellipse.
  • We have a number of big hourly differences between SolarCity and Sense, but only a few big relative differences between SolarCity and Sense at a daily level. That means that the big daily mismatches are likely caused by the accumulation of sequential hourly errors.

A quick look at the hourly differences in a histogram show a different view on the ellipse, a typical distribution the width of the ellipse, with a small number of outliers worth investigating.

The daily histogram tells us that we really only need to look closely at a small number of mismatches. The histogram once again highlights the systemic optimism of the SolarCity data - the mode of the distribution is offset bay about 800W from 0.

Now we have looked at direct comparisons between Sense and both “utility” sources. Next, it is time to do some detailed mismatch analysis between Sense and PG&E data.


#5

So now it’s time to figure out the origins of the 217 biggest hourly mismatches between Sense net energy (I’m correcting this from previous entries - I’m really comparing energy, not power) and my PG&E hourly net energy, for the 5,421 exported hours. But how does one dig through that much data to analysis and categorize root causes ? Fortunately there are a couple of easy clues about what to look at more carefully:

  • First, the comparison between solar hourly and daily mismatches hinted that multiple mismatches often occur in the same day. Therefore it makes sense to apply a measure to each mismatch that looks at how many other mismatches occurred in the surrounding 24 hours or so. That measure of locality would probably be helpful in identifying systemic issues that last multiple hours.

  • Second, looking at the 5 largest mismatches (largest Diff) in the sorted list, it’s clear that there is something wrong with Sense’s measurement during these hours - Total Usage is negative ! So we should look at the magnitude of mismatches vs. Sense Usage and Sense solar to see if there is any pattern. What’s more, most of the largest mismatches take place during only 3 different days (table below)

It’s a simple matter to add a calculation to sum the number of mismatches in the surrounding 24 hours. We’ll call that value the number of problem neighbors (ProbNeigh) and plot the results over time.

Time locality of many of mismatches totally jumps out from this chart, though there also appears to be a random dispersion of other mismatches one time. Let’s push more closely into a time region with plenty of grouped issues.

Clearly we’re going to need to look into what happened on April 29th, June 7th, June 10th and June 21st.

But before we look too closely, we should also look for patterns between size of mismatches, Sense Usage and Sense Solar. Here’s that plot:

It should be immediately apparent that there are some problematic Sense measurements here. Sense Solar data should always be zero or negative (or some very small positive value). Sense Total Usage should always be positive. We have 2 quadrants of measurements that violate those rules with the ones in the negative Sense Total Usage and positive Sense Solar containing mismatches of the largest magnitude. What’s happening here ?


#6

Now it’s time for the painstakingly manual part of the process, looking at the the detailed waveforms for each of the mismatches to see what’s actually amiss, starting with the obvious Sense measurement errors I identified earlier.

The good news is that the Sense web app makes this much easier. Once you are logged in, the Sense web app lets you call up a time specific window in the Power Meter via a start and end parameter in the URL. Using this feature, I was able to quickly generate URLs for every 2 hour window surrounding all 217 mismatches. Here’s an example URL that displays the 2 hours surrounding 9pm on the 2nd of Jan in the Power Meter:

https://home.sense.com/meter?end=2018-01-02T20:30:00&start=2018-01-02T18:30:00

So now comes the fun part - actually seeing what mismatches look like. For my Sense environment, I discovered two flavors of measurement errors. The first was the negative Sense Total Usage situation, shown below.

The start of a negative Total Usage hour:

The end of a negative Total Usage hour after a reboot:

For three multi-hour periods on March 7th, April 28-29th and June 7th, my Sense monitor went totally wonky and produced these kinds of waveforms and data, eventually correcting itself or fixed with a reboot. As the earlier graph suggested, this Sense monitor issue was the root case of the 5 largest errors, as well as bunch more smaller ones. The good news is that Sense has updated the monitor firmware to alleviate this bug.

The second flavor of Sense measurement errors first made itself known as I was investigating the cluster of mismatches detected on June 10th. More pedestrian than the negative Sense Total Usage phenomenon, this mismatch stems from simple loss of data, either due to monitor down time or a networking problem extensive enough to prevent full backfill of the data from the Sense monitor buffer.

It turns out that the next batch of mismatches by magnitude, were caused by this kind of data gap occurring late at night when our EVs were charging, like the situation below.

Eventually, after looking carefully at the first 20 or so waveforms, I decided to just muscle my way through all 217 mismatches, categorizing the 2 monitor measurement issues along the way. In the process, I discovered a third flavor of mismatch waveforms - one that looked completely normal. The waveform below is associated with the largest gap that can’t be directly traced to an obvious Sense measurement problem or data gap.

So where did the mismatch come from ? We’ll have to delve a little deeper and more analytically on these, plus look at the PG&E side of the equation as well.

BTW - Quick statistics on the 217 largest hourly mismatches after viewing them all. 36 stemmed from negative Total Usage, 56 tied back to data gaps from the Sense monitor, and 125 look, for all intents and purposes, as completely normal on the Sense side.


#7

Whew ! Now that I’m done labeling all the Sense measurement errors and gap that result in mismatches, I can do some fun stuff. I’m going to try to categorize the 217 mismatches by all the known variables, including # or problem neighbors and whether they are Sense data gap issues.

I decided to use a simple K-Means clustering with 4-6 possible clusters, and tried to adjust the weighting to do two things:

  • Clearly separate mismatches that were Sense monitor related vs. others of unknown origin, so I could focus on the ‘non-gap’ mismatches
  • Create distinct groupings in the “non-gap” part of the mismatches

Without going into all the details and weighting experiments that I did, here are some of results given my strategy.

My clustering cleanly separates mismatches due to Sense monitor problems vs. other errors, and also stratifies by the number of problem neighbors. Note that most Sense monitor errors occurred standalone, or nearly standalone, with no other nearby mismatches.

The clustering approach also stratifies the ‘non-gap’ mismatches by the magnitude of Sense Usage. We’ll see if that is helpful in identifying the root cause. These first and second scatter charts also explain the labeling of the clusters.

One cluster, in cyan, consists solely of both types of Sense monitor issues. The reddish orange are the mismatches that have, by far, the most problematic neighbors. And the olive and lavender have fewer or no neighbors, but are distinguished by whether they are in the high or low end of the usage curve.

Now let’s apply the clusters to more familiar scatter charts.

We saw this one earlier in black and white and wondered about the positive Sense Solar Production and negative Total Usage. Turns out those indeed were all monitor-related data gap errors, as well as others.

Here’s the same type of scatter chart we used to initially look at correlation, except now I’m using it to look at only the mismatches. Two things stand out to me from this chart:

  • I made my dots way too small to really reflect the true size of the mismatches.
  • ‘non-gap’ mismatches are heavily skewed toward the lower end of usage. Probably worthwhile looking at a distribution.

And speaking of distributions, here’s a view of the “density of mismatches” by size.

  • Very few large ones - mismatches rapidly fall off.
  • Virtually all the really large ones are attributable to monitor issues.
  • Probably worthwhile pushing into the next set by size, which are mostly ones with few neighbors but high Total Usage.

Here’s a chart to get everyone thinking. I went back to my graph of the number of problem neighbors (mismatches in the surrounding 24 hours) vs. date for the most mismatch-prone period of time, and overlaid both the cluster coloring plus my best guess at when various firmware upgrades happened. It does look like firmware upgrades may have caused 10 or so of the data gaps in 3-4 different time periods. Other then that, I’m looking for comments on what I should try next.

One more plot looking closely at what mismatches really look like. Hourly Sense and PG&E data overlaid with markers for the different types of mismatches for some of the most mismatch-prone days in June. What’s fascinating is that the accuracy is typically so good that you can’t even see the Sense data line in pink - it’s completely covered by the PG&E data, except in the mismatch zones. Blue dots indicate Sense monitor data gaps, while the rest of markers indicate the type of cluster categorizing that mismatch.

BTW - these monitor issues aren’t all on Sense. I’ve been tinkering with my network for various reasons and have created a few outages on my own. If my Fing network monitor had a deeper event log, I could have overlaid my network tinkering events as well.


#8

Now that I’ve been able to identify some of the real measurements errors, I’m going to strip those hours off and take a look at the earlier plots again, with the known problematic data removed.

Here are the hourly and daily scatter plots, looking much better…

And the same histograms of the difference between Sense and PG&E are predictably much tighter …

Plots between my solar data sources also look better - no visually dramatic outliers.

And a tighter histogram spread:

If I do a linear fitting on both usage and solar, I get adjusted R2s that are very close to 1, meaning a very close linear fit.

The hourly usage comparison has a slope that indicates that Sense is slightly more than 1% optimistic vs. my revenue meter. From this perspective it looks like there are still significant mismatches in the center of the line and a curve in the tail in the negative zone that bear investigating.

The daily solar comparison has a slope that indicates my SolarEdge inverter is slightly more than 3% optimistic vs. my Sense data. Probably worth taking a closer look at SolarCity vs. Sense vs. PG&E during solar production. Unfortunately, there’s not a direct way to compare all three, since I only have net readings from my PG&E meter and SolarCity only offers solar data.


Sense vs. Ecobee
Total kwh accuracy?
Sense ToU Calculator for PG&E
#9

Wow, glad to see people are really digging into this data, and fast.

I’ll throw 1 of mine in the mix, seems fairly basic compared to the processing above, but this has been incredibly helpful in tracking usage and $, as well as impact of any major changes.

I’ve essentially been tracking daily kWh usage manually, and comparing with total degree days (TDD), to trend usage with HVAC. I’ve found that my geothermal heat pump (GTHP) is by far the primary user in cold months, and there is a clear trend between HDD and kWh (and subsequently $/day). The trend, with an R^2 of ~0.9, allows me to accurately predict my daily / monthly bill based on weather forecast and historical/expected TDD.

Also, I made some changes in March, Success Story - Payback in <4 months, the effects of which can be seen in the shift between data sets (red to orange). The general trend follows a similar slope, but shifted down >10kWh / day. That alone brought approximately $45/month savings, with smaller incremental changes on top of that.

In cooling months, the GTHP is much more efficient, and therefore a lower percentage of the total daily use. So, the scatter for May-Sept is a shotgun pattern, without a clear discernible trend. Also, the GTHP usage is intermittent, as the cooling requirements are not only tied to average outside temps, but sunshine/cloud cover, etc. So in general, cooling requirements don’t trend as closely to TDD as heating.

This has been fairly quick to update semi-manually, but I suspect the data export will make all of this tracking nearly automatic.


#10

While this doesn’t really need the raw Sense data to track total kWh / day, that is the easiest way to track this for me. However, the Sense data is most helpful when I want to dig further into any of those days, to better understand consumption outliers. I can quickly see how a few loads of laundry, for example, might throw a day to higher than normal consumption. Or how a -12°F day in January is just plain miserable for both comfort and $$.


#11

From the whole team here at Sense — this thread has been awesome to follow. Keep it coming!


#12

Cool ! What’s your source for heating degree days (HDD) and cooling degree days (CDD) data ? Kind of nice to see the actual ROI from your improvements.


#13

Weather underground has good weekly/monthly summaries, and forecasts, but no longer offers free API.

https://www.degreedays.net/ has historical data, but seems you have to pay for API now as well.

NOAA Offers XML Feeds as well - https://w1.weather.gov/xml/current_obs/seek.php?state=oh&Find=Find


#14

Thanks - I have about a year’s worth of Ecobee and Sense data, but am looking for an authoritative source for local degree days and also for temperatures by the hour for a little fun analysis.


#15

@kevin1- You inspired me to analyze my home data. It’s been a while since I have used EXCEL charting…

I compared my daily electrical consumption with my local power company meter and the internal personal energy monitor called SENSE. I now have almost a year of data stored. My electrical provider is CenterPoint Energy of Texas.

Setup Steps:

  1. I extracted the daily readings from the ‘SENSE V4.0 web version’ for each month in 2018.
  2. I downloaded my power company’s (CenterPoint Energy) meter readings from WWW.SMARTMETERTEXAS.COM
  3. I combined all of the .CSV files into a single Excel file for 2018. (and developed another file for 2017)
  4. I setup my calculations in Excel:
  • kWh (daily) difference = SENSE kWh – Power Company kWh
  • I removed any bad data. (-1.0 < ‘kWh diff’ < 1.0 [between -1 and 1]) If SENSE did not download all of the results for that day, then I excluded that data point. Generally the problem was a loss of my SENSE WiFi connection.
  • % error = kWh (daily) difference / kWh Power Company (daily) * 100
  • And an ‘offset value’ from the average baseline defined later.

Plotting Charts in Excel (Windows 10).

First, I plotted the SENSE values against the Power Company values using a simple graph. This allowed me to determine which days might be bad data. Then I plotted a linear regression. If the slope is 1.00 and the R2 factor is 1.00, then the data points would be a perfect correlation.

Second, I plotted the ‘kWh difference’ values as a Histogram. I was looking for a perfect single bell curve. What I observed was two distinct bell curves indicating two separate trends. My first plot showed a nice bell curve.

I kept reducing the range and discovered two bell curves.

Third, I plotted the ‘kWh difference’ values as a scatter point chart and looked for any trends. Two distinct baselines were observed. (It is hard to see the two dashed lines that show the average baselines on this chart at -0.137 and +0.011)

Fourth, I calculated the average for each baseline, then I calculated the ‘offset’ from the baseline. ‘offset’ = kWh difference - baseline average, I plotted those values in a Histogram, Then I summed all the outliers (values that were not close to the bell curve).

Observations:
On April 23rd, 2018 there was a shift on the offset baseline of 0.148 kWh and has stayed consistently at the new baseline. I explored several possible reasons for the baseline shift.

  1. New monitor software update from SENSE during this time period. (That had not happened.)
  2. Change in power consumption. Warmer weather, more A/C usage. (2017 data did not show a baseline shift when the weather changed.)
  3. Temperature change inside the house. My thought was maybe the SENSE monitor (located inside the house in a climate controlled room) was operating at a different condition. (We keep the same setpoint on our thermostat year-round).
  4. Maybe my home power company meter had been changed out or their meter was at a different operating condition. (No changes were noted.)
  5. On 4/23/2018 I added a TD-69 delay timer relay to my SENSE monitor. At the same time I reworked my CT clamp installation. I used the foam insulation from a ½-inch pipe insulation as a spacer to center my clamps and to position them so that they are 90-degrees perpendicular to the service cable in the breaker panel. When I initially installed the CT clamps (Sept. 2017) they were not at a true perpendicular angle or perfectly centered around the cable. I also taped the CT clamps in closed position, making certain they were completely closed. The new foam insulation ‘spacers’ were not allowing the clamps to remain closed.
  6. My charts indicated that prior to re-positioning my CT clamps, that I could expect a higher number of outlier data points.
    Pre- 4/23/2018: 111 data points with 37 outliers
    Post-4/23/2018: 124 data points with 30 outliers

Recommendations:

  1. Verify your CT clamps are completely closed and at a 90-degree angle to the power (or service) cable when doing your initial installation. Changing the clamp positions may give you a change in the readings.
  2. My SENSE monitor now tracks the same values as the Power Company meter more frequently after making this very minor change. The SENSE unit currently reads an average of +0.011 kWh/day more consumption than my power company meter where previously it read -0.137 kWh/day or less consumption.
  3. SENSE currently tracks the power company meter with an average 0.024 % daily error between the two readings.
  4. It is also possible that the new TD-69 relay is helping to automatically reboot the SENSE unit (and reconnect to the WiFi sooner) after a power outage. Prior to 4/23, I was manually rebooting the SENSE monitor 1.5+ hours after the unit failed to communicate. SENSE text and message “off-line” alarms do not send until the device has been off-line for over an hour.

#16

@Dcdyer,
Totally impressive stuff. You have regained your Excel mastery :slight_smile:
Good push into the bi-modal error distribution and associated analysis. Looks like you are doing great with the squared up CTs ! 0.24% is tight, especially when I think most revenue grade power meters are only guaranteed to be within 2% of actual.


#17

@shanefinn03 – Thank you for the info on weather temperature indexes. You inspired me to review my data.

I analyzed my home HVAC energy usage with the CDD index. I have a two-story house with two electric central HVAC units (with gas-fired heating). We live on the Texas Gulf Coast so we generally are always cooling the house. I did not run a ‘HDD comparison’ because we use gas for heating. I do not have an ECOBEE type of thermostat that allows me to gather any daily information on runtimes.

“Cooling degree days”, or “CDD”, are a measure of how much (in degrees), and for how long (in days), outside air temperature was higher than a specific base temperature. They are used for calculations relating to the energy consumption required to cool buildings. Quoted from: https://www.degreedays.net/

Setup Steps:

  1. I extracted the daily readings from the ‘SENSE V4.0 web version’
    from 9/14/2017 through 8/27/2018.
  2. I downloaded my local weather readings using 75 degF as the baseline for CDD from https://www.degreedays.net/
  3. I combined all of the .CSV files into a single Excel file for 2017 and 2018.
  4. I setup my calculations in Excel:
  • Total KWh/day = AC1 + AC2 (I only have the compressor wattage readings from SENSE. SENSE has not discovered my blower fan motors for each HVAC unit.)
  • I did not remove any bad data. I attempted to delete bad data and found the same correlation and trend.

Plotting Charts in Excel (Windows 10):

First, I plotted the SENSE values against the CDD values using a simple scatter graph. This allowed me to determine which days might be bad data. Then I plotted a linear regression.

Second, I also deleted what appeared to be bad data points and plotted a second chart.

If the R2 factor is 1.00, then the data points would be a perfect correlation. I am only posting the first chart showing ‘all data for all days’.

Observations:

Both charts had similar slopes and R2 values. There is a large scattering of data points away from the baseline. My correlation value (R2) was 0.835 I am not certain that I can find a 100% direct correlation between the outside temperature (CDD) and the amount of energy that is used to cool our house. I think our home energy usage for cooling the house is based upon several factors:

  • Outside temperature.
  • How humid is it outside / inside.
  • The amount of stove top or oven cooking occurring.
  • The number of times we enter or exit the house on a daily basis.
  • The amount of laundry done for that day.
  • Our personal preference for the thermostat set-point on that day.
  • Whether we have family or guests visiting.

What I did notice is that ‘shanefinn3 R2 values’ were similar to my R2 values. I would be interested to see a similar type of charting that anyone has created and hear their thoughts.


#18

@shanefinn03, @Dcdyer, @kevin1, @RyanAtSense,
I have a couple apps that utilizes openweathermap.org for temperatures.
Can any if you peek at this? It would be interesting to know which source appears to be the most powerful for when I can get back to developing.


#19

@MachoDrone,
I’m more about the data and less about the code. So I would be likely to use Dcdyer’s other link, https://www.degreedays.net, to bring in weather data from the most local weather station. It looks like it gives what’s needed straight off the shelf.


#20

@dcdyer, I just wanted to say, your analysis brings back my statistics studies in college. But your post makes my statistics work look like Kindergarten sandbox stuff.

Impressive!

just saying…