Weatherflow Tempest Weather Station (New Plugin)

[jltnol]

When it's raining, how often does Tempest update the data into the plugin? Not really a problem, just curious.

[Grognard]

When it's raining, how often does Tempest update the data into the plugin? Not really a problem, just curious.

Obviously Glen knows best,but the UDP (local) updates are essentially real time, about once a minute. The web updates are a different story because of how their “nearcast” rain feature works. They seem to update at a similar rate, but revise over a few minutes. Prior to installing this plugin, i hadn’t been systematically comparing local vs web data. That said, we have an official county weather station about 1/4 mile away, and it is generally pretty close to the “nearcast”number. I will continue to monitor and report anything interesting.

[GlennNZ]

Hi all,

1.
Thanks for finding that feature - I'll have a look - the simplest solution is likely to remove the units altogether from the CP / Triggers. But will see.

2.
Tempest UDP (Debug logging shows this)
- Essentially a realtime push
- Wind updates (rapid-wind) are real-time, along with significant other changes, including rain start, temperature
- Web side - is polled - and then updates the web side rain data which they fudge with a bit (latest version separates this completely so can choose what to use)

EcoWitt Plugin/Weather station & plugin
- A cheaper option for hardware

I actually now have both, as Tempest dying after 3 years, and thought Ecowitt looked interesting and similar. Then Tempest support offered me 50% off - so got both New Tempest yet to arrive and old tempest in Ecomode, so not all data sent.

Ecowitt differs slightly
- Sends data every 60 seconds with no pushing
- As a system -does have a number of additional sensors which can be added (bit like Oregon old systems) Including cheap Temp/Humidity sensors
- Rain Station WH40 I added which seems to give very accurate rain fall data, and does differ a bit from the Piezo sensors on the Ecowitt WS90 .
- Once added (essentially turned on) these sensors then appear in the states of the plugin device.

[jltnol]

So I'm pretty sure I understand how this is supposed to work. I've actually messed around with the NOAA plugin and icons, and got that to work on a Control Page, but NOAA updates are far too slow to be of much use.

Back to this plugin, I have a "base" weather.png icon, and have chosen it on the control page "As Image", and it does show up on the control page. I've also included the weather icon text as another page element (for the time being) on the same page.

So I've got some icons, and they are all named weather+cloudy.png (well, at least 1 of them is...), and while on the page the icon text says "Cloudy", the icon is the same as the base icon.

So 2 questions: I'm assuming the icons don't all have to be the same.... ie some can be "animated" and some "static", at least during my test phase, is this right ?

and 2nd, with the NOAA plugin, the actual base icon is called NOAA Conditions+.png, so am wondering if the base icon should have a "+" in the file name as well?

Past that, not sure what else I've got wrong, but have double checked spelling, but don't see anything wrong, yet none show up correctly.
Do I need to include the word "condition" in all of the icon file names? is that my mistake ?

[GlennNZ]

So I'm pretty sure I understand how this is supposed to work. I've actually messed around with the NOAA plugin and icons, and got that to work on a Control Page, but NOAA updates are far too slow to be of much use.

Back to this plugin, I have a "base" weather.png icon, and have chosen it on the control page "As Image", and it does show up on the control page. I've also included the weather icon text as another page element (for the time being) on the same page.

So I've got some icons, and they are all named weather+cloudy.png (well, at least 1 of them is...), and while on the page the icon text says "Cloudy", the icon is the same as the base icon.

So 2 questions: I'm assuming the icons don't all have to be the same.... ie some can be "animated" and some "static", at least during my test phase, is this right ?

and 2nd, with the NOAA plugin, the actual base icon is called NOAA Conditions+.png, so am wondering if the base icon should have a "+" in the file name as well?

Past that, not sure what else I've got wrong, but have double checked spelling, but don't see anything wrong, yet none show up correctly.
Do I need to include the word "condition" in all of the icon file names? is that my mistake ?

Icons should all be png name files - but don’t believe will matter whether under that are apng or static png.

Base icon - is any name, no need for conditions, with a plus weather+.png weather+Cloudy.png weather+Raining.png etc. Case likely matters here are well. If there is no match it defaults to the + icon.

Seems like probably almost there


Sent from my iPad using Tapatalk

[jltnol]

Ugh.

Rookie mistake.

I did NOT have the "+" in the file name for my default icon. Put that in, updated the Control Page, and all is well.

Thanks again for a great plugin and endless support.

[whmoorejr]

I think I may have found an "undocumented feature" though: Despite having my Weatherflow device presences set to °F, all menus which reference custom states (e.g., triggers/conditions) show as °C. It looks like this is in fact the case for any trigger/condition which has both metric and imperial values. The test appears to evaluate correctly (in the above example it was 88 °F out, but the Condition evaluated as true), so this appears to be a cosmetic bug.

To add to this.... I can't use UDP (My weather station is on a different subnet.) I'll probably move it back to the same as my indigo machine at some point. Adding it as a Tempest Weather Station worked just fine and it shows the correct tempF in both Custom States and on the Indigo GUI.

I then decided to add a few public stations for places I like to go or have family. They all show the Celsius value. Currently is says it's 26.9F in Lubbock where it is currently 80. If I change the setting to Celsius, then it just says 26.9C. So the math part of that device is missing somewhere.

[GlennNZ]

WeatherFlow Tempest — Plugin Update v2.5.8

Four bug fixes: Public Tempest Station unit conversion,

Code: Select all

last_strike_distance

and

Code: Select all

last_strike_time

not updating during thunderstorms, and strike log visibility. Plus a Distance Display preference (km / mi) for Tempest, Sky, and Air devices.

Wiki: https://github.com/Ghawken/WeatherFlowTempest/wiki
GitHub: https://github.com/Ghawken/WeatherFlowTempest
Release notes: https://github.com/Ghawken/WeatherFlowTempest/wiki/Release-2.5.8



Bug 1 — Public Tempest Station always showed metric regardless of configuration

A Public Tempest Station configured for Fahrenheit, mph, and inches was still displaying °C, m/s, and mm. The plugin was sending unit parameters to the

Code: Select all

observations/station/{id}

API expecting it to return converted values — but this endpoint returns metric regardless of what unit params are sent.

Fix: The public station fetch now always requests metric, and the plugin converts to user preferences using the same Pint-based conversion used for personal stations. Temperature, wind, pressure, rain, and lightning distance are all now correctly converted. No reconfiguration needed — values will show in your configured units immediately after plugin reload.



Bug 2 —

Code: Select all

last_strike_distance

only updated when UDP was inactive[/b][/size]

The web API always provides

Code: Select all

lightning_strike_last_distance

, but the plugin only read it inside a block that only runs when UDP observations are stale or inactive. With a working UDP device,

Code: Select all

evt_strike

UDP packets are supposed to keep this state current — but

Code: Select all

evt_strike

is a separate event that can be silently dropped even when normal

Code: Select all

obs_st

observations are flowing. When that happened, the state never updated from either path.

Fix: Moved to the always-runs section — refreshes on every web poll regardless of UDP status, the same way

Code: Select all

lightning_count_last_1hr

/

Code: Select all

lightning_count_last_3hr

already did.



Bug 3 —

Code: Select all

last_strike_time

had no web source at all[/b][/size]

The WeatherFlow REST API returns

Code: Select all

lightning_strike_last_epoch

(Unix timestamp of the last strike) in every observation response. The plugin never read it.

Code: Select all

last_strike_time

could only ever be populated by UDP

Code: Select all

evt_strike

packets — no web fallback existed.

Fix: Added

Code: Select all

lightning_strike_last_epoch → last_strike_time

extraction in the always-runs section.



Bug 4 — UDP strike events logged at DEBUG only

The strike handler only emitted its summary at DEBUG level, making it impossible in normal operation to tell whether

Code: Select all

evt_strike

packets were arriving at all.

Fix: Promoted to INFO — every UDP strike now logs

Code: Select all

distance=X  energy=Y

.



New — Distance Display preference for Tempest, Sky, and Air

Lightning distance states were always displayed in km regardless of configuration. The Public Tempest Station device type already had a Distance Display preference; this release adds the same option to Tempest, Sky, and Air devices.

• New Distance Display field (Kilometres / Miles) in Edit Device for Tempest, Sky, and Air
• Lightning distances (

  Code: Select all

  last_strike_distance

  ,

  Code: Select all

  lightning_strike_average_distance

  ) now convert to the selected unit
• Existing devices default to km — open Edit Device and set Miles if needed

Understanding the lightning states

Three groups of states that update at different times and answer different questions:

Per-observation states (reset every ~1 minute)

• Code: Select all

  lightning_strike_count

  — strikes in the current 1-minute window. Resets to 0 at the start of each new observation. Not a running total. Being 0 between strikes is completely normal.

• Code: Select all

  lightning_strike_average_distance

  — average distance of strikes in that same window. Only meaningful when count > 0. Reads 0 the rest of the time — not the same as a strike at 0 km.

Per-strike states (persist until the next strike)

• Code: Select all

  last_strike_distance

  — distance of the most recent strike. Blank until first strike, then persists. Always read alongside

  Code: Select all

  last_strike_time

  [/b] to confirm it's from a current storm. Blank if sensor could not determine range.

• Code: Select all

  last_strike_time

  — UTC timestamp of the most recent strike. Persists until the next strike.

• Code: Select all

  last_strike_energy

  — dimensionless relative intensity (not joules/watts). Useful for comparing within a storm only.

Rolling window counts (requires Web API token, updated every ~60 s)

• Code: Select all

  lightning_count_last_1hr

  — quality-controlled count of all strikes in the rolling last 60 minutes. The most reliable indicator of current storm activity. Use this in triggers.

• Code: Select all

  lightning_count_last_3hr

  — same but 3-hour window. Useful for tracking a storm's approach or retreat.

Quick guide: "Is there a storm right now?" →

Code: Select all

lightning_count_last_1hr > 0

. "How far was the last strike?" →

Code: Select all

last_strike_distance

+

Code: Select all

last_strike_time

. "Is it getting closer?" → compare

Code: Select all

lightning_count_last_1hr

vs

Code: Select all

lightning_count_last_3hr

.



Full release notes: Release 2.5.8

[whmoorejr]

Thank you for the updates. I'm running 2.5.8 now. (FYI: your still on 2.5.5 in the plugin store).

[jltnol]

Soooo which Trigger point on the RIGHT corresponds to the State on the LEFT?
Looking for a Trigger that will fire every time the "rain_today" changes.....

Trigger Point.png (467.92 KiB) Viewed 170 times

[GlennNZ]

Hi,

Potentially the one you are after is Rain Today since local midnight - that reflects the one you are pointing to.

Rain states — two families

There are two parallel sets of rain totals. When you open a Device State Changed trigger the list shows both, which is where the confusion comes in.

Family 1 — WeatherFlow cloud values (rain-check corrected)

These come from the WeatherFlow web API. WeatherFlow runs a Rain Check algorithm that cross-references nearby stations to filter out
false triggers (spider webs, bird impacts on the sensor) and adjusts the total accordingly. This is the same number the WeatherFlow app shows you.

• Rain Today (since local midnight) — the one to use. Updates every minute, resets at local midnight.
• Rain Yesterday — yesterday's corrected total.
• Rain Today Raw (internal) — internal mm store used by the plugin. Ignore in triggers.

Family 2 — Local UDP values (raw, no rain-check)

These come entirely from UDP packets broadcast by the hub — no internet required. The sensor reports how much fell in the previous minute and
the plugin accumulates it. No Rain Check correction is applied.

• Rain Today Local (device source, not rain-check corrected) — raw running total for today.
• Rain Yesterday Local (device source, not rain-check corrected) — yesterday's raw total.
• Rain Today Local Raw (local device accumulation only) — internal mm store. Ignore in triggers.
• Rain Today Local Source (hub = device direct / accumulated = per-minute fallback) — diagnostic string showing how the local total was
  built. Not a number — ignore in triggers.

For a trigger that fires every time today's rain total changes → choose Rain Today (since local midnight)

It fires roughly once per minute while rain is accumulating. If you want to avoid it firing on the midnight reset back to zero, add the condition: new
value is greater than old value.

[jltnol]

Wow!

You answered my question and even my next question, which was what all those different rain amounts mean. I'm using the MatPlotlib plugin to create a rain bar graph, and once the trigger fires, does some conversion from MM to inches, and after a few more steps, creates the graph. And I have a schedule at 11:59PM that disables the trigger, does some number rotations, then re-enables the trigger at 12:01AM.

The plugin is amazing! I really appreciate all the work you've put into this, and now that all the rain data has been solved, and I have my Conditions Icons working, I'm all good.

Thanks so much for you never-ending help and support.

[jltnol]

I live literally less than 1 mile away from the NOAA weather station which I also monitor in Indigo, so while I never expect their reading to match the readings from my Tempest, nevertheless they are, generally speaking,... pretty close. Tempests updates much more quickly than NOAA, which is why I love it so much.

But as we go through the "Heat Dome Of Summer" here in the south, the Heat Index readings from my tempest are generally MUCH higher than NOAA, by as much as 15 degrees sometimes.

Granted it all depends on where the Tempest is located, how high up.. a million factors that can affect this. But am generally wondering if the Heat Index as shown with this plugin is actually coming from the Tempest, or is the software doing some behind the scene calculation for this data?

While it's nice to claim 120º heat index during parts of the day, based on the corresponding data from NOAA, I'm just not quite sure this is really the case.

So, NOT an problem... just looking for some clarification about how Tempest handles the Heat Index data.

THANKS!

[McJohn]

Hi Glenn,

Big compliments for another great plugin, we collect them all!

Do you think you could add the following custom states?:

rain_lastweek
rain_lastmonth

We know that it is not in the Tempest API data, but perhaps you can calculate it?
We are now using an old RFX rain gauge and the RFX plugin also contains these weekly and monthly custom states.
And especially for irrigation, it is useful to know whether it rained last week/month (and how much) (or not).

Thanks in advance and all the best,

John

[GlennNZ]

Hi John

See version 2.6.0

https://github.com/Ghawken/WeatherFlowT ... ease-2.6.0