ImportError: cannot import name 'open_binary' from 'importlib_resources' with Core 2023.7.2

[alvinchen1]

Installed 2023.7.2 and composite 2.8.2 will not load. Redownloaded via HACS and same error.

Invalid Config error Error during setup of component composite Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/setup.py", line 288, in _async_setup_component result = await task ^^^^^^^^^^ File "/config/custom_components/composite/init.py", line 218, in async_setup await hass.async_add_executor_job(create_timefinder) File "/usr/local/lib/python3.11/concurrent/futures/thread.py", line 58, in run result = self.fn(*self.args, **self.kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/custom_components/composite/init.py", line 205, in create_timefinder from timezonefinderL import TimezoneFinder File "/usr/local/lib/python3.11/site-packages/timezonefinderL/init.py", line 3, in from .timezonefinderL import TimezoneFinder File "/usr/local/lib/python3.11/site-packages/timezonefinderL/timezonefinderL.py", line 8, in from importlib_resources import open_binary ImportError: cannot import name 'open_binary' from 'importlib_resources' (/usr/local/lib/python3.11/site-packages/importlib_resources/init.py)

Verified my configuration.yaml

composite:
  trackers:
    - name: User 1 Phone WiFi At Home
      time_as: device_or_local
      entity_id:
        - binary_sensor.user_1_phone_wifi_at_home
    - name: User 2 Phone WiFi At Home
      time_as: device_or_local
      entity_id:
        - binary_sensor.user_2_phone_wifi_at_home

[alvinchen1]

Resolved for me. Changed

time_as: device_or_local

to

time_as: local

And works again. May be an issue with device_or_local still however.

[townsmcp]

@alvinchen1 thanks - I had the same issue with the latest HA. Changed time_as like you suggested and rebooted. Now working fine

[jriker1]

Thanks this fixed mine as well. Is there any impact to this change?

[alvinchen1]

Thanks this fixed mine as well. Is there any impact to this change?

So it just turns out that I am vacationing out of the country and so my time zones are all jacked up. But take a look at this:

https://github.com/pnbruckner/ha-composite-tracker#tracker-entries

Check out the time_as options to see if they align with how you'd like the attribute of the entity to appear in your instance. Your milage may vary.

Haven't read through the code, but my guess is that either there is a time zone dependency that may need bumping or the recent addition in 2023.7.x where you can have the FrontEnd display time based upon the time zone of the homeassistant or your current timezone may have something to do with why this changed.

See https://www.home-assistant.io/blog/2023/07/05/release-20237/#select-the-timezone-to-usedisplay

[pnbruckner]

As best I can tell (without looking into it further) the TimezoneFinder(L) package uses another package (importlib_resources) which has apparently changed in the new HA release that causes TimezoneFinder(L) to break. Until I can come up with a fix, the work around is to not use device_or_utc or device_or_local. (Those settings cause the composite integration to use the TimezoneFinder/TimezoneFinderL package.)

[Mariusthvdb]

I really hope you can find a fix, as the most important reason for me to use the CC is the time as device aspect (ofc, next to the better handling of the individual trackers compared to the core person...)

[michaelsleen]

Resolved for me. Changed

time_as: device_or_local

to

time_as: local

And works again. May be an issue with device_or_local still however.

This worked for me. Thank you.

[pnbruckner]

Looks like timezonefinderL lists the importlib-resources package as a requirement but without a specific version. The latest release of importlib-resources (6.0.0, which was released on July 7, 2023) removed the "legacy" implementation of the open_binary API, which timezonefinderL uses. So, the error comes from an update to the importlib-resources package and is not due to a change in HA. It just happens that updating HA indirectly causes the newer (and incompatible) version of the importlib-resouces package to get installed, thus breaking timezonefinderL, and indirectly this integration (if your configuration causes timezonefinderL to be used.)

I still need to see if there's a fix or other work around that allows use of the device_or_utc or device_or_local options.

[pnbruckner]

The timezonefinderL package is apparently no longer maintained. It hasn't had a new release in over four years. So, probably the right thing to do is to change this integration's default to use the newer timezonefinder package (and its "light" TimezoneFinderL class, that was meant to replace the timezonefinderL package.)

Could someone give this configuration a try and let me know how it works? E.g.:

composite:
  tz_finder: timezonefinder
  tz_finder_class: TimezoneFinderL
  ...

If that doesn't work, try different versions of the timezonefind package, e.g., one of the following:

  tz_finder: timezonefinder<6
  tz_finder: timezonefinder<5

If none of those work, then maybe:

composite:
  tz_finder: timezonefinder==4.2.0
  tz_finder_class: TimezoneFinder

[Mariusthvdb]

tested the top variant and can confirm success

all sensors report correct timezone and the offset sensors are in order too

[pnbruckner]

I just did pretty much the same thing. I used that first config w/ 2023.6.3, which worked ok, then upgraded to 2023.7.2, which still seems to work ok.

The current release of timezonefinder is 6.2.0. If you don't want to be surprised again (or, at least, to minimize the chance of a surprise), you can specify this version with:

composite:
  tz_finder: timezonefinder==6.2.0
  tz_finder_class: TimezoneFinderL

Note that the TimezoneFinderL class is inteded to be a "light" version of this package. I.e., it in theory uses less computational resources. You can try the "main" class instead, which although it will probably use more resources (and might install more stuff, not sure), it, in theory, can produce more accurate results. To use it change the tz_finder_class option (or just delete it or comment it out, because the TimezoneFinder class, without the "L" suffix, is the default.) You can always change it back to the L version if necessary.

I'll work on a new release that changes the defaults to:

tz_finder: timezonefinder==6.2.0
tz_finder_class: TimezoneFinderL

But since there's a reasonable work around, it might not happen right away.