Improve Z-Wave response speed?

[rccoleman]

I'm just trying out some Z-Wave plug-in modules (these) and the delay introduced by the roundtrip to the ISY is immediately noticeable compared my original Insteon setup (which was instantaneous using native links).  The sequencing of "on" and "off" for each device is clear if I create a separate scene with only two plug-in modules and turn the scene on and off, while turning each device on or off independently via the admin console is essentially instantaneous.  There are no configuration parameters in these modules and they're not dimmers, so I don't think there's anything that I can do to improve the scene response time.

I started to look at the actual Z-Wave traffic and I wonder if the sequence within the ISY can be optimized.  Here's what the sequence looks like:

Thu 02/07/2019 09:24:12 AM : [ZWAVE-TX ZW048_1] [25/01] Binary Switch Set val=0xFF ACK,AUTO,EXPLORE To=0x30

Thu 02/07/2019 09:24:12 AM : [ZWAVE-TX ZW048_1] [25/02] Binary Switch Get ACK,AUTO,EXPLORE To=0x30

Thu 02/07/2019 09:24:12 AM : [ZWAVE-RX ZW048_1] [25/03] Binary Switch Report val=0xFF ACK,AUTO,EXPLORE From=0x30

Thu 02/07/2019 09:24:12 AM : [ZWAVE-TX ZW031_1] [25/01] Binary Switch Set val=0xFF ACK,AUTO,EXPLORE To=0x1F

Thu 02/07/2019 09:24:13 AM : [ZWAVE-TX ZW031_1] [25/02] Binary Switch Get ACK,AUTO,EXPLORE To=0x1F

Thu 02/07/2019 09:24:13 AM : [ZWAVE-RX ZW031_1] [25/03] Binary Switch Report val=0xFF ACK,AUTO,EXPLORE From=0x1F

Thu 02/07/2019 09:24:13 AM : [D2D EVENT   ] Event [ZW048_1] [sT] [100] uom=78 prec=0

Thu 02/07/2019 09:24:13 AM : [     ZW048_1]       ST 100 (uom=78 prec=0)

Thu 02/07/2019 09:24:13 AM : [D2D-CMP 00F2] STS [ZW048_1] ST op=6 Event(val=100 uom=78 prec=0) != Condition(val=0 uom=78 prec=0) --> true

Thu 02/07/2019 09:24:13 AM : [D2D EVENT   ] Event [ZW031_1] [sT] [100] uom=78 prec=0

Thu 02/07/2019 09:24:13 AM : [     ZW031_1]       ST 100 (uom=78 prec=0)

Thu 02/07/2019 09:24:13 AM : [D2D-CMP 00F2] STS [ZW031_1] ST op=6 Event(val=100 uom=78 prec=0) != Condition(val=0 uom=78 prec=0) --> true

Thu 02/07/2019 09:24:13 AM : [VAR  2   54 ]       1

Thu 02/07/2019 09:24:16 AM : [iNST-TX-I1  ] 02 62 00 00 1D CF 11 00

Thu 02/07/2019 09:24:16 AM : [iNST-ACK    ] 02 62 00.00.1D CF 11 00 06          LTONRR (00)

Thu 02/07/2019 09:24:17 AM : [iNST-TX-I1  ] 02 62 00 00 24 CF 11 00

Thu 02/07/2019 09:24:17 AM : [iNST-ACK    ] 02 62 00.00.24 CF 11 00 06          LTONRR (00)

I believe that the two first two bolded lines are the points at which the ISY tells each switch to turn on, and they do both appear to happen within a second of each other.  Still, it looks like the ISY, after turning on the switch, immediately queries it and waits for a response before moving on to the next switch.  I wonder if the response time could be improved by either moving the status check to the end (after setting all devices in the scene to their new states) or even completely eliminating it.  Or perhaps there something else that I could tweak?  Since these are Z-Wave Plus switches, I think they subsequently report their status themselves in the last two bolded lines, making the manual queries unnecessary.  Maybe the easiest thing to do is to recognize when a device is Z-Wave Plus, know that it will report its own status asynchronously, and skip the query in that case.  The best case would be central scene support, where I believe the Z-Wave devices would operate more like Insteon.

The delay is certainly noticeable in a scene including only two Z-Wave modules, but is more irritating and looks more amateurish as I include more devices.  I have a scene in my living room that includes an Insteon SwitchLinc and 3 plug-in modules, and it takes a few seconds for all the lights to independently turn on.  It adds up.

 

I have a pretty good mesh now, I’ve healed many times, the routes seem reasonable (1-2 hops from the ISY), and controlling the modules individually is fast, so I don’t think there’s anything deficient about my Z-Wave network.

Edited February 7, 2019 by rccoleman

[lilyoyo1]

What is your exact setup in regards to controlling your devices? Is this scene triggered by a program or another device? What's the device? Is the device itself scene capable? The more information we have about your setup the better we can help

[rccoleman]

I set up a new scene just to test this and I ran that experiment by hitting the "On" and "Off" buttons for the scene manually in the admin console.  I tried to make the test as simple as possible.  I linked to the GE/Jasco on/off module in the original post.

Here's the scene.  Both "default" and "command"->"On" seem to do the same thing (as I would expect).

Edited February 8, 2019 by rccoleman

[simplextech]

@rccoleman one thing with Z-Wave to keep in mind is that it's a serial communication.  Even though devices are in a "scene" the communication is serial not broadcast like Insteon devices.

The controller will send the command to the devices one at a time and wait for the ack before moving to the next device (or timeout) whichever is first. 

On Command:

Controller -> Device -> On?

Device -> ACK -> Controller -> Yes/No

Move on to the next device in your "scene". 

Sometimes this happens very quickly and sometimes not so quickly. 

This is actually a reason why I'm investigating Insteon.  I have nearly 100 Z-Wave devices mostly powered and there are still delays in some devices responding and especially in multi-light "events" or "programs".  Just the nature of Z-Wave...

[rccoleman]

Sure, I understand that it's not the same as an Insteon scene, at least not yet.  I was hoping that the "Central Scene" command class would help alleviate some of the delay by allowing more Insteon-like inter-device communication, but now I'm not so sure.  I haven't found a clear enough (at least for me) description of what the possibilities are.

Reading your post and looking at the log again, it looks like the second and third lines (send a "get ACK" and receive the ACK) are part of the protocol and can't be avoided.  I thought the ISY was explicitly checking the status of the device to make sure that the "on" command worked rather than a protocol-required  ACK of the previous command, leading me to wonder if it was really necessary.  It doesn't look like there's much else to do at this point to improve on the delay between commands.  I guess they could collect the ACKs and check all the devices at the end once the scene has ‘executed’  

I think you'll find that Insteon mostly eliminates the delay, and gives the illusion that all lights/devices are hardwired together.  It's disappointing to move to newer technology like Z-Wave and feel like you're going backward.  The biggest downside for me, as I recall, is that Insteon scene commands don't have ACKs (unlike device-to-device commands) and devices will sometimes miss commands due to interference or otherwise.  So they're fast, but can also be unreliable, and you're left trying to find and filter any noise sources or signal suckers.  The alternative is to program each device to turn on in sequence, but then you're back to the Z-Wave model, albeit even slower.

Edited February 8, 2019 by rccoleman

[simplextech]

@rccoleman, there are benefits and draw backs with z-wave as with any of the protocols commonly used.  The "ACK" is part of the protocol and used for validation.  One of the z-wave specifications is ensured message delivery and re-transmission on failures.  This makes the communications more "robust" but has it's drawbacks in speed.  The nature of the communications being serial are also a drawback on speed as there is no "broadcast" mechanism.  The "Central Scene" command class has actually been phased out and is not commonly used anymore and most newer devices don't even support it.  I can go and double check the z-wave specifications but the last I checked and the talk on the z-wave alliance boards that was the case.  Even HomeSeer has mostly phased out the "Central Scene" functionality which many people were using for this type of scenario.

I've read of the draw backs of interference/noise with Insteon but at least it's known and there are mitigation steps.  With Z-Wave it's unfortunately harder to figure out what the cause could be without expensive tools.  A misbehaved z-wave device can wreak havoc on the entire mesh and trying to isolate and find it without the proper tools can be maddening!!!  For lighting (personally) I have found Z-wave to be less than stellar for wanting the lights to respond quickly and dim/brighten or fade nicely.  I've had Lutron, Z-Wave, Zigbee and now insteon in my home and test environment and as it stands now I'm still in the middle of rolling out more Insteon for comparison.  However In my very early testing/comparison of things for lighting I would place Insteon and Lutron on the same playing field.  May just be my opinion but I'm coming from a mostly Z-Wave background and I'm liking Insteon more and more each day for lighting and for motion sensors and contact (door/window) sensors.  I just replaced all of my door sensors with Insteon because they respond much faster and more reliably than the Z-Wave sensors I had.  

All in all I think I will ultimately always have a mixed environment but for now I think Insteon will have my lighting and Z-Wave will be mostly plugin devices and energy monitoring devices and some exotic devices only available in z-wave.  I think my switches/dimmers will all be converted to Insteon along with the motion sensors controlling the lighting.

[rccoleman]

Thanks very much for that insight. I feel like there’s a slow migration away from Insteon and to Z-Wave, so it’s interesting (and a little refreshing) to see someone go in the opposite direction for good reason. As you might expect, there are some heated discussions here with proponents on both sides. Agreed about the ability to filter interference for Insteon, but I find it frustrating to try to methodically track down marginally dodgy communications. Still, at least it’s possible.

 

Regarding central scene, it looks like I may be thinking more about associations. This describes what I’m really looking for, where devices talk directly to each other: https://www.vesternet.com/knowledgebase/technical/kb-27/. As you point out, the lack of broadcast is really the problem.

 

When you mention Lutron, are you talking about RadioRA2? A colleague had that installed in his house and it sounds great, but the anti-DIY aspect turns me off.

 

[lilyoyo1]

17 hours ago, simplextech said:

@rccoleman, there are benefits and draw backs with z-wave as with any of the protocols commonly used.  The "ACK" is part of the protocol and used for validation.  One of the z-wave specifications is ensured message delivery and re-transmission on failures.  This makes the communications more "robust" but has it's drawbacks in speed.  The nature of the communications being serial are also a drawback on speed as there is no "broadcast" mechanism.  The "Central Scene" command class has actually been phased out and is not commonly used anymore and most newer devices don't even support it.  I can go and double check the z-wave specifications but the last I checked and the talk on the z-wave alliance boards that was the case.  Even HomeSeer has mostly phased out the "Central Scene" functionality which many people were using for this type of scenario.

I've read of the draw backs of interference/noise with Insteon but at least it's known and there are mitigation steps.  With Z-Wave it's unfortunately harder to figure out what the cause could be without expensive tools.  A misbehaved z-wave device can wreak havoc on the entire mesh and trying to isolate and find it without the proper tools can be maddening!!!  For lighting (personally) I have found Z-wave to be less than stellar for wanting the lights to respond quickly and dim/brighten or fade nicely.  I've had Lutron, Z-Wave, Zigbee and now insteon in my home and test environment and as it stands now I'm still in the middle of rolling out more Insteon for comparison.  However In my very early testing/comparison of things for lighting I would place Insteon and Lutron on the same playing field.  May just be my opinion but I'm coming from a mostly Z-Wave background and I'm liking Insteon more and more each day for lighting and for motion sensors and contact (door/window) sensors.  I just replaced all of my door sensors with Insteon because they respond much faster and more reliably than the Z-Wave sensors I had.  

All in all I think I will ultimately always have a mixed environment but for now I think Insteon will have my lighting and Z-Wave will be mostly plugin devices and energy monitoring devices and some exotic devices only available in z-wave.  I think my switches/dimmers will all be converted to Insteon along with the motion sensors controlling the lighting.

I agree with what you've said. Zwave has come a long way over the years for lighting but they still fall short at what insteon excels at. All of my switches are insteon as I like the speed and functionality of them over zwave counterparts. I do have zwave outlets (insteon's as well) for repeating purposes. I use zwave door locks and sensors (I prefer them to insteon). 

[simplextech]

21 hours ago, rccoleman said:

Regarding central scene, it looks like I may be thinking more about associations. This describes what I’m really looking for, where devices talk directly to each other: https://www.vesternet.com/knowledgebase/technical/kb-27/. As you point out, the lack of broadcast is really the problem.

Yes associations is another topic.  However the "gotcha" here is that not all devices support the full capability.  All devices support the minimal of 1 association which is the controller.  To benefit from this the end devices must also support multiple associations.  This is device specific and not all devices support it which is really a downside that you have to be careful about devices and not just assume they are all implementing the full spectrum of z-wave capabilities.

21 hours ago, rccoleman said:

When you mention Lutron, are you talking about RadioRA2? A colleague had that installed in his house and it sounds great, but the anti-DIY aspect turns me off.

All Lutron systems use the same radio technology.  So whether it be Caseta Standard (buy at stores, Best buy, Home Depot, Lowe's etc etc) or Caseta Pro which can be integrated with systems or up the spectrum to the RA2 or HomeWorks systems.  They are great systems.  As an individual you can get "certified" for install/setup of any of the systems.  The RA2 classes I think are still free even.  Getting up to the HomeWorks (high end) systems costs though.  But if you can afford to deploy a system like HomeWorks then the cost of setup/integration would look like pennies on the final bill.  I've actually been considering a Polyglot for RA2 compatible systems as I still have my Caseta Pro bridge and the Pico remotes are awesome and dirt cheap compared to Insteon remotes.

 

21 hours ago, rccoleman said:

As you might expect, there are some heated discussions here with proponents on both sides.

I'm sure there are.  I can say I'm mostly neutral but with a background in Z-Wave (Z-Wave Alliance member) and some exposure to Zigbee which is good but still not prime time for "general home automation" uses as it's still too fragmented even with the ZHA spec.  Z-Wave really isn't much better in regards to the fragmentation but it has gotten better and controllers have gotten better at overcoming some of the problems that mostly originate with the devices and the lack of a "true" enforcement of the standards.

[rccoleman]

I bought a couple of Homeseer WS200+ switches to experiment with and added them to a scene with two GE/Jasco on/off modules, making the switch a controller and the modules "Z-Wave Association".  The switch didn't have any obvious effect on the modules, but I need to look deeper into the traffic.  There was a post asking if the ISY would allow the creation of associations beyond group 1 to support virtual circuits and the answer was "no", so I suspect that it may not be that useful right now.  I'm sure what the purpose of the "Z-Wave Association" option is right now, if not for that.

That's interesting about Lutron RF.  I bought a Caseta starter kit when I was initially researching HA systems and sold it when I wasn't thrilled with the switch design and device options.  RA2 had more and more traditional devices, but I didn't want to go through a distributor/installer.  My whole house is now outfitted with 60+ Insteon SwitchLincs, but I'll keep that in mind if I move.  I also like their remotes better than the Insteon remotes.

It seems like even Insteon has trouble sticking to their own standard and product specs based on the challenges that UDI has had working with the new motion sensor, but the fragmentation, rapid evoluution, and regular EOLing of devices worries me about Z-Wave.  Building a whole HA system is expensive and time consuming and it's not at all the same as just swapping out a Blu Ray player when something new comes along.  I like the Switchlincs that I have now and it doesn't sound like the Z-Wave Plus equivalents really buy me anything at this point.

 

[simplextech]

8 hours ago, rccoleman said:

I bought a Caseta starter kit when I was initially researching HA systems and sold it when I wasn't thrilled with the switch design and device options.

The Caseta lineup of products is very entry level.  There's the Caseta Pro bridge which has the integration option but again the available devices is very limited.  Stepping into the RA2 product family opens up a lot of possibilities but at a much higher entry cost.  I think the appeal in general HA is around the Caseta Pro of having the fast lighting and Pico remotes.  Lutron just announced a fan controller for the Caseta line which I have limited details on, however to me it's not worth changing out a Fanlinc + KPL for the same functionality.

I think now is an interesting turning point with Insteon.  With the MSII I think they are trying to evolve into more than just powered devices and remotes. 

[rccoleman]

I spent a little more time with the "Z-Wave Association" option and it's working now.  It feels like it's about twice as fast for on/off as a standard scene, but I think it's still a little short of Insteon.  Here's what the activity looks like (off and then on):

Quote

Sat 02/09/2019 09:18:42 AM : [ZWAVE-RX ZW054_1] [20/01] Basic Set val=0x00 ACK,AUTO,EXPLORE From=0x36
Sat 02/09/2019 09:18:42 AM : [ZWAVE-RX ZW054_1] [5B/03] Central Scene Notify key=2 act=0 (Press) seq=58 slow=T ACK,AUTO,EXPLORE From=0x36
Sat 02/09/2019 09:18:42 AM : [D2D EVENT   ] Event [ZW054_201] [DON] [0] uom=0 prec=-1
Sat 02/09/2019 09:18:42 AM : [   ZW054_201]      DON   0
Sat 02/09/2019 09:18:42 AM : [ZWAVE-RX ZW054_1] [25/03] Binary Switch Report val=0x00 ACK,AUTO,EXPLORE From=0x36
Sat 02/09/2019 09:18:43 AM : [D2D EVENT   ] Event [ZW054_1] [ST] [0] uom=78 prec=0
Sat 02/09/2019 09:18:43 AM : [     ZW054_1]       ST   0 (uom=78 prec=0)

Sat 02/09/2019 09:19:03 AM : [ZWAVE-RX ZW054_1] [20/01] Basic Set val=0xFF ACK,AUTO,EXPLORE From=0x36
Sat 02/09/2019 09:19:04 AM : [ZWAVE-RX ZW054_1] [5B/03] Central Scene Notify key=1 act=0 (Press) seq=59 slow=T ACK,AUTO,EXPLORE From=0x36
Sat 02/09/2019 09:19:05 AM : [D2D EVENT   ] Event [ZW054_201] [DON] [0] uom=0 prec=-1
Sat 02/09/2019 09:19:05 AM : [   ZW054_201]      DON   0
Sat 02/09/2019 09:19:05 AM : [ZWAVE-RX ZW054_1] [25/03] Binary Switch Report val=0xFF ACK,AUTO,EXPLORE From=0x36
Sat 02/09/2019 09:19:05 AM : [D2D EVENT   ] Event [ZW054_1] [ST] [100] uom=78 prec=0
Sat 02/09/2019 09:19:05 AM : [     ZW054_1]       ST 100 (uom=78 prec=0)

Interestingly, when I physically operate the switch there's no report from either of the controlled modules and the ISY doesn't reflect the state change of the modules.  It's all about the switch, and the switch handles all communication with the modules.  It looks like I'd have to poll the modules themselves to refresh their status in the ISY.  It only seems to work when I physically operate the switch, and I can't create associations between the ISY and modules (only the switch, when added as a controller in a scene).  Oddly, it also creates a new node in the ISY called "Scene Button 1" that seems to operate the modules sometimes, but it behaves strangely and I haven't figured it out yet.

It's promising, but I think we'd need the following to make it truly useful:

• Automated status updates for responders when the controller reports a state change.  If the switch reports that it turned on or off along with a central scene notification, change the internal state of all responders
• Allow the user to create associations between the ISY and devices as part of the scene definition.  The first image shows what you get when you modify the responders for a controller (the switch), and the second image shows what you get when you try to modify the members of the scene from the ISY scene definition.  For Insteon devices, the ISY scene definition basically acts as a controller for everything in the scene, and it seems like you should be able to create an association with Z-Wave modules in the scene.

 

 

Edited February 9, 2019 by rccoleman

[simplextech]

19 minutes ago, rccoleman said:

Automated status updates for responders when the controller reports a state change.  If the switch reports that it turned on or off along with a central scene notification, change the internal state of all responders

This is what you will find advertised as "Instant Status" from various z-wave switches/devices.  HomeSeer switches have this as do some others.  Lutron held a patent for years (expired now) that caused z-wave manufacturers to implement a "work around" that really never worked well.  Most older z-wave switches do require polling to update the controller.

[rccoleman]

Yes, I'm aware of the patent issues in the past around "instant status".  I believe that all these devices already support "instant status" (Homeseer WS200+ and 2 GE/Jasco Z-Wave Plus Enbrighten modules), and that's what I had in mind when I started this thread.  I think I can see the modules report their status unprovoked when I operate them from the ISY through a scene (see the log in the first post), but it doesn't seem to work if they're being controlled via an association.  Perhaps they just report their status back to device that sent the command, and if that happened entirely within the switch via associations, the ISY won't see the state change?

Here's a log when I operate the module directly.  It does support "instant status":

Quote

Sat 02/09/2019 10:30:35 AM : [ZWAVE-RX ZW031_1] [25/03] Binary Switch Report val=0xFF ACK,AUTO,EXPLORE From=0x1F
Sat 02/09/2019 10:30:35 AM : [ZWAVE-RX ZW031_1] [20/01] Basic Set val=0xFF ACK,AUTO,EXPLORE From=0x1F
Sat 02/09/2019 10:30:35 AM : [ZWAVE-RX ZW031_1] [25/03] Binary Switch Report val=0x00 ACK,AUTO,EXPLORE From=0x1F
Sat 02/09/2019 10:30:35 AM : [D2D EVENT   ] Event [ZW031_1] [ST] [0] uom=78 prec=0
Sat 02/09/2019 10:30:35 AM : [     ZW031_1]       ST   0 (uom=78 prec=0)
Sat 02/09/2019 10:30:35 AM : [D2D-CMP 00F2] STS [ZW031_1] ST op=6 Event(val=0 uom=78 prec=0) != Condition(val=0 uom=78 prec=0) --> false
Sat 02/09/2019 10:30:35 AM : [ZWAVE-RX ZW031_1] [20/01] Basic Set val=0x00 ACK,AUTO,EXPLORE From=0x1F

 

Edited February 9, 2019 by rccoleman

[simplextech]

40 minutes ago, rccoleman said:

Perhaps they just report their status back to device that sent the command, and if that happened entirely within the switch via associations, the ISY won't see the state change?

That is the way associations work.  Device -> Device without any controller involved.  However I had thought at least for the HS switches they would still report back their status (on/off/level) even if from association.... interesting.

[rccoleman]

7 minutes ago, simplextech said:

That is the way associations work.  Device -> Device without any controller involved.  However I had thought at least for the HS switches they would still report back their status (on/off/level) even if from association.... interesting.

The switch does report the status change to the ISY (see the log from a couple of posts up), but the modules that the switch controls via association don't.  If I operate the modules directly, they do report status without querying.

[simplextech]

11 minutes ago, rccoleman said:

The switch does report the status change to the ISY (see the log from a couple of posts up), but the modules that the switch controls via association don't.  If I operate the modules directly, they do report status without querying.

Log data doesn't tell me which is which... so the controller is the HS switch?  The responders are the Jasco/GE?  That makes sense as the Jasco/GE DO NOT provide real instant status.

There may be something else in play with the associated devices as well.  I have some HS switches and a HS WD-200+ so I may play around with them and see what I get as well as pairing with a GE switch and see if they results are different.  I may not get to that today though as I have a garage door to repair and weekend chores

 

[rccoleman]

8 minutes ago, simplextech said:

Log data doesn't tell me which is which... so the controller is the HS switch?  The responders are the Jasco/GE?  That makes sense as the Jasco/GE DO NOT provide real instant status.

There may be something else in play with the associated devices as well.  I have some HS switches and a HS WD-200+ so I may play around with them and see what I get as well as pairing with a GE switch and see if they results are different.  I may not get to that today though as I have a garage door to repair and weekend chores

 

Yes, the HS switch is the controller (ZW054) and the GE/Jasco modules (ZW031 & ZW048) are responders.  Here's what happens when I hit the button on one of the GE/Jasco modules (ZW031, from a few posts up):

Quote

Sat 02/09/2019 10:30:35 AM : [ZWAVE-RX ZW031_1] [25/03] Binary Switch Report val=0xFF ACK,AUTO,EXPLORE From=0x1F
Sat 02/09/2019 10:30:35 AM : [ZWAVE-RX ZW031_1] [20/01] Basic Set val=0xFF ACK,AUTO,EXPLORE From=0x1F
Sat 02/09/2019 10:30:35 AM : [ZWAVE-RX ZW031_1] [25/03] Binary Switch Report val=0x00 ACK,AUTO,EXPLORE From=0x1F
Sat 02/09/2019 10:30:35 AM : [D2D EVENT   ] Event [ZW031_1] [ST] [0] uom=78 prec=0
Sat 02/09/2019 10:30:35 AM : [     ZW031_1]       ST   0 (uom=78 prec=0)
Sat 02/09/2019 10:30:35 AM : [D2D-CMP 00F2] STS [ZW031_1] ST op=6 Event(val=0 uom=78 prec=0) != Condition(val=0 uom=78 prec=0) --> false
Sat 02/09/2019 10:30:35 AM : [ZWAVE-RX ZW031_1] [20/01] Basic Set val=0x00 ACK,AUTO,EXPLORE From=0x1F

Isn't that "instant status"?  There's no associated query, and comments on the web seem to indicate that they do support instant status.

Edited February 9, 2019 by rccoleman

[simplextech]

Newer GE may... historically they did not and used a work around from the controller stand point.  I would expect newer switches/dimmers to support it now that the patent is expired but there's still lots of other reports from other controllers that use work arounds for it.  Of course those may be issues with older end devices being used... I dunno...

I realized that I've not setup any z-wave associations with ISY... so I'm going to have to figure that out..   I've been spending my time learning about this new Insteon world and not mucking too much with the z-wave switches I've included.

 

[rccoleman]

Yeah, these are the newest models. Association support in the ISY seems to be pretty limited compared to what I read about in other controllers. It seems like UDI is still focusing on basic functionality before opening up ‘expert mode’ options. 

[simplextech]

Just now, rccoleman said:

Yeah, these are the newest models. Association support in the ISY seems to be pretty limited compared to what I read about in other controllers. It seems like UDI is still focusing on basic functionality before opening up ‘expert mode’ options. 

In initial playing I saw the change to z-wave association and after update I get no options for what function to associate... hmm... I'll play around more later.  I think you're probably right about UDI focusing on getting the basics completed before extending themselves too much into the more advanced z-wave capabilities.  

[rccoleman]

I think it’ll just follow whatever the on/off state of the controller, with no way to change the command that’s sent. Maybe that’s just a limitation of the UI, but it’s also how I would normally expect to use an association between devices. 

[rccoleman]

I'm still investigating (I have a few new Z-Wave Plus motion sensors coming today), but wanted to see if any of the improvements that I mentioned earlier (this post) are planned.  

Quote

It's promising, but I think we'd need the following to make it truly useful:

• Automated status updates for responders when the controller reports a state change.  If the switch reports that it turned on or off along with a central scene notification, change the internal state of all responders
• Allow the user to create associations between the ISY and devices as part of the scene definition.  The first image shows what you get when you modify the responders for a controller (the switch), and the second image shows what you get when you try to modify the members of the scene from the ISY scene definition.  For Insteon devices, the ISY scene definition basically acts as a controller for everything in the scene, and it seems like you should be able to create an association with Z-Wave modules in the scene.

@Chris Jahn, @Michel Kohanim

[simplextech]

I'm going to piggy back on this thread a bit....

I posted another thread about this but maybe @rccoleman you would have some ideas on this or perhaps @Michel Kohanim might have some thoughts.

I have a program to turn on light switches when any of a group of doors are opened.  Originally I had z-wave open/close sensors and z-wave switches in my previous system.  I then changed out the open/close sensors to Insteon and things worked well and about the same speed I would say it was actually faster.  Yesterday I changed out the switches to Insteon switches and I swear the speed of the program is now much slower in execution.  Is this a speed issue of Insteon?

I then created a scene with the door sensors as the controllers and that response is instant which is awesome.  But it seems in a scene the lights also go off when the door is closed which is not what I want.  So a program is what I have to use but the speed just seems very slow.... thoughts?  Ideas?

[larryllix]

I'm going to piggy back on this thread a bit....
I posted another thread about this but maybe [mention=7541]rccoleman[/mention] you would have some ideas on this or perhaps [mention=2]Michel Kohanim[/mention] might have some thoughts.
I have a program to turn on light switches when any of a group of doors are opened.  Originally I had z-wave open/close sensors and z-wave switches in my previous system.  I then changed out the open/close sensors to Insteon and things worked well and about the same speed I would say it was actually faster.  Yesterday I changed out the switches to Insteon switches and I swear the speed of the program is now much slower in execution.  Is this a speed issue of Insteon?
I then created a scene with the door sensors as the controllers and that response is instant which is awesome.  But it seems in a scene the lights also go off when the door is closed which is not what I want.  So a program is what I have to use but the speed just seems very slow.... thoughts?  Ideas?

Different protocols tie up different hardware.

Logically, if a trigger comes in on the zwave i/o and goes out on the Insteon port it should be faster.

It would be interesting to hear what happens when a loop flashing an Insteon device is running to swamp the Insteon port, and time the same test zwave trigger/ Insteon out.

I know one thing The ISY CPU has no lack of horsepower for the measly HA job.

Sent from my SM-G930W8 using Tapatalk