With the code as written above, you would need them to publish to a different topic. Alternatively, instead of the one Channel with a wild card subscription, you could create a separate Channel for each room and omit those Channels as triggers to the “External Temp” Rule that you do not want to use to drive the devices.
NOTE: The new Broker Thing and these Channels can be defined by the users using PaperUI instead of through the text based configs.
Implement something like the Time of Day Design Pattern to define the various time periods. Then one needs to make a mapping between a time of day and which room takes control of the heater. From there its a simple matter of populating the PrevousXReading with the reading from the right room. This could be expanded to support occupancy sensors (motion sensors with wasp in the box algorithm, FIND2, reelyActive BT sensing, etc.).
But the problem is the user needs to create the mapping between the room and the time of day. And they need to be able to define the times of day. And using Rules DSL, that is going to require editing .rules files. If we were using the NGRE, there are ways we can let the user define these using just Items which are created using PaperUI, no need to edit files.
To enable/disable we can use a Switch, but the actual configuration, using OH 2.4 and Rules DSL and with everything in text based configs rather than JSONDB means the user will have to edit files. The ability to access Item metadata which is a prerequisite for this.
NOTE: I’ve already an implementation of the Time of Day DP which doesn’t necessarily require users to edit any text configs in order to define the times of day and it would be trivial to add the mappings to the room that should control the heater. It even supports a different schedule for weekends and holidays. But it requires the NGRE and OH 2.5.
This is somewhat easier if we assume we only care about the max and min of all the external sensors like presented above. In that case the only difference between one external sensor and multiple external sensors is which topics are subscribed to that trigger the Rule. Just subscribe to one (or have one sensor publish to hestia/external/blah). The code would be the same.
To switch between the remote sensor(s) and internal sensor the easiest is probably to just use a Switch on BasicUI.
I’m really keen on moving to JSONDB for storing the configs over the text based configs. They will give us way more flexibility to support stuff like this and provide a UI for the users to customize everything (the UI doesn’t have to be PaperUI btw, it’s all REST API based). That sort of customization really isn’t available with the text based configs.
It also will let you develop an ecosystem of Rules that users can use and contribute to that they can just import as a template and use. Rules can enable/disable each other, you can turn Rules on and off through PaperUI and all that sort of thing which should make it much easier for users to customize their config, all without touching the text configs.
But I’m not sure how you build your images and don’t know the best way to source control them. I would imagine adding a var/lib/openhab2 folder along side the etc/openhab2 and home/pi/scripts folders and checking in at a minimum the etc, jsondb, and config folders.
That’s my inclination too, but I was trying to see if I could implement this without touching the main Rules. That could be easier for users to adopt and show how they can customize their config without requiring changes to the main .rules files. It doesn’t seem to be possible but I’m still thinking about ways to change default.rules in a way to make this possible.