[RELEASE] WeatherFlow Lite

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:

curl -X GET --header 'Accept: application/json' --header 'Authorization: Bearer 7777aaaa-9999-8888-5555-121212434343' 'https://swd.weatherflow.com/swd/rest/observations/device/12345'

The value in bold is your user specific token. Just use that and you can access your private station.

2 Likes

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.

Glad it has been useful!

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.

I'm testing out the following changes:

  • Round temperature values to the nearest even tenth (75.367 -> 75.4)
  • Round illuminance values to the nearest thousand, hundred, and ten (165378 -> 165000, 378 -> 300, 78 -> 80)
  • Round UV index and wind speed to the nearest integer (11.36 -> 11)
  • Round pressure to the nearest hundredth (29.893 -> 29.89)

This should greatly reduce the number of events produced. Does anyone see any issues with these changes, or have any suggestions? Thanks!

I like it... but why does 378 round to 300?

My mistake, it would round to 400

1 Like

Not sure if relevant, but in my Ecowitt driver to try to minimize them I decided to send an event only if the new value is different from the previous:

if (device.currentValue(attribute) != val) sendEvent(name: attribute, value: val)

1 Like

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

2 Likes

Yes, but isn't an async sendEvent() still costlier?

PS: any member of the staff (@mike.maxwell, @chuck.schwer) willing to weight in on this? I'm a novice when it comes to hubitat development and I'm always wondering which one is better:

assuming I have a weather station reporting (possibly) dozens of values per minute, is it better to check if the value has changed:

if (device.currentValue(attribute) != val) sendEvent(name: attribute, value: val)

or let the platform deal with it and send the event anyway:

sendEvent(name: attribute, value: val)

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

3 Likes

Interesting, good to know :+1:t3:

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

Tell me what you think.

2 Likes

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.

That's okay, I have some other changes I need to do. I appreciate the offer!

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

Download the Hubitat app