[PRERELEASE] Virtual Prestaging

⚙️ Custom Apps and Drivers Custom Apps
21

@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.

Is this unsupported, or am I doing something wrong? The bulb I'm testing is a Hue and I've tried with both the Advanced Zigbee RGBW and @jonathanb 's Hue driver [RELEASE] Philips Hue Zigbee Driver (not using Hue Bridge)
I turned on all the things.
image

22

The current behavior is to sync CT/Hue/Sat if and only if the source and the target share the same color mode.

I could envision adding a mode that also pushes color mode, or you could run two virtual sources that will be used based on the target's color mode.

23

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.

24

My bulbs go down to 2000K, which is plenty red for me. But if you need to go redder, I can look at syncing color mode.

25

"need" is subjective. I would appreciate it and use it, but don't fret if you've got more interesting/important things.

1 Like
26

So I set out to do this, found a significant bug, and one partial rewrite later I came up with Reorganize handling of CT, RGB, and ColorMode by MikeBishop · Pull Request #3 · MikeBishop/hubitat-virtual-prestage · GitHub. If you're up to grabbing the version from that branch and trying it out, I'd appreciate the testing assistance before I merge it.

2 Likes
27

So I set out to do this, found a significant bug, and one partial rewrite later

No good deed goes unpunished :joy:

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.

28

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.

1 Like
29

Thanks! Pushed a commit to use null-safe dereferences (and tried a fresh install on a spare hub!).