Light On Using Color Or Color Temperature

#1

Typically when you turn on a light, it uses the last known settings when it was turned off. If you turned it off with a color set, it ignores the color temperature and comes on using that color, and vice versa.

The exception would be lights that allow changes while the bulb is turned off, without turning on. As of an update a few days ago (I believe), Lifx is now one of those types of bulbs.

Anyway, my question is as follows: How do you tell webCoRE to turn a light on in a certain color if it was turned off last using color temperature? Conversely, how do you turn a light on in a certain white temperature if it was last turned off as a color?

A related question: Can webCoRE query for which one (color or color temperature) the light plans to use before turning it on?

#2

This discussion might help you.

#3

Hi Pantheon,

Thanks for the link. I started from the post you referenced and read a bunch, then even went up to look at the original post and a few others, but am still not following.

Forget about list variables for a second. Imagine you change the color of a Lifx bulb to Blue while it’s off (Lifx allows this now), then turn it on. How do you tell webCoRE to turn it on using color rather than the color temp it shut off with?

I’m trying to avoid turning the light on white first, THEN visually changing it to Blue after that. I want it to just turn on Blue. This works if you turned it off when set to Green, but not when you turned it off set to 5000K.

You get the idea. Is there a “Turn On with color” or “Turn on with color temperature” command, rather than just the basic “Turn On”?

#4

If I am understanding you correctly, do you mean something like this…

image

Or…

22%20-%201

I have not tried the following…

image
image.png777×333 24.3 KB

Also, I know that the DTH for Lifx was updated recently and there have been some difficulties…https://community.smartthings.com/t/lifx-bulb-stopped-working-today/184586

#5

I’m not familiar with colour devices but I see what you are getting at. I think it is really an issue of what the device handler offers, both in terms of standard SmartThings capabilities, and any custom attributes and commands it defines. WebCoRE is good at offering you access to the custom stuff, but it can’t offer something that isn’t there. If the developer(s) of the device handler haven’t seen the need to offer the ability, it seems likely that there isn’t much webCoRE can do.

#6

Let me clarify…

What I’m trying to say is that if you captured all attributes of a bulb that has color + tunable white capabilities (color, color temperature, level, hue, saturation, switch), it would look something like this:

Color: #dc0000 (Red)
Color Temperature: 5000°K (White Daylight)
Level: 50%
…and so on.

But when you turn the light on, it can’t use both Red AND White Daylight at the same time (half bulbs would be cool). It has to choose a single “color”, so it picks whichever the bulb was using at the time it was last turned off.

I’m asking how to know (or control) that setting in order to program for it accordingly.

#7

I’ll simplify further with a mental exercise…

You capture these attributes from a bulb that’s currently off. How do you know if the bulb will be coming on Red or White?

#8

That’s what I thought you meant. What I am suggesting is that such knowledge and control, if available, does not seem to have been allowed for in any SmartThings capabilities, and so in turn there are no standard attributes or commands for webCoRE to use, and so no specific answers to offer. It would require the developer of a device handler to add custom attributes and commands and so if there is an answer it is device handler dependent.

Now it might be that the device will do what you require if given one or more of the existing commands in the right order. Again it may depend on the device handler and device.

#9

Got it. So, even though the bulb itself holds that information, it hasn’t been added universally to webCoRE. That’s because either it varies too much between devices, or isn’t something easily accessible for handlers.

Forgive the naivety, but aren’t DTHs only used in the ST Classic app? The Sylvania bulbs I have, for example, connect directly to the hub through the ST Connect app. So, if Sylvania has the ability to report on this native in the bulb’s firmware, and every other attribute (color, temp, hue, sat, etc.) is available withouth using the Classic app, where would a handler come into play?

#10

The ‘classic’ environment is very much built around the idea of devices connected to the hub and communicating by Zigbee or Z-Wave, with a device handler handling the device specific stuff and mapping it to SmartThings capabilities and events. The device handlers also define a custom UI to be used in the Classic app. The DTH model fits individual Wi-Fi based devices on the local net quite well and can be stretched to handle devices on local hubs or bridges, and even those connected by the cloud. In the latter cases there are typically apps doing most of the work with the device handlers just providing essential plumbing.

In the ‘new’ environment, device handlers still work, and indeed are still the way to handle new hub connected devices. However the ‘new’ app builds its UI from metadata describing the devices and the UI used gets defined elsewhere. That process isn’t fully mature yet. There are now ways to directly integrate third party clouds to the SmartThings cloud, or to integrate devices directly to the SmartThings cloud, without basically fudging a solution using device handlers designed for hub connected devices. ‘Placeholder’ device handlers exist to stop older software falling over. Devices created with the integrations in the new environment can still work with older apps (like webCoRE), and probably should if well written, but not all do.

Perhaps when talking of device handlers I should have allowed for new integrations, but I’m not sure what terminology to use yet. The bottom line is that something somewhere is providing an interface to the hardware in a standardised fashion. If it isn’t providing an attribute saying whether colour or colour temperature is currently in use, or providing commands to manipulate the device behaviour as required, then nothing is.

#11

This explanation helps, as I’ve seen it only with Kasa plugs so far.

Got it. Yeah, it makes no sense that this hasn’t been brought up in any meaningful way before. Seems like a fairly straightforward thing to wonder, as I’m only 5 or 6 months into ST and ran across it a few times already.

The only thing that’s obvious to me (as a half-assed programmer, graphic designer, and web dev, and someone with very basic hardware knowledge) is that the bulbs all keep some sort of marker or flag enabled to track which one - color or color temperature - to use when turning on. Whether or not it can be viewed or modified externally is another story.

Someone should try, then get it added to ST/webCoRE for whichever devices allow it. Probably easier said than done, but it’s a pretty significant attribute to have control over.

#12

orangebucket,
What is the new environment that is replacing webcore?
Thanks.

#13

Broadly speaking, ST is moving from an environment based on SmartApps running code written in Groovy that runs inside the ST Cloud, to an API based environment.

The legacy Classic environment does have an API but it is really about interacting with device handlers. All the ‘if this happens then do that’ type logic has to be explicitly coded in SmartApps.

ST are implementing a ‘Rules API’ which implements the logic natively in ST, and the goal is to replicate most of the functionality available in webCoRE pistons. The intention is that instead of pistons being saved as Groovy SmartApps, as they currently are, webCoRE would become a visual editor creating input for the Rules API.

What isn’t entirely clear is who will be doing the work required to convert webCoRE. Will ST be adopting it, or will the community be expected to pitch in?