@mbishop thanks for this app. Should it be capable of sync'ing a bulb across CT vs RGB modes? What I mean by that is have the source a RGBW light and have the secondary device(s) also RGBW. Starting from a happy place, say, CT 4000 for both the source + secondaries, if I change the CT and/or Level on the source, the secondaries update. But if I change the source to an arbitrary colour, then the secondaries have their Level adjusted, but remain in a CT mode. Similarly if everything was a colour and then trying to hop back into the CT mode the secondaries remain in RGB mode.
Thanks for confirming I wasn't crazy. Not for that reason anyway.
My original thought was to use CT during the day and shift more reddish at night. For now I'll reduce complexity and stick to CT throughout, then revisit "sometimes using colour" after I get more comfortable with the current moving parts.
So I set out to do this, found a significant bug, and one partial rewrite later
No good deed goes unpunished
I'll take it for a spin in the coming days. You saw my PR earlier where I bumped into my own issues and knocked me back to rethinking the landscape a bit (I've discovered Scenes don't seem to be implemented in drivers at all). So my focus is at a more basic level now. But I'll poke at your branch to help you get that improvement vetted.
I tried making a fresh "new" app from your branch so that it wouldn't change anything with what's installed and so that HPM will keep giving me the updates to one in use. I made changes to the name to keep it distinct. I think I did that right. No other changes.
Installing the new parent is smooth. Installing a new Child I immediately get:
java.lang.NullPointerException: Cannot invoke method currentValue() on null object on line 153 (method mainPage)
Although primaryDevice is marked as required, it looks like updateDevices gets called before primaryDevice is initially set.
Hey @mbishop….Mike love this app — mega thank you.
A detail question—for devices that don’t have xxxxPreset implemented, any reason to expect this app would be faster at turning the light on to the desired HSL value(s) than interacting with the device itself, where faster = less of the brief flicker when the light goes on?
I’m guessing the answer would be NO since in these cases the device itself hasn’t stored these values in advance. It’s not like the prestaging reduces overhead when the “on” event itself happens. Correct?
In general, no. It sees the on event and responds by sending the target HSL command. However, I have noticed that some bulbs respond immediately to HSL command received during a transition rather than beginning a new transition, so there might be some device-specific quirks around this.
Hello all - I am using Hue CT bulbs throughout my home with no hue hub. direct to HE. all works amazingly well.
Question: what driver is best to use with these bulbs so that they work well with this app?
Optional question: (I understand it's involved to respond to this one, I can figure it out im sure, but if anyone has time and wants to provide guidance, would be much appreciated!) what is the general configuration to get this to then work with recommended drivers above? I have tried to follow the guide using a virtual switch as a master. it just doesnt seem to get what I am hoping for in terms of response. maybe im doing something wrong.
