search

michielpost / Q42.HueApi

C# helper library to talk to the Philips Hue bridge
MIT License
409 stars 114 forks source link

Turning light OFF then ON via API results in low brightness #233

Closed Exergist closed 3 years ago

Exergist commented 3 years ago

This may be an issue with the Hue API itself, but I wanted to mention it.

Let's say you set a light to RED at 75% brightness (the light is on of course) in the Hue (Android) app. If you then turn OFF the light in the app and then turn it back ON again in the app the brightness will jump back to 75%. Behind the scenes the prior state of the light is remembered.

If again you set a light to RED at 75% brightness (let's just say it's done in the app again) but perform the OFF and subsequent ON actions via Q42.HueApi, the result is the light is indeed ON but at a Brightness value of 1. In this case it seems like the prior light state is forgotten.

If the 75% bright RED light (again, configured in the app) is turned OFF in the app but turned ON via Q42.HueApi the light WILL return to 75% brightness. This agrees with what the Hue API documentation says as of this writing (Core Concepts section) regarding turning a light ON:

on – This is the easiest example. A light can be on or off. So setting this resource to true turns a light on to its last setting. Setting the resource to false turns the light off.

If this inconsistent behavior related to the OFF action (remembering or forgetting the brightness when using the app vs. Q42.HueApi) is indeed an issue with the Hue API itself, then the light state must be stored prior to turning it OFF and later recalled when turning it ON to have the brightness mimic the app behavior.

michielpost commented 3 years ago

The Q42.HueApi library will not remember the state, it will only send the on/off command. If you don't specify any brightness, it should not send it to the bridge, and the hue bridge will turn the light back on to the brightness it had previously.

If the app and this library behave different, best is to check the json requests to the bridge to see why it is different. The app communicates with the bridge using the same api as this library. So if you send the same json data, the behaviour should be the same.