A 1 sec transition was used when a light is turned on or when sleep state changes. The short transition should also be used when the CL switch is turned on. Also, because this is used in multiple spots, better to define it in one spot (this will also make it easier to make it configurable, if desired)
And only when light isn't already on. This should allow for users to disable CL when they adjust a light from the frontend, without CL immediately readjusting. This also should remove the need for checking state of each light before adjusting, because infinite loops should no longer trigger.
Supposedly the max light brightness is 255, but my Hue and Lightify lights both max at 254. 0 turns off the light, so the range is probably (0, 255) not [0, 255]
The biggest concern is that apparently any device_class with longitude, latitude, and elevation will show up on the HA map (not just device_tracker). In general, however, configuration options in attributes is extraneous and the community voted to remove them (https://community.home-assistant.io/t/circadian-lighting-custom-component/61246/355)
The basis of Circadian Lighting is to figure out how to adjust lights to mimic the sun, which is roughly parabolic above and below the horizon. Originally I used three points to calculate the parabolas - sunrise, sunset, and solar noon/midnight. I did a bunch of generic arithmetic to generate the parabola from those three points. The problem is that this arithmetic generates a parabola from _any_ three points - in reality the points I have are the intercepts and vertex.
The problem with the old method is that if solar noon/midnight did not fall exactly between sunrise and sunset then the calculated vertex could be more or less than 100%, which would cause the integration to set color/brightness values above or below the set min/max. Generating a parabola from the intercepts and vertex is much simpler and also should guarantee the min/max are what's expected.
In addition to this change, I'm also now calculating 4 "half" parabolas instead of just one for above horizon and one for below horizon. The "half" parabolas are: sunrise->solar-noon, solar-noon->sunset, sunset->solar-midnight, solar-midnight->sunrise. This is necessary for the case where solar noon/midnight don't fall exactly half way between sunrise and sunset, which is especially prevalent for users who specify a specific time for sunrise or sunset but not both.
I'm embarrassed at how it's been before it dawned on me that I could calculate the parabolas from intercepts/vertex rather than the three random points method, but hopefully this fixes inconsistencies for users - it should definitely fix issue #25!
astral seems to only be compatible with with deprecated time zone strings, and because times returned are timezone aware the calculations still work properly.
Include time_zone and elevation to get more accurate times. Always pass date into get_sunrise_sunset (otherwise it was returning inconsistent results). Add some debug logging.
