Weatherflow’s support for local readings is one of the reasons why I got a Tempest in the first place - the idea that you need a fully working Internet connection to know the temperature in your own backyard just doesn’t make sense to me. Enhancing your own readings with input from Weatherflow’s backend, sure, but it should not be a hard requirement. So kudos for supporting this!
While UDP broadcast is nice, it does not work well on modern home networks where more and more people rightfully tend to put their “IoT” devices on a segregated Wifi network that cannot connect to the main home wifi. That leaves BLE as an alternative which works pretty well in a lot of situations.
I took a quick look a Weatherflow BLE packets, and they are straightforward to parse, but I was hoping Weatherflow would publish an official spec for it?
Short of doing that, can Weatherflow confirm whether the Hub is fine with long lasting BLE connections from, for instance, and Android tablet or a Raspberry Pi that will ingest/display readings that way?
Not quite sure that’s accurate - you can put the Hub on any wifi setup you want, as long as you let it reach out to Internet to the WF servers so you can get the sensor tunings from their Continuous Learning magic.
The only thing you need to do is join the phone/tablet to that same wifi when you set up the station (as a one-time thing). You’d of course need to hook up any computer that ‘reads’ the UDP broadcasts locally to the same network.
Just put your pi on the same wifi network as the hub.
Thanks @vinceskahan. The point is that, like many people do, my home network is split between one SSID/LAN for my own devices, and my “Internet of Things” wifi/LAN where I put all the IoT devices that I have no control over (Philips Hue, Weatherflow, Chromecast, smart TV, cameras, you name it). Devices on my home wifi can connect to devices on that “IoS” network, but devices on the IoS network can only connect to the Internet, think of it as a one-way configuration. This lowers the risk with security issues that are common on IoT devices… which is also why I won’t connect a Pi to that network
I’m done with BLE anyway (just missing lightning, but I would probably need a storm to do that), so I’ll finish the job using that!
Ummm - yeah. Been there done that for a living for too many decades.
If you wanted to run software that listens for the udp/50222 broadcasts, you’d need a dedicated computer on the same network as your IoT located Hub.
I’d argue that a single-use raspi running weewx and @vreihen’s driver could trivially be made secure enough to be safely on that network. Accept in ssh from your home lan only, using keys only (for management) and udp/50222 from the ip address of the Hub (to read the data). Hard-allocate the ip address of the hub and pi in your DHCP setup, or statically configure their addresses. If you want to see the weewx web pages, let in tcp/80 or tcp/443 from your home LAN subnets. It isn’t rocket science.
But everybody’s measure of good-enough differs. My friends in InfoSec trust nothing and nobody to the point where I don’t know why they don’t think the batteries in their watches are hacked and causing the watch to tell the wrong time as a denial of service.
Thanks Gary, I think I’m done, it was simpler than I thought. The only thing I have no baseline for is lightning and rain. I’ve gotta wait for a storm, or generate some false positives So if you have pointers to those two elements, I’m interested…
Don’t worry about it, BLE contains pretty much the same info as the UDP API, at the same frequency, nothing much to it. Works great for my use case, but UDP is just as easy if you don’t want to get into Bluetooth…
I suppose it all depends on the backend you are using. Using NodeJS, ‘noble’ is a BLE library that works well, I’m not super familiar with other stacks. You can experiment on Android using “nRF Connect” which is a great BLE utility for generic BLE debugging.
Can anyone here confirm if they were able to get local BTLE readings from Tempest? (Hub not connected to internet, but Mobile connected to internet and Hub showing blue LED).
Here are my findings:
I was able to confirm using an Ubertooth, that the hub does indeed send BTLE packets. One 11 byte PDU every 3 seconds for (likely for wind). Every minute two other PDUs, the first one is 20 bytes and has my Station Serial number in ascii, and the second one is 19 bytes.
I haven’t been able to decode anything except the serial numbers of my Hub and Tempest Station. But due to the specific timing of BTLE traffic compared to UDP Broadcasts and MQTT to your cloud server (when allowed), this is certainly the realtime weather data that I expect.
I observe the same BTLE traffic using the Tempest Weather mobile app on both my Android and an iPhone. There appears to be no change in the BTLE traffic if the Hub is connected to the Internet or not.
This confirms that the issue is likely in Tempest Weather mobile apps (both Android and iOS). It seems that although the data is available over BTLE, the app discards this data in the dashboard in favor of only cloud data. I guess BTLE is only being used by the app to communicate the initial setup, login and to transfer the WiFi credentials.
Not sure if that 2018 update to supposedly fix this, was ever merged.
As the 1st post in this thread indicates: yes, you can get local readings from Tempest over BTLE, they are formatted the same as with UDP packets. No need for an Ubertooth or anything fancy, NRF Toolbox will let you view the packets on a Tempest hub
Also, as far as I can tell, the Tempest app uses BTLE if it can for local readings (i.e. when it detects the hub nearby) and avoids cloud communication, which is very neat.
I understand that is they way it is supposed to work. The reason why I am using an Ubertooth, is for troubleshooting why this is NOT working for me.
The app (tried iOS and Android) is NOT using local readings when the hub is not connected to the internet. It simply stays stuck at the last known reading from when it was online.
Also, is there any Tempest Bluetooth documentation that says that the data is formatted the same as the UDP broadcast packets? I know the UDP format is the same as what is sent to their cloud server mqtt.weatherflow.com over tcp/1883 mqtt. But I’d imagine BLE PDU packets need to be much smaller and not have all the ascii descriptors.
