Multi sensor 6

[JayC]

I was wondering if anyone has any good experience with these under USB power. If so how well do these work as repeaters. I was wanting more out of a zwave device than just a standard repeater or siren as some have good luck with.

 

Sent from my SAMSUNG-SM-N910A using Tapatalk

[KeviNH]

With USB power, the Aeon Multisensor 6 works great as a sensor, you can set the update interval so lag (e.g. on temperature) is minimal.

 

I just recently re-included mine as a secure repeater, so far it doesn't seem to have made a difference (e.g. no change in signal reliability)

[JayC]

I have two zwave door locks that I can't integrate into my isy yet because they sit too far from the isy. I am wanting something that connects to the powerline because it my understanding that battery powered devices do not act as repeater. I'd rather buy this multisensor 6 because it offers more benefits than just a signal repeater when usb powered. Do you believe that if this is the only thing that I have for repeating that it will be sufficient, ie does it work just as good as the zwave siren that several have suggested for better zwave repeating?

[KeviNH]

I have two zwave door locks that I can't integrate into my isy yet because they sit too far from the isy. I am wanting something that connects to the powerline because it my understanding that battery powered devices do not act as repeater. I'd rather buy this multisensor 6 because it offers more benefits than just a signal repeater when usb powered. Do you believe that if this is the only thing that I have for repeating that it will be sufficient, ie does it work just as good as the zwave siren that several have suggested for better zwave repeating?

I suspect the MultiSensor 6 is not nearly as good a repeater as the Z-Wave siren.

 

For door locks, you want repeaters known to support both "beaming" and "secure" inclusion and is known for very good signal sensitivity and transmit power -- the last two requirements are influenced by antenna design and orientation.

[vjk]

For door locks, you want repeaters known to support both "beaming" and "secure" inclusion and is known for very good signal sensitivity and transmit power -- the last two requirements are influenced by antenna design and orientation.

For door locks, the last device in the communication path has to support only beaming, the secure inclusion is not required.  E.g. my zwave thermostat wakes up a lock by beaming at it, but it does not support any security commands -- it simply re-transmits the original encrypted security command that the controller tries to send to the lock.

[Toddimus]

Can anyone comment on the speed or latency of Z-wave motion sensors (like the Aeon) vs. Insteon motion sensors when run with only programs?  In other words, when you set up a program that turns on a light when triggered by a motion sensor (as opposed to a direct link between an Insteon MS and Insteon Switch), does the Z-wave sensor turn on the light sooner or later than an Insteon motion sensor?

 

For instance, something like this program:

 

IF:

Motion sensor control (turned on)

 

Then:

Turn Insteon switch ON

 

I'm hoping that Z-wave might have less latency than Insteon, since the Z-wave sensor doesn't have to make the "transit" through the network, be processed by a program and then turn on a light.  If Z-wave can be quicker to trigger the program, then the light might turn on more quickly.

 

I plan to buy a Z-wave motion sensor to do this test, but I'd be curious if anyone else has already done this test.

 

Thanks in advance if anyone can either save me the money if it (the Z-wave sensor) is actually no improvement or worse!

[MWareman]

For door locks, the last device in the communication path has to support only beaming, the secure inclusion is not required. E.g. my zwave thermostat wakes up a lock by beaming at it, but it does not support any security commands -- it simply re-transmits the original encrypted security command that the controller tries to send to the lock.

You probably had direct comm then between the lock and ISY.

 

The zwave protocol requires all devices in the path to support security to support a secure path between nodes. Relays have to be security enrolled to participate - otherwise they won't relay secure signals. This is a protocol requirement detailed in the Sigma standards doc.

[Scott847]

Can anyone comment on the speed or latency of Z-wave motion sensors (like the Aeon) vs. Insteon motion sensors when run with only programs?  In other words, when you set up a program that turns on a light when triggered by a motion sensor (as opposed to a direct link between an Insteon MS and Insteon Switch), does the Z-wave sensor turn on the light sooner or later than an Insteon motion sensor?

 

For instance, something like this program:

 

IF:

Motion sensor control (turned on)

 

Then:

Turn Insteon switch ON

 

I'm hoping that Z-wave might have less latency than Insteon, since the Z-wave sensor doesn't have to make the "transit" through the network, be processed by a program and then turn on a light.  If Z-wave can be quicker to trigger the program, then the light might turn on more quickly.

 

I plan to buy a Z-wave motion sensor to do this test, but I'd be curious if anyone else has already done this test.

 

Thanks in advance if anyone can either save me the money if it (the Z-wave sensor) is actually no improvement or worse!

 

I tried timing a Z-Wave Fibaro motion sensor turning on an Aeotec Smart Switch 6 but it's too fast to time with a stop watch. Less than a second, probably around 0.5 seconds.

 

Test program on my ISY 5.0.4:

 

PROGRAM: Motion Sensor

If

        'ZW 021 Binary Sensor' Status is On

 Then

        Set 'Aeotec SS6 ZW-004 On-Off' On

 Else

        Wait  3 minutes 

        Set 'Aeotec SS6 ZW-004 On-Off' Off

 

I don't have an Insteon motion sensor so don't know how that compares.

 

EDIT: For this test I was using a Fibaro sensor, not the MultiSensor 6 but I'm pretty sure the speed is about the same.

[vjk]

You probably had direct comm then between the lock and ISY.

 

The zwave protocol requires all devices in the path to support security to support a secure path between nodes. Relays have to be security enrolled to participate - otherwise they won't relay secure signals. This is a protocol requirement detailed in the Sigma standards doc.

I have both a directly accessible lock and a lock requiring a relay node. Here's an RF trace for an indirect lock with some explanations (node 13 is the controller, node 10 is a thermostat without any security capabilities and node 12 is the lock). The signal strength indicator (RSSI)  provides sanity check for node locations: about -45 is the controller signal (the RF probe is about two feet from the controller), about -77 is the thermostat, about -85 is the lock):

-- Indirect communication:

Trace info:

xxxxxxxx -- Home ID:
13 -- source
12 -- destination
08100a104098801baa4da9f74a0912b6 -- payload
  08100a1040                     -- routing info (x0a/decimal 10 -- the relay node id)
  98801baa4da9f74a0912           -- secure command
  b6 -- checksum
  -46 -- RSSI

(RSSI helps identify the beaming node since the beam command does not contain the source addr)

  
2016-07-26T02:23:52.643059 xxxxxxxx 13 12  08100a104098801baa4da9f74a0912b6  -46  ; controller(13) sends a secure command via node 10 to node 12(lock)
2016-07-26T02:23:52.648007 xxxxxxxx 10 13  88  -77                                ; node 10 acks

node 10 beams at node 12:                                          
2016-07-26T02:23:52.652830 55 12  -76   
2016-07-26T02:23:52.657243 55 12  -78
   
....

2016-07-26T02:23:53.811787 01037408 13 12  08110a104098801baa4da9f74a0912b7  -76 ; node 10 retransmits verbatim the original command to node 12
2016-07-26T02:23:53.818923 00037408 12 13  0b100a5b  -85                         ; node 12 acks to node 13 via node 10                
2016-07-26T02:23:53.825824 01037408 12 13  0b1f0a55  -77                         ; node 10 retransmits the ack to node 13             
2016-07-26T02:23:53.831779 01037408 13 10  88  -46                               ; node 13 ack to node 10                             

Direct communication (node 11 is a lock). As before, RSSI helps  identify nodes (-46 is the controller signal strength, -79 -- locks's RSSI).

-- Direct communication

2016-07-26T08:40:26.938802 55 11  -46 ; Node 13 beams at node 11 (lock)
2016-07-26T08:40:26.943747 55 11  -46

...   

2016-07-26T08:40:28.088692 55 11  -46
2016-07-26T08:40:28.096751 xxxxxxxx 13 11 9880e3c37ee8d7dd62d5cc  -45 ; node 13(controller) sends a command to node 11
2016-07-26T08:40:28.102675 xxxxxxxx 11 13 83  -79                     ; node 11 acks to node 13

[Toddimus]

I tried timing a Z-Wave Fibaro motion sensor turning on an Aeotec Smart Switch 6 but it's too fast to time with a stop watch. Less than a second, probably around 0.5 seconds.

 

Test program on my ISY 5.0.4:

 

PROGRAM: Motion Sensor

If

'ZW 021 Binary Sensor' Status is On

Then

Set 'Aeotec SS6 ZW-004 On-Off' On

Else

Wait 3 minutes

Set 'Aeotec SS6 ZW-004 On-Off' Off

 

I don't have an Insteon motion sensor so don't know how that compares.

 

EDIT: For this test I was using a Fibaro sensor, not the MultiSensor 6 but I'm pretty sure the speed is about the same.

Thanks! How about the timing with zwave sensor turning on an Insteon light? Is it similarly quick?

 

 

Sent from my iPhone using Tapatalk

[KeviNH]

Can anyone comment on the speed or latency of Z-wave motion sensors (like the Aeon) vs. Insteon motion sensors when run with only programs?  In other words, when you set up a program that turns on a light when triggered by a motion sensor (as opposed to a direct link between an Insteon MS and Insteon Switch), does the Z-wave sensor turn on the light sooner or later than an Insteon motion sensor?

Timing between the sensor triggering and the program running for Insteon vs ZWave is pretty much identical, but much slower than having an Insteon sensor acting as a scene controller and directly turning on a light.

 

Thanks! How about the timing with zwave sensor turning on an Insteon light? Is it similarly quick?

Both are equally slow if your baseline is how long it takes for an Insteon sensor as scene controller to turn on an Insteon light as scene responder.

 

If the goal is, for example, to turn a light on when entering a room, anything slower than using scenes is not going to be "wife acceptable".

[Toddimus]

Timing between the sensor triggering and the program running for Insteon vs ZWave is pretty much identical, but much slower than having an Insteon sensor acting as a scene controller and directly turning on a light.

 

Both are equally slow if your baseline is how long it takes for an Insteon sensor as scene controller to turn on an Insteon light as scene responder.

 

If the goal is, for example, to turn a light on when entering a room, anything slower than using scenes is not going to be "wife acceptable".

That's what I figured but was hoping it would be quicker.

 

 

Sent from my iPhone using Tapatalk

[Scott847]

That's what I figured but was hoping it would be quicker.

 

 

Sent from my iPhone using Tapatalk

 

Just to confirm, I tested with a MultiSensor 6 triggering a program to turn on an Insteon ApplianceLinc V2 and it seemed similar, maybe 0.6 or 0.7 seconds. Didn't do any formal wife acceptance testing... I think it would have passed here but she may be more tolerant and no guarantees about other wives!

[Toddimus]

Just to confirm, I tested with a MultiSensor 6 triggering a program to turn on an Insteon ApplianceLinc V2 and it seemed similar, maybe 0.6 or 0.7 seconds. Didn't do any formal wife acceptance testing... I think it would have passed here but she may be more tolerant and no guarantees about other wives!

 

Thanks Scott.  My wife acceptance factor with this HA stuff is finicky at times.  It's kinda like reviews of products... you only hear about it when it isn't working right.  When it's invisible, you know it's doing a good job but you never get the positive accolades when you get it right.  I guess that's my lot in life. 

 

I still might get one of the Zwave sensors to try it out for myself, side by side.  Having extra temperature/humidity sensors wouldn't hurt either.

 

I'll set up a test in a quiet house (i.e. after the toddler and wife go to bed).  I'll do multiple tests and average them together, noting the variation in time.  I want to know this data:

 

Insteon MS triggering Insteon Dimmer (using scene) = XX milliseconds +/- ?? milliseconds

Insteon MS triggering Insteon Dimmer (using program only) = YY milliseconds +/- ?? milliseconds

Zwave MS triggering Insteon Dimmer (using program only) = ZZ milliseconds +/- ?? milliseconds

 

Even if the Zwave and Insteon (program driven) come in close to the same latency, having more deterministic timing from the Zwave might make it worthwhile.  I've noticed that the Insteon MS driven program sometimes takes longer to run, for no apparent reason.  Maybe it's just other Insteon traffic getting in the way?