All-in-One Scene: How to do it Better

[cag014 731]

51 minutes ago, Rover said:

I see:

Please login or register to see this spoiler.

Nothing wrong with ?random(...)?, as you can see it shows 13

Thanks for finding new bug... the command works fine. The error that instead of showing jM line number, it uses alias with the same number.

setTimeSpan{&XBoekenkastRechts>HitteOverloop)13')

means setTimeSpan for &XBoekenkastRechts>[ jM_line ] to 13 minutes.

Will fixed, but the command works fine... tested.

Edited September 18, 2020 by cag014

[Rover 47]

10 hours ago, cag014 said:

2. Regarding sceneActivation I think the problem is in command - you're trying to turnOff remote?

trueAct={ {"&ConstantHalLicht","setGlobal","0"},{"`DimmerHal`","turnOff",""},{"Dimmerlicht","sendEmail[2]","SceneActivation 11: 1x op Omlaag klikken"} } }},

I assume it should be

trueAct={ {"&ConstantHalLicht","setGlobal","0"},{"`Dimmerlicht`","turnOff",""},{"Dimmerlicht","sendEmail[2]","SceneActivation 11: 1x op Omlaag klikken"} } }},

Thanks again for finding bug - error checker should warn that "turnOff" command is not available for remote controller, from other hand might be that your remote does have it. Could you please post API data of this remote, I want to be sure about that.

It looks somewhat different: the Fibaro Dimmer2 has 3 devices each of type Dimmer and not Remote Controller.

"Dimmerlicht" is no device, but just a text in an email.

SceneActivation produces the right response of the dimmer (S1=10, S2=11)

So no error that dimmer device has also remote controller functionality.

Please login or register to see this spoiler.

Please login or register to see this attachment.

Please login or register to see this attachment.

Please login or register to see this attachment.

Edited September 18, 2020 by Rover

[Rover 47]

8 hours ago, cag014 said:

Nothing wrong with ?random(...)?, as you can see it shows 13

Thanks for finding new bug... the command works fine. The error that instead of showing jM line number, it uses alias with the same number.

setTimeSpan{&XBoekenkastRechts>HitteOverloop)13')

means setTimeSpan for &XBoekenkastRechts>[ jM_line ] to 13 minutes.

Will fixed, but the command works fine... tested.

No, it is not an alias with the same number (DevID of HitteOverloop = 17).

Have a look:

Please login or register to see this spoiler.

 

[Rover 47]

Scenario:

An AOQ trueAct line has to be triggered by 2 remote controllers of type sceneActivation (WALLC-S) and by 2 Fibaro Keyfobs and by one of type centralSceneSupport (Remotec ZRC90) and by your nice AOQ_REMOTE QA.

How to implement this without copying the (long) trueAct line?

Using a HC3 scene to toggle a global variable is one solution, but maybe you know a more elegant way.

[gggizmo 6]

I'm now testing a mixed configuration of block scenes and aoq for action not triggered too often.

Cpu load is higher than only block scenes scenario but not too much.

@cag14

Actions triggered by motion sensors are a minimum delay of 1 sec if executed in jm lines, virtually no delay in block scenes.

Weird is that wall remote has less delay if action is starded by aoq...

So heating, cooling, sprinklers ( in slave hcl) and wall remote now are in jm lines

Lights automation is configured in block scenes to have the most responsive actions after any trigger.

Do you think it's normal that for example light triggerd by motion sensor react with 1 sec delay in aoq and no delay in block scene?

 

 

 

[cag014 731]

3 hours ago, Rover said:

No, it is not an alias with the same number (DevID of HitteOverloop = 17).

Have a look:

Please login or register to see this spoiler.

I'm confused... on the same jM line you're updating timeSpan for few items? Like on line 18,19

Could you please post your jM... I think there is an update for line 17 as well and then the alias takes place.

[Rover 47]

4 minutes ago, cag014 said:

I'm confused... on the same jM line you're updating timeSpan for few items? Like on line 18,19

Could you please post your jM... I think there is an update for line 17 as well and then the alias takes place.

Please login or register to see this spoiler.

 

[cag014 731]

1 hour ago, Rover said:

Please login or register to see this spoiler.

@Rover and all

Please download attached version.

Bug Fix:

sceneActivation of multilevel switch triggered by any command

Alias name shown instead of jM line number at command line

-------

Common format for all commands action_name, parameters {devices)

 

Please login or register to see this attachment.

Edited September 18, 2020 by cag014

[Rover 47]

8 minutes ago, cag014 said:

Common format for all commands action_name, parameters {devices)

TNX cag,

Please give an example for this common format.

[cag014 731]

Just now, Rover said:

TNX cag,

Please give an example for this common format.

It's a cosmetic issue for example

setColor,214,33,0,0{792'hc2)

setValue,53{792'hc2)

while

setTimeSpan{&web_7>2)15')

New format

setTimeSpan,15'{&web_7>2)

[Rover 47]

10 minutes ago, cag014 said:

It's a cosmetic issue for example

setColor,214,33,0,0{792'hc2)

setValue,53{792'hc2)

while

setTimeSpan{&web_7>2)15')

New format

setTimeSpan,15'{&web_7>2)

What is then the new

Please login or register to see this spoiler.

?

[cag014 731]

3 minutes ago, Rover said:

What is then the new

Please login or register to see this spoiler.

No, the new format is only how executed command displayed, that's all.

No changes in jM, jS2n, jP2n tables.

[Rover 47]

30 minutes ago, cag014 said:

sceneActivation of multilevel switch triggered by any command

No bombardments of emails anymore ?

[cag014 731]

5 hours ago, gggizmo said:

I'm now testing a mixed configuration of block scenes and aoq for action not triggered too often.

Cpu load is higher than only block scenes scenario but not too much.

@cag14

Actions triggered by motion sensors are a minimum delay of 1 sec if executed in jm lines, virtually no delay in block scenes.

Weird is that wall remote has less delay if action is starded by aoq...

So heating, cooling, sprinklers ( in slave hcl) and wall remote now are in jm lines

Lights automation is configured in block scenes to have the most responsive actions after any trigger.

Do you think it's normal that for example light triggerd by motion sensor react with 1 sec delay in aoq and no delay in block scene?

 

 

 

Expected delays are:

1.1 second on slave devices...

400 milliseconds on primary HC3.

 

Delays above expected only if your HC3 is not active very much, means no frequent events happen.

When the HC3 is active less than 400 milliseconds delays expected.

2 minutes ago, Rover said:

No bombardments of emails anymore ?

Great to hear.

Thanks again for finding that. It happens only when the dimmers configured to sceneActivation as well and you are using that.....

[gggizmo 6]

3 minutes ago, cag014 said:

Expected delays are:

1.1 second on slave devices...

400 milliseconds on primary HC3.

 

Delays above expected only if your HC3 is not active very much, means no frequent events happen.

When the HC3 is active less than 400 milliseconds delays expected.

ok tnx. So it's by design that aoq react with a little delay compered to block scene or as usual my guessing is wrong?

[cag014 731]

Just now, gggizmo said:

ok tnx. So it's by design that aoq react with a little delay compered to block scene or as usual my guessing is wrong?

Yes...

The reason behind is to have a proper delay for slave devices.... if HC3 has no events the AOQ could wait up to 30 seconds for event and this delay is unacceptable to work with slaves.

In general it works in that loop...

 

wait for event on HC3 with time out of 1 second. No event run the code to get slave data and perform actions  ~100-400 milliseconds (depends on how many devices you have)

back to HC3 for events

 

in the future I will to try just to scan devices values w/o waiting for triggered events on HC3. Don't know if it will have better performances.

[cag014 731]

@gggizmo

By the way on new beta version of HC3 looks like delays on HC3 could be reduced w/o extra CPU load.

Let's wait for official release and see. (right now there are few major bugs)

[gggizmo 6]

12 minutes ago, cag014 said:

@gggizmo

By the way on new beta version of HC3 looks like delays on HC3 could be reduced w/o extra CPU load.

Let's wait for official release and see. (right now there are few major bugs)

Ok. tnx. I start to understand now. So it's not a problem at all: i know that for now if i want a specific action to perform virtually without delay it's better to create a block or lua scene. 

 

[cag014 731]

Probably, but if your HC3 has many devices then almost always some events executed and you should have no delays....but...

Another observation, that zwave communication could take up to 100 milliseconds. So even block scene will have in worse case scenario up to 200 milliseconds delay (receiving motion sensors and executing command). All that without considering CPU load...

Edited September 18, 2020 by cag014

[gggizmo 6]

1 minute ago, cag014 said:

Probably, but if your HC3 has many devices then almost always some events executed and you should have no delays....but...

Sure, but in my specific case with a lot of events expecially during evening i have a lot of delays, sometimes 2 or 3 seconds in aoq. Today as i previous said i tried mixed configuration. Same devices, same declarations in aoq, with slave hcl. And block scenes actions are quite immediate. I tried stopping block scenes and reactivate jm lines for lights...again minimum delay of 1 sec.

May be my specific system, but for now i'm happy ...and my experimental jm lines are on secondary hc3 so i can play with no fear