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.