EventRunner 5

[Sjakie 144]

No I don't use subscribe now.

 

tryArm I don't see the breached devices if I use your rule.

Please login or register to see this code.

tryArm see breached devices so I need to set a delay in alarm signals and then it's excellent

Edited November 15, 2023 by Sjakie
add tryArm

[jgab 2,166]

3 hours ago, Sjakie said:

No I don't use subscribe now.

 

tryArm I don't see the breached devices if I use your rule.

Please login or register to see this code.

tryArm see breached devices so I need to set a delay in alarm signals and then it's excellent

Yes, you need to set an "exit delay" and use tryArm. Then you get an event and can cancel if there are breached devices.

If you just use id:armed=true you don't get any event.

If you arm the partition/house with the fibaro UI/yubii ap you don't get any event either...

The best way is to arm the house with a QA that sends an event to ER5 and let ER5 arm using tryArm....

[Sjakie 144]

Jan, sorry your ER its to good so my ER arming QA is doing all.

Will set time delay in ER.

Reminder> remote? if that is sorted outI can switch all QA's on ER5 

Thanks

Edited November 15, 2023 by Sjakie
delay in ER

[jgab 2,166]

Yes, just pushed v0.051 with remote  

[Sjakie 144]

Jan, thanks for your service excellence!

Btw is ER5 now faster?

Edited November 15, 2023 by Sjakie

[jgab 2,166]

9 hours ago, Sjakie said:

Jan, thanks for your service excellence!

Btw is ER5 now faster?

Yes, I believe so - I have removed the fibaroExtra library that it depended on and made it more tailored for ER5.

It's simplified so it should be faster....

[jgab 2,166]

Time scheduling rules

 

Scheduling rules to run at specific times are easiest done with the @<time> directive - called a 'daily'.

Dailys specifies time(s) of the day the rule shroud be triggered

Please login or register to see this code.

 

We can specify a single time or a list of times. The times can be calculated, like the sunrise minus 10 minutes in the example.

The expressions can contain global variables, QuickApp variables and trigger variables

Please login or register to see this code.

 

Daily rules are rescheduled every midnight for the upcoming day. If the rule contains a global/QuickApp/trigger variable the rule will also be rescheduled if the variable changes value.

 

Daily can only schedule rules on a daily basis, what if we want a rule to only run on sunset on Thursdays?

The approach is to schedule the rule every day for sunset and add additional tests so the rule condition is only true on Thursdays.

Please login or register to see this code.

wday('thu') in this case is only true if it is a Thursday, so our action, the log, is only done at sunsets on Thursdays.

The same way if we want to check if it's someone's birthday.

rule("@07:00 & month('jun') & day('15') => log('Happy birthday!')")

It can seem wasteful that we check every day if it's the birthday, but rules are quickly checked and has negligible impact on performance.

The typical date time tests we can add is

wday(<weekdays string>)

Ex.

Please login or register to see this code.

 

day(<daynumber string>)

Ex.

Please login or register to see this code.

 

month(<months string>)

Ex.

Please login or register to see this code.

 

date(<cron pattern string>) -- more under functions chapter of doc...

 

 

This time/date tests allows us to make quite complex time rules.

Ex.

Please login or register to see this code.

...in the evening before the last Tuesday in the month remind me to put out the trashcans...

 

 

Beware that we can combine device triggers and dailys

Please login or register to see this code.

The rule will trigger on sunset but also when lamp changes state. In this case if it's not sunset the condition will be false.

However, if we change the rule's '&' to or '|' we get

Please login or register to see this code.

we have a rule condition that will be true if it's sunset and/or the lamp is on

 

One issue with daily rules are that when we restart the ER QA, we may want to run the action even if the time has passed - to "catch up" the rule.

rule("@sunset => lamps:on")

If we restart/reload the rules after sunset, the rule will not run and the lamps will not be turned on.

We can add  a catchup marker to the daily to tell it to run the rule at startup even if the time has passed

Please login or register to see this code.

This will run the rule action even if the time has passed when the rule is defined.

A problem with this is that we may not want to catch up if the time is too far after the specified daily time.

In that case we can add another test to not run the action after a certain time. Assume in the previous example we don't want to turn

on the lamps if the time is after 23:00...

Please login or register to see this code.

This will catch up, run the action, if we restart after sunset but before 23:00

 

Edited November 17, 2023 by jgab

[jgab 2,166]

Interval rules

 

Interval rules are rule that are triggered on regular intervals throughout the day.

Please login or register to see this code.

The rule will start when it's defined, so if it's defined 11:44:03 it will ping at 11:44:03, 11:49:03, 11:54:03 etc.

The good thing is that it's drift free so it will ping at these intervals forever.

If we want it to start on even intervals we can specify the negative time

Please login or register to see this code.

if it's defined 11:44:03 it will ping at 11:45:00, 11:50:00, 11:55:00 etc.

Please login or register to see this code.

This will ping on the hour.

 

Sometimes we only want to run the interval between specific times of the day. We could solve that with an extra test

Please login or register to see this code.

This works but is a little bit wasteful as it runs every 5min even outside the hours we are interested in.

We can solve that by having other rules that start and stop the rule
 

Please login or register to see this code.

Here we define the rule and disable it directly. We also assign the eventscript variable 'myRule' the rule defined.

Then we have 2 rules that enables resp . disables the rule at sunrise and sunset.

In this way the first rule will only run it's 5min rule between sunrise and sunset.

 

Important. An interval rule will disable all other triggers for the rule, so it will not be triggered on devices changes or global variables etc.

Edited November 27, 2023 by jgab

[Sjakie 144]

Jan,

Please login or register to see this code.

I have some more rules with | time is there a special reason in ER% its not present anymore?

[Pica2017 2]

Hi Sjakie i came across this as well, the fix was to write the rule 

 

rule("@{sunset-00:15, sunrise-00:15} => ...")

[Sjakie 144]

aha great Thanks

[jgab 2,166]

1 hour ago, Pica2017 said:

Hi Sjakie i came across this as well, the fix was to write the rule 

 

rule("@{sunset-00:15, sunrise-00:15} => ...")

Yes, that's the way to do it if you want several dailys in one rule.

[Sjakie 144]

Jan just a minor change in It is, if not error

Please login or register to see this code.

[jgab 2,166]

Can't have ' in 

Please login or register to see this code.

as the second ' terminates the string

[Sjakie 144]

sorry I am not clear please change in your example.

Please login or register to see this code.

 

[jgab 2,166]

Http and Nodered
 

HTTP

http requests are done with

Please login or register to see this code.

They are synchronous, meaning that the call returns the result. More specifically, the json.decoded result.data field of the response.

 

options can be 

opts.type, the header content-type.

opts.user, user name for credentials

opts.pwd, password for credentials

opts.timeout, request timeout

 

Ex.

Please login or register to see this code.

Here http.get returns a complex json table and we access the .datetime field.

 

In practice, the request could fail for various reasons and if we do a http.get(...).datetime we would get a rule error as the http.get returns nil.

To guard agains an error and nil value returned, we could do

Please login or register to see this code.

Here we assign the result to a variable 'res' and if true (not nil) we access res.datetime, else we return 'no time' to the log function.

 

Nodered

 

To call nodered we have 

Please login or register to see this code.

and we need to have setup the ER variable noderedURL first.

Ex.

Please login or register to see this code.

 

The nr.* functions return the response from the nodered flow we are calling.

 

There are 2 types of NR flows we can integrate with, named sync and async.

The 'sync' means that the flow called ends with an "http response" node.

In some cases that is not an optimal way to design the flow and we can then do an

'async' flow, which means that we need to call the outgoing event flow ourself when the result should be returned.

 

The communication between NR and ER is with events, json structs with a type key, like the events we deal with in ER.

The incoming msg.payload is the event, and we construct a new msg.payload event when we return the result to the HC3.

 

In nodered we have a flow with an incoming http endpoint http://<IP>:<PORT>/ER_HC3

 

Please login or register to see this attachment.

Please login or register to see this spoiler.

 

On the main flow "HC3 connect" there should not need to be any changes. Instead we have outgoing flow connections to the "Flow 1" tab...

Please login or register to see this attachment.

...where we can switch on our events from the HC3 and do whatever we want to do with nodered...

If you only have sync flows or only async flows, you can delete the unused flow to make it cleaner.

 

Sometimes we have flows that wants to post events to the HC3 without having been called first from the HC3.

The only thing we need is that we set up the payload as an event with a type field and we call the outgoing event flow.

The outgoing event needs to know the IP of the HC3 and the QA deviceId to send the event to the right QA.

Either, add that in the msg.EIP = <HC3 IP> and msg.EDeviceID=<QA deviceID>,

or do a nr.post(#echo1) from a rule in ER when starting up. The Nodered flow will cache the last IP and QA deviceID from incoming events and use that when posting to the HC3 if there is no msg.EIP and msg.EDeviceID fields given.

 

You can test this with the 'Manual trigger' flow.

Incoming events in this case (not associated with a nr.* post), will just be posted in ER as any event and can be picked up by a rule with the right #event trigger.

 

Edited November 17, 2023 by jgab

[jgab 2,166]

v0.052 released with support for

Please login or register to see this link.

 

[Sjakie 144]

Jan,

Please login or register to see this code.

What can I or you do to eliminate this?

Edited November 17, 2023 by Sjakie
add HUE

[jgab 2,166]

It seems like you do a

remote(1066,#licht_Badkamer_Uit) from another QA with id 1065

 

In 1066, when that remote event is received, it has taken 9 seconds(!) since it was sent from 1065.

 

9 seconds is a long time.

 

If 1065 sends it just when 1066 is starting up, 1066 is of course busy and will delay handling incoming calls.

 

When 1066 has loaded all rules it will log "Rules setup time: ---"

How long does it take?

[Sjakie 144]

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.