2024.5: Just a little bit smaller

[JoFie (Irregular)]

Agree. But it would suggest that the person responsible for publishing the release has the same lack of interest/pride in what he/she does, because he allows it to happen. We don’t talk about hours of documentation, it took me 10 minutes to click on the links in the sub-release and copy the detail from the respective github pages.

[Robban]

It’s also about signalling what type of work it is, it is much quicker to get a review of a library bump than of feature PR, because it’s much smaller and simpler in nature. Typically there are references to fixes within the PR itself.

[inkblotadmirer]

What does “Bumped <something> to <version>” actually mean?

This is a perfectly reasonable, succinct way to document the change. If you go to the PR (the # is referenced) a link to the original PR asking for the change is linked – there’s your reason.

And if you go to the library being bumped, all detailed changes from version to version are documented in that library. It is typically better to have “one source of truth” and keeping that in the responsible library is the norm.

You could possibly suggest better means of conveying this information, etc. but saying this is a means to avoid documentation, or that it’s being lazy aren’t valid criticisms.

[ShadowFist]

@inkblotadmirer

You could possibly suggest better means of conveying this information, etc. but saying this is a means to avoid documentation, or that it’s being lazy aren’t valid criticisms.

I disagree. It’s not any better than the “Various bug fixes and improvements” you see when you try to upgrade a mobile app.

No one is asking for all the detailed changes (the PR already contains all those). What would be really helpful is a brief overview (even if it’s only 1 or 2 sentences) summarising impacted areas of those changes. It makes for better readability in the same page where you’re deciding whether you should upgrade or not.

[JoFie (Irregular)]

Just to confirm, we are talking about the information that is part of the release to the end users. This should be consistent, and transparent, also for those with no IT background. For those with no clue of what bump means to start with.

For the end user it (only) matters what changed in the release, so that they can judge the risk of upgrading, and perhaps do some related testing post upgrade to test if that problem is now finally solved, or to ensure their system is still functioning okay. This is the reason why changes are listed in the release notes in the first place. For the user it is irrelevant whether the change was a result of a CR or PR or “bump” or whatever happened behind the scenes. Whether it is quicker to get a review for a library bump compared to a PR. All immaterial. What changed. That’s the question.

If for bumps we expect end users to click on links and read library documentation to find out what changed, then to be consistent they could/should do the same for other changes.
On the other hand, if for PR-based changes it is justified to provide a short summary of what changed in the release notes, then why not be consistent and do the same for the bumped change? Or, what justifies that what changed is not mentioned for bumps??

[francisp (Francis)]

Bumping is not user friendly

The title is a little cryptic. But let me explain. When users report bugs, we submit a github issue with a title. And if the person is normal or near normal, the title will be a fair short description of the problem. Example: I submitted enigma2 “integration fails to start and flood log after upgrade to 2024.1.0” The workflow on the project is that a PR is created. And in many many cases the fix is to update a version of a dependency. The title of the PR is usually something like " Bump openw…

[ShadowFist]

Thanks @francisp. I thought the request sounded familiar.

[nickrout]

On a related note, practically every integration has a pypi library. To find the library my current method is

1. Go to the integration source (helpfully linked in the docs and the UI)
2. Click on manifest.json
3. Find the underlying library
4. Go to pypi, search for the library
5. Click on project details
6. Finally click on homepage and look at the source.

I wish there was a link in the docs and web ui to the library source.

[teskanoo]

@nickrout

I wish there was a link in the docs and web ui to the library source.

Right there… to me that’s the missing piece. The three click rule to find the relevant information is maintained by bring the link to the dependency upgrade notes.

But I kinda get it too, I am an application developer and do not always link back to the change logs of all the libraries I update on a project

[J4CE]

I was hoping to change the display name for the main energy devices too? I.e. solar, grid import/export, gas, water? That would be nice, rather than the entity name now which may be ugly. Can this be done or is it only individual devices that we monitor that we can add display name for?

[TheFes]

Only individual devices at this moment

[parautenbach (Pieter Rautenbach)]

@J4CE

That would be nice, rather than the entity name now which may be ugly.

You can rename any entity ID in HA as well as set a friendly name. Wouldn’t that do what you want?

[DumahBrazorf]

@teskanoo

I think you could negate this issue if you added the availability key to your yaml to ensure the calculation only happens when all contributing sensors are available.

I’m trying to understand your advice. The trigger for this template is sensor.pc321_power_l3 simply because having debounce in z2m i have one full message with all data published each time. I have no idea how to modify the trigger, i struggled and copied/pasted yaml from here and there last time having little clue what i was doing. And I’m a programmer! yaml is so distant to visual basic…

EDIT: So, leaving the trigger alone i should add something like
availability: “{{ has_value(‘sensor.pc_321_power_l1’) }}”
don’t know how to set it for l1 l2 l3

[teskanoo]

@DumahBrazorf

I’m trying to understand your advice. The trigger for this template is sensor.pc321_power_l3

@DumahBrazorf

template:
- sensor:
- name: "power_ac"
  unique_id: '0a7476cc-d6c1-40ba-8ae1-606518c3497'
  unit_of_measurement: "W"
  device_class: power
  state_class: measurement
  availability: “{{ has_value(‘sensor.pc_321_power_l1’) and 
  has_value(‘sensor.pc321_power_l2’) and has_value(‘sensor.pc321_power_l3’) }}”
  state: "{{ ( states('sensor.pc321_power_l2') | float(0) + states('sensor.pc321_power_l3') | float(0) - states('sensor.pc321_power_l1') | float(0) ) | round(0) }}"

I think that the trigger for the template sensor would be any of the entities you use in the sensor, in this case:

Entity: sensor.pc321_power_l1
Entity: sensor.pc321_power_l2
Entity: sensor.pc321_power_l3

I have added the availability statement into the template

[DumahBrazorf]

Hi, thank you for your patience.
I modified the configuration and after a couple of hours i can see it has no effect.
There’s something wrong in 2024.5

[K-n-C]

yes I know. I thought it was initially a network issue because I saw errors in the HA logs, but my linux box tcp monitoring never saw it fail (for months). HA just lost it for some reason. I was busy for a few days and not home so I could not troubleshoot, but it has been stable since upgrading to 2024.5.2.

[DumahBrazorf]

Seriously. I copied the same code of power_ac sensor in the template editor

EDIT: after some tests i can say it does not refresh all the sensor states so it do math always with new l3 value and old l1 and l2 values. On the contrary the template editor engine works correctly.
Changed trigger to

    trigger:                                            
      - platform: state                                              
        entity_id:                                                             
          - sensor.pc321_power_l1
          - sensor.pc321_power_l2                                                                                                             
          - sensor.pc321_power_l3 

and it seems to have solved the issue.
Before 2024.5 it was working with only l3.
Repeating entity_id: before each sensor does not work, i think the last one overwrites previous ones.

EDIT2: Too soon, it still have some unusual spikes, never did before 2024.5

EDIT3: Checking the history veery closely is clear the template just fires 3 times in the same second, one for each sensor in the trigger, so the first 2 times the value is wrong but it’s stored in the graph and the last is correct and it’s the one i see in the frontend. So before 2024.5 was i simply lucky to use trigger with only sensor l3 as it was the last updated?
Looks like someone added a DoEvents() in the code somewhere before finishing read the full mqtt message…

EDIT4: The last sensor to update now is l1 so the code works exactly as before 2024.5 if i trigger to l1 only, however i don’t think this is the proper way to do things…

[wrcaston84]

I was previously in 2024.3.3 which seemed to work with my sonoff devices. Since the upgrade, after a while, the states stop updating. If I switch the lights on, the state goes back to off but the light remains on and vice versa.

[nickrout]

I know you are new here, but you provide none of the information required. How to help us help you - or How to ask a good question

[opq]

Has anyone else’s Lutron Pico switch button press events stopped working after upgrading to 2024.5? I moved from 4.4 to 5.3 recently and HA stopped taking action on my switch button presses. The button presses show up in the HA Log/History but the Scenes don’t work. I didn’t see any breaking changes called out.