[RELEASE] WeatherFlow Lite

⚙️ Custom Apps and Drivers
25

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!

26

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

27

My mistake, it would round to 400

1 Like
29

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.

30

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!

31

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
33

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
34

Interesting, good to know :+1:t3:

35

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

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.

37

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.

38

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

39

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?

40

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

41

Just pushed an update with the following changes:

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

Thank you to @nh.schottfam and @thomas.c.howard for their contributions.

2 Likes
42

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.

43

@augoisms lots of errors:

Failed to parse json e = groovy.lang.MissingMethodException: No signature of method: user_driver_augoisms_WeatherFlow_Lite_2622.formatDt() is applicable for argument types: (java.lang.Integer) values: [1596377282]
Possible solutions: formatTemp(java.math.BigDecimal)

There are also a ton of debug messages being logged even though I have debug logging turned off.

image
image1724×177 40.3 KB

44

Just pushed an update. There was a typo in the strike event handler.

I am purposefully logging the response when an exception occurs. I feel like it's helpful to debug issues, esp since logging gets turned off automatically. If you don't want that you can comment out line 161.

1 Like
45

Expecting thunderstorms here today, I'll test it out!

1 Like
46

I just got the same exception message in my log. Rain is starting to move in here in the Chicago area but we had a couple of cells popup with a few lighting alerts. Thanks for the fast update.

1 Like