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

[cag014 731]

52 minutes ago, Rover said:

Please login or register to see this spoiler.

It's because the start was when the lights are ON.

4 seconds is too much...

Try attached version.. I saw that could happened, and have added some kind of fail-safe mechanism

It work a little bit complicated, but you can define repeat actions and end of action.

for example:

trueAct={{"`DImmerHall`","trunOn;else;turnOff"," if {`DimmerHall`:value=0}"},{"`DImmerHall`","turnOff"}}

{"$blank>2","rptAction,6,1","trueAct,1"}

The number in trueAct,1 means to repeat command number one and after that to execute the rest of trueAct commands.

The previous format supported also {"$blank>2","rptAction,6,1","trueAct"}

 

 

Please login or register to see this attachment.

Edited October 2, 2020 by cag014

[Rover 47]

2 hours ago, cag014 said:

It's because the start was when the lights are ON.

4 seconds is too much...

Try attached version.. I saw that could happened, and have added some kind of fail-safe mechanism

It work a little bit complicated, but you can define repeat actions and end of action.

for example:

trueAct={{"`DImmerHall`","trunOn;else;turnOff"," if {`DimmerHall`:value=0}"},{"`DImmerHall`","turnOff"}}

{"$blank>2","rptAction,6,1","trueAct,1"}

The number in trueAct,1 means to repeat command number one and after that to execute the rest of trueAct commands.

The previous format supported also {"$blank>2","rptAction,6,1","trueAct"}

 

 

Please login or register to see this attachment.

It did not exactly behaves like that. The scenario is that even when the dimmer is on it starts flashing with maximum light level and after flashing returns to the previous light level.

Please login or register to see this spoiler.

 

[cag014 731]

1 hour ago, Rover said:

It did not exactly behaves like that. The scenario is that even when the dimmer is on it starts flashing with maximum light level and after flashing returns to the previous light level.

Please login or register to see this spoiler.

I do see 6 repetitions (means 3 cycles), but that's abnormal to have up to 4 seconds  delay...

I am running same exact the same scenario and it works fine

Let's try to set drastic time reduction on refreshState

Go to last function in Lua code "QuickApp:onInit()" and set in follow line 100 (timeout)

 

self.http = net.HTTPClient({timeout=100}) -- bigger timeout is needed 

 

 

Edited October 2, 2020 by cag014

[Rover 47]

3 hours ago, cag014 said:

I do see 6 repetitions (means 3 cycles), but that's abnormal to have up to 4 seconds  delay...

I am running same exact the same scenario and it works fine

Let's try to set drastic time reduction on refreshState

Go to last function in Lua code "QuickApp:onInit()" and set in follow line 100 (timeout)

 

self.http = net.HTTPClient({timeout=100}) -- bigger timeout is needed 

 

 

The result with timeout=100 seems somewht more responsive, but the 3-4 seconds delay are staying.

Please login or register to see this spoiler.

While using this HC2 scene has a perfect timing (0.5 sec. turnOn and 1 sec. turnoff), working with Dimmer2. I only have to translate this scene to HC3 later on, but for now <_sceneID'hc2> works excellent.

My idea is that acts with devices with very small reaction times are not suitable for AOQ with normally acts with seconds reaction time. Agree?

Edited October 2, 2020 by Rover

[Rover 47]

15 hours ago, cag014 said:

To all, attached slave switch emulation QA. Emulation includes power and energy readings, if exist on slave switch.

This QA suitable for all kind of switches (WallPlug, Fibaro double/single switch and etc.)

 

Please login or register to see this attachment.

 

I see now the use of this SlaveSwitch.fqa. It is usable in HC3 scenes!

 

Could you make a SlaveDimmer.fqa (or more general SlaveMultiswitch.fqa) please?

Then I could make a scene in HC3 steering a dimmer in HC2.

 

Or can SlaveSwitch.fqa do the dimmer job too?

[cag014 731]

1 hour ago, Rover said:

While using this HC2 scene has a perfect timing (0.5 sec. turnOn and 1 sec. turnoff), working with Dimmer2. I only have to translate this scene to HC3 later on, but for now <_sceneID'hc2> works excellent.

My idea is that acts with devices with very small reaction times are not suitable for AOQ with normally acts with seconds reaction time. Agree?

I agree that overall it's not recommended to run that on slave devices... but for other hand it runs excellent on my HC3 while the device on HC2.

 

Please login or register to see this spoiler.

It could be interesting to see if the same HC2 scene will run on HC3 also with correct timing...

[cag014 731]

@Rover

To tell the truth the delay of 4 seconds sounds to high at any configuration and it looks like HC2 is the cause of delay.

Could you open browser and switch the dimmer every second thought the browser?

The scene runs internally on hc2 while browser and AOQ use REST API commands.

I have seen some problems when too many tabs are open ...

Another way to test it... upload slaveSwitch QA and set it for Dimmer. Now again press turn on off on HC3 UI and see if it works correctly.

Or just reboot HC2 and test it again...

 

Edited October 2, 2020 by cag014

[Rover 47]

15 hours ago, cag014 said:

Or just reboot HC2 and test it again...

Rebooted HC2: no difference in {"$blank>2","rptAction,6,1","trueAct,1"} reaction times, all about 4 seconds.

Using slaveSwitch QA in {"$blank>2","rptAction,6,1","trueAct,1"} : works with 3-5 seconds in between.

Using slaveSwitch QA in HC3 scene 0.5 second on and 1 second out, 5 times: irregular flashing.

Using slaveSwitch QA in HC3 scene 1 second on and 1 second out, 5 times: irregular flashing.

Using slaveSwitch QA in HC3 scene 2 seconds on and 2 seconds out, 5 times: irregular flashing, 3-5 seconds in between.

AOS on HC2: 1 second on and 1 second out, 3 times: irregular flashing.

Conclusion: all very unsatisfactory.

Only solution: scene on HC2 and after migration of devices to HC3: scene on HC3.

 

BTW: Fibaro switches react fast as slave. But a dimmer is another story...

Edited October 3, 2020 by Rover

[Rover 47]

20 hours ago, cag014 said:

I do see 6 repetitions (means 3 cycles), but that's abnormal to have up to 4 seconds  delay...

I am running same exact the same scenario and it works fine

Let's try to set drastic time reduction on refreshState

Go to last function in Lua code "QuickApp:onInit()" and set in follow line 100 (timeout)

 

self.http = net.HTTPClient({timeout=100}) -- bigger timeout is needed 

 

 

Should I set the timeout back?

CPU-load with timeout=100 is about 30%.

[cag014 731]

Since it doesn't help yes, you can set the timeout back.

This is very interesting issue....

[Rover 47]

8 minutes ago, cag014 said:

Since it doesn't help yes, you can set the timeout back.

This is very interesting issue....

O.K. With timeout=450 CPU-load goes back to about 20%.

[cag014 731]

I still don't understand the delay of 4 seconds in your system

AOQ has no delay inside at all... have checked AOQ with 200 lines and still no delay.

 

[cag014 731]

@Rover

Did some change to make sure that the highest priority in AOQ is to execute the commands and not refreshState scanning....

Please try it.

 

Please login or register to see this attachment.

[SmartLifeSystems 20]

Hi cag,

 

I think i find a bug in the AOQv3 series. Int the push notifications the AOQ put a "\n" characters before the messages or after the subject.

Can you see please?

Please login or register to see this attachment.

[SmartLifeSystems 20]

The interesting that is in debug window that's correct.

 

[2020-10-03] [14:31:58] [TRACE] [AOQ3694]: ^3.3jM{126} _LGarage:421:Garage door sensor[true] => sendPush,3370(Attila iPhone-ja,) 'Garázsajtó:','A garázsajtó nyitva van...')

[2020-10-03] [14:32:40] [TRACE] [AOQ3694]: ^3.3jM{123} _TGarage:421:Garage door sensor[false] => sendPush,3370(Attila iPhone-ja,) 'Garázsajtó:','A garázsajtó csukva.')

[cag014 731]

37 minutes ago, SmartLifeSystems said:

The interesting that is in debug window that's correct.

 

[2020-10-03] [14:31:58] [TRACE] [AOQ3694]: ^3.3jM{126} _LGarage:421:Garage door sensor[true] => sendPush,3370(Attila iPhone-ja,) 'Garázsajtó:','A garázsajtó nyitva van...')

[2020-10-03] [14:32:40] [TRACE] [AOQ3694]: ^3.3jM{123} _TGarage:421:Garage door sensor[false] => sendPush,3370(Attila iPhone-ja,) 'Garázsajtó:','A garázsajtó csukva.')

This is the new line character between subject and message body. It doesn't shown on debug window.

Works fine on Android phones....

More likely Fibaro's bug...

See how it looks on Android, the new line not shown!!

Please login or register to see this spoiler.

 

 

 

 

[cag014 731]

To all,

On HC3 FW version 4.051.xx (not sure if all of them, works for 5.041.50 ) there is an option to see devices in full view on browser.

Please try it

http://<HC3-IP>/app/webView/devices/<deviceID

Please login or register to see this spoiler.

 

Edited October 3, 2020 by cag014

[Rover 47]

4 hours ago, cag014 said:

@Rover

Did some change to make sure that the highest priority in AOQ is to execute the commands and not refreshState scanning....

Please try it.

 

Please login or register to see this attachment.

Please login or register to see this spoiler.

Interesting: Total time 11 seconds (just only turnOff).

[cag014 731]

21 minutes ago, Rover said:

Please login or register to see this spoiler.

For the switches that's OK, because you need different condition value=false and not value=0

For the dimmer, that's strange! For 11 seconds the status not updated??? So the dimmer was always on?

To me it sounds like the condition for the dimmer is wrong also? Is it the same `DimmerHall` that you tested before?

 

 

 

 

Edited October 3, 2020 by cag014

[cag014 731]

Please change the line of $blank back to ON/OFF, it makes the line generic for all dimmers/switches (no specific conditions)

{0,"$blank",{trueAct={{"`HalDimmer`","turnOn"},{"`HalDimmer`","turnOff","1"}}}},

and set {"$blank>2","rptAction,3,1","trueAct")

Edited October 3, 2020 by cag014