Adjust sun elevation offset using input_number

Configuration
9

Have you checked the states page to make sure the entity exists and what the state of the entity is?

10

Thanks for your time. Yes, the entity exists and has an initial value after restart of -10.0.

11

:+1: Yes, I caught that and changed it already.

12

I’ve also checked that the value changes with the number slider.

I have a feeling this has something to do with float or int but really don’t know where to look.

13

It would seem that what I’m attempting is not currently possible.

So, I’ve decided to use a binary sensor to achieve the same:

- platform: template
  sensors:
    lights_on_elevation:
      value_template: >-
        {{ (states.sun.sun.attributes.elevation | float) > (states.input_number.sunset_elevation_offset.state | float) }}

Thank you for all of the help.

14

I’ve come to the same conclusion. It seems like below: is not designed to handle templates.

15

It’s possible… just different. You need to evaluate your output in the value_template and assign it hard coded values. Then your below: attribute simply is in the middle of your 2 hardcoded values. Is this a work around? Yes, but it will work.

      trigger:
        platform: numeric_state
        entity_id: sun.sun
        value_template: "{{ 0 if state.attributes.elevation < states('input_number.sunset_elevation_offset') | float else 10 }}"
        below: 5

EDIT: You could have also just used a value_template trigger. Either is fine.

      trigger:
        platform: template
        value_template: "{{ state_attr('sun.sun','elevation') | float < states('input_number.sunset_elevation_offset') | float }}"
16

you beat me as I was templating this:

{{ 0 if state_attr('sun.sun','elevation') < 
        states('input_number.sunset_elevation_offset') | float else 10 }}

still, since I have also worked around this specific format for the below:, please let me ask if the state.attributes.elevation, or any other state in any other entity, can be called this was, if one first states the entity_id on its own? Not a very usual construction but very useful indeed!

1 Like
17

state.anything is only possible because it treats the entity_id: whatever as the state object. This is only doable inside numerical_state trigger and condition. It may be doable in other areas but they will be very specific, i.e. tied to an entity id during the setup.

1 Like
18

It was 40 years ago I used to program C and am just getting back to coding with this. I keep looking for variables to use, but of course, HA doesn’t currently support them.

19

They do support variables in certain context. They don’t support global variables. If you want global variables, you can always make a python script that stores states inside sensors.

20

That’s beyond me right now!

21

I’m also a newcomer to Home Assistant (but not home automation) and the technique used to store globals feels like a kludge. Why? Because it uses UI widgets as global variables.

Need to store a boolean value? Create an input_boolean and store it there. Need to save a global numeric value? Create an input_number and use that. Don’t want these widgets visible in the UI? Use hidden: true in customize.yaml.

Anyway, like traveling to a foreign country, where “they do things differently there”, you just learn the local customs and roll with 'em.

22

They really aren’t UI widgets. The old frontend is so ‘tied’ to the back end that it appears as if they are UI widgets. Hopefully this switch to lovelace will show the separation a little better.

23

I would welcome that change. There are cases where you’d want to use an input_boolean as a global variable and NOT want it to be automagically exposed in the UI. Having the choice of exposing/not exposing it in the UI is a step forward.

24

That’s the point, everything will be hidden by default because you have to place it into lovelace to appear. Lovelace is opt-in, not like the frontend which is opt-out.

example w/ frontend:

  1. Make your input_number.
  2. Hide it.

Example w/ lovelace

  1. Make your input_number
  2. Show it.
25

not sure if this is fully correct tbh. You can make anything in plain old HA, but without configuring that in the views/groups they don’t show up.
That was the whole reason I/we made the orphans and ghost scripts, to find upgrouped but existing entities.

I find the way plain HA went about with dynamically created entities much preferable to Lovelace, which keeps showing those ugly yellow bars when entities aren’t initiated yet. regular Ha simply didn’t show these, until created/initiated.

Think media-players, think bluetooth trackers, even think the amazing group.set and group.set_visibility to create views on the fly, and kill them again…

Still have to find a way to have these media_players.xx only show when they exist. or when they don’t have a state yet…:

03
maybe there’s a state filter?

26

They show up on the main states page by default inside their respective ‘all_x’ groups, or as sensors on the top bar. Only way that don’t appear is if you override the default states page. Maybe that’s what you are doing?

EDIT: I guess it’s possible that some might not show up. Personally, I haven’t had that happen yet.

27

A yes, that is correct… forgot about that one. But that is so default, to have a custom default page, I don’t think many users still have the startup default page with all entities.

anyways, would you know a solution for having a media_player group/view with all media_players, and only have them appear when actually initialized? I tried a monster card

  - type: "custom:monster-card"
    card:
      title: Monster media players
      type: entities
    filter:
      include:
        - entity_id: media_player.*

but that only shows these little ‘entities’

04 while I am looking for the big media_control cards:

17

see: Lovelace - Media-control filter? - #7 by Mariusthvdb

28

I’m not sure. Monster card is like an entities card so it makes sense that it doesn’t display media players. Sounds like we just need glob for views.