Wunderground

[grivers3]

Home Assistant release 0.48.1 Python release: Python 3.4.2 (on Raspian) Component/platform: Wunderground

Description of problem: device_state_attributes only update on restart. entity_picture updates, friendly_name, & value update as expected

Expected: device_state_attributes update when entity_picture updates, friendly_name, & value update.

Problem-relevant configuration.yaml entries and steps to reproduce:**

• platform: wunderground api_key: !secret weatherunderground_key monitored_conditions:
  • weather
  • weather_1h

Open state card of sensors. Weather will return: date Last Updated on [last restart]

weather_1h will return: (the Friendly Name is correct) date Next hour after reboot

[hoopty]

Thanks for submitting, I noticed this as well.

[arsaboo]

It looks the device attributes update correctly, just the date attribute is not updating. Just try something like {{as_timestamp(now())-as_timestamp(states.sensor.pws_temp_f.last_updated)}} in the template editor and it will tell you when the entity was last updated.

[grivers3]

sensor.pws_weather_1h

Values at 8:55PM after restart: Friendly Name: Fri 9:00PM Value: Partly Cloudy Attributes at 8:55PM after restart: pressure inH:g 30.05 date: 9:00 PM EDT on July 14, 2017 wind kph: 14 precip prop: 15 humidity: 68 wind mph: 9 dewpoint c: 22 precip in: 0.0 pressure mb: 1018 temp f: 83 precip mm: 0 temp c: 28 dewpoint f: 71 sky: 74

Values at 10:30PM Friendly Name: Fri 11:00PM Value: Partly Cloudy Attributes at 10:30PM (Exactly the same) pressure inHg: 30.05 date: 9:00 PM EDT on July 14, 2017 wind kph: 14 precip prop: 15 humidity: 68 wind mph: 9 dewpoint c: 22 precip in: 0.0 pressure mb: 1018 temp f: 83 precip mm: 0 temp c: 28 dewpoint f: 71 sky: 74

[hoopty]

Agreed, the problem is not the state values getting updated, but instead the device_state_attributes. There should not be a date attribute showing "Last Updated on XXX" if it is not accurate. Bad data is worse than no data!

[grivers3]

I copied the wunderground code into a custom component and added logging to trace the function calls.

def _cfg_expand(self, what, default=None): _LOGGER.error("cfg_expand call Entry: " + str(what) + " / " + str(default)) cfg = SENSOR_TYPES[self._condition] _LOGGER.error("cfg_expand call A: " + str(cfg)) val = getattr(cfg, what) _LOGGER.error("cfg_expand call B: " + str(val)) try: val = val(self.rest) _LOGGER.error("cfg_expand call C: " + str(val)) except (KeyError, IndexError) as err: _LOGGER.warning("Failed to parse response from WU API: %s", err) val = default except TypeError: _LOGGER.error("cfg_expand call D: TypeError") pass # val was not callable - keep original value return val

The first time through the val = getattr(cfg, what) returns a dictionary of the attributes and the lambda function. After that it returns a dictionary of the attributes and the value.

[First call] cfg_expand call Entry: device_state_attributes / {} cfg_expand call A: <custom_components.sensor.mywunderground.WUHourlyForecastSensorConfig object at 0x6dacacb0> cfg_expand call B: {'precip_prop': <function WUHourlyForecastSensorConfig.init.. at 0x6dace540>, 'date': <function WUHourlyForecastSensorConfig.init.. at 0x6dace7c8>, ...} cfg_expand call D: TypeError

[Subsequent calls] cfg_expand call Entry: device_state_attributes / {} cfg_expand call A: <custom_components.sensor.mywunderground.WUHourlyForecastSensorConfig object at 0x6dacacb0> cfg_expand call B: {'precip_prop': '15', 'date': '12:00 PM EDT on July 18, 2017', ...} cfg_expand call D: TypeError

Not much of a coder so I have not figured out why yet or how to work around it.

[grivers3]

I believe I found it. Originally device_state_attributes is set to return an array device_state_attributes={...}

Change it to a lambda function device_state_attributes=lambda dsa: {...} seems to work in the traces.

Still testing.

[grivers3]

Looks like that works.

[hoopty]

Great, are you going to do a PR?

[grivers3]

Like I said, I'm not much of a coder. I'm trying to set up a development environment and learn how to do a PR.

[hoopty]

No problem, can you copy & paste the updated code into this issue? I don't mind submitting me submitting a PR with the code snippet you provide. I'll test & verify it passes the test suite. Just put a ``` before and after the code snippet. It would also help if you tell me what file & line(s) of code you changed.

[grivers3]

Lines 96, 123, 157, 185

Before device_state_attributes={

After device_state_attributes=lambda dsa: {

I believe the name of the lambda function (dsa) does not matter.

[hoopty]

In which file? :)

[grivers3]

homeassistant/components/sensor/wunderground.py

[pezinek]

Hi Guys, I didn't quite get all the details about the proposed solution, but the reason why the date doesn't change could be because that value is passed directly from the WU API and is reflecting the time when the forecast have been calculated, so it may not change frequently (if I remember correctly WU calculates the forecasts every 4 hours - even for hourly forecasts)

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[balloobbot]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem 👍