Tutorial: Single scene instance / Event model

[fastvd 7]

hello everyone, hello Jgab... I haven't come to the forum for a long time, I haven't played with a smart house, because it was summer.. it's time to overload my mind.. but unfortunately or fortunately it's already autumn and I need to work a little bit... I haven't followed the forum for the last 4-5 months, so maybe my idea has already been implemented somewhere...

still: there is a problem that HC3 lite from time to time disappears/falls off from wifi... I myself, who doesn't know, am a communicator, an Internet provider to be exact... and we have a simple thing called WATCHDOG for such cases.. .that's why I came up with an idea, can somehow implement this simple mechanism at the level of ER4...

if I don't forget, sometime in the spring, we raised the topic of controller overload through ARP, and even tried to reboot the remote...
well, the trigger is also not difficult to come up with... you can use the system that I use to monitor whether the phone is at home... ARP requests in another QA on some router mac, say... or I think that JGAB is an even more elegant option will offer...

 

[Neo Andersson 230]

@jgab

Hello Jan,

Please check on this..

I am running out of answers. This doesn't trigger

 

Please login or register to see this code.

 

The rule should trigger whenever the global variable dayPart chanhes to 'night' and the automation_office switch is turned on. For some reason it never triggers.

BTW the dayPart global variable is also updated in ER4. Can it be somehow related to the problem?

(I have douuble checked the global variable and it is nicely updated , also the switch is ON)

[jgab 2,641]

11 hours ago, Neo Andersson said:

@jgab

Hello Jan,

Please check on this..

I am running out of answers. This doesn't trigger

 

Please login or register to see this code.

 

The rule should trigger whenever the global variable dayPart chanhes to 'night' and the automation_office switch is turned on. For some reason it never triggers.

Do you see the sourceTrigger events from global-variable 'dayPart' and/or the sourceTrigger from the automation_office device turning on?

Only when (at least) one of those events are emitted the rule will trigger.

Note that sourceTrigger events are only emitted when a global var or devices changes value - not if it "changes" to the same value...

 

If you see the sourceTrigger events, do you see the rule being triggered but returning false?

Ex.

Please login or register to see this code.

 

 

11 hours ago, Neo Andersson said:

BTW the dayPart global variable is also updated in ER4. Can it be somehow related to the problem?

no, its independent. 

11 hours ago, Neo Andersson said:

(I have douuble checked the global variable and it is nicely updated , also the switch is ON)

So, do you see the sourceTrigger when the variable is updated?

 

 

Could it be that you want the rule to check the conditions when the QA starts up, and 'dayPart' is already 'night' and the device is already on? Then you need add .start() to the rule.

Edited October 1, 2023 by jgab

[Neo Andersson 230]

1 hour ago, jgab said:

Do you see the sourceTrigger events from global-variable 'dayPart' and/or the sourceTrigger from the automation_office device turning on?

Only when (at least) one of those events are emitted the rule will trigger.

Note that sourceTrigger events are only emitted when a global var or devices changes value - not if it "changes" to the same value...

 

If you see the sourceTrigger events, do you see the rule being triggered but returning false?

Ex.

Please login or register to see this code.

 

 

no, its independent. 

So, do you see the sourceTrigger when the variable is updated?

 

 

Could it be that you want the rule to check the conditions when the QA starts up, and 'dayPart' is already 'night' and the device is already on? Then you need add .start() to the rule.

The source trigger events are not there. (i believe, there are hundreds at this point)

So i think your last suggestion is the problem. I need to use the start function. I thought, start function evaluates and runs the rule when the QA loads, and later the rule is not active anymore, but apparently this is not the case. So we will use the start function with every rule we have, if it means, that

all the rules will be evaluates at the beginning without having the rule triggered, and later the rule will do his job like before.

In this case, i think using the start function is more or less inevitable, if we want to have correct device behavior even if some rule evokers has already been triggered before.

Thank you

[jgab 2,641]

39 minutes ago, Neo Andersson said:

The source trigger events are not there. (i believe, there are hundreds at this point)

So i think your last suggestion is the problem. I need to use the start function. I thought, start function evaluates and runs the rule when the QA loads, and later the rule is not active anymore, but apparently this is not the case. So we will use the start function with every rule we have, if it means, that

all the rules will be evaluates at the beginning without having the rule triggered, and later the rule will do his job like before.

In this case, i think using the start function is more or less inevitable, if we want to have correct device behavior even if some rule evokers has already been triggered before.

Thank you

Yes, because rules only get triggered when something referenced in the head of the rule is changing (time rules like @ and @@ are handled similarily  and there are special "sourceTriggers" emitted when their times comes up...)

 

For some rules we want to run .start() when the QA restarts, because we want to trigger rules where the condition is already true.

However, we don't want to do this for all rules. Therefore the .start() is optional.

 

Be also aware that rules using trueFor will only watch from when the rule is triggered (or .started). If a device has been on for hours and we have a rule trueFor(01:00,device:isOn) it will start to count that hour from when the QA was restarted, not when the device was last turned on.

 

[Neo Andersson 230]

@jgab

Hello Jan.

What is the pattern for trueFor, when i am checking on multiple devices same property? Does it use OR or ANY logical connection between device states?

How should we format it?

 

Example with 1 device

Please login or register to see this code.

 

Example with 2 devices - Can we use this for multiple devices.

Please login or register to see this code.

 

 

If so is this evaluated as

Please login or register to see this code.

or it stands for

Please login or register to see this code.

 

 

 

2nd question

 

Is there any performance difference between these two calls? (or any difference)

Please login or register to see this code.

 

and

 

Please login or register to see this code.

 

Thanks 

 

Edited October 2, 2023 by Neo Andersson

[jgab 2,641]

12 hours ago, Neo Andersson said:

@jgab

Hello Jan.

What is the pattern for trueFor, when i am checking on multiple devices same property? Does it use OR or ANY logical connection between device states?

How should we format it?

 

Example with 1 device

Please login or register to see this code.

 

Example with 2 devices - Can we use this for multiple devices.

Please login or register to see this code.

 

 

If so is this evaluated as

Please login or register to see this code.

or it stands for

Please login or register to see this code.

 

 

When you test a property on a list of devices {....}:prop, the semantic depends on the :prop

 

{...}:isOn            -- OR

{...}:isOff           -- AND

{...}:isAllOn       -- AND

{...}:isAnyOff    -- OR

{...}:safe           -- same as :isOff

{...}:breached  -- same as :isOn

{...}:isOpen      -- same as :isOn

{...}:isClosed   -- same as :isOff

{...}:isDead      -- OR

 

It will get the property of each of the devices in the list and apply the logical operator and return a boolean

{77,88}:isOn

is thus equal to

77:isOn | 88:isOn

but 

{77,88}:isOff

is equal to

77:isOff & 88:isOff

 

The logic is that a room with one lamp on is lit, but a room with all lamps off are dark.

 

Most other :prop will just return a list of the prop values

Ex.

{44,55,66}:lux

will return a list of the lux values, ex

{200,300,200}

Therefore you can do stuff like

rule("luxSensors={44,55,66}")

rule("average(luxSensors:lux) < 200 => lamp:off")

 

 

12 hours ago, Neo Andersson said:

 

2nd question

 

Is there any performance difference between these two calls? (or any difference)

Please login or register to see this code.

 

and

 

Please login or register to see this code.

 

Thanks 

 

There is no performance diff for the execution of the rule.

However, the first rule will be triggered also when the luxsensor changes value, the second rule will not.

So, it depends on what you want.

If you are "unlucky" the second rule may trigger on a breach, but the lux is < 2000 and nothing happens.

...a second later, while the sensor is still breached, the lux changes to 3000, but the rule will not be triggered - and you

have a breached sensor and a lux >= 2000 but your rule doesn't run.

Sometimes, you don't care for such cases or you only want to use the lux as a test and then it's ok to just have rule 2.

 

[Neo Andersson 230]

1 hour ago, jgab said:

 

When you test a property on a list of devices {....}:prop, the semantic depends on the :prop

 

{...}:isOn            -- OR

{...}:isOff           -- AND

{...}:isAllOn       -- AND

{...}:isAnyOff    -- OR

{...}:safe           -- same as :isOff

{...}:breached  -- same as :isOn

{...}:isOpen      -- same as :isOn

{...}:isClosed   -- same as :isOff

{...}:isDead      -- OR

 

It will get the property of each of the devices in the list and apply the logical operator and return a boolean

{77,88}:isOn

is thus equal to

77:isOn | 88:isOn

but 

{77,88}:isOff

is equal to

77:isOff & 88:isOff

 

The logic is that a room with one lamp on is lit, but a room with all lamps off are dark.

 

Most other :prop will just return a list of the prop values

Ex.

{44,55,66}:lux

will return a list of the lux values, ex

{200,300,200}

Therefore you can do stuff like

rule("luxSensors={44,55,66}")

rule("average(luxSensors:lux) < 200 => lamp:off")

 

 

There is no performance diff for the execution of the rule.

However, the first rule will be triggered also when the luxsensor changes value, the second rule will not.

So, it depends on what you want.

If you are "unlucky" the second rule may trigger on a breach, but the lux is < 2000 and nothing happens.

...a second later, while the sensor is still breached, the lux changes to 3000, but the rule will not be triggered - and you

have a breached sensor and a lux >= 2000 but your rule doesn't run.

Sometimes, you don't care for such cases or you only want to use the lux as a test and then it's ok to just have rule 2.

 

 

..."When you test a property on a list of devices {....}:prop, the semantic depends on the :prop"

 

 

@jgab Jan,are you sure is it true for a trueRef rule too? Because i have some difficulties when i use this approach with trueFor rules.

1.)

Please login or register to see this code.

this will evaluate as 'Turn off the light when both sensor1 AND sensor2 are safe for 5 min' ?

2.)

You wrote

{...}:isOn            -- OR

{...}:isOff           -- AND

{...}:isAllOn       -- AND

{...}:isAnyOff    -- OR

{...}:safe           -- same as :isOff

{...}:breached  -- same as :isOn

{...}:isOpen      -- same as :isOn

{...}:isClosed   -- same as :isOff

{...}:isDead      -- OR

 

And how can we add some different logic, if the ER4 pattern doesn't fit for our goal. What if I want to use {...}:isOff    with OR logic operation? Can we explicitly define it inside the rule like

 

Please login or register to see this code.

 

Thanks

 

Edited October 3, 2023 by Neo Andersson

[jgab 2,641]

39 minutes ago, Neo Andersson said:

 

..."When you test a property on a list of devices {....}:prop, the semantic depends on the :prop"

 

 

@jgab Jan,are you sure is it true for a trueRef rule too? Because i have some difficulties when i use this approach with trueFor rules.

1.)

Please login or register to see this code.

this will evaluate as 'Turn off the light when both sensor1 AND sensor2 are safe for 5 min' ?

yes, it's :safe and not :isSafe 

and it will return true when both have been safe for 5min. Not that if any of the sensors goes breached during the 5min the counter restarts...

 

39 minutes ago, Neo Andersson said:

2.)

You wrote

{...}:isOn            -- OR

{...}:isOff           -- AND

{...}:isAllOn       -- AND

{...}:isAnyOff    -- OR

{...}:safe           -- same as :isOff

{...}:breached  -- same as :isOn

{...}:isOpen      -- same as :isOn

{...}:isClosed   -- same as :isOff

{...}:isDead      -- OR

 

And how can we add some different logic, if the ER4 pattern doesn't fit for our goal. What if I want to use {...}:isOff    with OR logic operation? Can we explicitly define it inside the rule like

 

Please login or register to see this code.

No, that's why we have :isAnyOff that tests with an OR. There are a few :props that return booleans and I think I have them all covered.

There :safe,:breached,:isOpen,:isClosed are just aliases for :isOn,:isOff so you can use

Please login or register to see this code.

if you need to...

 

 

You could do your own custom tests if you need

Please login or register to see this code.

The :value will return a list with the boolean values of the sensors in the list.

Our custom function counts the number of true and checks if they are in the majority...

We can use that expression inside the trueFor if we want (trueFor can take any expression returning a boolean)

 

 

Edited October 3, 2023 by jgab

[Neo Andersson 230]

7 minutes ago, jgab said:

yes, it's :safe and not :isSafe 

and it will return true when both have been safe for 5min. Not that if any of the sensors goes breached during the 5min the counter restarts...

 

No, that's why we have :isAnyOff hat tests with an OR. There are a few :props that return booleans and I think I have them all covered.

There :safe,:breached,:isOpen,:isClosed are just aliases for :isOn,:isOff so you can use

Please login or register to see this code.

if you need to...

One more thing.  How to use the same approach that we use in case of isAnyOff in case of blinds? There's no isAnyClosed pattern...

2 minutes ago, Neo Andersson said:

One more thing.  How to use the same approach that we use in case of isAnyOff in case of blinds? There's no isAnyClosed pattern...

Okay, meanwhile you updated your answer with the custom function, so that can be used in case of situtaion that are not covere by ER's  predefined patterns. This goes for blinds i assume.

[jgab 2,641]

1 minute ago, Neo Andersson said:

One more thing.  How to use the same approach that we use in case of isAnyOff in case of blinds? There's no isAnyClosed pattern...

No, but because :isClosed is an alias for :isOff you can use myBlinds:isAnyOff

 

I may add the :isAnyClosed alias in the future...

[jgab 2,641]

2 hours ago, jgab said:

No, but because :isClosed is an alias for :isOff you can use myBlinds:isAnyOff

 

I may add the :isAnyClosed alias in the future...

as a hack you can add this in main()

Please login or register to see this code.

and you have an alias isAnyClosed that is the same as isAnyOff

[Neo Andersson 230]

14 minutes ago, jgab said:

as a hack you can add this in main()

Please login or register to see this code.

and you have an alias isAnyClosed that is the same as isAnyOff

Thanks Jan

[lux 14]

 

 

@jgab

I have added this function to eventrun. Does eventrun have its own method

Please login or register to see this code.

 

[jgab 2,641]

18 minutes ago, lux said:

 

 

@jgab

I have added this function to eventrun. Does eventrun have its own method

Please login or register to see this code.

 

 

Well, if you have a list of devices

Please login or register to see this code.

You can do

Please login or register to see this code.

It will call turnOff on all devices, but calling turnOff on a device that is already off is (usually) no problem. 

For turnOn it may be a problem...

Some multilevelSwitches may behave differently when they are turned on. Some keep their last state and some turn on full brightness - so that could cause an issue when calling turnOn on an already turned on multilevelSwitch. I don't think this is a problem for most z-wave devices, but some QuickApps may change the brightness level when turning on an already turned on device...

 

You could in ER do

Please login or register to see this code.

...but you could also keep your own lua functions.

 

The problem with your code is that binarySwitches have a true/false value if they are on or off, and multilevelSwitches have an integer where 0 is off. EventRunner takes care of that when testing :isOn

 

 

Edited October 7, 2023 by jgab

[lux 14]

@jgab thanks !

If use a lot of for _, D in ipairs (myDevices) do d: isOff&d: on end“

Will it bring about some strange problems?

Edited October 7, 2023 by lux

[jgab 2,641]

1 hour ago, lux said:

@jgab thanks !

If use a lot of for _, D in ipairs (myDevices) do d: isOff&d: on end“

Will it bring about some strange problems?

No, no problems. One way to create something like a reusable function out of it is to do

 

Please login or register to see this code.

 

Edited October 7, 2023 by jgab

[lux 14]

Good idea, thank you very much

23 minutes ago, jgab said:

No, no problems. One way to create something like a reusable function out of it is to do

Please login or register to see this code.

 

 

Edited October 7, 2023 by lux

[lux 14]

@jgab
It seems that there is no way to use toggle for curtains

My use of  blind: toggle  is invalid

Please login or register to see this code.

 

[lux 14]

 

 

@jgab rule("#turnOn{ids='$ids'} => for _,d in ipairs(ids) do d:isOff & d:on end")
                 Do i need to create a new function for dimming lamps or strips?
now i user this:
 

Please login or register to see this code.

 

am i true?

Edited October 7, 2023 by lux