rccoleman

Yes, I understand that Insteon and Z-Wave are different protocols. Please ignore Insteon for now. Creating an association between a Z-Wave switch and other Z-Wave modules improves the speed at which those devices respond compared to controlling all of them individually from the ISY without associations. It seemed almost twice as fast, and there was less variation in the timing, especially when triggering multiple lights in a room. I don’t know how much autonomy the Z-Wave board in the ISY has, but I wonder if an association can be made between the Z-Wave board in the ISY and other Z-Wave devices, allowing the communication to bypass the ISY firmware and maybe improve the performance. Perhaps it has no autonomy and all Z-Wave communication involves the ISY firmware, even communications within an association group, but that’s why I’m asking here. As it is, there’s sometimes a delay of a second or more when turning on two lights in the same room via an ISY scene and I’m looking for some way to improve that.

Maybe at least the second one? Can we create associations between the ISY and other responders as we can with Z-Wave devices within a scene? I think that would help improve performance, especially when an Insteon device controls a set of Z-Wave devices. That’s a very common scenario in my house.

UDI already sells a 500 Series Z-Wave Plus board for the ISY. In fact, I think it’s the only one you can get now. You do have to use the beta 5.0.14 ISY firmware with it.

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. @Chris Jahn, @Michel Kohanim

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.

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.

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): Isn't that "instant status"? There's no associated query, and comments on the web seem to indicate that they do support instant status.

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.

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":

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): 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.

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.

Looks like it worked for me last night and this morning. Are you going through the portal? Maybe try the URL in a browser.

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.

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.

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).

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: 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.

This sounds a lot like the issue I reported back in 5.0.13, but with a simpler setup: I added a few new Z-Wave devices tonight and watched the ISY freeze and then rapidly process all of the backed events several times.

I mentioned it in the 5.0.14 thread, but I've had good luck just copying the file from an old backup onto the SD card. I couldn't back up my ISY because of a 0-length .REC file that had apparently become corrupt and copying a good version fixed it. Once you do that and have a current backup, I'd switch to a new SD card and restore that backup.

I tried a couple of different Estimote models and found them to be completely unreliable for location. I have them in a bag for the next electronics recycling event. They’re really sold as a dev kit for building a more complete solution, so they don’t really have a support plan for consumers.

The Locative iOS app with its built-in geofence + notification through the ISY portal has been working so well for me that I don't even think about it anymore. It just works, even though the app is no longer supported. It sounds like the main differences for your solution are: You can use some other hardware that may provide more accurate geofencing or quicker reporting. The effectiveness of phone geofencing is somewhat related to the quality of the app (it'll fail if it crashes in the background), so I suppose that I can see the value in using different hardware if you can't get what you need from the phone in your pocket. You host servers that serve as an intermediary/translator between the GPS/sensor device and the HA system (such as the ISY). From the perspective of the ISY portal, which already supports direct URL calls to change states, I don't really understand the value that offers beyond just having the device talk directly to the endpoint (ISY/ISY portal). Locative allows the user to specify a URL to call when crossing the boundary, and it sounds like you assume that any compatible device has a similar capability?

This is interesting. So without any IR hardware, I could just create fake Hue bulbs and use a Hue device on the Harmony to control them? And then trigger programs based on state transitions?

Here's my Query All program: Query All - [ID 00A0][Parent 0001] If Time is 3:00:00AM Then Set 'ISY' Query Else - No Actions - (To add one, press 'Action') Factory Query Program I renamed the top of my node tree to "ISY", but I think it starts as "My Devices" or something like that.

I think he's talking about the program that runs every morning at 3am or so to query devices. The "query" command stopped working somewhere in 5.0.13 and was fixed in 5.0.14, so I wonder if that somehow caused the program to disappear. Like you said, it's easy to replace.

It would be awesome if it were possible to trigger on button presses using the Harmony Hub node server. Right now, the only hooks are commands to the hub or triggering on starting or ending an activity.

Ah, my apologies. I see the keypad and function keys at the bottom. I’ll have to try the arm/bypass thing when I get home.