Would be great to be able to use helpers / inputs such as input_number / input_datetime / input_select etc directly in automations.
For example have input_datetime setup in Lovelace and once a time is selected it adjusts the trigger time in an automation etc.
You can already do this, albeit they need to be coded first⊠like any other automation.
Perhaps you need to explain what you want a little more clearly�
wanting to use the helper / input directly in automationâs or other areas without having to do any extra coding would make it much easier for users that try to use the UI only i.e. in these two examples.
Or like this
That would require the GUI automation editor to be capable to creating templates on the fly, something we have wanted for a while, but probably a long way off. I think there is another request for this already
To be honest I donât really get why such a logical request has be done with a jinja to begin with. Wouldnât it be nice if it was possible to just use it in yaml the same as we use entity_id?
Definitely! I donât use the GUI automation editor so being able to use input_* directly in yaml for data values etc would be epic. Templates are just something I donât have a good handle on.
In an alternate timeline, there are no services or templates and itâs possible to do this in Home Assistantâs scripts:
if sensor.exterior.illuminance < 35:
switch.porch.powerstate = true
light.bathroom.brightness_pct = 70
climate.hallway.temperature = 21
fan.bedroom.speed = 'low'
else:
light.tablelamp.rgb_color = [138, 75, 12]
light.tablelamp.powerstate = true
notify(my_phone, now().time, 'Hello world!')
Iâve been asked how does one do this? A good question for which the short answer is âYou canât.â
This is a fictional example representing what could be possible in another world where python was adopted as Home Assistantâs scripting language and entities were objects with properties and methods.
In this fictional universe, if you set an entityâs powerstate property to true, it serves to turn on the entity. Entities with a powerstate property would be things like switches, lights, fans, etc (in other words, all these objects inherit this property from a common âpowerâ base-class).
FWIW, this is not an entirely fictional example. Itâs precisely how it works in another home automation software I use (except it uses VBScript, which hints at the softwareâs age).
Anyway, just a brief trip to the Twilight Zone and now we return to our world of YAML, services and templates.
This doesnât seem impossible without templates even in YAML but it would take some work. So for instance your time trigger is expressed like this in YAML currently:
automation:
- trigger:
- at: '10:00'
platform: time
This field at is something which currently expects only a constant as its value in the schema. For backwards compatibility this has to be maintained. But what you can do is enable this schema to also become valid:
automation:
- trigger:
- at:
entity_id: 'input_datetime.ac_auto_time_on'
platform: time
This way if the value of at is a string then you use the value as is. If the value of at is an object then you look for the entity_id field and find the state of the entity. You could even take this further and enable more options like this:
automation:
- trigger:
- at:
entity_id: 'sensor.ac_info'
attribute: 'auto_time_on'
platform: time
or this:
automation:
- trigger:
- at:
template: '{{ insert some template here }}'
platform: time
Unfortunately you would have to do this on a per input/field basis. But you could make a resusable schema validator that anyone could use to turn any field that currently only accepts constants into a one that provides more dynamic options for collecting its value.
This could also be carried into the UI. Now I am very much not a designer so this is a quickly hacked up job in Macâs image editor but hopefully it conveys the idea enough to get my point across:
That UI could then translate to the appropriate YAML config, no template generation required.
Anyway just a thought. I like the idea and I think something like this could make it feasible. Still would be significant effort to modify the schema in all the places though so not clear where something like this would fall in the priorities list.
This is why I (quite directly after using Home-Assistant for the first time) switched to do all my scripting in Home-Assistanâs AppDaemon. If I got you right, you can basically just do there what you suggested. However, you still have functions like call_service("power_on", ...) (or similar, I never can remember the syntax), instead of just setting powerstate = true.
So, yes. This is something I expected from Home-Assistant, but settled with the workaround.
p.s. And yes, I wanted to use an input field to trigger the time of an automation, as the original poster, too. When I noticed this does not work (that easily), I started to look into AppDaemon.
Owing to Home Assistantâs architecture, I canât imagine that will ever change. Whenever you want to act on something, you must explicitly call a service.
I can accept that but I prefer the way it was handled in Premise. Read on only if youâre interested in how another product addressed the challenge of creating automation logic.
An entity has properties and if you change its properties, the entity responds accordingly. Want to turn on something? Just set its powerstate property to true. Set it to false to turn it off. Couldnât be easier.
The principle even works with complex devices where you may need to set many properties prior to activating it. For example, playing a TTS message where you may want to specify the voice, volume, the text to speak, and an optional sound clip to play, before the text is spoken.
Given that you donât use a function call for that in Premise, how do you do it? Like this (itâs VBScript):
with Devices.Speech
set .AudioClip = Media.GetObject("sys://Media/Content/Music/Effects/Twinkle.mp3")
.Content = "<silence msec='1000'/> Hello world!"
.ContentType = "XML"
.Voice = 1
.Volume = 0.8
.Speak = true
end with
All the properties of Devices.Speech are initialized and then the final Speak property is set to true which activates Device.Speech. First a preliminary Twinkle.mp3 sound byte is played followed by a 1 second pause and then Microsoft Zira (`Voice = 1) speaks âHello world!â at 80% volume.
The with ... end with is just a VBScript technique to indicate everything between the two boundaries belongs to Device.Speech (so you donât have repeat it in front of each property name). The only reason set is used with the AudioClip property is because that property is an object pointer and thatâs how (in VBScript) you assign it an object. The other properties are text, integer, float, and boolean.
In this case, Speak is a momentary boolean. When you set it to true it instantly sets itself back to false. All it serves is to provide way of triggering the action.
Lastly, entity names are based on their location within your home (like a file-path). Itâs like Home Assistantâs Areas but you can nest them and they become part of the entityâs identifier. For example:
Home.Second.Master.TableLampRight
To turn it on, just append powerstate to the entityâs name and set it to true. Easy-peasy.
Anyway, thatâs a sampler of how itâs done in Premise.
When using the time only component of input_datetime we get a nice HH:MM:SS tuple that could so easily drop into an at: or above: or below: clause in platform: time or condition: time but have no way of doing so.
Currently, using input_datetime in a trigger or condition has no simple use case for a beginner or intermediate user. The example below in the input_datetime documentation is a rather complicated workaround for the fact that sensor.time doesnât have any HH:MM:SS formatted string to allow for even a simple string comparison. The majority of hass users likely donât know how to use unix timestamps and advanced templating are probably just going to copy/paste from the example in the documentation without understanding how the template works.
value_template: "{{ states('sensor.time') == (state_attr('input_datetime.bedroom_alarm_clock_time', 'timestamp') | int | timestamp_custom('%H:%M', False)) }}"
How to emulate condition: time before: and/or after: with input.date_time in a template sensor isnât in the documentation. The template needed will be even more complex than the one above.
I see input_datetime as the most glaring example in this WTH. Input_boolean, input_number, input_select can be already be handled with simple comparisons in templates, state and numeric_state, but input_datetime cannot.
This is awesome news! It will make a heap of my automations easier to code⊠if I can be bothered re-coding them 