Is there a way to write a rule that will pick this up? This is in the rule logs.
IF condition logic check failed on:
What do you mean pick it up? Is the IF Condition consistently failing or what’s happening?
More details would be helpful.
By “Pick Up” I mean is there a way to write a rule that will identify this condition from my logs?
The problem was with a virtual switch that has not been used since last fall. Recreating the switch and reauthorizing resolved the issue.
Had I known the virtual switch was causing this condition, I could have figured out my issue much quicker today.
Im not getting anymore failures within the logs, but… Ive never seen this triangle and spinning circle in the rule before. What is it? The rule appears to be working properly.
On a desktop device, you should be able to hover your mouse over the triangle to see the details of the warning.
It usually means that something with the rule post-processing failed. Your example rule seems to be triggered by device and variable events with no timer / delay scheduling type features nor any HTTP Triggers, so there might not have been any meaningful impact if it was one of the post-processing steps related to those features that encountered an issue (since you don’t use them in that rule).
Im wondering… because this sets the cooling set point on an Ecobee thermostat, is it waiting for confirmation from Ecobee that the change has occured, like when a switch gets confirmation that it is ON, or OFF?
Since Ecobee dosen’t respond or update more frequently than 10 or 15 minutes, could the rule be waiting for this?
Apologies, but I’m not sure what you’re talking about at this point. Something different than the 2 items mentioned above?
Keep in mind that the rules are interacting directly with your connected smart home hub. So each action or condition takes as much time as SmartThings takes to respond to the API request behind the scenes.
And the rule post-processing when you save is mostly an internal process for the items I mentioned above (timers / delays / http triggers) as well as setting up event subscriptions for the ‘trigger’ devices if those event subscriptions don’t already exist. So the post-processing is only talking to your smart home hub if it needs to setup a new event subscription (or remove an unused one).