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

[cag014 731]

Attached version includes command action states description in hcWebEye 

Please login or register to see this spoiler.

 

Please login or register to see this attachment.

[Rover 47]

2 minutes ago, cag014 said:

Attached version includes command action states description in hcWebEye 

Please login or register to see this spoiler.

[20.01.2021] [11:24:01] [ERROR] [QUICKAPP372]: QuickApp crashed[20.01.2021] [11:24:01] [ERROR] [QUICKAPP372]: main.lua:1523: unfinished string near

[cag014 731]

No... maybe same problem as @gggizmo, needs to reboot?

By the way for the first time that you copy the code,  you'll see a random error but the program runs... that's OK in this HC3 version...

Please login or register to see this spoiler.

 

Edited January 20, 2021 by cag014

[Rover 47]

2 hours ago, cag014 said:

No... maybe same problem as @gggizmo, needs to reboot?

By the way for the first time that you copy the code,  you'll see a random error but the program runs... that's OK in this HC3 version...

Please login or register to see this spoiler.

?

[Rover 47]

Please login or register to see this spoiler.

run errAct{} ?!?

no display of okAct or errAct ?!>

[Rover 47]

1 minute ago, cag014 said:

Could you please post entire line?

The entire line has been showed above.

[cag014 731]

17 minutes ago, Rover said:

Please login or register to see this spoiler.

Could you post debug window of commands sent to buzzer?

Have tried to display errAct or okAct, but since these actions could be long and complicated it makes mess on the commands structure.... didn't find proper way to display it yet.

[Rover 47]

5 minutes ago, cag014 said:

Could you post debug window of commands sent to buzzer?

Have tried to display errAct or okAct, but since these actions could be long and complicated it makes mess on the commands structure.... didn't find proper way to display it yet.

Please login or register to see this spoiler.

 

[cag014 731]

22 minutes ago, Rover said:

Please login or register to see this spoiler.

Try attached version

Let me know if buzzer works

Please login or register to see this attachment.

[Rover 47]

15 minutes ago, cag014 said:

Try attached version

Let me know if buzzer works

Please login or register to see this attachment.

Yes, works!! ?

What was going on?

[cag014 731]

2 minutes ago, Rover said:

Yes, works!! ?

What was going on?

Since you have errAct and okAct they replace current trueAct in buffer... this is a mistake from me, they should be executed in parallel to all other actions. Fixed...

 

[Rover 47]

1 minute ago, cag014 said:

Since you have errAct and okAct they replace current trueAct in buffer... this is a mistake from me, they should be executed in parallel to all other actions. Fixed...

 

Does that also explain the "run errAct" in webEye?

[cag014 731]

1 minute ago, Rover said:

Does that also explain the "run errAct" in webEye?

No... trying to find why it displayed in the wrong command.

[cag014 731]

@Rover

Attached version displays correctly the verification request, but in order to display errAct or okAct extra two columns should be added to the table.

Since most of the commands are not include verification, do you think it necessary and must be included?

 

Please login or register to see this attachment.

Edited January 21, 2021 by cag014

[Rover 47]

7 minutes ago, cag014 said:

@Rover

Attached version displays correctly the verification request, but in order to display errAct or okAct extra two columns should be added to the table.

Since most of the commands are not include verification, do you think it necessary and must be included?

 

Please login or register to see this attachment.

webEye display is correct now with correct indication of verification ?. I do not understand your question: why remove this nice display of verification, or do you mean if other commands then arming/disarming should also have verification indication? In that case I do not think so.

Display of errAct and okAct would be nice to have a complete insight.

[cag014 731]

The verification would be always displayed where defined.

I meant the errAct and okAct display...

[Rover 47]

13 minutes ago, cag014 said:

The verification would be always displayed where defined.

I meant the errAct and okAct display...

Maybe errAct and okAct are used more then f.i. timeLoopAct. I think it is necessairy when operating a lot of devices within one command taking noticeable time per device, like arming/disarming. Although since your last timing miracles everything is super fast: arming/disarming in a few seconds and also putting all lights on/off in a few seconds! When I am thinking back to the HC2-slaves period where all this took more then a minute...

[cag014 731]

Attached version includes dynamic columns arrangement and shows only columns of actions in use. It means if you don't use some action then the column is not displayed.

So if you have errAct or okAct it will be displayed.

In addition fixed an issue when using delay in conjunction with state condition, the status printed all the time till the command executed.

 

 

 

Please login or register to see this attachment.

[Rover 47]

12 hours ago, cag014 said:

Attached version includes dynamic columns arrangement and shows only columns of actions in use. It means if you don't use some action then the column is not displayed.

So if you have errAct or okAct it will be displayed.

In addition fixed an issue when using delay in conjunction with state condition, the status printed all the time till the command executed.

 

 

 

Please login or register to see this attachment.

One AOQ OK, other AOQ (the one with okAct/errAct): 

Please login or register to see this spoiler.

 

Edited January 22, 2021 by Rover

[Rover 47]

What is in webEye the meaning of value TBR?