As a follow up, I do not have an ETA, but resolution for this has forward momentum. If it happens on other accounts it is just being missed or glanced over. It is not acute enough of an issue it seems to get a lot of people reporting it.
However, the basic error of the rule was identified. I would assume a few weeks before an ETA for resolution. Then again, given the type of error it is, it may just be fixed before an ETA is set.
However, the basic error of the rule was identified. I would assume a few weeks before an ETA for resolution. Then again, given the type of error it is, it may just be fixed before an ETA is set.
please share details of the “identified basic error of the rule” what is the error?
thanks
please share details of the “identified basic error”
There aren’t really details. The emPower individuals I’ve spoken to are in agreement with our observations based on their own continued testing.
It is something where it may be easy to assume what is the issue when looking at a single account, and easy to spur investigation, but it has to be tested across many, proven, and submitted for a fix. (This has occurred)
As an update:
I spoke to a rep working on this issue who is pushing for a change to the rule.
It sounds like a change won’t be available until next season.
Good news:
It is being addressed differently. After looking at the rule and discussing and going over fixes/etc., ADC is looking to overhaul the rule to better follow forecast temps as they change and instead of just overriding for a 10 hour or so period PM to AM roughly when the low temp would occur, it will take into account when that low is projected to occur, and when that below threshold temp is expected to resolve to control the rule (so that if the below threshold won’t last long, the override is less, but if the below threshold is to last longer, it will lengthen the override to match)
I still would like an explanation of how the bug affects some, and not others.
I think the issue is in fact universal personally. I think the rule is just not used enough and doesn’t apply to an acute event or time-frame so unless you are actively looking for it to occur it is easy to miss.
The testing was done when below temp threshold may have occurred two days in a row for some, skewing results.
The issue is I’m sure precisely what it seems. A misapplication of the override due to the designer misunderstanding forecasts.
Instead of just tackling it with a bandage, the reps I’ve spoken to want to take the opportunity to revamp it into something with more benefit.
Then if that is the case, it is probably based on the NWS date as shown (e.g., “SAT 55/14” really means SAT high of 55, and SAT/SUN overnight low of 14…not early morning SAT (FRI/SAT overnight) low of 14).
I have been saying this all along. It isn’t brain surgery. The fix should be easy…code the rule to trigger overnight event 24 hours later.
All they have to do is program the overnights to occur 24 hours following the temp event.
This is probably true, but then it may become more difficult to press for an improved version. Considering we are nearing the end of the winter season, they’ve decided it makes better sense to overhaul while it needs addressed. I’d agree.
As it stands, if the rule activated as expected, it would turn on the evening prior, end late the following morning.
The true forecast low temperature is definitely within that timeframe, but is more likely near the tail end, near sunrise. That low temp below what you have set as the low end in the rule may continue through the next afternoon, but the rule would no longer apply.
They want to make it a more dynamic function to account for these things.
As it stands, if the rule activated as expected, it would turn on the evening prior, end late the following morning. The true forecast low temperature is definitely within that timeframe, but is more likely near the tail end, near sunrise
Yes. Agree.
Any status update on a fix for this?
I was told in the most recent update that they are pushing it for an overhaul by next winter season.