[electroluxair] No longer connecting to API

Aaargh20318 commented 1 month ago

Expected Behavior

Binding connects to API

Current Behavior

Binding is offline with status COMMUNICATION_ERROR

Logging: 2024-08-13 21:28:31.927 [DEBUG] [xair.internal.api.ElectroluxDeltaAPI] - HTTP POST Request HttpRequest[POST /one-account-authentication/api/v1/authenticate HTTP/1.1]@a790bcf. 2024-08-13 21:28:32.000 [WARN ] [xair.internal.api.ElectroluxDeltaAPI] - Failed to refresh!

Steps to Reproduce (for Bugs)

Configure electroluxair thing
Try to log in

Your Environment

Version used: openHAB 4.0.0 Release Build,

lsiepel commented 1 month ago

Are you aware of a change on the API side? probably not fixing the issue, but would be nice to know if it also exists on an openHAB 4.2.1 installation.

@jannegpriv are you aware of any change?

jannegpriv commented 4 weeks ago

I will look into this, I see the same on my installation.

jannegpriv commented 4 weeks ago

Electrolux has discontinued the Delta API that the binding is using and has created a new Electrolux Group API.

That API can be used to control all Electrolux appliances, so I guess the best idea is to deprecate the electroluxair binding and instead create a new electrolux binding, that will use the new API.

jannegpriv commented 2 weeks ago

@lsiepel What is the best option here?

Rename the existing electroluxair binding to electrolux, then let it handle all electrolux appliances
Discontinue the electroluxair binding and create a new binding electrolux, that will handle all electrolux appliances

lsiepel commented 2 weeks ago

g electroluxair binding to electrolux, then let it handle all electrolux appliances

Discontinue the electroluxair binding and create a new

Depends on how similar the bindings exposed model to the user will be (Things, Channels etc) If they are very similar, it would be fine to rename andd extend the current binding. If they differ, it would be best to start coding a new binding from scratch.

I tend to suggest start from scratch and copy code from the current binding where possible. But I can't exactly advice where the switch is between the two scenario's as im not familiair with their products or this binding.

jlaur commented 2 weeks ago

You might want to reconsider the naming, i.e. if it can somehow be more specialized than just "electrolux". I'm not aware how big the company is and how many different things they produce, but choosing only the company can lead to problems later on. Examples:

There is a tesla binding for the car, but Tesla also started producing Powerwall and Solar Roof, so now there is also a teslapowerwall binding. I assume it has nothing in common with the car binding, which should probably have been named teslacar.
There is a samsungtv binding, which is quite big since it supports many different models and features. But Samsung as a company a huge and into so many different domains that a samsung binding wouldn't have made any sense.
Same example with Siemens - creating a siemens binding could even expand to supporting nuclear power plants. 😄 There are siemenshvac and siemensrds bindings.
It seems that the miele binding didn't run into such issues (yet), except that there is now also a mielecloud binding. They both cover home appliances, but support different technologies (local Zigbee vs. Wi-Fi through cloud).

I'm not saying the name is right or wrong, just some input you could take into consideration when choosing a name for whatever that binding will cover.

lsiepel commented 2 weeks ago

nds on how similar the bindings exposed model to the user will be (Things, Channels etc) If they are very similar, it would be fine to rename andd extend the current binding. If they

Thanks @jlau, i mainly focused on the process, but the actual name is also a very important decision.

jannegpriv commented 2 weeks ago

Since the new API works with different Electrolux Appliances, maybe the naming of the new binding should be ElectroluxAppliances [electroluxappliances], WDYT?

I think creating a new binding is the way to go, and take some inspiration from the old one.

How do you deprecate/remove an outdated binding?

lsiepel commented 2 weeks ago

Since the new API works with different Electrolux Appliances, maybe the naming of the new binding should be ElectroluxAppliances [electroluxappliances], WDYT?

I think creating a new binding is the way to go, and take some inspiration from the old one.

How do you deprecate/remove an outdated binding?

I would say: Remove the binding folder, update the bundles\pom, codeowner and add a warning to the distribution upgrade notice.

jannegpriv commented 2 weeks ago

add a warning to the distribution upgrade notice.

How do I accomplish that?

lsiepel commented 2 weeks ago

add a warning to the distribution upgrade notice.

How do I accomplish that?

Create a PR to the distro repo for this file: https://github.com/openhab/openhab-distro/blob/main/distributions/openhab/src/main/resources/bin/update.lst

jannegpriv commented 2 weeks ago

Like this:

[4.2.0]
DELETE;$OPENHAB_USERDATA/logs/audit.log
ALERT;ElectroluxAir binding: The binding has been removed since the Electrolux Delta API has been discontinued.

Or should it be DELETE or DELETEDIR?

lsiepel commented 2 weeks ago

Like this:

[4.2.0]
DELETE;$OPENHAB_USERDATA/logs/audit.log
ALERT;ElectroluxAir binding: The binding has been removed since the Electrolux Delta API has been discontinued.

Alert, REPLACE and updated version number. Not surre how we handle this when we backport it to 4.2.2, but when you create a PR it will be picked up.

[4.3.0]
REPLACE;electroluxair;;$OPENHAB_USERDATA/config/org/openhab/addons.config
ALERT;ElectroluxAir binding: The binding has been removed since the Electrolux Delta API has been discontinued.

openhab / openhab-addons