This won't do what you are asking, but is it really a problem if the space heater is turned off when it is already off? As long as your temperature reports aren't frequent, I'd just ignore that. You could always make turning it off conditional on it being on, or track some Boolean that tells you in which direction you've crossed the threshold.
Sending a redundant command (switch off when Space Heater is already off) isn't really an issue. After noticing (in the logs) the constant requests once the temp raises and stays above 72, I was really just trying to reduce calls. Everything was running fine anyway... so the real problem may be that I can't stop tinkering with rule logic. 
Yeah, I know. It just looks wrong. As mentioned, you could say, "If heater is on, turn it off", although it could be the driver does that optimization anyway.
Re the constant requests, if you want to make things neat and clean, I'd tinker with the frequency of the temperature reports if possible. You probably would stay just as warm and cozy if the temp report was every 3-4 minutes rather than every 10 seconds, for example.
You can add a condition for the heater to be on. This way it will not send the off command again.
For my own learning purposes. Can someone explain how this will work? The way I read it is that the trigger will never happen as the required expression is false. If the temp hits 72, the trigger point, the required expression will be false and therefore will not trigger, right?
I think you are correct that the rule will never trigger (and I have since removed the required expression). Thanks, everyone, for the suggested alternatives - I'm looking into both the polling on the temp monitor and a boolean on the switch.
I had noticed that the Rule 5.1 documentation states that you can "use a required expression to restrict triggering when a certain expression is not true (if the expression is not true at the moment just before the trigger event happens, the rule will not trigger)." The example use case is to trigger a rule only when changing from a specific mode to another.
I was hoping I could use a required expression to replicate the "on transition only" feature in SharpTools, which triggers only "when the value changes to your desired state." The developer explains:
This is helpful for situations where you only want the rule to trigger when a value ‘rises above’, ‘drops below’ or ‘changes from’ a specific value. This means that your rule will only be activated when the configured trigger initially transitions to true… and will only reactivate once the trigger leaves the configured state and re-enters it.
But changing from (Hubitat's required expression) and changing to (SharpTools' on transition only) aren't the same thing 
and so my rule config didn't work.
Change your required expression to include your temperature requirement and for the space heater to be on.
It should actually work as the OP expects, due to the order in which triggers and required expressions are evaluated. There have been many posts about this as the behaviour seems counterintuitive at first.
If you want to verify the behaviour for yourself, create a virtual temperature device and use it to trigger the rule with logging enabled, and watch the logs for the rule as you change the temperature on the virtual device.
It's false now (well, when the screenshot was taken) because the temperature is >= 72. That's actually exactly what the OP wants: it will prevent the rule from triggering when this is the case. On the other hand, when below 72, the expression will be true, allowing the rule to trigger -- once (until the temperature again goes below), also exactly what is desired.
This rule should work as intended, in other words. This very kind of specific transition is one of the use cases this feature was added for, as the OP also found in the docs. This is essentially the same as the mode example, just a different event.
To the OP: you might consider making the threshold a bit wider if you have the "on" half of this automated too (though there's no reason to think that from what you have written), have a fairly sensitive or chatty sensor that might frequently report events on both sides of this threshold, and wish to avoid this possibility. But, of course, that depends on what you really want.
This is how I would do it if it were me using private boolean to prevent it from running again until the switch turns back on, the temperature drops below the threshold, or 30 minutes has elapsed. Adding the switch to the required expression also prevents it from checking if the switch isn't already on.
I'm not following. The Required Expression and the Trigger Event are testing the same value in this case. When the event triggers, the required expression is checked. But the temperature at the time of the trigger can never meet the Required Expression (< 72.0) and what triggered it (>= 72.0) at the same time.
Doesn't Required Expression get evaluation upon the trigger event only? That is, a change in the truth of the required expression is not a trigger. But a trigger is required for the Required Expression to be considered.
Yes and no
In general, the required expression gets evaluated upon receiving events for which it is subscribed. Same for triggers. This is a special case where both required expression and trigger depend upon the same event, and therefore order of evaluation matters.
It so happens that the trigger evaluates before the required expression for the same event, therefore in this case at 72 the rule will trigger and shortly after the required expression will turn false and drop all trigger subscriptions. When the required expression is false, there is no ambiguity: only the required expression is subscribed, and triggers will be re-subscribed only after it turns true.
@bertabcd1234 might know more about it, but I see it as a design choice, and a good one IMO, as it allows representing these "edge-triggered" use-cases simply.
I appreciate that explanation. If I'm understanding correctly, the special case of the required expression and trigger being the same, the logic is that the required expression was true at the instance of time just before the trigger event occurred. That is, the trigger event notwithstanding, the required expression was true when it .. well .. started to occur.
So I get it. It also helps to read Bruce's explanation here:
Not quite. Think of it like the docs say: the value of the required expression at the moment just before triggering (i.e., any change that might happen as a result of the trigger event won't yet matter). So if the temperature 71, the required expression will be true. If it becomes 73, the rule will trigger. Then the required expression will become false, and it won't be eligible for triggering until the required expression is again true.
The use @hubitrep mentioned is one of the reasons this feature was introduced, capturing specific state changes (in this case, below and above a threshold; in the docs example, one specific mode to another -- that would never work if evaluation worked differently).
Well, I should have looked more closely at the logs. It does seem to work as intended:
10:58:49.965 am info Event: Office Environment temperature 74.20
10:42:33.018 am info Event: Office Environment temperature 73.40
9:42:33.968 am info Event: Office Environment temperature 73.37
9:33:06.120 am info Event: Office Environment temperature 73.22
8:48:18.268 am info Required Expression now false
8:48:18.203 am info Action: Off: Space Heater
8:48:18.198 am info Triggered: Temperature of Office Environment(72.24) reported >= 72.0
8:48:18.195 am info Event: Office Environment temperature 72.24
8:42:36.594 am info Event: Office Environment temperature 70.97
7:42:38.688 am info Event: Office Environment temperature 70.99
6:42:41.221 am info Event: Office Environment temperature 70.87
5:42:43.790 am info Event: Office Environment temperature 70.67
Just following up here to confirm that the rule as illustrated in the original post is indeed working as expected.
I've also adapted it to other rules - all temperature based. Required Expressions are handy in a few different ways (e.g. Modes), but they seem especially useful whenever a temp threshold is invovled in the rule's logic - even though it's not really immediately obvious (or at least wasn't to me). I wonder if including an example in the docs would help Hubitatians get more mileage out of them.
