rccoleman

I can confirm that I don’t get isy994_control events when operating ISY devices from HA or from the ISY admin console, but I suspect that’s as-designed. I’m personally only interested in detecting events that can only be generated at the physical device and not ones that are simply a state change (which is easy to trigger on). I *do* get isy994_control events when operating my ISY devices manually, as expected. I’m using the beta 3.0.0dev15-1 version of the ISY integration from HACS, but I don’t think the behavior is any different with the built-in integration.

When I first installed the HACS version, I had trouble getting it to use PyISY_beta underneath instead of the original PyISY. It’s mentioned properly in the manifest and both versions ended up in the homeassistant container (I’m using Hass.io), but I had to manually copy it into config/deps/... to have it be used. Not sure what was going on there, but maybe it’s biting others as well.

Yeah, PyISY_beta is what HA is now using as long you install the custom component through HACS, and that has all the new goodness. I do think that the revised custom component and the new PyISY are tied together, so I wouldn’t recommend using one without the other. In any case, I’m glad to see ISY integration get some attention.

The conclusion from discussions here is that the ISY responds with 404 when it’s busy or thinks the Insteon network is busy, so I contributed a simple retry mechanism that’s now in PyISY. There were also some serious issues in PyISY that could cause non-deterministic delays (basically not recognizing the response to some commands until the start of the next one), but that’s also fixed in the latest PyISY. It was dormant for a few years and has recently gotten some much-needed TLC, which is good for anyone using PyISY, including HA. Yay open source!

Yes, all automations are in HA, either through YAML automations/scripts or through Python Appdaemon scripts. The only perceptible delays are due to cloud-based services taking longer to respond or the ISY periodically pretending that it doesn’t have certain ISY devices or scenes and returning a 404. Honestly, unpredictable timing of program/device response on the ISY was one of the things that pushed me to experiment with HA and I find HA to be much more predictable. It’s also leaps and bounds easier to debug when strange things do happen. It’s at least as fast as the ISY, but I’m also bringing considerably more processing power. It’s pretty close to instantaneous to respond for triggers and actions that are under its control. I just looked at the resources in use and the active memory was 3.6G for HA and a Plex server together, with a load avg of 0.4 on a 4-core i5. It’s more machine than HA needs, but it was only about $300 all-in for a refurb Lenovo m92p tiny PC form factor.

I'm running HA on a mostly-dedicated I5 with 16GB of RAM and total usage is usually in the 5GB range. While many do run HA on a Pi, I got tired of that really quickly and I can see where you'd run into resource issues. I had NodeLink and 5-6 Polyglot node servers when I started messing around with HA last year and I certainly wasn't up to that number of additional nodes. When I decided that my general direction would be towards HA and every nodeserver that I used had a native analog there, I switched to the HA version and left the Insteon devices and scenes on the ISY. On the plus side, the ISY admin console loads much, much faster now

I've had the same feeling watching the back-and-forth on this thread. The isy994 custom component from HACS and the built-in one before that both worked fine for my fairly extensive Insteon installation that supports all the wall-switches in my house. I still see retries triggered every so often when the ISY erroneously reports "404", but it works after a few seconds. I have removed all nodeservers from my ISY now that I'm controlling all of my third-party devices through HA, so my ISY essentially operating as a glorified Insteon hub may help avoid some hiccups. But my experience is that the ISY994 component and HA itself has been pretty rock-solid for the last 6 months or so.

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.

It looks like it should pick that up properly based on uom="17", which translates into TEMP_FAHRENHEIT, but it may get tripped up somewhere along the way. I had a similar problem with Agave for a long time with a Z-Wave temp sensor, where it showed up as a switch. James fixed it when I gave him a copy of the node definition from the ISY.

Either add this whole thing as-is to configuration.yaml, or add the last line to an existing logger: section: logger: default: info logs: homeassistant.components.isy994: debug But I suspect that the problem is in the device type detection in __init__.py in the isy994 component. There's a lot of code devoted to trying to figure out what each device is. If you want to try to figure it out, you can find the node definition from http://<isyaddress>/rest/nodes and walk through the code in __init__.py to see where it goes wrong. It might be as simple as adding a type, and the first step for that would be to make a copy of the isy994 component directory in config/custom_components and modify as needed. If you do that, you'll need to change the logging line to custom_components.isy994: debug Or you can post the node def here and I can try to help figure it out.

Yep, it’s really annoying, but it does get better as you asymptotically approach nirvana and don’t need to restart as much. Also, take advantage of the ability to runtime reload what you can (automations, scripts, customizations, themes). Hard to say. I’d like to say that the few Z-wave sensors that I have reported correctly as sensors, but I pretty quickly moved all Z-Wave to HA. Unpredictable Z-Wave support on the ISY was one of the main reasons that I investigated HA, and I’ve been quite happy with OZW in HA. It gets a lot of grief (and the author Fishwaldo, specifically), but it works quite well for me. I recommend turning on debug in the isy994 component to see if you can find out what’s wrong. It rediscovers all devices at boot each time. I can copy/paste the lines to enable logging you need them. Are you using 5.0.x on your ISY? It looks like 5.0.x provides more information on node type: def _check_for_node_def(hass: HomeAssistant, node, single_domain: str = None) -> bool: """Check if the node matches the node_def_id for any domains. This is only present on the 5.0 ISY firmware, and is the most reliable way to determine a device's type. """ if not hasattr(node, 'node_def_id') or node.node_def_id is None: # Node doesn't have a node_def (pre 5.0 firmware most likely) return False node_def_id = node.node_def_id domains = SUPPORTED_DOMAINS if not single_domain else [single_domain] for domain in domains: if node_def_id in NODE_FILTERS[domain]['node_def_id']: hass.data[ISY994_NODES][domain].append(node) return True return False

I pretty quickly got tired of the super-long startup time of the RPI, and it was terrible as I was building my system. It might be better once you’re up and running, but I definitely don’t regret the $250 I spent for the tiny, powerful I5-based machine I use for HA (+Plex+UniFi+other stuff). It’s worth considering for the size system you have, and the fact that several new integrations don’t work on the Pi (VSCode, TensorFlow, maybe others) Regardless of the number of devices you have, they’re not all updating status at the same time. You’ll really only tax the system at startup when it does query all devices, so you have to decide how often you expect to do that. I don’t think you’ll have any problem once you’re up and running, even with a Pi. I have ~70-80 Insteon devices and 20-30 Z-Wave devices and it takes about 4 minutes to query everything at startup on my machine, most of it Z-Wave. Someone just found a significant bottleneck in the OZW python wrapper and he’s getting some substantial perf improvement with preliminary changes that push blocking tasks into threads. You can also ignore entire device domains in the ISY integration if you like, but there’s really no downside to just pulling in your whole ISY config via the integration and seeing how it works. You can always just delete the integration if it causes problems. Or you can get yourself a Z-Stick and migrate your Z-wave devices to HA at your own pace and leave the Insteon devices on ISY to eliminate the middleman. Just make sure that you’re using a self-powered hub if you go that way.

It’s instantaneous for me unless it results in flooding the Insteon network from the ISY’s perspective. In that case, it can take a long time or just not work at all. I have a languishing PR here to PyISY that helps my setup tremendously: https://github.com/automicus/PyISY/pull/46 Did you turn on debug for the isy994 component? No need to create a separate custom component for that. If you want to add debug, you can just copy the component directory into the config/custom_components directory and modify it there (create the dir if needed).

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

Yep, that’s it! Hass is addictive. There’s literally new stuff every week or two and it really scratches my developer itch.

Home Assistant is awesome. Setting a variable is easiest done with a REST call, and there’s a great example of a guy doing it from Hass here on the UDI forum (with video!). I can’t find it from my phone, but a Google search should do it.

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 built an extensive Home Assistant system over the past few weeks that controls nearly everything in my house, with the ISY acting as a conduit to my Insteon SwitchLincs and KeypadLincs. I've learned a lot and feel like I have a pretty good handle on how it works (both Python & YAML), so feel free to ask if you have questions, here or via PM. I also have an outstanding pull request for PyISY that retries REST commands that the ISY rejects, making communication from Home Assistant to the ISY much more reliable, especially if you're controlling several devices at once. That pull request seems to have stalled and modifying dependencies in Hass.io is a pain, so I also built equivalent functionality into the ISY994 component that I'm using as a custom component. The pull request for PyISY is here: https://github.com/automicus/PyISY/pull/46. If anyone is interested in the ISY994 component changes, just let me know. Overall, I'm loving Home Assistant. It's super-powerful, development moves really quickly, and it's all open-source, so anyone can debug and fix anything. It's right up my alley. It's also super-fast, partly because it's running on a 3.6GHz I5 in a Lenovo m92p "tiny PC".

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.