-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
[solax] Initial contribution #14880
[solax] Initial contribution #14880
Conversation
This pull request has been mentioned on openHAB Community. There might be relevant details there: |
6bf7069
to
7589809
Compare
This pull request has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/warning-during-build-and-error-in-the-pr-build/147406/1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR!
You can probably fix the builds by adding a dependency for your add-on to this POM file:
bom/openhab-addons/pom.xml
Thanks for the suggestion. That indeed fixed the build issue. I wonder if you could also do a review of the binding. At the current stage I think we can merge it as initial version of the binding with local connection only. |
Signed-off-by: Konstantin Polihronov <polychronov@gmail.com>
Signed-off-by: Konstantin Polihronov <polychronov@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the contribution! It looks good - I have added some feedback from my first review round. 🙂
...enhab.binding.solax/src/main/java/org/openhab/binding/solax/internal/SolaxBridgeHandler.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Jacob Laursen <jacob-github@vindvejr.dk> Signed-off-by: Konstantin Polihronov <polychronov@gmail.com>
Signed-off-by: Konstantin Polihronov <polychronov@gmail.com>
Signed-off-by: Konstantin Polihronov <polychronov@gmail.com>
Hi, Cheers, |
How can I create / remove channels dynamically? I think that could be very well the solution (instead of creating separate handlers)... |
...in/java/org/openhab/binding/solax/internal/connectivity/rawdata/LocalConnectRawDataBean.java
Outdated
Show resolved
Hide resolved
...in/java/org/openhab/binding/solax/internal/connectivity/rawdata/LocalConnectRawDataBean.java
Show resolved
Hide resolved
You would need to do either one or the other. For this scenario it seems simplest to remove a few statically defined channels: List<Channel> channelsToRemove = new ArrayList<>();
updateThing(editThing().withoutChannels(channelsToRemove).build()); See for example: Lines 604 to 650 in 5c6fabb
In other more dynamic scenarios the best (or only) option is to create all relevant channels dynamically. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See latest posted comments.
Hi,
` I had to tackle it by adding the following dependency to the pom.xml: Do you know what could be the reason for this? I couldn't find any breaking changes in the recent commits... also tried to update to 4.0.2 my docker infrastructure but it's the same behaviour... |
Could it be related to this issue? The other warnings during build that I have are these: |
OK. Seems that the units of measurement library has changed in 4.1 (or at least it's very similar to what I see written here: #10926) |
* Add empty json string check * Add serialization annotations for the fields with capital letters * Refactor the fields with capital letters Signed-off-by: Konstantin Polihronov <polychronov@gmail.com>
Hi, |
Yes, I wanted to clone your branch and try to propose a fix yesterday, but unfortunately ended up not finding the time. I'll try to prioritize it in the evening today. |
Oh. OK. No worries. Take your time. We all have our other tasks...
…On Wed, Aug 23, 2023 at 2:59 PM Jacob Laursen ***@***.***> wrote:
the only leftover warning is the one for the NPE which I don't know how to
resolve at the moment... Could you please check my comments in the thread
about it?
Yes, I wanted to clone your branch and try to propose a fix yesterday, but
unfortunately ended up not finding the time. I'll try to prioritize it in
the evening today.
—
Reply to this email directly, view it on GitHub
<#14880 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB7Q3LUJMOKIUYZINS7T6JDXWXWDJANCNFSM6AAAAAAXLFSSFM>
.
You are receiving this because you were assigned.Message ID:
***@***.***>
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With these suggestions it compiles for me without any warnings or checkstyle issues.
...in/java/org/openhab/binding/solax/internal/connectivity/rawdata/LocalConnectRawDataBean.java
Outdated
Show resolved
Hide resolved
...in/java/org/openhab/binding/solax/internal/connectivity/rawdata/LocalConnectRawDataBean.java
Show resolved
Hide resolved
…nding/solax/internal/connectivity/rawdata/LocalConnectRawDataBean.java Co-authored-by: Jacob Laursen <jacob-github@vindvejr.dk> Signed-off-by: Konstantin Polihronov <polychronov@gmail.com>
…nding/solax/internal/connectivity/rawdata/LocalConnectRawDataBean.java Co-authored-by: Jacob Laursen <jacob-github@vindvejr.dk> Signed-off-by: Konstantin Polihronov <polychronov@gmail.com>
OK I confirmed your changes and tested them locally. All looks good except my Eclipse warning but that's fine... |
Before we complete the PR.... just to be sure that I understand the approach - your proposal is to add all the possible channels in one thingtype (inverter) and based on the inverter type I just dynamically remove the unnecessary channels in the handler, is my understanding right? |
Exactly. It might be a good idea to create an issue for the next development iteration. This can also be used for discussing such things. Just give me a go-ahead for merging. |
Yep. Please merge. I'll create a new PR once I'm ready with the option to support multiple inverters.. |
You're welcome, and thanks again for your contribution. To not forget, please see https://www.openhab.org/docs/developer/addons/#add-your-add-on-s-logo-to-the-openhab-website |
Signed-off-by: Konstantin Polihronov <polychronov@gmail.com>
Signed-off-by: Konstantin Polihronov <polychronov@gmail.com> Signed-off-by: Jørgen Austvik <jaustvik@acm.org>
This is a OpenHAB binding for a Solax Wi-fi modules that have the option to be connected directly via HTTP (firmware version 3.x+).
Currently the Solax cloud services provide an update on every 5 minutes (sometimes even more) and they also happen to be down sometimes, which makes it hard to automate the decision making by OpenHAB if we have more complex rules.
For example: I want to charge my car if the battery of my inverter is 90%+ and my overall consumption is only from the solar power.
The binding retrieves structured data from the wifi module, parses it and pushes it in to a inverter thing where each channel represents a specific information (inverter output power, voltage, PV1 power, etc)
More about the technical review of the PR:
The HTTP connectivity part is in the connectivity package.
There we have a "connector" which uses the common jetty client from the openhab distribution, connects to the wi-fi module and retrieves the raw data from the module. It is used directly from the bridge handler to connect and retrieve the necessary data.
Then we create the raw data bean which implements the InverterData interface and the methods of the interface directly retrieve data from the raw data bean and provide it as an easy to use Java code. (this is arguable from architecture perspective if it's better bean to have only the raw data and to use a separate parser that returns a DTO but from simplicity point of view it looks better to me this way currently)
The methods of the InverterData interface are used as getters to make the data transformation and set the channel values of the inverter thing in openHAB thing handler by using the InverterDataUpdateListener interface which is called from the bridge.
The InverterData interface is needed because at later point in time I will implement a second bridge which can retrieve a different raw data from the cloud service which could be useful for people who do not own/did not upgraded to firmware version 3.x of the Solax wi-fi module and only support cloud connection. The idea is not to care what bridge do we have but to have a common way to retrieve practically the same data which is structured in a separate way and set the Inverter thing channels.
A marketplace topic: https://community.openhab.org/t/solax-binding/146324
Cheers,
Konstantin