Topic: Local API broadcast behavior in case of power outage

[hmderek]

I'm considering moving away from my Meteostick + Pi setup, because it's not terribly stable and reception is poor.

The big advantage I have now, is that the Meteostick is connected to a Raspberry PI with battery backup. I've coded the Pi to cache any updates it cannot post to the server (in case of internet or power failure).

Pretty much like the WeatherLink does in such cases. It will broadcast the data to the Davis servers after power/internet has been restored.

My question: Will the Weatherlink behave in the same way with the local broadcast requests? That is, if you request the WeatherLink to broadcast to a local IP adress for 24 hours, and the power is out for 1 hour, will the WeatherLink also attempt to rebroadcast the data during that time to the local IP, or only the Davis servers?

[mcrossley]

It will only send old buffered data to the weatherlink cloud. The local broadcast is "live" data.

[hmderek]

It will only send old buffered data to the weatherlink cloud. The local broadcast is "live" data.

Thanks for the response.

Hmm, so how to keep a local network available during a power outage.

[johnd]

I am tempted to wonder if what we're waiting for is for someone to write a basic utility that polls a WLL and maintains a traditional log of archive records accessible by a DMPAFT call. Minimal GUI, if at all, just something providing basic logging functionality. This could run on a dedicated Pi Zero for instance (or even possibly one of the new Pi Pico devices, but would then need to be written in C or MicroPython) and would be much easier to provide battery backup for.

But yes of course it would also need WLL and router (as a minimum) to be on a UPS.

[mcrossley]

I am tempted to wonder if what we're waiting for is for someone to write a basic utility that polls a WLL and maintains a traditional log of archive records accessible by a DMPAFT call. Minimal GUI, if at all, just something providing basic logging functionality. This could run on a dedicated Pi Zero for instance (or even possibly one of the new Pi Pico devices, but would then need to be written in C or MicroPython) and would be much easier to provide battery backup for.

But yes of course it would also need WLL and router (as a minimum) to be on a UPS.

But if you are keeping the WLL on UPS, along with your local server and router, why would you need a buffer device?

The old DMPAFT functionality is provided by wl.com - alright you have to pay for it, but it does provide other benefits too.

[johnd]

But if you are keeping the WLL on UPS, along with your local server and router, why would you need a buffer device?

True, but a logging utility might be useful in other ways too.

The old DMPAFT functionality is provided by wl.com - alright you have to pay for it, but it does provide other benefits too.

Isn't that only true for API v1 devices, which wouldn't include WLL for instance? I've never tried it, just assumed that it wouldn't work for WLL but maybe I'm wrong.

[mcrossley]

As you know the WLL uses the v2 API, there is not direct DMPAFT equivalent, but what I meant was all your historic data is available to download - including the data the WLL buffered during any power outage. So you can "catch-up" on any missed data and do with it what you will.

[johnd]

As you know the WLL uses the v2 API, there is not direct DMPAFT equivalent, but what I meant was all your historic data is available to download - including the data the WLL buffered during any power outage. So you can "catch-up" on any missed data and do with it what you will.

Ah, OK. I was reading the previous post too literally!

[Sleuth255]

I actually do keep my WLL on a small UPS.  The local API will keep working pretty much indefinitely (I tested this by denying WLL internet access over a 3 week period) as long as it has external power supplied.  Here is the UPS that I'm using:

https://www.amazon.com/gp/product/B07W8MCBMS/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1