Tutorial: Single scene instance / Event model

[Neo Andersson 230]

@jgab Hello Jan

Can we somehow utilize ER4, to simplify or unify a rule, that is used in a same way in many instances, where only some single value is different?

EX

Customer has remote controller that has 10 buttons.

Every button controls a group of window blinds (open/close)

As you can see, this means 10 line of code only for Pressed event. (there are other events like HeldDown, Released, Double click etc) (He has 34 blinds, 4 remote controllers)

Please login or register to see this code.

 

 

So as you can see there is the same logic repeating for every button group.

Buttons 1,3,5,7,9 open some group of blinds while buttons 2,4,6,8,10 close some group of blinds.

I am pretty sure there is some way to simplify these actions, but i could not find the way.

 

 

 

Question 1: Can we get the keyId on the action side of the rule. The test below doesn't seem to work.

 

Please login or register to see this code.

 

 

Question 2: Can we use table for central.keyId? 
 

Please login or register to see this code.

 

 

 

Any suggestions would be appreciated

 

Thanks

 

[jgab 2,641]

2 hours ago, Neo Andersson said:

@jgab Hello Jan

Can we somehow utilize ER4, to simplify or unify a rule, that is used in a same way in many instances, where only some single value is different?

EX

Customer has remote controller that has 10 buttons.

Every button controls a group of window blinds (open/close)

As you can see, this means 10 line of code only for Pressed event. (there are other events like HeldDown, Released, Double click etc) (He has 34 blinds, 4 remote controllers)

Please login or register to see this code.

 

 

So as you can see there is the same logic repeating for every button group.

Buttons 1,3,5,7,9 open some group of blinds while buttons 2,4,6,8,10 close some group of blinds.

I am pretty sure there is some way to simplify these actions, but i could not find the way.

 

You could do like this (assumes you have several remotes that control different blinds). 

You need to setup the blindRemotes table. key open, key+1 closes.

Please login or register to see this code.

 

2 hours ago, Neo Andersson said:

Question 1: Can we get the keyId on the action side of the rule. The test below doesn't seem to work.

Please login or register to see this code.

No, there is no way that '$keyId' will be bound. '$...' only works inside table/events when matching.

You can see how I do in the first rule above.

If you need keyId in the action you can use 

Please login or register to see this code.

 

 

2 hours ago, Neo Andersson said:

 

Question 2: Can we use table for central.keyId? 
 

Please login or register to see this code.

 

No, remote_controller:central.keyId only return a single value,

 

You can match against the #device event like in my first rule and have a list of deviceIds.

 

You could also do

Please login or register to see this code.

 

 

Edited October 8, 2023 by jgab

[jgab 2,641]

21 hours ago, lux said:

 

 

@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?

Yes, it works but I don't think its a problem to set the same value for a device so no need to check it it already have the value,

so

Please login or register to see this code.

should work

 

Note, this only works with multilevelSwitches or devices with brightness as value - not binarySwitches.

[Neo Andersson 230]

2 hours ago, jgab said:

 

You could do like this (assumes you have several remotes that control different blinds). 

You need to setup the blindRemotes table. key open, key+1 closes.

Please login or register to see this code.

 

No, there is no way that '$keyId' will be bound. '$...' only works inside table/events when matching.

You can see how I do in the first rule above.

If you need keyId in the action you can use 

Please login or register to see this code.

 

 

No, remote_controller:central.keyId only return a single value,

 

You can match against the #device event like in my first rule and have a list of deviceIds.

 

You could also do

Please login or register to see this code.

 

 

The thing is, actually one remote controller is used for different blind groups. The remote controller has 5 button pairs. (10 buttons), so we used to use each pair for different blinds, so user doesn't need to have several remotes. Button 1-2 used to be used for Kitchen blinds,1 for opening 2 for closing them. Kitchen blinds is a group of blinds in kitchen. Buttons 3-4 used to be used for Livingroom blinds group. 3 for opening 4 for closing, and so on for other rooms.

[jgab 2,641]

17 hours ago, Neo Andersson said:

The thing is, actually one remote controller is used for different blind groups. The remote controller has 5 button pairs. (10 buttons), so we used to use each pair for different blinds, so user doesn't need to have several remotes. Button 1-2 used to be used for Kitchen blinds,1 for opening 2 for closing them. Kitchen blinds is a group of blinds in kitchen. Buttons 3-4 used to be used for Livingroom blinds group. 3 for opening 4 for closing, and so on for other rooms.

So, just remove the other_controller then in the example. You still need the table to map button to group.

[Neo Andersson 230]

@jgab Hello Jan

I want to ask you, isn't it possible to somehow implement into ER4 functionality, that when an action is called, the framework should chceck if the device state is not already that desired value?

Like we always ckeck a light state before we turn it on 

eg.

Please login or register to see this code.

 

So i think this logic is always good to have. Maybe the ER4 should do this state control automatically, so we don't need to care about it. So the particullar function would be calld only when the device state is not already in the desired state. What do you think?

 

 

[jgab 2,641]

11 minutes ago, Neo Andersson said:

@jgab Hello Jan

I want to ask you, isn't it possible to somehow implement into ER4 functionality, that when an action is called, the framework should chceck if the device state is not already that desired value?

Like we always ckeck a light state before we turn it on 

eg.

Please login or register to see this code.

 

So i think this logic is always good to have. Maybe the ER4 should do this state control automatically, so we don't need to care about it. So the particullar function would be calld only when the device state is not already in the desired state. What do you think?

 

What problem do you get if you call :on on a device that is already on?

For a binarySwitch that is a no-op as the HC3 will not update the device if there is no change of value.

For multilevelSwitches, as I understand it, it can vary. Some, few, devices may turn on full brightness when :on is called. Most seem to restore previous value.

So, example. If you have a multilevelSwitch (dimmable light) dimmed down to a bare minimum during the night, but you want to turn up when a sensor is breached, rule("motion:breached => light:on") makes sense, if :on turns on full value.

Otherwise you do rule("motion:breached => light:value=99") to turn on full value.

 

So, I don't think the logic is always good to have. Maybe an :onIfOff prop instead.

 

I'm in the process to implement ER5 at the moment (complete rewrite) and it will have user defined :properties so stuff like this could be implemented on a per-needs basis...

 

[Neo Andersson 230]

1 hour ago, jgab said:

 

What problem do you get if you call :on on a device that is already on?

For a binarySwitch that is a no-op as the HC3 will not update the device if there is no change of value.

For multilevelSwitches, as I understand it, it can vary. Some, few, devices may turn on full brightness when :on is called. Most seem to restore previous value.

So, example. If you have a multilevelSwitch (dimmable light) dimmed down to a bare minimum during the night, but you want to turn up when a sensor is breached, rule("motion:breached => light:on") makes sense, if :on turns on full value.

Otherwise you do rule("motion:breached => light:value=99") to turn on full value.

 

So, I don't think the logic is always good to have. Maybe an :onIfOff prop instead.

 

I'm in the process to implement ER5 at the moment (complete rewrite) and it will have user defined :properties so stuff like this could be implemented on a per-needs basis...

 

Of course I did not go into details, how to from the function. Of course in case of such a funcionality, first the function sholud check the device type. If multilevel then it should check against value >0 or < 100, and in case of binary switches or others it is always true or false i suppose. 

What is the benefit? Well i think having a system with more than 300 rules running, it is quite beneficial to spare the system from unnecessary communication. But having the fucntionality in ER5 probaly will solve this. I am awaiting ER5. Thanks

Edited October 10, 2023 by Neo Andersson

[jgab 2,641]

56 minutes ago, Neo Andersson said:

Of course I did not wen into details, how to from the function. Of course in case of such a funcionality, first the function sholud check the device type. If multilevel then it should check against value >0 or < 100, and in case of binary switches or others it is always true or false i suppose. 

What is the benefit? Well i think having a system with more than 300 rules running, it is quite beneficial to spare the system from unnecessary communication. But having the fucntionality in ER5 probaly will solve this. I am awaiting ER5. Thanks

Ok.

but If it's a binarySwitch there is no communication (for same value).

...and if it's a multilevel it's only communication (sending to the device) if you change the value from the existing value. If you change the value from the existing value you surely want it to communicate it to the device, or?

 

The question is just if turnOn should mean restore old value or turn on full brightness for multilevel. Here, ex zwave, QAs, and zigbee may have different behaviours.

To be on the safe side I would have a rule that saves the old value so it can be restored if asked for.

Edited October 10, 2023 by jgab

[Neo Andersson 230]

2 minutes ago, jgab said:

Ok.

but If it's a binarySwitch there is no communication (for same value).

...and if it's a multilevel it's only communication (sending to the device) if you change the value from the existing value. If you change the value from the existing value you surely want it to communicate it to the device, or?

 

The question is just if turnOn should mean restore old value or turn on full brightness for multilevel. Here, ex zwave, QAs, and zigbee may have different behaviours.

To be on the safe side I would have a rule that saves the old value so it can be restored if asked for.

Well i was not aware of that, when device is already ON and there is called a turnOn  action, it won't make any communication to the device. So in this case you are right completly, but i am pretty sure, that i have red about this in some topic. It was stated there, that sending  a turnOn command to a device that is already ON is just burdening the network with unnecessary communications in ZWAWE, So if this is not true, then my question is not appripriate at all.

[jgab 2,641]

38 minutes ago, Neo Andersson said:

Well i was not aware of that, when device is already ON and there is called a turnOn  action, it won't make any communication to the device. So in this case you are right completly, but i am pretty sure, that i have red about this in some topic. It was stated there, that sending  a turnOn command to a device that is already ON is just burdening the network with unnecessary communications in ZWAWE, So if this is not true, then my question is not appripriate at all.

So, now I'm getting uncertain - I just expected that behaviour because that's the behaviour when updating other device properties...

@petergebruers Does turnOn create traffic if device is already turned on?

We know that querying  for values does not as they are "cached" in the HC3...

Otherwise, it's pretty easy to patch fibaro.call to do the necessary tests before... (although, I haven't tested it)

ER uses fibaro.call so it should be picked up by :on etc.

Please login or register to see this code.

 

Edited October 10, 2023 by jgab

[petergebruers 1,268]

4 hours ago, jgab said:

@petergebruers Does turnOn create traffic if device is already turned on?

Last time I checked was in 2017 on a HC2 and it certainly did... Even worse than creating traffic, they also get queued

 

On 4/27/2017 at 3:21 PM, petergebruers said:

But keep in mind, that your HC2 might be the cause. For example, if you send ten thousand 'turnOn' commands to a device, they will be queued and sent. I guesstimate, on a normal network and with a direct connection, this will keep your network busy for about 10 minutes.

 

 

I cannot test that on a HC3 right now and to make the question a bit more complicated: HC3 ZW2 might behave differently than HC3 ZW3 because the latter is based on completely different Z-Wave engine.

 

A possible test you can do: send "turnOn" to a single device in a "for loop", say 100 or 1000 iterations, without any sleep... If your Z-Wave network gets sluggish then they get sent...

 

Two rules I used in my scenes on HC2:

• Send "turnOn" only if the device is "off" and you want it on
• Add a small sleep, 100 to 250 ms, to allow for reporting and avoid saturation your system if you accidentally write an infinite loop

Edited October 10, 2023 by petergebruers

[jgab 2,641]

Then it could be a good idea to patch fibaro.call to queue up commands to zwave devices, and send them off with small delay if too many....

Here is a version that queues them up and dispatch them with 200ms delay and gives an error if more than 500 is queued up

Please login or register to see this code.

Of course it will only be synched within a single scene or QA. If several scenes/QAs sends commands in parallell it will be more.... also, os.clock is effective cpu time used...

Edited October 10, 2023 by jgab

[jgab 2,641]

17 hours ago, jgab said:

Then it could be a good idea to patch fibaro.call to queue up commands to zwave devices, and send them off with small delay if too many....

Here is a version that queues them up and dispatch them with 200ms delay and gives an error if more than 500 is queued up

Of course it will only be synched within a single scene or QA. If several scenes/QAs sends commands in parallell it will be more.... also, os.clock is effective cpu time used...

 

So, this patch only works within one QA/Scene.

If too much traffic generated in this way is a real problem - making the HC3 unstable, I would expect Fibaro to solve this in the platform/fw where they have control over the zwave traffic - there should be no need to do patches like this in "app space"...

Edited October 11, 2023 by jgab

[Neo Andersson 230]

On 10/10/2023 at 9:54 PM, jgab said:

Then it could be a good idea to patch fibaro.call to queue up commands to zwave devices, and send them off with small delay if too many....

Here is a version that queues them up and dispatch them with 200ms delay and gives an error if more than 500 is queued up

Please login or register to see this code.

Of course it will only be synched within a single scene or QA. If several scenes/QAs sends commands in parallell it will be more.... also, os.clock is effective cpu time used...

@jgabJan, does this mean, that we could somehow use this function paralell with ER4, or rather wait for ER5 and use the new possibilities? Or will you create a onIfOff, and offIfOn command for rules in ER4?

Also it is a good idea to keep track on possible infinite loops somehow as @petergebruers mentioned.

Edited October 12, 2023 by Neo Andersson

[jgab 2,641]

1 hour ago, Neo Andersson said:

@jgabJan, does this mean, that we could somehow use this function paralell with ER4, or rather wait for ER5 and use the new possibilities? Or will you create a onIfOff, and offIfOn command for rules in ER4?

Also it is a good idea to keep track on possible infinite loops somehow as @petergebruers mentioned.

Yes, you could use that now. It will return an error if more than 500 calls get queued - so the infinite loop check.

However, if this is a real problem this should really be solved in the framework (by Fibaro) - not in ER -- but I may add something like this in ER5 to catch buggy rules.

No, I will not add it in ER4 (ER4 has feature-stop now), either use

Please login or register to see this code.

or define helper functions

Please login or register to see this code.

 

but once again, be careful, because this won't work on list of devices.

Note that

Please login or register to see this code.

doesn't works the right way as :isOff is true of all lamps are off. You actually need to check it on individual lamps

I would define a turnOff event that checked each lamp individually, to be on the safe side

Please login or register to see this code.

 

 

 

 

 

Edited October 12, 2023 by jgab

[Sjakie 156]

Jan, I am struggling with replacement for 

now > sunrise

Please advice

[jgab 2,641]

2 hours ago, Sjakie said:

Jan, I am struggling with replacement for 

now > sunrise

Please advice

Sorry, need more info. Both 'now' and 'sunrise' haven't changed for years...

[gurpal2000 3]

@jgab is this "optimal" given the comments above about doing check prior to actions

 

Use case: Turn on first floor bathroom fan when light is "on". Turn off the fan when light is off for 5s.

Devices: two physical devices (dimmer plus switch)

Note: not interested yet in the dimmer level, just is it on or off

 

Is there a need to further check if the fan is already off in the last line?

 

Please login or register to see this code.

Edited October 15, 2023 by gurpal2000

[jgab 2,641]

13 hours ago, gurpal2000 said:

@jgab is this "optimal" given the comments above about doing check prior to actions

 

Use case: Turn on first floor bathroom fan when light is "on". Turn off the fan when light is off for 5s.

Devices: two physical devices (dimmer plus switch)

Note: not interested yet in the dimmer level, just is it on or off

 

Is there a need to further check if the fan is already off in the last line?

 

Please login or register to see this code.

No, no need. The issue is if you fire of many commands at the same time - like turning on 20 lamps with one command. In that case it may be advantageous to pace the commands with a small delay and not send :on to lamps already on.

In your case the fan will only be turned off every 5s at max... and the first rule is kind of "guarded" as it will not turn on the fan unless its off,