bpwwer

Internet going out shouldn't effect the node server connection to Polyglot. Both the node server and the Polyglot are running on the Polisy and that internal connection should be very stable. If the Polisy isn't loosing power, then the connection should be stable, if the Polisy is loosing power then it seems like everything should re-start when power is restored. An external Internet outage shouldn't have any effect unless it is also causing your local network to fail such that all traffic is blocked. I still think it would be best to try and understand what's causing the node servers to go off-line, but I'll try to make some time to add the query command.

@macjeff, the problem I have with this is that I don't like to do the wrong thing to fix something that shouldn't be a problem in the first place. The query request from the ISY to a node server is supposed to do a specific action. It is asking the node server to get the very latest data from the device and report it. The node server framework has a base implementation of this that reports the current values. This is just a placeholder since it doesn't know how to query what device(s) the node server is talking to. It's very easy to expose that placeholder as is. This is what most (maybe all) of the node servers are doing, but this wrong. The correct way to implement this for the weather node servers is to query the services for the most recent data and report that back to the ISY. Thus the correct implementation is a bit more involved than just exposing the placeholder. However, all your node servers shouldn't be going off-line. That's really the problem you need to fix. The fact that you've found a way to work-around it is commendable, but you really should figure out why they're going off-line. That sounds like a problem that's only going to get worse if it's not resolved.

Support for the WeatherFlow forecast will be in the next release, that's mostly coded at this point. Support for multiple devices/hubs is a much larger/complex feature. The original stand-alone node server I wrote had that support and, at the time, the Polyglot based version was supposed to be a more simple version. That's obviously changed over time and the Polyglot version needs to evolve.

Thanks for the report. I think I have that fixed now. It's looking for just the single 6 character code. It can be either an zone code or a county code. For example " AZC001" for Apache county AZ.

I had a typo in the id used for Winter Storm Warning, it was the same id as Tsunami Warning. I've fixed that in version 1.1.1 that should be available in the store in less than an hour. When I made the node server, NOAA didn't define anything called Winter Weather Advisory so it doesn't match and thus, is NONE. This is the main problem with NOAA forecasts and alerts. They use text strings and to work with that, the node server has to be able to match those strings exactly but apparently they don't define what all the strings are that they use. Since the ISY doesn't support string data, strings have to be mapped to numbers and I can only do that if I know what the strings are going to be.

I'm sure there must be some way to have the loops on top of the floor and covered well enough to survive being driven over. My cars that are in the garage, rarely leave the garage, otherwise I'd think about experimenting with this.

A quick search found these https://www.amazon.com/Wal-front-Vehicle-Detector-Inductive/dp/B07K1BNL59/ref=psdc_7459508011_t1_B07H3N41H4 Not much info, but for ~$20 it might be worth playing with.

I would assume that most home buyers aren't going to have the DIY automation knowledge that I do and that my ISY/Insteon/Z-wave installation would not be a value add to the home sale. For my home, I'd either configure the Insteon/Z-wave devices in a stand-alone manner such that they basically operate as standard devices or I'd pull them and replace with standard switches. Now if the system was professionally installed, is well documented, and has a company standing behind the work to support it for the new owners, then it may add some value (or at least not remove value). And at this level, the technology is less important than the reputation of the company that did the work and supports it.

If the temperature display doesn't correct with the next query of the service, then something probably didn't get fully installed. When the node server is installed, it copies a few files to the ISY that control how everything is displayed on the Admin Console. However, the ISY does have limited network resources and sometimes a file will fail to copy which can lead to display issues like that. On the current condition node screen, there's a button on the bottom labeled 'Load Profile'. That will make the node server resend those files to the ISY. After doing that, you will have to restart the admin console so that it can re-read those same files from the ISY. That should correct any display issues.

The node server does try to minimize the data sent to the ISY (and thus minimize the log entries) by only sending data when it has changed. But some weather data values do change frequently and the only way to change how often is to change the poll interval. This is one of the reasons I try to be somewhat selective in the weather data presented by the weather node servers. The more different values the node server tracks, the more data that has to be sent to the ISY.

Setting the log level to error should reduce the messages down to just error messages. Re-Discover causes the node server to review the nodes it's created. It will do this every time it start automatically and if you change the Forecast Days parameter as that's the only way to change the nodes it creates. Remove Notices will clear any notices the node server has displayed on the Polyglot dashboard-details screen. Update Profile will cause the node server to resend the profile files to the ISY. This also happens automatically when the node server is installed, but in some cases, the ISY is unable to accept the files (maybe it was too busy) so the option is there to resend them manually.

Unfortunately, Dark Sky is going away sometime this year. I'm not sure how to debug the authentication failure you're seeing. I'm not seeing that with my platform key. If they do actually follow through and meet with me, I'll ask.

I just wanted to point out that it's not a requirement to have to Polisy's or RPi's to support two ISY's. The current ISY ecosystem wasn't really designed with the idea that there'd be multiple ISY's trying to co-exist with overlapping data sources. Some type of creative solution will likely be needed. For the Davis, that may mean feeding the data to something else first, that can support sending the data to multiple consumers.

No, not currently. It adds a lot of complexity to support multiple hubs. And with PG3, it should be possible to run multiple copies of the node server, one for each station. I also have multiple hubs (3) and have written software to support them so I do understand what's required to make it work. I did write a stand-alone (non-polyglot) based node server for WeatherFlow that does support multiple hubs/stations. It's probably a bit out-of-date now.

I believe you'll need to create a new account for the Climacell Platform and use that. Someone from Climacell has reached out to me asking for a meeting to discuss this. I'll see if anything useful comes of that.

You can run multiple instances of Polyglot on the same hardware. It does have environment variables that allow you to change the ports used by an instance of the program. I'm currently running both version 2 and an alpha of version 3 on my Polisy. If you wanted to install a second instance of Polyglot running on a Polisy, you'd have to set up the directory structure and port configuration so they don't conflict with each other. You can also run multiple copies of Polyglot on an RPi, though I've never tried that.

The current version of the node server doesn't use the key. Is it not working with just the station ID now?

@drprm1 The log has this "The method requires authentication but it was not presented or is invalid." from Climacell which sounds like the API key is not valid for that request. I suspect that means you're still using a key for version 3. Like I pointed out above, it looks like they have 2 completely different systems now with different logins. You need an account and key for the Climacell Platform, not the Weather API.

Unfortunately, the ISY doesn't have any way to display a date/time other than as a raw integer which doesn't really help. I was very confused by what Climacell was doing. When I went to my account, there seemed to be two different ways to log in. One would accept my info and take me to a dashboard that said my key was expired, but provided no way to renew it. The login would not accept my info and I ended up creating a 'new' account to get in that way. When I did, it had a different dashboard and allowed me to create a new key. Their API documentation does say that the version 3 API will be discontinued in Feb 2021. From what I could tell, the two logins are unrelated. One generates keys that work with version 3 only and other generates keys that work with version 4 only. I've updated the node server to only use version 4 of the API. @andrewmI'm surprised that it says it will auto-renew in June. That seems to imply that you may be using the new account that I thought would only work with the version 4 API. From the main climacell web page there are two options under login 1) climacell platform and 2) weather API If I select weather API, I get a dashboard that says plan expired and no way to renew or change plans. If I select climacell platform, I get a dashboard with a secret key that says active. This is the key I'm using with the node server now.

No not OpenHab, I just searched on github and npm for projects related to velux. The ones I found provide simple examples to create a program that uses the module to communicate with the KLF200. The first one I found on github looked like you could load it on an rPi via PIP and create a simple python program that used it. That's where I'd start just to get an idea on how to use the module. Maybe look at more than one and pick the one that works best. At this stage, not even trying to do any integration with ISY. We're still working to define the PG3 API's, but there's no expectation that existing PG2 node server will run as-is on PG3. How much effort will be needed to migrate a node server is still unknown.

it looks like there are both Python and node.js modules available that implement the API. I'd suggest looking over those and maybe experimenting with them first to understand better how to interact with the KLF200. Then you have to decide what information is important to both for display and commands. Use that to define what you want the nodes to look like on the admin console. From there you can create the profile files and start creating a node server from the template available. Based on what little I've looked at, the KLF200 is a controller that supports a number of different devices, that means creating nodes with status/commands for all the different supported devices so it sounds like a fairly complex node server. Another consideration at this point is that PG3 has just started alpha testing. It's not ready yet to start developing node servers for it, but it will be soon. It may not make sense to put in a lot of effort creating a new PG2 based node server and then more effort to convert it to PG3.

Climacell node server update. Climacell has recently made some changes that effect the node server. The node server was written to work with version 3 of their API. Version 3, is now approaching end of life and they have stopped issuing API keys that work with version 3. As accounts with version 3 API keys expire, you will no longer be able to renew the key and will be forced to get a new API key that works with version 4 only. Since version 4 API keys don't work with the version 3 API, the node server needs to be updated to work with the version 4 API. I've made these changes and will release them shortly. This is a breaking change. Once you update to version 1.1.0 of the node server, you will need to get a new version 4 API key. There are a couple of changes based on the data available from the version 4. API accumulated precipitation is gone. It is not available via the API moon phase moves from the current condition node to the forecast nodes as it's only available via a day query the weather condition codes have changed

New version of NOAA node server (version 1.1.0) The NOAA node server now includes data on alerts from alert.weather.gov. You can specify a county or zone code in the configuration and it will start polling for alerts for that area. There are a couple of limitations. Currently, this only supports getting a single alert. If the area has more than one active alert, you'll only see the last one listed. I haven't figured out a good way to present a dynamic list in the ISY. If you have any ideas, let me know. The ISY can't really deal with time, thus one important piece of information about the alert is missing; the time/date it expires. I believe this will only work with ISY firmware release 5.3.x, It might work with 5.2.x but I haven't tested it. It most certainly won't work with anything older.

Someone else may be able to provide a better solution, but I believe you need to set a flag (variable) and use that to trigger the notification. Something like: if AQI > 100 then high_aqi = 1 else high_aqi = 0 and a second program if high_aqi = 1 then send notification The problem you're having is that every time the AQI changes, it triggers the if condition to re-evaluate. By using a variable, the variable only changes when the AQI goes over 100 or under 100.

If you weren't aware, the admin account used to ssh in and the admin account used for the web interface are different accounts. That's more of an FYI for anyone following this. Have you reloaded the web interface browser page? My system will get stuck where I can't log in, but as soon as I reload the page it lets me log in. Something seems to be cached on the browser that prevents it from properly authenticating. I'm now in the habit of always re-loading.