bpwwer

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.

I don't have any real plans, just experimenting. Seems like this could be the basis of a Insteon node server. Currently, I'm able to see messages from my mini remotes and that's about it. I don't think I have too many dual band devices as a lot of my Insteon network is old.

@evilpeteThanks! This is pretty cool! I just installed librtlsdr and rtl_433 on my Polisy and it's working. I had been using rtl_433 to pull data from an Acurite weather station so I had the rtl_sdr dongle already. What should I try to do with it now? I might have to dust off some of my old Insteon message decoding code. There is a freebsd package for rtl-sdr that includes librtlsdr so maybe that can be added to the Polisy's package repository? @Michel Kohanim?

@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.

ANNOUNCEMENT Changes coming the WeatherFlow node servers. WeatherFlow is changing their API to no longer accept a "developer" API access key and transition to requiring Personal Access Tokens instead. Today, the developer API key allows access to any station observations for stations that are marked public. After the transition, the Personal Access Token will limit access to the account it was issued for and only stations associated with that account. Shortly, I'll be releasing new versions of both the WeatherFlowPoly and WeatherFlowPGC node servers that implement this change. This mean: If you're using these node servers to access stations you don't own, you'll lose access unless the owner of the station provides you with an access token. For WeatherFlowPoly you'll have to generate a access token for your WeatherFlow account and add it as a new custom configuration parameter in the node server when you update to the new version. For WeatherFlowPGC you'll be automatically upgraded when stopping/starting the node server and will have to generate and enter an access token to continue using the node server. I expect the current versions of both node servers to simply stop working when WeatherFlow flips the switch which is expected to happen at the end of 2020.

Yeah, I noticed that it was backing up and trying to restore sensor too. I'm currently looking at devices that have status units of 100 (level 0-255) and 51 (percent) as covers the Insteon switches/lamp type modules (and sensors) and z-wave switch/lamp modules (and possibly others as well). That's all I had to work with when getting the info via the /rest/status endpoint. Now that I'm using the /rest/nodes endpoint, not only is is faster, but it also provides some category/type information so I need to refine the filter to look more specifically and dimmer/relay devices.

If that's not working still, let me know, I'll probably have to add a config option to add the port.

Just missed the store update. Version 1.0.1 will be in the store in about 1 hour. It fixes the duplicate bug and switches to use the /rest/nodes endpoint based on @Michel Kohanimcomment about about performance. The added benefit is that I now get the type and device name so that should make it easier to improve the selection of devices and debug.

Yeah, just enter that with the IP address so something like 192.168.1.30:8000 should work. You might want to wait a bit before moving forward with it though. There's a bug where each time the backup is run, it duplicates all the devices. It's fixed in my tree but I want to try one more thing before I push out the update.

Any idea about how many devices it's restoring? For reference, I'm backing up/restoring 51 devices. It takes my system about 22 seconds to restore those. I've run it a number of times and have not had the ISY lock up. It's not really doing anything that should cause the ISY problems other than hammering it briefly with a bunch of commands. I did find a bug while checking the number of devices. Every time you run the backup, it adds all the devices instead of replacing the existing ones. I was to the point where I had run it 4 times and it was restoring each device 4 times (so over 200 commands to the ISY) and the ISY was fine with that. Possibly there's a device that it's trying to restore that causes problem. It is guessing as it tries to determine which devices to save and restore by looking at the status UOM. So maybe it's trying to send a DON/DOF to a device that doesn't support that. Unfortunately, the ISY query only returns the device address and not the other device info like name so it may be hard to determine if one of the devices isn't a lighting type device. I was a bit afraid that the complexity might snowball on this node server. If I need to add a way to manually select/deselect devices it starts getting complicated fast.

It's in the store now, simply called "Backup"

It's ready now. I just need to push it to the node server store. I'll try to do that today. It's still a lot slower than I would like. The main issue is the communication with the ISY. The call to get the device status (/rest/status) is taking my ISY 10-15 seconds. Some of that is probably because of the number of node servers I have installed, Restoring is sending individual commands to the ISY for each device it restores so that's dependent on the number of devices and how long it take s the ISY to process each command. There are really just two controls for the node server: backup and restore. Both are available for use in programs. backup takes a snapshot of the current status and restore restores the latest snapshot. Only one snapshot is saved. I wanted to keep this as simple as possible at this point.

Ok, I created a node server that does this. It still needs a bit of clean up before I publish it. I have it looking for lighting type devices (basically, devices that have a status with a unit of 0-255 level or 0-100 percent. It will save the current value of the device status and can restore it later. It currently does all devices that match the above criteria. It's not fast. It takes it a couple of seconds to read the status values on my system and a bit longer to write them all back

You do have to restart the admin console. It only reads those files once, when it starts.

On the Aeris current conditions screen on the ISY admin console, there's a button to update the profile files. That will force Polyglot to send the current profile files to the ISY. Just upgrading may not do that. I can't really help with issues related to the cloud polyglot. The version number not changing after a node server update is a known issue and I believe the only way to get the version number to update is to delete and re-install the node server, but I'm not 100% sure on that.

Yes, by station ID. The station ID should be the number that is part of the url when you click on a station. Currently, forecasts are just available via their own application/website. They've promised an API that will allow others to pull the same forecast data it is just not available yet.

Currently, the Polyglot cloud version of the WeatherFlow node server can get data for any station that is marked public. However, WeatherFlow has stated that this will likely change and access will require an access token, provided by the station owner, to access the data. Also note, that while the WeatherFlow station is an excellent way to get current local conditions, it does not yet have the ability to provide any forecasts (that also is expected to change in the future). The non-cloud version of the WeatherFlow node server is designed to get data directly from the WeatherFlow station on the local network, so that can't really be shared. There are also the WeatherBit and Climacell node servers. Both of those weather services have limited no-cost plans that can be used to get current condition and forecast data.

Thanks guys! @vspetethe changes are in version 1.0.12

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.

Not too hard. There's now a NOAA node server in the store.

WeatherPoly doesn't work that way, it runs a server and expects data to be pushed to it, it doesn't poll. A basic node server to pull NOAA data wouldn't be too hard to create. I'll look into it.

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.