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

Bugfixes and new feature -- currently testing at home #40

Draft
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

jeffmaki
Copy link

Currently testing in my setup via my day-to-day usage. Feel free to join me? LMK if you have any thoughts/feedback?

Fix for #17: confirmed fixed for fahrenheit units, TBD for celsius
Fix for #9: duplicate of #17
Fix for #16: requires user to choose in Homebridge UI since HomeKit cannot support custom characteristics (e.g. a switch for this)
Fix for #18
Fix for #19
Plus, new feature: display filter cleaning status

Fix for sman591#17: confirmed fixed for fahrenheit units, TBD for celsius
Fix for sman591#9: duplicate of sman591#17
Fix for sman591#16: requires user to choose in Homebridge UI since HomeKit cannot support custom characteristics (e.g. a switch for this)
Fix for sman591#18
Fix for sman591#19
Plus, new feature: display filter cleaning status
Plus this file that should have been part of the last commit
@sman591
Copy link
Owner

sman591 commented Aug 15, 2020

Hey, thanks for contributing! Just glanced through everything and this looks reasonable. I'll try it out locally and give it a full review later -- feel free to convert to a full PR when you're ready.

For the future, please split up each "major" contribution into its own PR. This should be ok for now, but it helps chunk up the review to each relevant change and benefits from automated changelog/release tooling

Copy link
Owner

@sman591 sman591 left a comment

Choose a reason for hiding this comment

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

Tested locally, looking good! Thanks for tackling these

config.schema.json Outdated Show resolved Hide resolved
src/characteristic/abstractCharacteristic.ts Outdated Show resolved Hide resolved
src/characteristic/abstractCharacteristic.ts Outdated Show resolved Hide resolved
src/characteristic/abstractCharacteristic.ts Outdated Show resolved Hide resolved
this.device.updateCharacteristics(
v.newValue === this.characteristic.AUTO ? true : false,
this.platform.Characteristic.TargetHeaterCoolerState.UUID,
)
Copy link
Owner

Choose a reason for hiding this comment

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

This is a clever way to accomplish what we need, but given a "cached" snapshot can be stale, this could inadvertently revert previous changes made in the UI since the last update interval.

Open to discussing a solution here, but it might be best in a separate PR. It seems like this is only necessary because changing the lockTemperature value has implications on other characteristics; I wonder if we'd want some way to subscribe to changes that happen because of it, or mark characteristics as dependent on this flag?

Copy link
Author

Choose a reason for hiding this comment

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

Would marking them dependent on each other do something in the UI? This is the best I could find given the way the Home app UI works. Regardless of the way we tackle this engineering-wise, do you know if we can make the UI more sensical in this case?

Copy link
Owner

Choose a reason for hiding this comment

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

"Marking dependent" would be only an internal concept to this plugin; no native UI change. More as a way for characteristics to optionally subscribe to important changes such that we don't have to trigger a full cache-based refresh

Copy link
Author

Choose a reason for hiding this comment

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

Got it. Well, the "temperatureLocked" concept is trying to be that. So if we put aside the particular engineering approach to implement, how would you suggest we handle the UI if not a cache-based refresh?

handleSet?(value: CharacteristicValue, callback: CharacteristicSetCallback) {
if (this.device.lockTemperature) {
// updating from cache when we're locked puts things back to where they were, essentially preventing edits
this.device.updateCharacteristics(true)
Copy link
Owner

Choose a reason for hiding this comment

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

This could be a potentially stale snapshot. I'd prefer we ignore the request or augment the handleSet / callback usage for this characteristic alone

Copy link
Author

Choose a reason for hiding this comment

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

Okay, but then the user can change the temperature to something the AC won't accept, and the temperature will just revert back next refresh. Which could be 10 minutes from now. I didn't think that was great either...

Copy link
Owner

Choose a reason for hiding this comment

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

I sort of think of it as one action -> one failure (ignored input) being better than (potentially) one action -> stale UI due to cache -> in-sync UI moments later. It's unfortunate that HomeKit doesn't support this set of modes appropriately but I think it could be more confusing to flash the user with a stale UI for this one case

Copy link
Author

Choose a reason for hiding this comment

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

Got it. You should try disabling the "lockTemperature" flag and run the plugin to see what happens without it--it's not great. Basically you still get what you could be construed as a cached update: the temperature stays where the user set it, then snaps back to what the AC is actually at next refresh, potentially 10 minutes later. So my thinking here is that the user thinks they set the temperature to something preferable, then later realize the update didn't work. This would happen 100% of the time, whereas the cache being stale would be only when the connection between Thinq and the plugin is down, which I assumed was less than that. So TL;DR: this approach shows the correct state of the AC more often than any alternative.

I agree the real fix would be on the HomeKit side, but alas, can't find any fix there. Know anyone at Apple to ask what they would do in this case? Maybe there's something we don't know here...

src/characteristic/abstractCharacteristic.ts Show resolved Hide resolved
src/characteristic/abstractCharacteristic.ts Show resolved Hide resolved
src/platformAccessory.ts Outdated Show resolved Hide resolved
src/platformAccessory.ts Outdated Show resolved Hide resolved
src/platformAccessory.ts Outdated Show resolved Hide resolved
src/platformAccessory.ts Outdated Show resolved Hide resolved
try {
characteristic.handleUpdatedSnapshot(device.result.snapshot)
characteristic.handleUpdatedSnapshot(
<Unpacked<GetDeviceResponse['result']['snapshot']>>device,
Copy link
Owner

Choose a reason for hiding this comment

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

This is happening because let device = this.getDevice().snapshot is somehow returning unknown when it should be ... | unknown -- not sure why that is, but I've pasted a suggestion above that should resolve this

Comment on lines 115 to 117
characteristic.handleUpdatedSnapshot(
<Unpacked<GetDeviceResponse['result']['snapshot']>>device,
)
Copy link
Owner

Choose a reason for hiding this comment

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

Suggested change
characteristic.handleUpdatedSnapshot(
<Unpacked<GetDeviceResponse['result']['snapshot']>>device,
)
characteristic.handleUpdatedSnapshot(snapshot)

src/platform.ts Outdated Show resolved Hide resolved
src/characteristic/abstractCharacteristic.ts Outdated Show resolved Hide resolved
src/characteristic/abstractCharacteristic.ts Outdated Show resolved Hide resolved
@@ -134,4 +169,87 @@ export default abstract class AbstractCharacteristic<
...parameters,
)
}

deviceUsesFahrenheit(): boolean {
return this.device.getDevice().countryCode.startsWith('US')
Copy link
Owner

Choose a reason for hiding this comment

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

I'm a bit confused -- is this necessary? My understanding was both the LG and HomeKit APIs operate in Celsius, and it's just a matter of what HomeKit/LG display on screen that differs

Copy link
Author

Choose a reason for hiding this comment

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

Is it necessary? Can't say with units that display celsius. So this was my attempt to limit my changes to only Fahrenheit units, and if we find it's needed with celsius units, we can change. But somebody else would have to test that (someone who has a celsius unit)

*/
getHomeKitCelsiusForLGAPICelsius(_celsius: number): number {
if (!this.deviceUsesFahrenheit()) {
return _celsius
Copy link
Owner

Choose a reason for hiding this comment

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

Is there harm in always performing the conversion? I believe both Celsius and Fahrenheit users will see these discrepancies due to rounding differences, right?

Copy link
Author

Choose a reason for hiding this comment

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

See above

Comment on lines 148 to 151
callback(error)

// put UI back to where it was before
callback(error, this.cachedState)
Copy link
Owner

Choose a reason for hiding this comment

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

Could you merge this with line 148?

Suggested change
callback(error)
// put UI back to where it was before
callback(error, this.cachedState)
// put UI back to where it was before
callback(error, this.cachedState)

@bluefangs
Copy link

@jeffmaki - Is this something that is still WIP / ongoing testing?

@bluefangs
Copy link

I ran this branch to poke out differences. Noticed these in the logs.

[4/19/2021, 9:56:18 PM] [LgThinqAirConditioner] Error during interval update Error: connect ETIMEDOUT 13.124.239.180:46030
[4/19/2021, 9:56:23 PM] [LgThinqAirConditioner] Error during interval update Error: connect ETIMEDOUT 13.124.239.180:46030
[4/19/2021, 9:56:23 PM] [LgThinqAirConditioner] Error during interval update Error: connect ETIMEDOUT 13.124.239.180:46030
[4/19/2021, 9:56:31 PM] [LgThinqAirConditioner] Error during interval update Error: getaddrinfo ENOTFOUND kic-service.lgthinq.com
[4/19/2021, 9:56:32 PM] [LgThinqAirConditioner] Error during interval update Error: getaddrinfo ENOTFOUND kic-service.lgthinq.com
[4/19/2021, 9:56:33 PM] [LgThinqAirConditioner] Error during interval update Error: getaddrinfo ENOTFOUND kic-service.lgthinq.com
[4/19/2021, 9:56:33 PM] [LgThinqAirConditioner] Error during interval update Error: connect ETIMEDOUT 52.79.134.204:46030
[4/19/2021, 9:56:33 PM] [LgThinqAirConditioner] Error during interval update Error: connect ETIMEDOUT 52.79.134.204:46030
[4/19/2021, 9:56:34 PM] [LgThinqAirConditioner] Error during interval update Error: getaddrinfo ENOTFOUND kic-service.lgthinq.com
[4/19/2021, 9:56:36 PM] [LgThinqAirConditioner] Error during interval update Error: getaddrinfo ENOTFOUND kic-service.lgthinq.com
[4/19/2021, 9:56:37 PM] [LgThinqAirConditioner] Error during interval update Error: getaddrinfo ENOTFOUND kic-service.lgthinq.com
[4/19/2021, 9:56:38 PM] [LgThinqAirConditioner] Error during interval update Error: getaddrinfo ENOTFOUND kic-service.lgthinq.com

sman591 added a commit that referenced this pull request Apr 20, 2021
github-actions bot pushed a commit that referenced this pull request Apr 20, 2021
# [1.12.0](v1.11.0...v1.12.0) (2021-04-20)

### Features

* add filter life & condition (thanks [@jeffmaki](https://github.com/jeffmaki)!) ([6c94d0f](6c94d0f)), closes [#40](#40)
sman591 added a commit that referenced this pull request Apr 20, 2021
github-actions bot pushed a commit that referenced this pull request Apr 20, 2021
## [1.13.2](v1.13.1...v1.13.2) (2021-04-20)

### Bug Fixes

* emit status on Homebridge boot (thanks [@jeffmaki](https://github.com/jeffmaki)!) ([97bfbc5](97bfbc5)), closes [#40](#40) [#18](#18)
@jbyerline
Copy link

Any word on getting this merged? I have a LG AC with Eco-Mode and would love the addition? Any known bugs since its been a year? @jeffmaki @sman591

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.

4 participants