bpwwer

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.

I just uploaded an update. Restarting should automatically install in the update. There may still be one error in discover_nodes(). I don't know what is causing that but added addition information to the error message to help determine that.

There's nothing wrong with using DHCP reservations for a Polisy. Just don't allow the reservation to change once you start adding node servers.

An ISY (any ISY) can work with multiple instances/versions of Polyglot. Each node server slot on the ISY can be "Owned" by a different instance of Polyglot. But it's a one-to-one mapping between an ISY slot and a Polyglot. So yes, you can have both PG3 and PG2 connect to a single ISY. But No, PG3 cannot take over and manage a node server that was installed by PG2. PG3 and PG2 node servers aren't interchangeable. There is not a full migration utility/path from PG2 to PG3 at this time. However, in some cases, it may be possible to do a backup using PG2 and restore that backup using PG3 to migrate some node servers. This will only work if the node server name is the same for PG2 and PG3 and if the PG3 version is not free, you have to purchase the PG3 version first. It will try to move the configuration over as well, but there is no guarantee that the PG3 version will be able to use the same configuration that the PG2 version did.

When you do the ssh from the mac, try ssh -l admin 10.0.1.164 That's an ell, not one. Without the '-l admin' it's trying to log you in with a steve1 account which doesn't exist on the Polisy.

Your question is unclear. There are no changes with how Polyglot interacts with an 994i vs. interacts with an ISY on Polisy. It continues to work as it does today. Over time, the various components will have their support end-of-lifed, but the components themselves should continue to work as is. Eventually the 994i will stop getting firmware updates. Polyglot version 2 is not likely to get any more feature updates. Node servers for PG2 will also likely stop getting feature updates and new node servers will likely be available for PG3 only.

I don't think this effects the current version of PG2, but using 'localhost' isn't working with PG3 (because it isn't resolving correctly with node.js). Using 127.0.0.1 does work. Something to keep in mind if trying out PG3.

Go to the menu item "ISYs" You can try automatic discovery, but if that doesn't find it, just add a new ISY and enter the information for the ISY on Polisy. PG3 can switch between ISY's so if more than one is configured you'll see them all in this menu and can switch between them.

That screenshot indicates it not running. If what @Bumbershoot recommends above doesn't work, make sure it really is installed. sudo pkg install pg3 then if no errors sudo service pg3 start

PG2 is on port 80 or 443(default web port) PG3 is on port 3000 You should be able to use the same URL you use for PG2, but add port 3000. For example if your polisy is at ip address 192.168.1.5 you'd use: PG2 - https://192.168.1.5/ PG3 - https://192.168.1.5:3000/

@asbril Can you be more specific about what you changed? To reset PG3 to it's default: sudo service pg3 stop sudo rm /var/polyglot/pg3/pg3.db sudo service pg3 start That will clear the database. When PG3 starts and no database is present, it will create it with default values.

That's weird. When PG3 starts and the database doesn't exist, it looks at, in order: an environment variable PG3IP (which shouldn't be set) the system's current IP address if those are both blank, it uses the local address 127.0.0.1 Can you post (or pm me) a screen shot of where you're seeing the old IP address and what you get when you run 'ifconfig' on the Polisy?

I don't think just uninstalling and re-installing will solve it as I don't think the uninstall removes the database, but I could be wrong. I haven't tried uninstalling. You can also just remove/move the existing database and restart PG3 if you're comfortable with the Polisy command line. The database is in /var/polyglot/pg3/pg3.db so either remove or move that file and then run sudo services pg3 restart that should re-create the database and populate it with the new IP address.

@sjenkins Is it the PG3 ip address that's showing wrong or the ISY address? Those are two different things in two different menus on PG3. The PG3 IP address is set when PG3 is run for the very first time and there is no mechanism to change it later. The only way is to uninstall PG3 and remove the database so that when it is re-installed it starts with the new/correct IP address. The ISY IP address is configurable using the Edit ISY menu option. Completely unrelated, but we used to go boating on Lake Fenton when I was a kid. I grew up in Grand Blanc. Small world sometimes.

The ISY version issue is a know issue. Restarting everything will probably correct that as I think PG3 only checks that on startup. Changing the Polisy's IP address is not a trivial process. When a node server is installed on the ISY, it includes the IP address of the node server (PG3/Polisy) so that it can send status/commands to the node server. PG3 will also compare the value the ISY has with its own IP to see if it "owns" the node server. If you change the IP on the Polisy without changing the IP for each node server installed on the ISY, PG3 will assume it no longer owns those node servers and will delete them from it's database. Once deleted from the database, the only way to restore would be from a backup or by re-installing the node server after manually removing it from the ISY. Because of this, PG3 isn't designed adapt to it's IP address changing. It checks the IP address when it is first time it is run and saves that IP address in its database. The assumption is is that if you're changing the IP address you are starting over with a new install. Basically, changing the IP address isn't really supported on PG3 and while it may appear to be working fine now, things may fail later that will be hard to debug.

Agree with @Javi about Global Cache. I've used on for years without any issues. I also have a Quatech 4 port device that I use with Russound systems. It might be the specific firmware version, but it seems to give up on dhcp if the dhcp server is down when it tries to renew the lease. This means that I typically have to power cycle it manually after power outages.

Since the Polisy has USB ports, it should be possible to add a USB IR receiver and write a node server to interact with it. Not a direct replacement for the IR support in the 994i/IR but should be able to provide the functional equivalent. And, no, I'm not volunteering to write the node server at this time

The primary goal for PG3 was to provide a platform that allowed for commercial node servers. I.E. a way for third parties to publish and sell node servers. In addition to that it has some user visible new features: Ability to connect with multiple ISY's, not just one. Ability to install multiple copies of a node server. Sorting the node server store list by various columns. Simplified install process. Automatic updates on restart (similar to what PGC does). Additional control of node servers from the GUI (discover, load profile). There has also been a lot of work to revamp the API used by node servers to interact with PG3 so that node servers work a bit better. An example here is how configuration parameters are handled. With the new API it is easy to set the default values for configuration parameters and handle user changes to those dynamically. So you should no longer have node servers that say set xyz and then restart the node server.