-
Notifications
You must be signed in to change notification settings - Fork 96
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
Add a max brightness field for each dimmer in config file #149 #200
Conversation
This reverts commit 52c2b14.
6663a12
to
b402d9c
Compare
To test this: Please make sure you have a local installation of homebridge. Thank you for your work on this! It is much appreciated. |
Please also make sure to implement the |
} else if (data?.brightness && data?.max_brightness) { | ||
stateValue = Math.round( | ||
(Number(data.brightness) / data.max_brightness) * 100 | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
data?.max_brightness
will not be defined in case the user does not enter device defaults information.
Please use the old value (255) as the default value In this case.
} else if (data?.brightness && data?.max_brightness) { | |
stateValue = Math.round( | |
(Number(data.brightness) / data.max_brightness) * 100 | |
); | |
} else if (data?.brightness) { | |
const max_brightness = data?.max_brightness ?? 255 | |
stateValue = Math.round( | |
(Number(data.brightness) / max_brightness) * 100 | |
); |
This will use 255 as fallback incase the max_brightness
is not set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I set the default value for max brightness to be 255 in the config file, then I read that value weather its provided or not, good enough? (check out latests commit)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe you only set the "default" value in the ui config. This has nothing to do with the actual config file. Just when users use config-ui-x. Furthermore they can still remove the default value, making it undefined. Or not add the device config at all. Therefor I believe the proposed changes are still necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
data?.max_brightness is null for me, before the change I read the value from the config file, where is the connection between data.max_brightness and config.max_brightness should be set?
This is a great start! Please see some of my feedback, some of which I didn't catch the first time - sorry for that. |
@milo526 I noticed there is another bug, at some point we stop receiving the real value from the accessory numeric scale (0...255) for example, and moving to (0...100) both for update value in HomeKit and reading values from Tuya app. |
That is due to the caching we provide here: https://github.com/milo526/homebridge-tuya-web/blob/master/src/accessories/characteristics/brightness.ts#L44-L47 Whenever we set the value in HomeKit (through the slider or through fetching data from the API) we cache the last known value. This value is always on the scale from 0 to 100. The characteristic should probably be used to convert the 0...100 scale to 0 to |
@milo526 what are those magic numbers ? |
So this maps the homeKitValue (range 0 - 100) to a range 10 - 100 since Tuya brightness value < 10 will just turn the bulb off in my experience. |
@milo526 Yes why not?, this is a very annoying issue data?.max_brightness is null for me, before the change I read the value from the config file, where is the connection between data.max_brightness and config.max_brightness should be set? |
src/accessories/DimmerAccessory.ts
Outdated
validateConfigOverwrites(config: TuyaDeviceDefaults): string[] { | ||
const errors = super.validateConfigOverwrites(config); | ||
if (config?.max_brightness) { | ||
const maxBrigthness = config.max_brightness; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are missing a cast to number here.
Most config variables are or can be strings, so we need to use
const maxBrightness = Number(config.max_brightness)
That also explains why we write it back.
src/accessories/LightAccessory.ts
Outdated
validateConfigOverwrites(config: TuyaDeviceDefaults): string[] { | ||
const errors = super.validateConfigOverwrites(config); | ||
if (config?.max_brightness) { | ||
const maxBrigthness = config.max_brightness; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also cast to number (and there is a small typo should be maxBrightness
)
@@ -63,7 +63,8 @@ export class BrightnessCharacteristic extends TuyaWebCharacteristic { | |||
) { | |||
stateValue = Number(data.color.brightness); | |||
} else if (data?.brightness) { | |||
stateValue = Math.round((Number(data.brightness) / 255) * 100); | |||
const max_brightness = data?.max_brightness ?? 255; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
max_brightness
should be defined as a getter property on the accessory. It is not part of the data.
Please take a look at the currentTemperatureFactor
method in the TemperatureSensorAccessory
.
No, please see the what @bamodio said in #149 Your suggestion would still have this problem in place
See my comment on the MR, you should get this value from the accessory device config, not from the data. |
So we can assume we should support 2 types of ranges |
I don't necessarily think so since I seem to vaguely remember that there are also (1,100) ranges. |
Ok so final solution: thats it? |
Sounds good! |
@milo526 Upon working on the minimum value I came a cross an odd behaiover:
I printed the 1% and 100% of the device and got those results, it gets weird if I set the value in Homekit for example 62% and I take the minimum as 10 then Tuya app reads it correctly 62% perfect even weirder is that checking in the automation rules in the Tuya app the range is 25-1000 |
@bamodio @milo526 Great news ! only 1 issue remains maybe you can assist, the decimal number sometimes can differ in some cases resulting in accuracy of 1-/+ , I noticed that values above 40 % are correct exactly where less then that we might see a 1% different Still with all of this its already a big leap in solving this once and for all, give it a test and lets roll out? |
src/accessories/LightAccessory.ts
Outdated
@@ -11,6 +11,7 @@ import { | |||
} from "./characteristics"; | |||
import { ColorAccessory } from "./ColorAccessory"; | |||
import { TuyaDevice } from "../api/response"; | |||
import { TuyaDeviceDefaults } from "../config"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are some warnings here, could you please take a look at those.
const value = Math.round( | ||
(100 - correctionFactor) * dimmerPercentage + | ||
correctionFactor + | ||
Number.EPSILON |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you opt to add the Number.EPSILON
here (and a few lines later)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The decimal number is very large, I wanted to be sure as much as possible the round will be correct
Thank you for your work once more. |
@milo526 So any news? |
I tested this a bit... There's still errors, and I believe they are related to the caching of values, and the mismatch of ranges... Here's a description and log sample...
Is this coming from the cache somehow? Is there a disparity of using/caching homekitValue vs the remote value? This is not working yet, sorry guys. @milo526 ? |
@bamodio You are correct I have stated before that @milo526 has a problem with caching. |
Please show me where the caching mechanism is wrong in the current plugin. |
@milo526 The scenario is:
|
Hey, I made some time to look at this today but there seems to be some merge conflicts. Could you please enable the Allow edits from maintainers option. |
@milo526 Its enabled, didn't touch it |
Sadly GitHub will not allow me to push any changes at this time. |
@milo526 I have sent you an invite to be a collaborator in my master branch, accept it and try again |
@milo526 You gave up? |
👍 Yeah that is exactly what I did, I did not spend any time on this at all, I have all the time in the world to work on this and have no other obligations. I'll fix this myself when I have the time. |
@milo526 Lol, did not expect that. |
Please feel free to release your own branch as a separate plugin! |
Hi milo I am not sure how can I test it and debug it, I am using VSC, if you could share with me this knowledge I will test and finish this feature fix.
like we discussed I added a new field in config file, first I touch type script language so I hope I added it in the right places