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

Update inverter.py #47

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

Update inverter.py #47

wants to merge 7 commits into from

Conversation

dvisser
Copy link

@dvisser dvisser commented Sep 23, 2021

To allow for direct LAN API access using X-Forwarded-For header.

To allow for direct LAN API access using X-Forwarded-For header.
@dvisser
Copy link
Author

dvisser commented Nov 1, 2021

hey @squishykid any ideas when this might be merged/accepted please?

@TheZeroBeast
Copy link

Yes please, keen as mustard!

Copy link
Owner

@squishykid squishykid left a comment

Choose a reason for hiding this comment

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

Sorry for the slow response. In this case, could you please only send the headers for the inverter models which require the header? I am not able to test all of the existing inverters which work without the additional headers

@dvisser
Copy link
Author

dvisser commented Nov 17, 2021

I dont think it is inverter specific as such. More so specific to the use of the pocketwifi v2 adaptor. It is a fix to allow direct communication without needing a pi etc in the middle acting as a proxy.

@squishykid
Copy link
Owner

Sorry, what I am trying to say is that some inverters do not require this header, such as the X1 Hybrid which I was able to test the initial version of this library with.

My concern is that not all inverters will be able to handle the addition of the header and this might cause a new bug. Therefore I only want to enable this feature for the specific inverters where it has been identified that this will improve functionality.

@dvisser
Copy link
Author

dvisser commented Nov 17, 2021

I have one X1 Boost and one X1 hybrid (both with pocketwifi v2 adaptors) and I needed to do this for both. Its the newer pocketwifi firmware solax released that broke this originally. Then a workaround is using the header, which they have patched out, which is why I posted the firmware that allowed this header method to work also.

@dvisser
Copy link
Author

dvisser commented Nov 17, 2021

I dont think this is inverter specific at all. It relates to the pocketwifi adaptor v2.

@dvisser
Copy link
Author

dvisser commented Nov 17, 2021

maybe we could make the header field an option then? that of which is defaulted to none such that it doesnt break any current deployments users may have?

@dvisser
Copy link
Author

dvisser commented Dec 19, 2021

is this likely to be merged? do I need to further explain that this is NOT inverter specific as it relates to the pocketwifi v2 adaptor? how can we move forward with this?

@dvisser
Copy link
Author

dvisser commented Dec 20, 2021

I am happy to alter the PR in whatever manner is deemed appropriate. I can add the header just for the X1-Boost and X1-Hybrid (the inverters I physically have) if thats what you wish, however it is not an inverter specific fix as it comes down to what inverter the user is using the solax pocketwifi v2 adaptor on.

@dvisser
Copy link
Author

dvisser commented Dec 20, 2021

tested last commit and does work for X1 hybrid and X1 boost only. Awaiting your further advice Mr @squishykid

@squishykid
Copy link
Owner

Hi @dvisser, very happy to have this type of change included. I think the issue at the moment is just implementation specific. I want to stress that it is important that we don't modify existing behaviour unless a user chooses to opt in, or if the library can detect which version to use.

Maybe we can take a look at adapting the discover mechanism to make the library attempt connecting to the inverter using the existing behaviour first, then falling back to using the headers. Another option might be to have the user pass the choice as a parameter, with the existing behaviour being the default.

@dvisser
Copy link
Author

dvisser commented Dec 21, 2021

@squishykid sure, could we look at the last option? I think a parameter (even a simple xffheader = true) that is defaulted to false would suffice. If you agree I can modify and push an updated commit to this PR? I would really like this parameter available via your home assistant solax platform also.

@dvisser
Copy link
Author

dvisser commented Dec 21, 2021

something like my last commit @squishykid ?

@squishykid
Copy link
Owner

squishykid commented Dec 21, 2021

Yeah! That's on the right track. We will need to update the tests so they exercise the new code path. I might have some more time next week to look at this properly if you get stuck with that.

One thing to note in your change is that you require the user to opt in and out of the feature by changing the parameter. There's a bunch of overdue work in home-assistant for the solax integration which means it's difficult to add new parameters. So ideally we would have the discovery element figure out on it's own whether or not to use the header.

@dvisser
Copy link
Author

dvisser commented Dec 21, 2021

@squishykid OK awesome. Well if you dont get time next week, please let me know and I will happily do some more dev to get this sorted. I assume we would just try to discover via the current manner and then if that fails, then try again with the xffheader turned on? or something along those lines?

I am keen if you want help with the home assistant solax integration also, so please feel free to give me a run through and I can help there too if you wish?

@dvisser
Copy link
Author

dvisser commented Dec 21, 2021

@squishykid something like that I am thinking? after the first attempt at discovery fails, the discovery method then tries again with the X-Forwarded-For header.

@dvisser
Copy link
Author

dvisser commented Dec 21, 2021

may need to make xffheader global, as when discovery sets it to true, it should remain true for all other methods if it was successful.

@squishykid
Copy link
Owner

squishykid commented Dec 31, 2021

As mentioned above, I want to introduce this new feature via the 'discovery' mechanism. You can see in #52 for how this was implemented. So we will need some API call examples for the test cases, as described here: https://github.com/squishykid/solax/wiki/DiscoveryError

@dvisser
Copy link
Author

dvisser commented Dec 31, 2021

OK @squishykid I will take a look at #52 and see how I go.

@dvisser
Copy link
Author

dvisser commented Feb 21, 2022

I will try to revisit this asap, as I really want to remove my automation that patches this code in home assistant everytime there is HA core update.

Have you had any time to look at this @squishykid ? I am not familiar with the discovery stuff, but I will try to learn it quickly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants