Flickering Issue #18
Comments
|
Instead of un-Whitening, what I was doing was to add Frida Script to log the actions from the ZhiHia App, |
|
The initial need is to obtain the (b, bArr, b2, bArr2) parameters passed to I do not have a rooted phone so I may not be able to launch your script. Would you please try to perform it on your side? A priori as the communication is unidirectional you do not need a lamp to test, in fact you just need the ZhiJia app on your phone, add a dummy lamp not paired and perform actions on it, and for each action capture the parameters sent to Here are the actions to be performed as per the problematic scenario given:
Thanks in advance ! |
|
Hello, Logs |
|
I do not see anything crazy here, or anything out of the ordinary, |
|
That is more or less what I was expecting indeed, but with slight changes:
This is globally what I guessed from the phone app software, except for the fact the software seems to always send 2 identical commands at the end of each change, and this might explain that some buggy lamps could wait for 2 identical changes... I think we could implement a custom light transition to replicate this behavior, should not be too difficult. I will try to do this today. |
|
I agree, but does not seem to explain the perceived brightness change on the colorchange, |
|
Well I totally agree a normal lamp coded by a smart developer should not react this way... My hypothesis is that the developer of the lamp have not tested each command independently, but only the global effect on the lamp when controlled with the phone app directly. The software of the lamp needs to keep the last brightness received somewhere in order to be able to keep it applied for the next color temperature transaction, but what if this software was not storing the last one received, but the previous one, as for example storing it at the beginning of the command handling, while the change of brightness was not processed by the lamp? The following would happen:
@cRazyK67, we would need your help (again) to test this hypothesis, I modified the Would you mind switch to If it still does not work, could you please add the following option to the light and re test? This would result in a behavior even closer to the one of the app, the last chance I would say... |
One other thing on your answer below, A Second think we could try is to use the scene button, as in those one you do not have this setBeganBrightness/setEndedBrightness combo |
Well there is a difference between the repetition of the exact same command by the loop and two different commands with the same parameters:
That is why I did the change on
Ah !!!! That could be interesting! I did not investigate this |
I will definitely test it. I have several esp boards, so I can test it without affecting the operation of my other chandeliers. But I won't be able to do it until tomorrow. |
LogsBut the broadcast seems to be much longer than what you describe, If I logged the correct function |
|
For the broadcast time, there are different things to consider:
I roughly described this behavior here in the ZhiJia part, with the link to the software For the sequence of actions:
@cRazyK67; another bunch of buttons (or custom service command if you prefer?) for testing, 'cmd: custom' and the following args, for a ZhiJia v2 light:
|
I think none of them are OK, and this is due to the Data extraction method, where getAdvDataX is called twice, we also see it with advData2 where I guess the counters are different BLERequest.sendMessage.overload('byte', '[B', 'byte', '[B').implementation = function (b, bArr, b2, bArr2) {
// Call the original method to get advData, advData1, and advData2
var advData = this.getAdvData(b, bArr);
var advData1 = this.getAdvData1(b2, bArr2);
var advData2 = this.getAdvData2(b2, bArr2);
// Log the input parameters
console.log(getCurrentTime() + ' - sendMessage - Inputs: b: ' + b + ', bArr: ' + byteArrayToHexString(bArr) + ', b2: ' + b2 + ', bArr2: ' + byteArrayToHexString(bArr2));
// Log the computed advData arrays
console.log(getCurrentTime() + ' - sendMessage - advData: ' + byteArrayToHexString(advData));
console.log(getCurrentTime() + ' - sendMessage - advData1: ' + byteArrayToHexString(advData1));
console.log(getCurrentTime() + ' - sendMessage - advData2: ' + byteArrayToHexString(advData2));
// Call the original sendMessage method
this.sendMessage(b, bArr, b2, bArr2);
};For the rest I agree with your analysis, it seems coherant, |
|
@NicoIIT, tested it 1.1. [168, 25, 25, 0, 0] => color: natural white, brightness: visually one step before minimum. If you set the brightness to 1% with the slider and press the button, the brightness becomes a little brighter (see log 1) 2.1. [167, 25, 25, 0, 0] => color: natural white , brightness: visually minimum With the first argument =167 all buttons lead to the same result, i.e. the brightness and color temperature arguments are ignored. my config: log 1 log 2 |
|
@cRazyK67 , I pushed a new version to |
|
@NicoIIT Results next: option "reverse" not include in my controller config. two lamp (bedside lamp) perfectly work without flickering to two other lamp (livingroom) not change color and brightness to Apparently the application sends 2 commands (0xAD(E) and 0xA8) at the same time. alternative_color_and_brightness_change: false (0xAD and 0xAE) |
|
@cRazyK67 , let's focus on the
I hardly understand this, may I ask you to test the 'scene' buttons with the phone app, meaning the shortcut buttons to put full cold / full warm and tell me if they work with those lamps? If they do not work it may explain...
You mean the Zhi Jia phone application? As per the logs we extracted previously with @14roiron this is not the case. If you mean our component ble_adv_controller this is not possible as per software: it is either one or the other, maybe a mix of logs? I am implementing the possibility to force the use of 2 separated commands AD/AE as previously, the default would be the use of the new A8 command. |
|
@NicoIIT this buttons works to all (four) my chandeliers
This works
Yes livingroom chandelier not respond to change color and brihtness/ |
|
@cRazyK67 : More and more strange... I will check the phone app software deeper in order to understand. I pushed the feature to choose which command to use, option 'separate_dim_cct' to be setup to true to use previous commands. |
|
@NicoIIT, In this configuration all my chandeliers work correctly, without flickering. |
|
The changes have been pushed to |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Concerning the flickering issue, the next steps to progress on this will be quite huge:
Given the amount of work, that the problem was already pre-existing and that the fix is not in the direct scope of this PR, I would recommend that we open a dedicated issue for this to track investigation progresses and resolution.
Sorry for not being able to solve this issue within the scope of this change 😢.
Originally posted by @NicoIIT in #17 (comment)
The text was updated successfully, but these errors were encountered: