bpwwer

Because when you restart the ISY the ISY forgets everything it's been told about nodes. The query on restart is a work-around to try and restore everything's current state. The connection status is kind of a hack to provide some indication of the node server state. The ISY was designed to monitor the state of nodes, not the the state of the node's controller. I.E. where is the Insteon on-line status or the z-wave on-line status? So basically, the ISY doesn't know the on-line connection status until PG3 sends it an update, which it won't do until the status changes. PG3 will continue to get updates. One of the things we're looking at is adding more status communication between node servers and PG3 and better error reporting for when things do go wrong. But since the ISY doesn't have any support for this, I'm not sure how this will be exposed to users yet. Also, none of these components were designed to be restarted. I understand the desire to try and automatically recover from catastrophic events, but just how often are you experiencing these? I know we'll never get to 100% uptime, but events that require a restart/reboot should be very rare. And, yeah, I know we're not there yet. But if everyone simply reboots or restarts automatically whenever there's an issue and the issue doesn't get reported, we'll never get there because developers won't know there's an issue to fix. You can restart a node server by clicking the restart button in PG3 you can restart PG3 via a menu option. Maybe I'm just lucky. But my production polyglot instance has been up for over 3 months which is how long the Polisy box has been running since I last cut power to it while doing electrical work. Yes, I do occasionally have issues with node servers and most of time it is because the device the node server is for has issues and the node server doesn't handle the device failure very well.

The on-line status isn't doing what you probably think it does. That value represents the status of the connection between the node server and PG3 only. It is set only when the status of that connection changes. When the node server is stopped, it is set to 'disconnected'. If the node server crashes and drops the connection, it is set to 'failed'. When the node server starts it is set to 'connected'. The connection status does not indicate the node server's status beyond the connection to PG3, it is also not any kind of heartbeat indicator. This node server's function is to query the OWM server for weather data and pass that data on to the ISY. A query action would logically force it to query the OWM sever immediately instead of waiting for the next query interval. But that's not what you are really asking for. I believe you're asking for the ability to query the status of the node server itself. But that doesn't really work. The node server could only ever report that it is running. If it's not running, it can't report that it's not running. I suspect that what you want is the ability to query PG3 for the status of the node server, but the ISY doesn't have a way to do that.

I can't speak for the original developer of this node server, but the answer to does UDI ever pick up unmaintained node servers is sometimes. Other individual developers can also pick up and maintain a node server. The pool of node server developers is not real large and in many cases, the developer has created a node server because they need the node server. Without having the equipment, it can be difficult for another developer to take over the maintenance of a node server.

That's not entirely true. More than 50% of the PG3 node servers are installed from the source in a github repository and even some that are not installed from a source repository still make the source available. This may not always be true because unfortunately, we live in a world where people will take advantage of other's work and deprive node server authors of reasonable compensation for their work. Also, there are companies that aren't willing to support node servers for their products because they're afraid the lack of protection on the node server source could expose something they consider secret.

Don't be embarrassed, like I said, PG3 doesn't tell you that it failed to install it to the ISY/IOP and makes you think everything is fine. This is one of many areas where it doesn't do a good job of communicating issues.

Nothing with your current version of PG3. The ISY record in the PG3 database must have a uuid, that's the key it uses to edit or remove the entry. Without the uuid, it is unable to do anything with that record. The latest version of PG3 should automatically remove that invalid entry for you. The current PG3 release is 3.0.63, if you don't have that, you need to upgrade.

PG3 (the current version anyway) will happily install node servers even if it can't communicate with the ISY/IoP. So when node servers fail to show up in the AC, it almost always means you haven't entered the correct username/password for PG3 to authenticate with the ISY/IoP. Go to the ISYS menu in PG3 and select the Edit Current ISY option. Verify the information there. It should have the either the IOP's IP address or 127.0.0.1 or localhost, I recommend either actual IP address or 127.0.0.1. Verify the port, the default for IOP is 8080. Also verify http is selected and not https. https is only valid for very special cases. And, of course, verify the username and password are the same as what you use to log into the AC.

It doesn't. The WeatherFlow hub uses UDP broadcasts to push it'd data to the local network. The node server just listens for those broadcasts. I don't know anything about VLAN's and their configuration so I don't know how or if UDP broadcast packets would route through them. The WeatherFlow hub doesn't have a way to connect to it directly via a TCP/IP address.

That's not a simple request for a number of reasons. The node server's primary operating mode is to use the data directly from the sensors. NearCast values are available from the server only so it can't be used with the node server's primary mode. The node server does use the server data when first started to get historical accumulation, but in that case it also wouldn't really make sense since it would then be mixing NearCast values with non-NearCast values in the values reported to the ISY. It would be possible to use the NearCast values when the node server is in the remote data mode, but that would mean differences between local and remote, would probably need a configuration to enable or disable and would make the code a lot more complex. Given that NearCast isn't available everywhere, I don't think it makes sense to add. At least not at this time.

From what I see in the log, the node server is working correctly. It's not reporting any data to the ISY because it's not receiving any data from your hub. Either the hub isn't working or something on your local network is preventing the hub's data broadcasts from reaching the node server.

No, it doesn't require any changes in the node server or keys. The API change is for getting historical data. The node server doesn't make use of any historical data nor does it use the current ThingSpeak API.

Restoring a PG3 backup will restore the username/password as well so that won't work. UDI does have access to a password reset tool to reset the PG3 back to admin/admin but that tools isn't currently installed so UDI support would have to do that for you. If you enter and invalid username or password, it should display a message saying "unauthorized". If you're not seeing that, try reloading the page. If you're using https to access the PG3 UI, you need to "trust" the PG3 server's certificate after the browser complains about it being invalid. It will only tell you this when you first try to load the UI. Otherwise it behaves as you describe, nothing happens because the browser is blocking access to the PG3 server.

Glad it was that easy Having a way to have the ISY and the admin console reload those files without having to restart them has been on the list of things to add for a while now, but below other priorities.

The profile files define the mapping between the numbers and the text. For email variable substitutions, the ISY (or IoP) is what should be replacing the number with the text. The admin console reads the profile files and does the same number for text replacement. So if the admin console is able to read and map the number to the text, then the node server files are fine. I believe the ISY/IoP only reads the mapping when it starts so is it possible you haven't restarted the ISY since installing ClimaCell?

PG3 isn't very good about aborting the installation when something is wrong. In this case, PG3 tried to install the node on the IoP, failed and continued on as if it was successful. The only way to fix it was to remove the node server and re-install it once the credentials were correct. I've done some work for the next release of PG3 so it should handle this case better by aborting the install so you aren't left thinking it was successful when it really wasn't.

Don't know. the node server lists those as possible modes, but doesn't expose them. I don't know why.

In general, there are no known issues that prevent node servers from running or reporting data except for miss-configuration. Your configuration looked correct. The ETo might cause forecast data to not display or it may be because it doesn't have any data to calculate ETo yet. The second listing is normal for a new station as it tries to get precipitation data for the year, but you don't have any historical data yet. Neither would (or should) cause it to not have or not display data. Please attach or PM me the full log, ideally after you've changed the log level to debug and restarted the node server.

No. it was not removed. PG3, since version 3.0.57 has forced the udi_interface to update to the latest version when it starts.

I don't have any additional information beyond what's in the API docs. The node server simply calls the API and reports the values returned to the ISY. ETo isn't based on precipitation. It's a calculation of how much water evaporates from the soil.

I have no idea. Maybe having two accounts would work. The VUE API isn't a public API and what we're using has been reverse engineered so there could be issues.

Here's the documentation from WeatherBit: https://www.weatherbit.io/api/weather-forecast-16-day

With the current version of PG3, node servers in different stores are considered different node servers. To switch between stores you'd have delete the original and re-install from the other store. This also means that a license purchased for a node server in one store is NOT valid for the same node server in another store. So basically should not purchase a node server from the non-production store and probably not install from the non-production store unless the developer asks you to. This will change in a future release of PG3 where the same node server can be added to multiple stores and the license for one will then be value for the same node server in other stores.

Version 3.0.21 fixes the bug you were seeing. If you refresh the store you should see that version. Then restarting the node server will automatically install it.

Other people, have more than one station, not you. The separate forecast and local entries are for them. In your case, since you only have one station, it is the same station number that gets entered for both.