Hi,
I would like to gradually dim the lights at some specific time, f.eks. when it is bed time, and to dim the lights up in the morning gradually, lets say in period of 20mins from 0 to 40%. And that should be pretty easy with some math, give me the current light state, give me the desired state and how much time I should use, and the process begins.
However, the dimming process should stop if someone manually changes the lights (during the dimming process of course) either via switch, app, google etc.
My initial thoughts is to have two counters, one for issuing the command and another on the light itself receiving the command, and if light receives one command more then totally issued by the automation, then the automation dimming should stop.
I will do it in node-red, but it doesn’t metter if it is easier with openhab rules engine (I am more interested in algorithm/pattern then the code)
Anyone who implemented something similar, or has suggestions/comments/better ideas?
Thanks!
@vzorglub that is what I want to do, but due to risky low WAF (“why is this light getting darker/lighter”, “something is broken, I turned light on/off with google/switch/phone/… and it got back on”) I would like to not limit it to one abort-switch.
Do you have any suggestions how to make a dead/abort switch which is basically
when
Item Lights changed (by anything except the specific automation rule)
then
wakeUpTimer = null
@bartus how would you implement auto-cancel if lights are changed from any other place, except this rule? (love your videos btw )
@dakipro - if you look at my “Minute” rule, I use the Light_FF_Living_Sconces_Dim flag (in the Configuration group) to enable/disable the dimming. So, if I want to abort the sequence, I can just turn off that switch (it will be automatically re-enabled the next day, when the “Sunset” rule triggers and sets it back on.
You could write a third rule, that triggers on the actual diimmer switch changing state from ON to OFF, and turn the _Dim flag OFF in that rule (to handle the abort action automatically).
Thanks @bartus But how to turn _Dim flag OFF on multiple switches (and app, and google home)?
Basically my question is “how to detect source of change for item”, as I need to know who changed the value of a dimmer, and if it is NOT my rule that changed the value, then do something…
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
8
In case anyone finds this topic whilst doing research, prior to investing in hardware.
It’s worth knowing that this functionality is standard within all Velbus dimmers.
@dakipro - I suppose you could create a group of switches that are able to turn OFF the dimmer, add the switches you want to use to that group (e.g. gDimSwitches) and use my third rule idea above to turn off the dimmer when any of them are switched OFF, i.e.:
rule "Turn Dimmer Sequence Off on manual input"
when
MemberOf gDimSwitches changed from ON to OFF
then
Light_FF_Living_Sconces_Dim.sendCommand(OFF)
end
Group is what I wanted to do initially, but if you use openhab phone app, or google home (or ikea switch) you do not see that input as item in openhab, as they change dimmer directly. And then we have this scenario
dimming rule starts, sends the command:
5%
7%
9%
11%
user changes manually dimmer to 50% via google/app/directly on light
but dimming rule continues with
13%
15%…
Google/alexa/openhab app - they are not items that rules can be applied to.
I guess I could write an proxy item so that my rule only uses proxy item and all other inputs go directly or via another proxy item, but I somehow feel that my counter logic from the first post might work better/same. Will post update
It is possible to distinguish where UI always issues commands, and knob-twiddling at a physical device produces updates, while rules can issue commands or updates at your choice.
You are certain to have to use some kind of proxy device or variable or counter though, because at some stage you have to issue commands to get the binding to ‘do things’ to the device.
So for example, you might have a proxy Item that appears on the UIs. You can run a rule on received command, knowing it originates from UI. You can manipulate this Item from other rules by postUpdate.
And of course other rules that link proxy to the real device Item, that implement your chosen logic.
It’s possible to have another rule listening for updates from device, and asking “did OH just send a command?”. If not, i.e, an unexpected update, we can declare it was manual knob-twiddling and do the things you do when detecting UI originated events. (I count that as presence detection too)
Don’t be frightened of having several Items associated with a single device.
Each of my on/off light channels has an Item for UI, an Item to reflect actual state, a countdown Item for timeout duration, and a “manual mode” flag Item.
It seems complex for a single light, ending up with several rules and Items. But once it is working, the use of associated Items naming conventions and Member of group triggers allows easy duplication for dozens of channels.
This is what I like the most I think, listen for a change on the item and figure out if change arrived from my own rule. This is then all encapsulated per-rule, without polluting other interfaces and integrations with huge number of proxy items.
How would you implement this?
I can think of counter for both rule and item, or comparing received value on the item with last value sent from the rule, or something even better?
(never thought of it as presence detection, although now it seems obvious, thanks)
I’m lucky/unlucky because of the switching devices I happen to use. The command ON gets applied to one Item, and the physical state gets reported back by updating another.
So I can compare a change to ON with another Item previously set to ON. If no match, it was a manual (knob-twiddling) change I can take “manual mode” actions.
The ‘real’ device is the one I put on the UI. Because it has no outbound binding, and I have autoupdate=“false”, if you send it a command from the UI (or a rule) nothing happens!
But another rule can listen for commands, and translate them into a command for the outbound Item.
You might be able to replicate that with two Items, one outwards bound to device, one inwards bound.
When interacting in this kind of way, always bear in mind the effects of autoupdate - you sometimes don’t want it to happen, sometimes do.
It took me some time, but at the end it was very easy to do in node-red (it is just I had old version installed, and I used 5 days debugging known bug in node-red)
Basically I have a function that would do the math of how many steps are needed to desired light brightness, and send all those steps to one delay node, who would then send them in intervals to the light. I would also remember which value was lest sent in the local flow.
Then in the same flow I would listen to each change that the light actually received, and if it is not what was last sent to it(±2%), it means that something else interacted with the light. This would then send a reset message to the timer above.
Now I just need to make it a subnode and to make it more smarter, so that it can be easily reused as a single node wherever it is needed (and I see a lot of places where I would like light to change without people noticing, perhaps the color as well)
Really loving node red, it simplifies automation a lot.
Here is how the rule looks like (of course, with debug nodes it is much messier, but also much easier to debug)
)
