bpwwer

Polyglot is not the only way to install and run node servers, there are others. However, Polyglot is the most used method. You're right in that when using Polyglot, it is managing the installation/removal, starting, stopping, and configuring of node servers. It tires to make that fairly easy. Polyglot version 2.x is designed to work with only one ISY at a time. You can switch it to another, as you've tried, but none of the node server configuration transfers to the new ISY when you do that and you're basically starting over as if it was a new install. Once you switch, Polyglot will remove all the old configuration (from Polyglot, not the old ISY) so you are not able to switch it back to the old ISY without again re-installing the node servers.

Yes, in theory. I believe it can do name resolution for the ISY IP but I haven't tried that. But the connection would have to work both ways. PG3 will connect to the ISY via an IP address/port number. As long as the IP/port is reachable, it will work. But the ISY also needs to communicate with PG3 (mainly to send commands back) so it needs to be to reach the http(s) IP and port that PG3 is using.

Unfortunately, that's not how Polyglot works. A node server is a program that translates data between a device and the ISY. It puts the data in a form that the ISY can consume, and it takes commands from the ISY and puts them in a form that the device understands. Polyglot is designed to help manage node servers and handle some of the common tasks that every node server needs to do. When Polyglot "installs" a node server, what it is really doing is configuring the ISY, setting up communication channels, and starting the node server program running. When Polyglot starts, it queries the ISY for what node servers have been configured there and then sets up the communication channels and starts the node server program running. Once you change the ISY and restart Polyglot, it queries the new ISY for what node servers have been configured. The new ISY doesn't have any node servers configured, so it returns none. Polyglot then thinks everything it has configured has been removed, so it clears all the previously installed node servers. The ISY is considered the definitive source of node server installs, not Polyglot. Unless you have a backup of the Polyglot database or did a backup of the node servers using the Polyglot backup feature, you are going to have to start over and re-install the node servers.

Not with PG2. It can only connect to one ISY. You'd have to run an additional copy of Polyglot on something else like a RPi and have one connected to your old ISY and one connected to the ISY on Polisy. PG3 will be able to do this, but it's not production ready at this point.

I did this in my HomeSeer plugin for ISY. The ISY does send the information on what devices are are programmed to be respond to the various configured scenes so you can create that mapping. I.E. scene # => list of devices and levels The initially for each scene, loop through the devices to see if they match the scene or not. That would give me the initial state of the scene (on/off). Then anytime a device status change happened, I'd have to check every scene that it was a member of and do the same check to detect if the scene state changed. It's been a while since I worked on that plug-in so I'd have to review the code to be more detailed in how it was implemented. For Insteon, the limit is something around 255 scenes so at least it is somewhat constrained. Also, I think the ISY does send out updates if the scene is adjusted so you can keep track of that and adjust internally as needed.

Insteon scenes, as defined by the Insteon protocol don't have status. The controller of the scene has zero knowledge of what the scene configuration looks like, it simply sends a command. Responders are then programmed to look for commands and do something. The controller has no idea which devices will respond nor how those that do, will respond. But it seem like everyone wants to see scene status so most software will try to come up with something to represent a scene's status. And because different people have different ideas of what scene status should be (since it is by the very nature of Insteon, undefined) we see different implementations of scene status. If I have to provide scene status, I choose to represent a scene as ON if and only if all the devices that respond to the scene on command are in the state that is defined for that scene command. If not all the devices are in the proper state, the scene is not "ON".

If I understand correctly ... You have a i994 controlling a number of Insteon devices. You added a Polisy running Polyglot and ISY so now you have 2 ISY controllers (the i994 and Polisy). You've configured Polyglot running on Polisy to connect to the i994 controller. If those above statements are true, then I believe you've got things set up correctly, but just misunderstand what Polyglot should be doing. Polyglot doesn't replace the ISY admin console. It is a separate frame work to manage third party plug-ins for other devices and services. Insteon devices (and z-wave devices) are built in to the ISY but if you want the i994 ISY to control say a Wi-Fi light bulb, then you'd add a node server (plug-in) to Polyglot for that brand of bulb. Then Polyglot + the node server will act as a translator so that you can control the light bulb from the admin console (or programs) just like you would an Insteon LampLinc device. You use Polyglot (what you're calling Polisy above) to setup/configure these other devices and services you see in the Node Server Store menu. Once configured, you'd continue to use the admin console to add them to programs, view their status, or manually control them, just like you have been with Insteon or Z-Wave devices.

Unmanaged means that there is an entry in the database, for the node server slot, but whatever is in that node server slot is not being controlled by this instance of Polyglot. The way something gets in the database is when Polyglot queries the ISY for what node servers are installed, it compares what's on that list with what it knows about. If there are entries on the list that it does not know about, they are added to the database and marked as unmanaged. Polyglot (PG3), will query the ISY every 5 minutes for the list of node servers. If there's an entry in the database that doesn't match an entry that the ISY reports, it will be removed from the database. So if this isn't going away, that means the ISY is reporting that there is something installed (in this case) in slot 10. Check the ISY node server menu -> configure and look at slot 10, if it doesn't say (empty) next to it, then there's something installed there. Select that slot and then click Delete. Within 5 minutes after doing that, PG3 should notice that it's gone.

I've seen Polisy and Polyglot used somewhat interchangeably because the Polisy ships with, and boots running Polyglot by default. So for many people, Polyglot is what they see and use when they have a Polisy. The same way we all used to refer to ISY and the i994 as just the ISY since it was/is a combined software/hardware device. You have to look at the context the terms are being used in to determine what the poster is really talking about. So, yeah, confusing. The Polisy was designed to be just one piece of hardware running all the various software components (hence the name Pol[yglot]isy).

I did the same thing, with similar results. Motion doesn't appear to work but I am getting temp, humidity, battery and luminance. I'm also powering mine via USB.

Almost right. ISY is software that manages device nodes and has a rules engine for if/then type programming. This was developed by UDI and includes management of Insteon, Z-wave type devices nodes. i994 is a small hardware device that runs the ISY software. This hardware was also developed and is sold by UDI. Polisy is a new hardware device. It is much more powerful hardware than the i994. It is also able to run the ISY software. Currently the the ISY software running on Polisy is a pre-production release version (alpha/beta). Polygot-V2 is software that interacts between other types of devices and services and the ISY software so that the ISY software sees those devices as device nodes that it can manage. Polyglot-V2 is open source software. Polyglot uses a "plug-in" type architecture so that it can expand to support many different types of devices and services. Those plug-ins are called "node servers". Typically, third part developers create the "node servers" that Polyglot uses. UDI has commissioned specific node servers to be written but otherwise is not involved in the development of node servers. Polyglot-V2 can run on a Polisy, a Raspberry PI, and many other computers. Polyglot-V3 is an evolution of Polyglot-V2 to provide a better framework with things like a payment processing back-end so that third party developers that create node servers are able to sell them and get compensated for their efforts. Polyglot-V3 is not open source and is being developed by UDI. Polyglot-V3 will only run on a Polisy. It is currently a pre-production release (alpha). And yes, this information should be converted to marketing material and posted on the website, I agree.

Context? This thread is about PG3 MQTT errors and PG3 doesn't have a user configurable MQTT port setting. This looks like it is probably from PG2, in which case the default setting is 1883.

There may be multiple issues happening. The first is that Polyglot is unable to connect to the ISY. You'll have to figure out why before anything else will work. The bit of the log you've posted doesn't seem to be referencing that issue. I'd start with verifying that the username and password for the ISY are set correctly (reset them, save, and maybe restart polyglot). If it still isn't connecting, look at the beginning of the polyglot log file for more information about why. Second, it looks like there may be more than one instance of WeatherLink running. When more than one instance is running you'll get constant connect/disconnect MQTT messages as they keep fighting with each other for a connection to Polyglot. Either reboot the Polisy or from a command shell run 'ps -auxww | grep -i weatherlink' and then 'sudo kill <pid>' for all that are running.

The latest PG3 version depends on node 17.0.1 and for some reason your upgrade removed node 17.0.1 and replaced it with node 16.13.0. You might have to specifically install PG3 which would then delete node 16.13 and re-install node 17.0.1. We're still working on getting the packaging dependencies correct so I suspect that this is just a one-time glitch.

I can't speak to the differences between v1 and v2 as I never used v1. The major change in v3 is a framework that allows third party developers to charge for the node servers they create. In addition v3 is able to manage multiple ISYs instead of just one. It also can also manage multiple copies of the same node server. There are a lot of internal changes to try and improve reliability and make it easier to create node servers.

When it shows the "not connected to server" message, it means that the user interface code running on the browser is not able to connect with the Polyglot instance. Because it is not connected, it is not able to receive any of the configuration information from Polyglot nor is it able send any updated information there to be saved. If refreshing/reloading the browser page doesn't cause it to reconnect, you'll have to look at the logs to figure out why it isn't able to connect. Both the Polyglot log and the browser's console log (developers tools on the browser) should provide some help in determining that.

The latest release is version 2.0.1. This is the first release that supports PG3. The node layout has changed from PG2 versions of the Ambient Weather node servers. You likely need to fix any programs that are based on Ambient Weather data when migrating to PG3. Pulls data from http://www.ambientweather.com and makes it available to the ISY. This node server uses an API Key associated with your ambient weather account to query the ambient weather servers for your weather stations. Supports multiple weather stations with multiple sensors. Nodes will be dynamically created for each station and each sensor attached to the station. The ambient weather servers are polled at the short poll interval (in seconds). The servers do rate limit so it is recommended to poll at a minimum of 60 seconds.

Just to clarify, you're using Polyglot cloud right? Local Polyglot has a drop down selector where you select the slot you want to install to. Or are you saying that feature is broken? And, no, you can't edit existing node server slots. You would have to remove and re-adding to a different slot.

I believe the root cause of this has been determined. It looks like the most recent version of node broke something with host name resolution. Specifically it fails to properly resolve 'localhost' to 127.0.0.1. To resolve the issue in PG3, replace 'localhost' in the ISY configuration IP field with '127.0.0.1' and save it.

I've been able to reproduce the errors by changing the ISY configuration in PG3 to use an incorrect port. You might want to try just re-entering the port number and saving from the ISY/edit current ISY screen in PG3.

Try restarting the ISY. This looks like the same issue reported on Slack and for that case, it appears the ISY is simply refusing connections from PG3.

I believe that most of the devices that @Goose66is talking about never publish an official API. They have an internal API that works with their apps(s) and the node server (or library it uses) has reverse engineered the API. In this case, the manufacturer isn't under any obligation to notify customers when the API changes so the changes do cause a support problem for the node server. I'm not sure what the "right" or "best" answer is for this. Creating node servers using unofficial API's is potentially a headache for the developer and more expensive for the customer. This is probably something we should do a better job of documenting. Knowing the node server uses an unofficial API may deter people from buying that equipment in favor of supporting a different manufacturer that does publish an official API.

True. I believe the very long term plan is to combine ISY and Polyglot so it's just one piece of software and one user interface.

Good question! At a high level, the ISY (standalone or running on Polisy) has an API that node servers use to interact with the ISY. That API hasn't changed and is used by PG2, PG3, and NodeLink (and maybe some other stand alone node servers). PG2, PG3, and NodeLink are all node server managers. They sit between the ISY and node servers. They provide some extra capabilities and handle some of the common tasks that node servers have to do. For example, when a node server is installed, there are some files that describe the nodes that the node server will create. Those files need to be uploaded to the ISY. The node server manager does that so each individual node server doesn't have to have the code to upload it's files. From a high level architecture, PG2 and PG3 are very similar. Both communicate with the ISY in the same way, both have similar user interfaces, and both provide a similar API to interact with the node servers. PG3 supports all the same basic core functionality that PG2 does. The main differences are some new core functionality in PG3, a lot of minor fixes and improvements and an improved API to interact with node servers. Probably the biggest user visible change was adding support for licensed/purchased node servers. A lot of the changes have to do with the internal structure of node servers with the goal to make them easier to write, easier to maintain, and more stable. There were internal design choices in PG2 that made it hard to improve and maintain compatibility. Some of that was tried when PGC was created but we just ended up with bunch of "if running on PGC do this, else do that" code in node servers. Given the scope of the changes, PG3 seemed like the right time to break compatibility to make node servers better going forward.

Currently, the node server license is tied to the Polisy so if you have multiple Polisys, you need multiple licenses. However, you can run multiple copies of the same node server on the same Polisy under one license and one Polisy can manage node servers for multiple ISYs.