EventRunner 6/7

[Sjakie 156]

Jan,

I only copy ER5 into ER6.

ER5 did't gave any error so I am very happy ER6 is detecting much more errors I have had in ER5.

 

 

[Sjakie 156]

Jan this kind of rule I use in each room

Please login or register to see this code.

How to read pos 106? 

[DEBUG] [QUICKAPP545]: Parser: Expected END in CASE statement at pos 106

[jgab 2,647]

The first rule needs an 'end' as the last statement to close the 'case'

Please login or register to see this code.

 

[jgab 2,647]

There was a bug in case statement parsing, fixed in v0.0.22

🚀 EventRunner 6 - Release v0.0.22

Changes in v0.0.22

• ♻️ Refactor: improve error handling in rule definitions
• ♻️ Refactor: update loadLibrary function scope
• ♻️ Refactor: enhance block parsing logic
• 🐛 Fix: bug in case statement fixed

Generated automatically from git commits

📥 Download

• GitHub Releases: 

  Please login or register to see this link.

• Direct .fqa files: 

  Please login or register to see this link.

  , 

  Please login or register to see this link.

📚 Documentation

• Full Documentation: 

  Please login or register to see this link.

---

This release was automatically generated from commit bc285bd

[Sjakie 156]

 

Jan, I have almost 2 QA's who can go live.

there are some parser remarks yet to solve

 

[DEBUG] [QUICKAPP551]: Parser: Expected END in CASE statement at pos 192

I have more similar errors in case with end to close

Please login or register to see this code.

 

[jgab 2,647]

Its "case || <expr1> >> <statements1> || <expr2> >> <statements2> .... end"
So, you are missing the || .. >> after 'case'
 

Please login or register to see this code.

or
 

Please login or register to see this code.

 

[Sjakie 156]

sorry stupid error, thanks

[Neo Andersson 230]

On 9/2/2025 at 12:41 PM, jgab said:

The first rule will complain that there is no triggers in the rule. x is just a plain variable.
The second will work. 'y' is a variable, but also a trigger variable.
Technically, it is initialized when we do triggerVar.y = 88, and that does not cause any event to be emitted.
Later if we assign 'y' a value (different from 88) it will emit an event and the rule will trigger.

Sorry Jan, but this was my first thought when i read your ducomentation and examples, but i still dont get, how can then the elements of a HT table behave as triggers, if you declare them as following (using var.HT)

Please login or register to see this code.

 

in this case you are referencing HT table elements in rules, but the HT table was declared with var.HT syntax, and not triggerVar.

And you never, nowhere declare them as triggerVars..

So how can in this case work all HT table elements as triggers?

Sorry, maybe i am that stupid to not get it...

[jgab 2,647]

var.HT = { room = { roof = 99 }}
we can use
rule("HT.room.roof:isOn => ...")
but there is nothing in the HT that is a trigger. 
The trigger is 99:isOn, and HT.room.roof is just a table reference that return 99 in this case.

We can't make tables triggers.

We can use variables in ER, like
rule("@sunset => x = 42")

and it will create var.x if it's not already created or we can create var.x before we declare the rule.
Variables behave like normal variables, nothing special about them.

However, we can "mark" certain variables as "trigger variables" by declaring them with
er.triggerVariables.y = 99
Those variables are special as they will emit values events when they change values.
It also means that the ER compiler accepts a rule with a triggerVar in the header,
rule("y => log('y changed')")
because the compiler knows that y was declared as a trigger variable and the rule should run whenever it sees the event {type='trigger-variable', name='y'}

[Neo Andersson 230]

3 minutes ago, jgab said:

var.HT = { room = { roof = 99 }}
we can use
rule("HT.room.roof:isOn => ...")
but there is nothing in the HT that is a trigger. 
The trigger is 99:isOn, and HT.room.roof is just a table reference that return 99 in this case.

We can't make tables triggers.

We can use variables in ER, like
rule("@sunset => x = 42")

and it will create var.x if it's not already created or we can create var.x before we declare the rule.
Variables behave like normal variables, nothing special about them.

However, we can "mark" certain variables as "trigger variables" by declaring them with
er.triggerVariables.y = 99
Those variables are special as they will emit values events when they change values.
It also means that the ER compiler accepts a rule with a triggerVar in the header,
rule("y => log('y changed')")
because the compiler knows that y was declared as a trigger variable and the rule should run whenever it sees the event {type='trigger-variable', name='y'}

ok i got it. any device property change will act as a trigger by default, because they emit the event..that was the missconception on my side. A device is not a variable...ohh sorry

So thats why this table below will trigger ,even if its a table, while table of variables will not trigger nothing 

Please login or register to see this code.

and this will not work

Please login or register to see this code.

 

[jgab 2,647]

20 minutes ago, Neo Andersson said:

ok i got it. any device property change will act as a trigger by default, because they emit the event..that was the missconception on my side. A device is not a variable...ohh sorry

So thats why this table below will trigger ,even if its a table, while table of variables will not trigger nothing 

Please login or register to see this code.

and this will not work

Please login or register to see this code.

 

Well, almost. 
In this case it will not trigger when you change something inside the table. The table is still the same.
It's like Lua
local t = { 'lamp1', 'lamp2'}
print(t==t)
t[1]='Peter'
print(t==t) -- still the same...

 

In your example, it will only trigger if you set nameable to another table.

 

[Sjakie 156]

 

 

[10:47:15] [ERROR] [QUICKAPP549]: timer handler failed with error: ./include/rule.lua:109: table index is nil

Please login or register to see this code.

 

 [DEBUG] [QUICKAPP550]: Parser: unexpected token op at pos 104

Please login or register to see this code.

Jan I see this in debug but can that be minimized or must I do that in device parameters.

I use device:power < 1 or similar I am not interested what the amount off power is in debug

 

4/7 QA' in ER6 (with some actions never had in ER5 because of some errors)

Edited September 3, 2025 by Sjakie
add power

[jgab 2,647]

48 minutes ago, Sjakie said:

 

 

[10:47:15] [ERROR] [QUICKAPP549]: timer handler failed with error: ./include/rule.lua:109: table index is nil

Please login or register to see this code.

 

 [DEBUG] [QUICKAPP550]: Parser: unexpected token op at pos 104

Please login or register to see this code.

Jan I see this in debug but can that be minimized or must I do that in device parameters.

I use device:power < 1 or similar I am not interested what the amount off power is in debug

 

4/7 QA' in ER6 (with some actions never had in ER5 because of some errors)

You can't do
keuken.Bladverlichting_Rechts:on & keuken.Bladverlichting_Links:on;

It's an expression. Instead do
keuken.Bladverlichting_Rechts:on; keuken.Bladverlichting_Links:on;
because you want to do them 1 by 1.
Alt. 

{keuken.Bladverlichting_Rechts, keuken.Bladverlichting_Links}:on;

What is rule 101, that fails with the error? The time looks very wrong...

[jgab 2,647]

"Jan I see this in debug but can that be minimized or must I do that in device parameters...."

What is it that you see in debug that you want to hide?

[Sjakie 156]

This power value in debug is from a RGB light.

I also have some similar debug for wall socket while in rule is id:power < 1 => action

 

Please login or register to see this code.

 

[jgab 2,647]

Please login or register to see this code.

It will improve...

 

The 🎬 is a rule that is triggered, and what event that triggered it
The 👎 says the the rule test failed so the action wan't run (👍 says that the the succeeded and the action is run)

You can silence it globally by setting these flags to false
 

Please login or register to see this code.

Started is the 🎬, check is 👍/👎, result is the result of the action.
One can tailor it more by setting the values to functions instead that can use some intelligence if it should be logged or not - I will come back with some info on how to achieve this.

I will also make it possible to set these flags per rule instead of globally for all rules...

[Neo Andersson 230]

Jan, if i define a function , it doesnt have access to variables created in rules?

I can not use ER syntax inside the function? like size(), or rnd, or the ++ string concatenation??

Please login or register to see this code.

 

Edited September 3, 2025 by Neo Andersson

[jgab 2,647]

my town is just a normal lua function using lua syntax and functions, so concatenation is '..'

You could access ER variables by accessing var.* in your lua function, but normally you should pass it arguments.

[jgab 2,647]

🚀 EventRunner 6 - Release v0.0.23

Changes in v0.0.23

• ✨ Feature: improve rule logging options and formats for rule events
• ✨ Feature: add trigger-variable support in event engine
• ♻️ Refactor: update loadLibrary function scope in documentation

Generated automatically from git commits

📥 Download

• GitHub Releases: 

  Please login or register to see this link.

• Direct .fqa files: 

  Please login or register to see this link.

  , 

  Please login or register to see this link.

📚 Documentation

• Full Documentation: 

  Please login or register to see this link.

---

This release was automatically generated from commit 1c820a3

[jgab 2,647]

A rule has a life-cycle, or states, that it passes through.

1. Defined, when a rule is defined/created.

2. When a rule is started/triggered

3. If the trigger expression (condition) of the rule succeeded or failed, if succeeded the action will run

4. Optionally, the rule can wait, be suspended, and later woken up. Typically with the wait(time) command.

5. The action of the rule can produce a result

 

When a rule is defined and triggered there are logs created in the console for the above states. We can tailor them to our own look&feel.

Please login or register to see this code.

The prefix strings shown are the defaults, and boolean/functions are set to false per default.

If we turn on all flags we get
 

Please login or register to see this code.

Please login or register to see this code.

 

To get a reasonable log we start in main by setting some of the flags.

Please login or register to see this code.

Then we get the triggers listed for a defined rule - always good to see if it will react to the events we had in mind.

We get a log when the rule is started and it show the event that triggered the rule

We get a log with thumbs up/down depending how the rule condition went.

 

er.opts are defined globally and are applied to all defined rules. We can override opts by giving an opts argument to rule(str,opts)

Please login or register to see this code.

The options for the rule will be the global er.opts override with the opts we give for the rule.

More advanced, we can provide a log function for the rule logs.
An example. When we see that our rule works we can ignore the start message, and instead only log if the check/success of the rule is true.

Please login or register to see this code.

Please login or register to see this code.

 

Edited September 4, 2025 by jgab