what firmware version is your Tempe sensor? any newer than 3.10 ?

My Tempe is ~3 years old, and it's also running 3.10. About the battery status, it's interesting that TempeWidget (https://apps.garmin.com/apps/194a50be-400a-432a-9efa-402b4b7cae18) can show battery info (at least on my Tempe).

On your last line, I think it's not fair to compare speed/cadence sensors and Tempe. Tempe is broadcasting the temperature 24/7, and considering that my >3 years old Tempe still runs on its original battery, it's energy consumption has to be *really* small, so I'm not surprised if they've cut corners on the hardware.

Now that was a very helpful reply, thank you!

Because that TempeWidget app is open-source (thank you Shane74 we can look at the source code to see how they get the voltage and if that is "real" or not

(initially I wanted to suggest it's the watch battery and not the Tempe but the source says otherwise!)

https://raw.githubusercontent.com/shane1974/TempeWidget/master/source/TempeWidgetSensor.mc

It looks like they TRIED to get exact fractional voltage but the code is commented out which means it is disabled and I bet that is because the Tempe never reports it.

Instead it looks like they just grab the battery "status" (not voltage, just ok or not) by making a specially formed query

So even Garmin themselves are not doing this special query on the ANT+ sensor status page and it's not in the FIT file during activities, which means this special query has to be done to get Tempe battery status.

} else if (pg == 82)
        {
            batteryStatus = (payload[7] >> 4) & 0x07; // Battery status

 function requestBatteryStatusPage() 
    {
        // Get the battery page only once. For some reason the device will start sending
        // page 0 for a longer amount of time after the acknowledge is sent.
        if (batteryStatus != null) {
            //("BatteryStatus no null " + batteryStatus);
            return;
        }

        // Request battery status page
        var command = new Ant.Message();
        command.setPayload([
            0x46, // Data Page Number
            0xFF, // Reserved
            0xFF, // Reserved
            0xFF, // Descriptor Byte 1
            0xFF, // Descriptor Byte 2
            0x01, // Requested Transmission
            0x52, // Requested Page Number
            0x01  // Command Type
        ]);
        antChannel.sendAcknowledge(command);
        //System.println("Requesting battery status page");
    }
}

I had a hunch the battery status might be just ok / not ok, thanks for confirming that. Btw, the sensor page on Garmin Connect (both web and mobile) seems to get the battery "ok" status from somewhere.

Yeah it is a mystery to me where Connect gets it from.

I do NOT see it in the FIT file, but maybe I need to check my FIT file from January

Because the status is mysteriously from the last indoor bike ride I had.

Now in that case the Tempe was connected over an hour.

Maybe time is the factor, maybe the Tempe only broadcasts battery status once an hour and if the device misses is, it's not stored anywhere.

According to the Tempe Widget's docs, "[it] can take up to 5 minutes for the Tempe to publish the battery status". So it shouldn't be hours...

I suspect the status has to be captured as it happens and if missed, it is lost and not saved.

But I've yet to see it on the Tempe sensor status page on my Fenix, always blank even when the firmware version and serial number get filled in eventually.

I checked the FIT file on that last indoor bike ride and there is nothing in there that seems to indicate the Tempe battery status, all the fields are voids so I have no idea where Connect is getting it from unless the Fenix bridged the ANT+ to Connect somehow during the ride (my android does not have ANT+ support so no way it read the Tempe directly)

I checked my last hiking activity with FitFileViewer (the last Tempe battery status in Garmin Connect was from that date). And in the Device Info message there's a row with Tempe's info, including battery status.

(The same record shows that I was wrong, based on the operating time I have changed the battery 1.5 years ago.)

Check this out! 

Today for the first time EVER, I mean in years and years of owning a Fenix5 and now a Fenix6 with the same sensor list and behavior, I have never ever seen not only a "Battery: OK" but never ever the Model and Manufacturer filled in for the Tempe

and that's with lots and lots of trying

The thing is I've always tried to check it before my run.

Today for the first time I tried to check it after my run and it was at first still completely empty.

But then something different happened, when I get back from my run it always tries for the first time to connect to my android tablet and start the upload.

The upload often fails with that red circle of death because the Fenix metal case has such poor connection quality.

For some reason after the fail I immediately went and checked the Tempe sensor, it reminded me to check it somehow.

And I got the first screen, still completely empty, no serial number nothing, but the mysterious "Battery: OK"

Then I fiddled some more, going back and forth on hitting About and going back to check the list.

And the rest was magically populated.

EXCEPT not the serial number which only rarely shows up otherwise.

It's like the Tempe either only broadcasts some of the info.

Or far more likely what I suspect, the Fenix is "stepping" on the ANT+ broadcast and only sometimes receives the data, sometimes it completely misses it.

The reason why I think the latter is because I discovered something, if I have an app or widget open that uses the Tempe like that mTempe widget I like, the sensor list will never ever populate, never ever, no matter how long you wait or go back and forth to check.

It's like other ANT+ app/widget polling will "steal" the data from the Fenix sensor polling in that list.

And that's not at all how ANT+ is supposed to behave, unlike bluetooth ANT+ is supposed to work simulateously across as many devices and currently running apps as you want, it's a "wide open broadcast".

This is clearly a bug.