Anything could happen, but that is a major part of the core. It would cause a riot.
Something to do on a snowy day 
Actually, I’m trying to reduce the number of templates I rely on to see if there is any performance improvement.
Sorry, not for everything. I meant just for GUI discovered and managed devices (My developer mind reading skills have proved to be completely useless)
Edit: Every day for you is snowy
You’re implying my directions are like rebuilding from scratch. They’re not that hard. One hoop at best. You’re changing one part of one line on the “user configurable” side of config.
“Prone to disaster” is a bit melodramatic. At worst, it breaks that single automation and HA runs in “safe mode” and lets you know something went wrong. You’re not going to delete your whole HA setup editing that YAML file, and if you have a backup it’s a remarkably quick fix.
It may not be to the taste of some, but this is a way of reconnecting automations until another method is created. We get your reasons for not liking device automations, but in all honesty it’s not like people’s devices are breaking or getting stolen that often that this is a huge blunder on the part of the devs.
There’s already another method that has been around a lot longer than device automations. It can be written in YAML or in the UI. It does not require reconnection. Why on earth would you use device automations?
What is the advantage?
Besides the clarity of knowing what automation is meant to work solely and specifically for the device, and hiding automations for devices that no longer exist?
You may see that as a negative, but for HA to be more user (especially inexperienced home user) friendly, it makes sense not to show a whole bunch of irrelevant items in the UI. You’re working from the assumption that change (ie; devices removed from the flow) only occurs if it’s a negative (broken, stolen) and not something chosen by the end user (just getting rid of a device they don’t like, or replacing with something dissimilar).
Can also be done for platform automations written in the UI.
Theses are not people who should be messing about in the registry.
I was explaining why it makes sense to the inexperienced home user as to why they’d want to hide automations, not that this is the route inexperienced home users should take. If you’re going to edit a YAML file, you probably at least know where they are to begin with.
As has already been pointed out, maybe platform automations are going away? You may riot, but I certainly don’t think that’ll be the consensus, nor a feature that the wider market that HA are obviously gunning for particularly care about.
Re: the registry. Looking at the registry is different than changing it. The only file that needs editing is automations.yaml, and that’s assuming:
a) This is not just an interim fix as the devs have zero plans in the future to address such situations.
and
b) The end user doesn’t just recreate the automation without first checking if there’s another way. Most users won’t have a need for ultra-complex automations that they can’t take 2 minutes to recreate.
I’m not a betting man but I’ll put money on that not happening.
And that supports my argument not to use them in the fist place as there is a perfectly acceptable alternative. That does not require the fix.
You and I are just going to have to agree to disagree on the current state of device automations and their balance of advantages/pitfalls.
Have a nice day.
For me, it´s working with the on trigger, but how am I supposed to initiate the shutdown from the media player card as I don´t see a shutdown button?
You could try the custom mini-media-player.
Fritske,
Thanks for this 
, but …
Don’t you have ‘1’ too many : - " entity_id: media_player.kodi_livingroom " In there ?
I reformated as : -
### Switches Kodi Off
- alias: au_media_kodi_turn_off
mode: single
trigger:
- platform: state
entity_id: input_boolean.ib_media_aeon_a01_sub
from: 'on'
to: 'off'
action:
- service: kodi.call_method
data:
entity_id: media_player.kodi
method: System.Shutdown
- delay: '00:00:20'
- service: switch.turn_off
entity_id: switch.switch_aeon_a01
Which seems to be working.
I have a fake switch (the boolean) which allows kodi to turn off gracefully before I pull the plug (just an explanation for any people wondering)
Thank you Mutt, got it working like this.
input_boolean:
tv:
name: TV
icon: mdi:tv
automation:
- alias: kodi_turn_off
mode: single
trigger:
- platform: state
entity_id: input_boolean.tv
from: 'on'
to: 'off'
action:
- service: kodi.call_method
data:
action: stop
entity_id: media_player.kodi
method: Input.ExecuteAction
- service: kodi.call_method
data:
entity_id: media_player.kodi
method: Input.Home
- delay: '00:00:02'
- service: kodi.call_method
data:
entity_id: media_player.kodi
method: System.Shutdown
- delay: '00:00:30'
- service: switch.turn_off
entity_id: switch.htpc_socket_htpc
- alias: kodi_turn_on
mode: single
trigger:
- platform: state
entity_id: input_boolean.tv
from: 'off'
to: 'on'
action:
- service: switch.turn_on
entity_id: switch.htpc_socket_htpc```As a workaround for the missing on/off actions, I’m proposing to wrap the Kodi mediaplayer in a Universal mediaplayer. That one still has turn_on and turn_off commands available. Do you guys know of any disadvantages to this approach?
In configuration.yaml:
- platform: universal
name: kodi_universal
children:
- media_player.kodi_livingroom # Your actual Kodi mediaplayer goes here
# The unavailable = off state is a workaround for a known issue at this time (0.116.2).
state_template: >
{% if is_state('media_player.kodi_livingroom','unavailable') %}
off
{% else %}
{{states('media_player.kodi_livingroom')}}
{% endif %}
commands:
turn_on:
service: script.turn_on
entity_id: script.turn_on_kodi_livingroom
turn_off:
service: script.turn_on
entity_id: script.turn_off_kodi_livingroom
Script turn_on_kodi_livingroom:
turn_on_kodi_livingroom:
alias: 'Turn on Kodi living room'
sequence:
- service: wake_on_lan.send_magic_packet # WOL for your Kodi machine
data:
mac: XX:XX:XX:XX:XX:XX
broadcast_address: 192.168.0.255
- service: remote.send_command # e.g. turn on Samsung television (as an example)
data:
entity_id: remote.mini3_remote
command: 'b64:JgVGAJSUEjcSNxI3EhISEhISEhISEhI3EjcSNxISEhISEhISEhISNxISEhISNxI3EhISEhI3EhISNxI3EhISEhI3EjcSEhIABaQNBQ=='
Script turn_off_kodi_livingroom:
turn_off_kodi_livingroom:
alias: 'Turn off Kodi living room'
sequence:
- service: kodi.call_method
data:
entity_id: media_player.kodi_livingroom
method: System.Shutdown
Edit: by adding the if-unavailable in the state template, this also work around this issue I believe:
Hello, is there a working way to turn off kodi (libreelec)?
Based on the information on this page
the task of simply turning off the player requires
alias: 'Kodi: turn off'
description: ''
trigger:
- platform: device
device_id: 034f06723c7********9d46f6da6c18
domain: kodi
entity_id: media_player.tv1
type: turn_off
condition: []
action:
- service: script.kodi_turn_off
mode: single
and to this you need to add the script itself
and I can’t do it, the construction is like
script:
kodi_shutdown:
sequence:
- service: kodi.call_method
data:
entity_id: media_player.tv1
method: System.Shutdown
does not work
sequence:
- service: kodi.call_method
data:
entity_id: media_player.192_168_1_201
method: System.Shutdown
Works for me.
I had to delete my yaml setup
Use Auto discovery (have kodi running when you restart HA)
I think I then found a new device and it created the entity (replacing the '.'s with '_'s
(this is the vague bit as I didn’t document it)
It works but I do have vague feelings of unease. The old method was straighforward and positive.
This method seems like you have to perform a ritual and have your tongue out at the “right angle”
Where is your script? In automation?
I’m not sure I understand your question.
My script is in scripts, that’s where all scripts are required to be
Some people store scripts in configuration.yaml
Others in script.yaml
I actually use packages so I can store them in any package
Mine happens to be in /config/packages/misc/media.yaml
But I’m not sure how that makes any difference
Though if you are storing yours in automation.yaml then that will just cause errors.
1 Like
Blockquote
The following scripts can be used in automations for turning on/off your Kodi instance; see Turning on/off. You could also simply use these sequences directly in the automations without creating scripts.
Blockquote
Seems I don’t understand this.
That means you can ‘call a script from an automation’
Or you can use the section from the script (ie without the ‘sequence:’ header) directly in an automation.
So when do you want to shut kodi down (ie just one trigger or multiple instances ?)
I have it shut down when my TV is switched off
1 Like