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.

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

Yes, it will work with a Roomba 690, there will just be less data/options available (no bin full sensor or x-y-theta position tracking). I did block internet access to my Roombas to prevent firmware updates but I haven't heard of any recent firmware updates breaking access. I did have trouble getting the BLID and password using the python project though; I wound up using the original node.js project: https://github.com/koalazak/dorita980

If you're on v5.0 there's a node server for direct integration with Roombas. It will alert the ISY when the Roomba stops, when it's docked, etc... Shameless plug: https://forum.universal-devices.com/topic/23292-polyglot-roomba-v2/

Allonis uses a web interface for all user interaction so it's platform-independent. I use it on Android, iOS, and Windows. The server-side of the software does have to be installed on windows though, so you need to keep a windows box running 24/7. Allonis works out of the box with very little customization but it also lets you build a customized interface, right down to moving buttons around, running custom commands, etc... I have some screenshots on another thread: https://forum.universal-devices.com/topic/23165-smart-mirror/