fahrer16

@PinchRoller, thanks for that additional Info, I always enjoy learning something new! The load in this case was a fluorescent light and I'm getting some mixed results googling how their inrush current would compare to LED and incandescent. It's walk-in closet, so probably a lot of on/off events for that switch with relatively short durations being on. This triggered me to resurrect an earlier search I had started for a suitable Insteon replacement. As part of that I took the training for Lutron RA3 and got a quote for the required parts. As much as I'd love to make that switch I don't think I can stomach the cost to replace my 140 insteon devices 💸

Thanks, guys. These devices are from 2019-2021, a little while before they went out of business, I think. I've been a big Insteon fan but I wonder if some of these issues are related to them cranking stuff through while dealing with supply chain issues and declining business. I've tried various dimmable LED bulbs based on some other forums on here. The Phillips bulbs seem the best, but still some flickering every now and then, even when the level is set to 100%. I was taking a closer look at the circuit board of that failed switch, and it looks like power is always supplied to the relay. If the relay's contacts are welded closed, pulling the air gap won't do anything to cut the power. Not the greatest from a safety standpoint, but maybe they did it that way because it would have been a lot of current to put through the air gap switch. 🤷‍♂️ Maybe I'll pick up a couple of i3 switches to give Insteon one last shot...

My wife told me yesterday that she couldn't turn off our closet light, which is driven by an Insteon SwitchLinc (2477S). I took a look and the the standard click of the relay could be heard along with the lights on the front behaving normally when operating the switch, except the load stayed on. I then pulled out the air gap so I could cut power to the light, which cut power to the switch itself, but the load still stayed on! The next day I pulled the switch out, and after replacing it with a spare, I did some troubleshooting and with the switch on the bench not plugged into anything, there was still continuity between the line and the load wires. I wedged a piece of plastic between the two pieces of the air gap switch and there was still continuity between the wires. I've also been a bit annoyed by my keypads, and some switches, making a lot of high-pitched humming noises. It's very noticeable because the pitch changes along with any insteon traffic. A lot of my LED bulbs connected to Insteon dimmers also blink on Insteon traffic. Due to those buzzing and blinking issues, I had been toying with moving away from Insteon. That issue with the switch has made be think about it more seriously now from a safety perspective. I guess I'm wondering if anyone else is having these issues and am I just being too picky or overreacting?

@Jimbo.Automates, I wrote the original node server but I've scaled back to a more basic eISY system and don't use them anymore. It would be great if you'd like to resurrect that plugin and give it some much-needed attention!

I no longer run any node servers or have Blue Iris, unfortunately, so I have no way to test. If you're comfortable going in and making a tweak to your local blue-iris-poly.py file, I think adding "self.connect()" to line 121 might do the trick. That's the section that sets the connection status to "disconnected", so adding that would have it try to reconnect.

I moved my ZMatter dongle from my Polisy over to Home Assistant and it worked great with the Z-Wave JS integration. I even brought it over without having to re-link my Z-Wave devices by finding that all of the keys needed by the Z-Wave JS integration are stored in the IoX backup files. All of my devices showed up and everything worked great. I didn't try out the Zigbee or Matter functionality though. I also moved by Insteon PLM over and set up the Insteon integration in HA. All in all everything works that way but after spending a day doing that and giving it a chance, I wound up putting all back and buying a new eisy because it does a much better job integrating things than HA alone, at least with merging Insteon and Z-Wave. It just wasn't right without the excellent scene management features that IoX has...

HA's ISY integration allows you to create custom devices in HA via ISY programs, so you can make a "cover" in HA that actually consists of programs in ISY that issue the command to the IOLinc and track the status of the door to display in HA. The program's 'then' logic issues a command to open the door, the 'else' logic issues a command to close the door. The integration page goes over it and actually has a garage door as an example: https://www.home-assistant.io/integrations/isy994/#creating-custom-devices-using-isy-programs

That's odd since the node server itself doesn't use the 'password' module, it comes from the underlying Roomba python project. As a first step, I'd recommend uninstalling the node server and also the Roomba module. Then re-install the node server from the store and let it install the prerequisites automatically. pip uninstall roomba pip3 uninstall roomba Also, this node server is pretty old now, there could be some modules or commands no longer supported by the current version of python. I think it has been ported over to Polyglot 3 if you switch over to the Polisy.

@GQuack, I'm not familiar with the lock function in Blue Iris. I don't think you're missing it, didn't implement it in the node server because I wasn't sure what it was. It looks straightforward enough to implement but I'm sorry to say I no longer use Blue Iris; I switched over to UniFi Protect a while back. I threw together a quick attempt at adding that feature offline here: https://github.com/fahrer16/udi-blue-iris-poly-1 but I have no way to test. @bpwwer took over that node server and ported it to PG3, he might be able to take care of the update if someone is able to test it out.

Most of what I know comes from the project that the node server uses: NickWaterton/Roomba980-Python: Python program and library to control iRobot Roomba 980 Vacuum Cleaner (github.com). From the various troubleshooting I've done, it seems like the first to connect to the Roomba locally wins. For example, if the connection from the node server is alive and well and then the app is used, it seems like it connects via the cloud and leaves the node server alone. If the app is able to connect locally, it seems like the node server isn't able to and is out of luck. I've wondered if maybe the local mqtt connection times out or if there isn't much traffic while the roomba is idle and it gives the app the opportunity to "steal" the one and only local connection. You can tell there's a lot of guessing going on, which is always the challenge of using reverse-engineering unsupported API's. Definitely pros and cons associated with isolating the roombas vs keeping them open to use the app at any rate.

Trying to use the app and the node server simultaneously will likely give sporadic results. The roomba hosts an mqtt server for local communications that has historically only allowed a single connection, so if the app is connecting locally the node server might get kicked or at least stop getting updates. I used to run my Roombas on a separate VLAN so the app wouldn't be able to connect locally (cloud should still work and wouldn't interfere with the node server comms). An additional option is restricting internet access from that VLAN so the Roomba's can't update their firmware automatically and break the reverse-engineered protocol the node server relies on (which also means the app won't work). I think one of the Roomba firmware updates a few months ago killed the tracking, causing the x, y, and theta values to no longer get reported.

It seems a little hit or miss whether it can tell the difference between devices. I have 3 air handlers that are the same make and model and we’re installed at the same time. It can tell that one of them is different but the other 2 it sees as one device. one caution is that devices in Sense can sometimes “disappear”, so I’d be hesitant to use any automations where it would be a big deal if it stopped working one day. The Sense app can do notifications, which might be more reliable since there are fewer systems and interfaces in the mix. That automation with the garage door is an interesting idea!

I've been using Sense for close to 2 years now. It was an attractive option for me because my house has a relatively complex electrical system with 5 panels and a parallel feed setup, using CT's everywhere would be a little pricey. If all things were equal, I'd probably prefer having CT's everywhere but the Sense is definitely easier, works pretty well, and provides a ton of data. In the screenshot below, I happened to catch it during a time where a lot of power was being used and it doesn't always do a great job telling you what's using so much juice. I hate seeing the "Always On" and "Other" buckets because they're not very helpful In terms of automation, I originally integrated it with ISY but haven't found much of a use to do that, but it works. The only annoying aspect is that it tends to create a lot of new devices that you have to rename once you figure out what they are. The app has the ability to alert when certain devices turn on, off, or is on/off for a certain amount of time, which covers most of my use cases.

I was wondering this too because deleting and re-adding the integration would be a massive PITA. I just took a look and it looks like it's stored in /config/.storage/core.config_entries It's a JSON file and the entry containing "domain": "isy994" has the config related to the ISY integration. I haven't actually tried changing it yet but obviously a backup ahead of time would be advisable. It's too bad HA is moving towards the GUI config for all of the integrations without providing a good way to edit their config.

I still use RR, with Home Assistant exposing the ISY devices over HomeKit. The RR interface looks nice with minimal config and it's easy to use for my wife. It also has the ability to issue voice commands to Siri on Apple TV, which is lacking from Home Assistant. Using Home Assistant to make ISY devices accessible over HomeKit is a pretty nice solution, actually better than using RR directly interfaced to the ISY.