That's actually very close I wrote it for. It doesn't totally eliminate the flash, but the time to switch is a lot faster than waiting for CD's next update cycle. The color change is sent a few hundred milliseconds after the light reports turning on; it might look like part of turning on depending on the bulb. On mine, if you're watching, you can see a moment of the old value followed immediately by a transition to the new one.
Have CD set the color temperature on a virtual device, then use this to push it to the other devices.
@mbishop I'm a big fan of virtual prestaging. Yesterday, I moved from an old version to HPM and now my disable switches are not working. In checking the logs, it looks like an error is being generated that causes the app to not follow the disable switches when turned on. I'm getting the following:
org.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: java.lang.String.call() is applicable for argument types: (com.hubitat.hub.domain.Event) values: [com.hubitat.hub.domain.Event@7978c3]
Possible solutions: wait(), chars(), any(), wait(long), each(groovy.lang.Closure), any(groovy.lang.Closure) (initialize)
Basically, my disable switch went on at 7:42:26.637am, this error logged at 7:42:26.729am, and the light reverted back to the virtual bulb setting at 7:42:37.577am even though my disable switch was still on. I'm going to remove the HPM instance and try just pasting the raw code to see if works, but wanted to give you a head's up.
Sorry I didn't get to this as quickly as I'd hoped. I just pushed an update to HPM that should address this, and behave a little better around the disable switch to boot.
In basic testing, it looks like things are working again. I appreciate it and will keep an eye if anything comes up. I utilize this app for the vast majority of my lighting, so I’m a big fan!
@mbishop A quick update, but it appears that there is a similar error still being generated. It doesn't seem to affect the switch, but it is present. I'm seeing the following in the logs:
app:2702023-07-10 07:30:00.568 AMerrororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_app_evequefou_Virtual_Prestaging_Child_167.switchChanged() is applicable for argument types: (com.hubitat.hub.domain.Event) values: [com.hubitat.hub.domain.Event@12410bd] (switchChanged)
app:2702023-07-10 07:30:00.338 AMdebugSwitch changed to off (enabled)
app:2702023-07-10 06:00:00.498 AMerrororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_app_evequefou_Virtual_Prestaging_Child_167.switchChanged() is applicable for argument types: (com.hubitat.hub.domain.Event) values: [com.hubitat.hub.domain.Event@1c19fb4] (switchChanged)
app:2702023-07-10 06:00:00.474 AMdebugPrimary device changed: colorTemperature to 2657
app:2702023-07-10 06:00:00.453 AMdebugSwitch changed to on (disabled)
It doesn't seem to affect the operation; though, I did have a weird issue with lights turning off and then on again with the virtual bulb settings being applied. It might be a timing issue and unrelated to the app's operation.
Can you try opening the app and clicking Done? If that doesn't do it, look at the app properties and check what handlers are registered for the switch.
I hit done for each of my five child devices and the main one. This seems to have cleared up the error with the turning on the disable switch. However, it still kicks an error when I turn off the disable switch.
As for the handlers, you’ll need to guide me on how to do that.
Finally, I went back and tried different versions of the child app from your GitHub. I had to go back to your February revision in order for the error to now show up in the logs. The good news is that disable switch still works in your update from Friday.
@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.
It doesn't totally eliminate the flash, but the time to switch is a lot faster than waiting for CD's next update cycle. The color change is sent a few hundred milliseconds after the light reports turning on; it might look like part of turning on depending on the bulb. On mine, if you're watching, you can see a moment of the old value followed immediately by a transition to the new one.
