My next attempt when i get some time is to just capture a number of actions and rotate through them instead of trying to construct the new ones. If there’s no embedded counter, then I should be able to capture 3 of each button and enabled blinds combination and rotate through them (make sure the requests don’t repeat). If that works, then we could ignore the checksum part.
Although I hope that dumping the firmware from the hub would allow us to figure out exactly how the messages are constructed.
Yes - ignoring the checksum - that was based on a NRF sniffer.
I think payload sizes are too large for the NRF24 module I was using which seems to have a 32 byte limit in fixed payloads (later captures were approx the same size as your HackRF captures)
The protocol itself seems to allow 252 bytes in fixed size payloads. Sourcing a NRF52 dev board to see if that helps.
There’s a chance that these are actually two separate messages, both starting at 0xaa. Even if not, you could pretend they are by matching on sync 16f3
A small update. With the power of a SAT solver, I got some parts of the checksum figured out. Now I know that it’s CRC16 with a non-standard poly 0x0083. It’s independent of the remote. All transmissions finish on a final 1 bit, which is not part of the ending checksum. Not sure about the boundaries of the message and init value yet… Needs more playing around.
This is significant, because with a partial crc state from the middle of the message we can validate/generate the correct checksum without understanding the whole structure. Just writing more code to figure out the init value that would include the remote id.
That absolutely explains the behavior I’ve been seeing. I have ~10 shades in my house and some of them occasionally won’t open when I try to open all shades in the house. When I saw the taskID, I was hoping there was some kind of ACK that could be tracked by the taskID but kept coming up empty.
@keito on your integration, it might be nice for it to hit /NM/v1/status shortly after an action occurs, if the shade’s position doesn’t match what was originally requested, try resending.
More specifically (this includes the blinds/remote selector), the CRC for the last 64 bits is CRC16, poly=0x0083, init=0x5473, no reflections. Still not sure where the calculation starts… but getting closer.
Their marketing material refers to a rolling code - tying a brute force approach on the message id looks like the final 2 characters follow a set pattern
16 codes in sequence with the final character the same, and the 3rd character follows a repeating sequence within each of the 16 code blocks. Resulting in a repeating pattern every 256 codes.
The first 2 characters appear more random.
There doesn’t appear to be a consistent interval for the full 4 characters.
Given the devices have to sync the rolling code with a single message I’m suspecting that the first 2 characters are random - but that seems too simple.
