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

[senechome] code cleanup and rename of battery state to system state #9535

Closed
wants to merge 3 commits into from
Closed

[senechome] code cleanup and rename of battery state to system state #9535

wants to merge 3 commits into from

Conversation

KorbinianP
Copy link
Contributor

@KorbinianP KorbinianP commented Dec 26, 2020

Hey,

While testing with OH3 I realized that the name "Battery State" is misleading. The State is of the whole PV system (Battery, Inverter, ...), so I renamed it to System State. This will lead to incompatibilities with older configs.

While reviewing the code I also found it quite ugly to have inside SenecHomeHandler:refreshState() function so much repeated code. I extracted it to a separate function and cleaned the refreshState() function. Saved about 40 lines of code for the same functionality and improved readability.

As usual please find here my self compiled jar for testing:
org.openhab.binding.senechome-3.1.0-SNAPSHOT.jar.zip

Cheers,

Korbinian

@@ -118,6 +118,13 @@ private void refresh() {
refreshCache.getValue();
}

private void updateChannelState(String channelConstant, org.openhab.core.types.State channelState) {
Copy link
Member

Choose a reason for hiding this comment

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

State should be added as import:

Suggested change
private void updateChannelState(String channelConstant, org.openhab.core.types.State channelState) {
private void updateChannelState(String channelConstant, State channelState) {

Comment on lines -141 to -145
if (channelConsumption != null) {
updateState(channelConsumption.getUID(),
new QuantityType<Power>(
getSenecValue(response.energy.homePowerConsumption).setScale(2, RoundingMode.HALF_UP),
Units.WATT));
Copy link
Member

Choose a reason for hiding this comment

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

I don't know if it's relevant. But what changed here is that the creation of the QuantityType instance is always done even if channelConsumption is null. I don't know if that could result in errors, which could happen if the value cannot be evaluated if channelConsumption is null and in case that dependency does exist.
If this is an actual problem you could pass the QuantityType as Consumer. Like: () -> new QuantityType(... and then in the method it can be called when the parameter is not null.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hey,
I don't see the problem that you mention in the code. The Data is passed by getSenecValue() from the Senec Device. So if the channel is null or not has no influence on the creation of the QuantityType, only the .getUID() will not work on a null Object.

I actually don't understand the check for null, how can a channel be null?

Cheers

Copy link
Contributor

@Skinah Skinah Oct 2, 2021

Choose a reason for hiding this comment

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

getThing().getChannel(
The above can return NULL if the channel does not exist. However you have removed the use of this and instead used a constant instead which I don't see the issue in doing it this way. The only thing to comment on is you can use an import and change it to...

updateChannelState(CHANNEL_SENEC_POWER_CONSUMPTION, new QuantityType<Power>(.............

If you did a find replace on SenecHomeBindingConstants. it would be a quick change to make.

Signed-off-by: Korbinian Probst <[email protected]>
Signed-off-by: Korbinian Probst <[email protected]>
Signed-off-by: Korbinian Probst <[email protected]>
@Skinah
Copy link
Contributor

Skinah commented Oct 2, 2021

@KorbinianP thank you for both this PR and for helping with the other PR here #10687
Can you reply what needs to happen to this PR, can it be closed as some/all changes are already merged in the above PR or does this still need to be reviewed? I triggered a rebuild and there are now conflicts with the above that will need to be addressed so where to from here?

@KorbinianP
Copy link
Contributor Author

Hey @Skinah, I think we can close this PR. Too much changed in #10679, and to be honest I forgot about this PR. Cheers

@KorbinianP KorbinianP closed this Oct 4, 2021
@KorbinianP KorbinianP deleted the improvement/senechome/cleanup branch October 4, 2021 06:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants