2024.1: Happy automating!

sorry if my answer was misleading… it was just generally spoken… it is something I blame the authors of custom integrations - to not take the required steps to fix deprication issues during the beta-test phase, especially, if these are pretty easy fixes and well documented.

it is frustrating for me, that users run into such issues ‘repeatingly’ when a major HA update (and we should all know the update cycle) are available.

For this month, I’ve submitted PRs to so many integrations, while running the BETA… and I don’t think, that this is the task for a user (to run beta and monitor what the integration from someone else might do - or not)…

I cannot really understand the lack of responsibility from the authors - if they provide their work to such a large community …

It might be different if you are using components, that are abandoned and not maintained anymore … but then, there was probably no update for years and sometimes many old issues still open. In this case, the user could “imagine” that he might run into issues at some point.

2 Likes

Seems there is an issue already opened (for somewhat similar case) and also I can see that in the dev version (2024.2.0.dev20240102) it is already behaving differently:
image
Edit: actually not really, sometimes it shows again without state and both icons are active. Here it the issue:

i had a seperate sensor.yaml file, it was there

1 Like

This is already fixed Get Shelly RPC device `gen` from config entry data by bieniu · Pull Request #107019 · home-assistant/core · GitHub

1 Like

After upgrade to 2024.1, my Midea Dehumidifier BA80 not working anymore. I use Midea Air Appliance (LAN). Also System Monitor have issues. Reverting to 2023.112.4, everything back to normal. Can anyoane help me ? I am new in this. Tks in advance.

There is a “fix” for this Sonoff Custom Component issue mentioned in the GitHub issue if anyone is reading/posting here and not checking the component’s repository on GitHub

@BebeMischa @Lucianosouza99 @lordwizzard just tagging as you posted about this issue too so might be of interest

1 Like

The real problem is not the faulty device but the fact that whole automation (with not affected items) is stopped.

BTW if the solution is so easy why there is no quick fix via “repair” functionality?

1 Like

the problem is, that with (i guess it was 2023.10 or .11) for some entities the UID has changed.
I don’t really know the reason for this detail, but some automations I had were also affected.

Open the Automation, re-add the Entity (with the new UID) - and everything should be fine.
Why is there no easy fix that can be rolled out automatically?

→ Because UIDs are a unique identifier and should Identify the entity / device.
It this ID changes, only YOU might be able to select the correct Entity you want to have in your automation.

if this is not the case, then more specific information like screenshots or logs might help further…

Ok I now understand your point and frustration regarding responisbility to author’s or maintainer’s of an integration.

Solved.
car_mod card was already updated to 3.4.x.
Now adding ‘card_mod:’ before ‘style:’ is mandatory.

Are you referring to this custom component for your dehumidifier?

As has been pointed out several times in this thread, it is the responsibility of the custom component developer to stay on top of these changes, so not really an issue for a core upgrade thread. Assuming, this is the component you are using, it seems a fix is discussed here.

As for system monitor, this is mentioned in the changes for the release. The integration has been moved from a YAML configuration to being configured via the UI. It should have been done automatically for you as part of the update, and you should have seen a repair notification, or at least something in the logs. If that was not the case, then you should probably report that as a bug.

1 Like

Are you referring to the official integration or the custom component from HACS? In both cases logs would help to understand why it “does not work”. Have you already submitted a Github issue?

The AVM FRITZ!Box Tools integration also fails in 2024.1.0. The WIFI switches are not able to turn WIFI on or off.

User TRyan84 already opened an issue on github: Since update to 2024.01 problem with AVM FRITZ!Box Tools · Issue #107106 · home-assistant/core (github.com)

the repository you have linked to doesn’t seem to be alive, to me.
recent changes are already from february 2023 - since then, no updates, no PRs merged and a couple of pretty old issues.

It should not be too hard to fix the depricated constants, etc… but if no one will merge the PRs, it doesn’t help much.

I would consider to check for another Custom Integration which is more up to date (if one is available)

As far as I could remember, I had this issue for a couple of versions now… :thinking:
Can’t remember that this has just changed with 2024.1. …

I lost use of the SwitchBot Bluetooth and Mobile App integrations. Reboot did not fix it. Reverted to a backup and all is well.

I know better than to upgrade to a .0 release but I was hopeful. I’ll stay in 2023 for a while I guess.

Nope, on my setup it came with 2024.1.0. All the other stuff stayed on the same level. Rolling back to 2023.12.4 makes the WIFI switches work again.

Well I suppose it could be this one, but it doesn’t seem to have been fixed either as yet. Hard to tell without the OP giving more details.

In any case, I don’t use either integration, but I was only trying to help, as I managed to resolve a few of these outdated custom components breaking on my setup in the beta. It’s a simple fix as you say, even for a non-coder like me.

1 Like

Yes - broke my Sonoff integration as well - restored back to 23.12 and will keep an eye on our for any further news on this being resolved.

I have used custom integrations, cards as well as testing the beta. As the custom is not part of the core, it is not any authors responsible to update. Some do and some don’t. It is the users responsibility to understand the risks in using custom software.

2 Likes