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

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

Do node server authors need to do anything to make existing node servers compatible with V3?

@Javi that pull request is all set, let me know if you see anything else!

I just saw this and accepted the pull request.

For what it's worth there are a couple of custom Airthings integrations for Home Assistant. It would be pretty easy to use one as an example to roll it into a node server if anyone were interested/motivated: The cloud version looks like it scrapes the web dashboard. If you don't have the Airwave hub the data might not be up to date but it's really simple. Danielhiversen/home_assistant_airthings_cloud: Airthings cloud (github.com) The local version uses BLE. I think the Polisy has Bluetooth built in so it might actually be possible to modify that to talk to Airwave devices directly. custom-components/sensor.airthings_wave: hassio support for Airthings Wave BLE environmental radon sensor. (github.com) Until a node server is developed it'd probably be possible to use a raspberry PI to serve up the values via MQTT then use the MQTT node server to pull them into the ISY. There's a github repo dedicated to getting the data from Airthings pushed to MQTT: stenjo/waveplus-reader: Importing data from my Airthings Wave Plus into openhab via MQTT server (github.com)

I've seen this quite a bit on my setup. I'm using a mix of 2477D dimmer switches and 2334 Dimmer KPL's with some pretty cheap (almost free) bulbs that I picked up from the local electric company. I've been working under the assumption that the cheap bulbs are the likely cause. It's very noticeable and reproduceable when adding a new insteon device. Luckily I don't do that too often.

Yes, the Roomba node doesn't currently have a mechanism included to automatically retrieve the required credentials. The dorita980 node is required to get the credentials needed to set up the node. With the ability to use node.js in polyglot it would be very easy to polish this up a bit and have the integration process be more automatic if anybody has the time. https://github.com/koalazak/dorita980