bpwwer

Right click on the node and select ungroup. It moves it out from the group then right click on the node and select delete.

I tried updating it to add support for the i7 (which is currently providing the same support as the 980). Try version 2.0.4 and let me know.

I guess I'll have to update. Maybe it fixes some of the issues I've been seeing.

If you turn on debug logging there should be a line in the log that lists the capabilities: "Capabilities: Position xxxx, CarpetBoost xxxxx, BinFullDetection xxxx" Those values determine what series it thinks to Roomba is; series 980, series 900, series 800 or none of the above.

I mainly just ported the existing PG2 version to PG3 and did some work to try and make the initial discovery work better. However, the library being used to interact with the Roomba's is all reverse engineered as there is now official API available to interact with them. If you send me a log package along with some details of what you were trying and when so that I can correlate what's in the log to what you're seeing, I'll see if I can make it work better.

Maybe fixed in version 4.0.4

Are you sure that's a 994?, usually they are on port 80 not 8080. PG3 will try to detect an ISY and add it to it's database when first started. If it doesn't detect one, it will add default values for IoP but maybe that's not working correctly and it's only partially adding it. what happens if you enter the correct values for that IP address (port, username, password)? Can you save that and does it then find it and populate the UUID?

I have only very little experience at this point. I have a Caseta smart bridge two Pico's and two automated blinds. Right now the bridge and the blinds are at opposite sides of our 2000 sqft. single story home and it just barely works. The bridge is able to control the blinds 99% of the time. If I move the bridge, it gets worse. If I were to place the bridge in a more central location in the house, I don't believe I would have any issues at all. It's currently located where it's at so that I can use it to develop the PG3 Caseta node server. When I first installed a z-wave lock, I had no luck communicating with over that distance, but that was with z-wave 300 series devices so it may not be a fair comparison today.

I don't understand what you did with random id's. The nodes listed are device id's not station id's. The station ID is associated with the main "WeatherFlow" node and the sub nodes are all the devices associated with that station (as listed by the WeatherFlow servers). The ISY won't let you delete sub-nodes when they are grouped. You have to first ungroup them then delete them.

It's backing up log files again because the module doesn't provide a way to exclude them. That's why it's so large and because it's so large, it takes longer. It's taking long enough that the connection between PG3 and the node servers fail, moving them all to "Failed" state. You should be able to restart the node servers after the backup is complete. So both libraries that provide the functionality we need fail when the backup gets to a certain size. At this point, I don't have a solution that works.

Looking at the code for the PG2 version, the port is set to 3001. Maybe you changed yours at some point? Try version 4.0.3. I'm still trying to understand the relationship between the various nodes in this node server.

Fixed the problem with the object has not attribute 'parent' in version 4.0.2

That's not really enough information to do any debug with. I'd need the steps you were doing that lead to this and the complete log.

right-click on the node and select delete. The node server will create nodes for all the devices associated with the station ID, so if all of those are associated with the station ID, the node server will re-create them when it restarts.

Try version 4.0.1 just released to store. Refresh the store listing and verify it's showing version 4.0.1 then restart the node server.

The node server to PG3 is now a tri-state value instead of boolean. The states are "Connected", "Disconnected", and "Failed".

Great! glad it's working now.

Might be more correct in version 2.0.2

I guess that makes sense, "not a number" isn't a number so it can't be converted to an integer. In any case, the latest version shouldn't crash if that happens again.

The version in the non-production store is the same, I was using it to test auto-update functions which is why it has a different version number. You can try version 2.0.3 and see if it makes any difference but I don't really think it will. The code that interacts with the roombas is from an external library and there haven't been any changes to that library since version 2.0.2.

I added code to check for that error, report it and continue. If you refresh the store, you should see version 2.0.4 and restart of the node server will install it. It should report an error to the log when it does this. I'd really like to know what Volumio is sending for the volume if you don't mind posting.

I think I see the problem. Try refreshing the store list to make sure it shows version 2.0.1 and then restart the node server

That's strange, I wonder what it's returning for the volume that's not a base 10 number?

@DennisCIt shouldn't be a problem with the latest version of PG3, released today.

Yes, at this point, you'll see the same problem with almost all node servers because it isn't really a problem with the node servers, but a module that they all depend on.