Yes! Sign up for the “Free” Weather API tier! The Free plan is free for non-commercial use. Some features of the “Free” plan are only available on a trial basis for 30 days after enrollment. After the trial period, these features will be disabled.
If anyone have used this weather plug to trigger lights to turn on at sunset, can you share your code? I have found this code snippet, but it is for Dark sky. I guess I would need to know the exact wording use in the value_template.
What, exactly, are you trying to do? That code uses the sun entity (which is built in based on your lat/lon) and then modifies it based off the weather conditions. If you just want to do it off the sunset, just remove the condition.
Yes, I want the lights to turn on base on the current weather as well. Since the condition is set for the Dark sky plugin, I figure it will not work for the Weatherbit plugin.
value_template: >
{{ trigger.offset.total_seconds()/60 == -20 or
state_attr('weather.dark_sky', 'forecast')[0].condition
in ('cloudy', 'partlycloudy', 'rainy') }}
2020-06-29 06:25:58 ERROR (MainThread) [homeassistant.components.weather] Error while setting up weatherbit platform for weather
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 186, in _async_setup_platform
await asyncio.gather(*pending)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 292, in async_add_entities
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 443, in _async_add_entity
entity.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 297, in async_write_ha_state
self._async_write_ha_state() # type: ignore
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 324, in _async_write_ha_state
attr.update(self.device_state_attributes or {})
File "/config/custom_components/weatherbit/weather.py", line 241, in device_state_attributes
ATTR_WEATHERBIT_UPDATED: getattr(self._current, "obs_time_local"),
File "/usr/local/lib/python3.7/site-packages/weatherbitpypi/data_classes.py", line 229, in obs_time_local
return get_timezone_date(self.ob_time, self._timezone, "%Y-%m-%d %H:%M")
File "/usr/local/lib/python3.7/site-packages/weatherbitpypi/data_classes.py", line 313, in get_timezone_date
val_date = dt.strptime(value, time_format)
File "/usr/local/lib/python3.7/_strptime.py", line 577, in _strptime_datetime
tt, fraction, gmtoff_fraction = _strptime(data_string, format)
File "/usr/local/lib/python3.7/_strptime.py", line 359, in _strptime
(data_string, format))
ValueError: time data '06-29-2020 05:58' does not match format '%Y-%m-%d %H:%M'
Can you tell me if you are using a specific country code in Weatherbit? And if yes what it is?
It seems that you get the datetime in DD-MM-YYYY format and not YYYY-MM-DD, which is what is expected.
Strange - Just tried to run with the German setup and I don’t get any errors.
Unless you made a lot of renaming of the sensors, could you try and remove the Integration and add it again, with the same options?
As writen, the change to EN didn’t help.
I deleted the integration and restarted ha, afterwards I added the integration again and restarted again
But I got the same error.
I tried it again. Deleted the integration --> Restart. Add the integration (Language EN) --> Restart
The problem is not the language, but it is also not the timezone. The line that fails simply tries to convert a string to a datetime object. Until now Weatherbit has always delivered the datetime in the YYYY-MM-DD HH:MM format, but suddenly some of you are starting to get this in a different format (DD-MM-YYYY HH:MM).
Currently I cannot reproduce this error, but I have made a temporary fix, until I can figure what the real issue is.
If you open the manifest.json file in the custom_components/weatherbit directory, and change the value of this part:
"requirements": [
"weatherbitpypi==0.24.1"
],
to
"requirements": [
"weatherbitpypi==0.24.3"
],
Restart Home Assistant, and then the value will be None instead of a date, but it will not stop the other sensors from loading.