Fix orvibo allone learn process and added flags:

[carlocontino]

• lastOperationSuccess (OrviboDevice)
• status (AllOne)

[tavalin]

Thanks for the PR. Could you give me a short description of the issue this PR is meant to address?

[carlocontino]

The problem is the length of the command received in learning mode with the orvibo allone.
The sdk give me an exception with message : "Invalid packet size. Discarding current buffer: ....".
I've noticed that the sdk does not accept the message learned because it is more bigger than expected, but in my tests the command learned arrived is correct. Probably the method "getExpectedLength()" of the class "PacketHandler" is wrong.
With my fix the command is stored if is equal or bigger than expected.
I've, also, added two flags:

• OrviboClient.lastOperationSuccess: return the status of the last operation
• AllOne.status: that can be: IDLE (ready for use), EMITTING (sending command), LEARN_INIT (initializing learning phase), LEARNING (waiting for command to learn).

I hope this explanation can be useful.

I've attached a zip with two sample commands (volume up and valume down of LG TV) that give me errors with master version.

P.S.: I think that PacketHandler::getExpectedLength() must be fixed, but I don't know how :-(

Regards
Carlo
commands.zip

[tavalin]

Could you send me the debug output when it says "Discarding packet size" including the hex string please. I think you might be right about getExpectedLength() not returning the correct result.

[carlocontino]

I've fixed the MAX_SIZE to 1024, 255 is not enough.
Here the command ("ok" button on sky remote control) hex and the message length:
Message length: 338
Invalid packet size. Discarding current buffer: 68 64 01 52 6C 73 AC CF 23 53 04 1E 20 20 20 20 20 20 01 00 00 00 00 02 38 01 00 00 00 00 38 01 00 00 00 00 00 00 00 00 28 01 CD 00 8C 04 D0 00 F3 02 D0 00 F4 0A D1 00 15 05 D1 00 14 05 D1 00 8B 04 D1 00 77 03 D0 00 A3 32 CE 00 05 04 CE 00 B0 06 CD 00 F5 02 CD 00 F5 02 CC 00 07 04 CB 00 A1 05 CA 00 F8 02 C9 00 F7 02 C7 00 FF FF 04 3F 01 00 A8 00 2B 04 A9 00 B3 04 A8 00 1B 03 A8 00 1B 0B A8 00 3D 05 A8 00 3D 05 A8 00 B3 04 B3 00 96 03 A8 00 CB 32 A8 00 3A 04 9A 00 1B 0B A8 00 5F 07 A9 00 19 03 A8 00 2B 04 A8 00 C4 05 A8 00 1A 03 A8 00 18 03 A8 00 FF FF 22 3F 01 00 A8 00 2B 04 A9 00 B3 04 A9 00 1A 03 A8 00 1B 0B A9 00 3D 05 A8 00 3D 05 A9 00 B3 04 A9 00 9F 03 A9 00 CC 32 AD 00 27 04 AD 00 17 0B AD 00 5A 07 AD 00 15 03 AD 00 26 04 C5 00 AB 05 AB 00 15 03 AE 00 12 03 AE 00 FF FF 22 3F 01 00 D0 00 04 04 D0 00 8B 04 D0 00 F2 02 D0 00 F3 0A D0 00 15 05 D0 00 15 05 D0 00 8B 04 D0 00 78 03 D0 00 A5 32 D0 00 03 04 D4 00 EF 0A D0 00 37 07 D0 00 F2 02 D0 00 03 04 D0 00 9C 05 D0 00 F2 02 D0 00 F0 02 D0 00 00 00

[tavalin]

Thanks for that. 255 for max size is indeed not enough. Theoretically it could be 65535 as the length bytes could go up to 0xFFFF. Could you try my length-fix branch, I can't promise everything is working but at least the packet parsing should work better now.

…

On Sat, 28 Jan 2017, 09:06 carlocontino, ***@***.***> wrote: I've fixed the MAX_SIZE to 1024, 255 is not enough. Here the command ("ok" button on sky remote control) hex and the message length: Message length: 338 Invalid packet size. Discarding current buffer: 68 64 01 52 6C 73 AC CF 23 53 04 1E 20 20 20 20 20 20 01 00 00 00 00 02 38 01 00 00 00 00 38 01 00 00 00 00 00 00 00 00 28 01 CD 00 8C 04 D0 00 F3 02 D0 00 F4 0A D1 00 15 05 D1 00 14 05 D1 00 8B 04 D1 00 77 03 D0 00 A3 32 CE 00 05 04 CE 00 B0 06 CD 00 F5 02 CD 00 F5 02 CC 00 07 04 CB 00 A1 05 CA 00 F8 02 C9 00 F7 02 C7 00 FF FF 04 3F 01 00 A8 00 2B 04 A9 00 B3 04 A8 00 1B 03 A8 00 1B 0B A8 00 3D 05 A8 00 3D 05 A8 00 B3 04 B3 00 96 03 A8 00 CB 32 A8 00 3A 04 9A 00 1B 0B A8 00 5F 07 A9 00 19 03 A8 00 2B 04 A8 00 C4 05 A8 00 1A 03 A8 00 18 03 A8 00 FF FF 22 3F 01 00 A8 00 2B 04 A9 00 B3 04 A9 00 1A 03 A8 00 1B 0B A9 00 3D 05 A8 00 3D 05 A9 00 B3 04 A9 00 9F 03 A9 00 CC 32 AD 00 27 04 AD 00 17 0B AD 00 5A 07 AD 00 15 03 AD 00 26 04 C5 00 AB 05 AB 00 15 03 AE 00 12 03 AE 00 FF FF 22 3F 01 00 D0 00 04 04 D0 00 8B 04 D0 00 F2 02 D0 00 F3 0A D0 00 15 05 D0 00 15 05 D0 00 8B 04 D0 00 78 03 D0 00 A5 32 D0 00 03 04 D4 00 EF 0A D0 00 37 07 D0 00 F2 02 D0 00 03 04 D0 00 9C 05 D0 00 F2 02 D0 00 F0 02 D0 00 00 00 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABsH_l9i5cZeZouewOWQ97SYMnfHoL7Cks5rWwUcgaJpZM4Lqz-f> .

[carlocontino]

Perfect, now it is ok. I'll use my branch with your correction, I need the two flags too.
👍

[tavalin]

That's good news - is everything else working regarding learn and emit? I don't have an AllOne to test myself.

I do plan to incorporate the functionality you've implemented with this PR, it would go well with my plans to implement retries if commands aren't acknowledged by the device.

[carlocontino]

Yes, ok in learn and emoticon! Inviato con AquaMail per Android http://www.aqua-mail.com In data 28 gennaio 2017 6:09:22 PM Daniel Walters <[email protected]> ha scritto:

…

That's good news - is everything else working regarding learn and emit? I don't have an AllOne to test myself. I do plan to incorporate the functionality you've implemented with this PR, it would go well with my plans to implement retries if commands aren't acknowledged by the device. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #17 (comment)