bpwwer

No problem, that's one of the issues with the Admin Console, it seems to need a minimum resolution that's pretty high and even then, it can't always display everything if there are too many node values.

The current condition node has a command to set the log level.

That's the plan, but WeatherFlow hasn't released an API to access the forecast data yet.

A combination. When it starts, it queries the WeatherFlow server so that it can determine what devices are associated with the station, what your preferred units are, the station elevation, the historical rain data and some historical pressure data to calculate the current pressure trend. Once it has all that, it then just listens for the UDP packets. You should be able to enter all the configuration that it's pulling from the server manually and it will function fine without a connection to the server. You do lose the historical rain and have to wait about 3 hours for the pressure trend to be accurate. WeatherFlow has been putting a lot more effort into their server based data correction to compensate for inaccuracies in the physical sensor data. The more they do this, the less useful simply reporting the local UDP data will become.

The log doesn't show anything wrong. The values on the ISY are only updated when the value changes. WeatherBit only sends barometric pressure in millibars.

Strange that this is just showing up now. I wonder if they changed that in the API or if no one has run with debug logging enabled? In either case, I've pushed an update that will fix it. Thanks for reporting the issue.

There are a number of different terms related to an adjusted temperature value (heat index, windchill, apparent temperature, feels like). Some of them get used interchangeably but there are actual formulas for each. So windchill and feels like may or may not represent the same formula depending on who is doing the reporting. The node servers are simply reporting the data that the service is sending.

The node server is pulling most of the data available from the "basic" Aeris subscription plan. That's the same for all of the weather service node servers. None of them take advantage of the additional data available in the higher priced plans. ETo is calculated based on forecast data, not current conditions. The main node for each node server is the current conditions and that is what gets updated most frequently. Via the custom parameters configuration you can specify how many days (again, limited by what the plan supports) of forecast data you want to see. Each day of forecast data is shown in a separate node. Forecast day 0 is for the current day. ETo is calculated for each forecast day. By definition, ETo is a per day value so it needs data for the entire day, not just a single snapshot at a point in time.

Yes, they are in seconds.

Hi Ken, It's on my list of things to do someday. Adding ETo to the weather station node servers isn't as straightforward as it is on the weather service node servers. The calculation requires things like the min/max temperature for the day. The weather services provide this in daily forecasts so the data is readily available. Your Tempest, on the other hand, just provides the current temperature. I'll need to add the capability of tracking the temperature (and other values) throughout the day and then will be able to do the calculation at the end of the day. And that's the other difference. Without a forecast, the data will always be 24 hours behind. Now if WeatherFlow adds the ability to get the forecast data they're providing on their APP, that should make it pretty easy to add ETo for the WeatherFlow node server.

While it is possible to organize things that way, the issue is that the ISY can only have a limited number of nodes (or devices). So if I split up each existing node into multiples, it means the one node server could potentially be using up a significant portion of the available nodes. I believe it also would use more memory resources on the ISY as it would increase the number of node definitions the ISY would have to hold in memory.

Found the bug, version 0.1.11 should be available to upgrade from the store in about an hour.

Not sure, maybe the log would show some information to track down what's happening. I don't see anything wrong in the code, if it's reported as MM and you're wanting inches, it should be doing the conversion. It's the same logic for precipitation as it is for temperature.

Not that I know of, but I just pulled that list from the Meteobridge website so there might be more information there.

You have to create a mapping between the Meteobridge data field number and the node server node value for each value you want imported into the ISY. There really isn't any easy way to set this up with the configuration framework provided by Polyglot. You'll add a custom parameter for each value you want. The "key" will be the node server's name for the value and the "value" will be the Meteobridge field number. For example to map the main temperature value: temperature-main = 2 2 is the Meteobridge field number for th0temp-act:-- which is the main temperature. This will create a node on the ISY with a temperature value. I have a list of Meteobridge field number here: https://github.com/bpaauwe/WeatherPoly/blob/master/METEOGRIDGE.md The valid list of node value "keys" is here https://github.com/bpaauwe/WeatherPoly/blob/master/NODE_VALUES.md

File -> Set Userid/Password from the admin console.

That did it, both are showing up now, thanks!

After uninstalling and re-installing I'm still getting Model SE7600A-USS20NHB2 is not yet supported Interestingly that's the older of the two models I have.

Yes, I've played around with the charts on the portal. I was really looking for real-time (at least every minute) info on battery charge/discharge rates that I can feed automatically to my database. While the charts are interesting, they're not real-time. I think the data only updates every 15 minutes and you have to regenerate the chart to see any updated data. I believe the API provides data updates every 5 minutes. It seems like the data should be available over the modbus, and that's probably how the battery communicates it's status to the inverter, but I haven't found any documents that indicate it's possible to access that data over the local network port.

Yup, I suspect the portal and the node server are using the same API calls to get the information. While I have the node server running, I'm not currently using it for anything. I am collecting data locally from the inverters and meter via modtcp and via an external meter. I dump this into a database and generate my own charts. The one things I'm missing is info on the battery. When the battery is charging, it looks like I'm not producing as much, but when the battery is discharging I see it as if I have PV production happening. So it works out in the end, but I was looking into the API to see if I could get some additional data on what's happening with the battery. There is access to a lot of different data vial the API but my understanding is that it's not real-time,

That's basically the system I have too. Two inverters with a battery connected to one of them. What I'm getting with this node server is a Site node which has an aggregate of the two inverters that has a single child node for the battery. However, I installed the node server after everything was installed. As a last resort you could delete the node server and re-install it.

Dean, that's not a node server problem. The node server is correctly reporting the values it's getting from Climacell.

Thanks! I just pushed an update with that fixed. That should have effected all forecast nodes so I'm not sure that's the problem, but let me know.

The service is supposed to supply the data in US units when that's specified. It seems to be working for other values so I'd have to say it's a problem with the data coming from Climacell. Setting the debug log level will cause the node server to dump the data it gets from the service to the log so you can check that.

Thanks for the feedback. That response from WeatherFlow doesn't really make sense to me. If the device was replaced, wouldn't the serial number be different? So why remove it? Also, why remove all the hardware information from the record, seems like if you're going to keep the data it would be real important to know what hardware was used to capture that data. I can certainly handle that case, but it looks more like a bogus record than a replaced device to me.