New Rule Breaking Itself, I Think It's an Adolescent

So I have created a rule which insists on not listening to itself. But allow me to give you a to of context which is probably unnecessary

I run a Smartthings v3 hub, heavy user of Tasker (albeit at a very shallow level), IFTTT, Join, and SharpTools. I have two Nest v2 which are like the rich kids in a neighborhood and don’t play well with others. I also have an Ecobee4 with Alexa baked in, the latter of which I rarely use because she insists on a very rigid lexicon & vernacular which is annoying (yes, I am aware of and at some point will configure AutoVoice w/ Natural Language).

So my issue is related to the Ecobee and a rule I wrote which I thought was pretty simple. So I have a wood burning stove in the finished basement of my house to save money in the winter. The Ecobee4, as some may be aware, has a remote sensor which talks to the thermostat, and enables it to provide a more ‘balanced’ HVAC experience. My remote sensor is located in the same room where in 8 out of 12 months of every year does what is supposed to.

As you can imagine, Ecobee had no provisions for a wood stove preprogrammed into its system, but of course, this matters not to the likes of this community. It does allow for users to create their own “Comfort Settings” but a coming in the native software (which I’ve communicated to the company) doesn’t allow for one to simply override the scheduled program which is currently running. Instead, after creating this custom Comfort profile, a user must then go in and amend the schedule in order for the system to run according to the custom settings.

So again, amongst this community, this is viewed as a Glorious Challenge. My custom Comfort profile called “Wood Stove”, and tells the Ecobee to only run the fan 100% (to circulate the warm air to the upstairs), and disregard the remote sensor’s temp indications (which is in the same room as the stove and can get up to the high 80° F range). Which brings me FINALLY to my failing rule.

So a wood stove is great, but if the fire burns too low or too high, it’s inefficient and bad. I won’t get into why a habitually low fire is more dangerous than what is called an ‘Over Fire’, but in my particular situation, I’m more likely to have an Over Fire condition. So I setup my new SharpTools rule to assist.

First, I need to make sure I say that whilst I have programmed the Ecobee to ignore the remote sensor temp indications, it still reports the temp, which is recorded by all systems integrated with the Ecobee (Smartthings Hub, SharpTools, Google Home, Tasker, IFTTT, etc.).

So I’ve set a rule in SharpTools to text me whenever the Ecobee remote sensor is indicating a temperature at or above 90° F. Seems simple enough, right? Well, I thought so too, but SharpTools is WAYYYYY too excited about it, and ended up triggering on that rule at least 3 times a day, regardless of the remote sensor indications. I had to delete it, but have attached some screenshots to see if you guys can see something that I’m screwing up.

Sorry for the novel, but I’m not sure if those details could be key to troubleshooting. Let me know if you see something I’m screwing up.

Thanks for the message and sorry that the rule isn’t working as expected! :open_mouth:

You indicated that the rule is triggering ‘regardless of the remote sensor indications’ and in your screenshot, the circled sensor was only reporting 63°. Am I reading correctly that it seems like the condition of greater than or equal to '90' is the part that doesn’t seem to be working as expected?

Have you checked through the device history in the SmartThings Classic app (or SmartThings IDE) to verify that the device hasn’t reported an odd value?

Note that once the temperature goes above 90° in this particular rule, each time the Ecobee reports in another temperature event above 90°, it will be considered another event and trigger another run of the rule flow.

Hey Josh:

Thanks for the quick reply. So I checked the ST Events List and it’s all below, mostly in the 70’s. As far as the reminder every change, that’s ok, and intended to get my intention. If it get’s that warm down there, it needs to be dealt with, and if I deal with it properly it’ll cool down quickly.

All your other interpretations are spot on.


Hi Pete,
Thanks for the updated info. I have located the bug in event trigger, and implemented the fix. Will do further tests and review tomorrow, and push the hotfix to production soon. :slight_smile:

1 Like

Rock on! That’s what I call some true Bad-assery IT support! Seriously, you guys obviously have a tremendous amount of emotional investment in SharpTools, because I’m pretty sure revenue motivation doesn’t even move that fast.

So as a budding (as in the plant is barely even poking out of the dirt) programmer (Java, Groovy), any chance you could show me what was causing the bug? I probably won’t understand it, but I’m just curious.



1 Like

Pete, it was just a small logic bug that we missed, and not related to any programming technique/language. But the good thing is we always implement unit test code for the bug founded to make sure we don’t step into the same issue again, which is important when the project scales, like Rule Engine. It can be complex when adding new features while making sure it doesn’t break other stuff. :smiley:

Edit: The fix has been released to production, so please go ahead to try it out if the issue has been fixed for you. Thanks.

1 Like