A NEW Garmin Sport Field. OVEN TEMPERATURE!

Can you get their BLE profile from the manufacturer?  There can be things that use a specific encoding.

For example, here's the spec for the thingy52.   nordicsemiconductor.github.io/.../firmware_architecture.html

Notice that the data for some things are sent in fixed point, like heading - which is denoted by 16Q16, defining how the 32 bits are used.  You'll see other things in fixed point that are noted as 10Q6, etc.  In the case of temperature there, you'll see it's two bytes, where the first byte is the integer part, the second, the decimal part.

Hey - this is amazing. You call it a field? Is it a data field, meaning I need to start an activity to monitor the internal temp of my Brisket in my smoker from my Fenix 5X?

It might be cool to make this a Widget. I haven't written widgets (only data fields), but I seem to recall that Widgets time out after a few minutes and it reverts back to the watch face - if so that is unfortunate. Or maybe there is a setting that causes a widget to be persistent until the user takes action?

Another cool thing to code (if this were a widget), would be an alert that you stepped out of BLE range. Then it could revert back to the watchface, but run in the background searching for the temp probe connection. And when you step back into range, it alerts you that you are back, and brings the persistent widget display back into view.

Finally, it would be REALLY cool to have a USER SETTING for a target internal temp. Then you could create an estimated time remaining to get to that temp by extrapolating the temp rise rate. For a brisket, as you might know, it enters a "stall" so that estimated time may look like 4 hours, and then change to 10 hours as it stalls...  but that's ok... 

So really this is really some suggestions but also two questions:

1. Can a widget be set to display persistently (not time out)?

2. Can a widget continue to run in the background if it does revert back to the watchface?

On wearable, widgets always time out, but can be easy to access.  I have a BLE widget that controls my garage door for example.  But depending on what's used, it's really easy to turn a widget into a device app by just changing the type in the manifest file.  I've also done BLE in a background process, but there you have the "every 5 minutes at most") restriction.  But it can request to launch the main app when a condition is met (say a certain temperature)

It could be the sensor itself allows you to set a desired temp, and have it notify when the temp is reached.

BTW, you could also have a watch face with a background process that gets the temperature from the sensor and displays it.  A few months back I posted a simple WF that does that with the thingy52.  The thingy52 goes to sleep after 3 minutes so you have to keep it awake for the watchface by shaking/moving it.

Great idea on a WF... essentially you change your WF during the time you need, effectively, a PERSISTENT WIDGET. Too bad there isn't an option to make a widget persistent but this is a very workable workaround. Most BT temp sensors have target temps for alarming, but they send a BT update every "n" seconds regardless. Which is cool because then your WF can actually plot the history of the temp.  Did you post the source code!? If so THANK YOU. That would be really cool to see a working example.

https://forums.garmin.com/developer/connect-iq/f/discussion/8182/a-very-simple-wf-with-a-background-that-talks-ble-to-the-thingy52

I did a simple hack to it this morning to get the temperate from a Raspberry Pi (I use 1 1wire sensor on the pi).  The background in a WF is the only way to do BLE in those, so the data is at most every 5 minutes but it is possible to get the data in a WF..