cold bolt
Hi,
How should the boolean state be defined in automation? UI just offers me 'not available' and 'unknown' options, but also hints that target state would be required (*).
Leaving it empty seems to be fine, but is it correct?
condition: state
entity_id: sensor.sun_solar_rising
state: ""
cold bolt
Hmm, input_booleans offer also 'on' and 'off' states in UI. I assume I need to use those also for this sun sensor.
gloomy spruce
Is that the built in sun integration? These are the entities I have. None of them match yours
cold bolt
Oh, well, I thought it is.
It is visible inside the "Sun" device... can I somehow track where it actually comes from?
At least it is listed here in the bottom of the list
gloomy spruce
None have the entity named you have there
You can check what integration an entity is from under the entity tab in settings -> devices & services
And also if the entities belong to a device, the device page will state it
cold bolt
It is under the Sun integration
gloomy spruce
Interesting, maybe the default naming scheme changed at some point?
At any rate if it's not working, do you have any of the entities listed at the bottom of the page you linked?
cold bolt
I have them all, and they even work fine. Just UI does not provide the possible states for that specific 'raising' sensor.
gloomy spruce
Try sun.sun with the attribute rising
cold bolt
It does not offer any options for that
gloomy spruce
Interesting. Well in yaml in can be formated like this
entity_id: sun.sun
attribute: rising
state: true
Note that because true is Boolean and not a string, I'm not sure how it plays with UI
Which might actually explain why it doesn't show up in the UI, as the UI explicitly states that it supports strings 😅
cold bolt
Yeah that seems to be the case 🙂
I thought that input_boolean states are also booleans, but they seem to be strings 'on' and 'off' instead, this sensor.sun_solar_rising seems to be actually boolean (I didn't know they can be booleans) 😄
But thanks for help. This seems to be clear now. Appears to be some inconsistency in HA.
spice summit
The state of every entity is always a string. Only attributes can be other objects, like booleans, integers, lists, datetimes, etc.
The UI will only offer options in the state dropdown box if it knows what those options can be. For a sensor, it’s not possible for the UI to know the states unless it is an enum device_class which explicitly lists the possible states. For a binary_sensor, or other entity domains like locks and covers, only specific states are possible so the UI can show them.
I don’t believe the UI will ever offer options in the dropdowns for to/from if an attribute is selected, because any attribute can take any value (in theory). The UI doesn’t know that the sun.sun entity has its rising attribute programmed to be only true or false. I can easily make a new template entity that has a rising attribute and set it equal to banana.
sly falcon
There's a few hardcoded that it knows, but not too many.
spice summit
Now I’m interested to know which ones
sly falcon
Now I’m interested to know which ones
cold bolt
I don’t believe the UI will ever offer options in the dropdowns for to/from if a...
What about my original question about sensor.sun_solar_rising? Why it is btw sensor and not binary sensor if it has a boolean value?
sly falcon
Good question, I don't know why.
I guess if you want to use that it would be "True" or "False"
You can type values into the state box even if they aren't offered as dropdown options.
spice summit
it probably should have been added as a binary_sensor; I don't see any comments in the PR for adding this sensor where anyone mentioned this. It certainly would have been more effort to make it a binary_sensor; looking at the code all the other sensors are in the sensor domain.
I would think a PR would be welcomed to change it to a binary_sensor
cold bolt
Yeah I see. Maybe not worth of time then.