Reply to thread

Message

<blockquote data-quote="Rick164" data-source="post: 1203022" data-attributes="member: 17766">Not sure if that can be done as we have no control over Hue schedules atm, right now we store its own last know color on sleep and restore on resume by default in AtmoHue without checking what the bridge has setup.Tried to read that out states and colors last time with the library we currently use but didn't work for some reason.Transition time = basically smoothing time, lowering it makes color changes faster and too low will get commands piling up at BridgeRemote api delay = delay between each command AtmoLight sends in this case, lowering the value will make it process commands faster.Would put transition time at 250 and api delay at 200 as a starter and lower if it doesn't act up, that has worked in the past here <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" /></blockquote>

[QUOTE="Rick164, post: 1203022, member: 17766"] Not sure if that can be done as we have no control over Hue schedules atm, right now we store its own last know color on sleep and restore on resume by default in AtmoHue without checking what the bridge has setup. Tried to read that out states and colors last time with the library we currently use but didn't work for some reason. Transition time = basically smoothing time, lowering it makes color changes faster and too low will get commands piling up at Bridge Remote api delay = delay between each command AtmoLight sends in this case, lowering the value will make it process commands faster. Would put transition time at 250 and api delay at 200 as a starter and lower if it doesn't act up, that has worked in the past here :) [/QUOTE]

Verification