stefanvictora/hue-scheduler

☀ Adjust your Philips Hue lights to your natural rhythm. With advanced schedules and transitions based on solar times.

hue-scheduler's Issues

No transition

Hi! I set a 100 min transition, yet it doesn't work for some reason. The config file looks like this:

Szoba, Konyhapult, Etkezo, Furdoszoba, WC 07:00 ct:4400 bri:254 tr-before:100min
Szoba, Konyhapult, Etkezo, Furdoszoba, WC 08:15 ct:4400 bri:254 tr-before:30min on:true
Szoba, Konyhapult, Etkezo, Furdoszoba, WC 20:00 ct:3400 bri:254 tr-before:100min
Szoba, Konyhapult, Etkezo, Furdoszoba, WC 22:00 ct:2200 bri:128 tr-before:100min

But transitions don't work. For example the lights should change colour very slowly starting from 20:20 and reaching 2200 K at 22:00. Instead, all the lights immediately switch from 4400 K to 2200 K exactly at 20:20. Why is this happening? How can I get the expected behaviour?

Continuous transition management

First off, thanks for creating tools related to controlling Hue lights. I've previously used f.lux to manage lights to transition my lights throughout the day but am exploring more customizable options.

As a disclaimer I haven't used hue-scheduler yet but plan to play around with it and read through the documentation.

I'm interested in creating a configuration where when lights are turned on they are set to a setting relevant to the sun's position.

In the current discrete state configuration it's my understanding that hue-scheduler will identify the state matching the current time, set the lights to the defined parameters, and then start transitioning to the next state if there exists a tr-before value defined.

For example in the example configuration:

Office    civil_dawn   ct:6500  bri:150  tr:10s 
Office    sunrise      ct:5000  bri:200  tr-before:90min
Office    12:00        bri:255  tr-before:90min
Office    sunset       ct:3000  bri:200  tr-before:90min
Office    civil_dusk   bri:150  tr-before:90min
Office    23:59        ct:2000  bri:100  tr-before:90min

Let's assume sunset is at 18:00. If the Office light group is turned on at 16:00 then the Office lights will be set to ct:5000, bri:255 as hue-scheduler is taking control of the lights. Then 90 minutes before sunset (16:30) the lights will begin to transition to ct:3000, bri:200. However if the lights were turned on at 17:30 then the lights would still be set to the same ct:5000, bri:255 as the previous scenario and hue-scheduler will execute the same full state-to-state transition in 30 minutes to match the sunset state.

My ideal execution of the transition (when lights are turned on at 17:30) would be for hue-scheduler to calculate the mid-transition state, set the lights to that state, and then continue the transition to the next state. In other words, it doesn't matter when the light was turned on, the light configuration is based on the time of day (relative to the sun constant times).

Not to overload this issue but I'm assuming that tr-before cannot reference sun states (e.g. tr-before:civil_dusk-sunset). Also I believe a "solar_noon" constant would be useful :).

Interested in what you think about this proposed behavior.

Docker image

Great project, thanks a lot for making and maintaining it 🙏🏻

I'd just suggest that you make it available as a docker image. I run all my home automation/media server stuff as docker containers via docker-compose, which makes it super easy to handle updates and related files for each running container. I think publishing this as a docker image would make it easier for new users to jump in and get started :)

Thanks again 💡

Schedule configuration validation

Hi, I just realized some schedules I configured in the summer, don't make sense in the winter, anymore. Example:

...
noon+180
golden_hour-180
...

Mathematically, the 2nd line should be scheduled before the 1st line. Hue scheduler still "works". Maybe it does this, already. If you think about more complex schedules and situations (tr, tr-before, turning on the lights during overlapping phases or having them powerd on all the time) I don't even know what users are supposed to expect here. Is there is any good interpretation people would understand and intent to configure like that?

I can't think of any good interpretation here. That's why the idea of validating the schedule configuration came into my mind. I'd be happy if hue scheduler would refuse to execute such a "weird" configuration (already in the summer in my case). "Weird" might be defined as:

1. The configured schedule order doesn't match the execution order.
2. There're overlapping phases.
3. ... both detected in advance for an entire year when hue scheduler is started for the given long, lat, elevation.

Thank you ❤

After struggling with many other solutions to achieve a proper time and sunrise/sunset based light I nearly surrendered and thought about creating something on my own. Fortunately, I found your project and it works like a charm. It has literally everything I was planning to do on my own as neither the philips hue solutions (natural light, dimmer switch, hue labs Time-based light) nor the other 2 major hue automation projects provide all of this in combination:

• proper support of dumb wall switches that really works
• time constant based scheduling (more than just sunrise, sunset)
• time constant offset capability
• time-based light
• easy configuration

Thank you so much for your great work!

It runs on my NAS packed inside a docker container just fine. This project needs way more attention. I didn't see it somewhere posted anywhere though many people request such capabilities. I found it directly on github by attempting a couple of keywords.

I am looking forward to see the first point on your roadmap (conditional states) implemented and released. With that it would solve 100% of my needs.

Feel free to close this issue :-)

Ikea Tradfri bulbs support

This is a feature request to have a better support for Ikea Tradfri bulbs.

In comparison to v0.7.1 the compatibility of v0.8.0 with these bulbs got reduced. Here is why: as far as I know and based on some API tests I made to confirm that with these bulbs (LED2101G4) and the latest Firmware (1.0.003) at least these properties are different to hue bulbs:

1. ct and bri sent within 1 API request will apply only ct. Unfortunately, fetching the data (see below) will respond with the intended values for some seconds, even though bri won't be applied.
2. ct and bri have to be sent with 2 individual requests and with a little delay in-between. Otherwise the ongoing change, e.g. brightness at 254 set to 1 (which is not instantaneous) is aborted in between. A delay of 100ms seems reasonable. Or send with a transitiontime of 0 (source).

As mentioned in #2 with v0.7.1 a workaround is possible: just run at least 2 hue schedulers, one responsible for brightness and another responsible for color temperature and make sure to schedule both properties at different times. Only the retry behaviour might violate number 2 but this is very unlikely.

With v0.8.0 this workaround yields to hue schedulers sending requests concurrently when a light is turned on due to the fast event mechanism. And the change from one scheduler would be interpreted by the other scheduler as a manual change, probably.

For sure another workaround would be to schedule either of these properties and never schedule the other property.

This is the response from such a Tradfri bulb:

https://ip/api-key/lights/7

{
 "state":{
    "on":true,
    "bri":254,
    "ct":250,
    "alert":"select",
    "colormode":"ct",
    "mode":"homeautomation",
    "reachable":true
 },
 "swupdate":{
    "state":"notupdatable",
    "lastinstall":"2023-07-06T17:51:53"
 },
 "type":"Color temperature light",
 "name":"Wohnzimmer Vorn #1",
 "modelid":"TRADFRI bulb E14 WS globe 470lm",
 "manufacturername":"IKEA of Sweden",
 "productname":"Color temperature light",
 "capabilities":{
    "certified":false,
    "control":{
       "ct":{
          "min":250,
          "max":454
       }
    },
    "streaming":{
       "renderer":false,
       "proxy":false
    }
 },
 "config":{
    "archetype":"classicbulb",
    "function":"functional",
    "direction":"omnidirectional"
 },
 "uniqueid":"94:34:69:ff:fe:bc:25:c1-01",
 "swversion":"1.1.003"
}

edit: Actually, hue scheduler recognizes a manual change for them with each schedule. I am not sure why, yet. When I check the lights with the above API request the intended brightness is set correctly.