?
What other sensors are you after? The proximity sensor? Not shown is also a Channel for “time to target temp”.
Even though the Time of Day design pattern uses an example based on the hour:minute of the day, the exact same approach can be used for setting the type of day. The challenge is how to calculate what type of day it is. If your work week is pretty regular though the Rule shouldn’t be too complicated.
There isn’t. It’s a known missing feature in OH. There is an attempt to address it in the work going into the next generation version of PaperUI under work now (see Next generation design: A Paper UI replacement proposal). There are other improvements in work that will make something like this easier to implement as well like the ability to set and read metadata on Items from Rules or the REST API. So, for example, you can put the temps for a given type of day in an Item’s metadata instead of needing to create separate Items to store each heating and cooling temp for each time for each type of day.
In the mean time, my usual recommendation is to use the CalDav binding and use a calendar to create your schedule.
Hmmmm. This does simplify things significantly.
OK, so if we have a way to figure out what type of day it is it is possible to load and parse some file types inside a Rule. Though often what I’ll do is create a .map file and use the transform Action to convert some Item name or other similar value (in your case they type of day and time) to a value.
It would be a bit awkward though but it could work.