Awesome. I knew it would be down to a stupid oversight, or something. Thanks! The second part was just a typo.
If you are really feeling lucky, you can make one automation to execute them all!
- alias: Input Select Scene Executer
trigger:
- entity_id: input_select.fav_scenes
platform: state
- entity_id: input_select.lr_scenes
platform: state
condition:
contidion: template
value_template: {{ trigger.to_state.state != ' ' }}
action:
- service_template: >
{% set my_map = {'Peaches & Cream':'script.peaches_and_cream_script',
'Kitchen Colours':'script.kitchen_colours_script',
'Relaxing':'script.relaxing_script',
'Reading in Bed':'script.reading_in_bed_script',
'Footpath Chalk':'script.footpath_chalk_script',
'Tropical':'script.tropical_script',
'Night Night':'script.night_night_script'}
{% if trigger.to_state.state in my_map %}
{{ my_map[trigger.to_state.state] }}
{% else %}
script.dummy
{% endif %}
- service: script.1526475620973
You’ll need to create a dummy script with that does something, anything really. Doesn’t matter what you do as long as the script contains a service you should be good. Example, you could have it turn on an input boolean, never display the boolean though.
The dummy script is needed so you don’t get an error when home assistant is starting or the input select option screws up.
You’ve literally just gifted me a Saturday—this was going to be my next line of investigation. I’ll try to implement it tomorrow—you can probably expect my call!
HI @petro,
you got me triggered here…
please see this input_select calling scripts i have, would that need the above improvements also? Thinking of the dummy script, and the set my_map…
input_select:
activity:
name: Activity selection
icon: mdi:home
options:
- Opstart
- Opstaan
- Aan de slag
- Uit huis
- Gym
- Gaming
- Selamat makan
- Home theater
- Naar bed
- Arrive home
# initial: Opstart
and
automation:
- alias: Activity selection
id: 'Activity selection'
hide_entity: True
initial_state: 'on'
trigger:
platform: state
entity_id: input_select.activity
action:
- service_template: >
{% if is_state ('input_select.activity','Opstart') %} script.opstart
{% elif is_state ('input_select.activity', 'Opstaan') %} script.opstaan
{% elif is_state ('input_select.activity','Aan de slag') %} script.aan_de_slag
{% elif is_state ('input_select.activity', 'Home theater') %} script.home_theater
{% elif is_state ('input_select.activity','Gym') %} script.gym
{% elif is_state ('input_select.activity','Gaming') %} script.gaming
{% elif is_state ('input_select.activity', 'Selamat makan') %} script.selamat_makan
{% elif is_state ('input_select.activity', 'Uit huis') %} script.uit_huis
{% elif is_state ('input_select.activity', 'Naar bed') %} script.naar_bed
{% elif is_state ('input_select.activity', 'Arrive home') %} script.arrive_home
{% endif %}
- delay: 00:00:02
- service: python_script.summary
# data_template:
# event: "{{ trigger.event }}"
im having issues at startup, where the scripts are triggered but not really do their job completely.
especially the accompanying input_select.mode:
automation:
- alias: 'Mode selection'
id: 'Mode selection'
hide_entity: True
initial_state: 'on'
trigger:
platform: state
entity_id: input_select.mode
action:
- service: homeassistant.turn_on
data_template:
entity_id: >
{% if is_state ('input_select.mode','Normal') %} script.mode_normal
{% elif is_state ('input_select.mode','Full house') %} script.mode_full_house
{% elif is_state ('input_select.mode','Kiosk') %} script.mode_kiosk
{% elif is_state ('input_select.mode','Developer') %} script.mode_developer
{% elif is_state ('input_select.mode','Vacation') %} script.mode_vacation
{% elif is_state ('input_select.mode','Locked') %} script.mode_locked
{% endif %}
- delay: 00:00:02
- service: python_script.summary
# data_template:
# event: "{{ trigger.event }}"
thanks for having a look!
Marius
Sorry, I just remember this post.
You may be able to avoid a ‘dummy script’ if you add a condition prior to executing the map. Also, you are pretty organized with your naming conventions, you could forgo the map and use some string editing.
automation:
- alias: 'Mode selection'
id: 'Mode selection'
hide_entity: True
initial_state: 'on'
trigger:
platform: state
entity_id: input_select.mode
condition:
condition: template
value_template: >
{{ states('input_select.mode') in ['Normal','Full house','Kiosk','Developer','Vacation','Locked'] }}
action:
- service: homeassistant.turn_on
data_template:
entity_id: "{{ 'script.mode_' + states('input_select.mode') | lower | replace(' ','_') }}"
- delay: 00:00:02
- service: python_script.summary
# data_template:
# event: "{{ trigger.event }}"
EDIT: simplified it some more.
thanks!
this is my next step in editing Yaml. Using these lists is still a bit new for me, after having been so meticulously meticulous with building yaml listing the separate entities.
Will give this a new impuls!
btw, I have found out that the fact this specific automation didnt kick in every on startup was also a timing issue. It calls a script calling a script, also notifying feedback.
On @balloob’s advice Ive revisited all of these scripts, and now trust restore_state to take care of the 2 automations I have at startup, mode selection and activity selection.
The specific sub script that was called here when selecting developer mode (showing several dedicated groups, and hiding them when the other options were called) is now being called directly as follows:
- alias: 'No dev tools at startup HA'
id: 'No dev tools at startup HA'
initial_state: 'on'
trigger:
platform: homeassistant
event: start
condition:
action:
- delay: '00:00:15'
- condition: state
entity_id: binary_sensor.mode_developer
state: 'off'
- service: group.set_visibility
entity_id: group.developer
data:
visible: False
- service: group.set_visibility
entity_id: group.developer_links
data:
visible: False
# - delay: '00:00:05'
# - service: script.mode_normal_direct
# - delay: '00:00:03'
# - service: script.opstart_direct
- condition: state
entity_id: input_boolean.notify_developing
state: 'on'
- service: notify.notify
data:
message: >
Dev mode - Dev mode visibility set to false at setup
Made an extra notify.Dev_mode so I dont hit the max notifications each day
exactly why do i need the condition here? the action template selects only valid states doesnt it? So no exception catching, or ‘else’ is necessary?
Because you will get an error if your data_template has an empty or invalid entity_id. Templates do not only select valid states, it will execute whatever code you supply it.
that makes sense, (from a computers point of view…)
btw changed the above automation into this, practically obliterating the need for the other input_select, which was till now mainly used, for selecting the dev mode tools or not…
have to develop the Modes now priority 1! (or cut code heavily of course)
- alias: 'Dev Mode selection'
id: 'Dev Mode selection'
initial_state: 'on'
trigger:
platform: state
entity_id: input_select.mode
action:
- service: group.set_visibility
entity_id:
- group.developer
- group.developer_links
data_template:
visible: "{{ is_state('input_select.mode', 'Developer') }}"
might as well combine the 2 and add the homeassistant: start trigger here, and be done with it.
Nice, looks good.
yep, and works beautifully and swift, better than before …
next up, trying the View: true bit of a group to change dynamically:
service: group.set
data_template:
object_id: Developer
view: "{{ is_state('input_select.mode', 'Developer') }}"
visible: "{{ is_state('input_select.mode', 'Developer') }}"
Looking at the source code, i would think it would work. It’s at the same level as visible on a group object. Give it a whirl. I’m not sure how it would behave in your browser because browsers can be dumb.
they’re dumb…
no luck just yet. No errors either, and even Hassio is connecting, so that’s rather noteworthy. Before with even the slightest thing Hassio would fail, and now, with a more substantial issue, is doesnt. All the better.
Ive tried the in the regular group definition, but that errored out.
Having it in the automation:
- alias: 'Dev Mode selection'
id: 'Dev Mode selection'
initial_state: 'on'
trigger:
platform: state
entity_id: input_select.mode
action:
- service: group.set_visibility
entity_id:
- group.developer_links
data_template:
visible: "{{ is_state('input_select.mode', 'Developer') }}"
- service: group.set
data_template:
object_id: Developer
view: "{{ is_state('input_select.mode', 'Developer') }}"
visible: "{{ is_state('input_select.mode', 'Developer') }}"
passes all checks, but has no results, at least the second service, which is whats all about of course.
Might have to try something else.
Cheers,
Marius
you clear cache and refresh page (ctrl+f5)?
yes, sure, even loaded Chrome, and in incognito mode. Nothing happening …
I wonder if they have methods that handle the visibilty for the visible property.
have you tried it in an automation but hardcoded? So have it off, fire the auotmation and have it turn on. Just to verify that it could work? It could just not allow templating.
no it allowed templating. On that is, or True.
Cant get it away anymore, using either:
{“object_id”:“developer”, “view”:“false”, “visible”:"false " } or
{“object_id”:“developer”, “view”:"{{ is_state(‘input_select.mode’, ‘Developer’) }}", “visible”:"{{ is_state(‘input_select.mode’, ‘Developer’) }} " }
hmm, seems it only accepts, true or True…
Invalid service data for group.set: invalid boolean value false for dictionary value @ data['visible']. Got 'False '
Forget what i said about only accepting true. It didnt accept " False", or " False ". Spaces…
tried a binary_sensor:
{“object_id”:“developer”, “view”:"{{is_state(‘binary_sensor.mode_developer’,‘on’)}}", “visible”:"{{is_state(‘binary_sensor.mode_developer’,‘on’)}}"}
no such luck.
Guess is was the templating after all… such a pity, only half the support we want…
filed a feature request at:
workaround for the time being:
##########################################################################################
## Switch
##########################################################################################
switch:
- platform: template
switches:
mode_developer:
friendly_name: Developer mode switch
value_template: >
{{ is_state('input_select.mode', 'Developer') }}
turn_on:
- service: script.mode_developer_direct
- service: homeassistant.turn_on
entity_id: input_boolean.notify_developing
- service: group.set
data:
object_id: developer
view: true
visible: true
turn_off:
- service: script.mode_normal_direct
- service: homeassistant.turn_off
entity_id: input_boolean.notify_developing
- service: group.set
data:
object_id: developer
view: false
visible: false
or, even better maybe per Mode:
scene_developer:
alias: Call Developer scene
sequence:
- service: homeassistant.turn_off
entity_id: group.philips_motion_sensor_switches
- service: input_select.select_option
data:
entity_id: input_select.theme
option: 'matrix'
- service: group.set
data:
object_id: developer
view: true
visible: true
anyways, hoping for the templating option…