bpwwer

It was reported before, but it makes no sense as getPurchaseEntry is definitely a function.

Use port 80 (or port 8080 if running ISY on Polisy) for the ISY port. Polyglot can not connect to an ISY using a secure connection unless your ISY has a valid, not self-signed, certificate.

The errors mean that the roomba isn't reporting the position. Maybe the i7 doesn't do that, I don't know. When I added support for the i7, I assumed that it could do everything the 980/900 series can, but that might be a bad assumption. There's no documentation for any of this so it's all just assumptions.

If you're running ISY on Polisy, it is typically using port 8080.

Whatever is at 192.168.86.51:80 is refusing the connection. Are you sure you PG3 properly configured with the ISY information?

Improved support for the i7 was just added, prior to that it treated the i7 as a basic roomba so I doubt that it had any support for position since that's one of the things checked to indicate it's not a basic roomba. I don't have i7 so I can't reproduce, test or really debug issues related to it. I also can't see what's in your log files unless you post/send them.

The PG3 web port is 3000, that hasn't changed since it was first released.

The Admin Console and the ISY independently read the profile file that maps the number to a string. From what @Javisays, it sounds like UD Mobile expects the ISY to send the formatted value. So if the admin console is correctly showing the string value, then it implies that the profile files are correct and it would be the ISY that's not reading and/or not mapping the values. There are times that the ISY needs a reboot to force it to re-read that file and get the contents into memory but it sounds like you already tried that. I think the next step may be to open a ticket to find out why that specific ISY either isn't reading the file or isn't performing the the mapping.

Version 2.0.5 should handle the new version of the Pandora plug-in. It uses the sort by newest to get the station list.

I'll try to explain what happened and where I think you're currently at and next steps. The ISY and PG3 both contain information that links node servers between them. If you mess with one but not the other you end up in a bad state. The "/var/polyglot/pg3/pg3db_xxxxxxxxxx" file contains the PG3 configuration at the time it was created. It contains the node servers installed on the ISY/PG3, the node server configuration info, the ISY configuration info, and PG3 configuration info. By copying that file, you put PG3 back to the state it was in when that file was created. By deleting the node servers from the ISY without also removing them PG3, you've left PG3 in a state where it thinks the node servers are installed on the ISY, but they aren't. If you have backups of everything, you can, in theory put everything back to the state it was in, but at this point, I'm not sure that's the best way forward. Since you've deleted the node servers from the ISY, it may make sense to clear the PG3 configuration again and start from scratch. To do that, you can simply 'sudo rm /var/polyglot/pg3/pg3.db' and then restart PG3. If the database doesn't exist, PG3 will create it with default values. Then configure the ISY and start installing node servers. If you continue to have issues with the itach node server, you'll have to contact the author of that node server. I believe there is a forum section where you can do that.

The restore process is two steps 1. select the backup file to restore. Then the button will change from "select file" to "restore" 2. restore the selected backup The restore process will log what it is doing to the PG3 log.

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.