EventRunner 5

[jgab 2,167]

1 hour ago, Sjakie said:

Both QA's where running I just checked warnings and errors, what I did since ER5 is implemented.

I noticed sometimes a delay in swithing lights on.

Please login or register to see this code.

 

This is the setup time for 1065, correct?

It's the QA 1066 rule setup time that's interesting - it's the QA that receives the remote event but seems too busy for 9 seconds. Do you have that?

[jgab 2,167]

ER v0.054 pushed.

- more bugfixes

- support for debugging (speedtime + simulated devices)

It's starting to be further and further between (serious) bugs, so I'm planning to release a v1.0 December 1 if things holds up... 🤞

 

[Sjakie 144]

Jan setup time is correct.

QA1066 was taking care for all light execution by remote from other QA's I modified just now  light is in the QA of the room. Gives less traffic between QA's

In ER4 I did't notice delay in lights going on now I have sometimes delay what is not good for our WAF.

Perhaps your new HUE V2 will speed up my QA's

Edited November 18, 2023 by Sjakie
Added HUe remark

[jgab 2,167]

Debugging

 

When rules don't compile (at startup), hopefully ER5 will give some indication what is wrong with the rule.

Giving good error messages are more difficult than one would expect so sometimes it can be difficult to know - please feel free to post the problem in this forum and I can see if I can improve the error detection for the specific problem you encounter.

 

When rules are running, they can still misbehave and not do what is expected of them. 

Then there is a couple of approaches that can be tested:

 

Inspect rule triggers

If the rule doesn't trigger on events in a way that is expected - check what events the rule actually triggers on.

Add .info() at the end of the rule definition to get a console log of what triggers the rule

Ex.

Please login or register to see this code.

It gives

Please login or register to see this code.

Here we see that the rule will trigger on the global-variable event for a global with the name 'Day'.

It also triggers on device id 77 changing the property 'value' - which happens when the devices goes on and off.

There is also a daily that is set to 15:15 every day.

The Timer entry is just the timers that are active for the rule. In this case for the Daily on the line before - so we don't need to concern ourselves with that (or the fact that the sun goes down in Stockholm 15:15 this time of the year)

 

Look at the events - these are the only events that will trigger the rule - are we ok with that?

Note, that in some cases we may see more events than what we really are interested in.

In the example above, we want to trigger the rule at sunset and no more, but it also triggers on device 77 and the global variable 'Day'. In this specific example that doesn't matter because if it's not sunset the condition will not be true and the action not run. But beware that you may see in the console log that the rule was triggered by the device or the global.

In most cases this doesn't matter and it makes the rule clear to keep all the conditions tests on the left side of the '=>'.

However, we could move the device and global test to the right hand side of the '=>'. Then they would not be triggers of the rule.

Please login or register to see this code.

Please login or register to see this code.

 

Enable debug flags 

er.debug.ruleTrue = true

er.debug.ruleFalse = true

These flags are enabled by default and will log a true or false if the condition of a rule succeeds. In production it can be convenient to disable these flags so the console log becomes a little cleaner.

 

However, we can enable the flags for individual rules - the rule we have problem with.

Please login or register to see this code.

Here we have 2 rules that trigger on the event #fopp. The first rule succeeds and the second will fail (5 is not equal to 2). 

We add the options to log true and false condition (assuming it's disabled globally).

IN the output we see

 

[18.11.2023] [14:01:54] [TRACE ] [QUICKAPP5000]: Posting #fopp{} at Sat Nov 18 14:01:54 2023 (ER)

[18.11.2023] [14:01:54] [TRACE ] [ER5000 ]: [Rule:1:1]>> TRUE #fopp{} -> #fopp => log('fopp1')

[18.11.2023] [14:01:54] [DEBUG ] [QUICKAPP5000]: fopp1

[18.11.2023] [14:01:54] [TRACE ] [ER5000 ]: [Rule:2:1]>> FALSE #fopp{} -> #fopp & 5==2 => log('fopp2')

 

Here we see that rule 1 condition succeeded - the green TRUE,

and the rule 2 condition failed - the red FALSE.

We also see the event that triggered the rule - the #fopp{} before the arrow '->'

This will give us reasonable good idea why the rule failed or not.

 

It can still be so that the condition is TRUE, but the action after the '=>' is faulty. That needs o be checked differently...

 

er.debug.sourceTrigger = false 

er.debug.refreshEvents = false

The sourceTrigger and refreshEvents debug flags works globally and not per individual rules. They are set to false as default.

er.debug.sourceTrigger set to true will log all sourceTrigger posted to the system. It can be useful to see that devices and globals are generating sourceTriggers when they change state. 

 

er.debug.refreshEvents set to true will log all incoming events from api /refreshStates. It's kind of a lower level sourceTrigger and will show some more info. If you don't get an expected sourceTrigger it can be worthwhile checking if the refreshEvents are coming in...

 

er.settings.logFibaro = false

er.settings.logApi = false

er.settings.logFibaro set to true will log all fibaro.call's done by the ER engine.

A device:on in a rule will translate to a fibaro.call(device,"turnOn"). It can be worth making sure that the actions you have specified does the expected calls to the HC3.

er.settings.logApi set to true will log all api.* calls done by the ER engine. Can also be good to see what is communicated to the HC3.

 

 

Add your own debug checks

If the condition doesn't become true in a way that we expect, we can add log statements to the condition part.

Ex.

Please login or register to see this code.

and we add a log statement to check the temperature

Please login or register to see this code.

Note that we need to add the log statement before we test it so it will be logged even if the condition is false.

Note also that log() returns the string so it is always true, which allow us to add it with &'s in the condition test.

 

It can be a bit boring to wait until sunset before see the result, so we can force to triggering of the rule by adding .start() to the rule definition.

Please login or register to see this code.

 

Trigger rules with delayed expressions

We can sometimes trigger our rules "manually" by changing device states.

Ex. if we have a switch and a rule that triggers on the switch

Please login or register to see this code.

we can explicitly trigger that rule a second after we started it by turning on the switch

Please login or register to see this code.

 

A sensor we can't turn on, but we can work around that

Please login or register to see this code.

Here we create a trigger variable 'testTrigger' and make our rule trigger on either the trigger var or the sensor being breached.

By setting the trigger variable to true we trigger our rule and can watch the actions...

 

However, it can be better to create a simulated device to test these kind of rules...

 

Use simulated devices with rule

We can easily make simulated devices to test with

Please login or register to see this code.

They create devices of type com.fibaro.binarySwitch and com.fibaro.multilevelSwitch and their return the deviceId assigned to them.

The simulated devices only exists inside ER5 and are not visible to other QAs on the HC3.

The difference between them is that the binary device has a boolean true/false value and the multilevel a number 0-99

We can use them as sensors in our rules too.

 

Ex.

Please login or register to see this code.

Testing this way and making sure it works, we can then switch the sensor id to our real sensor.

 

A more complex example.

We have some rules to turn on light in bathroom if sensor in bathroom is breached. There are also logic to not turn off the light if the door is closed and the sensor becomes false (we assume that no one can escape a closed room, so there's still someone there)

Please login or register to see this code.

Redefine the sensors and lights 'Livingbath_x" with simulated binaryDevices.

er.createBinaryDevice() creates a simulated binary device and returns the assigned deviceId.

 

Then we have the bathroom rules as usual - now using our simulated devices.

 

Thence setup a remote/keyfob so key presses toggles the door and motion sensor and logs a message what new state they have.

We also setup debug options so the console output is not so noisy

Please login or register to see this code.

Then we can lean back, press the remote to toggle the state of the door and the sensor and see how the rules are triggered...

Without having to run to the bathroom and open and close any door or breach any sensor  

 

Run rule at simulated time

If we know that sunset happens at 15:15, we can set a simulated time for ER.

Please login or register to see this code.

It will set a "fake" time for ER to 15:14:50, and we just need to wait 10s before the rule hopefully triggers.

 

The simulated time is used by all ER functionality (incl. os.time() ) - However, it doesn't change the real time of the HC3.

 

Speed up time for scheduled rules

An experimental feature is to run ER5 faster than realtime.

If we set

Please login or register to see this code.

it will speed run the emulator for 24 hours. The speeding will start after rules are loaded and QuickApp:main() returns.

This can be useful if we want to check how scheduled rules behave over a certain time period. Combined with setting the simulated time it can be a powerful tool to get this hard to find bugs (will the lights turn on on New Years Eve next year?)

When we speed run fibaro.call are disabled and api.put and api.post

The reason is that otherwise, if you are turning on/off lamps they will blink a lot while you speed run  

In any case, use this with caution, and be prepared that a lot of rules will trigger and run during a short period of seconds....

 

Use Terminal5 to interact with the rules

By getting the

Please login or register to see this link.

up and running we can type EventScript expressions and inspect values and interact with our rules by triggering them like in earlier examples

Ex. print a list of all devices currently on

Please login or register to see this code.

 

Run EventRunner5 offline and debug it

ER5 QA is fully developed offline using the

Please login or register to see this link.

environment and is the easiest way to test and develop rules quickly...

Edited November 26, 2023 by jgab

[Sjakie 144]

This is difficult

Please login or register to see this code.

 

[jgab 2,167]

Please login or register to see this code.

ends with an ';' before the next ||

It become faulty when you commented out the line with the log...

[Sjakie 144]

if not commeted out same error 

[18.11.2023] [12:24:32] [ERROR] [QUICKAPP1063]: [Rule:56] Parser: bad expression log('#C:yellow#Verlichting woonkamer ingesteld gedurende de dag 1 - Opstaan')

[jgab 2,167]

39 minutes ago, Sjakie said:

if not commeted out same error 

[18.11.2023] [12:24:32] [ERROR] [QUICKAPP1063]: [Rule:56] Parser: bad expression log('#C:yellow#Verlichting woonkamer ingesteld gedurende de dag 1 - Opstaan')

So, show me the whole rule...

[Sjakie 144]

Sorry found it one  ;'; to manny it's easy to overlook.

Whole appartment is now on ER5

All known error(s) are solved as long as your improvement does't throw newones up.

No warnings either

Must keep track of the warning about taking long time

Thanks

Edited November 18, 2023 by Sjakie
remark

[jgab 2,167]

11 minutes ago, Sjakie said:

Sorry found it one  ;'; to manny it's easy to overlook.

Whole appartment is now on ER5

All known error(s) are solved as long as your improvement does't throw newones up.

No warnings either

Must keep track of the warning about taking long time

Thanks

I'm thinking of releasing a v1.0 first of December. I have no new significant features to implement. Mostly  minor bug fixes (knock on wood) and cosmetics & documentation.

I think I now how to warn for the extra ';'...

[Sjakie 144]

Jan can you add the line number buy the error?

This error was 7 lines before

[ChristianSogaard 62]

Hi Jan

I having some issues/crash when pushing, the list rules button

 

Please login or register to see this spoiler.

 

[jgab 2,167]

2 minutes ago, ChristianSogaard said:

Hi Jan

I having some issues/crash when pushing, the list rules button

 

Please login or register to see this spoiler.

Yep, bug from my side. In file engine at ~line 446

change

Please login or register to see this code.

to

Please login or register to see this code.

for now.

I will fix it in next release but earliest tomorrow morning,

 

[Sjakie 144]

Jan for me it's difficult to find the rule where the error is

How you count the rule numbers

Please login or register to see this code.

Please login or register to see this code.

 

[ChristianSogaard 62]

Hi Jan

 

Im adding this rule into EV5, but getting this error from the Parser 

Please login or register to see this code.

 

 

Please login or register to see this spoiler.

 

Edited November 19, 2023 by ChristianSogaard
Typo

[jgab 2,167]

5 minutes ago, ChristianSogaard said:

Hi Jan

 

Im adding this rule into EV5, but getting this error from the Parser 

Please login or register to see this code.

 

 

Please login or register to see this spoiler.

Yes, that is a change from ER4

The ||>> rules looks like

Please login or register to see this code.

 

Note, that the last statement don't have a ';' before the next '||' starts

 

 

[jgab 2,167]

1 hour ago, Sjakie said:

Jan for me it's difficult to find the rule where the error is

How you count the rule numbers

Please login or register to see this code.

Please login or register to see this code.

 

Ok, I fixed it. The first was a bug but I also added so that errors print the start of the rule so it's easier to recognize.

(To get the rule numbers you can do list rules in the UI or er.listRules() )

The second was a bug when you turn on log for triggered rules and not a bug in your rules. I fixed that too.

 

Thanks for spotting these stuff - helps to improve ER5 tremendously... 👍

Pushed v 0.155

[Sjakie 144]

Hehe I started to doubt on myself. Strange I cut and copied all of that QA in other QA's and no error at all.

Thanks 

Remark I thougt to resolve all errors but I see newones comming up and I did where I am good in >>nothing

[ChristianSogaard 62]

My reading of Netatmo is till playing tricks to me

 

[19.11.2023] [15:08:41] [TRACE] [ER1961]: [Rule:8:1]>> TRUE #device{id=1992,va.. -> c02sensor:value => local value = c..
[19.11.2023] [15:08:41] [ERROR] [ER1961]: [Rule:8:1]>> [Rule:8:c02sensor:value =>
local value = c02sensor:value;
log('CO event:%s',t..] Runtime: table is nil for array reference
log('CO event:%s',tjson(er.event));

 

--------

Please login or register to see this code.

 

 

 

Edited November 19, 2023 by ChristianSogaard
Typo

[jgab 2,167]

You had written er.event instead of env.event in log('CO event:%s',env.event);

 

However, I probably fooled you with errors because tjson does not exist in ER5 yet.

%s in log automatically convert tables to json.

Please login or register to see this code.

 

You can define tjson yourself if you want

Please login or register to see this code.

or 

Please login or register to see this code.

if you have

Please login or register to see this code.

...defined.