tstat extreme temp energy saving rule bug

Noticed that the extreme temp rule is a bit off.

For example, yesterday’s (sun) temps were forecast for 48/24. (the 24° low being 9pm Sun through 9am Mon morning). So the extreme temp rule kicks in Saturday evening when the actual overnight temps are in the 30°- 40° range (well above extreme temps), and remains in effect throughout the day till yesterday (Sun) evening (where day time temps were near 50°).

Then yesterday (Sun) evening, (just prior to the actual overnight Sun/Mon extreme temp of 24°, that it was supposed to be offset for), the tstat turns off the extreme temp rule, and returns to normal set point.

The rule is practically useless.

e.g., extreme temp is set for below 20°, Tuesday forecast is “36/18” 9pm Tues/9am Wed overnight is forecast for 18°, so extreme temp rule kicks in on Monday evening, and turns off Tuesday evening (which is prior to forecasted Tues/Wed extreme overnight low).

The problem is, that the algorithm (or whatever ADC is using) is not taking into account the following days weather for the rules is actually spanning the two following days as the low is from the following day at 9pm to the day after that at 9am.

It apparently is only taking into account the hours between 9pm - 11:59pm, when the forecasted “low” is actually occurring early the following morning.

Can Surety shoot this to ADC?

I would really like to be able to use the extreme temp rule for night lows as well as for days (9am to 9pm?)

The expected function and history on this account is being verified with Alarm.com.

For whatever reason, the tstat went back from extreme setback (65°) set point to normal set point (68°) on it’s own around 4:51pm (yesterday).

And as previously noted, the actual extreme temp event occurred early morning today 11/23 ( forecast for Sunday overnight 22/23). Approx. 12 hours or so after the extreme temp setback restored to normal set point.

I suspect the way it is being used by ADC is that the low of say 25° is not the upcoming night forecast used for rule based automation for the period starting tonight at 9pm till tomorrow at 9am or so, but the overnight temp low that has already occurred.(low this morning of 25°, not low tomorrow morning of 25°).

This makes sense, and would explain why the extreme temp setback occurred a day early. The forecast may be very well be for the upcoming overnight low, by ADC is using it for the current day’s lows (which would actually be the previous days over night low, since the overnight low actually spans two days).

Bug.

The expected function and history on this account is being verified with Alarm.com.

Why? I do not think this is particular to just one account.

This is a problem across the board for all accounts. It is simple to reproduce.

In a nutshell, the extreme temp rule kicks in on all ADC accounts using it the day before the forecasted extreme weather event, in the evening, right?

That works fine for events that occur during the day (9am to 9pm) , the problem occurs with the nighttime low temp events as they run 9pm to 9am the following morning… hence the issue.

Instead of rule kicking in 9pm or so the previous day to the event, perhaps it should kick in 9am the day of the event if the trigger for the event is a night time low, and 9pm prior to the trigger event if the low is day time.

The way I see it, you can’t use the same trigger time frame for extreme high or extreme low for both day and night events because of the way the night time temp forecast spans two days as opposed to the day time forecast only spanning the one day.

I think I figured it out, so for the sake of simplicity, this is what I think is occurring.

The weather forecast for overnight lows (today for example) is 25° with day time lows of 41°. The question is… is that low for tonight (Mon night/Tue morning), or was it the Low from this morning between say midnight and 9am?

I think ADC is going with the later. It is using the forecasted low for the particular day (after midnight), and not for the upcoming overnight evening (after 9pm).

Sunday’s (Nov 22) Temp: 48/24

(the low of 24° was not the Sun/Mon overnight as far as ADC was concerned, but the Sun early morning after midnight low), hence the extreme temp setback at 3am on Sun morning, and restoral Sun afternoon at 4pm)

I’ve been looking into this myself. Trying to confirm basically what you stated. I’m about 99% sure that the NWS reports a low as the temp that date through the following morning. I was pretty certain that is how the rule functioned through Alarm.com. I’ve not noticed a discrepancy before. Perhaps a change occurred.

Edited last post

about 99% sure that the NWS reports a low as the temp that date through the following morning

I think you are correct, the problem is ADC isnt using it that way… hence the “bug”

This would explain why the Sun 11/22 forecast was 48/24 and it triggered the ADC extreme temp rule (which was set for 3° if temp lower than 25°),and early this morning temps were in the lower 20’s.

But instead the rule triggered extreme setback for early yesterday (Sun) morning where temps were in the 30’s (Sat 11/21 forecast was something like 49/35).

The Saturday forecast is helpful.

When you say this:

This is a problem across the board for all accounts. It is simple to reproduce.

Do you know of other people who are reporting this? The stated function through Alarm.com is shifted one hour from NWS, but it is indeed 10am-10pm for high that day, 10pm-10am for low through the following day. (NWS uses 9-9 I think, but same thing)

Sunday morning should be affected only by Saturday’s forecast, in other words.

Well Sundays overnight low triggered the extreme temp rule, so it should have setback tstat after midnight this morning, but it did it yesterday morning when the overnight temp exceeded the rule threshold.

So something went wrong.

I am going to do a test and see when the extreme temp setback occurs.

According to the forecast, it should kick in early Wednesday morning (Tues/Wed overnight approx. 3am). If it instead kicks in the extreme temp rule tonight/early tomorrow morning, we will know ADC is not using the NWS temp date through the following morning like it should be. Lets see.

I’ll try this on mine as well.

If it is gonna trigger early morning, I should receive the alert this evening or so

Something like this in notifications:

Thermostat Extreme Temp Event (Overnight) 9:45 pm

Well, it definitely triggers too early. NWS Extreme weather is for Sat-Sun overnight (12/19 - 12/20), but the ADC rule triggered event for Friday/Sat overnight (12/18 - 12/19).

Fri/Sat (12/18-12/9) overnight lows are 28F (where 24F is the extreme threshold rule trigger).

The ADC rule/algorithm is unable to distinguish that the NWS forecasted overnight is actually for the following day (that SAT overnight low is actually spanning through SUN early morning, and should therefore kick in the day of the actual forecasted extreme temp event, e.g., in this case, Sat around 9 pm, not Friday at 9pm). It apparently sees it literally as the overnight low for that DAY, and so triggers the rule the evening/night before, and that is not how it should work. it is off by a 24 hour period.

ADC needs to adjust it so it actually kicks in the evening of the projected NWS low that is used as the trigger for rule event. (for example, if THURS is 54/20, then it kicks in overnight rule THURS evening at 9pm through FRI evening at 9pm where it then restores thermostat).

For anyone using this rule, you may want to disable it until it can be fixed, as it isn’t working like it is supposed to.

The primary purpose of this rule is to save energy and cost by lowering/raising the tstat on those days configured for extreme temps, since it is kicking in for a period prior to the event, then restoring to normal on the actual extreme event it is essentially a useless rule that is wasting energy and costing you more as it is actually increasing the temperature on a day where it should be lowering it (returning to normal temp from setback on an extremely cold day).

We’ve forwarded your description of the issue to Alarm.com and requested they test this as well.

As a follow up, this is not known to be affecting accounts widespread, at least at the moment, and Alarm.com is requesting the feature be re-enabled so that they can track the next time it fires. Haven’t been able to replicate it myself. Can you re-enable it for a degree point that can be tested soon and just make the degree change 1 degree?

I can say that mine appears to be working OK. We had a low temp forecast last week and the energy save kicked in at the appropriate time, e.g. overnight, as far as I can tell.

I’ll try to keep an eye on that but truth be told we hardly ever reach the threshold in the winter. Summer is another deal altogether as I have the high temp threshold set to 110F and we hit that numerous times. I know it worked over the summer quite well but that’s not relevant if anything changed recently at ADC.

Still doesn’t work properly, and kicks in the overnight extreme temp setback a day early… (1/3 @ 9:46pm where Sun/Mon overnight temp is forecasted for 26°). Extreme temp setback should have kicked in at approx. 9pm on 1/4 for Mon/Tues overnight low of 15°. (extreme temp setting is for below 20°)

Temp/overnight low for 1/3 (Sun/Mon) which is near forcasted:

Thank you, this is a really good example. Following up with ADC on this today.