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

@drmacro, the controller node that gets created behind the scenes is what's actually subscribing to the websocket and processing all of the data. The nodes that are inserted into flows just provide access to what the controller node provides. To answer your question, a websocket node provides a means to access the raw websocket XML in a flow if desired. A websocket node never has to be used, any node (including a device node) can be used by itself in a flow.

@drmacro, glad to hear it's working out. The next thing I was going to ask was whether there could have accidentally been two configuration nodes for the ISY controller created when installing since that might explain the continuous websocket connects but going nuclear and rebuilding the PI from scratch certainly works too!

I’m on 5.0.11 without any issues. It sounds like 5.0.13 reverted the websocket behavior introduced in 5.0.12 back to it’s behavior in 5.0.11 but I’ll try to find some time this weekend to upgrade test out 5.0.13. @drmacro, you mentioned you were getting the same error in relation to the variable XML. If that’s the case, that doesn’t sound like a websocket issue but rather the contents of the XML returned for variables via REST. It might be worth checking that the original URL’s you accessed for integer and state variables now include a “prec” element for all variables.

@drmacro, thanks for the XML. Based on the XML you provided, the variable definitions in your ISY don't have the "prec" element. I don't recall when variable precision was added, feels like ages ago but I'm not sure where to check. If you update your ISY to a recent firmware that error will go away. I'm not sure if @Michel Kohanim would know which firmware revision introduced variable precision. The ISY typically does a fantastic job maintaining backwards compatibility as things move forward but I suppose this brings up an issue that adding backwards compatibility earlier than the firmware this project was developed with would be very difficult. If I can find some time, it might be a good idea for me to add a firmware version check to this project and prevent it from running if the firmware revision is unsupported.

I wrote the node-red project pretty quickly and it’s definitely in more of a beta if not alpha state. I wish I had some more time to devote to the project because I think it has a lot of potential. @drmacro, what firmware version of ISY are you running? That error indicates the xml being returned for variables from the ISY doesn’t have the expected elements (“val” in this case).. Could you open up a web browser and send along the xml returned for the following url’s? http://<<ISY IP address>>/rest/vars/get/1 and http://<<ISY IP address>>/rest/vars/get/2 If all else fails, you can suppress errors from any node in node-red by adding a “catch” node to the flow. p.s. The controller node in node-red is what does all of the work, it gets created when the connection to the ISY is defined. It’s called a “configuration node” in node-red. A lot of nodes use them so that common configuration can be shared across nodes. You can view all of them by going to “configuration nodes” in the node-red menu (the hamburger icon at the top right of the main screen).

The Node-Red implementation will kick an event off if anything on the variable changes. If you set your debug node to view the complete message you'll see more than just the variable value, which might have something else that changed.

That's great, @johnstonf I'm glad you've liked the node-red integration so far and thanks for sharing your project and making a video! Most of the weirdness around getting it to work for the first node is due to a catch-22. Node-Red needs to have credentials defined and deploy to start the code to get the lists of devices, variables, etc.. from the ISY but you can't deploy a node until the device/variable is selected. If I can find some free time I'll try to add some more feedback to help make the initial deployment a little more intuitive. I also started making another node that would act as a custom-defined node inside of the ISY (kind of like a quick and dirty polyglot node that can be built in a few seconds). Finding time seems to be the limiting factor, unfortunately!

That's actually one reason why I integrated the roomba with the ISY, so it only runs when someone is home.

Great news, glad to hear it's working out for you!

The 900 series software is labeled version 2.x while the 600 and 800 series shows version 3.x. My Roomba 690 is on firmware "3.2.10+32" last updated on 07Dec17 and working well. The node server implements an MQTT client for communications with each roomba. What were your results from trying to get the robot's BLID and password from the dorita980 project?