Questions about Weather, Lists - Severe Weather

[beedix]

Background
Creating a piston to tap into NOAA (emergency alerts) via webCore. The plan is if the data is truly NOAA format, that I might be able to use it to trigger some automation at a remote location. The current piston state is simplified to ensure the data looks ok and given I ran into a few questions. I made a few assumptions and ran into some questions. I’d appreciate some re-education (very new to webCore).

Questions\Assumptions

1. Is anything detectable to signal the end of an array when walking through each element? Null, 0, or the like? I just assumed using any value less than an epoch value of about an hour ago would be invalid alert data and was probably the end of the array.
2. In my search, I saw some references to loop array problems (possibly due to bad weather underground data) that could really screw up webcore? Hoping the index limit of 20 and checking for semi-valid data may help.
3. I’m a little concerned that I’m accessing the two related weather fields in two separate API Calls (i.e. not atomic). If an API call is made at line 32 to retrieve a epoch date and on line 33 an API call retrieves the alert message and the data changed between those two lines, it seems like I could run into a couple minor scenarios. Correct? Would the only way to address it be to add logic after line 33 to re-read the epoch and verify nothing changed and if so, re-do it?
4. Is there a way to access the “alerts” in whole with all various member objects intact so that you could loop through the different fields without multiple API calls?
5. I suppose there is no way to trigger an event from webCore’s weather? Would be nice to process only upon change and do so closer to real time given this is moments away severe weather yet I don’t want to be firing off a 30 second timer.

FYI, not planning to use this in place of battery powered emergency radio or similar and wouldn’t recommend it as a replacement given the scanning latency and possibility of internet or power outage or similar.

[Robin]

I suppose there is no way to trigger an event from webCore’s weather?

Have you considered using the NOAA RSS feed via IFTTT, which could make a webhook to your piston passing the alert in $args

This example applet uses notifications instead:

NOAA Severe Weather Notification

[beedix]

Nice find. That may be a better route.

[beedix]

Not much useful info in the $args on the IFTTT route. I guess I was thinking we’d get the full message data. This is an output from a weather event this morning:

[eventName:noaa_alert, param1:ifttt, param2:noaa_alert, params:[:], remoteAddr:18.233.165.71]

But I might be able to use this as the trigger only and then process the same one in my original example. That seems to be working well so far although running on a 10 minute delay. I’d think the IFTTT trigger combined with a 60 second timer would probably ensure processing is fast enough while leveraging IFTTT when it’s reliable.

[Robin]

Are you putting {{EntryContent}} in the IFTTT webhook body?

[beedix]

Now I am

[beedix]

{{EntryContent}}

Sorry @Robin, I just got my first NOAA alert and unfortunately that didn’t make much of a change for me. Spring is fast approaching. Here is essentially what I have:

I started out with this piston based on the weather API (with some concerns about atomic execution and rate at which I’d need to scan). It works pretty well and provides the email format that I’d expect.

Then you mentioned the IFTTT route which seemed like a good idea so I added another piston:

And after some empty body’s in my email, you gave me a pointer to add some language to the body section, which I did.

So, this IFTTT route is much faster and consistant, but I still don’t have the email body I’m looking for and can’t seem to find some documentation that would help me. Here is what I get in this IFTTT based body:

[eventName:noaa_alert, param1:ifttt, param2:noaa_alert, params:[:], remoteAddr:3.81.105.35]

Any tips to get me on track?

Much Appreciated!

[Robin]

I’m afraid if the above does not work I’m not sure… I very rarely use IFTTT

[beedix]

Ok, no worries @Robin , I appreciate the help thus far. One more question and I’ll leave you alone

As an appreciative and hopefully resource courteous user of this fabulous free (at least for now) creation, I wanted to get your thoughts so I’m not pushing the limits of what I should be doing on webcore.

So the first piston works fine, I just wish I could run it almost in real time. 5 seconds or maybe even every 2 seconds. I realize that long term, I should tap directly into NOAA’s API and process locally with my resources. BUT, in the short term, what is generally acceptable? Couple of ideas floating in my head…

1. Are there established limits for timers (beyond the caution that is given when trying to select faster than 10 second timers)?
2. Since this requires no smart devices, is there any benefit from your perspective of simply creating a second instance with only this one piston - achieve better timer performance and\or any resource benefits on your end?
3. What about if I ran a local instance of webcore (ala hubitat) and then ran it practically real time. It’s still pinging away at your API account so not sure that’s a good idea, but at least the timer spins are using my resources.

Hoping to find as good of a solution as I can for this year and I should have plenty of time to solve this in other ways for next year.

Thanks for all the help
Ben

[Robin]

webCoRE does not apply any rate limits, as monitoring said limits uses resources in itself.

It’s all happening in the cloud on ST servers (Amazon AWS), 10-15 seconds shouldn’t do any harm.

In the unlikely event you get limited by ST, create a brand new ST account(s) and run webCoRE without a hub (a completely virtual environment). Pistons on those accounts can ping less often in a staggered manner, and then trigger your main piston to fire as and when required.

[WCmore]

I just wish I could run it … every 2 seconds.
what is generally acceptable?

For what it’s worth, if any free user was pounding my server 43 thousand times a day, I would ban or block them the moment I discovered it.
(if 1% of Americans did this, this would be nearly 150 billion hits a day!!)

A more courteous approach is hourly, or at most, every 10-15 minutes…
(Personally, my weather alerts fire every ten minutes if there is a change)

Do with that what you will, but I suspect pistons like this is why WUnderground is now charging for API usage.

[Robin]

Note the WU API calls do not pass through webCoRE servers, and if 0.0001% of Americans were running a piston like this I would be amazed… I’m sure WU can handle it just fine.

(Not 2 seconds though… ST would have something to say about that… 10-15 seconds should be fine as I noted above).

[beedix]

I’ll use 15 seconds for now.

I understand why even that might be considered a bit much, but you have to consider the use case. As part of automation, I need near real-time national weather alerts. 5 seconds DOES matter. You may only have 20 seconds to run a motor or similar and severe weather (and the alerts) can occur with very little notice.

Even NOAA and their multiple APIs which feed WU must be handling just crazy numbers of access calls. Long term, this should be easier to do off webcore in such a way that it presents itself as more event driven to a hub\rule language. I’m even hopeful NOAA has some notion of a callback as I’m sure they really dont want continuous URL hits back to back only looking for the one or two severe events every now and then, but I haven’t looked too deeply. I suspect there must be a better way to provide an abstration layer over WU similarly to reduce either or both WU API access and reliance on frequent timers.

Mostly on hubitat at the moment, so that’s where I’d start with NOAA processing, but I can devote a FreeNAS Jail too.

[WCmore]

5 seconds DOES matter

Wow, you must live near tornado alley…

Nearly every alert I have ever seen was given to me an hour or so in advance… Sometimes two hours…
(I think once I only got a 45 minute warning)

Maybe expanding your zone a couple of miles wider will give you more time to react.

[beedix]

Definitely tornado alley (northern part of texas), but personally the significant\damaging hail is happening 1-2 times a year now. Replacing roofs is not a cheap affair even with top notch insurance.

When cells pop up, seconds do matter. Expanding out by counties is actually not viable because the line where the bad stuff forms can pop up seconds away. Sometimes it tracks in a given direction with plenty of general directional warning, but in these cases the cell switches from tornado\hail producing to not along the way (they seem to have to rebuild\strengthen). So the only decent solution is news coverage (doppler) and NOAA does as good of a job as I can expect.

My goal is to reduce the insurance claims related to hail on a couple of properties through automation. Also, I have cars that I could protect automatically with inflation blower motors in a similar way. In our area, residential\business hail damage is usually 2% out of pocket…it hurts. So automation as wacky as my use case sounds, might be a good solution.

Believe whatever you will about global warming or not, but the last several years have been so extreamly unstable that…well, here I am bugging you guys about details on WC\WU Makes sense to me to have a better emergency weather device driver\handler.