2024.9: Sections go BIG

FYI you should never have to restart for frontend changes to take effect. Only refreshing cache. The frontend lives in your browser.

5 Likes

I have some automations which play sound (MP3 Media) on Apple Homepod mini. After the update no more sound playing (even if it says „Action run successfully“).
I restored my daily backup and it works fine again.
The issue is reproduceable: I did the update again —> no sound
Restored my backup again: works fine

Rgds,
Joop
UPDATE: I just installed 2024.9.1 and issue no longer exists

1 Like

Great thanks for your help Chris I’m glad Hive still works for you, and thanks for being such a helpful human being. As mentioned it works for me too as I rolled back.

All my sensors are report back in English now?
“Zuhause” is "Home, other sensors are on/off instead of any translation that was present before the update…
Did i miss something?
UPDATE: As usual users fault - clearing cache did the trick, all back to normal :slight_smile:

I’m not seeing the untracked energy at all. Is there a setting that needs to be enabled?

For me, it took a little waiting after the reboot and some refreshes before it appeared.

Look for the hidden entities might be there

I did the upgrade yesterday, I think that should be plenty of time for that to appear…

The first thing I looked for myself after upgrading was the untracked consumption, and I remember it not being there. I then watched the release livestream, and during watching that and refreshing the energy dashboard page it suddenly was there - I didn’t enable anything. I suppose you tried clearing browser cache etc?

Nice! The ability to just control those gaps natively (similar to PowerToys Fancyzones) would be awesome.

2 Likes

No; didn’t find it

The only reason I can think of it would not be there is if you do not have any grid or solar sensors.

HA needs to be able to calculate the whole house load before it can derive the untracked consumption from that.

Do you have grid sources, or some other power source?

Otherwise it’s maybe just a cache clearing issue. There’s no setting to enable or disable this.

Hi @NathanCu, thanks for your answer, but I’m not sure how to do that.

I had this automation that was working fine with the normal intents:

alias: Alarm
description: This automation activates the phone alarm in 'time_amount' minutes.
trigger:
  - platform: conversation
    command:
      - Set the alarm in {time_amount} minuts
condition: []
action:
  - data:
      message: command_activity
      data:
        intent_action: android.intent.action.SET_ALARM
        intent_extras: >-
          {% set alarm_time = now() +
          timedelta(minutes=trigger.slots.time_amount|int) %} {{
          'android.intent.extra.alarm.HOUR:' ~ alarm_time.hour|string ~
          ',android.intent.extra.alarm.MINUTES:' ~ alarm_time.minute|string ~
          ',android.intent.extra.alarm.SKIP_UI:true' }}
    action: notify.mobile_app_xxx
  - set_conversation_response: The alarm will ring in {{trigger.slots.time_amount}} minutes.
mode: single

So I tried this in my configuration file:

intent_script:
  PhoneAlarm:
    description: Set the alarm in the phone (in minutes)
    speech:
      text: Alarm set in {{ trigger.slots.time_amount }} minutes
    action:
      action: notify.mobile_app_xxx
      data:
        message: command_activity
        data:
          intent_action: android.intent.action.SET_ALARM
          intent_extras: >-
            {% set alarm_time = now() + timedelta(minutes=trigger.slots.time_amount|int) %} {{
            'android.intent.extra.alarm.HOUR:' ~ alarm_time.hour|string ~
            ',android.intent.extra.alarm.MINUTES:' ~ alarm_time.minute|string ~
            ',android.intent.extra.alarm.SKIP_UI:true' }}

Following the documentation from: Intent Script - Home Assistant
But I can’t see how the LLM is supposed to pass the variable ‘time_amount’ to the intent_script.

It seems that Yale Access Bluetooth can’t fetch offline keys from new Yale (Home) integration, as it used to with August integration. Any suggestions?

1 Like

I’ve been trying since last night after switching from August to Yale, the Bluetooth connection is broken! I even created a new account, performed factory settings on my Yale Linus, re-integrated everything + Connector WLAN… Nothing has helped. A restart of Home Assistant, instance of Yale Access Bluetooth and Yale deleted and Yale re-added successfully… Now I have a found Yale Access Bluetooth and am asked for offline key and slot… What else to try? Also checked all logs and protocols, no success. - I also tried the old key and slot - searched everything and found nothing for the key and slot… Does anyone have a tip?
:frowning:

image

Integration with Yale Access Bluetooth

  • The Yale integration must support the lock. - yes Linus Lock V1
  • The Yale Access Bluetooth integration must support the lock. - Yes Linus Lock V1
  • The Bluetooth integration must be active and functional. - Yes, everything went perfectly under August.
  • The lock must be discoverable by the Yale Access Bluetooth integration. - Yes, Screenshot
  • The account logged in with the Yale integration must have the offline keys. - yes, only one account all new…

This clearly states that the offline key will be executed. All points are taken into account. + Yale lock reset, everything deleted from account and account deleted! Re-created and re-linked everything.

Nice update to the sections!
It needs one more thing and then I can convert all my dashboards :slight_smile:

Is changing the sections layouts’ grid size on the roadmap… now they are all fixed so making 3 equal icons on a row still needs an hstack card extra…

In my experience, the DB migration requires at least as much free disk space as the size of your current DB. After the migration, the DB is about 25% bigger.

1 Like

Seems that a similar estimation is for a “repack of a native sqlite base” case.

1 Like

Worth to mention that if it’s true, then it’s not db limitation but HA architecture.
I understand 10days limit for sqlite running on raspberypi class HW. But with resonable resources said postgress can maintain and serve in real-time data out of unlimited stored size. If db and app are properly designed.

on the other side of the coin, indeed time series databases are even more efficient for such a job. I recently installed Postgres with TimescaleDB, LLTS and Grafana. All running on rpi4 together with HA. and indeed, graphs provided by grafana are rendered way faster than Apex charts.
Another benefit is, that such postgres-based db cannot break (benefit of fully transactional db) In worst scenario some records might be lost but anomalies in stored data will definitively not affect HA (which cannot be said about sqlite sometimes messed up by HA)

2 Likes

btw the Energy dashboard. I can see some love put on this recently.
What hit me not long ago is, that the dashboard is tightly coupled with sensors set to it (with their entity names)

If one collects energy data for years and then installs FVE, he likely has to change the dashboard settings replacing energy sensors with others, likely provided by a solar inverter (consumption and production)
In such case house consumption for past days/years is gone from the dashboard.

The same will happen if you change the energy sensor for another one, unless you secure the same entity name

Do you know about incoming improvement in this area?