Heat vs. glare (direct sunlight) precedence #137
Replies: 2 comments 3 replies
-
|
Happy to the recent improvements work well for you! Regarding the temperature: I'm not sure I follow. Smart Cover Automation is not designed to use indoor temperatures at all. Instead, it uses outdoor temperature thresholds (docs) to determine if it's hot enough to enable heat protection mode. |
Beta Was this translation helpful? Give feedback.
-
|
So what good are the exposed external entities 'switch.smart_cover_automation_XXXX_wetter_heiss_externe_steuerung' for each window. Did I get something wrong there? I know about the forecast min and max temps but I got them locally (do you always trust the weather forecast,☺?). And I don't really care if it's hot outside, it's the inside I'm interested in. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, you should have mentioned what specifically you were referring to. Those entities allow you to control from your own automation under which conditions you want the integration to consider it to be hot enough for a specific cover to close. The point is that you can come up with any automation you find necessary based on any metrics you need for that decision. |
Beta Was this translation helpful? Give feedback.
-
|
You specifically mention indoor temperature mesurement to control the hot state of a windoe (room). Coming back to my initial question/idea its a matter of precedence of temperature (whatever the source may be) versus glare (direct sunlight). |
Beta Was this translation helpful? Give feedback.
-
|
You could use a combination of indoor temperature and luminance for the decision whether Smart Cover Automation should consider it "hot" enough to enable heat protection mode. Or use some other source, based on temperature or not. Feed the result of your automation's calculation into SCA's external |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi Helge,
first off, 3.3.0 works great, had to experiment a bit with slat overlap first but is working fine now, also the timeout for clouds.
I'd like to discuss the existing precedence of heat (from a room sensor) over light intensity (from a luxmeter). The trigger temperature to set the external entity was met in only one room (both on the same side of the house with identical azimuths), so only one blind came down.
As room temperature (outside of heating period) is a primarily a function of sun radiance, wouldn't it be better to let brightness take precedence over temperature (or make it configurable).
Just an idea to discuss, I could always turn down the trigger level (as I already did with the values from weather forecast).
LG Christian
Beta Was this translation helpful? Give feedback.
All reactions