Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support info for implementing Fan coil Thermostat, Beok TGR87G-WIFI-AC2 #465

Open
ciafe opened this issue Oct 30, 2020 · 3 comments
Open

Comments

@ciafe
Copy link

ciafe commented Oct 30, 2020

Hi,

I have a Fan coil Thermostat, Beok TGR87G-WIFI-AC2, which is not supported by the library. Is there any plan to add support to this Broardlink Thermostat?

I debugged a little bit the library with my Thermostat and “devtype” reported is 0x4F5B. I can provide more debug information from the device, if needed! But I don't know what else should be checked, or done, to add support to it.

Thanks for your support!

@ciafe
Copy link
Author

ciafe commented Nov 3, 2020

Hi,

I'm trying to develope the support for this Thermostat, and currently using the Hysen climade device as a reference. I'm able to send requests with the send_request() and some are working, like set_power(), but most of the reading information, like get_full_status(), or get_temp() is readback but not valid (temps, times, ...).

I don't know where to get the information on how the response_payload is coded and structured in the frame. Is there any Broadlink documentation available? Could someone guide me on how to get the payload information codification, so I can implemented the decodification and usage in the library? How people does for other Broadlink devices?

Thanks a lot for the support!

@ciafe ciafe changed the title Library support for Fan coil Thermostat, Beok TGR87G-WIFI-AC2? Support info for implementing Fan coil Thermostat, Beok TGR87G-WIFI-AC2 Nov 3, 2020
@felipediel
Copy link
Collaborator

felipediel commented Nov 12, 2020

Hi there. Thanks for your dedication to this.

The official documentation serves us better to understand what they are doing than how they are doing it. There is no shortcut, you need to look at the bytes and try to understand what they mean.

One thing I usually do is to compare an old message with the new message to understand the changes. It usually doesn't change much. A pattern that I am seeing over and over: in the new devices the payload is being preceded by its length, example:

b'\x04\x00\x00\x00'

Becomes:

b'\x04\x00\x04\x00\x00\x00'

This is what happened to RM2/RM4 and SP4/SP4B, and it will continue to happen because this is how the new version of the protocol works. So that's where I would start looking.

@nortnil
Copy link

nortnil commented Jul 29, 2022

lockmode = (payload[3] & 0x0f);
lock = (payload[3] >> 4);
power = (payload[4] & 0x01);
valve = ((payload[4] >> 4) & 0x01);
controlMode = payload[5];//1:ventilate;2:cool;3:heat
windSpeed = payload[6];//1:low;2:middle;3:high;4:auto
pv = payload[7];
sv = payload[8];
dif = payload[9];
adj = (payload[10] > 127 ? -((256 - payload[10]) / 10) : payload[10] / 10);
sh1 = payload[11];
sl1 = payload[12];
sh2 = payload[13];
sl2 = payload[14];
fanMode = payload[15];
freMode = payload[16];
hour = payload[17];
minute = payload[18];
second = payload[19];
week = payload[20];
// payload[21];//reserve
loop = payload[22];
openHour1 = payload[23] & 0xff;//enable in bit7
openMinute1 = payload[24];
closeHour1 = payload[25] & 0xff;//enable in bit7
closeMinute1 = payload[26];
openHour2 = payload[27] & 0xff;//enable in bit7
openMinute2 = payload[28];
closeHour2 = payload[29] & 0xff;//enable in bit7
closeMinute2 = payload[30];

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants