Kodi on/off actions in 0.115

  • Your turn on/off actions will not be imported. This functionality is now available through device triggers.

Before I upgrade to 0.115, could someone kindly give me an example on how this would look like, as I havn´t used device triggers yet.

Thank you and Happy updating weekend!

You’ll have to make automations for this, really simple.
As trigger, select device and you’ll have a dropdown with the choice for trigger when turning off or on.

Beware though, as of know it seems the kodi.call_method doesn’t work properly in the new release.

See this issue:

What about if you use yaml instead of the automation editor?

Right now, everything is working fine with the below config, but in the release log for 0.115 it sounds like it would be better to switch to the UI config?
If this is supported in the future, I´d rather keep my current config.

  - platform: kodi
    name: kodi-livingroom
    port: 8080
    tcp_port: 9090
    username: kodi
    password: kodi
      service: script.kodi_livingroom_shutdown
      service: switch.turn_on
      entity_id: switch.tasmota11_kodi_livingroom_power

Not just better, required.

this works for me:

  alias: kodi  shutdown
  - service: kodi.call_method
      entity_id: media_player.kodi_livingroom
      method: System.Shutdown
    entity_id: media_player.kodi_livingroom
  mode: single

So, I’m a little confused as to how I would get my current setup working on a “discovered” Kodi. I have a separate Hyperion setup that gets turned on and off with Kodi. The Kodi box runs 24/7, and so all that’s really getting turned on and off is the TV (via the Kodi CEC-JSON plugin). It’s a pre-Smart TV, and so it’s the only way I can turn it on and off is using CEC.

 - platform: kodi
   port: 8080
   name: kodi
   username: kodi
   password: *******************
   enable_websocket: true
   timeout: 10
   - service: kodi.call_method
       entity_id: media_player.kodi
       method: Addons.ExecuteAddon
       addonid: script.json-cec
         command: activate
   - service: switch.turn_on
     entity_id: switch.ambilightcontrol
   - service: kodi.call_method
       entity_id: media_player.kodi
       method: Addons.ExecuteAddon
       addonid: script.json-cec
         command: stop_and_standby
   - service: switch.turn_off
     entity_id: switch.ambilightcontrol

How do I then integrate this into the new setup method?

I also have scripts to turn kodi on/off. But with new integration how do set them up? automation.yaml?

You’ll have to set them up in Automations in the UI now.
Separate turn on and off automations are required, the following is for the turn on automation.

Create new automation, press “skip” button in bottom left.

Name your automation (“turn on kodi” or whatever you’d like), it should be single mode.

Create a trigger—

Type: Device
Device: [your kodi name]
Trigger: "[your kodi name] was requested to turn on"

Then set up your actions are required. In my case, I had two actions. A script triggering the Hyperion lights, and a Call Service to turn on the display via the Kodi JSON-CEC plugin.

In the case of the latter—

Action type: Call Service 
Service: kodi.call_method
Name(s) of the Kodi entities...: media_player.[your kodi name]
Service Data:
  method: Addons.ExecuteAddon
  addonid: script.json-cec
    command: activate

Basically, as a “turn off” automation, it’s the same except the trigger changes to “[your kodi name] was requested to turn off” and the command it the Service Data changes to “stop_and_standby”

Yeah, stuff that for a game of soldiers. Device automations are an abomination.

If you create device automations and have to replace your device (faulty, stolen,etc…) then you have to rewrite all your device automations associated with that device as the unique device ID can not be duplicated. It’s not like you can just edit the device automation to change the old device id for the new, as the automations disappear from the UI.

If it was a platform trigger all you have to do is match the entity id of the old device wit the new.

So no thanks.

Ooops, Fantastic feature. never used it yet. And looks will not try.

So look up the UID of the new device in the device registry and manually replace it in the automations.yaml. Hiding automations tied to a missing device makes sense from a ease-of-use standpoint.

If you wanna mess with YAML all day long, you still can.

:rofl: ROFL

A simple edit of my new entity id (from the UI) vs digging around in the undocumented registry. Not only that but I might not even have to edit the “_2” from the new entity id if I delete the integration before adding the new device.

Yeah I’ll take “all day long” thanks.

Nope. It’s like a bandaid on a severed limb.

Device automations are badly flawed from an ease of changing physical devices point of view. Platform automations are not.

1 Like

I’m putting this here for others, as I’m pretty sure you’ve got your mind made up and are just here to complain.

Fancy you can do it better? Fork the repo. Change the code to suit your needs. Don’t expect the devs of this free software to shift their direction to suit you. As a JSON formatted (Key/Value) file, the “undocumented” device registry isn’t particularly hard to read or understand. You’ve got a list of devices, and those devices have attributes. We aren’t editing hex here.

For everyone else:

My guess is that the devs have a plan for the changing of automations with missing devices, but this software is in frequent development and things change all the time. 0.115<1.0, after all. So many things have changed in the last 8 months I’ve been using it, and has shown me the team is excited and eager to make this as user-friendly as possible.

Now, examples from my setup. No need to edit .storage/core.device_registry, just run a find on the device’s name. (In my case, “KodiLivingRoom”).

The “id:” here in this entry corresponds to “device_id:” in the Automations.yaml.


                "config_entries": [
                "connections": [],
                "identifiers": [
                "manufacturer": "Kodi",
                "model": null,
                "name": "KodiLivingRoom",
                "sw_version": "18.8",
                "entry_type": null,
                "id": "5149e4c0fa6c11ea811d2beece028f9b",
                "via_device_id": null,
                "area_id": "85455ebc94c548c58a1ba9eef74199ff",
                "name_by_user": null

Your entity id is right there (as “id”). Copy it.

And the corresponding automation entry from automations.yaml:

- id: '1600571146194'
  alias: Turn on Kodi Livingroom
  description: ''
  - platform: device
    device_id: 5149e4c0fa6c11ea811d2beece028f9b
    domain: kodi
    entity_id: media_player.kodilivingroom
    type: turn_on
  condition: []
  - service: kodi.call_method
      method: Addons.ExecuteAddon
      addonid: script.json-cec
        command: activate
    entity_id: media_player.kodilivingroom
  - service: switch.turn_on
    data: {}
    entity_id: switch.ambilightcontrol
  mode: single

Make a backup copy of the automations.yaml, then literally copy the “id” from the core.device_registry entry and paste it into “device_id” of the automation in automations.yaml. Make sure quote marks and commas are removed when pasting. Not particularly hard, a bit daunting for the inexperienced perhaps. No chance of permanently breaking anything useful, even if you’ve made a backup. Restart home assistant. Voilà.

No, I’m trying to convince you that rather than jump through all those hoops you just outlined all you have to do is avoid device automations and use platform automations (which can still be constructed in the UI if you wish).

What you just wrote is a hell of a lot more work, and prone to disaster, rather than just clicking on an entity id and editing it.Which is all you need to do if a device is replaced and all you have are platform automations.

You know that I’m a great supporter of yaml methodology …


Given that my config has been complaining about my : -

# media_player:
#   - platform: squeezebox
#     host:
#     port: 9000
#   - platform: kodi
#     host:
#     turn_off_action:
#       service: kodi.call_method
#       data:
#         entity_id: media_player.kodi
#         method: System.Shutdown

… for about 6 past releases and ‘this’ is the chosen future.
Also my abilty to shutdown Kodi Broke (I think with 0.115.2, not sure)
But this morning I went though the ‘magically appearing (interfering) new kodi integration’ and changed the devices entity_id back to it’s old name, it seems to be working again now.

What else can we do ? Stay on 0.115.1 ???

Edit: no my normal shutdown doesn’t work anymore, I’m going to have to investigate device options :face_with_symbols_over_mouth:
Edit2: didn’t have to play with devices, I used Fritske’s code from post 6 - which works fine

I have no issue with the new Kodi integration. I’m using it. It works fine.

I have an issue with device automations. Which the release notes said we must now use for certain actions. That is not true. This works: Kodi on/off actions in 0.115 Not a device id to be seen.

1 Like

I have NFC as to these ‘device’ automations, there’s just TOO much to adsorb absorb (no I wish to retain it) of late and I have bigger fish to fry trying to sort out my sensors.
I’ve corrected over 120 sensor templates but the logs say I still have 7 (two binary, 5 not) and not a f3k1Hg clue as to where they are.
I going to have to rename some yaml files and that’s a LOT of restarts


But maybe this is transitional and will be fully deprecated ?

I’ve finished all my binary and sensor templates. Finished the time triggers using helpers now (great improvement). Now working on template conditions -> helpers.

Why, you don’t need to ?