2021.12: New configuration menu, the button entity, and gorgeous area cards!

[san4essss]

@MNL

Now you find it at Configurarion, Add-ons/Backup and Supervisor, and from now you know it again

Ahh, thanks a lot. I expected it in a new place )

[petro]

device_id has never been supported in the limited templates, not sure how that worked prior to 2021.11

[dshokouhi]

@klogg

How are non admin users supposed to change their settings in the Companion App?

Non admin users have it at the same location as previously in the sidebar, make sure to be in the latest point release

[elik745i (El Nur)]

Integration is available through HACS

[klogg]

Thanks for coming back.
I’m on 2021.10.0-full

[dshokouhi]

I am talking about HA core, it was brought back for non-admin users in 2021.12.2

[Krammie (Mark)]

Same here; media_player.media_stop does not work anymore after the update.

[andwei49 (Andrew)]

This is really the same after every update. Something no longer works afterwards, which previously worked for a long time. Just totally annoying!

[avd706]

need to specify Andriod or iOS or are they called differently?

[dshokouhi]

as mentioned 2 comments above yours…HA core and not the mobile apps.

2021.12: New configuration menu, the button entity, and gorgeous area cards!

I am talking about HA core, it was brought back for non-admin users in 2021.12.2

[maurizio53 (Maurizio Fabiani)]

Suddenly also the “volume_set” service is broken…
This is what i can see in the log:

Error executing service: <ServiceCall media_player.volume_set (c:22f001f9e13158937236415ef241318e): entity_id=all, volume=0.6>

[Sriracha]

Weird, I was using this ever since I upgraded to zwave JS a few versions ago up to 2021.11.3 until 2021.12.

If this is not supported, is there another way to trigger on zwave event of a specific device? Hardcoding the device_id is not very friendly unfortunately.

I could put it in a condition, but it is not really clean either.

[maxym]

@andwei49

This is really the same after every update. Something no longer works afterwards, which previously worked for a long time.

And you have to chose between one or another suboptimal build

you can vote for making HA more modular in terms of deployment. Not that it will resolve all issues.But likely would help a lot

Feature Request: Allow update and back-level integrations individually

Most people depend on multiple different integrations in their HA system. These integrations change all the time (which is good.) But the testing is, by its nature, very difficult for one developer to do. There are so many different environments out there, it’s almost guaranteed that fixing one bug or making one update will introduce another problem for some users. Lately it seems these bugs are creeping into merged integrations more and more. I use one integration which was changed in version …

[VincentClement1 (Vincent Clement)]

Just noticed with the 2021.12 release that the TP-Link Kasa Smart integration creates two switch entities for every plug that has a lamp. For the plug I use to turn my Christmas tree on and off, the first entity is named switch.christmas_tree and the second entity is switch.christmas_tree_led. This did not happen with 2021.11 or earlier.

On the device page for this plug, switch.christmas_tree is listed under Controls and switch.christmas_tree_led is listed under Configuration. Both entities turn the light on or off.

As far as I can tell, the integration is adding the switch.X_led entity based on icon selected in the Kasa app as I have two plugs that used for battery chargers and there are no switch.X_led entries for those plugs. So it’s only a lamp or light that has the switch.X_led entity added.

I can’t find anything about this in the documentation or in the release notes as to the change or purpose. I don’t appreciate the integration assuming that the lamp plugged into the plug is an led - because at least two of the lamps aren’t leds.

[CaptTom (Tom)]

@VincentClement1

Just noticed with the 2021.12 release that the TP-Link Kasa Smart integration creates two switch entities for every plug that has a lamp

My two TP-Link smart plugs don’t control lamps, and don’t have any lamp-like icon associated with them.

But I checked, and yes, I have the _led entities there now, too. Likewise, some previous release changed the name of the “consumption” entities, but I figured that out and changed everything over to the new one.

I agree that these kinds of changes need to be better communicated.

[Gav_in]

Hello @CaptTom and @VincentClement1
This change to Tp-Link/Kasa is there a few releases now (.9 or .10 I think) and was documented. It’s not a change in .12 so is not mentioned here. Maybe worth a read of the older release notes/blogs before jumping into posting, particularly if you’re not just upgrading one version number.

The “_led” entity for the plugs does pretty much what it suggests…it controls the LED light on the plug and can turn this on/off

[avd706]

oh sorry, got mixed up with a different comment.

[Pucki]

Thanks but doesn’t seems to bring the solution.
Just tested with an VM and my backup before updating from 2021.12.1 to 2021.12.2. Everything’s fine before doing the update. After “ha core check” came up with the error.
Unfortunately I can’t downgrade easily.

[andwei49 (Andrew)]

@Feature Request: Allow update and back-level integrations individually

Most people depend on multiple different integrations in their HA system. These integrations change all the time (which is good.) But the testing is, by its nature, very difficult for one developer to do. There are so many different environments out there, it’s almost guaranteed that fixing one bug or making one update will introduce another problem for some users.

Lately it seems these bugs are creeping into merged integrations more and more. I use one integration which was changed in version 8.0, which made it unusable. I had to back-level HA to version 7.4. It looks like that integration might be fixed in 10.5, but now I’m reading reports of two other integrations I need becoming unreliable in that version.

The longer a user stays at an old version, the more breaking changes there will be, requiring a lot of re-work when they finally upgrade. And since bugs aren’t included in the list of breaking changes, there’s no way for the user to know whether there will be other broken integrations requiring them to back-level HA again.

I’d like to see a more modular approach, where the integrations can be updated or back-leveled separately from the core, right in the UI. It may be as simple as including core integrations on the “Integrations” page in the GUI, and offering previous versions there along with the current version.

A user could then update the core, but back-level a problem integration until that one is fixed.

Thanks for the tip!

Just the fact that the last updates, within a few days immediately two, three, four more updates are delivered, but clearly shows that there is a problem with the quality and reliability.

Apart from that, the documentation is simply bad. Especially when it comes to the impact of new features or changes on the previous configuration or hardware.

[nickrout]

Contact. The. Author.