bpwwer

I suspect that something (IoX or PG3x) is saving the UOM values and unless something actually changes them back, they'll stay that way. I faked the creation of a node (since I don't have an api key) and the plug-in created the node with the correct UOM's and the admin console shows the node correctly as well. You can try first just deleting the node from PG3x. When you display the nodes for the plug-in, you can click the [X] button under Delete on the right and it will delete the node from PG3x. Restart the plug-in and it will recreate the node. You may also have to delete the node from IoX but that may mess up any programs that are using that node.

I really can't explain, nor do I have any suggestions other than to re-install the plug-in. The plug-in node defaults GV2 to UOM 25 and no where in the code does it change that. So how or why it got changed to UOM 17, I have no idea. For the temperature values, they should be UOM 17, that's what the data from the device shows. It's reporting the following: targetTemperature': 62, 'temperatureUnit': 'F' and that's the data the plug-in uses to determine the temperature UOM.

It is supposed to look at the units that the sensibo is set to and dynamically determine which units to use (C or F) when sending updates to IoX. I don't believe that PG3x's node display is dynamic so it should just be showing the initial units that the plug-in defaults to before it gets any updates from the sensibo. But that's not something I've ever looked into. The plug-in's debug log level should include messages showing what data is coming from the sensibo. There's nothing in the plug-in that is modifying the UOM of the power state. Looking at the PG3x log should show what the plug-in is sending to IoX when GV2 is updated. I don't believe it should be sending any UOM, so it should be defaulting to default UOM which is 25. If the log shows the plug-in sending the wrong UOM, then it may be a bug in the plug-in -> IoX interface library. If it's not, then it may be bug in IoX.

This is one of the plug-ins that I ported over from PG2 to PG3 for UDI. I don't have a Sensibo so I'm not able to do any debug/testing on this plug-in but I do try to fix bugs when possible. Since the plug-in uses the Sensibo cloud API, it's very possible that if it fails to connect to the cloud service that it will stop working and need a restart. That should show up in the log. Note that PG3x won't display historical log entries, you'd have to download the log to get the entries prior to is hanging/stopping. The profile files have GV2 using UOM 25 and restricted to values 0 and 1 with those mapped to Off and On. This matches what's defined inside the node itself: {'driver': 'GV2', 'value': 0, 'uom': 25, 'name':'Power'}, which is what PG3x should be displaying. I have no explanation for you seeing GV2 with UOM 17.

Not really. I haven't been able to find anything incorrect in the plug-in. What seems to happen is that after sending a few commands to the device, the device just stops responding and doesn't send anything else to the plug-in after that. I see this after about 3 days and I send commands to my bulb device 2 time a day, so that seems to match what you're seeing. I wonder if it's a race condition between polling the device for updates and sending commands. It may be possible that a poll happens while the command is waiting for a response. I guess one way to test this would be to increase the polling interval from 60 seconds to something really big like 6000 seconds and see if that helps. So just ran an experiment. I changed short poll to 6000 and was able to do at least 30 on/off cycles without any issues. Then I changed the short poll to 20 seconds and it failed after 3 or 4 on/off cycles, well it set the on-level to 0 so on stopped working. So I'm not sure that's the same failure. I've set my short poll to 600 now and I'll let it run and see if it fails after a few days.

I've been busy with other stuff and haven't had time to work on it lately. I'll get back to it soon.

I don't really know as I don't have a stick to test with. Even if the wired and wireless are the same network, it's possible the router isn't passing broadcast messages between them, so I'd check the router settings for something like that.

That line of code that's throwing the error hasn't changed. What did change was that it moved inside a loop so that it will keep trying to connect instead of timing out after 10 seconds. I'll take a look at that section and try to determine what's going one to make it fail now.

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.