bpwwer

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.

As I think I mentioned before, the goal is to have most of the existing PG2 node servers available in PG3, that's one of the gates to moving from a Beta product to a Production product. Whether or not the PG3 version is free, is up to the node server author. Like @Jimbostated, it's slow going because the node server authors are doing the conversion in their spare time. However, realize that you will be able to run both PG2 and PG3 on the Polisy (or PG2 on RPi), so you can continue using the PG2 versions for node servers that haven't been converted and switch over to PG3 versions as they become available and it makes sense to do so. Eventually, support for the PG2 versions will disappear, and how quickly that happens, is again, dependent on the individual node server authors. Because the production release date of PG3 is unknown, I expect to continue providing support (and bug fixes) for my PG2 node server for quite a while. But any new node servers will be PG3 only and new features will be PG3 only.

In no particular order, here's the list of node servers currently available in the PG3 store. Airscape JImBo $10 Airscape Node Server HusqvarnaMower Bob Paauwe $10 Husqvarna Mower: A node server for control of AutoMower Timedata Gordon Larsen $5 An ephemeris nodeserver for Polyglot V3 on Polisy PurpleAir Bob Paauwe $5 Add air quality data to the ISY994 WLED AutomationGeek free Interface between WLED and PG3. AERISWeather Bob Paauwe free Add AERISWeather service weather data to the ISY994 Roku Bob Paauwe $10 Control Roku media devices. PythonTemplate James Milne (Einstein.42) free Template Node Server Example-1 Bob paauwe free Example node server that simply increments a count. This is demonstrating how to create a simple node server that doesn't have a controller node and creates only a device node. WeatherBit Bob Paauwe $5 Add weather data from WeatherBit.io. Includes current conditions and daily forecasts NOAA Bob Paauwe $5 Add weather data to the ISY994 Daikin James Paul $5 Daikin Node Server to control Daikin Mini-Split System AMINEM Steven Bailey $5 / 12month Net Energy Utility Meter for Landis+Gy & Oncor models you can set the devisor in custom parameter nem_oncor. WeatherLink Bob Paauwe $10 Pull weather data from a Davis weather station using WeatherLink Live's local device API. UnifiPresence AutomationGeek $10 UniFi Device Network Presence Detection Example-2 Bob paauwe free Example node server that simply increments a count. This is demonstrating how to create a simple node server that has only a controller node. Climacell Bob Paauwe $5 Add weather data from Tomorrow.io. Includes current conditions and daily forecasts Volumio Bob paauwe $10 Add control of Volumio media players WeatherPoly Bob Paauwe $10 Receive weather data from locally configured station software like meteobridge, Cumulus, WeeWx, acuparse, etc. Example-3 Bob paauwe free Example node server that creates a user specified number of counter child nodes. Twinkly AutomationGeek free Twinkly Light WeatherFlow Bob Paauwe $10 Make WeatherFlow weather station data available to the ISY. BASIRRIGATION Steven Bailey $5 / 12month Universal Devices WiFi Controlled irrigation controller, with optional local camera for up to thirty six (36) irrigation Zones. It utilizes up to six (6) Contemporary Controls BASpi-6u6r or the BASpi-Edge-6u6r. Please see documentation. Backup Bob Paauwe free Save and restore lighting type device status OpenWeatherMap Bob Paauwe $5 Add weather data from OpenWeatherMap.org. Includes current conditions and daily forecasts RainMachine Gordon Larsen $20 Nodeserver for the Green Electronics RainMachine BASPOOL Steven Bailey $15 / 12month Universal Devices Wifi Ethernet Pool Controller using the Contemporary Controls BASpi-6u6r or the BASpi-Edge-6u6r control Devices. You can have up to (6) pools using this Node Server and it is a great fit for a conventional Time Clock controlled pool upgrades. Please see GitHub documentation for details on setup. Acurite James Paul free A Node Server for retrieving AcuRite Access Remote data for AcuRite devices BASGARAGE Steven Bailey $5 / 12month WiFi Controlled Garage door opener momentary push button duplicator, with optional local camera for up to six (6) doors. FlumeWater JimBo $10 FlumeWater Nodeserver VUE Bob paauwe free Monitor your smart meter with Emporia VUE Sense AutomationGeek free Sense Home Energy Monitoring MySmartBlinds AutomationGeek free MySmartBlinds *Only support Blind and required a Bridge* Eagle-200 Bob Paauwe free Smart Home Energy Monitor. Monitor home electricity use. AmbientWeather Bob Paauwe $10 Pull weather data from weather stations connected to Ambient Weather's ambientweather.net servers

Thanks everyone for the info. It was helpful to see that my pricing models seem to be aligned with expectations to most extents. Hopefully other node server authors will see this and get some value from it as well. I do agree about preferring non-subscription pricing, but I can also envision some cases where it could be required. A node server that accesses data from a data service that requires a paid account and a monthly subscription to access the data would mean that monthly subscription cost would need to be passed to the node server purchasers. Otherwise the node server author would end up paying out-of-pocket at some point.

Yes. I've added a couple of PG3 only node servers for integrating with smart meter energy monitors. There might be a couple of others also, I haven't really looked. Most are simple conversion from PG2 to PG3. For some of mine, I've tried to make the PG3 version better in some way to help justify the price. For example, the WeatherFlow node server for PG3 support the forecast data, the PG2 version does not. The PG3 version of the Volumio node server supports multiple Volumio devices, the PG2 version supports only one.