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

[intesis] Improve session handling #16476

Merged
merged 6 commits into from Mar 5, 2024
Merged

[intesis] Improve session handling #16476

merged 6 commits into from Mar 5, 2024

Conversation

fd0cwp
Copy link
Contributor

@fd0cwp fd0cwp commented Mar 2, 2024

I have changed the login process so that the binding now only logs in at the beginning and logs out at the end. If a request fails due to a missing login or an invalid session ID, a new login attempt is made.

This ensures that

  • Several requests can be sent in direct succession (if I switch the air conditioning from cooling to heating, I also want to change the slats at the same time)
  • Less traffic is generated as there is not a constant logout and login again
  • Ideally, the login credentials should only be visible once at startup

I am unsure whether I have used the correct levels for the logging.

The updated binding has been running without any problems for a few weeks now in my environment. First under 4.1.0, and since a few days now under 4.1.1.

Signed-off-by: Christoph fd0cwp@gmx.de

I have changed the login process so that the binding now only logs in at the beginning and logs out at the end. If a request fails due to a missing login or an invalid session ID, a new login attempt is made.

This ensures that
- Several requests can be sent in direct succession (if I switch the air conditioning from cooling to heating, I also want to change the slats at the same time)
- Less traffic is generated as there is not a constant logout and login again
- Ideally, the login credentials should only be visible once at startup

I am unsure whether I have used the correct levels for the logging.

The updated binding has been running without any problems for a few weeks now in my environment. First under 4.1.0, and since a few days now under 4.1.1.

Signed-off-by: Christoph <fd0cwp@gmx.de>
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.

Left some comments, the build error has to be fixed (spotless), please also check if there are compile warnings.

Edit: Documentation about logging is here: https://www.openhab.org/docs/developer/guidelines.html#f-logging

@lsiepel lsiepel added the enhancement An enhancement or new feature for an existing add-on label Mar 3, 2024
@lsiepel lsiepel changed the title [intesis] SESSION ID HANDLING IMPROVED [intesis] Improve session handling Mar 3, 2024
fd0cwp and others added 4 commits March 4, 2024 17:37
…binding/intesis/internal/handler/IntesisHomeHandler.java


I think this is no code I changed, but I also prefer your suggestion.

Co-authored-by: lsiepel <leosiepel@gmail.com>
Signed-off-by: Christoph <36006493+fd0cwp@users.noreply.github.com>
I have changed the login process so that the binding now only logs in at the beginning and logs out at the end. If a request fails due to a missing login or an invalid session ID, a new login attempt is made.

This ensures that
- Several requests can be sent in direct succession (if I switch the air conditioning from cooling to heating, I also want to change the slats at the same time)
- Less traffic is generated as there is not a constant logout and login again
- Ideally, the login credentials should only be visible once at startup

I am unsure whether I have used the correct levels for the logging.

The updated binding has been running without any problems for a few weeks now in my environment. First under 4.1.0, and since a few days now under 4.1.1.

Signed-off-by: Christoph <fd0cwp@gmx.de>
@fd0cwp fd0cwp requested a review from lsiepel March 4, 2024 19:30
I have changed the login process so that the binding now only logs in at the beginning and logs out at the end. If a request fails due to a missing login or an invalid session ID, a new login attempt is made.

This ensures that
- Several requests can be sent in direct succession (if I switch the air conditioning from cooling to heating, I also want to change the slats at the same time)
- Less traffic is generated as there is not a constant logout and login again
- Ideally, the login credentials should only be visible once at startup

I am unsure whether I have used the correct levels for the logging.

The updated binding has been running without any problems for a few weeks now in my environment. First under 4.1.0, and since a few days now under 4.1.1.

Signed-off-by: Christoph <fd0cwp@gmx.de>
@fd0cwp fd0cwp requested a review from lsiepel March 5, 2024 11:06
@lsiepel lsiepel merged commit 9987215 into openhab:main Mar 5, 2024
3 checks passed
@lsiepel lsiepel added this to the 4.2 milestone Mar 5, 2024
@@ -109,6 +112,9 @@ public void initialize() {
updateStatus(ThingStatus.OFFLINE, ThingStatusDetail.CONFIGURATION_ERROR, "Password not set");
return;
} else {
logger.trace("trying to log in - current session ID: {}", sessionId);
login();
Copy link
Contributor

Choose a reason for hiding this comment

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

initialize() should return fast and not do any blocking network calls. This is the reason for background initialization below.

@@ -129,6 +135,8 @@ public void dispose() {
refreshJob.cancel(true);
this.refreshJob = null;
}

logout(sessionId);
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here.

@lsiepel
Copy link
Contributor

lsiepel commented Mar 6, 2024

@fd0cwp can you come up with a folow up PR as i missed these comment jlaur mentioned.

@fd0cwp
Copy link
Contributor Author

fd0cwp commented Mar 7, 2024

I am not sure if this is reasonable.

What is the purpose of the initialize function? I would say that the binding shall be set up so that it is functional. In my view, this also includes the login.
initialize should only be run when openHAB is started. Does the two seconds for the login matter? Or am I missing something?
From my point of view, the same applies to dispose.

I could remove the login from the initialize. This would result in the first call failing, then the login is made and the call is tried again.
I could also remove the logout from dispose. But then openHAB no longer shuts down cleanly.

@lsiepel, @jlaur: What do you think?

@jlaur
Copy link
Contributor

jlaur commented Mar 7, 2024

@lsiepel, @jlaur: What do you think?

I already stated what I think. 🙂 Please have a look at https://www.openhab.org/docs/developer/bindings/#startup:

Furthermore, the framework expects initialize() to be non-blocking and to return quickly. For longer running initializations, the implementation has to take care of scheduling a separate job which must guarantee to set the status eventually.

So this means you need to move the login(); into the scheduler.submit block just below, as mentioned. Similarly, you can also schedule the logout - like it was previously also done here:
20f306f#diff-94852e57bc82cccaead7afd2af8297593bd11fd5cee89fa0957a41a57677494eL176-L182

@fd0cwp
Copy link
Contributor Author

fd0cwp commented Mar 19, 2024

Hi @jlaur,

in https://www.openhab.org/docs/developer/bindings/#lifecycle this is noted:
The initialize method is called when the handler is started and dispose just before the handler is stopped. Therefore these methods can be used to allocate and deallocate resources.
I was the opinion that a valid connection is also some kind of resource.

However, I found several threads telling what you stated.
@lsiepel: So, I updated the source code again. Hopefully, it is now OK.

austvik pushed a commit to austvik/openhab-addons that referenced this pull request Mar 27, 2024
* [intesis] SESSION ID HANDLING IMPROVED

Signed-off-by: Christoph <fd0cwp@gmx.de>
Signed-off-by: Jørgen Austvik <jaustvik@acm.org>
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.

None yet

3 participants