I'm not sure why you have the motion sensors as part of your trigger?
I'd try something like this:
Trigger:
Front door, back door any *changed*
actions:
IF Front Door, Back Door any open THEN
Delay 0:05:00 (cancel)
IF Front Door, Back Door any open THEN
turn thermostat off
speak message
END-IF
END-IF
The way I built the rule I didn't think it really needed the cancel delayed actions.
If either door is opened, it's going to wait for 5 minutes and then check if either door is still open. If either door is still open, then it will turn the thermostat off and speak the message. If neither door is open, it does nothing, so there's nothing really to cancel. You could cancel the delay, but it's not really necessary.
You could do it like this if you really wanted to cancel the delay:
Trigger:
Front door, back door any *changed*
actions:
IF Front Door, Back Door any open THEN
Delay 0:05:00 (cancel)
IF Front Door, Back Door any open THEN
turn thermostat off
speak message
END-IF
ELSE
Cancel delayed actions
END-IF
Note that, although the final END-IF is technically optional, it's always best practice to pair IF with END-IF, REPEAT with END-REP, etc. That way it's really clear how the rule is expected to work.
I like the second rule you posted better with the cancel. There is a difference in behavior between the two, and the first (without the cancel) is likely to cause unexpected results in some cases. Consider the following:
Front door opens at 8:00:00 (and 5-minute delay starts)
Front door closes at 8:01:00 (nothing happens in rule)
Front door opens at 8:04:59 (a new 5-minute delay starts)
At 8:05:00, the first delay expires. Because the front door is open (or the back--it wouldn't matter), the thermostat gets turned off and a message gets spoken, even though it has been open for only one second.
With the "Cancel Delayed Actions" version, you avoid this likely undesired outcome--this is the difference between checking whether a door is open 5 minutes after it (or any) was opened (possibly closed in the meantime and reopened) versus checking if a door stays open for 5 minutes.
For the OP's rule, the (second rule) above should help; your rule likely gave multiple notifications because of the extra trigger, so any time any of the motion sensors sent an "active" event, your rule actions ran. If the conditions for the IF were met (any contact open and Ecobee in heat mode), it would spawn a new instance of the rule, so if a contact sensor remained open the entire 5 minutes (or more), you'd have a queue of delayed actions pent up for each "active" event from each sensor--likely not what you want. You could also simplify your coding a bit: the ELSE with a nested IF inside is equivalent to an ELSE-IF. It should work as is, though it would be good practice to include the last END-IF you're technically missing (but if you switch to an ELSE-IF you'll only need the one END-IF that you already have, albeit one level out, which it should automatically adjust to).
What contact sensor are you using? A few have been known to report multiple events in a row. Some have had driver updates to "fix" this. You can see if that is what's happening here by looking at live or past logs or the device events/history page. This could explain multiple events within a second or two of each other. If something is really happening minutes later without a change, I'm not sure what that could be. The former could likely be easily worked around in a rule (unless there's a way for the device or driver to stop this in the first place, in which case you wouldn't need to).
You're right. I think what is happening is the door is been opened closed and opened within a minute sometimes and that is when this rule is firing twice. As i have the rule to if changed.
maybe as the action only needs to trigger when it's open only i should make the trigger open then only wait for the close as the else?
the contact sensor is a smartsense smartthings one. it's the multi sensor
OK, so that's probably not what I was thinking--a few Z-Wave sensors have been known to relay the same information in a couple different ways within a few milliseconds of the event, and some drivers read and report both. I haven't seen this with any Zigbee device, but I've also never used the ST Multi for open/close, so I don't really know, but it seems unlikely.
Your trigger is "changed" (Rule 4.0, perhaps ironically, actually doesn't have the discrete concept of "rule" anymore), but you need it that way: the IF catches when any are open, the ELSE catches when all are closed, which you need to cancel the delay from them being opened. I could see the thermostat-off and speak actions running before one particular door has been open for 5 minutes if there was never a period in between when all were closed (the only time your "Cancel Delayed Actions" action would run: the opposite of "any open" is "all closed"), so if that's happening, it could explain the problem. If that's something that matters, I can think of a couple ways to work around this issue, though the most elegant might be just to make two rules, one for each door.