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

I think i’m doing something very wrong or i’m missing something obvious.

I have copied the OH3 version to dimmer.rules in the rules folder and restarted OpenHab, on changing the item i can see in the logs it fires but I get errors. They all look to be caused by the import not working as it the logs start with

2021-02-17 11:13:18.666 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID ‘c29fb592c9’ failed: ___ import ___ org.openhab.core.model.script.ScriptServiceUtil

Ignore me, I was being stupid!
Copied it back over and its working fine now, the error I was seeing was caused by something else entirely I was playing around with

Guys sorry to revive this but I’m having with this rule.
If the Dimmer last state is 100% then this rule does nothing, I have to manually reset the dimmer to 0 using the sitemap’s slider for it to work.

So the question is: How do I reset the dimmer state to 0 once I turn off the lights?

Ok… figured out. I had to use the same rule to fade out instead of turning the lights off, which clearly makes sense.

Sorry

Hi Habau!

I’m having some issues with your script, for some reason it is not getting to the full values, that is it never reaches 100 or 0. It stays in 2.35225000 (instead of 0) and 97.13350000 (instead of 100).

I’m still on OH2 if it helps…
Your rule was copy pasted so I did not modify it.

Can you help me?

EDIT:
Sorry… me again…

This rule is killing my NUC CPU… it goes %100.
Is there any way to reduce the load while still mantaining the smooth fading? (increments of 1 o 2)

Hi Facundo - confirming you are using the latest version from github gist?
re: CPU - you can change line 38

var int timerTickEveryMs = 200;

And increase the ticks between timers.
Also check the logs which may give some clues as to what is happening.

Hi Brent! sorry for the inconvenience, your script works perfectly; the culprit was that I was mixing the 2.5 version with 3.0 and don’t ask me how I got it working like that. :sweat_smile:

Hi Brent,

Thank you! I upgraded to the new version, and it’s working great with two things in parallel - awesome stuff!

Cheers,

Andrew

1 Like

Script works really well so much appreciated.

Issue I have with my setup is my lights are really sensitive to the dim levels so it’s not a nice smooth change in brightness but rather a step up or down which makes me sad lol.

I was going for the nice slow fade on and slow fade off effect but seems the lights are too sensitive for what I am after.

Other than changing hardware there is not much else one can do right?

You understand the purpose of the step size parameter?
It does have to be an integer, so smallest step is 1.

As in the longer the time the smoother the level change is?

No, as in the difference between one brightness setting and the next.

The “height” of each step, if you like.

Just upgraded yesterday to OH3.1 from OH2.5, most things work again, had to fix some now.getMinuteOfDay() in my rules and the Frontal logging was posting at the old log files, but besides that, everything migrated flawless :slight_smile:

Another issue I just ran into, is the universal dimmer rule, I used it before to dim several light up or down by rule or on the habpanel, so you won’t have a lose or big increase in light all of a sudden.

Now I updated the new universal dimmer script in the rule and installed Regex.
I updated my rule to trigger a change in value of a lamp into this:

rule "Ganglamp fading"

when

Item dummyGanglampDimmer received command

then

var Number varLight_DimmerGanglamp = Light_DimmerGanglamp.state as Number

universaldimmer.sendCommand("Light_DimmerGanglamp,"+varLight_DimmerGanglamp.toString+","+receivedCommand.toString+",20000,1")

end

rule "Ganglamp fading slow"

when

Item dummyGanglampDimmerSlow received command

then

var Number varLight_DimmerGanglamp = Light_DimmerGanglamp.state as Number

universaldimmer.sendCommand("Light_DimmerGanglamp,"+varLight_DimmerGanglamp.toString+","+receivedCommand.toString+",5000,2")

end

So when the motion gets detected in another rule, the light goes up from (for example) 0 to 50, after 2 minutes when there is no motion anymore, the light should be dimmed down to 0, but that won’t happen, this is the output of the logging:

2021-07-11 12:59:49.070 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'dummyGanglampDimmerSlow' received command 0
2021-07-11 12:59:49.081 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'universaldimmer' received command Light_DimmerGanglamp,50,0,5000,2
2021-07-11 12:59:49.090 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'universaldimmer' changed from Light_DimmerGanglamp,50,50,20000,1 to Light_DimmerGanglamp,50,0,5000,2
==> /var/log/openhab/openhab.log <==
2021-07-11 12:59:49.104 [INFO ] [ab.core.model.script.UniversalDimmer] - Transition Light_DimmerGanglamp PercentType from 50 => 50 over 0 ms
==> /var/log/openhab/events.log <==
2021-07-11 12:59:49.317 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Light_DimmerGanglamp' received command 50
==> /var/log/openhab/openhab.log <==
2021-07-11 12:59:49.317 [INFO ] [ab.core.model.script.UniversalDimmer] - Finished transitioning Light_DimmerGanglamp from 50 => 50
==> /var/log/openhab/events.log <==
2021-07-11 12:59:49.326 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Light_DimmerGanglamp' predicted to become 50

For some reason, the item gets his original state again as command. This is the rule that commands the light to slowly dimm down.

var Timer occupancyTimer = null
val timeoutMinutes = 2

rule "Motion gang received ON"
when
    Item Philips_motion2_Occupancy_Gang received update ON
then
    if(occupancyTimer === null || occupancyTimer.hasTerminated()) {
        occupancyTimer = createTimer(now.plusMinutes(2), [|
            dummyGanglampDimmerSlow.sendCommand(0)
            occupancyTimer = null
        ])
    }
    else {
        occupancyTimer.reschedule(now.plusMinutes(timeoutMinutes ))
    }
end

really confused what I’m doing wrong, who has any idea?

Ok, just found the mistake(s) I made, 1 was that I thought that I passed in the new rule script for OH3, but, apparently it wasn’t.
So I fixed that, then I was reading that new script and saw the example command and noticed that you didn’t need to give the start value, and I still had the steps mentioned in the command. I removed the variable in the command and the steps, that left me like a command like this:

universaldimmer.sendCommand(“Light_DimmerGanglamp,”+receivedCommand.toString+“,20000”)

Now it’s working again like I used to :slight_smile:

1 Like

Hi,

I’m using the latest revision (8) of the Universal dimmer script, and it is working perfectly, but I have 1 issue.
After the command is send to dimm the light to a target value, it is dimming, but after completion, the value of the item changes back to a random number, but the light is still off. This is how the log looks like when it happens:

==> /var/log/openhab/openhab.log <==

2021-11-15 12:57:50.062 [INFO ] [ab.core.model.script.UniversalDimmer] - Finished transitioning Light_DimmerGanglamp from 50 => 0

==> /var/log/openhab/events.log <==

2021-11-15 12:57:50.066 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Light_DimmerGanglamp' predicted to become 0

2021-11-15 12:57:50.071 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Light_DimmerGanglamp' changed from 18 to 0

2021-11-15 12:57:50.122 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Switch_Ganglamp' changed from ON to OFF

2021-11-15 12:57:50.125 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Light_DimmerGanglamp' changed from 0 to 18

I don’t understand why he’s doing that, and the issue is, the next time it should slowly dimm up, it is already 18 right now so I’m missing a lot of steps in this case.
The strange thing is, if I let it run again, the latest value it get set to, can be totally different like you can see here:

==> /var/log/openhab/openhab.log <==

2021-11-15 13:07:45.231 [INFO ] [ab.core.model.script.UniversalDimmer] - Finished transitioning Light_DimmerGanglamp from 50 => 0

==> /var/log/openhab/events.log <==

2021-11-15 13:07:45.234 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Light_DimmerGanglamp' received command 0

2021-11-15 13:07:45.240 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Light_DimmerGanglamp' predicted to become 0

2021-11-15 13:07:45.252 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Light_DimmerGanglamp' changed from 17 to 0

2021-11-15 13:07:45.318 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Switch_Ganglamp' changed from ON to OFF

2021-11-15 13:07:45.326 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Light_DimmerGanglamp' changed from 0 to 17

This is the rule, I use a dummy dimmer to send certain value’s at different moment’s of the day, it looks like this:

rule "Ganglamp fading slow"

when

Item dummyGanglampDimmerSlow received command

then

universaldimmer.sendCommand("Light_DimmerGanglamp,"+receivedCommand.toString+",4000")

Any thought’s what it could be?

Let’s examine the process here.
Starts with command 0, that’s the last thing coming from the auto-dimmer script - anything else that happens has nothing to do with this script.
The binding should send that off to the device.

Autoupdate feature also gets the command, and makes its prediction of new Item state 0 within a few milliseconds.

A few more milliseconds, and the prediction 0 is actually applied to the Item - but remember this is just a guess.

A hundred milliseconds later, some apparently unrelated Item named Switch_Ganglamp changes. What’s that about, what does that Item represent? It’s clearly something to do with all this.

At about the same time, the original dimmer Item gets updated to 18 or whatever. That’s come from your device, about which we know nothing.

I’m going to guess that your device has separate brightness and on/off channels. If you command it with brightness=0, it responds with state=off … but brightness may be left as it was. You might be able to improve that behaviour by configuring at device or binding.

Because this is unrelated to the example script, I suggest starting a new thread for that problem with some device details.

Yea ofcourse, you’re right again :slight_smile:
Apparently the device handels the command 0 as OFF and didn’t change the value. It is a Shelly Dimmer 2 with stock firmware that communicates over MQTT.

I wanted to flash these devices with Tasmota but still didn’t do it. So now was a nice opportunity to do so, I first flashed one dimmer with Tasmota and tested it again with the fading rule. With Tasmota over MQTT it works like a charm again, thanks for pointing me in the right direction!

1 Like

Any plans on porting this rule to OH 3.3?

Change now.plusMillis(mytime) to now.plusNanos(mytime*1000000)

I don’t see anything else that would be different.

Thanks Rich, already did that long time ago, but it seems to have stopped working for some reason (I just updated to 3.3.0). Maybe some dependency is missing?

EDIT: yes… something was missing, regex transformation.

Thanks!