Fix consumption update for live sensor of second zaehlpunkt

[tschoerk]

When updating the consumption data for the second zaehlerpunkt, the base meter readings don't have the information for this zaehlerpunkt, since it's not the "default" zaehlerpunkt. So the live sensor tries to get the information by checking the consumption data for yesterday to update the sensor with this value. This second method has several bugs though, which this pull request aims to fix.

This should resolve #227

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 85.06%. Comparing base (02015a3) to head (5f6e847).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #233 +/- ## ========================================== + Coverage 81.25% 85.06% +3.81% ========================================== Files 5 5 Lines 288 288 ========================================== + Hits 234 245 +11 + Misses 54 43 -11 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[tschoerk]

Both live sensors receive the meter readings the same way now by calling the historical data API with the value type METER_READ which returns the meter reading for each day. The latest value is then used to update the live sensor. This can be done with one or more zaehlpunkte and all return the same value type now, which is the total usage/feeding since implementation of the zaehlpunkt. This fixes the problems with the live sensor on a second zaehlpunkt as well as makes the output uniform.

[DarwinsBuddy]

@tschoerk I fear you've created another merge commit instead of rebasing the branch onto master. :grimacing:

[tschoerk]

@tschoerk I fear you've created another merge commit instead of rebasing the branch onto master. 😬

Sorry not too experienced with git. What to do, to fix this?

[DarwinsBuddy]

1. git checkout DarwinsBuddy main
2. git pull
3. git checkout tschoerk bugfix/loadConsumption
4. git rebase --onto main
5. resolve all conflicts one commit at a time by 5.1. resolving 5.2. git rebase --continue 5.3. repeat 5.1. until all conflicts are resolved
6. git push --force-with-lease

!Be careful! Do point 6 after you've successfully confirmed, that this branch is working as you'd expect it, otherwise throw away the branch, check it out anew and rebase again.

This should resolve all conflicts and remove all merge commits that you've introduced

[s00500]

Just tested this PR and it seems to work! I was bothered by this issue forever now... 😅

[tschoerk]

Sorry, I probably did something wrong here. I rebased following your instructions and now all my commits in my branch are gone and it's just like main, because I am stupid and did not check properly. I will create a new branch with the changes, just so it's kept for future reference. Let me know how to best proceed. Sorry for the inconvenience.

[DarwinsBuddy]

@tschoerk no worries. when I did my first rebase I also messed it up. :) So that's part of the journey

Maybe something that helps https://saraford.net/2017/04/21/how-to-visualize-a-rebase-in-the-git-visualization-tool-111/

Just file a new PR with the changes applied. :)

[s00500]

The Rebase tools in VSCode are usually very good :-) (by now it will automatically allow you to continue and understand you are in a rebase)

I usually tell all devs on my team to use autorebase+autostash on pull, once you get comfortable with it it is a great workflow ;-) On 7. Oct 2024 at 11:06 +0200, Christoph Spörk @.***>, wrote:

@tschoerk no worries. when I did my first rebase I also messed it up. :) So that's part of the journey Maybe something that helps https://saraford.net/2017/04/21/how-to-visualize-a-rebase-in-the-git-visualization-tool-111/ Just file a new PR with the changes applied. :) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>