2024.12: Scene you in 2025! 🎄

[erikm]

It turned out to be too much hassle, so I gave up running hass core and moved to container based deployments. Most of the work was to give the container access to the SkyConnect stick and the fail2ban log. Here’s my Docker compose file:

version: '3.7'
services:
    home-assistant:
        container_name: home-assistant
        image: homeassistant/home-assistant:2024.12.3
        restart: always
        user: 1000:1000 # UID and GID of the 'pi' user on the Raspberry Pi host
        group_add:
            - 4  # 'adm' group for fail2ban log
            - 20 # 'dialout' group for SkyConnect stick
        environment:
            - TZ=Europe/Amsterdam
        devices:
            - '/dev/serial/by-id/usb-Nabu_Casa_Home_Assistant_Connect_ZBT-1_fcbd3b7b7b31ef11985b51cfdfbc56eb-if00-port0:/dev/serial/by-id/usb-
Nabu_Casa_Home_Assistant_Connect_ZBT-1_fcbd3b7b7b31ef11985b51cfdfbc56eb-if00-port0'
            # target should be something like /dev/skyconnect for new installs, but this is
            # a migration so keep the old name
        network_mode: host
        volumes:
            - type: bind
              source: /home/pi/.homeassistant
              target: /config
            - type: bind
              source: /var/log/fail2ban.log
              target: /var/log/fail2ban.log
              read_only: true

Right now I have also included the zwave-js-ui service in the same Docker compose file and made the home-assistant container depend on its health, but this dependency could also be made in the systemd unit files.

[Mariusthvdb (Marius)]

finally getting to the title feature: creating a scene in the UI…
I am stuck however, and must be doing something wrong entirely.

Id love to create an ‘off’ scene for a given set of light entities.

no matter what I try I can only add several entities to the new scene, but dont get where I should enter the desired state I want them to be in

In neither mode there is an option to set attributes or states?

seems the editor takes the current state of an entity? because the yaml shows

name: Nieuwe scène
entities:
  light.achterdeur:
    min_color_temp_kelvin: 2202
    max_color_temp_kelvin: 6535
    min_mireds: 153
    max_mireds: 454
    supported_color_modes:
      - color_temp
    color_mode: null
    brightness: null
    color_temp_kelvin: null
    color_temp: null
    hs_color: null
    rgb_color: null
    xy_color: null
    is_hue_group: true
    hue_scenes:
      - Helder
      - Gedimd
      - Nachtlampje
    hue_type: room
    lights:
      - Achterdeur lamp
      - Achterdeur spot 1
      - Achterdeur spot 2
    entity_id:
      - light.achterdeur_spot_1
      - light.achterdeur_spot_2
      - light.achterdeur_lamp
    dynamics: false
    icon: mdi:lightbulb-group
    friendly_name: Achterdeur
    supported_features: 40
    state: "off" # <---------------------------- this is the current state
metadata:
  light.achterdeur:
    entity_only: true

how does this get close to the yaml ease of creating a scene with these options:

# Example configuration.yaml entry
scene:
  - name: Romantic
    icon: "mdi:flower-tulip"
    entities:
      light.tv_back_light: "on"
      light.ceiling:
        state: "on"
        brightness: 200
        color_mode: "xy"
        xy_color: [0.33, 0.66]
  - name: Movies
    entities:
      light.tv_back_light:
        state: "on"
        brightness: 125
      light.ceiling: "off"
      media_player.sony_bravia_tv:
        state: "on"
        source: HDMI 1
  - name: Standard
    entities:
      light.tv_back_light:
        state: "off"
      light.ceiling:
        state: "on"
        brightness: 125
        color_mode: "white"

[Fat-Knees]

Sun automations dont seem to be working for me either since this update.

[plainkay]

Same here. i’m upgrading again to 2024.12.4 hoping it’ll fix it.

[nickrout]

Yet neither of you post logs. Amazing.

[bbs2web (David Herselman)]

Shelly dimmer 2 modules turn on but one can’t then turn them off afterwards. Same thing with them being on initially, in that one then can’t turn them off.

I’d skipped the first release of 2024.12, where 2024.12.2 and 2024.12.3 worked perfectly but 2024.12.4 exhibits this problem.

PS: Using the official Shelly integration.

[Mariusthvdb (Marius)]

anyone else seeing the Ecowitt integration no longer create entities after updating to 2024.12.4?

not yet seen any obvious loggings, so cant post anything yet, but hoping I am no alone…

diagnostics shows 500 Internal server error. but is that the Ecowitt or HA connecting to it.

Checking the actual display seems to connect to the weather station outside alright, and shows it has an excellent connection to the router…

[petro]

@Mariusthvdb

500 Internal server error

500 errors come from what you’re connecting to, not from what you’re connecting from.

I.e. It’s an Ecowitt error provided to HA.

[Mariusthvdb (Marius)]

thx.

checking the display again, I now noticed a flashing wifi icon.
which is somewhat puzzling as the router shows the device being online just fine (and its not the connection to the outside station, because that has its own connection icon)

every data point was fine, so all I could think if was to unplug the power cord (it has batteries also …) wait 10 sec and reconnect.

lo and behold the entities popped back to life.

the mysteries of Home automation… was it all a coincidence? guess I will never know

[jerryinc (Jerry)]

I upgraded to version 2024.12.4 and am having issues with the Roborock integration. I can log in, receive a 6-digit code from Roborock, enter the code into the integration and it appears everything is good except the integration shows “Failed to Setup”.

Here is a snippet from the logs:

Logger: homeassistant.config_entries
Source: config_entries.py:640
First occurred: 1:10:01 PM (9 occurrences)
Last logged: 1:37:58 PM

Error setting up entry [email protected] for roborock
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/config_entries.py”, line 640, in __async_setup_with_context
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/components/roborock/init.py”, line 72, in async_setup_entry
device.duid: device for device in all_devices
^^^^^^^^^^^
AttributeError: ‘dict’ object has no attribute ‘duid’

Thanks.

[stamandr]

Unfortunately, nothing is appearing in my logs in regard to this issue. What I have discovered is that after the update to 2024.12, Perform action ‘Switch: Turn on’ on Light Group (LR) - Switches doesn’t work anymore, but Switch ‘Turn on’ on Light Group (LR) - Switches does work in my automations

[EricT (Eric Tuck)]

@jerryinc

t recent call last):
File “/usr/src/homeassistant/homeassistant/config_entries.py”, line 640, in __async_setup_with_context
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/components/roborock/init.py”, line 72, in async_setup_entry
device.duid: device for device in all_devices
^^^^^^^^^^^
AttributeError: ‘dict’ object ha

I’m having exactly the same issue with 2024.12.4 and the Roborock integration.

[plainkay]

Didn’t think about posting them. But I did turn on debug logging so I’ll be sure to post soon. Thanks for the reminder.
Could have been kinder, but a good point nonetheless.

Where do we put / upload the logs?

[nickrout]

Probably in a GitHub post.

[Lash-L (Luke)]

@jerryinc @EricT Your issue was due to an api change and has been resolved with the next update

here’s extra context from another thread:
Hi everyone! Codeowner for the Roborock integration here. I have a fix for this already included in 2024.12.5 as of this morning. Once 2024.12.5 gets pushed out, update to that.

Basically, Roborock changed their api yesterday a tiny bit and that is causing the issues. I added a solution that will help prevent a similar error from happening again, but api changes of any form can cause major problems.

MANY previous versions of the roborock integration will be permanently broken! So I’m sorry to force anyone to 2024.12.5 that wasn’t planning on it, but you will need to. I encourage everyone to go here: #133533 where I will leave the issue open for any further questions. I do not frequently check the forums.

Sorry for the inconvenience everyone! I fixed it as soon as I was aware of it, but of course I have no real affiliation with Roborock, so I did not know beforehand. Hopefully 2024.12.5 will be released shortly.

[AlanMW (Alan)]

Is there something specific I have to do to enable the fall back option for assist? I don’t see the option to enable “prefer handling commands locally” in my 2024.12.4 containerized version.

Edit… clearing the browser cache did it.

[parautenbach (Pieter Rautenbach)]

Just a callout for everybody using HA Core directly (yes, I know we’re a minority and responsible for dependencies ): I noticed an error I didn’t see until I upgraded from 2024.11.3 to 2024.12.4.

[aiohttp_fast_zlib] zlib_ng and isal are not available, falling back to zlib, performance will be degraded.

You need to enable the isal integration (assuming you have the required dependencies installed). This is new since 2024.6 and isn’t included in the default config.

Configuration of this integration only applies to Home Assistant Core installations types. Home Assistant Container, Home Assistant Supervisor, and Home Assistant Operation System installs already have isal pre-installed, and no action is required.

My dashboards are now noticably faster.

(Also see this issue for reference.)

[jd3073 (John)]

Any one else having issues with CarPlay no longer showing previous HA devices?

[NOS4A2]

After upgrading to 24.12.5, all my MQTT remote controls lost their action property.

I can see the action happening on the Zigbee2MQTT logs and interface but all button actions disappeared from HA.

I tried to delete one remote control and pair it again but same result.

Anyone else facing the same issue?

[Idaho947]

No issue for me with my mqtt.