Is the Particle device capable of receiving and reacting to " Wireless Emergency Alerts""
These are the Emergency alerts that make everybody’s cellphone go off in case of a tornado, amber alert, etc.
they are supposed to be up to 90 characters, and are sent automatically by the wireless carrier to everybody without requiring an explicit subscription.
Since Particle.io is basically the wireless carrier, how do we get a particle device to watch for this kind of message.
I am building what is basically a scrolling LED display, and would like the display to show emergency warning since we live in tornado country.
More info on “WEA” here: https://www.ready.gov/alerts
@Awake Yes you can do this based on my research but it may cost you some money the way I know how to do it. Weatherunderground charges to receive these alerts but most of their other weather data is free to access up to a certain amount of times per day.
You basically just set up a webhook to listen for Weather Alert Messages for your area:
I considered going the Internet way, but there are two shortcomings that I would like to avoid:
a) Reliability. The internet to home is very fragile. It seems to be always breaking down even during the best of times. Cellular transmissions are more reliable, or at least can be redundant.
b) Requires regular polling. I want to have to avoid the bandwidth costs over cellular of having to contact an emergency notification provider every two minutes to ask “Any notices?”.
The major cellular companies provide basically a ‘Push’ service for an emergency message. You don’t have to subscribe, it is actually an ‘opt out’ system, and they just have to send one text out that everybody gets. That is the kind of notification that I am trying to figure out how to get on an Electron.
Hmm, I think that new standard refers to them as “WEA” (wireless emergency alerts) messages. I don’t see mention of that in the ublox AT command manual, so I’m guessing maybe it’s called something else, or they’re treated as text messages?
The alerts are not technically SMS text messages. Although they go over carrier networks, they use a separate technology that "will not get stuck" if wireless traffic is congested in the region — often a problem in an emergency situation.
BDub, thanks for the link, WEA is exactly the type of notification that I would like my device to monitor for using an Electron as its core.
An alternative would be to find some kind of service that would ‘push’ the alert to another service like twilio, which could then send a formatted SMS message to my device. But there doesn’t seem to be a working 'push via Internet" service for emergencies. I guess that it has to do with granularity since most emergency messages (thank God!) are very local in nature. WEA messages include ‘regions’ which the carriers then translate to cell-tower coverage areas. So basically WEA pushes a couple of dozen messages out (instead of millions) to carriers, which then forward them as appropriate.
One interesting footnote is that “the handset must support WEA” in addition to the carrier participating. I wonder if they are just saying that you need a smartphone to get WEA messages, or if there is a hardware issue (which I doubt).
Oh EAS, what a pain it was - all the priorities and overrides and setup and… well that was for IPTV actually and I don’t do that any more… but if I may offer this - weather radios (in the USA) receive broadcast alerts MUCH more frequently than our cell phones, at least in the Ft Worth region. They are coded to specific counties or zip codes if I remember using SAME (Specific Area Message Encoding). whats even neater is you CAN get a module build specifically to decode them:
Or so they state on the sparkfun page… however I know they transmit the type of alert in the signal, because its quite clear on the radio display I have whether its a tornado watch or warning (get that distinction right, its important!) or other weather events…
Might look that way - nothing to subscribe to, no net needed, and almost all the US is covered…
RBRB:
You might be on to something. I was looking for a practical use for the Electron that I bought and activated, and thought that EAS would be a good choice, specially for redundancy if the Internet goes out. But I found a different project for the Electron, so I can move on from implementing EAS on it.
When it comes to emergencies, you can’t have too many redundancies. The recent wildfires that killed a dozen people show that some of them might not have gotten emergency EAS messages because the scarce cell-towers failed, and now there is serious debate on its dependability -vs- FM radio emergency transm.ssions, including the mandatory ability to receive FM radio on a cellphone.
So what I will probably do is get an Si4707 emergency broadcast receiver chip, and add it as a module to the display that I’m building. They are about $15 on eBay, and seem to be rare in-the-wild. The SparkFun card is retired, probably due to lack of demand. Since the chips have their own RF tuner, the build is fairly straightforward. I could just get an Emergency radio receiver, but what’s the fun in that?
I am building a geiger counter to detect nearby nuclear explosions… maybe that chip would be a worthy addition to the worlds most useless/redundant device?
Strange that you mention Fort Worth; that’s where I live also.
Hey all! u-Blox responded and mentioned this WEA is supported on the modules as SMS Cell Broadcast (CBS). So even though it’s not technically SMS, it appears to use the SMS interface to receive these messages. A quick search of the AT Command Manual for “cell broadcast” suggests that these CB messages are not indicated as received by default. This is a feature that can be enabled with the AT+CNMI command. These messages would be indicated when received with the +CBM URC. We would probably have to enable an asynchronous callback for this URC specifically to avoid requiring users to poll for these messages, and instead allow for a user callback to be registered much like we currently do for non-WEA/CBS SMS messages (see my SMS examples above).
After exploring this feature if anyone would like to contribute an issue for feature proposal or pull request implementing this feature, that would be welcome.
@BDub That’s good news. The bad news is that I have no idea how to properly code so this actually works.
What would be the easiest way to implement this?
Could there be a function created so that we could just check for a WEA flag in our main loop and if it’s positive have it return the text data that the WEA Alert contains?
Hopefully there will be others who have more skills than I who can help make this happen It can be a very useful feature.
If you take a look at how the SMS received callback is registered, example here.
I think that’s a good way to keep it really flexible for users:
void cbs_received(void* data, int index)
{
newCBS++;
}
// Then in your
void loop() {
if (newCBS > 0) {
// do something to read and process new CBS messages
}
}
This would be accomplished by doing something similar to how the SMS callback handler was added see last 3 commits here. It would also benefit from a proper Cellular. Wiring API so you don’t have to access the cellular_hal directly.
Also, the CBS feature needs to be enabled with the AT+CNMI command, and testing needs to be done. The testing is the hard part I think because these CBS messages are far and few between. Anyone know of a regular source of these?
I just mentioned it to Awake as an alternative that was perhaps lower cost (no ongoing costs). While it seems like an interesting project, I’ve got way too many others on my plate to help out on this one. Thanks though and good luck!
RWB,
Thank you for the interest that you took in this question.
For now, I think that I will go with the radio choice, although I would like to follow up on the Cellular notification system.
As far as developing for it, well, I’m not that well versed in programming, everything that I write is a first grade level. It normally ends up working, but it is a real mess from a professional programmers perspective.
It can be a very useful feature.