Rules - Retrieve info if task is active or not

[chromo23]

Is there any way to get the status (enabled/disabled) of a task in rules ?

What I use at the moment is a bit cumbersome.
These are the current events that are generated when enabling or disabling a task:

Code: Select all

ACT : TaskDisable,4
EVENT: TaskExit#Device=4,0

ACT : TaskEnable,4
EVENT: TaskInit#Device=4,1

I can use these to save the state somewhere.
(btw: the last numbers of each event are a redundancy since "Exit" and "Init" are unique events that already tell the state.)

This could imho be improved to

Code: Select all

TaskState#Device=1or0

or

Code: Select all

Task#State=4,1or0

[Ath]

We have been brainstorming about this for a bit, some time ago, but didn't make any decisions yet. This is a trigger to get the priority up a bit

[TD-er]

(btw: the last numbers of each event are a redundancy since "Exit" and "Init" are unique events that already tell the state.)

Nope it isn't.
PLUGIN_TASK_INIT may fail.

But the enabled state should also be available in the JSON, isn't it?

Anyway, we do have some recently extended feature for tasks to get some values other than the taskvalues.
Original inspiration was the getLevel from the Level plugin.
[taskname#getlevel] would then return the set level, even though that isn't a taskvalue name.

We can do the same for [taskname#enabled] and [taskname#disabled]

So in short:
[taskname#taskvaluename] = current value of the task value.
[taskname#taskvaluename.foo] (added for task stats, like .avg, .max, etc.) is a derived value of a taskvalue
[taskname#bar] = some task specific value which isn't present as a taskvalue. (e.g. getlevel for the Level plugin, and the GPS plugin has all parameters made available via such calls)

Does this introduce some ambiguity or does it make sense?

[Ath]

We could use a somewhat fine-tuned approach, using a . prefix:

[taskname#.enabled] = 0/1 for disabled/enabled
[taskname#.interval] = current value for interval
[taskname#.valuecount] = the number of values available in the task

This has the advantage of these special value name being unique from the usual value names, where a period prefix would be, well, strange, and also recognizable as special values.

Rule:

Code: Select all

 LogEntry,'ST7796: [st7796#.enabled#O#C]/[st7796#.interval] SysInfo: [SysInfo#.enabled#O#C]/[SysInfo#.interval]/[SysInfo#.valuecount]'

Output:

Code: Select all

344936 : Info   : ACT  : LogEntry,'ST7796: On/0 SysInfo: Off/60/3'
344939 : Info   : ST7796: On/0 SysInfo: Off/60/3

[chromo23]

But the enabled state should also be available in the JSON, isn't it?

It is and i am using it in easyfetch.
But i also would need an option for rules based on the state.

Does this introduce some ambiguity or does it make sense?

It makes almost totally sense...

We can do the same for [taskname#enabled] and [taskname#disabled]

Here only one event is needed right? Like [taskname#enabled]=1 for enabled and =0 for disabled.
Why the [taskname#disabled]?

[chromo23]

This has the advantage of these special value name being unique from the usual value names,

i agree...

We could use a somewhat fine-tuned approach, using a . prefix:

since a point represents hidden files in unix/linux environments i would at least make sense for me.. so like the hidden values

[Ath]

In AdafruitGFX_Helper and the PRs for P137 and P138 (and others) I have also used the 'GetLevel' approach to make all usable values available, mostly because of the limit of 4 taskvalues, making it easier to use any available value from plugins.

[Ath]

since a point represents hidden files in unix/linux environments i would at least make sense for me.. so like the hidden values

I can relate to that

[TD-er]

But then the argument for "derived" values for taskvalues no longer makes sense.

It is after all a property or value of the task, thus [taskname#enabled] then makes more sense.
You could use an _ to indicate it is like a state of the task, but I think this will be confusing as we also don't do it for the "getValue" kind of requests.

I do agree that #disabled isn't needed.
After all, the checkbox is also labelled "Enabled".

Maybe we should check and see what other "get" types we have.
Perhaps we can then opt for [taskname#setting.enabled] ?
This way we have only a single keyword which may not be used as a taskvalue name (or else this functionality cannot be used)

[Ath]

But then the argument for "derived" values for taskvalues no longer makes sense.

It's just the derived value of the task, without the taskvalue (name)

[TD-er]

But it isn't a derived value, it is a setting.

A derived value is something which is... derived from other values.

For example if you have temperature and humidity, then you can derive a dew point temperature.
Average value is also a derived value as it is derived from the previous values.

But a setting like "enabled" or "interval" isn't a derived value.

When using a '.' in [taskname#settings.enabled], we can also describe it as a property or a member, like in programming languages.
But [taskname#.enabled] is rather confusing.

[Ath]

That makes sense to me, I'll adjust my code

[chromo23]

[taskname#settings.enabled],

That’s even better since it is more logical despite the fact, that it has a bit more text!

[chromo23]

[st7796#.enabled#O#C]

What does the "#O#C" do?

[TD-er]

And we can use it globally on all tasks, so no need to have it implemented in specific tasks.

[TD-er]

[st7796#.enabled#O#C]

What does the "#O#C" do?

Probably related to this: https://espeasy.readthedocs.io/en/lates ... sformation

[Ath]

I also added
[taskname#settings.controllerN] where N can be 1..3 (CONTROLLER_MAX actually) to get the enabled/disabled state per task per controller

Formatting code O = ON/OFF, Justification option C is First Capital, so the result will be On or Off

[chromo23]

Thanks

[chromo23]

Just testet it...great!
So this specific problem here is solved for me. Thanks a lot.

[Ath]

Would there be a need for having the [taskname#settings.controlleridxN] values available, for the controllers that support that (only for the Domoticz controllers, I think)?

[TD-er]

Yep, add them.
But perhaps the more clean way to have these is something like
[taskname#settings.controllerN.enabled]
[taskname#settings.controllerN.idx]

etc.

[Ath]

Yes, that's a great suggestion

[chromo23]

And now the only (of course not) thing missing is a command to get the pinstate/value of a pwm pin. (and a json entry for that too)