Irrigation rule: Has it rained yesterday and will it rain tomorrow?

In order to let openHAB decide whether the sprinklers should be activated, I assume the best factors are whether it rained yesterday and whether it will tomorrow (and how much mm fell).

I searched for relevant topics, but they all seem rather outdated. I now created two items through the Openweathermap binding:

  1. From thing Local Weather and Forecast (One Call API): an item with channel forecastTomorrow#rain
  2. From thing Local History Data (One Call API): an item with channel history#rain

(About that thing Local History Data (One Call API)… The documentation states for each day, a seperate thing must be made (OpenWeatherMap - Bindings | openHAB), but it also states that in the thing settings, you can have the thing go back as far as 5 days (OpenWeatherMap - Bindings | openHAB). This sounds contradictory…?)

Anyway, let’s see what these have to items offer.

But if anyone else has done this exercise already, your advice is most welcome! :slight_smile:

Hi @ErikDB , for the history entries that means that you can go back up to 5 days in history, and every thing covers one day. So if you want to see the last 3 days, you have to create 3 different things. The 5 days limit says that it is not possible to create a thing that looks to day 6 in the past, as the API does not support it. Does that explanation help?

1 Like

I gave up using openweathermap. Haven’t got enough time to look into it more closely, although I did use it for more than two years.

In the end I just rely on my local weather station, which provides me information about the current rainfall, so I know how much has fallen in the past 24 hrs. No forecast data though.

How do you integrate that in openHAB?

I bought an ecowitt weather station (ECOWITT GW1101). It communicates via RF (433MHz?) from the outdoor station to a USB dongle. That goes to a docker (ecowitt2mqtt) and from there via mqtt, to openhab.

I see; I misunderstood the meaning of ‘weather station’. :slight_smile:

What about today?

In OH 4.1 the ability to store future values into persistence (MapDB and rrd4j are not supported). However, it won’t be until OH 4.2 that all the persistence actions are updated so you can query for these values in a rule.

OWM was one of the first add-ons to implement this forecast capability, though note that it requires special configuration of the Items under persistence (i.e. you need to add a forecast strategy. See openHAB 4.1 Release | openHAB. However, since the actions aren’t there yet you’ll either need to upgrade to the milestone (or wait a week for 4.2 release) or go about this the old way.

But once you have it you should be able to have one forecast rain Item and query persistence to get today’s and tomorrow’s forecast.

In the mean time:

Not contradictory, it’s covering two different aspects of the Thing as @Wolfgang1966 describes. You must create a separate Thing for each day in history you want. So one for yesterday, day before yesterday, three days ago, etc. But there is a limit. But you cannot go back more than five days. So creating a Thing for six days ago is not allowed. The historyDay property cannot be > 5. That does not mean that one Thing can go back up to five days. You still need a separate Thing per history day.

1 Like

I see, thanks for the explanation. :slight_smile:

And if I want to go back one day (i.e. yesterday), I put “1” under History Day in the thing configuration, I assume? (The wording number of days confused me, but I can’t immediately think of better phrasing myself…)

Yes, that’s how I think it works. I only use the current values from OWM so don’t have direct experience with history and forecast.

In Thing One Call API weather and forecast i created for channel:
openweathermap:onecall:xxxxxxx:local:current#rain (Number:Length) an Item OneCallAPIhistorydata_Regen

and for channel:
openweathermap:onecall:xxxxxxx:local:forecastTomorrow#rain (Number:Length) an Item

in the rule for my purpose the calc is:
WassermengeRegenLast2Days = (items.getItem(‘OneCallAPIhistorydata_Regen’).history.sumSince( / (2 * 24 * 60);
WassermengeRegenMorgen = items.getItem(‘OneCallAPIweatherandforecast_Regen’).state;

1 Like

What threshold do you use for both rain “quantities” in order to irrigate?

Also, I get an unexpected result from the “rain for the past two days”:

var regendevoorbijetweedagen = (items.getItem("regen_nu").history.sumSince( / (2 * 24 * 60);
var regenmorgen = items.getItem("regen_morgen").state;

console.log("regendevoorbijetweedagen = " + regendevoorbijetweedagen)
console.log("regenmorgen = "+regenmorgen)


2024-07-06 08:34:02.403 [INFO ] [mation.script.file.irrigatieRegel.js] - regendevoorbijetweedagen = 0.4393967916666666
2024-07-06 08:34:02.404 [INFO ] [mation.script.file.irrigatieRegel.js] - regenmorgen = 1.38 mm

I assume this has something to do with the unit of measurement, with which I fiddled a bit to get it from m to mm…?

These are the two items:

state description: %.3f mm


state description: %.3f mm

Anyone any idea why the “sum” isn’t in mm? And how can the product of 2 * 1.38 start with a 4?

(Also, it seems unlikely yesterday (I noticed this yesterday), today and tomorrow all experience exactly the same amout of rain (1.380 mm), but I assume that’s OWM ‘fault’?)

I tried to standardize it to mm and the calculation for lawns and flower beds to mm/m².

The idea is to get the values ​​from ow, then depending on your soil (loamy, sandy, etc.) to know how much water (mm/m²) is needed. For example, with my lawn I look at the last 5 days and the 1 day forecast, as watering every 5 days makes sense here, the flowers need water every 2 days. I have been using this procedure as a set and forget for over 3 years now, as the rule only applies until the temperature falls below 10°C at night, for example.

And how did you do that?

If you are not on a recent 4.2 milestone or, the just publkished release, persistence actions do not return value with units.

Also keep in mind that the .state of an item in JS Scripting is a string, not a number. use .numericState to get a plain number or .quantityState to get it with units.

It can’t meaning that the calculation is what you think it is. How many entries are there and what are those entries you are doing the math with?

It also rained quite hard a few hours ago, but…:

This doesn’t aspire confidence in Openwearhermaps as source…


You don’t show what Channel that Item is linked to, how often OH polls OWM for new information, and lots of other factors that could impact this reading. For example, if it’s a forecast Channel, it’s not going to reflect the actual amount of rain that fell. If rain fell unexpectedly the forecast Item would remain 0.

Depending on where you live, no forecast or even now cast is going to be that good. Where I live temperature can vary by 5-10 °F in as little as half a mile and it could be raining heavily across the street while my yard remains dry. No weather service can handle that well. If you want accurate weather info about your location, you need your own weather station.

However, if that Item is linked to the Rain Chanel under Current Weather and the rain started more than the OWM polling period ago (I think 10 minutes is the default) I would expect that Item to show some values other than 0. Note that the Channel represents the amount of rain that has fallen in the last hour so it’s not going to be useable for much else (e.g. total rainfall over the past day).

Apologies, you’re right.

OK, so that Channel does reflect the actual measured amount of rain that has fallen,. However, it only updated every 30 minutes. So if it started top rain 29 minutes ago, it will take another 30 minutes before any rain reading is reported. If it started raining 31 minutes ago, it will take 30 minutes before any meaningful amount of rain will be reported.

And any value reported to this Item is only going to cover the past hour. When it stops raining the Item will return to 0 60 minutes later.

Note: the random string in the Thing UID that you’ve redacted has no meaning. It’s randomly generated by OH to ensure each Thing has a unique ID and is not related to your API key, OWM account or anything else. You don’t need to redact it…

Also, it is pretty much always better to click on the code tab and paste in the YAML you find there than it is to post screen shots. Screen shots cannot be searched, copied and edited, and usually leave out a whole lot of useful information. Though do be careful to redact API keys and passwords and such from the YAML before posting.

1 Like

Okay, but then the “analysis” of the past day (as I posted above) should not be “0”, right?