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

[DLinkSmartHome] add DSP-W215 Smart Plug #8648

Closed
wants to merge 1 commit into from

Conversation

pasbi
Copy link

@pasbi pasbi commented Oct 3, 2020

Note: the original PR (2.5.x) is #8361.

DESCRIPTION

  • What is the classification of the PR, e.g. Bugfix, Improvement, Novel Addition, ... ?
    Add support for a thing.
  • Did you describe the PRs motivation and goal?
    Read temperature, state and total/current power consumption of the thing, set the state of the thing.
  • Did you provide a link to any prior discussion, e.g. an issue or community forum thread?
    No.
  • Did you describe new features for the end user?
    Yes, in the README.md
  • Did you describe any noteworthy changes in usage for the end user?
    Not necessary.
  • Was the documentation updated accordingly, e.g. the add-on README?
    Yes.
  • Does your contribution follow the coding guidelines:
    https://www.openhab.org/docs/developer/development/guidelines.html
    It passed all the checks, and I'm not aware of any violation. Yet, I'm not sure. BTW, the link is broken.
  • Did you check for any (relevant) issues from the static code analysis:
    https://www.openhab.org/docs/developer/development/bindings.html#static-code-analysis
    Yes.
  • Did you sign-off your work:
    Yes.

TESTING

add DSP-W215 Smart Plug (2.5.x PR: openhab#8361)

Signed-off-by: Pascal Bies <pascal.bies@k-lens.de>
@pasbi pasbi requested a review from MikeJMajor as a code owner October 3, 2020 19:13
@pasbi pasbi changed the title [DLinkSmartHome] migrate code from 2.5.x [DLinkSmartHome] add DSP-W215 Smart Plug Oct 3, 2020
@TravisBuddy
Copy link

Travis tests have failed

Hey @pasbi,
please read the following log in order to understand the failure reason. There might also be some helpful tips along the way.
It will be awesome if you fix what is wrong and commit the changes.

<version>3.0.0-SNAPSHOT</version>
<version>2.5.9-SNAPSHOT</version>
Copy link
Member

Choose a reason for hiding this comment

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

Is this change intentional?

*
* @author Pascal Bies - Initial contribution
*/
public abstract class DLinkHNAP {
Copy link
Member

Choose a reason for hiding this comment

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

Please add the NonNullByDefault annotation.

public void start(ScheduledExecutorService scheduler) {
try {
pollFuture = scheduler.scheduleWithFixedDelay(this::poller, 0, DETECT_POLL_S, TimeUnit.SECONDS);
} catch (Exception e) {
Copy link
Member

Choose a reason for hiding this comment

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

What type of exception do you expect here? Can you specify the concrete type?

} catch (Exception e) {
updateStatus(ThingStatus.OFFLINE, ThingStatusDetail.HANDLER_INITIALIZING_ERROR,
"Unexpected internal error.");
logger.error("Failed to start http client or scheduler.");
Copy link
Member

Choose a reason for hiding this comment

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

Bindings should only log to error if something severe happened, like the detection of a bug in your code. This could be warn.

Additionally, you could remove the logging statement at all, as updateStatus() already does the logging.

Comment on lines +162 to +168
} catch (CommunicationException e) {
logger.error("Failed to get quantity (communication error).");
updateStatus(ThingStatus.OFFLINE, ThingStatusDetail.COMMUNICATION_ERROR);
} catch (SOAPException e) {
logger.error("Unexpected internal error.");
updateStatus(ThingStatus.OFFLINE);
}
Copy link
Member

Choose a reason for hiding this comment

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

You could include the exceptions message as third parameter to updateStatus() to display the error in the UI.
You could remove the logging statement, as updateStatus() already does the logging.

Comment on lines +64 to +68
try {
DLinkSmartPlugHandler.this.setState((OnOffType) command);
} catch (ClassCastException e) {
logger.error("Unexpected command type for channel '{}'.", DLinkSmartHomeBindingConstants.STATE);
}
Copy link
Member

Choose a reason for hiding this comment

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

Unchecked exceptions should be cought only if necessary. Please check the type beforehand.

Comment on lines +79 to +82
@Override
public void dispose() {
super.dispose();
hnap.stop();
Copy link
Member

Choose a reason for hiding this comment

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

The super destructor should be called at the end of the implementing method.

private ChannelUID getChannelUID(final String name) {
Channel channel = thing.getChannel(name);
if (channel == null) {
logger.error("Did not find channel '{}'.", name);
Copy link
Member

Choose a reason for hiding this comment

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

See above. this could be warn.

Comment on lines +146 to +147
logger.error("Unexpected channel: '{}'.", channelID);
throw new IllegalArgumentException("Unexpected channel.");
Copy link
Member

Choose a reason for hiding this comment

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

Uncought unchecked exceptions are logged by the framework. You could remove the logging message.

xmlns:thing="https://openhab.org/schemas/thing-description/v1.0.0"
xsi:schemaLocation="https://openhab.org/schemas/thing-description/v1.0.0 https://openhab.org/schemas/thing-description-1.0.0.xsd">

<channel-type id="current_consumption" advanced="true">
Copy link
Member

Choose a reason for hiding this comment

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

Is there are reason why you made all Channels advanced?

@cpmeister cpmeister added the enhancement An enhancement or new feature for an existing add-on label Oct 4, 2020
@Hilbrand
Copy link
Member

Hilbrand commented Oct 6, 2020

Can you also address the comments in #8361 that are shown under 8 hidden conversations. Also note that in this pr are hidden conversations.

@fwolter
Copy link
Member

fwolter commented Jan 13, 2021

@pasbi What is the status of this PR?

@pasbi
Copy link
Author

pasbi commented Jan 16, 2021

Sorry -- I'm totally confused right now. Please be patient with me.

That confusion comes from two points:

  1. The automatic conversion from 2.5.x to 3.x (maybe this is easy, but for me it's intransparent)
  2. The fact that the original PR [DLinkSmartHome] add DSP-W215 Smart Plug #8361 was kind of rejected (reason: new code does not integrate well into the old one).

So my proposal was to close this PR and start over again with the approach proposed in #8361 :

  1. refactor existing code
  2. add the new device properly

I'm willing to do that, but I need some advice from the code owner @MikeJMajor to refactor.

please also see #8361 (comment)

Edit: I've now updated my IDE and looked through the existing code, Everything is ready to start.
Before I start to refactor, I'd like to chat with @MikeJMajor to agree on the changes.

@fwolter
Copy link
Member

fwolter commented Jan 16, 2021

I'm not quite sure what you are confused about. You already managed to migrate the code from 2.5 to 3.x. Next step would be to incorporate the review feedback, I gave in this PR.

Maybe you could ask a concrete question, that @MikeJMajor or anybody else can answer?

@openhab-bot
Copy link
Collaborator

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/developing-a-binding-for-dlink-plugs/24122/69

@pasbi
Copy link
Author

pasbi commented Feb 3, 2021

I'm planning to continue working on this PR, but I'm quite busy atm, unfortunately. If others want to contribute, go ahead 😄

@Skinah Skinah added the work in progress A PR that is not yet ready to be merged label Jun 15, 2021
@fwolter fwolter added the stale As soon as a PR is marked stale, it can be removed 6 months later. label Dec 11, 2021
@wborn
Copy link
Member

wborn commented Mar 7, 2022

Feel free to reopen this PR when you continue working on it.

@wborn wborn closed this Mar 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting feedback enhancement An enhancement or new feature for an existing add-on stale As soon as a PR is marked stale, it can be removed 6 months later. work in progress A PR that is not yet ready to be merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants