StartRampToLevel for easing into the morning via smart bulbs

I’m trying to set MBR lamp and Kitchen sink lamp to go from 0 to 20% over 00:00:30 period each morning at 0630 ET. The smart bulbs are dimmable.

I tried StartRampToLevel but that did nothing this morning. My question is simply, of these options, is this the correct one to get to the goal?

image

This isn’t really a Reactor question as much as it is a device question. Since you indicated the devices are smart bulbs, it’s up to both the plugin that controls them and the bulb to support the action (or not). So that’s what you need to find out. Reactor lists all the actions in the service. There’s no way for Reactor to tell which are implemented and which are not.

Gotcha. So trial/error, sounds like. :heart_eyes:

What kind of bulbs are they?

GoControl dimmable bulbs. Precisely, GoControl Z-Wave Dimmable LED Light Bulb, LB60Z-1

If your device does not have the capability there is Lua code.

1 Like

WARNING AND DISCLAIMER: The following workaround is not recommended.

Determined to recast this as a “Reactor problem”, I hastily cobbled together the following routine that I think achieves more or less the same operation. Namely, at a certain time (default = Sunset) causing a light (here, my “Fireplace” Hue light #110) to steadily brighten from OFF to a preset level (default = 70%) over the course of some fixed time (default = 30 minutes), incrementing by predefined steps (default = 1%) every fixed interval (default = 15 seconds). NOTE: If the light is already ON at or brighter than the target value, this routine will not run.

Here’s how I’m doing it:

EXPRESSIONS

CONDITIONS

ACTIVITIES


NOTE: Truncated value field should read {lightLvlNext}

OUTPUT CONTROL


This is necessary in order to force the routine to continually execute every N (default = 15) seconds to increment the brightness value.

Just because you can do something doesn’t mean you should, my friend. :smiley:

Ramping is often done on the device itself, when it’s available. These actions and parameters are meant to give access to that feature, not guarantee it. Doing it in software on a ZWave mesh is a dicey proposition–no guarantees on timing, and for Vera in particular, a high probability of creating timing problems within the ZWave subsystem and bringing the dreaded deadlocks. Got CAN? You’re playing with fire. Aside from that, a lesser consideration is that you’re also using a Very Large Subsystem to do a Very Trivial Thing (when you have a hammer, everything looks like a nail).

1 Like

WHO SUMMONED ME?

1 Like