fahrer16

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