feature request: fader function and items ignoring input from specific sources

[onkelandy]

Hi there!

The fader function works like this right now: It fades a specific item from value x to z - but immediately stops fading when the value of the item gets changed "from outside".

That's useful to interrupt the fade by clicking on a KNX switch. But it's very problematic when a KNX actuator constantly sends the actual value after a change. Because this received value stops the fading process. Only solution right now is to delete the knx_receive attribute from the specific item (i.e. a light)

It would be perfect if the fader only interrupts the fading process when a value is received from a specific source. Let's say a switch has KNX:1.1.10 and the actuator hast KNX:1.1.1. Stopping the fade of lamp XYZ should only happen when the source of the valuechange is KNX:1.1.10

offline's Autoblind plugin features such a logic. If it's too complicated maybe just disabling the fade interrupt would also help in most cases I guess (or making this an option in the function)

Thanks alot, hope it was somehow understandable ;)

[smaiLee]

I agree on the problem.
But i would prefer the solution the other way round: You can define one or multiple sources which do not stop the fading rather than define the one which do stop.

In your scenario there's one source (the status of the actuator) which should not stop fading.
But you can have multiple switches, a visu or even sh.py itself that could send a new value and therefore should interrupt fading.
Furthermore i'm not sure if the physical address is the right thing to filter on or if the group address would be better (actually i not even know if the PA of the sending device is known at this position in sh.py's code).

A workaround could be to introduce a new item for fading:

[Light]
  [[DimValue]]
    type = num
    knx_dpt = 5.001
    knx_send = 1/2/1 # dim value GA
    knx_listen = 1/2/2 # status GA
    [[[Fader]]]
      type = num
      knx_dpt = 5.001
      knx_send = 1/2/1
      knx_listen = 1/2/1

Now you call the fade function on the new item: sh.Light.DimValue.Fader.fade(100, 1, 2.5)
I did not try this, but if i'm right fading should only be interrupted when there's something sent on GA 1/2/1 but not on the status GA 1/2/2 because the item Fader is not changed by the status GA.

You didn't tell something about your item and GA structure.
Does your switch send on the same GA as the status of the actuator? Or do you have multiple GA in knx_listen (the mentioned knx_receive attribute does not exist AFAIK)?
And where do you call the fade() function? In eval or in a logic?

[onkelandy]

Hi!
The workaround works well when I leave out the knx_listen. So there shouldn't be any knx_listen in the fading item (and yes I meant listen, not receive ;)) So thanks alot for the suggestion. I wonder why I didn't try that earlier.. :(

So in general my structure is the same as you mentioned and I'm calling the fader function from a logic.

Most likely for the fading function your solution to exclude specific GAs might indeed be good enough, though using the PA would make the function much more flexible. Small problem with the solution: When a light is fading and you set a specific dim value (ie in the Visu) the fader doesn't stop. No big deal for me but maybe for others and other situations..

Maybe including or excluding specific callers and sources might in general be an interesting feature for some other functions in smarthome..?

[onkelandy]

I've changed the title of the request as I think it might be a cool feature to implement in the item definition in general. somehow the way it is done in the autoblind plugin.
include = KNX:1.1.1 | Visu:*
exclude = KNX:*
would update the Item only when it's changed in the Visu and from the switch 1.1.1

[onkelandy]

Würde das gerne mal angehen in nächster Zeit.
Soll ich einfach mal die Funktion fade erweitern? fade(Zeit, Wert, include="all", exclude=None) ?
Angabe über regexes

[onkelandy]

Erledigt, siehe #687