rccoleman

On the web. Polls don’t work in Tapatalk, if you’re using that. You can use the web view in Tapatalk, though. Same issue as BrianH, BTW.

That's not a big deal - lots of components say that and it really doesn't matter once everything is up and running. I've spent a lot of time poking around in the isy994 component and there's really not a lot of fat there. If it comes from the ISY quickly, you'll get it quickly in Home Assistant. One of the things that has pushed me away from the ISY were weird, unexplained delays in processing device state changes, but that was mostly with local devices and I doubt that it's affecting your use case. You can monitor the ISY side by opening the event viewer, setting it to level 3, and correlating the event viewer content with the error log, which will show the subscription updates to Home Assistant.

You can't. It only connects to the ISY, so you need to use the ISY as a relay to get events from the ISY Portal into Home Assistant. The only way that you can eliminate the ISY from the communication path between Alexa/GH and Home Assistant is by using Nabu Casa, the cloud service for Home Assistant, instead of the ISY portal. If I understand correctly, you're using voice commands via Alexa/GH to control ISY devices/programs/variables/etc exposed via the ISY Portal, and you want those changes to be reflected in Home Assistant? I found that device state changes like on/off were reflected very quickly in Home Assistant via the isy994 component. Instantly, really. And then you can trigger automations from those state changes in Home Assistant if you like. If you're using Alexa/GH to control an ISY program, you can use a REST command in an ISY network resource to a Home Assistant webhook to get that info into HA. Again, I've found that to be very fast. I recommend turning on debug in the isy994 component in Home Assistant to see what might be slowing it down. You can do that by adding this to configuration.yaml: logger: default: info logs: homeassistant.components.isy994: debug The only issue that I've seen with ISY<->Home Assistant communications is that REST calls into the ISY to control scenes and devices often fail with 404 when many are sent quickly, and that results in delayed or completely missed commands to the ISY. I have an outstanding pull request to PyISY that adds retries to work around that and it's eliminated the uncertainty out of HA->ISY communication. I think it'll only be a problem when controlling Insteon devices because apparently it's an indication that the ISY thinks that the Insteon network is overloaded.

Like what? Home/Away presence? Polyglot cloud? You can use webhooks or the "custom devices" described here to get data from the ISY into Home Assistant or trigger automations. For Alexa, I created programs that run and make REST calls to webhooks in Home Assistant. If you're looking for something new to be exposed, maybe post here or get in touch with OverloadUT here or over there. If you're bought into the Home Assistant ecosystem, Nabu Casa offers much of the same functionality + supports the HA project monetarily. I've moved everything over and have no complaints.

You probably missed the trailing " 1" in the third one. This works for me: http://isy994/rest/nodes/3C%20EB%20EC%201/cmd/DON

Locative is still in the iPhone app store, and it was even updated for the iPhone X screen and misc bugfixes after it was declared "not supported". It still works fine and I think it's still the best of the bunch, so I wouldn't dissuade folks from trying it.

I've been playing with Home Assistant (hass.io) using an Aeotec Z-Stick 5 for a couple of days now and I'm seeing some really positive results. Even without setting up associations, turning Z-Wave devices on and off is much, much faster than going through the ISY. It's about as fast as Insteon, and I'm just controlling two GE/Jasco plugin modules sequentially in a set of HA "automations". With a SwitchLinc controlling two lights and two GE/Jasco "Enbrighten" Z-Wave Plus plugin modules, all of the lights go on and off almost simultaneously when I use the SwitchLinc manually, when I use either of two RemoteLincs, or when I turn a scene on or off in the ISY. Much of this is made possible with the built-in ISY support in HA that exposes the ISY devices and scenes directly in HA, making it easy to detect scene activation or manually flipping switches that the ISY controls. The only thing I'm missing is seeing the status of the HA-controlled Z-Wave devices in the ISY, but I can do that via REST & variables fairly easily. A Polyglot node server would be an even better way to expose HA entities to the ISY. At least for now, I'm finding Home Assistant to be much less user-friendly to program than the ISY, and getting the syntax and names/types of entity IDs right is tedious at best. There are ways to improve this by using the Configurator and Node Red, but it's far behind the ISY admin console in terms of usability. It feels very "fiddly" for lack of a better term, and some of it is due to the free-form text entry of HA vs. drop-down list UI of the ISY. It's much faster to edit in HA, but also much easier to get something wrong. At this point, I don't intend to move any significant functionality from the ISY to HA, but instead to use it where Z-Wave performance is important and to experiment. This obviously adds a whole separate component to my home automation system that needs to be maintained and could fail, so it's not for everyone. I could also just go back to Insteon plug-in modules to get the instant control that I'm looking for, but I've gotten tired of scenes randomly not working and arduous process of identifying and filtering interference. It worked properly most of the time, but the random failures were frustrating. I started using HA on an RPI3 and found it to be very, very slow. It's much better in a Virtualbox VM on my always-on Mac Mini, and not too hard to set up. I first tried native MacOS and Docker installations on the same Mac Mini and ran into problems both times, so I recommend going straight to a VM if you're using a Mac. Virtualbox is free and works fine. Edit: A few more thoughts: With the ISY managing some Z-Wave devices and HA managing others, I basically need to maintain two different Z-Wave networks, each with a solid mesh. As I pull line-powered Z-Wave devices away from the ISY, I'm degrading the ISY mesh to some degree. My HA Z-Wave network is currently only Z-Wave Plus, which technically means that it should be able to run twice as fast as the other network that includes regular Z-Wave locks a couple of motion sensors. I wonder if that's somehow contributing to the boost in performance that I'm seeing. I can swap out all of the motion sensors, but upgrading all three locks to new Z-Wave Plus versions would require several $100 that I'd prefer not to spend.

Nothing has come of it, or likely will. Smarthome would need to support UDI with chips and documentation and they've refused to do so.

I’m considering setting up a HomeAssistant test environment specifically for that. It still would be helpful to know what UDI is planning to do here. The last post that I could find from Michel said that there were no plans to support advanced association editing or to stop the ISY from destroying associations created elsewhere. The thread just ended at that point, and I hope that’s changed. Maybe I’ll actually like HomeAssistant, but I’m not replacing my Insteon switches and will still need something to tie the two technologies together.

The other problem that I’ve seen with associations is that they only seem to work if you manually control the device, at least if I try to control an associated device from the ISY. I suppose that makes sense because you’re letting the devices talk to each other without the intervention of the hub, but that also makes it unsuitable for programming. I’m hoping that it’s a matter of sending on/off/etc *to* the association group in the associated device, or something like that, in order to have it work remotely. And the associated devices don’t report the status change, regardless of their being Z-Wave plus and supporting instant status, presumably also because they’re communicating independent of the hub, but I could work around that. I poked around on the web and found some discussion about associating the responding devices, allowing you to turn one on and have the others come on automatically and presumably faster. That’s sounds intriguing, and I can create an association between two on/off modules in the ISY with one as a controller, but turning on one via the ISY or locally doesn’t affect the other linked device. I don’t know whether that’s a limitation of the device, protocol, or how the ISY creates associations, but I saw that Chris mentioned that there are some issues with associations in 5.0.14 that perhaps are related. As I mentioned above, I *am* able to get a Homeseer switch to directly control two other modules via associations created in the ISY, so they do work sometimes.

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