bpwwer

You have to restart using ssh, the menu item "Restart Polyglot 3" doesn't work yet. The ssh command is sudo service pg3 restart

Don't know about PG2, I would think the versions should match also. For PG3, you need to restart it. Updating installs the new version (which when the browser reloads the page, gets the new frontend files) But the backend continues to run the old version until it is restarted. Once restarted, it should be running the new version.

The PG2 update option should also update PG3. I haven't tried this, but will with the next release. You will have to restart PG3 after it has been updated.

We use Pandora almost exclusively and the support seems pretty good, but not perfect. I've also played around with Spotify but haven't switched over yet to see how it works for long periods. My wife will it playing for most of the day some days. The node server only checks on startup. It queries for the stations and then builds the definitions for the ISY based on that. Because those station lists are dynamic and the ISY really isn't, we have to take a snapshot and live with it. In order for the ISY to present the source list, it has to have a mapping of source names to numbers. The ISY uses the number in the programs. So if you change list and change the mapping, the number no longer points to the same source, and programs are broken. There's really not much the node server can do about that.

Thanks @garybixler, I appreciate the time to post all those details. I've found the problem and fixed it in version 2.0.3 All you should need to do is restart to get the new version.

Playlists, favorites, Pandora stations and Spotify stations. I probably didn't test with anything other than Pandora and Spotify so it's possible the others are broken. It should be possible to add other sources as well, but the interface we have to work with, doesn't really handle large lists that well. I'm not sure I'd like to try and add all albums or artists to the list for example. I haven't played with webradio, but maybe the favorites or my web radio selections from there would be OK.

The PG3 version should have both nodes too. I just pushed out version 2.0.2. I made a change that should prevent the crash, but I don't know why the node wasn't created. If it doesn't create the node when you restart, can you can post the first 30 seconds of the log after the restart?

@garybixlerThat's strange. It looks like this was called from a query, is that right? It crashed because it didn't find an 'indoor' node. Based on the data just before that, it looks like you have an indoor sensor so should have an indoor node. Do you have an indoor node? I don't see anything wrong in the code that would cause this. It's like the indoor node disappeared before it tried to update the node values.

I've seen cases where the message persist after you make the configuration changes and save. Something doesn't refresh and UI doesn't realize that the core is configured and properly communicating with the ISY. This could be caused by the browser caching info and not realizing that new information is available so in many cases a refresh or reload of the browser window will bring them back in sync.

It was probably a coincidence since one shouldn't have any effect on the other. First step is to always check the logs. The node server log will have the info needed to know what the next step is. Typically, if a node server stops reporting data, it is because something failed and the log will tell us what it was that failed. If it is something in the node server, the developer will need that info to help find and fix the problem. If it is with the service or device then you'll know where to look next. In many cases, simply restarting the node server will get things working again. So that's the second step. If restarting the node server doesn't have any effect someone will need to know what the log is reporting. You must have, and be logged into your UDI Portal account to purchase node servers for PG3. Click the button at the top of the store page that says "Log into Portal". Your Portal account will contain the information on what node servers you've purchased.

The node server developer has the option to specify a trial period so users can "try before buying". Like @Jimbo, I've configured all of mine to have a 30 day trial available as one of the "purchase" options. The system does track this so that you can only "purchase" one trial period. With the latest PG3 release, there is also the concept of a 'beta' node server store. This will give developers an option to release early/test versions. It's not fully fleshed out yet, but is another option to test before purchasing.

I'm not sure that's the problem, Node server licenses are tied to the Polisy running PG3. I'm not sure if that's related to the link between portal account and ISY. For the 'Purchase' button to show up for node servers in PG3, PG3 simply has to receive confirmation that you have a valid portal account. When you click on the "Log into Portal" button, you should get redirected to the portal login screen. Once you log in, it should redirect back to the PG3 screen and the store entries should now have a 'Purchase' button. Are you getting this far? When you press the 'Purchase' button to purchase a node server, it should again, redirect to the Portal purchasing screen. If you're Polisy is not registered, you are given the option to register it. You then proceed to either purchase or cancel.

You have to purchase the node server before you can install it. Free node servers don't require a purchase so they are always available to install. To purchase a node server, you have to be logged into your Portal account via PG3 so it knows who to charge for the node server. Use the "Log into Portal" button at the top. Once you log in, it should populate all of those with a "Purchase" button that you can use to purchase the node server. For node servers you have purchased (and free node servers), you'll get an "Install" button.

The "ISYs" menu lets you add, edit, and remove which ISYs PG3 will work with. You'd also use this menu to select which ISY to display on the dashboard, if you connect to more than one. PG3 can work with multiple ISYs but will only show one on the dashboard. You have to switch between them to manage multiple ISYs.

I thought I answered this in another thread ... The Polisy configuration menu doesn't work in PG3, there's a menu item but no code to do any actual configuration. @Michel Kohanimsays we don't need this menu option for PG3 so it will be removed in the next release.

Some answers: 4. You should be able to use the GUI update. Once the PG3 package is installed, it will update with the standard package update commands. 5. Yes. If you 'stop' the node server on PG2, and then install it on PG3 you could switch back if necessary. However, the PG3 install may or may not take over the existing nodes, that's going to depend on how the node server was designed and I suspect that most are NOT designed that way. You can restore all the node servers (that exist) from a PG2 backup with PG3, but that's not perfect and you can't move one at a time. There are plans to add the ability to take over nodes as a feature of PG3, but that feature hasn't been written yet. 6. The limit is in the ISY. A single ISY can only have 25 node servers. 7. Yes, each is separate. 8. The goal is to port every node server to PG3 with the only exception being node servers that are specific to RPi hardware. I.E. the GPIO node server and ones that work with bluetooth are the only ones I'm aware of that won't be ported. 9. Keep in mind that PG3 is currently just a pre-release. There are a few areas that need work and it will be changing. I'll make every effort to not break existing installations with new updates, but I can't guarantee that it won't happen.

I'm not seeing any problems with the node server on my installation. The API key I was given to test with is for a setup with 3 stations each of which has various sensors and they are all reporting correctly. If it is saying the API key is invalid, then it is not going to initialize properly which may be part of the problem. Can you generate a key for me and PM it to me? The PG3 node server is different from both of the PG2 versions. The PG2 versions were only able to support specific station types and sensor types, because of the design used, new station types or sensor types had to be added to the code as we were made aware of them. The PG3 version is designed to create the nodes based on what shows up in the data from AmbientWeather. So it should adapt automatically to new stations and new sensors. This also means that the way the data is organized into nodes is different. Instead of having a node for indoor temperature, it has a indoor node with the temperature being one of the values of that node. The indoor node will contain values for what types of sensors the indoor device has (temp, humidity, etc.). Your screen shot for the PG3 version looks correct. Based on what I see above, your indoor node should have temperature, dewpoint, humidity, feelslike, and battery. The MAC address is used to generate a node address. To do that, it removes the ':' and '0' characters. This is to make it work with ISY limitations on how a node address is formatted. Otherwise, the node server doesn't care what the MAC address is.

It sounds like the correct nodes based on what you've said. The node names come from the data. 'main' is probably the WS-2000 sensors 'indoor' is probably the additional indoor sensor 'five' and 'two' are probably the air quality, one of those is indoor sensors and the other outdoor. When Ambient Weather sends the data, it suffixes the various keys with which device the data is from but it uses things like 'temp' for the main temperature, 'tempin' for an indoor temperature, 'temp2', 'temp3', etc. for other temperature sensors. The node server organizes it by the suffix, 'main' for values with no suffix, 'indoor' for values with 'in' suffix, 'five' for sensors with '5' suffix. That was the best way I could think of to organize it without making you manually enter what every values means.

I just installed and tested and it is working correctly. You'll have to provide specific details about what is not working for you. I can't see your station(s), your data, or what it's doing on your system. AmbientWeather has a lot of different hardware with different configurations and I'm only able to test with a small sub-set of that. Please provide data on the hardware. Also check the log for errors.

The first error: 2022-01-11 11:50:45,330 Thread-3 udi_interface ERROR wll:discover_nodes: Failed to query WLL device at http://192.168.30.63/v1/current_conditions: HTTPConnectionPool(host='192.168.30.63', port=80): Max retries exceeded with url: /v1/current_conditions (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x802f13c10>: Failed to establish a new connection: [Errno 61] Connection refused')) is fatal, it is saying that it can't establish a connection to the WeatherLinkLive device. It should be better about not trying to continue working after that because if it can't connect, nothing is going to work.

Polisy settings has never worked in PG3. The menu item was just enabled in the latest release but there's no support in the code for that option.

@jkosharek I'm not sure what you're asking for ideas about. The PG3 node server is a replacement for the two different Ambient node servers available on PG2 and as such, it is different from both. It creates nodes based on the data it gets from AmbientWeather.net. There should be a node for each sensor it finds.

I expect the first error to still happen wll:discover_nodes: Failed to query WLL device at http://192.168.30.63/v1/current_conditions But I added some additional info to help narrow down what is failing. If you're still getting that do you see some additional info? If so, can you post that?

You're still seeing the "Controller object has no attributes nodes" errors? Those should be gone now. There are 3 different components with different version numbers PG3 version (currently 3.0.36) There's both a frontend and backend version, they should match. These are shown in the bottom footer of each PG3 screen. The node server version. For WLL, the current version is 2.0.1, you should see this in the node server details screen, right underneath the connection status. You'll also see this in the Node Server Store listing next to the node server name. The udi_interface version. This is the API version being used for the node server to communicate with PG3. You see that in the log as you posted above. Current version of this is 3.0.31. This can help developers debug issues.

@garybixler @dbwarner5 How compatible a PG3 node server's nodes are to PG2's, depends on the node server and if changes where made to the node structure in the PG3 version. For the Wemo node server, I removed the controller node as it wasn't needed in the PG3 version. The device nodes are the same between versions. So if the node server is restore onto PG3 from a PG2 backup, it should take over the existing nodes, except for the controller node which will end up as an orphaned node in PG3. I don't have any insight into the Ecobee node servers so I don't know if it will be possible to migrate that one or not. If you're not restoring from a backup, you'll have to go through and fix programs manually so it doesn't matter which slot is used for the PG3 version. The slot number is part of the identification of a node server node, so it does matter. You can have the same node server installed in multiple slots and they are unique because of the different slots.