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

Further research on last 17 bits #3

Open
drphungky opened this issue Jan 20, 2021 · 3 comments
Open

Further research on last 17 bits #3

drphungky opened this issue Jan 20, 2021 · 3 comments

Comments

@drphungky
Copy link

I have a BY-305 remote, also for Bofu motors, that I have also worked on decoding. These came from blinds.com in the US, which appears to be a reseller of Comfortex blinds out of NY, which is using Bofu roller motors on their internals. I had a LOT of data - each individual channel and command, but couldn't make heads or tails of it. Your findings that it was a tribit was a HUGE help and pushed me over the hump. I have now independently confirmed that for the BY-305 remotes the first 16 appears to be a RemoteID, 17-20 is channel, and 21-24 is command. My values also match your values (e.g. channel 1 is 1000, etc).

However, my positions 25-32 do not appear to be static remote identifiers like yours. My values for 25-28 are 0000 on up or down commands, and 1000 on stop, limit, confirm, and limit confirm combo. 29-32 is 1000 on confirm and for the first move (down or up) message in a tap command. On my remote, if you hold the button down, the first messages (8 linked 41 bit commands with the AGC) are as normal, but the second message has two bits changed - 29-32 becomes 0000, the same as confirm and other commands, and the last 4 digits change in various ways. I'm not sure how to share a spreadsheet on github since I'm new to this, but I have everything mapped out for my controller. We may be able to solve the checksums, as I've definitely figured that 33-36 is a function of channel (17-20) and 25-28, and 37-40 is a function of channel and tap or hold. The last bit appears to always be 1.

So my findings could be different because it's a different remote and slightly different protocol, or we just may be closer to deciphering the actual check bits. Because the BY-305 is a 6 channel (they call it 6 with only 5 channels and "all"), I tried to spoof a new remote to try to get my 13 blinds on individual channels. Unfortunately, as soon as I changed the remote id, nothing worked. Because I've been working on this off and on for months, and my wife is fed up with the blinds not being in google home, I just ordered 3 different remotes to test out more patterns, and then I plan to return them. Once I have more protocols to share, maybe some enterprising puzzle solver will be able to take a better crack at the checksums! I will keep you updated.

@akirjavainen
Copy link
Owner

There seems to be a lot of variation with this protocol between different brands. Some care about the checksum, some not. Timings vary quite a bit, too. As for cracking the checksum, the issue @vonnieda posted on my A-OK repo might give you ideas: akirjavainen/A-OK#1

I've gotten e-mails from several people who are trying to crack the Markisol checksum, but (so far) with no success (including myself). I regret that at the moment work is keeping me too busy to "hack around" with home automation, but hope to get back to it soon.

I've connected my Bofu motors to Alexa via IFTTT Webhooks (and a Raspberry Pi) so that's something you could take a look at to get your blinds working with Google Home.

@thepudding
Copy link

hey @drphungky not sure if you ever got the checksum figured out, but I also have bofu branded rollers with BY-301/5 remotes, and for mine the checksum is a one byte sum complement, but it adds to 1 instead of zero.

It was a bit confusing because the bit order needed to be reversed.

I intended to submit a pull request with the checksum implementation, but scope creep got the better of me and I ended up doing a full refactor 😅

in any case this is what I ended up with for the checksum calculation:

  uint8_t Message::calculateChecksum(uint32_t message){
    uint8_t sum = 0;
    for(int i = 0; i < 32; i += 8) {
      sum += (message >> i) & 0xFF;
    }
    return 1 - sum;
  }

@drphungky
Copy link
Author

I never did - I just ordered a bunch of remotes and found it was helpful to have them mounted around the house anyway, so my home assistant just has individual messages for each blind copied from various remotes. I will definitely try this later though, as it seems very useful for custom groups (e.g. blinds in this room, upstairs blinds, etc).

In any event, awesome job cracking the code!

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