bpwwer

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.

I believe PG3 may be installed by default now with the latest updates. Certainly, once it is installed, it can be updated using the standard pkg commands or via the Polyglot (PG2) menu items to update the Polisy. Soon those same menu items will be available on PG3. I've been posting announcements of updated versions (and the changes) to a Slack channel for PG3 node server developers. Seems like more people are interested in it so I'll have to start posting those here as well. Occasionally, the updates to PG3 have broken existing PG3 installations. I've tried hard to minimize this, but it is still a possibility. However, I don't know of any changes on the horizon that would do this. Most of my effort going forward will be to get existing node servers ported to work on PG3.

There are a couple of node servers that make use of specific hardware features of the RPi that won't be ported to PG3 as they just can't work there. Currently, you can use the Polyglot backup process to backup PG2 node servers and use the PG3 restore from PG2 backup to restore them on PG3. However, there are things to note about this process. 1. The node server must exist in the PG3 store. It can't restore node servers that don't exist for PG3. 2. The node server in PG3 must have the same name as the node server in PG2. If the name has changed, it won't be able to find it under the new name. 3. If the node server in PG3 is not a free node server, you'll need a license for the PG3 version or it won't restore. 4. Configuration parameters will only carry over if they are the same. If the PG3 configuration is different, it can't translate.

You can change the password but not the username. Polyglot can only have one user account and currently PG3 doesn't allow you to change that.

It doesn't replace the existing PG2 installation. That remains active. It adds a second dashboard at a slightly different web address. https://<polisy ip>:443/ ==> Your normal PG2 dashboard (or https://<polisy ip>/) https://<polisy ip>:3000/ ==> The PG3 dashboard

Yes, it available with recent Polisy updates. You'll have to install it from the ssh command line. 1. Make sure your Polisy is up-to-date sudo pkg update sudo pkg upgrade 2. Install PG3 sudo pkg install pg3 sudo service pg3 enable sudo service pg3 start Once it is installed, you can access it at https://<your polisy's IP>:3000/ It has the standard default login of 'admin' / 'admin'

No, but given that you aren't paying for any of them, you are always getting what you paid for. I disagree with the conclusion. Do you really expect a single entity to provide better support for 100's of different devices they don't have and don't use than individuals that actually have and use the devices? My experience is that the other controller manufacturers either can't support all the different devices or provide the minimum of support so they can claim they support them. UDI provides a platform and API, the community is currently providing Polyglot and device support. This is changing as UDI takes a more active role in developing and supporting the third party development community. That's an interesting question as the Polisy is really a future ISY product, not the current ISY product. So I believe most folks are taking the "plunge" with Polisy now so they can be better prepared for the future, not based on what it can do today. If you don't want to run pre-release/beta software, the Polisy is really just a nice piece of hardware with Polyglot pre-installed. Both the Polisy and an RPi with Polyglot installed give the ISY the ability to interact with other devices and services beyond the support for Insteon and Z-Wave devices built into the ISY. If you need support any other device/service, then node servers are the only option you have. And I use the term "node servers" specifically because that's a reference to the API that the ISY uses to interact with other devices. Polyglot (on either Polisy or RPi) is a framework that supports many different device node servers. It is community developed and supported and is not well documented. You basically have to install it to see what is available and (as others have pointed out) the documentation for each. NodeLink is another framework that supports device node servers. It was developed by a forum member and you can find more information about it here in the forums. Polyglot Cloud is a cloud version of Polyglot that runs on machines in the cloud instead of a local (Polisy or RPi) hardware device. It supports a subset of the node servers that Polyglot has. In a few cases, there have been individual node servers developed that aren't part of any framework. But I believe most of these have been abandoned in favor of NodeLink or Polyglot. Polyglot version 3 is currently in development and is an evolution of the current Polyglot. The main goal is to provide a better customer experience and allow third party developers to be compensated for their efforts, should they desire. Yes.

Keep in mind that with the current release of Polyglot, all node servers are free. They are mostly developed by individuals that create them for the equipment they own, to do what they want to do. And then they do their best to support others who want to use them in their spare time without any compensation. I state this simply so that you have the right expectations set. That's not to say that the existing node servers aren't good. Most of them are very well written and do what they are intended to do.

To answer the question about running multiple copies of the rainmachine node server on PG3. That is true. PG3 will allow for multiple copies of the same node server to run so you would be able to support both controllers. It is also possible to run two copies of the same node server on PG2, but you would have to manually install one of the copies and give it a different name. When PG2 installs a node server from the store, it uses the node server name as the location to do the installation (hence you can only install it once from the store).

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.