Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[aWATTar] Add aWATTar API class #17169

Merged
merged 1 commit into from
Aug 30, 2024

Conversation

tl-photography
Copy link
Contributor

This PR introduces an class for the aWATTar API for future refactoring and testing.

The class is intended to encapsualtes the API access.

All current tests will still be positive but can later be split into API and Bridge tests.

@tl-photography tl-photography force-pushed the feature/create-awattar-api-class branch from 4f57c66 to 6346d1b Compare July 28, 2024 09:29
@J-N-K
Copy link
Member

J-N-K commented Jul 28, 2024

What is the benefit of refactoring this to a new class?

@tl-photography
Copy link
Contributor Author

tl-photography commented Jul 28, 2024

The main idea was to split the functionality for better testing the bridge.
I was working on tests for the refresh functionality for the Bridge and I thought the class had too many functionality directly build-in.

I figured it would be beneficial to move functionality into separate classes for better maintainability and testing later on.

EDIT: if you want i can split the tests also with this PR, maybe then the intention would be more clear.

Copy link
Member

@J-N-K J-N-K left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added some comments.

@tl-photography tl-photography force-pushed the feature/create-awattar-api-class branch 2 times, most recently from 127e5f7 to 21dd81f Compare July 31, 2024 23:00
@Wolfgang1966
Copy link

From my point of view extracting the API makes sense. As I would not call myself a experienced Java developer (anymore :-) ), I can't comment on nifty details, so take my approval for the general approach :-)

Copy link

@Wolfgang1966 Wolfgang1966 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@Wolfgang1966
Copy link

Wolfgang1966 commented Aug 2, 2024

One more idea that came to me yesterday evening: Encapsulating away the aWATTar API from the rest of the binding logic would make it much easier to add other energy price providers to the binding (e.g. entsoe), while reusing all the rest of the code. So the aWATTar binding could be extended to a general energy price binding. And as are about to add TimeSeries support also already most of the work for such an universal Energy address binding is already there soon. What do you think @tl-photography ? From my point of view we mainly would need to add an Interface to be implemented by the API providers to make this happen. Ok, configuration of access data (e.g. entsoe API requires an API key) will be needed also. Am I thinking too big now?

@jlaur
Copy link
Contributor

jlaur commented Aug 2, 2024

One more idea that came to me yesterday evening: Encapsulating away the aWATTar API from the rest of the binding logic would make it much easier to add other energy price providers to the binding (e.g. entsoe), while reusing all the rest of the code. So the aWATTar binding could be extended to a general energy price binding.

While I do think it would be beneficial to reuse logic between energy price providers, I don't think this is the right approach.

We already have different bindings: aWATTar, Energi Data Service, Tibber and an ENTSO-e. They are very different bindings integrating with different services. Merging them would be similar to merging e.g. the Hue, WLED and Govee Lan-API bindings, because they are all related to lighting.

openhab/openhab-core#3478 proposes some kind of energy management component, and there is even a proposed architecture. Unfortunately no one has had time (and/or interest) to pick this up yet.

@Wolfgang1966
Copy link

Hi @jlaur , thanks for the pointer to the energy management component. I just scrolled over the discussion (did not read it in detail), but the idea looks very good to me. And, I have to admit that I am a little bit proud of the fact that the aWATTar binding seems to cover a fair part of the computational aspects (consecutive/nonconsecutive) bestprice time ranges that are discussed there :-). So my assumptions about the typical use cases seemed not to have been completely wrong, although of course further aspects might need to be considered also. The potential problem with picking this up might be that it describes a quite complex architecture that requires a lot of work, and it has to be part of the openHAB core which significantly reduces the number of people being able to do it, while it is much easier to provide one additional binding or modify an existing one. I was reminded of the discussion between OSI and TCP/IP networking in the 1990th, where OSI networking was carefully crafted to cover every networking aspect that might ever be needed by somebody, while TCP/IP just implemented what somebody needed at a certain moment. Guess who won :-)

So on the one side we have the aWATTar binding which already exists and covers perhaps 50% of the use cases, but mainly lacks the functionality to work with different price providers. On the other hand, we have the elaborated architecture, which nobody picked up yet.

How about this: We make a very simple interface between energy price providers and the calculation service and try to start with this? The calculation service could be taken from the aWATTar binding, and the interface for the price providers, as soon as it exists in the openHAB core, could then be implemented with acceptable effort by the different bindings that already exists. It could be some variant of a TimeSeries with objects like the one described above.

@tl-photography
Copy link
Contributor Author

tl-photography commented Aug 2, 2024

The idea does not sound that bad thb.

I also think that the proposed architecture does sound good and it is a good idea to have this inside openHAB, since this is the future in my opinion.

But this is not a short term solution.

We could, however, get in touch with the guys from the other bindings and propose an interim solution for this, with using a extensible API interface.

I think it would make A LOT of sense to instead develop all separate in parallel together to get the best out of it.

@tl-photography
Copy link
Contributor Author

tl-photography commented Aug 2, 2024

One more thing @J-N-K:

I wanted to add tests to the exception and the "@test/...." part is not resolved there.
Is this something that is handled by OSGI or else?

If yes, is this actually testable with unit tests?

See here: https://github.com/openhab/openhab-addons/pull/17169/files#diff-42bf1c985f5ee02185636c69552f530ef88e73d06a4ffaa98d685b281f6ee6c9R145

@tl-photography
Copy link
Contributor Author

We already have different bindings: aWATTar, Energi Data Service, Tibber and an ENTSO-e.

I had a look at the code of these bindings and i would say, apart from Tibber (which offers also live data and has a little bit more complicated data model), all the others do use more or less the exact same data structure and have similar API architectures.

Energi Data Service seems to be more advanced in general, but also quite complex.

@tl-photography tl-photography force-pushed the feature/create-awattar-api-class branch from 037cef7 to 4f5d21a Compare August 4, 2024 12:01
@tl-photography
Copy link
Contributor Author

ok, this should be good now.
I also checked coverage and looks good.

image

@J-N-K We are going to have conflicts with your open PR. I checked the potential parts an i think i can merge them quickly afterwards. Or would you like to make the changes after my PR?

@jlaur
Copy link
Contributor

jlaur commented Aug 6, 2024

I was reminded of the discussion between OSI and TCP/IP networking in the 1990th, where OSI networking was carefully crafted to cover every networking aspect that might ever be needed by somebody, while TCP/IP just implemented what somebody needed at a certain moment. Guess who won :-)

Well, TCP/IP has a pretty nice architecture as well, so I would consider that statement a bit exaggerated. 😄

How about this: We make a very simple interface between energy price providers and the calculation service and try to start with this?

I would need to get back into the details of @kaikreuzer's proposed architecture, but if it's possible to implement a sub part of it without preventing a full implementation later, I don't see any problems with that. Perhaps this discussion should be continued in that issue?

The calculation service could be taken from the aWATTar binding

I didn't check it in details, but I think some parts of the Energi Data Service binding might come in handy as well (at least conceptually), as I think it can do more advanced calculations - see for example https://www.openhab.org/addons/bindings/energidataservice/#thing-actions-example.

@Wolfgang1966
Copy link

Well, TCP/IP has a pretty nice architecture as well, so I would consider that statement a bit exaggerated. 😄

You know that the "current" architecture with IP and TCP separated into two layers was actually the second approach, incorporating the learnings from the previous one (without layering)? 😉

How about this: We make a very simple interface between energy price providers and the calculation service and try to start with this?

I would need to get back into the details of @kaikreuzer's proposed architecture, but if it's possible to implement a sub part of it without preventing a full implementation later, I don't see any problems with that. Perhaps this discussion should be continued in that issue?

Sounds good! My impression is that you are deeper in the topic already than I am, so it would be great if you could start that.

From what I learned the last days regarding the discussions about desired legal changes for PV in 2025, this topic will become more and more important.

The calculation service could be taken from the aWATTar binding

I didn't check it in details, but I think some parts of the Energi Data Service binding might come in handy as well (at least conceptually), as I think it can do more advanced calculations - see for example https://www.openhab.org/addons/bindings/energidataservice/#thing-actions-example.

Checked it, it is more elaborated especially for non-linear loads. Also, the danish price model seems to have more components than the one in Germany, so the architecture should be able to provide an interface for calculation of the total prices out of the spot prices as well.

Ok, things are starting to become complex.

@kaikreuzer
Copy link
Member

I would need to get back into the details of @kaikreuzer's proposed architecture, but if it's possible to implement a sub part of it without preventing a full implementation later, I don't see any problems with that. Perhaps this discussion should be continued in that issue?

I second @jlaur here. The proposed architecture is not meant to be an initial first step. Rather the vision at the horizon. Naturally, we should go there step by step (and also adapt it on the way while learning). So instead of creating a "temporary solution between different bindings" (you all know that temporary solutions last longest...), all the binding developers should join the discussion on the core issue and help defining suitable interfaces to get started on the topic. I am personally still very much interested in driving it forward and the more activity there is on the issue, the more I'll be forced to involve myself as well. 😄

@tl-photography tl-photography force-pushed the feature/create-awattar-api-class branch from e9143b3 to 8b6d765 Compare August 9, 2024 20:13
@tl-photography tl-photography force-pushed the feature/create-awattar-api-class branch from 8b6d765 to 8877997 Compare August 9, 2024 20:18
@tl-photography
Copy link
Contributor Author

tl-photography commented Aug 10, 2024

Hi i think I did cover all requests and fixed the conflicts.
Is there anything missing?

Copy link
Contributor

@lsiepel lsiepel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@lsiepel lsiepel requested a review from J-N-K August 20, 2024 10:20
Copy link
Member

@J-N-K J-N-K left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@J-N-K J-N-K added this to the 4.3 milestone Aug 30, 2024
@J-N-K J-N-K added the enhancement An enhancement or new feature for an existing add-on label Aug 30, 2024
@J-N-K J-N-K merged commit 229737f into openhab:main Aug 30, 2024
5 checks passed
digitaldan pushed a commit to digitaldan/openhab-addons that referenced this pull request Sep 24, 2024
pgfeller pushed a commit to pgfeller/openhab-addons that referenced this pull request Sep 29, 2024
Signed-off-by: Thomas Leber <[email protected]>
Signed-off-by: Patrik Gfeller <[email protected]>
joni1993 pushed a commit to joni1993/openhab-addons that referenced this pull request Oct 15, 2024
matchews pushed a commit to matchews/openhab-addons that referenced this pull request Oct 18, 2024
@jlaur jlaur changed the title [aWATTar] add aWATTar API class [aWATTar] Add aWATTar API class Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An enhancement or new feature for an existing add-on
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants