Go to this url, WeatherFlow Smart Weather API and click Authorize. In the popup check the user box and click the top Authorize button. Sign in, click allow. Click the expand operations button. Type in anything you want for the device_id, 12345, and click Try It Out. It will show a command like this:
Thanks for this integration. Big help in getting this device running.
Few suggestions (I'll send you a pull request)
This device really pounds the HE database. In my case 1000s of events per day. It slows down the hub quite a bit as the db is a shared resource (and common choke point in HE).
The changes I made reduce the events sent to the DB by about 1 -1.5 orders of magnitude. Much happier hub with less DB contention.
The challenge with most weather devices is the above - too many events getting stored into the DB each day.
The 2nd order effect (which is important) is apps using this get woken up a lot - likely way more than needed to get their core function done. Again more load on the hub that is likely not needed for functional automation
Strange I am seeing events from the socket coming in a 1 per minute normally. Now with lightening strikes there is more real time events. I am not seeing it slow my hub down at all. But I do see what you are stating is that every attribute has it's own record in the database by every web socket update.
I'll be interested to see what you came up with. I am aware that it updates the DB frequently, but in my own testing I did not notice any ill side effects. The fact that this driver many fewer attributes than other, typical weather drivers seemed like an okay tradeoff.
I see your point though. I just did a quick comparison with the Wunderground driver I used previously. At a 5min update interval it produced around 2k events per day. This driver produces quite a bit more.
I bet reducing the resolution of temperature values down to tenths would cut the number of events by quite a bit. Rounding values to 0.5 would reduce even further. Personally, I like the frequent updates but I'm only interested in full to half degree changes.
Maybe put in a option to round with a setting that you can toggle but I am using lumens and uv in their raw states. If you start to round most of the automations and loggings I have done will be invalidated. Or I would have to branch your code with your permission to keep the original methods.
Off topic but can you share any references you used to build the websocket listener? This is the first instance I've seen and curious if it would work with a webservice that requires basic auth. Thanks!
The event doesn't get published to the DB if the value doesn't change, so there's no need for the additional logic.
I'll keep this in mind, I definitely don't want to remove utility for you. Perhaps what I can do is have a multi select dropdown where you can pick which attributes to reduce resolution.
I originally looked at the Harmony driver, but I would consult the docs as the interface has changed. There are options to specify headers, so you should be able to do basic auth
I had asked @mike.maxwell (maybe it was chuck, can't remember now) this very thing a long time ago and he recommended doing the check. There is still cost incurred doing the sendEvent and even though it internally does essentially the same check, he recommended comparing the values
@augoisms, first off LOVE the driver, I was going to take a look at a Web-socket implementation, but you already did it! When I saw that a few people were hesitant due to the relatively high number of events created, I took an hour and made an update. I have posted a pull request with some changes to your driver that allows the user to select 1, 5, 10,15, 30 minutes or 1, 3 hours. It "collects" the data and on the selected boundary creates "averaged" events.
Thanks for the PR! I don't think that averaged values is best option. At then given interval I would want to know what the current values are. I do like the option to select a time interval. I think that I will combine that with @nh.schottfam 's PR where he skips observations every 11 minutes, except for rain and strike events.
If you’re interested, it would literally take 20 minutes (later tonight) to add a choice of average vs latest as well as give the user the option to “exclude” data from averaging or holding off. Your code is so clean, it makes it easy.
Is there any possibility of calculating the rain rate? I'd like to show a different icon on my dashboard for heavy vs. light rain. I'd code it myself but it looks like you're not reporting the current precip amount (index 3 of the obs), only the daily amount?
I decided to not publish it because it wouldn't be valuable on it's own since it's just the amount of precipitation since the last observation (last 1 minute).
I'll look into collecting those values and publishing a precipitationRate attribute (in/hr, mm/hr).
Publish Rate - you can now select the rate at which you want observations to be published. Precipitation and strike events are always published in real time.
Reduce Resolution - you can (optionally) reduce the resolution of Illuminance, Temperature, UV Index, and Wind Speed values.
Precipitation Rate - the driver now collects the rain_accumulation observations and calculates the precipitation rate (in/hr, mm/hr). This data is stored in a static field, so it won't survive hub reboots or updates to the driver code. I don't get much rain where I am, so let me know if this isn't working for some reason.
Thanks for the update, when I am back in town I will stand it up and test. We have some rain due for tonight and it would be a good test of the Precipitation Rate.
