@fredrike - I don’t think anyone “left” your solution, as it was more you leaving the discussion, although involentary…
@vilhelm.carlsson has made an attempt to a published blueprint, to his best effort. I can not condem him for his choice of inspriation to the actual logic, as he only had your code snipets, which can be usefull for the compiled solution, but being just snipets makes them a little more difficult to integrate unless thinking along the same path.
If you have a working blueprint, please show it, as discussed above the idea is to have a collaborative solution, and in that regards everyone’s effort counts - and at the same time some ideas will be rejected.
Currently I have a solution that “works” for me but it is entirely based on template sensors and thus not easily transferred to a blueprint. As you too indicate, it reiles on google calender for any of the regular departures (which I am not too happy with as I want to keep the solution within my four walls, but it was the quickest solution). All in all it seemed like a elegant solution which removed the need of having time pattern based automation fireing every umpteen minutes to evaulate the trigger condition (outside temp rise/drop). The downsides are:
- the template sensor is evalutated all year round, while an automation can be turned off summer time
- it depends on external source in terms of Google calendar, this can be mitigated by installing a private iCal solution
so I’m not that satisfied with my solution, but neither have I contributed that much to the public solution, so I feel that I have no right to complain.
