103.4 update here (from 102) with malfunctioning yeelights. They’re manually specified and no ip address change. Thus far they seem the only class of device that does not respond. Any remaining problems along those lines?
Yeelight app itself still has control. Edit: Switched to autodiscovery with no joy. Pity, well if anyone else is glitching, or has an “aha!” thought lemme know.
Edit Edit: I guess time cures all things. After a day they just started responding again.
I think I found a bug.
When rearranging ‘actions’ that include service data, the service data does not follow the ‘action’ as it moves up.
Eg. I add a notify service and want to move it up (say second to last). It will in fact move, but its service data will not. It will now appear as if it belongs to the action that is now at the bottom.
Use a real editor.
I have the same issue with TUYA. Upgrade to 103.5 made things worst
Regards
M
After upgrading from 103.0 to 103.5 there is a behaviour change on some my automations that use the following value template as a Trigger:
{{ state_attr('sensor.daylight', 'daylight') == False }}.
When this is triggered this will turn some lights on if they are off, however, every time there is a state change in ‘sensor.daylight’ while daylight attribute is ‘false’ e.g changes from dawn to sunrise_start to sunrise_end. my lights turn on if they are off.
This did not happen before the update. If
{{ state_attr('sensor.daylight', 'daylight') == False }} matched it would only trigger when the state was {{ state_attr('sensor.daylight', 'daylight') == True }} and then changed to {{ state_attr('sensor.daylight', 'daylight') == False }} , now it triggers whenever ‘sensor.daylight’ state changes occur e.g changes from dawn to sunrise_start to sunrise_end.
I see that the state shows as all lower case (not sure it was like this before the update), so have changed the value template to this:
{{ state_attr('sensor.daylight', 'daylight') == false }}
but I don’t think this will fix it. Wondering if anyone else has this problem or similar? And not sure if it’s a hassio update, deconz update or conbee II update issue? Or perhaps my automation needs changing?
Thanks!
What happens if you plug it into the template editor? Is daylight a valid state?
if i enter the following {{ state_attr('sensor.daylight', 'daylight') == True }} it returns True as it is daylight now. {{ state_attr('sensor.daylight', 'daylight') == False }} returns False.
`{{ state_attr(‘sensor.daylight’, ‘daylight’) == random sting that does not match }}’ returns False.
these are the current state attributes sensor.daylight has
'on': true
daylight: true
friendly_name: Daylight
icon: 'mdi:white-balance-sunny'
device_class: daylight
state is ‘golden_hour_1’ for sensor.daylight
Can confirm that when the ‘state’ of sensor.daylight changes it still triggers this automation with the trigger for the attribute ‘daylight’ value template {{ state_attr('sensor.daylight', 'daylight') == False }} even though the attribute ‘daylight’ is still false and has not changed, that i can see.
I can replicate this issue at night (when sensor.daylight, state attribute daylight = False), changing the state to something different from the current state in developer tools > states > entity 'sensor.daylight' > state, when i do this and the lights are off changing the state will trigger the automation and turn the lights on. The daylight attribute is not updated/ is not changed, only the state for the entity is changed to something else and updated and triggers the automation which it didn’t do before the updates to Hassio, Deconz and ConBee II.
Thanks!
where did you get that sensors? does it have a documentation page?
It is part of Deconz https://www.home-assistant.io/integrations/deconz/#sensor
documentation under the ‘deCONZ Daylight Sensor heading’. So ConBee II firmware version update is unlikely to be /not responsible for the behaviour change? The automation is triggered whenever there is a state change for that sensor even though it is using the daylight attribute (which has not changed from false) and not the state for that sensor. This is reproducible via a state change for the entity sensor.daylight via the developer tools. I shall create another automation using another sensor if I can find one using a similar scenario to see if this is general behaviour.
I have replicated this scenario using the updater binary sensor eliminating Deconz/ sensor specific issues.
alias: test attribute trigger on updater sensor status update
description: ''
trigger:
- platform: template
value_template: '{{ state_attr(''binary_sensor.updater'', ''newest_version'')
== "0.103.5" }}'
condition: []
action:
- scene: scene.downstairs_lights_on
changing the state triggers the above automation.
During testing of the above test automation have noticed this happens only once and after I have reloaded the automations, so it does not trigger every time for this test automation. Now not 100% sure that this is the same as the sensor.daylight scenario and perhaps this is not a consequence of an update but never had the lights come on after I turn them off late at night before. Perhaps i have never reloaded automations etc after the lights have turned off at night before.
Updated hass.io from .103.4 to .103.5 this morning, and Ecobee climate/weather integration failed. 
Not certain whether it’s the hass.io image, but Ecobee’s online servers are up and running and recognize my two thermostats.
No log, no issue.
I’ve been doing a ton of work on my setup the last few days and twice I’ve lost the ecobee service - I wonder if it has to do with too many restarts/calls to their API?
Anyway, I just deleted the integration, removed the ‘App’ from their site, re-added the integration, entered the PIN and was up and running again in no time.
Hope that helps!
You’re absolutely correct. Did not have time to dig this morning before leaving for work. Looks like ecobee thinks my authorization has expired, despite my developer access working on their website this morning. Honestly, the first thing I thought was their servers were laggy/down. Reported it here for the benefit of any other Ecobee users who may have noticed it, as well.
2020-01-02 09:02:49 ERROR (SyncWorker_0) [pyecobee] Error while refreshing tokens from ecobee: 400: {'error': 'invalid_grant', 'error_description': 'The authorization grant, token or credentials are invalid, expired, revoked, do not match the redirection URI used in the authorization request, or was issued to another client.', 'error_uri': 'https://tools.ietf.org/html/rfc6749#section-5.2'}
2020-01-02 09:02:49 ERROR (MainThread) [homeassistant.components.ecobee] Error updating ecobee tokens
@Jessev I’ll give that a shot this evening, now that I have a bit more time. That should do the trick. It’s just that it worked so well for so long, I’d almost taken it for granted.
Yup, that did the trick. 
Kudos to @Jessev
Hi,
I’m really new one in HA.
I have worked a couple of months with last version 0.102 . Today I have upgraded to 0.103 (my first upgrade) and now I can’t access to HA.
I’m sorry because I have probabily lost my work but my experience could be usefull to community to fix this issue. For this reason I post the image of log…
You haven’t lost your work, but you should create a new thread. The image you have presented is not the log.
Create a new thread with information and you will be back up and running in no time. This thread isn’t the place for that.
Ok. Thanks
If you have a PlayStation I would skip this version (103.6). I updated thinking it may have the fix for the Ring Oauth issues but it did not but what it did do is break the PlayStation integration. Hopefully they will get these fixed soon.
Here is the issue in github: https://github.com/home-assistant/home-assistant/issues/30537
It will be fixed in 104: https://github.com/home-assistant/home-assistant/pull/30327
I just upgraded from Hass.io 0.103.5 to 0.103.6 but now there is a Nabu Casa error in the log. I cannot reach the GUI through the Nabu Casa URL. These errors persist after a Docker restart. Any clue?
This is the error:
2020-01-07 19:12:41 ERROR (MainThread) [hass_nabucasa.remote] Can't handle request-connection without backend
2020-01-07 19:12:41 ERROR (MainThread) [hass_nabucasa.iot] Error handling message
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/hass_nabucasa/iot.py", line 90, in _async_handle_handler_message
result = await handler(self.cloud, message["payload"])
File "/usr/local/lib/python3.7/site-packages/hass_nabucasa/iot.py", line 143, in async_handle_remote_sni
await cloud.remote.handle_connection_requests(caller_ip)
File "/usr/local/lib/python3.7/site-packages/hass_nabucasa/remote.py", line 216, in handle_connection_requests
raise RemoteNotConnected()
hass_nabucasa.remote.RemoteNotConnected
Edit: also created an issue on Github