bpwwer

From the log, the Hue node server installed correctly. It seems to be the node server itself that exits abnormally after starting. We'd need to see the node server log which should indicate why.

Thanks for being so detailed in describing the problems. Typically, when a node server stops and shows disconnected immediately after trying to start it, it means that the node server crashed for some reason. Info on that will show up in the node server log. If there is no node server log, then it was never able to start and those errors will show up in the PG3 log. Both the Hue and Sonos node servers are free node servers. Thus, you haven't actually purchased any yet so that's why you're seeing the error since it really did fail to get any info on purchased node servers. That message should be improved to be a bit more helpful in the next release. With PG3, you can install the same node server multiple times into different slots so even after installing it, you can still install it again. Once you install a node server, the column labeled "Installed" should show the slot number(s) that it is currently install in. We'll need to know what's in the log files to determine what isn't working.

The PG2 version is probably just ignoring the bad response.

I thought I was outputting the results of the query in debug mode, but I guess not. AmbientWeather is not known for their reliability so I still suspect it either returned an error or a corrupted response to the query. There's not really anything else the node server could do. It recognizes that the response isn't valid and continues on, the next query response is fine and the data is updated.

The restore from PG2 option was written for PG3 before I took over PG3 development and as @apostolakislsaid above, it's not an elegant solution. It does sort of work, depending on what node servers are being backed up and restored, but in general, I'd not recommend using it. The process basically goes through the node servers listed in the backup and attempts to find one in store with the same name and install it. It will also try to port the configuration over. It basically overwrites the node server configuration in the ISY for those node servers it successfully installs leaving the PG2 version orphaned. As far as PG2 is concerned, nothing changed. It still thinks it has the node server installed and that it is working. Since PG2 (and PG3) are designed to remove the node server from ISY when it's deleted, doing so on PG2 will very likely remove it from ISY, leaving PG3's version now in limbo. The only real solution is to stop the PG2 version and either never restart it or simply stop PG2 entirely. If you're trying to migrate slowly and or still need PG2 running, it is much better to manually migrate the node servers you can to PG3 by first documenting the config, deleting the PG2 version, installing PG3 and updating the config.

Make sure you add a value to the custom parameters that evaluates to true. Something like key - change_on_pon, value = '1' If you leave the value blank, that evaluates to false and means you don't want that feature enabled.

The connection to the Roomba is handled in a separate thread by the roomba library code developed as part of the Roomba980-Python project. That code waits for updates from the Roomba and stores them. The node server polls that stored data at the poll interval. Thus the node server can look like it is updating frequently when in reality, it is just getting whatever stale data was last received from the Roomba. Also note that if the data is not changing, the node server won't pass it on to the ISY. It only sends data that has actually changed to the ISY.

You can also check the PG3 log as it will show everything being sent to the ISY. If the connection was lost for some reason you should see errors in the PG3 for each attempt to contact the ISY.

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.