Query: Speed consitency and accuracy

[sshaikh]

I've read a few previous issues so suspect I do understand some of the background of the situation here. But I feel it's worth revisiting for a fresh perspective.

The following composite tracker just wraps a single device tracker, one provided by your adjusted ha-gpslogger integration[1]. I believe that this should give a relatively robust speed that equals what is reported by the underlying device tracker. My GPS logger frequency is 4 minutes, which matches the updates in the chart.

However I am still seeing spikes:

The blue line is the speed from composite, the red is the speed from the GPS Logger device tracker (extracted via template).

I believe the spike occurs when I use a tunnel with no reception, but given that GPS logger reports locations on time I'm not quite sure why it's off. I have two observations that may be related:

1. Composite speed seems to lag behind GPS speed
2. The values themselves can be wildly different

Looking at the source, I see that "last seen" values are used for the time divisor in the speed calculation. Are "last seen" values determined by location time or receive/recorded time?

Some further analysis:

1. I do think that speed calculated from raw values is the way to go, even in a case like this (a single device tracker) since GPS reported speed can sometimes be unreliable while a location over time could be more accurate. This is why I'm not using the GPS speed directly itself.
2. Zooming into the spike at 1352, we have the following points (distance provided by the proximity integration wrapped around the same GPSL device):

HA Time	HA time elapsed(s)	GPS Time	GPS time elapsed(s)	abs distance via proximity (m)	distance travelled via proximity (m)	calc'd speed via proximity (m/s)	distance via lat/lon (m)	calc'd speed via lat/lon	composite speed(m/s)	GPS Speed (m/s)
13:47:50		2025-06-18T12:47:49.003Z		669					0.1	1.69
13:51:54	244	2025-06-18T12:51:52.996Z	243	500	169	0.69	173.3	0.7	0.7	1.25
13:51:55	1	2025-06-18T12:51:53.997Z	1	502	2	2	2.512	2.512		0.62
13:51:59	4	2025-06-18T12:51:57.394Z	3.3	489	13	3.25	13.025	3.94	4.3
		2025-06-18T12:56:02.000Z	245				247.1	1.01		1.05
13:56:08	249	2025-06-18T12:56:03.000Z	1	257	232	0.93	6.079	6.079	1	0.94
-	-	-	-	-	-	-	-	-	-	-

To be honest I'm still trying to digest the above, but I have the nagging feeling that we could do better than the calculated column and GPS speed. In fact I'll update this table with the raw logged GPS data to see if we can.

[1] https://github.com/pnbruckner/ha-gpslogger

[sshaikh]

Here are the related local logs (scrubbed). I guess that indicates it's the network location that caused the upset? I'll disable it and monitor. I guess there's also a semantic difference between the GPS reported speed and the average distance/time that is calculated.

<trkpt lat="" lon="">
	<ele>47.0</ele>
	<time>2025-06-18T12:51:52.996Z</time>
	<extensions>
		<gpxtpx:TrackPointExtension>
			<gpxtpx:bearing>20.6</gpxtpx:bearing>
			<gpxtpx:speed>1.25</gpxtpx:speed>
		</gpxtpx:TrackPointExtension>
	</extensions>
	<geoidheight>47.0</geoidheight>
	<src>gps</src>
	<sat>15</sat>
	<hdop>1.0</hdop>
	<vdop>2.2</vdop>
	<pdop>2.4</pdop>
</trkpt>
<trkpt lat="" lon="">
	<ele>48.0</ele>
	<time>2025-06-18T12:51:53.997Z</time>
	<extensions>
		<gpxtpx:TrackPointExtension>
			<gpxtpx:bearing>20.6</gpxtpx:bearing>
			<gpxtpx:speed>0.62</gpxtpx:speed>
		</gpxtpx:TrackPointExtension>
	</extensions>
	<src>gps</src>
</trkpt>
<trkpt lat="" lon="">
	<ele>23.0</ele>
	<time>2025-06-18T12:51:57.394Z</time>
	<extensions>
		<gpxtpx:TrackPointExtension></gpxtpx:TrackPointExtension>
	</extensions>
	<src>network</src>
</trkpt>
<trkpt lat="" lon="">
	<ele>104.0</ele>
	<time>2025-06-18T12:56:02.000Z</time>
	<extensions>
		<gpxtpx:TrackPointExtension>
			<gpxtpx:bearing>6.3</gpxtpx:bearing>
			<gpxtpx:speed>1.05</gpxtpx:speed>
		</gpxtpx:TrackPointExtension>
	</extensions>
	<src>gps</src>
</trkpt>
<trkpt lat="" lon="">
	<ele>106.0</ele>
	<time>2025-06-18T12:56:03.000Z</time>
	<extensions>
		<gpxtpx:TrackPointExtension>
			<gpxtpx:bearing>6.3</gpxtpx:bearing>
			<gpxtpx:speed>0.94</gpxtpx:speed>
		</gpxtpx:TrackPointExtension>
	</extensions>
	<src>gps</src>
</trkpt>

[pnbruckner]

1. Composite speed seems to lag behind GPS speed

Not surprising. I don't know how the GPS Logger app itself works, so I wouldn't be surprised if it is using more data points to calculate speed. The composite integration can only use the data provided, i.e., lat/lon & timestamp, and can only do the calculation once the data arrives (meaning when the sensor updates may be later than the actual timestamps.)

Looking at the source, I see that "last seen" values are used for the time divisor in the speed calculation. Are "last seen" values determined by location time or receive/recorded time?

You probably saw this, which defines where the composite gets the value for its last_seen attribute. And you probably saw this which describes how to add a last_seen attribute to the GPS Logger entity. Where the GPS Logger app gets the timestamp, I'm not sure.

As you've seen, the composite integration simply uses the data provided to calculate a speed, so it's only as accurate as the provided data, and can report speed updates "late" depending on how much of a delay there is between when the data is originally sampled and when it finally arrives. It makes no attempt to massage or otherwise filter the data. That is better done by other integrations, IMHO. Having said that, I'm open to ideas.

[sshaikh]

I believe that GPSL uses the speed from the GPS system itself (like altitude and heading). I suspect that is also sampling though, so your point about it using more points stands. To answer your question about time, that also seems to be taken from the GPS/network as appropriate, so having these two time frames is bound to cause issues. I'll see how things fare with network off.

Perhaps speed is just a difficult problem.

The above exercise was academic more than anything else and I think it's the best effort while keeping in scope - although maybe the underlying device tracker's speed could be used somehow if it's available?

That is better done by other integrations, IMHO

Do you have any tips? I've tried derivative helpers and statistics with mixed luck.

[pnbruckner]

Using an input's speed attribute, if it's available, has basically the same issues as using an input entity's altitude attribute (see #96.) I.e., if not all inputs have that attribute, what do you do when an input that doesn't have it updates the composite? Or what if multiple input entities do have it, but they're not providing equally accurate values?

The composite integration's purpose, first and foremost, is to use/merge location updates from multiple input entities to provide a device_tracker entity that updates more frequently / is less stale than each of the individual inputs alone. Calculating speed is basically an easy "freebie" to add. I'm willing to do some simple, clear "filtering" when it makes sense, but I'm not looking for this to be the "be-all end-all" integration for deriving speed from moving entities. (There are some other, closed incidents that went into this in quite some depth.) I think that's better left to other integrations, automations, etc.

[sshaikh]

Yeah makes sense. To be clear I first used composite to derive speed (and most of my instances still only use one source tracker). You're right in that the same issues happens everywhere but composite's seems to be the least problematic :). In hindsight perhaps another specific speed implementation would have been the way to go?

My approach now is to not be so sensitive to speed (wherever it comes from) and just use it in an advisory manner alongside other factors.

Happy for this issue to be closed unless further discussion is warranted.