Oh, sounds like you’re still talking about reading raw BLE from the hub. Yeah, i confirmed that the hub still sends data with the ubertooth. (Thanks for the tip about using nRF connect which gets the same info but I preferred to sniff using Linux so I didn’t have to wonder if it was my phone’s BT that was a problem).
The hub sends data over Bluetooth as expected, yes.
But i need to know if the latest Android or iOS Tempest Weather mobile app actually ingests that data to update it’s dashboard. Because it looks like it only uses cloud data, and only uses Bluetooth for setup.
Gotcha. When I put my phone (iOS) in airplane mode with Bluetooth only enabled, I can see the hub data when pressing the small icon on the upper right of the screen, and the hub’s Bluetooth blue led turns on. The main dashboard page complains it can’t reach the server, which is expected, since it normally contains forecast data which the hub can’t provide…
I agree it would be neater for the dashboard to have an ‘offline mode’ that displays only local data if network connectivity is not available.
I tried replicating that scenario. iOS app v5.01(609).
Bluetooth On, Open app and connect. Hub light turns blue. Turn on Airplane mode.
Data in dashboard freezes and no longer updates. If I try to click on the wind sensor, I get “no data at this zoom level”.
I am testing by paying attention to the wind sensor, since that is a 3 second update, and not subject to any nearcast data.
Are you saying that you have the same iOS app version, and are putting it into airplane mode (leaving BT on), and your wind sensor still updates every 3 seconds?? And the history graph is updating every minute?
A better test case, would be turning off the wifi that the hub is connected to, so it simulates the use case of the hub being offline, and the phone getting local readings.
I just tried again: when in airplane mode, data in dashboard still updates at regular interval, but I cannot see the graphs anymore, I get the same zoom level error you’re getting.
So yes, unless you have some local setup that will read hub data over UDP or the Bluetooth interface to store it in a local database, the only thing you get in offline mode is instant readings on the dashboard at a fairly low refresh rate. There is absolutely no wind where I am right now, so I can’t verify the 3 second rate…
Here is a bit of code that decodes a BLE notification received from a Tempest hub. I have not touched this for a long time, format may have changed, so please take it with a grain of salt:
// Parse a Weatherflow BLE packet, and send data to front-end if necessary
var parseWeatherFlowBLE = function(dv) {
var ptype = dv.getInt8(0);
switch (ptype) {
case 0x1a:
readings.sensor_voltage = dv.getInt16(17,true) / 1000;
break;
case 0x52:
readings.brightness = dv.getUint32(7, true);
readings.uv_index = dv.getUint16(11, true) / 100;
readings.solar_radiation = dv.getUint16(17, true);
break;
case 0x53:
readings.wind.speed_avg = Math.round(dv.getInt16(7, true) *1.94384)/100; // Convert to knots
readings.wind.dir_avg = dv.getInt16(9, true);
readings.wind.gust = Math.round(dv.getInt16(13,true) * 1.94384)/100;
readings.wind.other = dv.getInt16(15, true);
readings.wind.lull = Math.round(dv.getInt16(11,true) * 1.94384)/100;
readings.wind.avg_period = dv.getInt8(17);
break;
case 0x54:
readings.temperature = dv.getInt16(7,true) / 100;
readings.rel_humidity = dv.getInt16(9,true) / 100;
readings.pressure = dv.getUint32(14,true) / 100;
readings.dew_point = Math.round(wxutils.dew_point(readings.temperature , readings.rel_humidity )*100)/100;
// readings.heat_index = Math.round(wxutils.heat_index(readings.temperature , readings.rel_humidity )*100)/100;
break;
case 0x18:
readings.wind.speed = Math.round(dv.getInt16(7, true)*1.94384)/100; // Instant wind direction
readings.wind.dir = dv.getInt16(9, true);
// Trigger a limited packet
self.trigger('data', { wind: { speed: readings.wind.speed, dir: readings.wind.dir}, unit: { wind: { speed: 'knots', dir: 'degree'}}});
break;
default:
break;
}
if (ptype == 0x54)
self.trigger('data', readings);
}
Thank you so much! That’s really helpful. I’m going to try to convert this code to run on an ESP32 using ESPhome and output to MQTT. This way the station can be completely offline.
Did you have any luck decoding the lighting information or rain/hail?
The issue with UDP is that it’s using broadcast every few seconds which will flood the network. Since BLE is available i’d rather use that and keep it off wifi.
Maybe it’s my Blonde… but the UDP data is being sent out every 3 seconds no matter if you are listening to it or not… so ‘flooding’ the network is already happening… and the data is already there.
I have discovered a use case where wifi is not available, so being able to read the data via BLE is the only local option. I’m going to be looking into writing a WeeWX BLE station interface from the above info sometime over the summer.
Note that WF had promised docs for the Bluetooth API back at the beginning, but the placeholder page and references have since been removed from the API docs web page…
Yes, I think I remember at some point that David said they had changed their mind on the Bluetooth API as in their minds the UDP solution covered all use cases. If my memory serves correct, he was open to users suggesting alternative use cases where only BLE was possible, and that might lead them to change their approach. Needless to say, that hasn’t happened yet
What’s the use case ? A standalone weewx pi with no LAN connected to a physical display ? In that case how would the hub even work ? Doesn’t it need to phone home to WF ?
Actually, I do need a hobby! Just signed to accept an early retirement buy-out from my job of the last 38 years, and fear that I will die from boredom by the fall…
