A NEW Garmin Sport Field. OVEN TEMPERATURE!

NEW! Presenting A NEW Garmin Sport Field.  OVEN TEMPERATURE!  Now, while using a BLE compatible temperature probe, you don’t have to struggle to look at your iPhone.  I mean-- my golly-- the horror...  Now, the information comes directly to your wrist.  Coded it yesterday.  And it just may save your life.  Ok . probably not.  Temperature displays in C and F.  Small problem is that the Carbon doesn't utilize the BLE per BLE specification.  Rather, they have added some of their own stuff, at UUID 0xFFF0  So the app mostly works, except it displays the wrong temperature.  But other than that, it works great!  If anybody has experience with CARBON's BLE implementation, it would be appreciated.  Or, if somebody smart wants to develop this, it's an opportunity.  I mean-- I can't wait to upload (and thereby legitimize) all cooking to Strava!  

 

Top Replies

All Replies

  • 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..

  • Making the Watch face would be really awesome.  I wanted to display the data field as a proof of concept.  The sad truth is the CARBON oven temperature sensor does not use SIG GATT Characteristics.  It certainly includes the temperature measurement characteristic within it's own custom (0xfff0) service, but the implementation of this profile is completely bonkers.  

    In the SIG adaptation of characteristic 0x2A1C, the first bytes is a bunch 'o flags.  bit 0 is Temperature Units Flag, the second bit is a Time Stamp field present and the third bit is Temperature Type field present.  The rest are reserved.

    The second three bytes are a 24 bit FLOAT value per IEEE-11073 32-bit FLOAT.  Here's an actual data-dump from the CARBON sensor in a 315 degree oven.  And, as you can see, none of these values make sense

    TEMP MEASUREMENT

    00 03 25 00 00 

    00 1C 00 6E 20 

    00 1C 00 6E 20 

    22 00 00 00 1B

    22 00 00 00 1B

    22 00 00 00 1B

    If anybody has ideas for a consumer BLE oven/BBQ sensor that actually follows Bluetooth specifications, let me know.  I'll buy one and make an app, a widget, a watch face and a whole lot of chicken