Hi all. I am developing an IOT solution that uses Tempest as part of the system. These are deployed at remote airfields, some with unmetered Internet connectivity and some are on LTE modems with data caps. I am using the UDP API for my own purposes and am happy to contribute my site data to the Weatherflow network. However, LTE site connectivity is a premium and I can’t let the HUB send data at the rate and frequency it normally uses.
The purpose of my post is to inquire about any existing capabilities with the hub to limit the number of pushes it sends to the cloud.
In my study of the API, I have not seen any references to such a capability so one idea I have is to blackhole the traffic coming from the hub and going to the Internet except for when I want it to send data to the cloud. I think I read elsewhere that the design of the hub is such that it will store readings when Internet connectivity is down and send all the cached data when connectivity is restored. If that’s the case, then my proposal will not work as the data usage will be unchanged.
Ideally there would be an API call that would allow me to configure the hub to send updates on a periodic basis (e.g. once every 15 minutes) and also asynchronously if a measured value changes suddenly (e.g. wind speed and/or direction). In the aviation world, this would mimic the AWOS update cycles, which are every hour unless a special (SPECI) update is required to communicate a dramatic change in the weather.
perhaps just don’t connect the hub to the internet, instead listen to the udp messages and send the relevant (compressed?) data in your own pace, to your own server. You just can’t send data to the weatherflow servers unless you use the hub to do so. Another idea… power down the hub for 55 minutes, somehow powercycle the tempest automatically (that also clears it’s buffer, as otherwise it would send all the data to the hub). Then turn on the tempest and the hub for 5 minutes (or less) and repeat.
yet another idea… ask weatherflow to change the settings on your tempest so it sends only data once every 15 minutes. I’m not sure if they can, but perhaps they can only set a certain powersave mode. Measuring for example only once a minute should be possible. Contact support to get that done.
You’re asking that they provide a switch to let you make the hub act ‘not’ as the hub is designed to do.
You could easily do this if you had a small linux box such as a raspberry pi in the data flow between the Hub and Internet. Have a cron entry that turns on/off ip forwarding or alternately add/delete an iptables rule to permit/block the hub, or something like that.
But if you have a LTE Hub, then I can’t suggest any way of getting in the middle of the data flow.
I second sending an email to support to see what your options are.
The cellular hub that was part of the Kickstarter was going to send data at a lower rate for the same reason you’re concerned about. “Converting” a standard hub data rate may not be possible, but it seems like something worth checking into anyway.
Short of that cutting power to the hub expect for when you wish to have data reported seems like the next best option.
Thanks for the suggestions. Cutting the power is not an option for me because I am processing the UDP messages for my own purposes. As suggested in a prior reply, I am in fact using an rpi as the iot host where I am processing the UDP messages and this is where I would potentially black hole the data being sent to the WF network.
In any case, I did some packet capture analysis and it looks like the steady-state (i.e no lightning or rain events) data rate is about 5 bytes/second or ~13Mb/month. I’ll probably just let it go for now as this is only about 3% of my monthly data cap.
If WF can help reduce it then all good.
If not then I would use the pi to collect and analyse your data without anything going to the internet. Then send your data as you wish from your pi.
Looking at what you are presenting I would also consider printing the ‘weather values’ onto your image.
cheers Ian
I don’t know, but is you data usage only measuring the size of the actual content of the message (292 bytes per minute, according to your measurements) or do you need to add all the extra header stuff that is needed to send some data. Perhaps even worse and every message you send might be stuffed into a 512 byte package (the same for a 1 byte message as for a 300 byte message) and you might get charged for those 512 bytes. I just don’t know, but it is something to watch out for. That at least 21 messages per minute.
If that is the case your monthly data cap might be consumed way more quickly and it would definitely help if you would ask weatherflow to reduce your sampling rate to say 15 seconds as that would drop the amount of messages to at least 5. Or go further and make it sample data only once every minute.
That’s something weatherflow can do. I know, because my unit is set to sample once every 15 seconds (even when it has enough battery power to sample every 3 seconds). It’s an experiment in order to save power.
