[RELEASE] WeatherFlow Lite

[augoisms]

A driver for the WeatherFlow WebSocket API

Code

hubitat/weatherflow.driver.groovy at master · augoisms/hubitat · GitHub

Also available on Hubitat Package Manager.

Setup

• Obtain a Personal Use Token (Settings > Data Authorizations)
• Find your station ID.
  https://tempestwx.com/station/{stationId}
• Subscribe to your devices.

Features

• A pared-down weather driver that includes only the essential attributes.
• Utilizes the WeatherFlow Smart Weather API WebSocket.
• Queries the station API to find your devices.
• Supports Tempest, Air, and Sky devices.
• Observations, rain, and lighting events are pushed to the driver.
• Observations update at a 1 minute interval (set by the server).

Notes

• For Air and Sky owners, this driver can subscribe to both devices at the same time.
• I have included most of observations provided by the WebSocket API. I don't plan to add any derived attributes, icons, links, etc.
• Alternatives: @snell has a great driver that utilizes the REST API with more attributes.
  [PROJECT] Driver for WeatherFlow API

v1.0.0	initial version	2020-07-06
v1.0.1	added strikeDistance	2020-07-08
v1.0.2	initialize strike attrs	2020-07-09
v1.0.3	added health check	2020-07-13
v1.0.4	added support for publish rate, reducing resolution, and precipication rate	2020-08-01
v1.0.5	bug fixes	2020-08-02
v1.0.6	added null handling and battery status	2020-08-23
v1.0.7	added water sensor capability	2022-08-07
v1.0.8	added dewpoint calculations, cleanups, fixes for parsing errors	2022-09-20
v1.0.9	fix for api key error	2023-03-03

[ronv42]

Thanks for this. How often are you seeing updates on the socket from the Tempest socket? Right now I am using a polling driver set to 5 minutes from @snell and it's works well. I was reading online that observation reporting with a fully charged battery is about 1 minute and then during storms that there are events per lighting report/strike.

Installed it this morning and watching my logs but so far looks like this will complement the REST API implementation:

UPDATE: I am seeing the arrival of data vis a the websocket every minute so at this arrival rate I think it's going to be great for real-time alerting without overloading the hub.

[augoisms]

You’ve got it right

1 min interval for weather operations. Rain and strike events come immediately.

[JDogg016]

So for lightning strikes (still waiting on a lightning strike). is it possible to report the distance as the result?

This way a user can trigger a rule based on this number (ie. Lightning distance < 5 miles)?

[augoisms]

I've updated the driver to include a strikeDistance attribute. The strikeDetected will still have the epoch.

Unfortunately there's no way for me to manually trigger/test the event and we don't get much lightning in my neck of the woods. Let me know if it works out okay!

[ronv42]

Thanks for the update. I'll keep an eye on it since we have been seeing a few late afternoon lightning reports this week. Question is that after the update I don't see strike attributes in my device or dashboard tile attribute:

And when I look for the attribute say for my dashboard it doesn't show either. But do see it in the driver code:

attribute 'feelsLike', 'string'
attribute 'heatIndex', 'number'
attribute 'pressureTrend', 'enum', ['steady', 'falling', 'rising']
attribute 'precipitationToday', 'number'
attribute 'precipitationType', 'enum', ['none', 'rain', 'hail', 'mix']
attribute 'solarRadiation', 'number'
attribute 'strikeDetected', 'number'
attribute 'strikeDistance', 'number'
attribute 'windChill', 'number'
attribute 'windDirection', 'string'
attribute 'windSpeed', 'number'

[ronv42]

I did find the attribute in Rule Machine, just not a selectable attribute within a dashboard tile.

[ronv42]

Ok so it appears that the lightening strike works but still concerned that custom attriubte doesn't show up for dashboard support until a strike is reported:

[augoisms]

Glad the strike events worked! Thanks for letting me know.

I just pushed an update to the driver that will initialize the strike attributes to zero so that that will appear on the device page the first time observations are processed. I believe this is why they were not showing up for the dashboards.

[ronv42]

I found something interesting with the the WebSocket last night. Around midnight my router received a software update that took about 15 minutes to install and reboot. When it came back up it the data for your driver was way out of wack. For example the luminance should have been very low but overnight it had a value in the 30k range when I checked my dashboard this morning.

I wonder if there is a something in the reconnect logic that didn't work or something in the way WebSockets handling is done by Hubitat. I went into the device this morning and just hit "initialize" and all the values updated.

Ok checked the logs and did see other devices like ecobee have issues at the same time but no socket errors until later in the morning, looks like WeatherFlow took something offline 2:00 am. So now I don't know if it was a combination of the router update and the WeatherFlow servers being offline individually. I'll keep monitoring it to see if these type of events happen again.

2020-07-10 02:01:08.428 am [info](http://ha-hubitat-home.vargofamily.com/device/edit/428)websocket is open

[dev:428](http://ha-hubitat-home.vargofamily.com/logs/past#dev428)2020-07-10 02:01:08.236 am [info](http://ha-hubitat-home.vargofamily.com/device/edit/428)initialize() called

[dev:428](http://ha-hubitat-home.vargofamily.com/logs/past#dev428)2020-07-10 02:00:52.209 am [warn](http://ha-hubitat-home.vargofamily.com/device/edit/428)failure message from web socket failure: No route to host (Host unreachable)

[dev:428](http://ha-hubitat-home.vargofamily.com/logs/past#dev428)2020-07-10 02:00:50.407 am [info](http://ha-hubitat-home.vargofamily.com/device/edit/428)initialize() called

[dev:428](http://ha-hubitat-home.vargofamily.com/logs/past#dev428)2020-07-10 02:00:42.340 am [warn](http://ha-hubitat-home.vargofamily.com/device/edit/428)failure message from web socket failure: No route to host (Host unreachable)

[dev:428](http://ha-hubitat-home.vargofamily.com/logs/past#dev428)2020-07-10 02:00:39.214 am [info](http://ha-hubitat-home.vargofamily.com/device/edit/428)initialize() called

[dev:428](http://ha-hubitat-home.vargofamily.com/logs/past#dev428)2020-07-10 02:00:35.196 am [warn](http://ha-hubitat-home.vargofamily.com/device/edit/428)failure message from web socket failure: No route to host (Host unreachable)

[dev:428](http://ha-hubitat-home.vargofamily.com/logs/past#dev428)2020-07-10 02:00:34.156 am [info](http://ha-hubitat-home.vargofamily.com/device/edit/428)initialize() called

[dev:428](http://ha-hubitat-home.vargofamily.com/logs/past#dev428)2020-07-10 02:00:32.110 am [warn](http://ha-hubitat-home.vargofamily.com/device/edit/428)failure message from web socket failure: sent ping but didn't receive pong within 30000ms (after 868 successful ping/pongs)

[augoisms]

Interesting. The WeatherFlow API was acting strange for me yesterday, so perhaps that's part of it. From your logs, it looks like the WebSocket never actually connected, but also did not result in a failure. Automatic reconnects are triggered on failures.

Perhaps I need to add a health check that periodically makes sure we're connected and receiving data, if not run initialize again. I'll have to think on this a bit.

[JDogg016]

Works perfectly! (Had to wait for rain/lightning). I did have to reinitiate the device again, but it seems all is well.

[augoisms]

I just pushed an update that adds a health check. It runs every 5 minutes and checks to see if we have received an observation within the last 3 minutes. If not, it will issue a reconnect.

I've been monitoring this for a few days and I've noticed the WeatherFlow API will stop sending data or have connection errors, usually sometime in the late evening for 5-10 minutes. The health check will keep retrying and eventually get things reconnected.

[ronv42]

Just want to say this has been running great for a week now. I did have a couple of unexpected data quality issues with what was returned by their websocket such as a huge swing in luminance and temperature in a few data pushes which scared the crap out of me when my "freeze" warning came on in the middle the summer and lights turned on in the middle of the day.

I am looking at your code and I am trying to think of a way to deal with out of bounds data reads like using a 5 minute rolling average and compare the new values to that before publishing the value changed event. This issues is what is an acceptable delta? I have such sanity measures in our applications at work for real time eventing.

I will keep thinking about this and maybe brush up on my groovy skills and do some prototypes.

[augoisms]

Glad it’s been working well!

I noticed a similar issue when writing my “open the windows” app. WeatherUnderground would sometimes send me temps that were wildly off, so I started to record the last event and then discard any over a certain delta. Temperatures can change rapidly, especially in the evenings, so you would have to be careful how you created your averaging logic.

For inspiration, you can use this averager from Hubitat:

HubitatPublic/averageTemp.groovy at master · hubitat/HubitatPublic · GitHub

[dman2306]

@augoisms Does this only work with public stations? I don't see any info on how to set it up using a private user token?

[dman2306]

I figured out a way to make it work. I used their REST API to generate an auth token for my station which I then supply as the API key. Now if only HE added UDP broadcast support then we could make this thing local!!!

[augoisms]

Glad you got it working! So no changes were needed to the code? Their docs say you have to specify the token differently, but their docs aren’t always the most up to date.

[nh.schottfam]

can you share this procedure?

[dman2306]

Yeah. I’ll post something tonight when I’m done with work.