bpwwer

When the node server sends data that is different from the cached values, Polyglot is supposed to send that to the ISY. I believe query (in this version) simply sends the cached values to the ISY. Getting the data to the ISY is a two step process 1) the node server queries NOAA and sends the data to Polyglot 2) polyglot compares the data with cached values and if different sends it to the ISY So short answer, is yes, when it queried new data, it should have updated the ISY automatically.

I started the node sever and it seemed to pull valid data so it could certainly have been a temporary outage. Polyglot caches the more recent data sent to the ISY so if the node server stops receiving anything, that's what it will still get when queried. By convention, the node server status reflects the status of the node server itself, not the service or device it's connected to. That's probably not right, but it's how most (all) of the polyglot based node servers work. PG3 actually embeds this so that it automatically reports the node server executable running status by default.

No, it will be a separate (different and empty) ISY. Since the ISY software on Polisy doesn't support z-wave yet you won't be able to do much with it at this time. You should be able to connect node servers to it, but the existing Polyglot can only connect to one ISY so you'd need a separate instance of Polyglot (I.E. running on a separate RPi) in addition to your Polisy to do that. I believe you could run PGC based node servers on it if you have a portal account (but I haven't tried). That might be a good thing for someone to test out. As @Michel Kohanimstated when he announced this, he's making it available to get some more wide spread testing, it's not ready for production use. You basically need a separate, non-production, environment to make use of it.

Installing the ISY software on the Polisy gives you another ISY box, independent of any others you own. So unless you move the PLM and re-link all your Insteon devices and re-create all your programs/variables and re-install all your node servers to the new ISY (which I don't recommend you do at this time), you continue to use your existing ISY as you normally would. ISY on Polisy is available to experiment with. On that note, I've installed the ISY software and the latest PG3 software on a Polisy and loaded up a PG3 node server. So far that is all working. It's pretty exciting to see all the components working together and running on one box.

It was a problem with my translation from the web page to the ISY profile file. I've fixed it already.

Ah, so probably no alerts are available at this time for that region. That looks like the same list I used. About 269 different conditions. It looks like there's an issue where "Light Rain" and "Drizzle" got combined as one condition when they should be two separate conditions.

Unknown means that whatever they are sending, isn't something that was documented as a valid condition. Some of the NOAA data is frustratingly difficult to deal with as they do a very poor job of documenting what all the possible conditions are. The ISY can only deal with fixed values so every condition needs to be pre-defined and mapped to a numeric value for use with the ISY. To get the alert data you'd have to configure the node server with an alert area which it doesn't look like you did.

Looks like they did remove it from the API. I'll update the README, thanks for pointing that out. The PG3 WeatherFlow node server has the forecast already done but I don't plan to upgrade the PG2 version. Right now I'm only doing bug-fix changes to the PG2 based node servers as I try to get them all ported over to PG3.

WeatherFlow runs proprietary algorithms on the data sent by the station and reports that "corrected" data in the app. The node server does not do any correction of the data and simply reports what the stations has reported. The correction is mainly done for rainfall and lightning. However, I don't see anything "wrong" with the rain data. Both are reporting a daily value of 0.6 inches. For lightning, there is a known issue in the Tempest firmware where it seems to miss a lot of lightning strikes and WeatherFlow pulls that data from other sources and reports it in the App. If you configure the node server to pull the data from the WeatherFlow servers instead of from your Tempest directly, it will get the corrected values. However, you are then depending on the cloud service.

I created something like what you want but it is designed to run full screen in a browser and provides status of mostly node server based devices. But the technique would also work for a small browser window and normal switch/lighting devices as well. I have a web page served from my local web server that makes a websocket connection with the ISY. It monitors that connection for specific events and updates the appropriate elements on the web page with the new values. I believe there is an example of this in the wiki (or maybe the forum) and the ISY itself can host the web page (I think you need the network module). It would also be easy to use this technique to create a desktop app with something like C# in .net (or whatever your language of choice is). The code to do this is pretty simple. WS = open websocket connection to ISY on WS event: # get event details (event type, device, action) if event type is something we care about: if device is one we want to monitor: display new action value for event You probably won't find a pre-existing solution because to do something like in a generic manner means you're going to end up re-writing the admin console / dashboard which is a lot more complicated. Plus, what you want to display and how is probably very specific to your environment. I could give you my javascript/web page, but by the time you modified it for what you wanted, you'd probably have changed almost every line. If you're curious, I did already post screen shot and code at

Starting on Friday, there was a problem with the store. I caused that when I updated something for the local Polyglot store and didn't realize that it would effect PCG. I won't go into the details, but that issue has been resolved. While @Michel Kohanimand I were trying to determine the store problem, we did something to cause the second problem, happening now. Neither of us really understand PGC all that well so we're trying to figure it out as we go. Does anyone know how to enable developer tools on their browser and report what it's doing when it's spinning? The basics are (at least on chrome/opera): - enable Developer Tools on the PGC page. - select the network tab - reload the PGC page I'd like to see the last couple of messages in the console. For me, it hangs after requesting the list of ISYs attached to my account. Something eventually times out and the page loads, but the request for the list of ISYs is taking anywhere from 50 minutes to 20 hours before it returns the list. My list of ISYs contains a Polisy, because that will be required for PG3 and that seems to confuse PGC so I'm curious if what everyone else is seeing is related to the getIsys request or if it's something else that I'm not seeing because I'm special.

I let mine sit there for a while and it eventually populated the ISY menu and seems to be working fine now (unless I refresh the ISY list). I don't think I have access to view/modify anything related to the running cloud instances so I can't do much else at this point.

This sounds similar to what I'm seeing too, I thought it might just be me since I have an "ISY" entry in the database that's special for PG3 testing, but it sounds like other's are having issues getting their ISY entry out of the database too. I'm looking into it.

@thruster999can you re-try connecting again? There were some issues with PGC yesterday that should be resolved now.

Yes. Click on the monitor and it brings up the green box with sensor information. At the bottom of that box is a link to "Get this widget". If you hover over that link, there will be an ID with the sensor number shown. For example : <div id='PurpleAirWidget_68719_module_AQI_conversion_C0_average_10_layer_standard'>Loading PurpleAir Widget...</div> <script src='https://www.purpleair.com/pa.widget.js?key=RRFYHSR646VW2YIQ&module=AQI&conversion=C0&average=10&layer=standard&container=PurpleAirWidget_68719_module_AQI_conversion_C0_average_10_layer_standard'></script> The sensor ID is the 68719.

Thanks for reporting it! I get annoyed when things are documented well because then I have to try and defend why it may not be working as user's expect. Not annoyed at you, at NOAA. If you're concerned about outdoor air quality, look into Purple Air. There are a lot people (and organizations) that have deployed them and many have their data accessible to the public. Using my Purple Air node server you can access that data and generate your own alerts based on a nearby sensor. Or buy your own, that's what I did because we've had a lot of smokey days from the CA wildfires.

I'm not ignoring anything, but because the ISY only works with numeric values and not random strings I can only process events that are documented. I got the list of possible events from https://www.weather.gov/nwr/eventcodes and that doesn't include anything for air quality.

The program is evaluated (run) when something in the 'if' part is triggered. at 5:21ish, the dusk/dawn sensor is triggered, the program is run and the if statement evaluates to FALSE (sensor switched off is TRUE but time range is FALSE) so the ELSE clause is executed. at 6:00am the program is run again and the if statement evaluates to FALSE (sensor switched off is FALSE but time range is TRUE) so, again, the ELSE clause is executed. at 9:30am the program is run again and the if statement evaluates to FALSE (sensor switched off is FALSE but time range is TRUE (maybe) so, again, the ELSE clause is executed. The confusion is that the condition is re-evaluated when any of the conditions change, not when all the conditions are TRUE. The conditions control which part of the program is executed (THEN or ELSE), not if the program is run. It sounds like what you might need two programs to accomplish this because you're trying to do a nested condition, but the ISY can't do that. You want: if sensor switch off then if time in range send text else send email On the ISY you can simulate that with: if sensor switched off and time in range then send text if sensor switched off and time outside range then send email

The Polisy Pro is not running Linux, it's running FreeBSD. They are different operating systems. While the hardware (and FreeBSD) are both capable of running a general purpose web server, I don't believe that UDI packages up any of the general purpose web server programs or other related software necessary to run one. Also, if you're using the Polisy to run Polyglot, Polyglot is a custom web server so you'd have to careful not to have anything you install conflict with that. My first question would be why do you want a publicly accessible web server on the Internet? Maintaining a public facing web server is a lot of work and typical home Internet providers prohibit running one because of the load/security issues. To make it accessible, you would also need to purchase a domain name, and configure DNS and have some way to map the your external (possibly changing) IP address to the domain name. If you really need a public facing web site, you're much better off purchasing one from a hosting provider. They end up doing most of the heavy lifting and you just have to create/add the content. Your ISP may even provide some limited web serving for you. If you just want a web server that is only visible to the devices on your local home network, then hosting it on the Arduino is fine (or on a RPi). Security is much less of an issue since only someone logged into your WiFi or router would be able to access it.

I also have an ISY at a cabin with no internet access and it is possible. Have you tried downloading the java app directly from the isy? http://<isy ip address>/admin.jnlp You should be able to run the downloaded admin.jnlp directly. It's been a while since I've had to access it so I'm not sure that's right. Also, can you get to the ISY by pointing your browser at the ip address? That should bring up a page that lets you control stuff, but you can't configure. It does have a link to the admin console, but I believe you have to have java enabled in the browser for that to work and most (all?) browsers have it disabled now.

Maybe a more simple way of putting this is that everything under the 'main' and 'program' tabs of the admin console can likely be migrated. Things under other tabs (like Elk or modules under config) will probably not be possible to migrate without manual intervention.

The issue with ISY modules is that they were written and designed before the concept of node servers so they're not manged the same as other "nodes". Their internal representation in the ISY firmware is different. So, yes, migrating from old ISY modules to new replacement node servers will likely always be a manual process.

No necessarily. There's really no reason why an Insteon node server would create nodes that are different from the nodes created by the current ISY firmware. Thus, it should be possible to use a backup of the ISY to recreate/restore the Insteon nodes using an Insteon node server. Scenes may be problematic. An ISY scene seems to be a superset of an Insteon scene/group and I don't know how those are linked in the current ISY firmware. I don't know if it will be easy to split them apart such that an ISY scene can be composed of components from different node servers. In general it should be possible to provide a migration path and I would hope that's being considered.

Not a dumb question. Today the ISY has an Insteon node server built in. It's a large part of the ISY firmware. The ISY also has a z-wave node server built in. You can think of an ISY as a couple of node servers with a node server framework and rule (programs) engine. For the Polisy, the idea is to separate the z-wave and Insteon node servers from the core framework/rules engine. A node server for Insteon would communicate with Insteon devices using the PLM. However, by making it a separate node server, it removes some of the restrictions imposed by the current hardware and it would be possible to use a USB PLM or maybe even the HUB for the device communication.

I'm just going to drop this here. Would UDI be willing to support an open source Insteon node server development project? With the existing group of node server developers, I'm sure there are a few of us that would be willing to contribute time/effort to developing a node server for Insteon. If UDI is willing to support the effort by providing existing nodedefs, etc. and possibly access to existing ISY Insteon code, that would provide a good starting point. I fully understand the issue that UDI has with Insteon. When it was new, I spent a lot of time trying to create a set of Insteon tools for Linux. I gave up when I found the ISY because UDI's effort was much farther along and a lot more stable than what I had working at the time. Developing for Insteon is painful, but, like others here, my house is using mostly Insteon so I'll likely devote some time/effort to supporting it, if only for my own use.