Yet Another Weather Driver (but for Edge!)

Yes, I experienced this in my tests…

1 Like

In this case it looks like it is the value that is missing, not the units. That would mean that for some reason you’re not getting that temperature data value returned. Can you share the URLs you have configured for current conditions and forecast (blank-out your API key).

It should look something like this:

Current Weather

https://swd.weatherflow.com/swd/rest/observations/?device_id=nnnnnnn&token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Weather Forecast

https://swd.weatherflow.com/swd/rest/better_forecast/?station_id=nnnnn&device_id=nnnnnn&token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

User error, again …

Using the URL you gave with a correct device_id (I had it wrong initially) and all is good.

Sorry for the false error report.

1 Like

@TAustin Getting an error on an illuminance value that is too large:

2023-05-05T16:56:41.673926262+00:00 ERROR Edge Weather V1 driver thread encountered error: [string "st/capabilities/init.lua"]:226: Invalid value for Illuminance Measurement.illuminance value: {value=113614} error: Given 113614 for value. Number out of bounds: 0 - 100000

Must be awfully bright there! Is this from WeatherFlow Tempest?

I’m also curious: what is the UV Index reading?

I may have to add an upper bound fix.

Very bright today!

Yes, this is from WeatherFlow Tempest.

Current readings:

It will have to be capped at 100,000 since that is the max supported by SmartThings. Will get you a driver update momentarily…

1 Like

Driver Version 2023-05-05T18:01:57.084913553 has been pushed out that caps the illumination field to max of 100,000 lux.

1 Like

Back in business. Thanks Todd!

Sometimes, this is because the value need to be divided by 10 or 100.

I don’t think this is the case, but it worths to mention.

Is it possible to use buienrader.nl with this edgedriver? I live in the Netherlands and its our most used weather app.

I checked out the link and I see that there is one URL that returns data for some number of stations. Is it possible to add parameters to the URL to get just the station you are interested in? I’m looking through the websites and don’t see any documentation of what is accepted.

@TAustin I scanned though the thread but didn’t see anything (apologies if it’s there and I missed it) … is there are reason why ‘feels like’ is not something you are parsing (in my case I care about WeatherFlow)?

There is an entire ecosystem of weather nerds that use Ecowitt sensors, and the ecowitt interface (this is basically the hardware manufacturer for AmbientWeather).

The ecowitt API is easy to parse, and has support for many (many!) more devices than other weather solutions. Would it be possible to create a driver for the ecowitt API calls? I can provide the API code, and would be willing to DM you my API credentials to see what the json looks like, or provide it here (I use Postman a lot so it’s easy to give you a raw file).

Sorta. They both use other manufacturers to make their hardware, including Fine Offset. But EW and AW are competitors.

Anyway, I have it on my list to finish a local implementation of an Edge driver for the GW1000/GW1100 series gateways. Since they’re both on the local LAN no external server would be needed. Hopefully I’ll get more time in the coming weeks/month.

2 Likes

If you need testers, let me know. Currently I am polling my Ecowitt through WU using this edge driver (works great as long as WU is up). I also run Cumulus locally collecting the data for internal dashboards and gadgets using cumulus api calls. I did this long before Ecowitt offered up an API.

Thanks for the clarification, always challenging to know who the OEM is :slight_smile: I’m looking forward to seeing what you can come up with, if you need any UAT, let me know!

@TAustin I ended-up calling this myself via the API in SharpTools.

Another question though … I’ve noticed when the driver gets an update from the API the precipprob and summary fields change to 0 and blank momentarily then they update to the actual values from the API call. Is this by design? If not and you want to take a look I have logs available.

To answer your original question - I had to make some decisions regarding what fields to include in these weather devices. What I ended up with was driven by the most common elements that were available across the various weather sources. ‘Feels like’ was not a commonly available field. I could possibly add it at some point, since for any given weather source, there’s always going to be blank fields where that particular data point is not available. I wanted to minimize having too many unused fields, but supporting a variety of weather sources makes that pretty much impossible!

I think what you are seeing is a result of a somewhat unique situation with the weatherflow data, in that the ‘current’ data values for those fields are received from the forecast data instead of the current conditions data. So they are getting set to blanks or 0 when the current conditions are received & updated, and then getting set to the real values only when the forecast data is received. So, yea, not necessarily by design, but to accommodate this unique case.

2 Likes

Thanks Todd, I appreciate the background on these items.