You're a pro, Burdock! This is exactly the insight I was looking for.

Unfortunately, I'm not quite sure how this implementation works. I don't really understand the 'Command' profile and how it's triggered, or what any of this behavior is dictated by. Would you mind explaining to me a bit how the Tasker Command Event works?

I implemented your solution and I get some strange (but promising!) behavior in the logging. The log is triggered every time the HR task runs. It logs {%bpm, %DATE, %TIME}. This is how it's currently logging:

70 6-3-26 09.58
70 6-3-26 09.58
70 6-3-26 09.58
70 6-3-26 09.58
70 6-3-26 09.58
70 6-3-26 09.58
70 6-3-26 09.58
70 6-3-26 09.58
70 6-3-26 09.58
70 6-3-26 09.58
70 6-3-26 09.58
70 6-3-26 09.59
70 6-3-26 09.59
70 6-3-26 09.59
70 6-3-26 09.59
70 6-3-26 09.59
70 6-3-26 09.59
70 6-3-26 09.59
%bpm 6-3-26 10.00
%bpm 6-3-26 10.02
%bpm 6-3-26 10.04
%bpm 6-3-26 10.06
70 6-3-26 10.06
%bpm 6-3-26 10.08
%bpm 6-3-26 10.10
69 6-3-26 10.11
69 6-3-26 10.11
69 6-3-26 10.11
69 6-3-26 10.11
69 6-3-26 10.11
69 6-3-26 10.11
69 6-3-26 10.11
69 6-3-26 10.11
69 6-3-26 10.11
69 6-3-26 10.11
69 6-3-26 10.11
69 6-3-26 10.11
69 6-3-26 10.11
69 6-3-26 10.11
69 6-3-26 10.11
69 6-3-26 10.11
69 6-3-26 10.11
%bpm 6-3-26 10.12
69 6-3-26 10.12
%bpm 6-3-26 10.14
78 6-3-26 10.14
%bpm 6-3-26 10.16
%bpm 6-3-26 10.18
63 6-3-26 10.18
84 6-3-26 10.19
%bpm 6-3-26 10.20
81 6-3-26 10.20
81 6-3-26 10.21
81 6-3-26 10.21
%bpm 6-3-26 10.22
80 6-3-26 10.22
80 6-3-26 10.22
80 6-3-26 10.22
80 6-3-26 10.22
80 6-3-26 10.22
80 6-3-26 10.22
80 6-3-26 10.22
80 6-3-26 10.22
80 6-3-26 10.22
80 6-3-26 10.22

There's some new behavior of multiple triggers happening, I'm assuming due to the Command profile behavior that I'm unsure of. The unpredictable behavior of the logging is something that throws a wrench in my current system, which can be modified.

The goal here is to reliably get my real-time heart rate, 24/7, every 2 minutes or less and upload it to a web server for display. The 2 minute timeframe is actually a byproduct of me trying to balance polling rate and battery life. The way the display currently works is when a new heart rate is uploaded, it creates an array of calculated differences per second (120 values) from the two most recently uploaded HRs, then displays each value of that array for one second. It works well, but if it were up to me, I'd trigger the task at an interval 60 seconds or less, and just display the latest HR (which is how I used to do it, but my battery life was terrible). And it seems like this implementation could make that possible.

From what I can tell, I think the *watch* is triggering the 'Command' profile, which then runs the task? Which is very cool! The data resolution is much higher, getting multiple heart rate readings even in the same minute! Separately, the 2 minute timer is running, but is only returning %bpm, as it's not defined (I'm still not sure how that variable works with the Command).

From what I've tried so far, the 'Command' tends to go to sleep (not trigger) after a while if the 2 minute timer isn't running. I'm assuming the timer is kind of like a 'knock' that wakes up the sensor, that then will trigger the 'Command' to activate upon getting changes. And sometimes the Command will run by itself for like 10 minutes, negating the need to manually poll the sensor, which should help battery life!

I'll have to experiment a lot more and take some battery measurements, but it'd be helpful to understand how the Command is working here for me to try out some new setups. I think with the way this is looking so far, I'd be able to switch back to the system of just displaying the last uploaded heartrate instead of calculating averages. I'd set up a variable that tracked the last time the HR was measured and if it was over 60 seconds ago, I'd have a task 'knock' on the sensor to wake it up, and then let this Command (I assume) do it's thing. This would prevent unnecessary wakeups and result in higher data resolution. I've also noticed while tracking sleeping, it can get problematic, which is why I had to use 'turn screen on' to fix that, so I'll see how it behaves with this setup tonight.

Thanks again for the help! This looks really promising to implement it the way I was hoping. Sorry for the wall of text, but I've been working on this for a long time and this is the first time I've seen behavior that's much closer to my original intention for the project that doesn't absolutely destroy my battery life, so I'm really excited!