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

[Rover 47]

Since I am using SlaveSensor for most sensor devices (15 D/W sensors and one motion sensor) because of developing the arming/disarming AOQ lines, the arming and disarming scenes on HC2 takes many minutes and the AOQ lines for lights on after detection by motion sensor takes 10-20 seconds. Using <device>'hc2 did not had this disadvantage, but they are not useful in showing up in Alarm Zones.

[Rover 47]

7 hours ago, cag014 said:

Yes, looks like fibaro issue.

I have 4.600 on HC2 and it was fine till few hours ago....

Meanwhile email notifications work again since 14:43.

[cag014 731]

14 minutes ago, Rover said:

Since I am using SlaveSensor for most sensor devices (15 D/W sensors and one motion sensor) because of developing the arming/disarming AOQ lines, the arming and disarming scenes on HC2 takes many minutes and the AOQ lines for lights on after detection by motion sensor takes 10-20 seconds. Using <device>'hc2 did not had this disadvantage, but they are not useful in showing up in Alarm Zones.

What sampleRate you're using?

[Rover 47]

3 minutes ago, cag014 said:

What sampleRate you're using?

What is sampleRate?

Please login or register to see this spoiler.

 

[cag014 731]

4 hours ago, Rover said:

What is sampleRate?

Please login or register to see this spoiler.

Edited October 14, 2020 by cag014

• Quote

[Rover 47]

25 minutes ago, cag014 said:

I mean in Slave sensor emulation

ip="192.168.99.99"

user="xxx"

passwd="xxx"

device=724

sampleRate=1000 

 

Another question, how fast reacts SlaveSensor  to change in HC2?

All SlaveSensors have the initial sampleRate=1000.

The HC2 arm scenes and disarm scenes are triggert by HC3 AOQ and have been gotten very slow (to minutes) in execution. The arming of HC2 devices (having also HC3 SlaveSensors) by HC2 scenes are so slow that in the HC2 arming tests most devices are notified as not armed.

BTW the CPU loads of HC2 and HC3 are low.

Edited October 14, 2020 by Rover

[cag014 731]

2 minutes ago, Rover said:

All SlaveSensors have the initial sampleRate=1000.

The HC2 arm scenes and disarm scenes are triggert by HC3 AOQ and have been gotten very slow (to minutes) in execution. The arming of HC2 devices (having also HC3 SlaveSensors) by HC2 scenes are so slow that in the HC2 arming tests most devices are notified as not armed.

It should take less than 2~3 seconds.. strange indeed

How many SlaveSensor you have on HC3... @gggizmo has an issue on HCL with too many emulations which slowed down the HCL.

Another test, can you write a line in jM that with some keyFob, you executes the arm/disarm scenes on HC2 - how long it takes?

[Rover 47]

1 hour ago, cag014 said:

It should take less than 2~3 seconds.. strange indeed

How many SlaveSensor you have on HC3... @gggizmo has an issue on HCL with too many emulations which slowed down the HCL.

Another test, can you write a line in jM that with some keyFob, you executes the arm/disarm scenes on HC2 - how long it takes?

(15 D/W sensors and one motion sensor) as SlaveSensors on HC3.

ArmSlapen scene 199 on HC2 triggert by HC3: total 2 minutes 11 seconds.

Please login or register to see this spoiler.

Edited October 14, 2020 by Rover

[cag014 731]

27 minutes ago, Rover said:

(15 D/W sensors and one motion sensor) as SlaveSensors on HC3.

ArmSlapen scene 199 on HC2 triggert by HC3: total 2 minutes 11 seconds.

Please login or register to see this spoiler.

Can you post debug info from HC2? I mean how long takes to scene to arm and set the global in HC2?

[Rover 47]

6 minutes ago, cag014 said:

Can you post debug info from HC2? I mean how long takes to scene to arm and set the global in HC2?

Is the addition in the previous message enough?

Edited October 14, 2020 by Rover

[cag014 731]

1 minute ago, Rover said:

Is the addition in the previous message enough?

No, how can you know when the HC2 global parameters set to armed?

You might have delays in HC2 scene? for example if you're using fibaro:sleep()  and etc.

[Rover 47]

1 minute ago, cag014 said:

No, how can you know when the HC2 global parameters set to armed?

You might have delays in HC2 scene? for example if you're using fibaro:sleep()  and etc.

Sorry, the insertion of the most instructive picture was going wrong:

Please login or register to see this spoiler.

The disarming loop in HC2 scene 200.

[cag014 731]

26 minutes ago, Rover said:

Sorry, the insertion of the most instructive picture was going wrong:

Please login or register to see this spoiler.

@Rover

Please download this version and let's see what the response time is?

In addition have added an option to use and statement in device list {"420 and 300 and 546","turnOn"}

 

Please login or register to see this attachment.

Edited October 14, 2020 by cag014

• Quote

[Rover 47]

2 minutes ago, cag014 said:

OK, this is disarming loop, where you send command to  disarm every sensor [ fibaro:call(ID,"setArm",0) ]and setting the global value?

By the way to disarm sensor in hc2 takes few milliseconds, your loop runs much faster, so till all sensors disarmed with delay 0.8 seconds you'll end up with few second delay.

 

This is the waiting loop for disarming using <device>'hc2 instead of SlaveSensors:

Please login or register to see this spoiler.

 

[cag014 731]

4 minutes ago, Rover said:

This is the waiting loop for disarming using <device>'hc2 instead of SlaveSensors:

Now I'm confused... <device>'hc2 instead of SlaveSensors:

What is the trigger in jM line?

[Rover 47]

5 minutes ago, cag014 said:

Now I'm confused... <device>'hc2 instead of SlaveSensors:

What is the trigger in jM line?

Please login or register to see this spoiler.

 

[cag014 731]

2 minutes ago, Rover said:

Please login or register to see this spoiler.

OK, so where is the reference to SlaveSensor?

[Rover 47]

5 minutes ago, cag014 said:

OK, so where is the reference to SlaveSensor?

reference to SlaveSensor?

The sensors are for arming and disarming still only controlled by HC2 + these sensors got a SlaveSensor QA + these SlaveSensors have been included in HC3 Alarm Zones.

Edited October 14, 2020 by Rover

[cag014 731]

1 minute ago, Rover said:

reference to SlaveSensor?

The sensors are for arming and disarming still only controlled by HC2 + these sensors got a SlaveSensor QA + these SlaveSensors have been included in HC3 Alarm Zones.

But SlaveSensors doesn't have alarm property as sensors in HC2 and alarm property changes according to HC3 alarm zone!

when you using <device>'hc2 , it does have alarm property which updated by HC2 and reflected in HC3.

The emulation of the sensors is to arm/disarm and monitor alarm breached on HC3 only and not mirrored in HC2 at all. The HC2 and HC3 alarms are totally disconnected.

The idea is to emulate all sensors in HC3 for alarm and from this point HC3 should take control on alarm and not HC2. Later after migration just change device IDs.

I understand that you want to keep meanwhile HC2 as your main alarm till migration, but you need to use HC3 alarm in parallel.

My suggestion is to arm/disarm alarm on HC3 and in parallel to start scene  arm/disarm on HC2 to keep your original functionality till everything will be on HC3.

 

Or I'm totally misunderstand what you trying to achieve!?

Could you briefly to explain what exactly your target with these alarms?

 

 

[Rover 47]

9 minutes ago, cag014 said:

But SlaveSensors doesn't have alarm property as sensors in HC2 and alarm property changes according to HC3 alarm zone!

when you using <device>'hc2 , it does have alarm property which updated by HC2 and reflected in HC3.

The emulation of the sensors is to arm/disarm and monitor alarm breached on HC3 only and not mirrored in HC2 at all. The HC2 and HC3 alarms are totally disconnected.

The idea is to emulate all sensors in HC3 for alarm and from this point HC3 should take control on alarm and not HC2. Later after migration just change device IDs.

I understand that you want to keep meanwhile HC2 as your main alarm till migration, but you need to use HC3 alarm in parallel.

My suggestion is to arm/disarm alarm on HC3 and in parallel to start scene  arm/disarm on HC2 to keep your original functionality till everything will be on HC3.

 

Or I'm totally misunderstand what you trying to achieve!?

Could you briefly to explain what exactly your target with these alarms?

 

 

I see your confusion without knowledge of my migration scenario.

Migration scenario:

• First implement all lighting functionality in AOQ and disable these functionality in HC2.
• Then implement arming/disarming functionality in AOQ with 2 D/W sensors as SlaveSensors.
  • The basic arming/disarming functionality in AOQ with 2 D/W sensors as SlaveSensors works
  • Meanwhile the HC2 arming/disarming scenes are triggert on HC3 by <device>'HC2
• In order to test the arming/disarming functionality all D/W sensors have been implemented as SlaveSensor.
  • Then the arming/disarming scenes triggert on HC3 by <device>'HC2 have become extremely slow. So the fact that a HC2 sensor is also HC3 SlaveSensor makes the arming/disarming operation in HC2 very slow, while the CPU load is low (average 20%).
  • Extra clue: I also have changed a motion sensor from <device>'hc2 to SlaveSensor: result is extremely slow AOQ turnOn of lights (>10 seconds), while another motion sensor is triggering lighting in AOQ as <device'hc2 quickly. This has nothing to do with arming/disarming.
• Now I am at the point of testing arming/disarming functionality with all D/W sensors implemented as SlaveSensor on AOQ
  • As soon as all arming/disarming works in AOQ the HC2 arming/disarming scenes will be discommissioned.
• After migrating some small scenes to AOQ and implementing NEST thermostat in HC3 (I intent to do this with an IFTTT QA) we are ready for migrating all devices form HC2 to HC3.