bpwwer

You should have mentioned that you wanted to keep existing PG3 nodes. That's not really what "start with a virgin install" implies. Likely why nothing is showing up as unmanaged is because it doesn't have the correct password for the ISY and thus, can't query the ISY for the node servers currently installed on it. Removing the database makes PG3 start without any knowledge of the previous installed version. There is currently no way to recover unless you made a backup with the previous install. If you did make a backup, you should be able to restore that. You can check to see if something did backup the database recently as PG3 will sometimes do that if making changes to the database schema. 'sudo ls -l /var/polyglot/pg3' If there's a pg3db_xxxxxxxxxxxx in there and it's recent, you can replace the new database with that one 'sudo cp /var/polyglot/pg3/pg3db_xxxxxxxxxx /var/polyglot/pg3/pg3.db' 'sudo service pg3 restart' The numbers after 'pg3db_' will be unique to your environment as that would be the timestamp of when the database was backed up. However, restoring either a backup or just the database, will bring back the ISY entry that you can't remove.

There's no reason to ever remove the "polyglot" user/group. And yes, both PG3 and PG2 rely on those. Deleting the package also won't delete the database since that's not generally what is desired. If you really want to start over with a fresh install, you'll need to do a 'sudo rm /var/polyglot/pg3/pg3.db' after removing the package.

Ok, thanks. I fixed it in 2.0.6

I almost always break something when adding enhancements. Version 2.0.5 should work better and actually start.

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.