Add Channel as a trigger for rules

[pfisterer]

Have you looked for this feature in other issues and in the wiki?
Yes.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.

The underlying problem has been described in #7160 but after discussing in Tasmota's support chat, @blakadder and User Adrian discussed this issue and concluded that this is not an issue but should be a feature request. For future reference, see the chat transcript below.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Add Channel as a trigger for rules. The following setup should trigger a rule:

• MagicHome LED controller with two separate PWM channels (using SetOption68).
• Manually changing the value of a channel on the Web UI yields this log output: 19:00:40 SRC: WebGui from 192.168.178.67and 19:00:40 CMD: Group 0, Index 1, Command "CHANNEL", Data "55"
• The rule Rule1 ON Channel#data do publish cmnd/test %value% endon should trigger on a change.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Periodically sending the value to the KNX bus - however, this adds a lot of overhead in terms of traffic and increases the latency until a change is visible.

Additional context
Add any other context or screenshots about the feature request here.

BlakadderToday @Adrian {"Rule1":"ON","Once":"OFF","StopOnError":"OFF","Free":457,"Rules":"ON Channel1#Data do publish test/channel %value% endon"}. triggers only on empty command, nothing on sliders or channelx with value

Adrian: @Blakadder yes, that is because rules can handle the JSONs outputs also as triggers
but there isn't any specific one for channels
that is why don't work

Blakadder: but why does it not handle channel1 20 but it triggers on channel1
different json response?

Adrian: Yes, exactly. @Blakadder if you execute a command, Tasmota will answer with a JSON with result. If you issue that change by webUI, it won't do that because it was not added as a trigger. when you issue the command channel1 20, what is the output?

19:39:01 CMD: channel1 20
19:39:01 SRC: WebConsole from 10.1.1.60
19:39:01 CMD: Group 0, Index 1, Command "CHANNEL", Data "20"
19:39:01 MQT: tele/h801/STATE = {"Time":"2019-12-09T19:39:01","Uptime":"0T00:47:51","UptimeSec":2871,"Heap":28,"SleepMode":"Dynamic","Sleep":0,"LoadAvg":999,"MqttCount":1,"POWER":"ON","Dimmer":97,"Color":"33F7F70000","HSBColor":"180,79,97","Channel":[20,97,97,0,0],"CT":153,"Scheme":0,"Fade":"OFF","Speed":1,"LedTable":"ON","Wifi":{"AP":2,"SSId":"HTPC","BSSId":"50:64:2B:5B:41:59","Channel":6,"RSSI":56,"Signal":-72,"LinkCount":1,"Downtime":"0T00:00:07"}}
19:39:01 MQT: stat/h801/RESULT = {"POWER":"ON","Dimmer":97,"Color":"33F7F70000","HSBColor":"180,79,97","Channel":[20,97,97,0,0],"CT":153}

the fact that i got a rule trigger on empty command was misleading me

Adrian: ok, channel1 20 command should respond as channel1. will make a PR for that

Blakadder: wait i forgot to turn on so68
19:40:57 CMD: channel1 20
19:40:57 SRC: WebConsole from 10.1.1.60
19:40:57 CMD: Group 0, Index 1, Command "CHANNEL", Data "20"
19:40:57 MQT: tele/h801/STATE = {"Time":"2019-12-09T19:40:57","Uptime":"0T00:00:19","UptimeSec":19,"Heap":29,"SleepMode":"Dynamic","Sleep":0,"LoadAvg":201,"MqttCount":1,"POWER1":"ON","Channel1":20,"POWER2":"OFF","Channel2":100,"POWER3":"OFF","Channel3":100,"POWER4":"OFF","Channel4":0,"POWER5":"OFF","Channel5":0,"Color":"33FFFF0000","Wifi":{"AP":2,"SSId":"HTPC","BSSId":"50:64:2B:5B:41:59","Channel":6,"RSSI":54,"Signal":-73,"LinkCount":1,"Downtime":"0T00:00:07"}}
19:40:57 MQT: stat/h801/RESULT = {"POWER1":"ON","Channel1":20,"POWER2":"OFF","Channel2":100,"POWER3":"OFF","Channel3":100,"POWER4":"OFF","Channel4":0,"POWER5":"OFF","Channel5":0,"Color":"33FFFF0000"}

this should trigger a rule right?

Adrian: the output MQT: stat/h801/RESULT = {"POWER1":"ON","Channel1":20,.... don't trigger any rule

Adrian: for enable a trigger, it should be: MQT: stat/h801/RESULT = {"POWER1":"ON","Channel1":{"DATA":20},.... on Channel#data do... as it is now, it won't trigger anything
So, the question is, If we change that in stat/h801/RESULT =, how many setups will broke ?
because is the same as few days ago with "POWER1":"ON" to "POWER1":{"STATE":"ON"} that we revert

Blakadder: {"Channel1":30} but this triggers it since its considered a single level reponse
noone is asking to change it... specially not you :smile: it was just misleading that the solo command worked as a trigger

Adrian: yes, that was weird. unintended

Blakadder: and the CMD response shows CMD: Group 0, Index 1, Command "CHANNEL", Data "" so i assumed it should work in each case

AdrianToday at 19:49 Ok, so there is no trigger for channel. So, what we should do? we can add the same mqtt response than an empty channel command ?

Blakadder: @Adrian setoption that enables firing single level mqtt message?

Adrian: mmmm, not optimal. we would need to add a lot of code for all commands

Blakadder: @Adrian well this is the first time this was requested... so maybe it just a case of "bad luck bro, it cant do it"

farberg: Maybe there is a better way to do it - but I'm currently trying to debug Tasmota KNX/IP with my KNX smart home setup. So I need to publish the state on change to the KNX bus.

Adrian: Well, so far there is no trigger for that. Anyway, may be in the future would be added a way to trigger those single JSONs like POWER and CHANNEL

Adrian: @farberg Please, edit your issue to be a feature request adding Channel as a trigger for rules.

(Please, remember to close the issue when the problem has been addressed)

[ascillato]

@arendst

What about adding a new way for using these single field values of the JSONs as rule triggers?

Now, the output JSON for state and tele have:

"POWER1":"ON","Channel1":20,"POWER2":"OFF",...

and as we know from previous PRs, changing those to "POWER1":{"STATE":"ON"} for using the trigger POWER1#STATE, will break other users's setups.

So, what about adding a new way of using these single field values as triggers as:

POWER1#VALUE
CHANNEL1#VALUE

what do you think?

[arendst]

Good idea but...

This will need a rewrite of the rule JSON validator as currently it looks for POWER1#STATE where POWER1 is the name of a field which has subfields like STATE.

It must be possible but as said it will need a rethinking of the rule JSON handler.

[pfisterer]

@ascillato any idea how to update the knx state then w/o this change? Maybe I'll resort to a timer then.

[ascillato]

As channel is not a trigger, you can't use it.

[micw]

Hello. I'd like to implement a use case that could potentially be solved with this feature:

In my bathroom I have a glass door with LED lights behind. Lights are dimmes with MQTT (e.g. day=off, morning/evening=100%, night=15%). When the door is opened (closes a switch), LEDs should dim to 100%. When it's closed, LEDs are dimmed to the original value.

To implement this, I need access to the current channel value within a rule. One option would be to make it accessible via special variables. I could also implement it, using a channel#state trigger to store the value as var.

What do you think?

Edit: There are 2 doors and one additional ambient stripe, so I cannot do it with dimmer.

[ascillato]

support added with bf215b1 and 92c05fa

[arendst]

Final support added by 89b130b

[pfisterer]

Great, thanks a million @arendst and @ascillato.

[NorthernMan54]

@pfisterer Am trying to use this feature, would it be possible for you to add a sample to this issue that shows how to use this feature?

[pfisterer]

@NorthernMan54 No, sorry. I haven’t used this feature until now. I’m still working on other issues. Maybe @ascillato has an example.

[ascillato]

Example:

Rule to publish a mqtt message with the value of the channel number 1:

Rule1 1
Rule1 on channel[1] do publish stat/chan1 %value% endon

The docs have been updated. If you need more information about rule's usage, please check https://tasmota.github.io/docs/Rules/

Thanks.

[NorthernMan54]

@ascillato Some days you have Homer Simpson moments, when you have tried ever possible option but the basic one. That works very well.

Thank you

[wm1962]

@ascillato there is no update in the wiki
I suppose your example does not work

Rule1 1
Rule1 on channel[1] do publish stat/chan1 %value% endon

Can you give a correct example.

Example:

Rule to publish a mqtt message with the value of the channel number 1:

Rule1 1
Rule1 on channel[1] do publish stat/chan1 %value% endon

The docs have been updated. If you need more information about rule's usage, please check https://tasmota.github.io/docs/Rules/

Thanks.

[barbudor]

This is old and closed
Please open a new discussion giving more details on what you are trying to achieve, especially on which message you are trying to trigger with channel[1]

[kapitan-iglu]

@ascillato there is no update in the wiki I suppose your example does not work

Rule1 1 Rule1 on channel[1] do publish stat/chan1 %value% endon

Can you give a correct example.

I did not find this feature in documentation too. The example usage is not working because of wrong syntax. So for anyone searching for trigger based on Channel<x> the correct rule is like follows:

Rule1
    ON Channel1 DO publish stat/chan1 %value% ENDON
    ON Channel1>50 DO var1 %value% ENDON
Rule1 1

I also realized that Channel<x> trigger is not working if Channel<x> <value> command is executed in same rule without Backlog statement.

Hope this helps.

[ascillato]

@kapitan-iglu

Thanks very much for your correction. Very appreciated !!!!!
My comment is 4 years old. Some features have changed since then.

Please, help us. Can you add this example to https://tasmota.github.io/docs/Rules ? In the top right there is an icon with a pen and page to propose changes.

Thank you very much in advance!!!!!

[sfromis]

As the rule docs are now, the case of picking JSON fields like Channel1 is already covered when https://tasmota.github.io/docs/Rules/#rule-trigger includes ValueName. Due to lots of different JSON-based triggers being possible, that very long list is not itemized; what is detailed is only the triggers which are not based on visible JSON payloads.