Rule to slowly fade in or out any given item based on variables

'numeric" was just an example. I’m usually more explicit with yourNumericValue or something.

Caution;

These are two different things. Commands are NOT states.
Commanding an Item may eventually result in a state change.
Examining the state immediately after a command may give you the before or after state, it’s pot luck with timing.

Who cares - don’t look at the state! Just use the command.directly
... "Dimmer,"+ receivedCommand.toString+",3000 ...

  • and in this case receivedCommand is the name of a real variable that is automatically available in rules triggered by commands.

I know, it was also a example from me, I replaced numeric with the testD in my rule :wink:

Hehe nice, didn’t know that this was possible but that’s indeed even more clever then looking at the state of the item, just edited the rule again and it seems to work quite well, it looks really nice :smiley: much better than the normal light switching! Thanks!

I’ve been using @tbnobody’s version but have been having problems with it going into infinite loops. Maybe it was because I set the timer to repeat too agressively but I couldn’t work out why so decided to iterate on the approach.

Rather than bump the value up or down a stepSize on every timer tick, mine calculates the required brightness at the time of the tick using linear regression (Y=Ax + B) and will always exit within the required fade time.

Usage

universaldimmer.sendCommand("item_name,target-value,fade-time-ms")

YMMV. Happy to receive feedback/PRs. I’m a solid coder but little experience in Java.

** EDIT: Updated to incorporate Joachim’s suggestions

2 Likes

Hello,

nice idea.

I have made a first Version as Python Script. It have the same Syntax, so you can change to NGR.
Only DIMMER is active, but the Function have one more switch, to regulate the Steps in Milliseconds.

I hope for Testinpeople.
The Script are availabe here:

All thanky by PeterK, it is his idea, i´m only convert it.

Best Thanks

Thanks for the code - works very well!

One minor suggestion for improvement:
Instead of having “type” as a parameter you can retrieve it from the item itself

// item Type: HSBType->Color or PercentType->Dimmer

val item_type = item.getAcceptedDataTypes().get(0).toString.split(" ").get(1).toString.split("\\.").get(6).toString

var int startingBrightness = 0

if (item_type == "HSBType") {     // type == "Color"
        startingBrightness = (item.state as HSBType).getBrightness().intValue
} else if (item_type == "PercentType") { // type == "Dimmer" 
        startingBrightness = (item.state as DecimalType).intValue
}

Example:
item.AccecptedDataTypes: [class org.eclipse.smarthome.core.library.types.PercentType, class org.eclipse.smarthome.core.library.types.OnOffType, class org.eclipse.smarthome.core.types.UnDefType]
thereof get(0): “class org.eclipse.smarthome.core.library.types.PercentType”
thereof split(" “).get(1): “org.eclipse.smarthome.core.library.types.PercentType”
thereof split(”\.").get(6): “PercentType”

This is e.g. useful for dimming a group of lights of different types (Color or Dimmer)

gLight.members.forEach[ i | universaldimmer.sendCommand("100,10000," + i.name) ]

Kind regards, Joachim

1 Like

One minor correction:

if (item.state == null) 
    { ...

should read

if (item.state == NULL) 

    { ...

(see also [SOLVED] NULL | UNDEF | null | uninitialized)

1 Like

Thank’s Joachim - have incorporated both tips and updated the gist.

:warning: item_name is now the first argument - not last.

Hi.
I like the idea behind the script and this matches pretty much, what i need for my automation.
So i created the item using “add item (textual)”-function in OH3.
Then i created an “universaldimmer.rules” file in the “rules” folder of OH andjust copy/paste the whole code block from the second post ino the file.
Now i can see the rule “Universaldimmer” in my rules-list.

To make it work now, i set up a new rule:

triggers:
  - id: "1"
configuration:
  itemName: Bewegungsmelder
  state: ON
type: core.ItemStateUpdateTrigger
conditions: []
actions:
  - inputs: {}
id: "3"
configuration:
  itemName: universaldimmer
  command: Dimmer,20,2000,10,Lampe_Helligkeit
type: core.ItemCommandAction

“Bewegungsmelder” is a presence sensor and this seems to work, but my light “Lampe_Helligkeit” keeps off. The log file tells me:

*[ERROR] [.internal.handler.ScriptActionHandler] - Script execution of rule with UID 'universaldimmer-1' failed: The name 'ScriptServiceUtil' cannot be resolved to an item or type; line 48, column 17, length 17 in universaldimmer*

So i don’t reallyknow, whats wrong there, but it seems, the scrips can’t find my light, or the
“ScriptActionHandler” does not work at all …
I’m stuck at this point, could you help me plz?

Well, i did it exactly, like the original creator of the script:

import org.eclipse.smarthome.model.script.ScriptServiceUtil

right at the first line in the rules-file
Is there a way to check whether the import is really successful?
Or is there a dependency which has to be met before? (Java is installed ofcourse)


Also i found another post ([Rules DSL] Get item from string name! which tells, you need to change the import to

import org.openhab.core.model.script.ScriptServiceUtil

And the last part did it! :smiley:
but you need to restart openhab, even the rule is reloaded, as sonn as you save the changes (te log file also shows, that the module is realoaded)

But you’ve shown us a UI entered rule, not a rule from a xxx.rules file as used in 2018? The UI entered rule shares nothing with your import, which is local to the xxx.rules file it is in only.

I don’t think you can do imports like this in UI rules.

But you’ve shown us a UI entered rule, not a rule from a xxx.rules file as used in 2018?

Right.
As described, this is a new rule i created, which calls the text-coded rule, as soon as movement is recognized by the presence sensor :wink:
It’s a bit tricky, but the error was caused by changed import in version 3 in combination with OH not loading the import, when it is not restarted.


Args … the script seems to be not ok anymore (due to changed environment i guess?)
The script runs now, but it’s buggy.

[ERROR] [.internal.handler.ScriptActionHandler] - Script execution of rule with UID 'universaldimmer-1' failed: 'plusMillis' is not a member of 'java.time.ZonedDateTime'; line 69, column 27, length 22 in universaldimmer

The light is dimmed by one step (which is set as the 3rd parameter) and stops then. It’s not repeated until the set destination value (the 1st variable).
So to be precise: when i turn my light on by hand to 40% and start the script with as follows:

Dimmer,0,2000,10,Lampe_Helligkeit

The dimmer is set from 40% to 30%, then 30% to 38%, and again 38% to 30% and the script stops …


Also found a solution for this.
You need to change to lines to make it work nice and smooth :slight_smile:

now.plusMillis(mytime)

must be changed to

now.toInstant().plusMillis(mytime).atZone(now.zone)

You should be able to. If it doesn’t work it’s a bug.

You didn’t mention whose version you were using. The code snippet you mention that needs fixing isn’t in my version. Your symptoms sound like problems I had with the one originally posted.

See my post from Sept 20 for a version that works much better. It has been working flawlessly for me.

I’ve been using your version for months without issues, although upgrading to OpenHAB 3 has broken the universaldimmer script, as it doesn’t seem to work at all.

I receive the following error in my openhab.log file when I attempt to execute a dimming function:

2021-01-23 00:55:01.396 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID ‘universaldimmer-1’ failed: The name ‘ScriptServiceUtil’ cannot be resolved to an item or type; line 40, column 20, length 17 in universaldimmer

Thinking it may have been caused by the import line at the very top, I commented out

import org.eclipse.smarthome.model.script.ScriptServiceUtil

and replaced it with

import org.openhab.core.model.script.ScriptServiceUtil

after reading My experience migrating from OH2.5 to OH 3.0 although that made no difference and the same error shows up in my logs when I try to use the universaldimmer command on a light.

The only other thing I’ve noticed that has broken for me as well is googletts, everything appears to be set up the same, although I’m just trying to work out one issue at a time.

I didn’t realise OH3 was out. Will look into upgrading and fixing the script.

Oh that’ll be great, thank you so much! :slight_smile: I wasn’t aware either until 3 or 4 days ago, when I randomly visited the OpenHab blog and saw it came out on Dec 21.

I’ve loved the universalfader script so much because it’s worked so well with my TP-Link Kasa Dimmer Switches to slowly fade certain lights with an offset of when it gets to be dusk, so as it gets dark outside, my office slowly gets brighter over the course of about 12.5 minutes so you don’t even really realize the lights are coming on. :slight_smile:

All done.

  • Revision 4 of the gist supports OH3. :warning: Requires Regex transformation to be installed
  • Revision 3 contains the OH2 version
1 Like

Thanks for such a prompt update! It seems I’m running into a small hiccup where it begins the dimming, but then fails within a 100ms. I seem to already have the Regex transformation installed, but here is what my logs show when I attempt to trigger the dimming:

2021-01-27 15:08:54.793 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'dimmer.rules'
2021-01-27 15:09:28.997 [INFO ] [ab.core.model.script.UniversalDimmer] - Dim Light_UL_OfficeCeilingBrightness PercentType from 0 => 50 over 5000 ms
2021-01-27 15:09:29.000 [INFO ] [ab.core.model.script.UniversalDimmer] - itemName=Light_UL_OfficeCeilingBrightness set to 0.13, iteration=1, elapsedMs=13
2021-01-27 15:09:29.002 [INFO ] [ab.core.model.script.UniversalDimmer] - itemName=Light_UL_OfficeCeilingBrightness set to 0.15, iteration=2, elapsedMs=15
2021-01-27 15:09:29.003 [INFO ] [ab.core.model.script.UniversalDimmer] - itemName=Light_UL_OfficeCeilingBrightness set to 0.16, iteration=3, elapsedMs=16
2021-01-27 15:09:29.008 [INFO ] [ab.core.model.script.UniversalDimmer] - itemName=Light_UL_OfficeCeilingBrightness set to 0.21, iteration=4, elapsedMs=21
2021-01-27 15:09:29.008 [WARN ] [el.script.internal.actions.TimerImpl] - Rescheduling failed as execution has already started!
2021-01-27 15:10:19.715 [WARN ] [ore.io.rest.auth.internal.AuthFilter] - Unauthorized API request: Invalid Basic authentication credentials
2021-01-27 15:11:36.296 [INFO ] [ab.core.model.script.UniversalDimmer] - Cancelling existing timer for Light_UL_OfficeCeilingBrightness
2021-01-27 15:11:36.296 [INFO ] [ab.core.model.script.UniversalDimmer] - Dim Light_UL_OfficeCeilingBrightness PercentType from 0 => 50 over 5000 ms
2021-01-27 15:11:36.298 [INFO ] [ab.core.model.script.UniversalDimmer] - itemName=Light_UL_OfficeCeilingBrightness set to 0.02, iteration=1, elapsedMs=2
2021-01-27 15:11:36.300 [INFO ] [ab.core.model.script.UniversalDimmer] - itemName=Light_UL_OfficeCeilingBrightness set to 0.04, iteration=2, elapsedMs=4
2021-01-27 15:11:36.304 [INFO ] [ab.core.model.script.UniversalDimmer] - itemName=Light_UL_OfficeCeilingBrightness set to 0.08, iteration=3, elapsedMs=8
2021-01-27 15:11:36.305 [INFO ] [ab.core.model.script.UniversalDimmer] - itemName=Light_UL_OfficeCeilingBrightness set to 0.10, iteration=4, elapsedMs=10
2021-01-27 15:11:36.306 [INFO ] [ab.core.model.script.UniversalDimmer] - itemName=Light_UL_OfficeCeilingBrightness set to 0.11, iteration=5, elapsedMs=11
2021-01-27 15:11:36.307 [INFO ] [ab.core.model.script.UniversalDimmer] - itemName=Light_UL_OfficeCeilingBrightness set to 0.12, iteration=6, elapsedMs=12
2021-01-27 15:11:36.314 [INFO ] [ab.core.model.script.UniversalDimmer] - itemName=Light_UL_OfficeCeilingBrightness set to 0.13, iteration=7, elapsedMs=13
2021-01-27 15:11:36.315 [WARN ] [el.script.internal.actions.TimerImpl] - Rescheduling failed as execution has already started!

That looks like an OH3.0 bug