bpwwer

I'm not sure what you're looking at but already does New Pr

Maybe set logging to debug to see what's causing the error. It sounds like the server is not sending valid data.

I screwed up the status for the different nodes. It should be fixed in version 1.0.2 so that the Today/Tomorrow nodes show True/False and the main node shows connected/disconnected/failed.

I didn't have Holidays Google running on anything but PG3 when I tried it. I don't use it so I had to create a Google calendar to test.

I tried setting up Holidays Google and get the same invalid grant/bad request error. It really needs to authenticate with Google before it can access the calendars so that's pretty much a fatal error. I have no idea why that's failing. The PG3 version is just a conversion of the PG2 version so the actually operation of the node hasn't changed.

Please provide a debug log. The only lower() being used in on the "LTE-xxxx" string which certainly doesn't look like a bool object. That code is unchanged from the PG2 version.

Fixed in version 1.0.1

I think @fahrer16explaination makes sense. He knows a lot more about this node server than I do as he originally wrote it. I just did the updates to make it work with PG3.

I'd recommend that you restart the node server from the PG3 details page. Then download a log package from the node server's log page. Then work with the Kasa node server author, @JimboAutomates, to figure out why the node aren't showing up on the admin console. I'm not real familiar with the Kasa node server, but generally, once it starts it should automatically add nodes so that they show up in the admin console and you'll be able to control the Kasa devices and see their status there.

@webminsterthanks for details. I'm always a bit concerned when I hear of someone rebooting the Polisy as that shouldn't be needed to resolve a majority of the problems. After OS upgrades, sure. Your case seems valid as well. I've added an issue and I'll try to reproduce. PG2 has bug related to saving credentials, I really know the cause as I don't work on it. Most of the time it works, sometimes it doesn't and takes multiple attempts to get them saved correctly. I had to dig back through our development channel to jog my memory. On a Polisy, 'localhost' was resolving to a IPV6 address and that would cause failures as nothing else in PG3/ISY is using IPV6. Using 127.0.0.1 instead of 'localhost' works since it's a IPV4 address.

Yes, the ISY IP address/port is editable on PG3. From the ISY-> Edit Current ISY. If you can't update/save changes from that screen then you have other issues that need to be resolved first. Don't use 'localhost' there's a problem where that doesn't do the right thing and it seems to be a node.js problem, not something that can fixed or worked around by PG3. Using the actual IP address is best. I can't say that I've ever seen the issue you're describing after a reboot but then I also don't reboot very often, the Polisy I use to develop PG3 on has been up for 102 days. How long do wait before you restart PG3? It's possible that it could take few minutes 5-10, before it retries and connects to the ISY.

Ok, I added some debug messages to 2.0.7 that should allow me to better trace what is happening. If you can run the same test again, but make sure you have debug log set for the node server, I'll see if I can figure out what's happening.

@jlambI believe I responded to clearing PG3 in another of your posts so I won't repeat that here. But since this is a more generic PG3 on Polisy thread, the following is a more general observations and not directed at any one person. When having an issue with PG2 or PG3 (or really any any piece of the Polisy/ISY environment) it is best to focus on the specific issue and try to contact the right folks for help on that issue. When you start changing random things and try to "reset" everything you end up getting your system into a state where it is really hard for anyone else to understand what that state is. Neither PG2 or PG3 on the Polisy are designed, at this point, to be fully deleted from the system or "reset" to a clean state. They are designed to try and preserve your configuration so that you don't loose anything important. When you have an issue, it is best to try and collect whatever log files you can and try to document the steps you've taken to the best of your ability. The more details you have, the easier it will be for someone to help you. For node servers, both PG2 and PG3 do a fairly large amount of logging. Being able to trace the log and compare it against the actions you've performed are the only real tools that node server developers have to debug issues. Keep in mind that it's very likely that the developer has not seen the issue you are reporting. Thus generic statements don't provide any information the developer can use to resolve the issue. I'll say it again. Be specific and provide (or be ready to provide) logs.

All three Roomba's were configured in the node server during this test right? The log doesn't really tell me much. I do see something changing state, but it seems to change state for less than 5 seconds. However, that may just be the other Roomba's state mixed with the i7's I can't really tell. The node server is supposed to update the state in the AC every 5 seconds (so there can be a delay between commands given via the app and the state changing in the node server) based on the default shortPoll time. Neither the underlying library being used to communicate with the Roomb's nor the node server itself output any info to identify which Roomba it's getting updates from or when it updates the node server state. Thus I can't really tell what is really happening. I'll have to add some debug info into the node server so we can see what's really happening. One thing that concerns me is that all the messages in the node server log indicate they are coming from "Thread-1". The node server is multi-threaded and I would expect each Roomba to be doing things on a separate thread. But because of the way the underlying roomba library works, that may not be true for the actual communication with the Roomba.

Neither PG3 nor PG2 are designed to be fully deleted from the system. However, If you want to clear PG3 of all settings and return to all defaults you can do the following from the ssh command line: sudo service pg3 stop sudo rm /var/polyglot/pg3/pg3.db sudo service pg3 start this will remove the PG3 database (which is the only configuration file it has) and PG3 will re-created it with default when it starts. I don't know how to do that same thing with PG2 as it uses a different database to hold it's configuration.

Yes, if PG3 is properly configured to use the same ISY. All nodes servers on the ISY but not installed by PG3 will show up that way.

The portal node server entry isn't managed by PG3 so PG3 has nothing to do with it.

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.