bpwwer

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.

All of the valid values are in the documentation here: https://github.com/bpaauwe/udi-owm-poly/blob/master/README.md Current condition node sys.node.[address].ST (Node sever online) sys.node.[address].CLITEMP (current temperature) sys.node.[address].CLIHUM (current humidity) sys.node.[address].BARPRES (current barometric pressure) sys.node.[address].WINDDIR (current wind direction ) sys.node.[address].DISTANC (current visibility) sys.node.[address].DEWPT (current dew point temperature) sys.node.[address].UV (current UV index) sys.node.[address].GV2 (current feels like temperature) sys.node.[address].GV4 (current wind speed) sys.node.[address].GV6 (current rain rate) sys.node.[address].GV7 (current snow rate) sys.node.[address].GV13 (current conditions) sys.node.[address].GV14 (current percent cloud coverage) sys.node.[address].GV18 (current percent chance of precipitation) Forecast node sys.node.[address].CLIHUM (forecasted humidity) sys.node.[address].BARPRES (forecasted barometric pressure) sys.node.[address].DEWPT (forecasted dew point temperature) sys.node.[address].UV (forecasted max UV index) sys.node.[address].GV19 (day of week forecast is for) sys.node.[address].GV0 (forecasted high temperature) sys.node.[address].GV1 (forecasted low temperature) sys.node.[address].GV2 (forecasted daytime feels like temperature) sys.node.[address].GV13 (forecasted conditions) sys.node.[address].GV14 (forecasted percent cloud coverage) sys.node.[address].GV4 (forecasted wind speed) sys.node.[address].GV6 (forecasted rain) sys.node.[address].GV7 (forecasted snow) sys.node.[address].GV18 (forecasted percent chance of precipitation) sys.node.[address].GV20 (calculated ETo for the day) Your 'address' is n001_weather for current conditions so just substitute n001_weather for [address] above. For the forecast nodes, it's probably n001_forecast_0, n001_forecast_1, etc.

@PeterBarker11I'm assuming based on your post in the other thread that this is now working for you? In case anyone else sees this while looking for the solution. I believe this was resolved by restarting the admin console. When a new node server is installed, the admin console must be restarted before it can properly display the new nodes created by the node server.

My node server does pull data directly from the device, I'm using the V1 API and it can be configured to pull as often as you want. It currently does not handle multiple sensors, at least not correctly, so I'd have to make some modifications to handle additional outside temp/humidity sensors and I'd need to see what the data looks like to do that. From looking at the docs, it appears that the WLL device does support multiple sensors for the current conditions, but I'm not sure I'd bet my own $200 on that.

The node server doesn't support any extra sensors. It pulls data from the 'current' 'indoor', 'soil' sections of the data. It only pulls one temperature/humidity value from the 'current' section. I can add more values, but would need to see the actual data from WLL with the additional data as I don't have a Davis system.

Great post! I have something like this also. I look at window status via a DSC alarm and will turn off the AC if a window is open. I also won't turn on the fan if all windows are closed. I use a personal weather station to get the outside temperature and look at the diff between the inside and outside temp. When the outside is a few degrees below the inside it triggers a program that can turn the fan on if a window is open. It will also turn the fan off if the outside is close to or above the inside. When this was all working, I could open a window when the outside temperature was about equal to the inside and as soon as it cooled down outside enough, the fan would automatically come on. When it started warming up in the morning such that the outside temp started to reach the inside temp, it would shut the fan off. There have been times that it got so cold inside that the heat would come on when the windows were closed so I like your idea of shutting off the fan if it gets too cool inside. I just created a Purple Air node server that monitors air quality so I'd like to incorporate that too so that we don't run the fan if it's smokey outside. We've woken up at night to find the house smelling like smoke inside.

I had a whole house fan set up with a bunch of rules including indoor/outdoor temperature. At one point I got it stuck in a loop where it would turn on, blow some air over the HVAC thermostat which would cause an indoor temperature change which would turn off the fan. Once it stopped the temperature changed again and the fan would turn back on. Probably not good cycling the fan like that. It took some playing around with temperatures to get it working right. It was pretty cool when it did. I had it also tied to window state so when the indoor and outdoor temp was about the same I could open some windows and then when there was enough of a difference the fan would come on and start cooling things down. And if it ever got too cold inside, it would shut the fan off, or in the morning when it started getting too warm outside, it would shut the fan off so that we wouldn't pull warm air into the house. Basically all we had to do to control the fan was open/close windows.

All of the weather conditions are considered status. Control would be used for things that don't really have a current status. Something like a lightning strike event could be a control, but the distance to the strike is a status. But I haven't created any controls in the WeatherFlow node server. Any program that triggers on a status, will get executed when the status value changes. So yes, if you had something like: if temperature > 76 then turn on fan else turn off fan would cause the fan to turn on/off every time the changed going above/below that limit. To prevent that you either need to guard band the value I.E. have the on temperature > than the off temperature or add time references so that it has to be above or below the threshold for some amount of time before switching. The node server is getting updates from the WeatherFlow hub at 1 minute intervals so that does limit somewhat how often things can change.

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.

I just pushed a new version that should fix this. Thanks for the report.

Thanks for the report Gary. Looks like WLL refused the connection for some reason, as it started working after the restart, I assume it must be a temporary failure. I added error trapping to the request so it shouldn't crash if it happens again.

Pushed an update that should trap the missing pressure value so it doesn't crash.

The OpenWeatherMap node server no longer works properly with Polyglot Cloud so I'm removing it from the store.

Step #4 was not necessary and may account for some of the issues you're having. Polyglot takes care of all interaction with the ISY, including adding nodes and setting up the node server configuration. Changing things like the ID and password will cause problems with the ISY/Polyglot communication. Given that it's difficult now to know what state everything is in, it may be best to delete everything and start over. Steps 1, 2, and 3 are all correct. After that your step 4 should have been to restart the Admin Console. Once the Admin Console is restarted, all the nodes should show up and start populating with data. Not all fields will necessarily have data, some like wind gust are optional and OpenWeatherMap may or may not send that data. You can try stopping and restarting the node server from the dashboard and then restarting the Admin Console and see if it all starts working, but depending on what you've changed, it may not work and deleting and re-installing would be the only solution. The logging level determines how much information is sent to the node server log file. Off means that almost nothing is sent to the log. You can change that via the drop down menu. All of the other weather service node servers are similar. They differ slightly in the data that they provide, the sources they collect data from, and the forecasting algorithms that they use.

Already did, thanks for the suggestion!

That's a good question and I agree with you about the quality of the documentation given that I'm responsible for a number of node servers with poor documentation. In my case, and I suspect others as well, because we aren't currently being compensated, it tends to be harder to justify the time for it. Having a reasonably good template for documentation and have it be a gate (I.E. done to some standard) before allowing something to be added to the store would help. I'm sure we'll get there eventually. In the meantime, if you see something you'd like better documented in any of my node servers, let me know. I'm always willing to add things to my todo list

Opera, just started happening yesterday for me too.

It looks like it should be reporting it. However, it only reports the reading to the ISY when it changes. If you look at the nodes in the polyglot dashboard. It's GV5 in the main controller node. Does that have a value that matches the data in the log? I think, because I tell the polyglot to only update the ISY when it changes, it's possible that upgrading the ISY, cleared the values in the ISY, but polyglot hasn't seen a change in the value so it hasn't sent an update. It works this way to reduce the load on the ISY. For a lot of my node servers I started forcing polyglot to send the values when the node server starts to as a way to work around this, but this one doesn't do that. I'll have to update it otherwise, you'll probably not see that update until you get more rain.

I've been following this because I'm going to have a SolarEdge inverter soon and would like to use this node server after it's installed. So I took a look at your log. I think the problem is the way that polyglot (and specifically the cloud version) is handling the parameter update. The node server doesn't get the updated value after you enter it. Try doing things in this order: 1) Install the node server 2) Enter the api_key parameter key and value. Save the changes 3) Stop the node server 4) Restart the node server 5) Check the admin console to verify the nodes exist. You should see a SolarEdge Controller node, a Quackenbush1 node with two subnode for battery. Since you already have the key entered (per screen shot), just start with step 3, stop and restart the node server and it should discover your inverter.