bpwwer

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.