bpwwer

From the log, these are the nodes that the plug-in is creating: 2025-12-11 10:41:30.915 Thread-6 (start) udi_interface.interface INFO interface:addNode: Adding node Bedroom Sound(zone_1_1) [None] 2025-12-11 10:41:31.915 Thread-6 (start) udi_interface.interface INFO interface:addNode: Adding node Laundry Room Sound(zone_1_2) [None] 2025-12-11 10:41:32.916 Thread-6 (start) udi_interface.interface INFO interface:addNode: Adding node Sunroom Sound(zone_1_3) [None] 2025-12-11 10:41:33.918 Thread-6 (start) udi_interface.interface INFO interface:addNode: Adding node Porch Sound(zone_1_4) [None] 2025-12-11 10:41:34.919 Thread-6 (start) udi_interface.interface INFO interface:addNode: Adding node Game Room Sound(zone_1_5) [None] 025-12-11 10:41:35.920 Thread-6 (start) udi_interface.interface INFO interface:addNode: Adding node Kitchen Sound(zone_1_6) [None] 2025-12-11 10:41:36.922 Thread-6 (start) udi_interface.interface INFO interface:addNode: Adding node Deck Sound(zone_1_7) [None] 025-12-11 10:41:37.923 Thread-6 (start) udi_interface.interface INFO interface:addNode: Adding node Garage Sound(zone_1_8) [None]So it doesn't look like the plug-in is creating those extra nodes. However, after it has set the initial values for those 8 nodes, it reports 5 errors: node address zone_1_10 does not exist ... node address zone_1_14 does not exist when it tries to query those nodes. The log doesn't show the plug-in creating them and it's not clear from the log where they are coming from, could be either the PG3x database or IoX. I'd suggest deleting them from both places and then restart to see if they come back. How they got there in the first place is something I have no way of knowing without seeing a debug log from the plug-in from when they first appeared.

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.