FR: Add altitude to composite

[sshaikh]

I noticed that altitude is missing from composite - could it be added if available in the tracked entities?

[pnbruckner]

I started looking at implementing this, and at face value, it's fairly easy. However, the question comes up, what to do if the composite entity has multiple input entities, and only some of those inputs have an altitude attribute?

The easiest way to implement it is to include the attribute in the composite entity if an input entity that has that attribute updates the composite, but not include it if an input entity that does not have it updates the composite. If the attribute is strictly "informational", then this is fine. The attribute will be there when available, but won't be when it's not. This can lead to the attribute "coming and going", which might not be optimal if the attribute is being used some other way, say, as an input to an automation.

If this "coming and going" isn't desirable, then how to "fill in the gaps"? I don't know that there's a clear way this should be handled in all cases.

Also, another question comes to mind: Should the altitude be included in the speed calculation? The easiest answer is no, and just treat speed as a "surface speed" or "ground speed", so to say.

So, a simple request, but not necessarily a simple way to implement it that would satisfy all use cases (and I'd really rather not add more config options & more complexity.)

[sshaikh]

My first thought is to make it "last value available", albeit with some kind of staleness logic.

If the general case is considered, then there's probably a case to nominate one of the sources to supply "non-location" values like that (and yes, I agree that sounds problematic when we deal with the semantics of what values are "non-location"). At the moment this is what I am doing to "backfill" composite supplied location data (I've specified to use the device tracker representing my mobile). This of course falls foul of your requirement to have it without config changes.

For the speed question, my gut suggests to keep it simple. What does the GPS speed do?

[pnbruckner]

FWIW, I would think altitude would definitely be considered "location" data. It's just a third axis.

The problem with using "last available" data is that it would then be stale/inconsistent with other data such as latitude & longitude (assuming, of course, a different input, that does not have altitude, more recently updated the composite entity.)

I'm not crazy about "staleness logic" in the first place, but it at least made more sense with the speed sensor. In this case, it only makes sense to me to either remove the altitude attribute when the input doesn't have it, or at least, once the composite has added an altitude attribute (when an input that updated it has it), to change it to None, aka null, when an input updates the composite but the input doesn't have that attribute.

Regarding your question about how the speed sensor works, basically it calculates the distance between the current location (as defined in latitude & longitude) and the previous location (from the previous update), and then divides by the amount of time between the updates (using the times from the last_seen attribute.) The angle is also calculated from these two location points.

[sshaikh]

Yes, if it's "essential" non-optional data then I guess the problem is a tricky one. It's actually because it's not that I'd consider it optional (despite technically being that third axis).

Regarding speed, I meant the speed that GPS devices give. I suspect they are done "on chip" too, and so are subject to implementation decisions as well.