Unexpected Relationship between Range (rated) and Range (est.) in Internal Drives Dashboard, Drive panel about teslamate HOT 26 CLOSED

@cwanja I understand you're trying to represent a LOT of data on this graph, and space is a premium. Dunno what the right solution is for everyone.

I do expect lines of the same unit of measure should sync, whether the labels are displayed or not. I'm ok with not seeing a 'miles' label. The popup for values makes it clear enough for me.

from teslamate.

I believe what is happening is that these values are not plotted against the Y axis with the values we had displayed. And thus they do not "fluctuate" how you would expect them too on a normal graph (e.g. proper spacing). Notice that on the left, there is no value for the range values in the axis - it is speed and power. I think Grafana is just doing its best to plot the range values. @DrMichael you see anything different to this?

I can make them show, but look how confusing the right hand side is:

If I have my understanding correctly then, I am seeing the same behavior @tjhart - see screenshot and where my tooltip is.

But I believe if we add them, it is going to be too confusing.

from teslamate.

@JakobLichterfeld and @cwanja I don't have experience with Grafana, so I'm not sure if this is the correct solution, but it resolves my issue.

I've fiddled with the pane definition for 'Internal Drive -> Drives'. Override 12 is defined as:

Fields with name matching regex: range_estimated_.*
Standard options > Display name: Range (est.)

Which is different than Override 9:

Fields with name matching regex: range_rated_.*
Standard options > Display name: Range (rated)
Standard options > Min: 0

Removing Standard options > Min: 0 from both, or setting it to the same on both, gives me what I expect to see on the graph.

from teslamate.

@tjhart definitely take a look at it later, my gut tells me it was oversight. I know these graphs have been a bit pain even when Adrian was around. Would want @DrMichael to validate further as well.

from teslamate.

If no or no negative feedback is given in 48 hours, I will propose a PR removing the property on override 9.
https://github.com/teslamate-org/teslamate/blob/425ffeea1eb9f85a56e9bc9c8381cea52619614a/grafana/dashboards/internal/drive-details.json#L297C1-L300C16

from teslamate.

@jheredianet would appreciate any insights you have as well.

Hi @cwanja @tjhart, before any change, please could you test with this PR? (already merged a few days ago) #3836

I've already changed the axis, because it's true that the info is a little confusing since it shows many values with different metrics of different units, so It's hard for Grafana to mix them all. So, what I did was to put the "power" to the right and the rest on the left (as they always were), also updated the color patterns, and the most important change is the "center cero" axis, with it the Y axis could visualize better the regen on a drive, on the other hand the ranges (estimate, rated or ideal depending on the user preference) show as expected.

New view with all metrics:

Only Speed, Range rated and estimated selected:

Could you check if it is ok or is it necessary to Remove Standard options > Min 0?

from teslamate.

@cwanja Yeah, that's odd. I was trying to inline the last screen shot from @jheredianet 's post. Looked fine in Preview mode. Apologies for that. I've edited the comment.

I only added the axis locally so I could see the entire range being represented, as a means of inspection and testing. I was not trying to create a PR or suggest that those axis should be a part of the displayed graph.

from teslamate.

@cwanja

Here's a screen shot with the range axis on the right. Again, this was just for me to visually see the scale. Zero seems to be vertically in the middle, which seems odd for these data sets.
Also, again, I expected one range for the distance data set, not two.

from teslamate.

Here's a screen shot with the range axis on the right. Again, this was just for me to visually see the scale. Zero seems to be vertically in the middle, which seems odd for these data sets. Also, again, I expected one range for the distance data set, not two.

Here, we cannot think only in some metrics, we have to consider that in this graph there are other metrics together. So, the challenge is if we adapt the axis for a specific metric, it would not be well represented for other one. Having zero in the middle is special for the Power which is the one that has positive and negative values. Maybe the Solomonic solution could be separating the familiar metrics in another graph, to avoid confusion.
That's why I think the elevation is represented in another graph instead to this one.

from teslamate.

@DrMichael @Dulanic - can you review this thread and the proposed change below. To resolve the irregular lines spacing in the Drive Details panel, @tjhart proposed one of the following fixes (note the orange and red lines):

1. Add Standard options > Min 0 to Override 12

2. Remove Standard options > Min 0 from Override 9

In my testing, option two looks like the better path.

1. Do you agree?

Hmmm. just my gut feeling: I would prefer option one. Option 2 suggests. that the est range is less than half of the rated range...

from teslamate.

Hi tjhart,
Not really sure if I understand your issue correctly.

• The graph do show that the values sometimes are really close or even the same
• but when there is a big change in Range (est) (due to hard acceleration or deceleration) the cursor does not snag to the right value when you are zoomed out?

from teslamate.

@JakobLichterfeld Note the 3 screen shots (all of the exact same graph), the units I calculated, and the displayed difference between the values:

1. As a baseline, The first screen shot shows the initial rated (244 mi) and estimated range (228 mi). The values are 16 units apart, and you can visually see some distance between them on the y axis, suggesting a delta in distance
2. The second screen shot shows rated (235 mi) and estimated range (234 mi). The values are 1 unit apart on the y axis, and (at least to me) a surprising gap between the two, but compare that to the 3rd screenshot:
3. Rated (234 mi) and estimated range (247 mi) they're now -13 units apart on the y axis, but are graphed at almost the exact same coordinate, with the estimated just being slightly below the rated. Compared to the baseline, I would expect the estimated coordinate to be above the rated coordinate, by a little less distance than the baseline
4. Rated (125 mi) and estimated (132 mi). They're now -7 units apart, with the estimated coordinate being significantly below the rated coordinate (y axis). Further below than the baseline, when the distance was 16 units. I would expect the estimated coordinate to be above the rated coordinate.

• The estimated range and rated range are the same unit (distance).
• At any point the estimated range and rated range were the same (both measured in distance), I expect the graph point to be the same coordinate.
• When the estimated range is higher than the rated range, I would expect the estimated coordinate to be higher than the rated on the y axis. The screen shots demonstrate that is not always the case.
• When the estimated range is lower than the rated range, I would expect the estimated coordinate to be below the rated coordinate.
• I expect the distance between the estimated and rated ranges y axis value to demonstrate the delta between the two values. It doesn't.

from teslamate.

As wrote before, the cursor does not snag to the correct value, this is a grafana "issue" when your zoom level is too small for quick changes in values.

from teslamate.

I don't understand "the cursor does not snag to the correct value" or "zoom level is too small for quick changes" What do you mean?

I recognize that in the graph above, Grafana is dealing with multiple records per point on the x axis. However, that does not explain the issue I'm seeing. The displayed values line up with the underlying data. I can't find 'adjacent' data that would explain the above.

Screen shot 3 explains the problem very well when you look at the data. The time is 2024-03-10 15:52:25 UTC. Here are records near that timestamp that have range values:

select id,
       date,
       convert_km(p.rated_battery_range_km, 'mi') as range_rated_mi,
       convert_km(p.est_battery_range_km, 'mi')   as range_estimated_mi
from positions p
where p.drive_id = 1781
  and p.date between '2024-03-10 15:52' and '2024-03-10 15:53'
  and p.rated_battery_range_km is not null
order by p.date


   id    |          date           |    range_rated_mi    |  range_estimated_mi  
---------+-------------------------+----------------------+----------------------
 4569786 | 2024-03-10 15:52:14.66  | 233.9903314402177290 | 247.0888687287956554
 4569841 | 2024-03-10 15:52:29.967 | 233.9903314402177290 | 247.0888687287956554
 4569890 | 2024-03-10 15:52:45.26  | 233.9903314402177290 | 246.7036176320727752

1. Screen shot 1 represents position ID 4567906. The values displayed in the screen shot for range equal the values displayed. This is the second record for this drive. The previous record had no range values. The next range value doesn't show up for 5 seconds - ID 4567906, date 2024-03-10 15:39:43.57, and the values are effectively the same.
2. Screen shot 2 represents position ID 4569599. The values displayed are correct for this record. The previous record with a range value was at 2024-03-10 15:50:58.281, and the next record with a range value isn't until 2024-03-10 15:51:28.858, ID 4569640. The values before and after are effectively the same
3. Screen shot 3 represents position ID 4569841. The values displayed are correct for this record. The previous record with a range value was at 2024-03-10 15:52:14.66 (id 4569786), and the next was at 2024-03-10 15:52:45.26 (id 4569890), the values before and after are less than 1 unit different.
4. Screen shot 4 represents position ID 4589081. The values displayed are correct for this record. The previous record with a range value was at 2024-03-10 17:47:50.972 (id 4589026), and the next was at 2024-03-10 17:48:21.738 (id 4589137). The values before and after are effectively the same

from teslamate.

@JakobLichterfeld I've provided data for a second drive which still demonstrates the same problem. This drive is only 10 minutes long, but the same issues are demonstrated.

from teslamate.

@cwanja has this issue been validated? I can create a MR with the field Min set to 0, but I'd prefer to know that it'd be accepted relatively soon.

from teslamate.

No, I have not taken the time to look into this further @tjhart. But will in the coming days.

from teslamate.

@DrMichael @Dulanic - can you review this thread and the proposed change below. To resolve the irregular lines spacing in the Drive Details panel, @tjhart proposed one of the following fixes (note the orange and red lines):

1. Add Standard options > Min 0 to Override 12

2. Remove Standard options > Min 0 from Override 9

In my testing, option two looks like the better path.

1. Do you agree?
2. Do you see / know any downstream impacts by removing this override property?

@jheredianet would appreciate any insights you have as well.

from teslamate.

@jheredianet and @cwanja I've reviewed the PR as it relates to this issue. The images above, and reviewing my own data with the changes, do NOT resolve the issue I see.

Note in this image

The rated range has a higher value, but the estimated range is higher in the displayed graph.

I displayed the data range on the right axis, (only for the purposes of testing and inspection), and to my surprise the scale for the estimated range dipped well into negative numbers, with zero at the middle of the graph. As best as I understand that statistic, a range, whether it's real, estimated, or rated, would never be below zero. I don't think this is related to any of the changes in that PR, but it's an interesting limit to consider.

from teslamate.

Note in this image

@tjhart unless I am missing it, your post does not include an image.

I displayed the data range on the right axis, (only for the purposes of testing and inspection), and to my surprise the scale for the estimated range dipped well into negative numbers, with zero at the middle of the graph. As best as I understand that statistic, a range, whether it's real, estimated, or rated, would never be below zero. I don't think this is related to any of the changes in that PR, but it's an interesting limit to consider.

Do you have a screenshot? Are you adding the ranges as axis markers? In all of the images here, only my comment has them listed on the axis'.

from teslamate.

Perfect, thanks for that response and clarity @tjhart. Based upon that, @jheredianet I would not say that PR unintendedly does not resolves this issue.

I would still like to see feedback from @Dulanic or @DrMichael before committing, but I am still thinking that removing Standard options > Min 0 from Override 9 is the solution path.

from teslamate.

@cwanja

Here's a screen shot with the range axis on the right. Again, this was just for me to visually see the scale. Zero seems to be vertically in the middle, which seems odd for these data sets. Also, again, I expected one range for the distance data set, not two.

I am no Grafana expert, but I imagine you should be able to resolve having zero in the middle similar to how the middle milage legend is on the right.

Also, again, I expected one range for the distance data set, not two.

What do you mean by this? Because you have both estimated and rated.

from teslamate.

Maybe the Solomonic solution could be separating the familiar metrics in another graph, to avoid confusion.

I disagree with moving some of the metrics out to its own graph, the Drive Details is already busy enough. I do think if we can smooth out the lines where metrics collide in an "unnatural" way, I think that is the best method. I do agree that we cannot add additional axis nor do I think @tjhart is after that (correct me if I am wrong however). If we can resolve the incorrect plotting of the lines where the lines are on top of each other (see image below) when the values are different would solve the issue in my opinion. These range values are not the same.

However, with Override 9 Standard Min > 0 removed, here is the same timestamp:

I was unsuccessful at modifying my image to pull your merged PR #3836 and test in my installation. But my gut tells me we would still need further modifications to smooth the line and achieve what @tjhart is reporting. Awaiting a response here (or on the PR) on how I could test that specific PR to validate my theory that further changes are still required.

from teslamate.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

from teslamate.

With all the attention that #3792 is rightfully getting, I don’t mind that this has become stale. And I don’t want this issue forgotten either. Bump. 😅

from teslamate.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

from teslamate.