I tend to look for outside-the-box solutions to problems. It sounds like you do have some control over the heating. Is there a way you can stagger the updates to the individual Items a little using a Thread::sleep or wait (if it is a shell script) or something like that? You don’t really have control over the Unifi binding but you do for the other.
What happens if you add a Thread::sleep(100) just before the findFirst lines for the Unifi binding Rule? If the problem is related to the Group updating in the background while the Rule is running, the sleep should give that enough time to finish before the Rule runs. It will add some latency (up to 600 msecs) to when the updates occur and when the rules execute for the last set of Items in the 30 temp updates case (only five can run at a given time).
On second thought that probably won’t work.
What if you deploy Design Pattern: Gate Keeper for that Rule? This will make the latency be even longer but what it will let us do is add a sleep after updating the member of gDiffTemp Items to give gDiffTemp a change to settle before the next Rule instance is run. You don’t need a proxy Item like described in the DP, just keep the same Rule trigger.