mlfunston / node-red-contrib-broadlink-control

Set of node-red nodes to manage the Broadlink home automation device suite
MIT License
44 stars 24 forks source link

Broadlink Timeout Received #25

Closed luxarts closed 4 years ago

luxarts commented 4 years ago

Hello!

I have an RM3 Mini (firmware: v44057) connected to my local network. When I use the Discover node I get this:

{
  "mac": "24dfa77a4ff9",
  "ip": "192.168.0.101",
  "typeid": "5f36",
  "type": "RM Mini 3 newer",
}

I imported the "learn and send data" example and configured the device parameter with the MAC and IP address received. When I run the learn flow it send the message: Broadlink Timeout Received - Closing Device Connection after a few seconds. Doesn't matter if I send the IR stream with a remote or not, the output remains the same.

Can be a firmware problem?

The device works with the IHC app, read the same remote control button that I'm trying to learn in the node so I discard a decode or hardware problem. Maybe the API used to communicate to the device is dead?

Thanks!

deadly667 commented 4 years ago

I have the same problem. I think that it is because RM mini 3 version 5f36 needs different header. Maybe something like this (source python-broadlink https://github.com/home-assistant/core/issues/30215):

class rm4(rm):
    def __init__(self, host, mac, devtype):
        device.__init__(self, host, mac, devtype)
        self.type = "RM4"
        self._request_header = b'\x04\x00'
        self._code_sending_header = b'\xd0\x00' 

5f36 uses the same header like rm4

luxarts commented 4 years ago

I did some research the last night and found the same thing. This type ID (5f36) is also known as red beans, which are the newer version.

Here you can see the diff when this new type ID was fixed. Here is the header that @deadly667 was talking about.

Accordingly to the above fix, the payload bytes 0x24 and 0x25 should be changed to devicetype & 0xFF and devicetype >> 8 respectively (see this). The request_header should be 0x400and the code_sending_headershould be 0xD000.

Unfortunately I don't have the required time and knowledge with NodeJS to make the changes, test it and send the PR but I hope this info helps you.

Regards, Lucas

mlfunston commented 4 years ago

Thanks, that helps. I will look into it and do an update and you can test. I don't have any of the newer units to test against but had heard there were some new headers possibly needed.

deadly667 commented 4 years ago

I already started with adding headers. I have this new 5f36 so I can also test it. I cannot tell when it will be done because Im still working from home. Or maybe @mlfunston if you want I can help with testing if you have more time then me.

mlfunston commented 4 years ago

@deadly667 - If you have started something, send it through and I can probably finish it off in the next couple of days if you don't have time.

luxarts commented 4 years ago

I will test it, so don't worry.

Thanks both!

deadly667 commented 4 years ago

@mlfunston https://github.com/deadly667/node-red-contrib-broadlink-control

Do you want maybe PR?

Im still having some problems with saving RM node. Im maybe missing some config. I dont have experience in node-red development neither Im JS dev. So please if you thing that something is wrong change it. :)

And yes, I will also test it if you need help.

luxarts commented 4 years ago

@deadly667 Create a PR in your fork pointing to this repo.

Also, the changes in the payload bytes 0x24 and 0x25 should be conditioned by device type, otherwise, the older devices won't work.

if (this.type == 0x5f36) {
  packet[0x24] = this.type & 0xff;
  packet[0x25] = this.type >> 8;
} else {
  packet[0x24] = 0x2A;
  packet[0x25] = 0x27;
}
deadly667 commented 4 years ago

Created. https://github.com/mlfunston/node-red-contrib-broadlink-control/pull/26

I also answer in PR and we can continue there.

mlfunston commented 4 years ago

Thanks for your help @deadly667 - Have published the update as v2.0.0 due to the breaking change after upgrading. Need to manually add the device type to the older nodes after upgrade, but it all works ok with the default value.

thermseekr commented 4 years ago

Hello all,

I was very happy to have found these nodes, so thanks a lot to the developer and to everyone else helping with the development.

I have three RM Mini 3 units, the older one is firmware v57 and the two newer are firmware v44057. They all get discovered as type 2737:

0: object
   mac: "c8f742174b74"
   ip: "192.168.200.131"
   typeid: "2737"
   type: "RM Mini"
1: object
   mac: "24dfa736c1cc"
   ip: "192.168.200.133"
   typeid: "2737"
   type: "RM Mini"
2: object
   mac: "24dfa73658b8"
   ip: "192.168.200.132"
   typeid: "2737"
   type: "RM Mini"

When I run the Learn and Send learned code flows from the examples I also get the Broadlink Timeout Received - Closing Device Connection message after a few seconds. Do we need to add new headers for this type too?

Thanks, Tales