Inhibit use of certain switches during daytime

Hello forum,
I’m interested to set a rule for certain entities to be operational only when the sun is gone.

I think that those entities should regard a script which will set a state from active to inactive during the daylight. So if one family member wants to turn light on by tapping the relevant command, that won’t be regarded and remain inactive when the sun is above horizon.

I’m very new to start such programming, it’s very appreciated a guide.

you could use a conditional card and put all of the switches that you don’t want to be available into that and then use the sun state as the condition.

Or you could put all of those switches into a view and then use Compact Custom Header to hide that view based on the sun state.

I think there is also another custom component called “state switch” by Thomas Loven that might do what you want.

There are a few options and I’m sure I don’t know all of them but those are a few to get you started.

Well a conditional card is appealing me.

I figured it would be the most useful in what you wanted to do. That’s why it was listed first. :wink:

Back to the discussion to deep the information.
It seems that the conditional card works with a Boolean state. But I’d like to expand a little the condition which checks that the event should be earlier a certain amount of time…
I’m trying this

But is not exactly the same formula to apply to the card condition.
I put like this
  - entity: sun.sun
    state: template
    value_template: "{{ state_attr('sun.sun', 'elevation') < 4 }}"

For the conditional card, but I’d like to have a better figure with a period of time, which is much suitable for me and doesn’t cause so much mess for a tropical area like mine. I think the conditional card doesn’t allow a list of condition.

Si I’d like to have the delay for both cases of the sun rise and set.


I started to understand how it works.
The template should follow a jinja formula

So I’m trying
  - entity: sun.sun
    state: template
    value_template: >-
      {{ state_attr(''sun.sun'', ''elevation'') < 4 }} | {{
      state_attr(''sun.sun'', ''elevation'') < -6 }}

But I’d like to know what are the data returned from such query, so I may decide which filter I will apply.

You can put the template into the template editor to see what the result is that is returned.

However before you do that to ensure that the template returns an expected value you need to covert the attribute (which is a string) to a number to then do the comparison:

{{ state_attr('sun.sun', 'elevation') | int < 4 }} | {{ state_attr('sun.sun', 'elevation') | int < -6 }}

Also, try to get out of the habit of using two single quotation marks in your templates. Just use either single or a double quotation marks (or an appropriate mix of the two) unless you absolutely need to do otherwise. It makes things less confusing for you and for others who may need to read it later. Like I am right now. :wink:

You’re right, I just discover that editor.
But the returned value is rather a float than a integer, so I may opt to use the first decimal to fine tune the event.

That was what the lovelace editor displays, roughly copied & pasted. But I think it must be quoted within a python style.

Template is correct but doesn’t work with lovelace. The card don’t appear even both conditions are true.

I just noticed that you are using the “|” symbol in your template.

That won’t work.

If your goal is to use those as “or” then you need top do this:

{{ state_attr('sun.sun', 'elevation') | int < 4 or state_attr('sun.sun', 'elevation') | int < -6 }}

You might be right, the intent is to extend the period over sunset and sunrise.

So the condition should result true if the elevation is a bit earlier the sunset and a bit late than sunrise. Am I right?

So if you want it to occur between 4 & -6 then change the comparator for the -6 condition and use ‘and’ in the template instead of ‘or’:

{{ state_attr('sun.sun', 'elevation') | int < 4 and state_attr('sun.sun', 'elevation') | int > -6 }}

I think that will get you what you want.

The condition is valid (everybody can test it on the template editor), but it seems that lovelace ignores it.

Maybe lovelace doesn’t accept template condition.

Did you read the configuration examples for the conditional card?

The way I usually help people is that I assume that they actually read the documentation for the thing that they want help with. I do that because I don’t want to take the extra time to have to do research on the whole thing that someone else wants to do every time I try to help someone. as you can understand If I did that with every question I try to give help with then it would take way more time to study the documentation and give specific information based on that documentation than to give general pointers and tell the person where they can find the information themselves. I guess one could consider that a flaw in my methodology but it does work most of the time.

That means that I assume that the configuration that they initially post is at least somewhat reasonably close to what the documentation describes as being valid. In this case what you are trying to do isn’t even close to how the conditional card is supposed to be configured per the documentaion for the card…

You are correct. it doesn’t take normal jinja templates. It takes normal yaml configuration.

I suggest reading the documentation for the conditional card and re formatting your conditions to match those configuration examples.

If it still doesn’t work then post back with the conditions you have then and we can go on from there.

Sorry. I don’t want to sound harsh. I just wanted to explain why we ended up going down the rabbit hole of talking about using jinja template conditions as opposed to the desired yaml based conditions. I assumed you checked and decided that you could use jinja templates in the conditions since that was the type of conditions you were posting.

I hope it helps.

I really don’t will to abuse for your help, I’m very grateful.
Please don’t cross your comfort line :slight_smile:

I read several time and I started to doubt that template is not applicable to the conditional card.

The example in that page giving two conditional states, which are referring to that entity. Am I interpreting wrongly?
So my understanding would summarize that the condition for sun.sun have only two conditions above_horizon and below_horizon.
as you might see

I apologize if lovelace accept another formula and I still not grasp that way to program it. It seems to me that is not accepting a template condition.
As I’ve shown the above conditional formula, are not giving the wanted result.

My config

System Health

|arch                       armv7l|
|dev                        false|
|docker                     false|
|hassio                     false|
|os_name                    Linux|
|python_version             3.7.3|
|timezone                   Asia/Kuala_Lumpur|
|version                    0.97.2|
|virtualenv                 false|
### Lovelace
|mode                       storage|

|resources                  0|
|views                      3|

yes, that’s correct. So you won’t be able to use the state to get what you want.

I think the easiest way to do it would be to create a template binary sensor using the conditions you have in your template above. Then use that binary sensor in the condition for the conditional card.

If I may suggest a possible solution is to make an input_boolean:, and run an automation at sunset (youcan offset the time either way) to set it to ‘on’, and another automation at sunrise to set it to ‘off’. These are available in the automation editor directly as call service - input_boolean.turn_on/off. Use the input_boolean state to control a conditional card as suggested by finity with the switches on it. Another solution is a custom component which has more states and elevations to choose from than sun.sun has, however this falls outside the realm of Homeassistant proper,and you may or may not be comfortable with that. I believe this will work for you, but did not test it myself, Good luck, YMMV

This is working correctly.
Many thanks to you and all.
I’ve slightly modified to accept a float, because I’m trying to set the event closer as much as needed.
As per binary sensor I may use an additional setting which would pose a delay to the event.

This is widening the entire choice, better than the limited result of sun.sun.