2023.7: Responding services

I really feel good about this project and have no regrets ever supporting it. What I like most though, is the documentation and style of communication - top notch! Pretty hyped about this month’s release!

5 Likes

not sure I understand this cryptic message? what exactly am I supposed to do here? didnt see a breaking change either

1 Like

You should (not?) check out frenck’s Spook: GitHub - frenck/spook: Spook 👻 Not your homie

1 Like

It’s likely the QNAP integration, who’s YAML is now depricated.
When it was updated, there was a small miss in that it seems they forgot to include the data for the repair message to display. See below:

Same here.

Am looking forward to checking out some of the new features, but instead have spent the whole night trying to figure out why my Fully Kiosk integration isn’t working. I know this is now an official integration as of this release, but didn’t see anything in breaking changes. Looks like I’m not the only one having issues: Setup failed for fullykiosk: Integration not found. Misery loves company! Note, was working perfectly for all of my kiosks prior to update.

1 Like

My history cards are freezing my Chrome browser and my iOS companion app after this update. I’m using the built-in recorder/db. Didn’t have issues before this.

1 Like

anyone get deep linking to work with the apple tv for twitch?

Nice update. Upgrading from the beta right now.

Great work, tnx!

I had some catching up to do for my HA admin, great release. Thanks guys/gals.

Same here. It seems there is a limit of eight entities. I don’t know if this limit is new, but I have had more than that without issues before 2023.07.00. In my case, the history graphs that are freezing have more than eight entities on them.

Were you still using the HACS version? I got an alert before the new release yesterday that it was now archived and I needed to remove it. I had to move over to the official version now.

that documentation is not too clear yet tbh…

trying to follow that using:

template:

  - image:

      - unique_id: my_first_tmeplate_image
        url: >
          /local/images/bonen.jpg

# or use
        url: >
          {{'/local/images/bonen.jpg'}}

(note: I did make a typo there…) I get something really odd in the states:

first of all, the naming: with regular templates, those names are taken from the unique_id, and, if one does not set a name: the prefix template_ is added to the unique_id, and set as entity_id, and name. Following that logic, I would have expected:

image.template_my_first_tmeplate_image, and a friendly_name of template my first tmeplate image

also, the url seems to be incorrect (though the image file does exist):

so that url probably has the incorrect syntax.

all in all, this template image does not behave the same way the other templates do, even considering I made a few mistakes here

ive edited it a bit to:

      - unique_id: my_first_tmeplate_image
        name: My first template image
        url: '/local/images/bonen.jpg'
        picture: /local/images/bonen.jpg

and now get:

as proof the image is correct.

The url is not yet. Can anyone shed some light on the correct syntax/requirements for that please?

edit

forget all of the above, there’s an error in the log:

Request URL is missing an 'http://' or 'https://' protocol.

really odd the config checker does not error on that config error of mine

changing to:

      - unique_id: my_first_tmeplate_image
        name: My first template image
        url: 'http://<my_server>.local:<port>/local/images/bonen.jpg'
        picture: /local/images/bonen.jpg

cleared that up.

remaining is the odd naming convention, which is not consistent with other template behavior?

Anyone else with the slim proto media player (Squeezebox Player) seeing this?

Logger: homeassistant.setup
Source: setup.py:379
First occurred: 16:32:28 (1 occurrences)
Last logged: 16:32:28

Unable to prepare setup for platform slimproto.media_player: Platform not found (Exception importing homeassistant.components.slimproto.media_player).

EDIT: opened an issue:

1 Like

Seems odd that you have to supply a URL and a picture option.

Wow, since upgrade last night my log file is 700MB. Let’s see what’s inside…

1 Like

Hi. I updated to 2023.7 and i dont have copy and past cards and also dont have number cards. Why?

I have 4 players here and Squeezebox integration (Logitech Media Server) and everything works as expected in HA version 2023.7

1 Like

the picture is for the entity_picture, the url is for the actual image
would have been neat if that would have auto set to the actual image. I havent tried that yet, so will do so now and report :wink:

update

changing that config to

template:

  - image:

      - unique_id: my_first_tmeplate_image
        name: My first template image
        url: 'http://<my_server>.local:<port>/local/images/bonen.jpg'
#         picture: /local/images/bonen.jpg

does indeed auto set the entity_picture to the image in the url:

we can override that though, so that is nice:

      - unique_id: my_first_tmeplate_image
        name: My first template image
        url: 'http:/<my_server>.local:<port>/local/images/bonen.jpg'
        picture: /local/images/espresso_art.jpg

the access token changes on each of those, so I must give the another check as I dont understand yet what that is/does.

for the frontend:

  cards:

    - type: entity
      entity: image.my_first_template_image

    - type: picture-entity
      entity: image.my_first_template_image

    - type: picture
      image: 'http://<my_server>.local:<port>/local/images/bonen.jpg'

considering the last type: picture I wonder what the added value of the new image template will be over that, being the identical url.