2024.1: Happy automating!

Email [email protected] which is indicated on the yellow website (https://yellow.home-assistant.io/) via the support button.

EDIT: I see you’ve already emailed

Hello,

Thank you for all your responses. I hope that this gets sorted because I miss my smart home :pensive:

Many thanks to @nabbi for the zoneminder fixes in 2024.1.3. More manual work-arounds eliminated!

Does anyone have the Spotify DJ support working that was added in 2024.1.3? I’m getting the same behavior that folks described before this update

Hello,
after updating to the latest version of HA 2024.1.3 I have problems with the Eva II Pro Wifi Midea Inventor Dehumidifier: I no longer see the “tank_show”, “fan_speed” and “fan_speed_mode” attributes.
The integration has been updated to accommodate the deprecation of constants and works well; the services to change the fan speed also work though if I go in
“Developer Tools => status” I can see the following attributes:

min_humidity: 40
max_humidity: 85
available_modes:
  - Target_humidity
  - Continuous
  - Smart
  - Dryer
current_humidity: 66
humidity: 55
mode: Smart
device_class: dehumidifier
friendly_name: midea_dehumidifier_23089744199949
supported_features: 1

and only for a few seconds I can see the attributes tank_show", “fan_speed” and “fan_speed_mode”, then they disappear.
I don’t think it’s an integration problem since it works but without those attributes the automations fail me.
Is there anyone else having the same problem as me?

As far as I see this is a custom component. Have you raised an issue in the respective GitHub repo?

Of course, but they haven’t answered me yet.

Is there more insight into how these changes are decided coming to the blog? I am sure that there was more consideration than just a focus group (of new users?) and I would be very interested to read about it.

2 Likes

I am also haveing problems with my Sonoff motion detectors. Every time I look for the Entities for the motion detectors they seem to change. I reverted back to 12.4 everthing works.

@dhaker Did you update via HACS the SonoffLAN by AlexxIT to 3.5.4?

Has the manufacturer for all Philips hue devices changed from signify Netherlands to Philips in this update?

Would be nice if it was noted in the breaking changes if so

None of mine changed:

What did it break?

The Home Assistant integration just passes on the device manufacturer names it gets from the Hue Bridge, so even if they changed it would be unlikely to be on the HA side.

I upgraded to 2024.1.3 earlier today.

This seems odd. Is anybody else experiencing the same?

{{ "123" | has_value }}
{{ "abc" | has_value }}

Both yield False.

These are just examples. It started with real sensor values doing this.

Both those statements in the Developer Tools > Template page of 2023.12.4 show False as well, so not sure it’s a 2024.1.3 thing.

Thanks for confirming. I upgraded from 2023.11.3 where it did work. I skipped 2023.12.

I’ll wait for more comments before logging a bug. I checked and didn’t see one on the core repo.

Did that ever actually work? I believe has_value is implemented as a function, not a filter; so it should be used like has_value("sensor.some_entity_id"). The code itself hasn’t been touched in ~ 10 months either, so if it did work previously, it likely was accidental and maybe some external factor caused a change in behavior.

Edit - Sorry, didn’t see the 2023.11.3 reference. If that’s the case, I’m guessing that the later portion of my statement is likely. Can you try switching the usage to calling it as a function?

1 Like

has_value needs an entity_id as input, eg {{ 'sensor.energy' | has_value }}

It never worked on a value itself, that’s why it’s called has_value and not is_value

4 Likes

You used ’ ’ whereas Pieter used " ". Is that important?