Initial Import of Historical Data #101
Conversation
This imports the hourly consumption into the statistics entity. If the integration is set-up for the first time, the current meter reading is fetched and used as a baseline.
My bad. I made a mistake setting up that test case |
Codecov Report
@@ Coverage Diff @@
## main #101 +/- ##
==========================================
- Coverage 33.16% 29.44% -3.72%
==========================================
Files 9 12 +3
Lines 392 618 +226
Branches 48 84 +36
==========================================
+ Hits 130 182 +52
- Misses 258 428 +170
- Partials 4 8 +4
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
… out Replace f-formatting by lazy formatting in various debug msgs
|
I launched it, got a warning stating that the updating of the sensor took > 10 seconds. Maybe 3 years is a bit far in the past for one shot.
That is amazing! How did you find out this is a feature of the b2b api? |
There was a problem hiding this comment.
Please run
flake8 custom_components/wnsm --count --select=E9,F63,F7,F82 --show-source --statistics --config tests/setup.cfg
and
flake8 custom_components/wnsm --count --exit-zero --max-complexity=10 --statistics --config tests/setup.cfg
and resolve the issues. (sometimes it pays of to disable them inline #noqa: XXX
| # Keep that in mind if for someone this fails. | ||
| logger.debug(f"Returned data: {data}") | ||
| raise SmartmeterQueryError("Returned data does not match given zaehlpunkt!") | ||
| obis_code = data[0]['zaehlwerke'][0]['obisCode'] |
just watched the webpage with the developer tools 😀
When you visit the dataexport in the smartmeter-web, 3 years is the standard setting. Thus I thought it might be OK to do the same. Does it take very long for you? I only have smartmeter entries since November 2023, and thus with any date range it is actually quite fast. I just thought about an issue with this approach: If for some reason it fails to gather the data, the init procedure will be called again and again. So we need some way of determining that the init was called once and do not start it again. |
…eSmartmeter into f/initial_import
# Conflicts: # custom_components/wnsm/api/client.py # custom_components/wnsm/sensor.py
So same technique as I did it. :) but I've not discovered this part yet. Good catch! ❤️
hmm... I guess then 3years should be fine. But you have a point there. What we could do though is only try it once at set-up. If it fails we shouldn't trigger it anew. We can implement an option in the config_flow to trigger it manually. I have to look into the details though. so better add an |
…eSmartmeter into f/initial_import
|
@reox unless you have any concerns. I'd release this feature. It's downwards compatible and runs smoothly already. Regarding
I'd create another issue, when I've got your Okay. :) |
|
@DarwinsBuddy it runs also smoothly on my side! Except some missing test cases, I think it is good to go :) |
yet another thing to test ;)
Implemented the fetching of the historical data and import it on initial sensor setup.
This resolves #26 - at least partially, because it grabs the data directly instead of asking