Large buffer array doesn´t work

[mondedos]

Hello,

From the Broadlink app, I can turn on and turn off the AC, however, when I capture the AC power on code and send it via the send command, nodered indicates ok status, yet the AC does nothing. I think there is a bug regarding the length of the code array, since I have tried with other devices that have shorter codes and it works.

Can you review the code and flow that I leave below?

I would appreciate some kind of response.

Thanks in advance and greetings

Long code not working

`var data = [38,0,6,1,107,53,13,15,13,14,14,39,14,14,13,41,12,14,14,14,13,14,14,40,13,40,13,14,14,14,13,14,14,39,14,40,13,14,14,14,13,17,13,15,13,14,14,13,13,14,14,13,14,14,14,13,14,13,14,13,14,14,13,40,14,13,13,15,12,15,13,14,14,13,14,14,13,14,13,40,14,14,13,14,14,13,14,13,14,41,13,40,13,41,13,41,13,40,13,41,13,41,13,40,13,14,13,15,13,40,13,14,13,15,14,13,14,13,14,13,14,14,14,13,14,13,14,40,13,40,13,14,14,14,14,39,13,15,13,14,13,14,14,13,14,13,14,14,14,40,13,40,13,14,14,13,13,15,14,13,13,14,14,13,14,14,13,14,14,13,14,40,13,14,14,13,14,13,14,13,14,14,14,13,14,13,14,13,14,14,13,14,14,13,14,13,14,14,14,13,14,13,14,13,14,14,13,14,13,14,14,13,14,14,13,14,14,13,14,13,13,14,14,14,13,14,13,14,14,13,14,14,13,14,14,13,14,13,13,14,14,40,13,14,14,14,13,14,14,39,13,15,13,40,13,14,14,40,13,14,13,15,14,0,13,5,13,5];

var msg = { payload: { "action" : 'send', "data" : data, "repeat":2 } };

return msg;`

My Flow

[ { "id": "e5666be2a6ebe39b", "type": "tab", "label": "Salón", "disabled": false, "info": "", "env": [] }, { "id": "09a580a88483f434", "type": "inject", "z": "e5666be2a6ebe39b", "name": "", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "payload": "", "payloadType": "date", "x": 240, "y": 120, "wires": [ [ "d7cd9c051fd5c1de" ] ] }, { "id": "d7cd9c051fd5c1de", "type": "function", "z": "e5666be2a6ebe39b", "name": "", "func": "var data = [38,0,6,1,107,53,13,15,13,14,14,39,14,14,13,41,12,14,14,14,13,14,14,40,13,40,13,14,14,14,13,14,14,39,14,40,13,14,14,14,13,17,13,15,13,14,14,13,13,14,14,13,14,14,14,13,14,13,14,13,14,14,13,40,14,13,13,15,12,15,13,14,14,13,14,14,13,14,13,40,14,14,13,14,14,13,14,13,14,41,13,40,13,41,13,41,13,40,13,41,13,41,13,40,13,14,13,15,13,40,13,14,13,15,14,13,14,13,14,13,14,14,14,13,14,13,14,40,13,40,13,14,14,14,14,39,13,15,13,14,13,14,14,13,14,13,14,14,14,40,13,40,13,14,14,13,13,15,14,13,13,14,14,13,14,14,13,14,14,13,14,40,13,14,14,13,14,13,14,13,14,14,14,13,14,13,14,13,14,14,13,14,14,13,14,13,14,14,14,13,14,13,14,13,14,14,13,14,13,14,14,13,14,14,13,14,14,13,14,13,13,14,14,14,13,14,13,14,14,13,14,14,13,14,14,13,14,13,13,14,14,40,13,14,14,14,13,14,14,39,13,15,13,40,13,14,14,40,13,14,13,15,14,0,13,5,13,5];\n//var data = [38,0,88,0,0,1,33,148,19,18,19,18,18,56,18,19,18,19,18,19,18,19,18,19,18,56,18,55,18,19,18,56,17,56,19,54,19,55,17,56,18,19,18,19,19,18,18,56,18,19,19,18,18,19,19,18,18,56,18,55,19,54,18,19,18,56,18,55,19,54,19,55,18,0,5,35,0,1,38,75,17,0,12,86,0,1,37,74,18,0,13,5,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];\nvar msg = { \n payload: {\n \"action\" : 'send',\n \"data\" : data,\n \"repeat\":2\n }\n};\n\nreturn msg;", "outputs": 1, "noerr": 0, "initialize": "", "finalize": "", "libs": [], "x": 460, "y": 160, "wires": [ [ "0c0c39bcd202b925", "6665408cb3f1e42e" ] ] }, { "id": "0c0c39bcd202b925", "type": "RM", "z": "e5666be2a6ebe39b", "name": "", "device": "147001dee0efa8f7", "action": "_msg_", "remote": "", "button": "", "fix": 1, "RFSweep": "false", "x": 650, "y": 160, "wires": [ [ "5bcdec6e23056e03" ] ] }, { "id": "6665408cb3f1e42e", "type": "debug", "z": "e5666be2a6ebe39b", "name": "", "active": false, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 590, "y": 60, "wires": [] }, { "id": "5bcdec6e23056e03", "type": "debug", "z": "e5666be2a6ebe39b", "name": "", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 830, "y": 160, "wires": [] }, { "id": "147001dee0efa8f7", "type": "rmdevice", "folder": "", "mac": "A043B0550E3A", "host": "10.0.2.133", "devType": "5f36" } ]

flows.zip .

[mondedos]

Hello,

I definitely confirm that it is a bug of this development. The problem is that it does not send long lR codes, neither in base 64 nor in array format.

I have performed the following test. I have two broadlink at home, the mini 3 and the mini 4 and I have tried the following scenarios.

Case 1 Code => [38,0,88,0,0,1,33,148,19,18,18,56,17,20,18,19,17,19,18,19,18,19,18,19, 19,55,19,18,18,56,17,56,19,55,19,55,18,19,18,55,19,55,19,55,18,19,18,19,18, 55,19,18,18,56,18,19,19,18,19,18,18,56,17,56,19,18,18,56,19,18,19,55,17,0, 5,62,0,1,38,74,19,0,12,82,0,1,39,73,18,0,13,5,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0]

I put the mini 3 in learning mode and send from the mini 4 a short frame, then the mini 3 receives the code correctly.

I put the mini 4 in learning mode and send from the mini 3 a short frame, then the mini 4 receives the code correctly.

case 2 Code =>

[38,0,6,1,103,54,13,14,13,14,13,40,14,14,13,40,14,13,14,14,13,14,14,40, 13,40,14,13,14,14,13,14,13,40,14,40,14,14,13,14,13,17,14,14,13,14,13,14,13, 14,14,13,14,14,13,14,13,14,14,13,14,14,13,40,14,13,14,14,13,14,14,13,14,13, 14,14,13,14,13,40,14,14,13,14,13,14,13,15,13,41,13,40,14,40,14,40,13,40,14, 40,13,41,13,40,14,14,13,14,13,41,13,14,13,14,13,14,13,15,13,14,13,14,13,14, 13,14,14,40,13,40,14,14,13,14,13,41,13,14,13,14,13,14,14,13,14,14,13,14,13, 41,13,40,14,13,14,14,13,14,13,14,13,14,14,13,14,14,13,14,13,14,14,40,13,14, 13,14,14,13,14,14,13,14,14,13,14,13,14,14,13,14,13,14,13,14,14,13,14,14,13, 14,13,14,14,13,14,14,13,14,13,14,13,14,14,14,13,14,13,14,13,14,14,14,13,14, 15,12,13,14,14,14,13,14,13,14,13,14,14,13,14,14,13,40,14,13,14,14,13,14,13, 41,13,14,13,40,14,14,13,40,15,12,14,14,13,0,13,5,13,5]

I put the mini 3 in learning mode and send from the mini 4 a long frame, then the mini 3 does not receive the code.

I put the mini 4 in learning mode and send from the mini 3 a long frame, then the mini 4 does not receive the code.

Therefore, I interpret that it is not a problem with the mini 3 or the mini 4 because from the broadlink application I can turn on the devices that have a long code. In this case it is clear that it is a bug of this development.

Please could you find out the problem and correct it?

Thank you

[mondedos]

After reviewing the code, I think the problem may be focused on the following function of the Device.js class

sendPacket(command, payload) { this.count = (this.count + 1) & 0xffff; var packet = Buffer.alloc(0x38, 0); //Is it possible to increase the buffer? packet[0x00] = 0x5a;

I don't know if it is possible or not to increase the buffer.

var packet = Buffer.alloc(0x38, 0); //Is it possible to increase the buffer?

I don't know how I could test this modification because I don't know how to program in this language, nor do I know how to set up a test project to verify what I say. But I understand that the length of the buffer could be calculated based on the IR code that is being sent to it.

Please, we need it corrected.

Thanks in advance.

[BertBloemen]

Hi,

I think I had the same issue. I had a look at the example codes that come with the package, and I noticed that they all ended on: "....,0,13,5,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]"

In my (recorded) codes, the end was always .....,0,13,5,13,5]

So I took my chances and replaced the "0,13,5,13,5" with "0,13,5,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0" and boomshakalaka there was the long awaited beep from my airco!

I hope it helps in your case as well! Cheers, Bert

[mondedos]

Hello BertBloemen, can you upload the change in the code so that we can update everyone and explain how to make said update?

Thank you

[BertBloemen]

Hi @mondedos , I didn't make any updates in the program code, I just change the IR codes that are recorded instead.

For example, change the following recorded blob:

[38,0,6,1,103,54,13,14,13,14,13,40,14,14,13,40,14,13,14,14,13,14,14,40, 13,40,14,13,14,14,13,14,13,40,14,40,14,14,13,14,13,17,14,14,13,14,13,14,13, 14,14,13,14,14,13,14,13,14,14,13,14,14,13,40,14,13,14,14,13,14,14,13,14,13, 14,14,13,14,13,40,14,14,13,14,13,14,13,15,13,41,13,40,14,40,14,40,13,40,14, 40,13,41,13,40,14,14,13,14,13,41,13,14,13,14,13,14,13,15,13,14,13,14,13,14, 13,14,14,40,13,40,14,14,13,14,13,41,13,14,13,14,13,14,14,13,14,14,13,14,13, 41,13,40,14,13,14,14,13,14,13,14,13,14,14,13,14,14,13,14,13,14,14,40,13,14, 13,14,14,13,14,14,13,14,14,13,14,13,14,14,13,14,13,14,13,14,14,13,14,14,13, 14,13,14,14,13,14,14,13,14,13,14,13,14,14,14,13,14,13,14,13,14,14,14,13,14, 15,12,13,14,14,14,13,14,13,14,13,14,14,13,14,14,13,40,14,13,14,14,13,14,13, 41,13,14,13,40,14,14,13,40,15,12,14,14,13,0,13,5,13,5]

to: [38,0,6,1,103,54,13,14,13,14,13,40,14,14,13,40,14,13,14,14,13,14,14,40, 13,40,14,13,14,14,13,14,13,40,14,40,14,14,13,14,13,17,14,14,13,14,13,14,13, 14,14,13,14,14,13,14,13,14,14,13,14,14,13,40,14,13,14,14,13,14,14,13,14,13, 14,14,13,14,13,40,14,14,13,14,13,14,13,15,13,41,13,40,14,40,14,40,13,40,14, 40,13,41,13,40,14,14,13,14,13,41,13,14,13,14,13,14,13,15,13,14,13,14,13,14, 13,14,14,40,13,40,14,14,13,14,13,41,13,14,13,14,13,14,14,13,14,14,13,14,13, 41,13,40,14,13,14,14,13,14,13,14,13,14,14,13,14,14,13,14,13,14,14,40,13,14, 13,14,14,13,14,14,13,14,14,13,14,13,14,14,13,14,13,14,13,14,14,13,14,14,13, 14,13,14,14,13,14,14,13,14,13,14,13,14,14,14,13,14,13,14,13,14,14,14,13,14, 15,12,13,14,14,14,13,14,13,14,13,14,14,13,14,14,13,40,14,13,14,14,13,14,13, 41,13,14,13,40,14,14,13,40,15,12,14,14,13,0,13,5,0,0,0,0,0,0,0,0,0,0,0,0]

and it will work. I have no idea why but it looks like a bug in the recorder function since all example codes have these 0s at the end.

It requires an easy manipulation of all recorded codes, one could fix this in the program code or create a function node for that but since I don't record new codes every day I guess I'll go with these manual updates for now.

Kind regards,