[Rules] Enhancement: add %eventvalue<nr>%

[clumsy-stefan]

In newer ESPEasy versions you can use %eventvalue% to directly access the values of an event with multiple values. Used mainly to access variables of the new "Single event with all values" feature.

[tonhuisman]

Used mainly to access variables of the new "Single event with all values" feature.

And for all events that receive multiple values, like current Rules#Timer events that now have %eventvalue2% set to the loop count of LoopTimerSet commands, and for passing in multiple values from (external or internal) commands like /control?cmd=event,eventname=value1,value2,value3,value4

The current limit in ESPEasy is 4 event values, and %eventvalue% is equivalent to %eventvalue1% (for backward compatibility)

[TD-er]

The current limit in ESPEasy is 4 event values, and %eventvalue% is equivalent to %eventvalue1% (for backward compatibility)

Not sure if that remains a hard limit as it used to be related to the number of task values.
But now we're also using it for other event values, so I guess we might later allow for more eventvalues if needed.

[enesbcs]

Support added at commit c679a2e

[clumsy-stefan]

Seems to work (at least for me). Same rules with "eventvalue<nr>% as in ESPEasy works now in RPIEasy.

Thanks a lot, great work.

[enesbcs]

Thanks for testing, should we close this issue now?

[clumsy-stefan]

IMHO yes... If something comes up you could always reopen it (or open a new one) with a more specific description of the problem...

[clumsy-stefan]

I have the following ruleset:

on sht30#temperature do // Heizung und Lueftung
  if %eventvalue% < 5
    event,ch9r=0
    event,ch5d=1
    TimerSet,2,1800
  endif
  if %eventvalue% > 8
    TimerSet,2,1
  endif
endon

It seems it takes the last %eventvalue1% that has been set and not the current %eventvalue%. Probably some kind of race condition? As in this example the 13.59 has been set in a recent rule from an event that generates 3 values and assigns them to local variables.

[enesbcs]

I have the following ruleset:

on sht30#temperature do // Heizung und Lueftung
  if %eventvalue% < 5
    event,ch9r=0
    event,ch5d=1
    TimerSet,2,1800
  endif
  if %eventvalue% > 8
    TimerSet,2,1
  endif
endon

Interesting. But why dont you use this instead?

on sht30#temperature do // Heizung und Lueftung
  if [sht30#temperature] < 5
    event,ch9r=0
    event,ch5d=1
    TimerSet,2,1800
  endif
  if [sht30#temperature] > 8
    TimerSet,2,1
  endif
endon

[clumsy-stefan]

You're right, I could, but that's always the case, so %eventvalue[<nr>]% would rarely be used anymore ;)

And, if I did, I wouldn't have found this bug! 😀

[enesbcs]

Eventvalue1-4 only implemented to the user called own named events, as nothing else supports multiple eventvalues in RPIEasy. I am sure that "sht30" has no eventvalue, it has 4 named taskvalue.

[enesbcs]

You're right, I could, but that's always the case, so %eventvalue[<nr>]% would rarely be used anymore ;)

Honestly I have never used it, and i have no idea why to use at all.

[enesbcs]

You're right, I could, but that's always the case, so %eventvalue[<nr>]% would rarely be used anymore ;)

And, if I did, I wouldn't have found this bug! grinning

From ESPEasy manual:

Event value (%eventvalue%)

Rules engine specific:

%eventvalue% - substitutes the event value (everything that comes after the ‘=’ sign, up to four values are possible).

Sample rules section:

on remoteTimerControl do
timerSet,1,%eventvalue%
endon

[clumsy-stefan]

Eventvalue1-4 only implemented to the user called own named events, as nothing else supports multiple eventvalues in RPIEasy. I am sure that "sht30" has no eventvalue, it has 4 named taskvalue.

Hmm... In ESPEasy it works like this. If a task has multiple values you can generate a <task>#ALL event where the values 1-4 are stored in %eventvalue<1-4>%. I guess it's done there to save processing cycles/ressources, so instead of generating up to 4 events and run through all rules for these, everything can be done in one run.
Example:

on weather#all do
  let,11,%eventvalue1%
  let,12,%eventvalue2%
  let,13,%eventvalue3%
endon

SHT30 has 2 values (temperature and humidity) which are named, sure...

And I guess %eventvalue% is still used as in ESPEasy there are events generated without having an associated task (eg. [pcf]GPIO inputs, timers, time, etc.).

[enesbcs]

Hmm... In ESPEasy it works like this. If a task has multiple values you can generate a

Than this is an undocumented feature.

SHT30 has 2 values (temperature and humidity) which are named, sure...

The event name is "sht30#temperature" so it is a very interesting logic, as sht30#temperature has exactly on value = temperature

[clumsy-stefan]

Than this is an undocumented feature.

yep, it's relatively new though..

The event name is "sht30#temperature" so it is a very interesting logic, as sht30#temperature ha exactly on value = temperature

agree, sht30#temperature has only one value, but sht30 in general (the task) has 2 values.

[enesbcs]

first taskvalue hacked into eventvalue1 in commit 2ec5b36

[tonhuisman]

You're right, I could, but that's always the case, so %eventvalue[<nr>]% would rarely be used anymore ;)

Honestly I have never used it, and i have no idea why to use at all.

In ESPEasy, events are queued, with the measured values of that moment in time in the %eventvalue% variables. When the event gets executed, the actual values may have already changed, making it close to impossible to f.e. detect extreme measurements. Current advise for ESPEasy is to use %eventvalue1..4% as much as possible for most accurate processing.

[clumsy-stefan]

first taskvalue hacked into eventvalue1 in commit 2ec5b36

Just updated with that latest commit and testing now...

However I'm not sure if that's the right way to go. What about events that don't have a task associated? There it has to be made sure, that %eventvalue% is the same as %eventvalue1% for backward compatibility (see commment here.

So IMHO instead of taking task#vlaue copying/linking %eventvalue% to %eventvalue1%. Like this it would also be back- and forward compatible if at some point in time more than 4 eventvlues are possible (eg. receiving events from another node with a number of values).

[tonhuisman]

The %eventvalue[1-4]% values should be parsed from the event at hand, not from anywhere else, as they can also originate from an externally triggered command, so not/never related to a task.
TD-er is already anticipating on extending the range, probably by using a c++ vector type, so there will be no real upper limit other than the practical limit in the string passed to the unit (or from the rules) and available memory.

[enesbcs]

However I'm not sure if that's the right way to go. What about events that don't have a task associated? There it has to be made sure, that %eventvalue% is the same as %eventvalue1%

Events without tasks has no real data in RPIEasy, and in the near future i do not plan to change this. Except with the timers, but they all have an own object in memory.

So IMHO instead of taking task#vlaue copying/linking %eventvalue% to %eventvalue1%. Like this it would also be back- and forward compatible if at some point in time more than 4 eventvlues are possible (eg. receiving events from another node with a number of values).

There are no such limit in python, it can be even a thousand length array. EventValues is a global array in RPIEasy which is filled with data at the same time when rule line is parsed. There are no direct link, just another lines of code added to the rule interpreter that slows down interpreting. :)

[tonhuisman]

Events without tasks has no real data in RPIEasy, and in the near future i do not plan to change this.

In ESPEasy there are the Event,<eventname>[=arg[,..]] and asyncEvent,<eventname>[=arg[,..]] commands, where Event should execute the event immediately and return where it left off, and asyncEvent adds the event to the event-queue to be processed after all events waiting to be processed. For these commands, the %eventvalue[1..]% variables are required to be used (though currently limited to numeric values, like all values in ESPEasy).
The only way of 'returning' a value from such event call would be to use Let,<x>,<y> and check that using [var#<x>], [int#<x>] or %v<x>%.

Does your statement imply that the Event (and the newer asyncEvent) commands aren't available in RPIEasy, or just don't support arguments to be passed into the event?

[enesbcs]

Does your statement imply that the Event (and the newer asyncEvent) commands aren't available in RPIEasy, or just don't support arguments to be passed into the event?

I know two types of events, either generated by the System or by the User.

I mean above: events generated from the system has no more than 1 value or zero

clumsy-stefan indicated that events generated by devices/system should have fill eventvalues with taskvalues also. And also referred "Events without tasks" that is something that i can not get.

About user generated events:
Event command is available (since 2019), and these user events accepts many parameters (since latest commit), and as there is no queue, event command is async by nature, so asyncevent command ha no sense in rpieasy at all.

[clumsy-stefan]

clumsy-stefan indicated that events generated by devices/system should have fill eventvalues with taskvalues also. And also referred "Events without tasks" that is something that i can not get.

Eg. a PCFGPIO does not have to have a task associated, but if it's changed (input) it generates an event in ESPEasy. Like this you don't need to waste tasks for pure PCFGPIO inputs, but still get the changes as an event.

Same as with timers, etc.

I mean above: events generated from the system has no more than 1 value or zero

I think this changed also in ESPEasy, eg. the looptimer set 2 variables when it generates an event, see here at Event value:
For example, the Rules#Timer event has 2 event values (since build 2020/08/12):

• %eventvalue1% has the timer number (1 … max timer ID)
• %eventvalue2% has the loop count for loop timers (since build 2020/08/12)

[enesbcs]

Eg. a PCFGPIO does not have to have a task associated, but if it's changed (input) it generates an event in ESPEasy. Like this you don't need to waste tasks for pure PCFGPIO inputs, but still get the changes as an event.

Yes this is a good example, as i do not plan to code something like this.
Tasks exists for good reason, there are 96 of them in RPIEasy, but with one byte i can modify it to 196...

[clumsy-stefan]

Yes this is a good example, as i do not plan to code something like this.
Tasks exists for good reason, there are 96 of them in RPIEasy, but with one byte i can modify it to 196...

That's the main reason why I'm switching for very complex nodes from ESPEasy to RPIEasy, as the standard 24 tasks of an ESPEasy node is not enough. Happens very rarely but I do have one or two applications, where I need more GPIO/Sensors and the associated tasks.

[TD-er]

However I'm not sure if that's the right way to go. What about events that don't have a task associated? There it has to be made sure, that %eventvalue% is the same as %eventvalue1%

Events without tasks has no real data in RPIEasy, and in the near future i do not plan to change this. Except with the timers, but they all have an own object in memory.

So IMHO instead of taking task#vlaue copying/linking %eventvalue% to %eventvalue1%. Like this it would also be back- and forward compatible if at some point in time more than 4 eventvlues are possible (eg. receiving events from another node with a number of values).

There are no such limit in python, it can be even a thousand length array. EventValues is a global array in RPIEasy which is filled with data at the same time when rule line is parsed. There are no direct link, just another lines of code added to the rule interpreter that slows down interpreting. :)

The idea of the event values is that these values will be appended to the event, not when parsing rules.

For example a task does generate an event with the new value.
As it is processed asynchronously, the [task#value] notation may yield a different value compared to %eventvalue1% when the event was generated.
For this reason, in ESPEasy the event + the event values are queued. (as Ton also explained)

A recent addition to ESPEasy is shown by @clumsy-stefan in a screenshot to let a task generate an event with all task values present as event values to be able to process less events and have them all present in a single event for example to generate an URL for posting all task values of a single task in one line.
Referring to the values of that task like [task#value1] ... [task#valueN] may result in different values as some plugins already update the UserVar array in the PLUGIN_TEN_PER_SECOND call for example or a task may produce lots of values in short sequence.

[enesbcs]

closed as implemented

[clumsy-stefan]

Just found another issue with %eventvalue%. It seems that the value gets lost if within a event another event or TaskValueSet is called.

When calling event,ch4r=0 the following ruleset (wrongly) sets %eventvalue% to 1 instead of 0:

on ch4r do
  TaskValueSet,6,4,1
  pcfgpio,1,1
  pcfgpio,2,1
  pcfgpio,3,1
  pcfgpio,4,%eventvalue%
endon

Log:

20:26:08 CMD: event,ch4r=0
20:26:08 Event: ch4r=0
20:26:08 CMD: TaskValueSet,6,4,1
20:26:08 CMD: pcfgpio,1,1
20:26:08 PCFGPIO1 set to 1
20:26:08 CMD: pcfgpio,2,1
20:26:08 PCFGPIO2 set to 1
20:26:08 CMD: pcfgpio,3,1
20:26:08 PCFGPIO3 set to 1
20:26:08 CMD: pcfgpio,4,1
20:26:08 PCFGPIO4 set to 1

The same seems to happen, if within an on - endon another event is called. When returning to the calling rule, %eventvalue% has changed.

[enesbcs]

Yes, as taskvalueset command changes a task value, which will trigger a new event, every event writes the same EventValue array, which is global variable.

I think this issue can be solved by deleting from Line 1155 to Line 1171 at commands.py

[clumsy-stefan]

Probably an event should have a kind of a unique "event-D" and the values assigned to that ID so it can be used again when returning from a recursion?

[TD-er]

That's why in ESPEasy the eventvalues and event are kept together.
It is a single string, so they cannot be altered, or get mixed up.
It also does not allow eventvalues to be used as reference variables which can be changed in the event handling, which could be useful.
But it allows events to be queued for asyncevent.

[clumsy-stefan]

Just found another case where %eventvalue% gets lost....

I have the following rule:

on ch17#switch do
  event,irswitch=%eventvalue%
  if [ch17#switch] = 1
     event,ch16r=0
  else
    event,ch16r=1
  endif
endon

Now in the log I find the following:

22:26:49 Event: ch17#switch=0
22:26:49 CMD: event,irswitch=1
22:26:49 CMD: event,ch16r=1
22:26:49 Event: ch16r=1

As you can see, the event ch17#switch=0 results in a %eventvalue% of 1 instead of 0. Somewhere still seems to be an issue on the soundness of %eventvalue%. Unfortunately this can result in all kind of strange behaviour on rules.

Obviously it works with [ch17#switch] substitution, but still I think also %ventvalue% should be correct.

[clumsy-stefan]

FYI: just had a bit more log of above issue:

11:28:10: Command arrived from ('10.0.10.103', 8266)
11:28:10: CMD: event,weather#all=1.22,80.49,1022.70
11:28:10: Event: weather#all=1.22=80.49=1022.70
11:28:10: CMD: let,11,1.22
11:28:10: CMD: let,12,80.49
11:28:10: CMD: let,13,1022.70
11:28:27: pump#speed=0
11:28:27: pump#ready=0
11:28:27: pump#rotate=0
11:28:27: pump#valve=0
11:28:27: Event: ch17#switch=0
11:28:27: CMD: event,irswitch=1.22
11:28:27: CMD: event,ch16r=1
11:28:27: Event: ch16r=1
11:28:27: CMD: pcfgpio,16,1
11:28:27: CMD: TaskRun,32

It seems that `%eventvalue% still has the value from the previous command (1.22 in this case, which was a sent value from another unit). Could also be some kind of race-condition or wrong sequence of assigning values.

[TD-er]

I think it may have to do with the event values not being stored along with the events when created.
Like I mentioned before, in ESPEasy the events and all event values are kept as a complete string.
Of course they can also be kept in a struct so you don't need to convert from numbers to strings and vice verse, but it is important they are kept together.

[clumsy-stefan]

Just found another rule where the comparison seems to fail:

Rule:

on bme280#humidity > 90 do
   event,ch5r=0 // Lueftung auf letzten Wert
endon

Log:

07:32:37 Event: bme280#humidity=69.25
07:32:37 CMD: event,ch5r=0
07:32:37 Event: ch5r=0

It can obviously be circumvented wtih an if statement, but I guess, that's not the idea...

EDIT: I just realised if I remove the spaces before and after the > it seems to work correctly!

[TD-er]

EDIT: I just realised if I remove the spaces before and after the > it seems to work correctly!

Hmm that may also fail on ESPEasy, I think