This is one of the differences between WebCoRE and SharpTools. With SharpTools, you specify which events you want to trigger the rule in the Triggers section.
I didn’t use WebCoRE, but from what I gather, it’s loosely equivalent to your IF lines with lightning bolts next to them.
So if you want the rule to be triggered by the switches changing (or time events), you would want to add those to the Triggers section.
@BeardedTechGuy put together a nice video for WebCoRE users transitioning to SharpTools Rules with some of the things he learned / experienced:
It doesn’t look like your new SharpTools Rule Flow mirrors your WebCoRE rule.
Your new SharpTools rule is using the ELSE path for the first IF Condition (which you weren’t doing in WebCoRE) and is always turning on the switches in that case.
Furthermore, the IF condition is doing the same thing as it’s ALL of the listed conditions in the block that must be matched… the order of the conditions and them being near each other doesn’t impact anything. So you have two date related conditions, but those aren’t going to be paired up with the time condition near them. Instead ALL of the conditions will be evaluated and combined in your current layout.
It might be helpful to describe in words what you’re trying to accomplish though, so we can better point you in the right direction.
For example, some people find it easier to use the new Expressions feature to create complex compound conditions where they need to compare multiple subsets of conditions together.
Please don’t do this. Without delays in a rule, that would cause an infinite loop and would hit rate limits.
In this particular case, since you’re using a ‘state stays’ condition on the mode rather than just the mode changing, it won’t retrigger the rule if the mode gets changed to the same value again.