search

bremor / bureau_of_meteorology

Custom component for retrieving weather information from the Bureau of Meteorology.
MIT License
186 stars 31 forks source link

AttributeError: 'Collector' object has no attribute 'location_name' #95

Closed nvx closed 2 years ago

nvx commented 2 years ago

Home Assistant 2021.12.7. BoM 1.1.1 via HACS. I've got the observational sensors enabled, but the forecast sensors disabled.

Getting the following in the log and the weather entities are not appearing:

Logger: homeassistant.components.weather
Source: custom_components/bureau_of_meteorology/weather.py:24
Integration: Weather (documentation, issues)
First occurred: 11:16:51 (1 occurrences)
Last logged: 11:16:51

Error while setting up bureau_of_meteorology platform for weather
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform
    await asyncio.shield(task)
  File "/config/custom_components/bureau_of_meteorology/weather.py", line 24, in async_setup_entry
    location_name = hass_data[COLLECTOR].location_name
AttributeError: 'Collector' object has no attribute 'location_name'
chicaneau commented 2 years ago

Same issue here

adamkoch commented 2 years ago

Has anyone found a solution to this?

adamkoch commented 2 years ago

Appears that the base [basename].weather entity disappeared for me when using BoM 1.1.0. I downgraded to BoM 1.0.0 and it came back.

Makin-Things commented 2 years ago

I am trying to reproduce this issues without success. Is it still a problem? If so can you please provide the coordinates you are using for the integration.

nvx commented 2 years ago

I am trying to reproduce this issues without success. Is it still a problem? If so can you please provide the coordinates you are using for the integration.

Definitely still an issue, configuring with coordinates of -27.3,152.6 - leave create observation sensors ticked, lave the basename default (shows up as "Amberley" with those coordinates), tick say Temperature for which sensors, untick create forecast sensors, it then says Created configuration for Dundas (which is strange, I'd have expected it to say Amberley again?). At this point the log will have appeared with the error as per the original post, and if you look at the entities created there is no weather.amberley or weather.dundas entity (or in fact any weather.* entitity created by the integration, unlike with previous versions).

Hopefully this is enough info to be able to reproduce.

Makin-Things commented 2 years ago

Ok, firstly I'll explain the name differences. Forecasts are created by some massive supercomputers and exist for all locations in Australia (down to the suburb level), while Observations are measurements made at specific locations. So for the coordinates you gave any forecast sensors would be named dundas* but the nearest weather station is at Amberley so any observation sensor would be named amberley*. So the final message is basically saying it has created forecast sensors for that location and observation sensors at the closest weather station.

I used those coordinates and with temp and feels like ticked in observations and unticked forecast and it created the 2 sensors that it should. Are you using the latest version? I released 1.1.2 earlier today, although I don't think there was anything in it that would have fixed this issue, but I still can't get it to fail as you described.

adamkoch commented 2 years ago

1.1.2 seems to work fine for me when 1.1.0 did not. Although as per my comment above, 1.0.0 worked fine as well so I had been using that for the past while without issue.

Makin-Things commented 2 years ago

@adamkoch glad to hear that 1.1.2 has fixed the issue. @nvx has the recent update also fixed it for you?

nvx commented 2 years ago

@adamkoch glad to hear that 1.1.2 has fixed the issue. @nvx has the recent update also fixed it for you?

Same issue with 1.1.2, I'm out of town at the moment though so I'll try deleting and recreating the integration on the new version when I get back to town next week and report back.

chicaneau commented 2 years ago

@Makin-Things i have deleted and re-added the integration today. Still seeing the same problem in the logs on restart of HASS Lat: -26.804707 Long: 153.09216149999997 Observation: on Forecast: off

Makin-Things commented 2 years ago

@chicaneau Ok, I still can't completely reproduce and I don't believe it has to do with the location entered. I am almost certain it is because of unticking the forecast checkbox. Could you try deleting it again and add it back with the forecast ticked and select a minimal set of items and see if it then works.

glenn20 commented 2 years ago

I can confirm this bug hit me on a fresh install with version 1.13 when I untick the forecast sensors box. A successful workaround is to tick yes to the forecast sensors box and select at least one sensor.

Makin-Things commented 2 years ago

I think I have figured out the problem. As mentioned above it only happens when you don't check forecasts. In that case a name doesn't get stored for the weather.location and weather.location_hourly sensors so they fail. All of the individual sensors still get created and work as expected. tbh I have never used or even looked at the combined sensors and feel they are pointless, but I am working on a fix for those that think they are useful.

Makin-Things commented 2 years ago

I have just put up 1.1.4b as a pre-release to hopefully fix this issue. Please install and test and let me know if it is fixed.

glenn20 commented 2 years ago

Thanks for the speedy response. I have just tested with 1.1.5 and this avoide the AttributeError exception and i get a working weather device. However, the current config flow does not allow you to confirm or change the forecast location name if you untick the forecast sensors box. But it does generate a working weather device - so that is a big improvement - thanks :-). Ideally, the config flow would allow us to confirm or change the forecast location name regardless of whether we tick the box.

Force setting the CONF_FORECASTS_BASENAME avoids the else clause on line 24 of weather.py (location_name = hass_data[COLLECTOR].location_name) which was triggering the AttributeError exception. I guess that a default hassio install always set the location_name attribute in the past - and that is no longer the case for a fresh hass install (like I just did - my previous hass install finally broke after many years of service).

Makin-Things commented 2 years ago

@glenn20 I agree that it should be more flexible to configure, but I am spread a little thin at the moment as I am working on some feature requests for other cards I manage. I am also pretty new to this codebase so if you are willing to help with a PR it would be appreciated.

glenn20 commented 2 years ago

@glenn20 I agree that it should be more flexible to configure, but I am spread a little thin at the moment as I am working on some feature requests for other cards I manage. I am also pretty new to this codebase so if you are willing to help with a PR it would be appreciated.

OK - I completely understand. I'll take a look and see if I can add any value.

glenn20 commented 2 years ago

@glenn20 I agree that it should be more flexible to configure, but I am spread a little thin at the moment as I am working on some feature requests for other cards I manage. I am also pretty new to this codebase so if you are willing to help with a PR it would be appreciated.

OK - I completely understand. I'll take a look and see if I can add any value.

@Makin-Things See #119 which adds a new config variable weather_name (CONF_WEATHER_NAME) and an additional config_flow step to allow the user to override or accept the default name for the weather entity. - independently of what they choose to do with the forecast sensors. Feel free to change whatever you don't like or ask for me to make changes.

Makin-Things commented 2 years ago

@glenn20 thanks for the PR. I have tested it out and merged. It has been released as v1.1.6.

glenn20 commented 2 years ago

@glenn20 thanks for the PR. I have tested it out and merged. It has been released as v1.1.6.

Thanks Simon and thanks for all your efforts supporting these integrations for the community.

nvx commented 2 years ago

Apologies for the slow response, but I can confirm 1.1.6 has fixed the issue!

Gitspecial commented 2 years ago

Sorry but can anyone tell me where and how you get forecast on/off selection? I only get coordinate enter fields while configuring the integration, no other option.

glenn20 commented 2 years ago

Sorry but can anyone tell me where and how you get forecast on/off selection? I only get coordinate enter fields while configuring the integration, no other option.

@Gitspecial - I can only guess that it might be that your browser is still caching some of the config flow data. You may need to do a hard refresh in your browser. I'm no expert in this, but I found I had to do that whenever I tweaked the config_flow sequence in the integration. I "thought" that the integration would prompt you to do that automatically, but maybe that didn't work in your case.