2023.7: Responding services

Does filtering work in your setup?
Cause it does not in mine.

Thx, I used the subset text I posted, and seems to work.
Together with all other filters I have in place.

Never figured we could use wildcards there too!

Those can not be filtered. Loader is something special, though I don’t recall why, sorry.

Do you mean - messages of some components cannot be filtered?
Too bad this is not mentioned in Docs.

Update: tested with other components (now and earlier) - no filtering.
So this is not about just “loader”.
Need to check more.

Update: I see, for some components filtering works, for some - does not…
Well, anyway this is a good news for me)))
Although 95% of my filters do not work.

I wonder - is anyone using “Demo” platform?
Haven’t you noticed anything weird about the recent changes?

Updated to 2023.7.1 today, ever since I’ve been experiencing a lot of freezing in the front end just doing basic tasks.

I see there are a few others but I’m wondering if this is widespread with a known fix or just isolated incidents?

Thank You, Team Nabu Casa!

Thanks again @Taras! This did the trick!

maybe bring this to a separate topic, because all of the filters work (can show what I use, but that might be considered spam here…), except the ‘Loader’ which probably isn’t even considered to be a ‘component’

could you please follow up on Taras earlier question too, and explains bit what brings about these triggers

It’s just that I am trying to figure out why and how, so even if this is a bit of a silly automation ( no offense meant ofc, but I dont think one would actually use this in HA as is currently, seems more of an experiment) Id still love to grasp the inner workings ;=)

If you set homeassistant.loader: error, it will filter those out

@Marius in this specific case automation is triggered by change in album name attribute of media_player entity. In my later post you can find whole automation, so you can see triggers too. So nothing fancy. I’m just trying to recreate sort of roon web display finctionality; every time album is changed I ask ChatGPT for information about this album (interesting to read, as responces are varying over time and sometimes something interesting can be found. I’m not trying to use here any type of music service (something like IMDB for music) as I’d expect length of response to vary, but asking the right question to ChatGPT I can limit lenght of response to something I can fully fit onto screen (I’m actually planning to put Samsung The Frame next to my audio gear to display this). So might be not very functional automation per se, more designed to enrich listening experience and yet showing what H A can be used for :slight_smile: Here is how it looks now:

Regarding other use cases; I just wanted to highlight that it is easy to retrieve long infomration string from internet (parsing json, scrapping web page etc), but storing of such data is not easy and requires some trickery, as in example we just went through. That’s why having possibility to use sort of input_text.set_attribute service and put very long text there would be huge simplification.

5 Likes

Thx, and yes this might actually be very nice and enriching indeed. I have to reconsider my initial perspective on that. Cool
And thx for your elaboration.
Might even have to install ChatGpt now…

Regarding the new “image” entity:
I am 100% sure that it should work with this:

template:
  - image:
      - name: test_image
        url: '/local/images/test/pink.jpg'

w/o specifying http, https, ports etc - in case of locally stored images.
“Should” - means “from a noob user’s PoV”.
In all other places of HA we use either “/local/…” path or “http(s)://…” path when needed.
See no reason why the “image” entity is an exception.

input_boolean:
  test_xxxxxxx:
  test_xxxxxxx_2:

homeassistant:
  customize:
    input_boolean.test_xxxxxxx:
      entity_picture: '/local/images/test/pink.jpg'
    input_boolean.test_xxxxxxx_2:
      entity_picture: 'https://design.home-assistant.io/images/logo.png'

Here is no difference, both paths are accepted.


It could be not a bug but a poor functionality.

that would have been a different approach indeed, not trying to filter logged messages, but set loglevel to a lower level (than my default warn) in the first place.

Doesn’t work though, all warnings are still logged. I fear it’s like I mentioned above, Loader is not the regular component, and can not be filtered/altered. I have that on authority of one of the core dev’s…

Not sure why it’s being characterized as “trickery”.

What petro suggested leverages the strengths of a Trigger-based Template Sensor, namely the ability to set its state, and/or attributes, to whatever you want via any kind of trigger. In other words, the example is using a Trigger-based Template Sensor the way it’s meant to be used.

The example ‘publishes’ the data via a custom event:

      - event: chatgpt_response
        event_data:
          entity_id: "{{ trigger.entity_id }}"
          response: "{{ chatgpt.response.speech.plain.speech }}"

The Trigger -based Template Sensor ‘subscribes’ to the custom event and receives the data (via trigger.event.data.response):

      - platform: event
        event_type: chatgpt_response
        event_data:
          entity_id: media_player.volumio_2

The Trigger-based Template Sensor uses the received data to set the value of one of its attributes. Easy-peasy (and that value survives a restart).


FWIW, what petro suggested is something I first discovered from these examples by CentralCommand and TheFes:

It’s a pattern I have also employed to fulfill other applications that require storing a value in a sensor’s attribute (with and without the use of custom events). Examples:

Message Queue

Last Ten Motion Detectors

Bad Shutdown Sensor

Song History

It’s a useful design pattern and far from being ‘trickery’.


Your proposed new service call, input_text.set_attribute, would probably need to be called multiple times, once for each attribute you wanted to set … unless it supported setting multiple attributes at once. Here’s a mockup of what the service call could look like:

service: input_text.set_attribute
target:
  entity_id: "input_text.{{ trigger.to_state.object_id }}"
data:
   attribute: album_description
   state: "{{ chatgpt.response.speech.plain.speech }}"

The main difference is that creating an Input Text is admittedly easier than a Trigger-based Template Sensor. Unless there’s an existing Feature Request, feel free to post a request for this new service call.

5 Likes

It does filter them from the log gui, not homeassistant.log

Hmm, this is not mentioned in Docs.

Reolink Cameras, using picture-entity lovelace pages is no longer working correctly.

The picture entities take 4-10 seconds if not timeout completely to display the camera. 2023.6.3. the images loaded immediately. Upgraded to 2023.7.1 and this problem started. On the one page I have with 5 cameras on it, it takes a good 20 seconds for most of them to come up and 1 or 2 have a broken image - sometimes 30 seconds later the broken ones will fill in. It then will often miss refresh updates or timeout while you watch it.

Back down to 2023.6.3 and it works perfectly again.

Live versions of the cameras using WebRTC gets the cameras in live real-time instantly.

It’s only the 10 second refresh picture-entity card that is causing this only seemingly on reolink cameras. (I use picture entity for weather radar and other refreshing images, and they still work and refresh perfectly) …

Hmm.

Dave

No you’re right but that’s what happens for me. The loader messages appear in the log file but not in the gui