Firstly, my apologies for not recognising your handle sooner, and thanks again for cocohue. I have a number of switches working with my Hue bridge and itās much better to see and be able to control them within the integration.
I didnāt want to go into too much detail about my set-up as it is highly unusual. I am in the north of the U.K. where we have electric heating using āstorage radiatorsā (lumps of metal housing heat retaining bricks). Electricity suppliers provide power to these at certain times of day (their choice) and the supply is turned on/off by them. I have heaters in several rooms and I want to be able to turn the power supply off when individual rooms are warm enough (monitored with a temp sensor in each room). āWarm enoughā differs for each room and time of day (and also when I am away).
We currently have this control automated with an old Vera controller and it involved writing a lot of lua code. I was hoping that Hubitat might be a bit simpler. I shall be looking at webCoRE now.
Thanks for your advice.
It seems to me like you need to write your first rule in Rule Machine and then clone it multiple times? Is this the case?
There are community-developed apps that can combine a switch and temperature sensor into a virtual thermostat device.
That might allow you to make use of more purpose-built apps like thermostat controller or thermostat scheduler?
Thanks, but I wouldnāt have posted originally if that was what I wanted to do. If anything changes I would have to make the same update in numerous copies of a rule. To me that is crazy, and very likely to end up with differences that are hard to track down. I just want one rule. 
I looked at one of those. The idea is good, but I would have to rewrite a lot of the code to make it fit my scenario. I only got the Hubitat last week so it would be a very steep learning curve! I am beginning to think that it would be the nice solution, but Iām disappointed. We ended up having to do that on our old Vera box and there were so many glowing reviews from people moving to hubitat that I thought it would be simpler.
I make some rules that are basically just "routines" that are things that commonly get called by other rules. These rules are basically just lists of actions and many of them don't even have a trigger. These would be groups of actions that I want to perform often enough, or get activated thru many different means, but I don't want to bother having so many actions in all those rules. So instead of including all those actions over and over again in many rules, I just say "Run rules actions from _______"
For example, I have many "arrival" rules that fire depending on who's arriving and at what time. But at the end of all of them, I need to reset everything, so I have a rule called "Arrival Model End" which resets a bunch of switches or variables and stops timers. The last action in all the individual arrival routines is "Run rule actions: Arrival Model End" to save me from putting the same list of rules on each individual automation.
I hope that makes some sense, I'm not fully awake yet.
I am still not sure what you are looking to do after reading this thread multiple times. You are asking for conflicting things here regarding simplicity vs having only one rule. There has been lots of good advice here regarding rules and how to handle heating devices.
As far as the documentation, what does it matter if you are turning on a light, or turning on a heater? The same basic logic applies, IF this (condition), do ABC, ELSE (condition) do XYZ.
One piece of advice nearly everyone says, including the staff who wrote these apps, is to keep things simple. Two simpler rules are better than one complicated one in nearly every case. The complicated rules are harder to write, harder to troubleshoot, and are often just unnecessary.
People let their OCD get in the way of just writing one rule for every device and moving on with life. Once you write a rule, it is pretty easy to edit it if for some reason things change.
If you need a more regular change like for the seasons, just clone the rule and limit each one to a particular season or dates on the calendar. I have quite a few rules that only run in the Summer and limited hours (for fans) but I could quite easily clone those rules and do slightly different logic (lower speed, different times) for Winter.
How are your heaters controled now? Are they simply switches?
With the amount of dynamic stuff in the request it seems, though several rules, the easiest method would be a rule written for each room
Otherwise I think you would need a written smart app with the logic in place in child apps. One install per room so you can set your values for each. Then anytime the logic is updated in the child app it immediately hits them all.
Who is to say you will want the exact same logic when this is all done.
Iām a great believer in KISS. Having multiple copies doing exactly the same thing is not simple. Itās what subroutines were made for. I will just agree to differ with you. Itās not OCD. Rewriting (or cloning) something just to change maybe one parameter leads to bloated software and a need for unnecessary amounts of memory/storage space.
Letās just agree to disagree.
I will agree that I have had some good advice on here
Now they are controlled by an old Vera controller using lots of specifically written code. But the same code is used for all of them.
A rule written for each room would mainly only differ in that it uses a different temperature sensor and controls a different heater. With a few more variables like the desired minimum temperature in each room according to the time of day. But the logic is always the same.
I was thinking about writing a virtual āheating controlā device. Probably based on a thermostat one. Is this what you are suggesting when you mention child apps? If not, please would you explain further or point me at an example. I am still learning. Thanks.
Have you considered simply writing a Hubitat Groovy App? They really are not that hard to write and maintain once you get the hang of it. You could reuse all the code you'd like inside one app 
and it could handle all of your rooms in one single instance of the custom app.
And then release it to the community and become a hero for those w/similar desires. 
Lots of peeps here w/Groovy experience who could offer tips and examples.
I mean a parent child smartapp that has this arrangement in the App part of HE
This is my app for Humidity management. It is the same logic in both Humidity manager Study and Master bedroom. The differences are the potential parms used like switch for my humidifer or dehumidifer and the settings for optimal humidity.
You would need a smartapp to relay between the Temp Sensor and the Heater. I don't believe devices and respond to other devices like that.
Honestly other the storing your prefered temp based on time of day a smart app shouldn't be hard to do at all. If i was going to do it i would base it off of that app actually. Just rename a few things.
Yes it does. I think I came across a post that discussed that in a bit more detail. I must see if I can find it again. Thanks.
I put together something that should kind of work. Here is what it does
a. It uses parent child structure so you can create child app for each room
b. Child apps use the following: a temp sensor for the room, a switch to turn on a heater, a offset so it will allow a variation of x degrees up and down. Last a toggle to set a setpoint, or use a thermostat for it, lastly based on what you select a entry for it
c. You would use a Virtual Thermostat per room and the Built-in thermostat scheduler to build out the schedule to set your schedule for personalized set points throughout the day or based on presence.
Does that sound like what you want. I can post it if you want it. I may continue to enhance this so it can work with Govee space heaters and my integration.
Damn, you people who can throw apps together like this impress me. And in addition that you're just being really nice, great contribution to the forum.
The thing is it really helps to already have the shell from a previous app. I litterly copied both the parent and child apps i mentioned earlier and then just changed descriptive stuff to make it make more sense for this ask. The actual logic is very simple and most of the code is just the UI.
As @ogiewon said once you get the basics down this kind of smart app is easy.
I will clean it up a bit and post it here.
Iām getting so much good advice on here that its hard to keep up with responding to everyone.
So, firstly, thanks all. Itās given me a lot to think about and explore.
I would really like to see the example from @mavrrick58 Examples are good. I donāt believe in reinventing the wheel and some parent/child examples to start from would be ideal. Groovy doesn't look too different to a lot of other things (but I do wish I didn't have to keep learning a new, slightly different language so regularly. I'm sure the hubitat developers will have a good reason why, but... 
)
And, sorry @danabw I donāt think Iāll be releasing anything of my own just yet. Iāve still got a lot to learn!
Here is the code. I tried to clean it up a bit this morning and make sure it was all working as expected. I haven't used it fully myself except for testing on my dev hub. That said i do believe the idea is fully functinoal. I will also put this under my github as well..
Here is the code
Parent app:
/**
* Heater control using an external temp sensor or weather underground
*
* Copyright 2015 Mavrrick
*
* Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
* in compliance with the License. You may obtain a copy of the License at:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
* on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
* for the specific language governing permissions and limitations under the License.
*
*/
/**
* 10/31/2018
* Updated required fields so the application can be used simply to humidify or dehumidify and not require both functions
* Corrected value used for humidification low value to turn on assigned switch
*/
definition(
name: "Heater Manager",
namespace: "Mavrrick",
author: "Mavrrick",
description: "Manages Heat in home with Space Heaters",
category: "Convenience",
installOnOpen: "true",
singleInstance: "true",
iconUrl: "https://graph.api.smartthings.com/api/devices/icons/st.Weather.weather2-icn",
iconX2Url: "https://graph.api.smartthings.com/api/devices/icons/st.Weather.weather2-icn?displaySize=2x"
)
preferences {
page(name: "setupMain")
}
def setupMain() {
dynamicPage(name: "setupMain", title: " ", install: true, uninstall: true) {
section("Manage Heater ManagerInstances") {
app(name: "Heat Manager", appName: "Heater Manager-Child", namespace: "Mavrrick", title: "Heater Manager Instance", multiple: true)
}
}
}
def installed() {
}
def updated() {
}
Child App:
/**
* Heater control using an external temp sensor or weather underground
*
* Copyright 2015 Mavrrick
*
* Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
* in compliance with the License. You may obtain a copy of the License at:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
* on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
* for the specific language governing permissions and limitations under the License.
*
*/
/**
* 10/31/2018
* Updated required fields so the application can be used simply to humidify or dehumidify and not require both functions
* Corrected value used for humidification low value to turn on assigned switch
*/
definition(
name: "Heater Manager-Child",
namespace: "Mavrrick",
author: "Mavrrick",
description: "Manages Heat in home using Space Heaters",
category: "Convenience",
parent: "Mavrrick:Heater Manager",
iconUrl: "https://graph.api.smartthings.com/api/devices/icons/st.Weather.weather2-icn",
iconX2Url: "https://graph.api.smartthings.com/api/devices/icons/st.Weather.weather2-icn?displaySize=2x"
)
preferences {
page(name: "page1", title: "Select sensors and set confortable humidity range", install: true, uninstall: true){
section("Give this app a name?") {
label(name: "label",
title: "Give this app a name?",
required: false,
multiple: false)
}
section("Room Temp Sensor:") {
input ("tempInput", "capability.temperatureMeasurement", required: true)
}
section("Space Heater?") {
input ("switch2", "capability.switch", required: false)
}
section("Temp On/Off range") {
input ("tempRange", "number", title: "Desired Temperature Variance for on/off range above and below the setpoint. Default is 1%.", required: false)
}
section( "Setpoint set by:" ) {
input ("setPointSupply", "enum", title: "which source?",
options: ["Entry", "Thermostat"], required: true, submitOnChange: true)
}
if (setPointSupply == "Entry") {
section("Enter Setpoint") {
input ("tempMin", "number", title: "Desired minimum temp.", required: false)
}
}
else {
section("Which sensor will supply the temperature?") {
input ("thermostat", "capability.thermostat", required: false)
}
}
section(/*getFormat("header-green", "${getImage("Blank")}"+*/ " General") /*)*/ {
// label title: "Enter a name for this automation", required: false
input "logEnable", "bool", defaultValue: false, title: "Enable Debug Logging", description: "debugging"
}
}
}
def installed() {
subscribe(tempInput, "temperature", tempAction)
log.info("Installed Heater manager application")
}
def updated() {
unsubscribe()
subscribe(tempInput, "temperature", tempAction)
log.info("Updated Heater manager application")
}
def tempAction(evt) {
if (logEnable) log.debug("tempAction(): Temp action to validate temp event ${evt.value}")
long evt2 = evt.value.toLong()
if (setPointSupply == "Entry") {
tempOn = (tempMin - tempRange)
tempOff = (tempMin + tempRange)
} else {
if (logEnable) log.debug("tempAction(): Current thermostat set point is ${thermostat.currentValue("heatingSetpoint")}")
setpoint = thermostat.currentValue("heatingSetpoint").toLong()
tempOn = (setpoint - tempRange)
tempOff = (setpoint + tempRange)
}
if (logEnable) log.debug("tempAction(): Temp to turn off at ${tempOff}, Temp to turn on at ${tempOn} based on variance ")
if (evt2 < tempOn && "off" == switch2.currentSwitch) {
if (logEnable) log.debug("tempAction(): Temp below minimum = ${evt.value}. Turning On Heater")
switch2.on()
}
else if (evt2 > tempOff && "on" == switch2.currentSwitch) {
if (logEnable) log.debug("tempAction(): Temp above setpoint = ${evt.value}. Turning off Heater")
switch2.off()
}
else {
if (logEnable) log.debug("tempAction(): no change = ${evt.value}")
}
}
The parent app is pretty typical for this type of thing. It just calls out that it is a parent and then what it's child name space and such is to call when it goes to set it up. You an put multiple entries in there if you had different kinds of child apps.
The child app is just as the inputs i mentioned above. Then it just has a simple bit of logic that based on how you setup your set point. it will turn on/off the heater device based on either a set temp value or based on a external Thermostat.
The logic is pretty simple: On any temp change for your triggering temp sensnr it collects and calculates your temp on/off values based on your set point source and the variance values. Then If it is below the set point value - variance and the device is turned off, it turns on the heater. If it is above the setpoint+variance value and the heater is on, it turns off the heater. If neither of those conditions are correct it just ignores the change and doesn't do anything.
For dynamic set points by room you will want to use the set point source as a thermostat. This means you will need to setup a virtual thermostat for the room before hand. To make it dynamic you will want to use the built in Thermostat Scheduler app. You may need to adjust this by season yourself though or create multiple instances that you disable enable by season.
Thanks.
