Smart cube fails to connect if already solved

[tautrimas]

trafficstars

Context:

• GAN 12ui freeplay
• newest or release online version of cstimer net. I am not sure if this ever happened with previous versions as I always started with scrambled state.
• macOS, both newest Chrome and Vivaldi browsers
• The issue appears only when trying to connect a solved cube. A single rotation before connecting will show a popup "Reset bluetooth cube as solved?" and the cube will be tracked normally.

Steps to reproduce:

1. Setup: connect the cube, make sure it's well synced and solved, 1 or 2 moves away from solved. 3 moves or more will make the cube connect as normal.
2. Disconnect the cube in any way including timing out
3. Click connect in bluetooth tool or refresh browser

What happens:

1. Partial bluetooth tool is displayed (image below)
2. UI/scramble state/virtual cube is unresponsive to cube rotations, but responsive to mouse/keyboard as usual
3. extra: if connecting with incorrect MAC decryption key, selecting another tool and getting back to bluetooth will show random battery charge level on every new rotation. However, actual virtual cube will stay solved or not displayed at all.
4. Moving onto the next scramble manually will update the bluetooth tool to show the correct battery charge.

What should happen:

1. app should track rotations

[afedotov]

Yep, I can confirm this, such weird behavior can be reproduced in the different way. Using even clear csTimer instance with default settings, i.e. when giiSolved equals to mathlib.SOLVED_FACELET:

1. Ensure that the cube is fully solved and its internal state equals to physical state.
2. White up, green front. Make simple sexy move on the cube - R U R' U'
3. Connect the cube to the csTimer, and observe mentioned behavior. No prompt to accept this state as solved will be shown.
4. Solve connected cube back with U R U' R', and after this bluetooth tool will be suddenly initialized.

Weirdest thing here is that not every initial cube state will cause the problem. If you basically rotate only U face (white) from solved state, the cube will be initialized properly. But if you rotate only R (red) face, this will cause the problem.

We need to investigate what change made caused the problem, and on which release this bug was introduced. Currently I'm AFK and can't properly debug this, can come back to this issue later. Meanwhile you can use the following workaround:

1. Physically solve the cube
2. Connect the cube to this application - https://afedotov.github.io/gan-cube-sample/
3. If state shown on virtual cube is not matching to physical state, press [Reset State] button.
4. Connect the cube to the csTimer, and if asked to reset cube as solved press OK.

Further if you need to synchronize physical and internal state of the cube, use mentioned application, or even this can be done with CubeStation.

[afedotov]

I've identified the commit after which the problem arise - ae3289c

After this changes something broke in the CubieCube.verify() function. It does not accept some valid states. Simple example to reproduce the problem:

var cc = new mathlib.CubieCube();
cc.fromFacelet('UUFUUFUUFRRRRRRRRRFFDFFDFFDDDBDDBDDBLLLLLLLLLUBBUBBUBB');
cc.verify()

@cs0x7f need your help to fix this.

[cs0x7f]

I've identified the commit after which the problem arise - ae3289c

After this changes something broke in the CubieCube.verify() function. It does not accept some valid states. Simple example to reproduce the problem:

var cc = new mathlib.CubieCube();
cc.fromFacelet('UUFUUFUUFRRRRRRRRRFFDFFDFFDDDBDDBDDBLLLLLLLLLUBBUBBUBB');
cc.verify()

@cs0x7f need your help to fix this.

Thank you for debugging. It's fixed in https://github.com/cs0x7f/cstimer/commit/11e601a62d0d2c5a7d7b26c1e4cce34e6c1119f3