freekode / pyopenweathermap

Python library for OpenWeatherMap API for Home Assistant
MIT License
2 stars 4 forks source link

Adding Minutely forecast for Home Assistant #14

Open 10100011 opened 1 week ago

10100011 commented 1 week ago

I have added functionality to homeassistant/core/components/openweathermap (fork: here) to create a new service with 60 sensors for each minute of the hour-long Minutely forecast.

Having that many new sensors wasn't my first choice but it seems to be the least worst option. Adding extra_state_attributes is discouraged for database growth reasons, which rules out having just one new sensor to cover the full hour with lots of attributes. Including a minutely forecast as part of OpenWeatherMapWeather also doesn't appear to be properly supported by HA's WeatherEntityFeature: only hourly and daily (and twice daily?).

On the plus side, having the sensors under a dedicated service does allow all the entities to be disabled quickly if they aren't required, every sensor may be added to a history chart with only a few clicks, and the native values are more easily accessible than attributes - which should aid with automation.

If 60 sensors is too much, it could be reduced to a sensor per 2, 3, or 5-minutes - with either an average or maximum value used.

Note that there is a dependency on the changes made in PR#13 - thank you @freekode for merging it.

Feedback welcome, particularly regarding the number of sensors.

freekode commented 1 week ago

If I understand you correctly, you are creating 60 new sensors for minute forecast. Home Assistant rather is moving away from creating many sensors. Since current service call doesn't support minute forecast, I would suggest you to create a new one (similar to this) which will be available only for OWM integration. That way you won't have so many sensors by default and can create only required ones using template.

10100011 commented 1 week ago

If it's my turn to understand correctly, the result of creating a sensor in the way you suggest would be to have a single sensor with up to 60 attributes?

The sensor documentation suggests that - done badly - it might not be good idea: "_Instead of adding extra_state_attributes for a sensor entity, create an additional sensor entity. Attributes that do not change are only saved in the database once. If extra_state_attributes and the sensor value both frequently change, this can quickly increase the size of the database_."

However, maybe if the sensor value doesn't change very often, having many attributes would be OK.

I also think it wouldn't be part of the Weather platform and extend homeassistant.components.weather.SingleCoordinatorWeatherEntity, since WeatherEntity seems to define specific data points that you cannot add to - unless I've missed something?

Happy to rework it into a single sensor with multiple attributes.

freekode commented 6 days ago

If it's my turn to understand correctly, the result of creating a sensor in the way you suggest would be to have a single sensor with up to 60 attributes?

Not necessary, you don't need to create a sensor at all. Users will do that by using a template where they can extract as much information as they want. All you need is to provide a service, similar to weather.get_forecasts which returns minutely forecast. Although this service should be implemented in OWM integration not in generic Weather.

10100011 commented 4 days ago

Good idea. A service is much simpler and neater: https://github.com/10100011/core/tree/minutely-service/homeassistant/components/openweathermap

Please feedback.

image

freekode commented 4 days ago

Looks nice. Somewhere here I think you need to check what current forecast mode selected, because minutely forecast is available only in onecall 3.0 (i guess) mode. So you want to register the service only when onecall selected.

10100011 commented 3 days ago

This should do it. The service will only appear if v3.0 is selected in the Configuration.

The service will also be removed if the user selects current or forecast after previously selecting v3.0. It does not seem to remove the service if the user moves from v3.0 to v2.5, but given that v2.5 has now been completely deprecated, if a user chooses that path then they have bigger problems!

Edit: Thank you for tagging pyopenweathermap v0.2.1. manifest.json also updated.

freekode commented 3 days ago

LGTM 👍 Nice work