Home Assistant release with the issue:
0.94
Last working Home Assistant release (if known):
0.93.2
Operating environment (Hass.io/Docker/Windows/etc.):
Raspbian/Python 3.7.2/venv
Component/platform:
switch/flux
Description of problem:
When calling service switch.turn_on for switch.flux entity there is error in log:
2019-06-06 08:38:45 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/flux/switch.py", line 209, in async_flux_update
if stop_time <= start_time:
TypeError: '<=' not supported between instances of 'NoneType' and 'datetime.datetime'
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
- platform: flux
lights:
- light.bulbs_salon
- light.lamp_salon
name: 'Flux'
start_colortemp: 4400
sunset_colortemp: 3850
stop_colortemp: 3300
mode: mired
brightness: 255
transition: 30
interval: 600
I got what appears to be the same error. Added below over multiple lines so we have one that is easier to read :)
2019-06-06 20:28:59 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/core.py", line 1150, in async_call
self._execute_service(handler, service_call))
File "/usr/src/homeassistant/homeassistant/core.py", line 1172, in _execute_service
await handler.func(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 194, in handle_service
required_features
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 316, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 337, in _handle_service_platform_call
await getattr(entity, func)(**data)
File "/usr/src/homeassistant/homeassistant/components/flux/switch.py", line 186, in async_turn_on
await self.async_flux_update()
File "/usr/src/homeassistant/homeassistant/components/flux/switch.py", line 209, in async_flux_update
if stop_time <= start_time:
TypeError: '<=' not supported between instances of 'NoneType' and 'datetime.datetime'
Same here. Hass.io, RPi 3B+, started with 0.94.
RPi 3B started with 0.94 exact same issue, running Raspbian GNU/Linux 9 (stretch)
Same for me. 0.94 broke it. Please fix
When I call the Flux switch I get the following:
switch/turn_on. '<=' not supported between instances of 'NoneType' and 'datetime.datetime'
This issue is related with PR#23832. When I used sun component from before this PR as custom component issue gone.
This issue is related with PR#23832. When I used sun component from before this PR as custom component issue gone.
@bieniu Not sure I follow. Once you added the sun component (i.e. sun:) to your config you stopped getting the error? I have had sun enabled in my config for a long time (2 years!). Is there something else you did?
I just re-read it. I think you are saying the sun component refactor likely caused this issue? In that case, I agree!
Yes, when I use old version of the sun component this issue has gone.
I think you're absolutely right - looking through the changes (linked above) it appears as though the way astral events are generated has changed, and it doesn't look like the component specifically defines them as datetime any more, so when the value for dusk gets pulled across to be used as stop_time, it can't be used for logical comparisons.
Have commented on the commit and hope @Swamp-Ig sees this!
Seen it, will take a look today. That's very odd though!
Ok this is odd that the change to the sun seems to have caused this issue, but nothing in the patch has touched code that affects this particular area, so I'm not sure why this is happening.
These lines of code are making incorrect assumptions about the sun, in some locations the sun never sets and/or never reaches twilight at some times of year, in these cases the get_astral_event_date method quite correctly returns None.
The code at this point needs to handle this situation gracefully rather than throwing an exception. I'm not entirely sure what the flux component is trying to achieve here, or what the correct behaviour would be in these situations, so it's hard for me to fix the issue, but yes that's what needs to happen.
A test case would be best defined by giving the latitude/longitude/timezone of your hass instance.
A test case would be best defined by giving the latitude/longitude/timezone of your hass instance.
@Swamp-Ig I'm not sure how this helps, since I think it just needs to be night-time anywhere. However...
homeassistant:
elevation: 130
latitude: 55.948372
longitude: -3.199466
time_zone: Europe/London
And the config I use.
switch:
- platform: flux
lights:
- light.study_sideboard
- light.study_desk
- light.study_ceiling
- light.study_bookcase
name: Study Flux
brightness: 255
disable_brightness_adjust: true
mode: rgb
interval: 120
If anyone needs a temporary fix in the meantime, here is an automation I've made that does the legwork of the flux switch - however, you need one automation per device to flux. Edit values as needed:
- alias: Flux
initial_state: True
trigger:
- platform: state
entity_id: light.bedside_lamp
from: 'off'
to: 'on'
- platform: numeric_state
entity_id: sun.sun
value_template: "{{ state.attributes.elevation }}"
above: 0
- platform: numeric_state
entity_id: sun.sun
value_template: "{{ state.attributes.elevation }}"
above: -6
below: 0
- platform: numeric_state
entity_id: sun.sun
value_template: "{{ state.attributes.elevation }}"
below: -6
condition:
condition: or
conditions:
- condition: state
entity_id: light.bedside_lamp
state: 'on'
action:
service: light.turn_on
data_template:
entity_id: light.bedside_lamp
color_temp: "{% if states.sun.sun.attributes.elevation > 0 %}300{% elif -6 <= states.sun.sun.attributes.elevation <= 0 %}400{% else %}450{% endif %}"
transition: 10
OK there's definitely something odd going on. If you run test cases individually from the test suite they fail, but if you run the whole lot they don't.
Will see if I get a chance to look at it over the weekend.
OK I'm unable to replicate this one unfortunately.
I did play around with making a test case to try and pinpoint the problem, but the test case works all fine.
If I alter the config to match this comment it still works OK.
Note that there is a bug here, in places where the sun doesn't rise/set/hit twilight then None comparison exceptions are going to end up being raised at the point where people are complaining about. I'm quite at a loss as to why this seems to be happening here though, at the latitude/longitude given above the sun does hit twilight.
The changes to sun.sun don't affect anything touched by that particular function, they're not even in the same area.
I can't really fix flux either to handle the None issues because I don't know what the correct behaviour would be at that point. I don't even own any colour controlled lights, so I can't test it at home.
I'm sorry but I can't really help you further at this point without the ability to replicate the issue.
@Swamp-Ig Maybe you can try with my config?
homeassistant:
latitude: 52.1084
longitude: 19.9406
elevation: 97
unit_system: metric
time_zone: Europe/Warsaw
switch:
- platform: flux
lights:
- light.bulbs_salon
- light.lamp_salon
name: 'Flux'
start_colortemp: 4400
sunset_colortemp: 3850
stop_colortemp: 3300
mode: mired
brightness: 255
transition: 30
interval: 600
I don't have a light with colours to connect it to though. Is there a template light?
I don't have a light with colours to connect it to though. Is there a template light?
Can you use the demo component? https://www.home-assistant.io/components/demo/
I'm having exactly the same issue. Let me know if I can provide any details.
OK have figured it out. Pushed a PR that fixes the issue.
This has uncovered an issue in flux, it won't properly handle latitudes where the Sun either doesn't set, or doesn't reach twilight. An elevation based approach where the colour temp is based on the elevation of the sun would be more appropriate.
Just a note, before you start working too much on the flux switch: it was agreed that the next substantial PR for flux should be a move away from the switch domain.