bpwwer

I'm far from an expert on how the Roombas work. Basically, if you're going to use the plug-in, don't use the app and if you're going to use the app, don't use the plug-in. And when I say don't use the app, I mean you should not have it running, not even in the background. I don't know what happens if the app is connected and you press the button on the roomba. Pressing the button on the roomba, puts it in a mode where it will send it's password to whatever makes a connection to it. Once something has that password, it can connect directly to the roomba without having to get the password again. So when the plug-in gets the password, it saves it along with the IP address of the roomba so that from that point on, it simply connects to the roomba when it starts.

So what changed between your two posts above? The first looks like it connected to the roomba and got something while waiting for the password. However, it doesn't appear to be valid password data. That line of code where it failed, has been in the plug-in since the beginning so I don't think it's suddenly wrong. It just looks like the roomba sent something it can't handle. The second isn't even connecting and the roomba is refusing to connect. Looks like I need to quit trying to connect if I get anything other than a timeout error. I'll add that to the code. But I don't think the plug-in can do anything to make the roomba accept the connection request, that's controlled by the roomba itself. The roomba can only have one connection at a time. If you connect with the app, the plug-in will be unable to connect and if the plug-in is connected, the app won't be able to connect.

Ok, I found what I missed when updating to the new getPassword code. It should now wait for you to press the button on the Roomba. Version 2.0.17 with this fix has been submitted to the store.

set the plug-in log level to debug, restart, download the log and attach here. I'll take a look.

I do see one problem in the log now. Looks like you only have 10 seconds to press the button on the Roomba before the plug-in gives up looking for the password. This one section of the code that had major changes to work with the latest Roomba library code.

Thanks. It did show a couple of the messages I added, but still doesn't seem to want to initialize the Roomba. Version 2.0.16 makes a slight change and I'm curios what happens. My working theory is that when it sends the notice, it interrupts the initialization so that it never finishes. If that's the case, I'm not at all sure how to fix it.

@Lore Thanks. I don't see the log message that I added to help debug this so something strange is going on. I made some change that may help, but I'm not sure. Try the new version and then capture the log again.

@Lore I don't have any PM's from you so I'm guessing it didn't go through. Maybe I don't have space for a large log file anymore. I'll clean up my PM's just in case.

@EricBarish Thanks for the details. It does give me a better idea of where to look for the issue. This file is not available (so the forum says). So I still don't have a full debug log showing the issue.

Seems to be working for me. I also do see the dependency error in my install.log after installing it on a system with IoX 6.0. But it doesn't seem to cause any issues. As mentioned above, Server error 500 is coming from the Emporia server, it's not something the plug-in can do anything about.

Neither Benoit or I was able to reproduce this, ST-Inventory was working for both of us. The error looks like it could be caused by the checkbox not being checked. I know at least once, I checked the box, but forgot to save it causing a very similar error.

One thing I just thought of, for ST-Inventory to work, you do have to check the checkbox on the config tab to allow the plug-in to access the IoX/ISY. and make sure you hit the save button after checking the check box.

Re-reviewing this, it does look like the sonos-http-api may not be running. Or may not have been running when the plug-in started. Have you tried simply stopping and then starting the plug-in? When I installed it, the first time it tried to start I got errors like what you posted, but after restarting it, it seemed to work fine. Of course I have no Sonos devices so it doesn't actually discover anything, but it did create the control node and didn't have any errors in the log.

I did find an issue with the dimmer and also with the rgb bulbs. Those have been corrected in version 1.0.9, which I have submitted to the non-production store. See if this version behaves a bit better when setting levels. I still need to investigate why it seems to stop getting updates from the devices after a day or two.

I don't think the warnings in the install log are significant. It looks like the plug-in got installed correctly. I still suspect that it's the interface file that needs updating by UDI. I sent a message to them, requesting that they look into it. There have been other reports of issues running the node.js based plug-ins and I am unable to start them as well. These were all running fine before whatever update broke them.

I think #1 would be a UDM issue. I've always considered the AC to the standard, if it works there, it should work everywhere. But with the new eisy-ui, that may have to change. If the level stays set in the AC, that implies that the plug-in isn't changing it. For the light turning off when setting the level, it's certainly possible that the plug-in isn't sending the correct messages, but since I don't have any documentation that would describe what messages to send, I'm relying on other projects that have spent time trying to reverse engineer the protocol and that could have incomplete information. I believe this happens on a dimmer switch device as I don't believe I've seen that issue with the dimmable bulb. I'll look at it again, but if I remember correctly, the plug-in sends a set-level message followed by a set on message. Maybe if I can combine the two messages into one it will resolve the issue, I'll try that, but I don't have any switches (dimmable or not) to test with. I do need to look into why it stops working. As I said, I'm seeing this every day or two, but it could be related to the number of messages being sent so I'll try repeatedly sending messages and see if that triggers it sooner.

I think that UDI broke a bunch of plug-ins with an update. Errors that start with "error: NS:" are coming from the interface library that the plug-in uses to interface with PG3x. That library is maintained by UDI but I'm not sure they actually test to make sure it works when they release updates. The deployment directory is "000db95608c0_10" so you'd have to do an "ls -la 000db95608c0_10" what files/directories where created when it was installed.

I believe that the proper behavior of setting a dimmer to on, is to set it on to the level specified by the level, so I'm not sure it's wrong, but it also may depend on the type of dimmer, seems dimmer switches and dimable bulbs behave a bit different. I believe the plug-in queries the device for current state and the level should be part of that. I think I mentioned before that the plug-in is not turning the light off when you change the level, that seems to be the device itself. However, it is possible that the plug-in is not sending the correct commands. I've been having a problem where the primary device that I'm using (I have one bulb as part of a scene that turns on at sunset and off at 11:15pm) seems to stop responding and the plugin gets stuck waiting for a response. This is happening every day or two and I have to restart the plug-in to get it working. When reporting something that seems wrong, please let me know what type of device.

The missing modules are used for creating the Roomba room mapping, which the plugin doesn't use. Thus the missing modules are expected and not an issue. I don't know why it gets stuck trying to initialize, I don't have that problem with my Roomba, so not something I can easily debug. I did add some additional debug info a couple of versions back, but so far, none of the logs you've posted have had that specific debug log message. Please set the plug-in log level to debug, restart the plug-in, note the time and once it gets stuck, download the plug-in log file and PM it to me. That way I have the entire log.

All values passed to IoX by the plug-ins are numeric. The plug-in supplies a file that maps those numeric values to a text string and IoX is supposed to use that file to provide a formatted output with the numbers replaced by the corresponding text. What you're seeing is an IoX issue, not a plugin issue. Restarting IoX so that it re-reads the mapping file may resolve the issue. If not, submit a ticket to UDI.

Local. The plug-in connects to the smart hub and all communication is between the plug-in and hub.

Fixed the name error in 2.0.14 @Lore I don't see any errors in the log but I also don't see that it ever called the initialization function so I don't really understand what's happening.

Looks like I forgot to push the changes from my local copy. I just did that so it should update to 2.0.13 now. Set the log level to debug and then download the log an either attach or PM it to me.

The problems looks like it's happening in the UDI node.js interface library. I'm guessing they never tested it with the upgrade to verify that it works. I'm no longer maintaining that library so you'll probably have to contact UDI.

version 2.0.13 has the additional info in the log message