WET-IT — Weather-Enhanced Time-Based Irrigation Tuning for Hubitat

I tried looking for global solutions. There is one, SoilGrids, but it's still in beta and not reliable. I tried it even though they said the service is “suspended.” The endpoints are up but don't always work or have valid data.

At least WET-IT has the right season for you. I did build that smarts in. :wink:

1 Like

Have installed the latest version with scheduling and set up all 6 zones on my B-Hyve controllers. It passes all the diagnostics, but gives a No valid API key error. How can I fix this?

Are you seeing that for any of the other wx providers or just Tempest? I tried to recreate it on my end, but I don't have access anymore.

Last API Test: :x: TEMPEST API test failed: status code: 401, reason phrase: Unauthorized

Cutting me off is the right thing to do, it just makes it harder to make sure what I'm seeing is the issue. :wink:

The logs show you are definitely getting weather and connecting at the validation stage. Looking at the code, I think the issue is when the wx update occurs every two hours.

If you'd be so kind as to let me in, I'll validate the fix I just made and then push it.

What controller are you using to get this working, I am also in Aus and keen to get this setup.

Ecowitt GW1101 / WS69

Sorry I was talking irrigation controller.

Oh sorry, I’m just using tuya Zigbee valves.

https://a.aliexpress.com/_mPsJsdj

1 Like

I’m so far from needing irrigation right now in the Pacific Northwest, but really looking forward to giving this a spin. Orbit B-hyve has been so unreliable with the forecasting that I just switched to time based last summer.

Would it be possible to just allow users to select weather station sensor data manually, and add separate forecasting from one of the existing sources you’re already using? There are already enough ways to get personal weather station data into Hubitat, so we should be able to just select the sensor data and put them into your app without you having accomdate a number of different weather station APIs.

1 Like

Awesome thanks, just purchase the Tuya 8 zone from Ali, hopefully that plays nice.

1 Like

Turns out the issue was indeed the API key, not the app. :wink:

All good now.

The short answer is... no. :wink:

Here's the longer reason why it's a no.

Forecasting and observations are two very different things. Sure, there are many ways to get PWS observations into Hubitat, but those aren't necessarily forecasts. Sensor observations don't help.

For example, integrating Tempest was quick and easy. There is a defined API with a data contract that is invariable. By contrast, I looked at integrating Ambient, and it won't work as a data supplier for WET-IT, despite being a very popular PWS. As an example, this contrast shows why you can't just take PWS data and incorporate it without knowing more about the source, its characteristics, and the data contract.

Tempest is effectively:

  • a station + opinionated aggregation layer
  • with stable semantics
  • designed to be consumed programmatically

Key points that align with WET-IT:

  • Single-station worldview (clear ownership of “truth”)
  • Explicit fields with known units
  • Predictable schema
  • “This is what my station measured today” mentality

That makes it safe to:

  • treat Tempest rain as today’s rain
  • treat Tempest wind as current conditions
  • fold it into ET logic without mental gymnastics

Ambient looks similar on the surface but behaves very differently:

  1. Ambient is a data broker, not a station platform
  • Multiple firmware versions
  • Multiple device classes
  • User-configured aggregation rules
  • Schema drift over time
  1. No single semantic contract
  • “Rain today” can mean:
    • reset at midnight local
    • reset at station boot
    • rolling accumulation
  • Wind fields vary by device type
  1. Account-first, not device-first
  • Everything is scoped to user accounts
  • Makes HPM installs, recovery, and diagnostics harder
  1. ET contamination risk
  • Ambient data is observational
  • Tempest is observational but constrained
  • Ambient invites double-counting unless it is aggressively walled off

To use Ambient safely, we'd need:

  • per-field trust rules
  • station capability discovery
  • per-user override semantics

Tempest:

“Here is the station, here is the rain, here is the wind.”

Ambient:

“Here is some data from some devices tied to this account.”

Those are fundamentally different trust models.

WET-IT needs deterministic inputs.
Ambient introduces interpretive ambiguity.

The same applies to just opening up to allow any user to select any weather data.

I've also been careful in the data modeling and conversions. Trying to accept any data and conversion leads to precision errors. Is the rain data being provided in mm or inches? Are the wind speeds in MPH, KPH, kts, m/s? Is the unit articulated in the data contract?

To paraphrase George Orwell, when it comes to personal weather stations, “Some are more equal than others.”

2 Likes

[UPDATE] WET-IT 1.1.0.0 — Weather-Enhanced Time-Based Irrigation Tuning for Hubitat — Scope Creep Edition

I know I said I wasn't going to make WET-IT a scheduler, and then I did anyway. Well… here's the rest of the scope creep.

Five fully integrated weather providers
* NOAA (US Only)
* Open-Meteo
* OpenWeathermap
* Tomorrow. io
* WeatherFlow Tempest PWS

This is a big deal. Having Open-Meto means we have a second API key-free source. NOAA is great, but it's only available for US locations. Open-Meteo is global. All four cloud providers have their pluses and minuses. Pick the one that best suits your needs. If you have a Tempest, it's the most authoritative for hyper-local forecasting and observations.

Optionally, you can choose a backup provider for observations and alerts:

Primary Fallback
Open-Meteo NOAA (US only)
NOAA Open-Meteo
OpenWeather Open-Meteo
Tomorrow. io Open-Meteo
Tempest Open-Meteo

So, now, if you don't want to use an API key (even though they're free for our level of usage), Open-Meteo works for everyone.

Geolocation handling and ISO 3166-2 regional awareness.

WET-IT now maintains a geolocation cache seeded from your hub's lat/lon. Upon installation, your regional information (country, province/state/region) is looked up and stored (this is anonymous, no PII, no cookie). Services that are not available for your geography are not displayed/made available. For example, if you're not in the US, you won't have NOAA as an option. The same for USDA soil type. (SoilGrid is still on the roadmap and will be here once they “fix” themselves.)

The other benefit to the geo-cache is that location API calls are greatly reduced. If your hub's lat/lon hasn't changed, there's no reason to look up which geo capabilities are different from the last time. The internal cache also reduces the calls to the hub's lat/lon service.

Soak & Cycle

  • Per-program cycle splitting and soak delays
  • Integrated with ET, Saturation Skip, and end-by-time/sunrise scheduling
  • Improved infiltration modeling and runoff prevention

The current implementation is “an implementation.” It currently completes one zone before moving to another. Ideally, it will move from zone-to-zone as a first pass and then cycle back to complete the next partial waterings. I didn't want to let perfection stand in the way of good enough. This one is proving harder to pull off than I thought, particularly when using end-by timing.

Saturation Skip

  • Automatically skips ET-adjusted programs when all zones are at or above calculated field capacity.

Amazon Echo integration:

  • Voice control via Hubitat Echo Skill

You can now start/stop and get status of scheduled programs via the Echos. Integration is via the built-in Amazon Echo Skill. No additional Amazon skill is necessary so you can just say, “Alegra, turn on the sprinkler” and not the long, “Alegra, ask Rain Bid to run Schedule A.” :face_vomiting:

Because the Echos are a “fire and forget” service, we can't ask it for things like, “How much time is left on Zone 1?” The best we can do is, "Is the sprinkler on?"

I'm not sure when I would use it either, but if the others have it, why not build it in here? :wink:

Hardened Scheduler Reliability

  • Guards against simultaneous program execution
  • Correct handling of partial zone completion and ET recovery
  • Refined irrigation tick logic to prevent repeat skips

Notfications

You can optionally receive a notification if the weather forecast data gets stale. This could be from a temporary outage (it's been known to happen for NOAA) or a critter destroying your PWS. There is also an option to automatically suspend all scheduled programs if the diurnal ET data becomes stale. In other words, if the data is stale, stop automatically watering until a human checks it out and turns the schedules back on.

Tool-Tips

There are now internal help screens for most sections. You can read them, ignore them, or turn them off completely under Logging & Tools.

There are a bunch of internal refinements as well. The latest has been published to HPM.

2 Likes

Thanks for adding Open-Meteo. This helps significantly. I thought maybe I could get some of the Tempest data from nearby stations sharing their data (there are three within a few blocks of me), but Tempest does require you to be a Tempest owner to get an API key, so that one isn't really free.

For the rain sensor, I can just create a virtual water sensor and use my station's hourly rain rate to trigger it. :+1:

1 Like

One more scope creep.....

It would be great to have an offset for Sunrise in both the start and end at Sunrise.

My use case is with summer time in Houston the sun gets up quickly. On sunny days the sun scortches wet grass. Water needs a bit of time to evaporate with the humidity. So I start watering the front lawn at dawn.

Hmmmm... Give 'em an inch... :laughing:

A time offset to sunrise isn't really “dawn,” aka civil twilight begin. I have a webCoRe piston I wrote years ago that sets global variables for dawn/dusk, twilight, etc. I use it for just about every one of my “time of day” items. I think I have one timer set to “sunrise.”

AAMOF, I have two driveway sconces that run dusk to dawn from HE. They are always in sync with the neighbor's “light sensors.”

That being said, I'll put a “dawn” setting on the whiteboard. :wink:

Since 1.1 just hit, let's see if anyone else has any other OFIs or issues, and I'll push it in the next update. I did a lot of testing before pushing to HPM but, as we know, no code survives first contact with the users.

[UPDATE] WET-IT 1.2.0.0 — Weather-Enhanced Time-Based Irrigation Tuning for Hubitat — Astronomical Edition

This one's for you, @JimB. The app now understands sunrise/sunset and dusk/dawn. You can schedule a program to start at or end by dawn in addition to sunrise.

The diagnostic section now shows:

:waning_crescent_moon: Day Length: 10:26 | Dawn: 6:47:05 AM | Sunrise: 7:13:32 AM | Solar Noon: 12:26:38 PM | Sunset: 5:39:44 PM | Dusk: 6:06:10 PM

Yes, those timestamps are calculated to the second based on the lat/lon of your hub. :wink:

If you really want to dig deep into ET, the daily soil measurements should be taken at solar noon (the point in the day where the sun truly is at its zenith for your position). The ET calculations built-in do not do that, but since I had the data, I figured I'd expose it.

You should never water your lawn at night but if you're in an area with an HOA or local time restrictions, you can now set your sprinklers to start precisely at dusk. Or, water the lawn with an "end-by" dawn and set another schedule for your soaker hose to run at dusk. It's all up to you.

The astronomical events are published in the JSON and to the child driver as attributes:

  • solarDate
  • dayLength
  • dawn
  • dusk
  • nightBegin
  • nightEnd
  • solarNoon
  • sunrise
  • sunset
  • twilightBegin
  • twilightEnd

I also enhanced the schedule conflict detection and reporting.

Hint: If you really want your Hubitat lights to run “dusk to dawn,” use the attributes that are now available in the child driver.

“Dusk” is not really “30 minutes before sunset.” It's close but not exact.

I've been using these triggers for years, and I get a little chuckle out of watching my outdoor lighting come on exactly when my neighbor's photocells turn on theirs. I have the advantage of being able to turn them off when we put the hub in 'night' mode and not having them run all night.

Another use is in the morning. The shade over our kitchen sink opens precisely at dawn every day of the year.

The update has been published to Git and HPM.

1 Like