meteohub.de

davidmc36 wrote: Sat Sep 06, 2025 4:00 pm If I wanted to make an alarm that included Solar Radiation, UV Index, and Sunshine duration, how would you fill in the X's? Especially the watts per sq meter??

[sol0rad-act=x.X:X] <= n.n [uv0index-act=x.X:X] <= n.n [sol0total-act=x.X:X] <= n.n

The basic variable structure is sensor-selector=convertor.decimals:replacement and depending on what the output is then convertor.decimals:replacement could be omitted all together and that removes the X's issue.

=x (Convertor) is only required if the default sensor data requires conversion to a specific unit like Temp default is Deg C and you want Deg F. You may want to use =h for sol0total to convert the value given in minutes into hours? Otherwise =x could be left out. sol0rad will only W/m^2

.X being number of decimals could also be left out but again just depends on the output required, Typically UV Index is reported as an Integer even though the underlying calc can be in decimals. Again most of the time can be left out.

:X being a replacement value is only useful when there is no valid data at the time and one might substitute a string like - - - to indicate this. Not sure I see any purpose of using a replacement in an alarm statement? Need to think further on this one.

If you only using defaults then start with the basics [sol0rad-act] <= n.n [uv0index-act] <= n.n [sol0total-act] <= n.n
and build onto as necessary/required

Mauricio wrote: Sat Sep 06, 2025 7:56 pm A problem that I have encountered is that every time my device, the trigger, gives the order to reboot daily with http://templates.meteobridge.com/reboot.sh it trigger a rain event (false).






Thanks for any help or ideas on how to fix this.

Fist question would be, why the daily reboot? What purpose?

Maybe look at number of decimals specified .0 being compared to a value of 0.2 (1 decimal)? rain0total default output is mm's with 1 decimal anyway.

Also look at the "Replacement" (zero/0) and how that is working being used in both the Raise & Clear

Rain can never be less than 0 so < used in the clear is irrelevant

Unrelated but you should make the minimum "raining" value something like 0.4mm which in Davis definitions (at least) is the start of a storm (rain) event, 0.2mm might not be rain but just a heavy dew?

Daily Reebot to update versions, simply because of that. It's not a Davis, it's a Fine Offset WT1081. Each rain gauge stroke is 0.3 mm. What would you set in the case of Clear? I'm unsure about that.

Mauricio wrote: Sun Sep 07, 2025 1:50 am Daily Reebot to update versions, simply because of that. It's not a Davis, it's a Fine Offset WT1081. Each rain gauge stroke is 0.3 mm. What would you set in the case of Clear? I'm unsure about that.

On the daily auto Reboot thing to update version, that's not a thing I will ever do for any hardware platform, period. Once a device is working then there's not need to update it unless the update fixes something that is specifically broken. Each one to their own thinking but I manually control how, when and why any device is updated.

I would suggest reading the Templates WiKi https://www.meteobridge.com/wiki/index. ... =Templates and especially in regard rain0rate & rain0total and especially rain0total as this sensor provides cumulated data unlike most of the other sensors. First thing to note is -act is not valid for rain0total but is a valid selector for rain0rate

rain0total selectors are hoursum, daysum/sumday, monthsum, yearsum, allsum & ydaysum as well as cumulated values using sum, delta and prev

Quite a few trigger option combinations here depending on your own specific needs using just rain0total or also including rain0rate, like how much rain over what time frame at what rate defines "Rain" etc.

([rain0rate-act.1:--]>0.5) is the current rainrate exceeding 0.5mm/h and might indicate rain for a purpose depending on your area?
([rain0total-sum2:--]>1) raised when rainfall over past 2 minutes exceeds 1mm

deltax & deltaxxh is also an interesting one (per minute up to 60 or hourly up to 24) with rainfall as it can be + or - indicating rain is increasing or decreasing/easing etc

To Clear a flag then something like ([rain0total-sum60:--]=0) says flag will clear with no rain in the past 60 minutes or sum10 no rain in the last 10 minutes or sum3h no rain for the last 3 hours

Mattk wrote: Sun Sep 07, 2025 12:51 am.......
The basic variable structure ....

Thanks for sharing that. Makes the starting point easy to grasp.

Cool. This seems to work on the test.
I am going to change some of the selectors though. Average UV last hour or something seems more useful.

Thank you very much Mattk! for such a comprehensive explanation.

If I wanted to have two alarms. One for first risk level, and another for second level, I would want to have a data range for the variable I think???

Can you do it?

([uv0index-havg] 1.5<>2.5)

This seems good for one event. Set up for "After every full hour".
But when it actually ran on the hour, all I got was this:

#if# #then# Exposure High #else# Low Danger #fi#

I changed it to "every hour" instead of "every full hour" and it sends a proper message.

davidmc36 wrote: Sun Sep 07, 2025 4:45 pm This seems good for one event. Set up for "After every full hour".

Code: Select all

Sun Exposure @ [[hh]:[mm]##if# {*([sol0rad-havg] >=150.0) && ([uv0index-havg] >=1.5) && ([sol0total-dmax=h] >=3.0)*} #then# Exposure High #else# Low Danger #fi#

But when it actually ran on the hour, all I got was this:

#if# #then# Exposure High #else# Low Danger #fi#

Yes need to watch the structure implementation of "After every full hour" etc because after every full hour is essentially triggered on the zero seconds of the next hour hence there's no hourly data to evaluate.

"before every full hour" will work for the hour (havg) that just passed (as such) immediately preceding the full hour.

"After every full hour" would have worked on every hour as you intended by using -avg60 instead of -havg but you would have had a similar issue using -dmax come midnight as "after every full hour" in the case of midnight becomes the zero second/start of the next day hence again no data at that very specific point.

So another way to deal with it, if reqd., would be to put into the syntax, the operators that would deal with no data.......generate dashes if reqd.????

And it seems to work as designed. During day got several High Danger warnings. Now in evening it get Low Danger message.

davidmc36 wrote: Sun Sep 07, 2025 11:48 pm So another way to deal with it, if reqd., would be to put into the syntax, the operators that would deal with no data.......generate dashes if reqd.????

That would be for when there is no valid data (as such) but in the "after each full hour" case using -havg etc the data is not invalid it just hasn't even occurred yet

Very nice learning these many things. I hope it may help another also if they find the thread.