Today’s SharpTools.io platform release adds the popularly requested Fade Level (Dim over Duration) feature to the Rule Engine and Custom Attributes (dynamic subscriptions) to dashboards.
Fade Level
Have you ever wanted to change the dim level of your lights over a period of time? Now you can with the new fadeLevel macro command. If your device implements the setLevel() command, you’ll now see a new ‘Macro Commands’ group with fadeLevel() in the list of device commands when creating a new Device Action in the Rule Engine.
The fadeLevel() command accepts the following parameters:
From: the optional initial value to set the level to. Note: If this value is omitted, the system will use the current level to determine the dimming levels over the specified duration.
To: the target dim level to end at
Over: the period of time over which to dim from the from level to the to level.
As you may have noticed, the command is grouped under a new Macro category… internally, the SharpTools.io platform will calculate a series a setLevel commands to send over the specified duration to achieve a gradual dimming from the start value to the end value.
This is particularly useful in dimming lights up or down in the mornings and evenings to approximately align with the rising and falling of the sun, but can be used with any device which offers setLevel commands.
Custom Attributes (dynamic subscriptions)
Today’s release includes the ability to use custom attributes in Hero Attribute tiles in the SharpTools dashboard. Previously, dashboards only exposed the attributes defined by the core/hero capability of a device. While this worked well for many device types, we heard your feedback that some devices implemented multiple capabilities or custom attributes that you wanted to expose in your dashboards.
This feature is immediately available for SmartThings users and is currently in the Hubitat 2.0.6 beta release (which will likely be available to everyone in the next few weeks).
Additionally, this improvement resolves an issue that some users may have experienced with Hubitat Weather device tiles where some attributes would not update as expected.
So I tried fade level in a rule.
My one set of lights was off because we left when we typically wouldn’t be.
Instead of fading from 0 to off, (I think it was 100% before shut off), it was flashing off then to the dimmed step.
So something like:
90%
Off
70%
Off
40%
Off
20%
Off
Is this just an issue with Hubitat or is ShapTools sending the individual commands?
Thanks for the report, @Keith_Croshaw and sorry to hear that things aren’t working as expected. Based on the screenshot above, I’m assuming it was the Dining Room Overhead Lights part of the rule that was doing the 90% → off → 70% → off… 20% → off?
Are there any other automations on that light which could be causing it to turn off?
SharpTools should just send the 90 → 70 → 50 → 30 → 10 → 0 sequence of commands. Internally it’s calculating and queuing a sequence of setLevel commands to be sent to dim from the current level to the target level.
Ok good to know.
Yes it was the dining room overhead lights.
They were turned off about 30 minutes before the fade level commands begun by my Mode to Away Rule in Hubitat. I’ve paused the old Hubitat Simple Lighting apps that used to do this…
That’s all I can think of.
@Keith_Croshaw have you tried again without other automation( Simple Lighting app)? As Josh mentioned, fadeLevel basically sends a sequence commands to adjust the level. You may also want to check the log to confirm where the “off” commands came from. Thanks.
So I was able to repeat the issue partially.
This time the Dining Room Lights, which we already off turned on and did fade level appropriately.
What I think is happening is I would expect it to respect that the light is already off, but for some reason it bumps it up to 100% and then fades it off appropriately.
Odd note after the fade the level of the lights is 5% but the switch is off.
I believe the lights turned themselves on automatically when received the first “setLevel” command based on their device design. In our tests, we observed lights turn themselves on automatically when received “setLevel” or “setColor” command, but won’t turn off when received setLevel:0 command, but this is really based on how they are designed and can vary. I guess I kind of understand the reason why they are designed in this way, but not completely.
So in your case, you may want to add an IF_Condition to check the lights’ switch status first, and only continue the fade command if they are On; otherwise, just ignore it.
This is interesting. I am wondering if your light device is designed to turn itself off when level is less than 5 or something, or is there another automation triggered to turn it off? Can you please try manually set the light level to 1 or 0 to see if the light actually turn it self off? Thanks.
I think this is really a key point… I’ve found that the implementation of dimmable devices varies across the different devices I’ve tested with.
As James mentioned, sending a setLevel command with a value greater than 0 to a device that is off should turn it on to the expected level, but some devices don’t do this.
Similarly, sending a setLevel command with a value of 0, should turn a device off, but some devices don’t do this (eg. Hubitat Yeelight integration).
Yea that’s reasonable, I wonder if others will expect this auto-magic evaluation to take place before the setLevel command gets sent in the first place. We’re in the DIY space so hopefully others will just figure it out too.
I just like to put myself in the shoes of somebody who doesn’t like to see how things break and just figure out how to fix them with the tools available. If that type of feedback isn’t helpful, let me know, I just like to imagine the kind of responses the everyday Joe who doesn’t have time for this stuff might report.
And to add to that… in the case that the device is switched off, you might expect the level to be reported as 0, but it may be reported as the last known value before being turned off. And SharpTools uses the actual reported level as the starting point for the dimming if you don’t explicitly specify a starting level.
And to further complicate things, some devices (like the Yeelight on Hubitat), basically just ignore a setLevel(0) altogether.
One workaround here is to explicitly set your starting point and ending point… or to use if conditions.
–
You might ask why we can’t just use the switch as a basis for overriding the starting level. For example, if the level is reporting as 60, but the switch is off, then can’t we assume the starting level should be 0? Unfortunately, we can’t as other devices implement switch and level in different ways.
Take for example an AV Receiver. It might use the switch to reflect the on/off state and the level to reflect the volume. If someone wanted to fade their volume to a certain level and the receiver was off, it wouldn’t be right to assume that because switch = off, then the starting level should be 0.
