Decoding the 433.92Mz LightwaveRF protocol

LightwaveRF Communi… > Forum > LightwaveRF Hackers > Decoding the 433.92…

LightwaveRF Community: Welcome Forums LightwaveRF Hackers Decoding the 433.92Mz LightwaveRF protocol

This topic contains 3 replies, has 3 voices, and was last updated by  Benjie 5 years, 3 months ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #4565
     Chris says:

    Chris
    Key Master

    Benjie Gillam (@benjie on twitter) has done some interesting work decoding the 433.92Mhz protocol used by LightwaveRF devices. This could lead to a number of home brew recipes for custom controllers and Wi-Fi link emulators based on Arduino and Raspberry Pi hardware amongst other things. Check out his blog post here:

    http://www.benjiegillam.com/2013/02/lightwaverf-rf-protocol/

    Chris Mills Founder and Editor - LightwaveRF Community http://cpmills.com/ http://lightwaverfcommunity.org.uk
    #4599
     Benjie says:

    Benjie
    Participant

    Hello everyone :)

    I’ve both received and sent 433MHz LightwaveRF data now – and more reliably than my RFXCOM to boot!

    I plan to make a cheap generic 433MHz RF transceiver capable of talking to many different things, and do the decoding in software on the computer. There’s no reason that you can’t embed the LightwaveRF encoding/decoding on an embedded chip though if you prefer.

    If you want more details just let me know what parts you’d like me to expand upon – I’m planning on writing a post about building your own transceiver using an Arduino and 433MHz radio receiver/transmitter. The wiring is insanely simple.

    #4668
     brownjl says:

    brownjl
    Participant

    :-) I wish you had published this just two weeks ago.. I’ve also decoded the protocol, but took a slightly different approach..

    I ignored high pulses and just looked at the timing of low’s. A short low is considered as a wire bit 1 and long as a wire bit 0. I see 72 bits per transmission with a single short bit (1) at the start and end of the packet for framing leaving 70 bits. I then found that there was 10 sets of 7 bits with each of these groups of 7 bits representing a nibble. So;

    Wire 7bits = 4 data bits

    0x7A:   0×00

    0×76:   0×01

    0×75:   0×02

    0×73:   0×03

    0x6E:   0×04

    0x6D:   0×05

    0x6B:   0×06

    0x5E:   0×07

    0x5D:   0×08

    0x5B:   0×09

    0×57:   0x0A

    0x3E:   0x0B

    0x3D:   0x0C

    0x3B:   0x0D

    0×37:   0x0E

    0x2F:   0x0F

     

    I believed they encode 7 bits to 4 so every nibble has exactly the same number of 0/1′s when transmitted so all packets regardless of content will take the same transmission time. I then found that the packet had the following framing:

     

    2 nibbles = 1 byte which I just called data!

    1 nibble = unit number

    1 nibble = cmd

    6 nibble = 3 byte id/address

     

    I found that there was 16 units –  with address F also being used as a broadcast too. I found the following commands;

     

    On    Unit:X CMD:0×01 DATA::0×00

    Off    Unit:X CMD:0×00 DATA::0×00

    Group oFFUnit:F CMD:00 DATA::0xC0

    MOOD1Unit:F CMD:0×2 DATA::0×82

    MOOD2Unit:F CMD:0×2 DATA::0×83

    MOOD3Unit:F CMD:0×2 DATA::0×84

    MOOD4Unit:F CMD:0×2 DATA::0×80

    MOOD5Unit:F CMD:0×2 DATA::0×81

    Lock Unit:XCMD:4 DATA::0×80

    UNLOCKUnit:XCMD:4 DATA::0×00

    All LockUNIT:x CMD:4 DATA::0x8F

    Close RelayUNIT:x CMD:7 DATA::0×00

    Open RelayUNIT:x CMD:4 DATA::0x1F

    Stop RelayUNIT:x CMD:4 DATA::0xC0

    Dim to Set LevelUNIT:XCMD:1 – LEVEL 1-31 = DATA::0×81-9F

     

    I found when an on is sent and the button is pressed the data value changes after a number of seconds of being pressed – I believe this is so the receiver can detect the long press and can start dimming until transmissions stop.

    I think this pretty much repeats everything you have done! Shame as I spent quite a few hours decoding this!

     

    James

     

    #4669
     Benjie says:

    Benjie
    Participant

    Great work, brownjl!

    I ignored high pulses and just looked at the timing of low’s. A short low is considered as a wire bit 1 and long as a wire bit 0. I see 72 bits per transmission with a single short bit (1) at the start and end of the packet for framing leaving 70 bits. I then found that there was 10 sets of 7 bits with each of these groups of 7 bits representing a nibble.

    I did something like this initially but felt that something was missing – the data didn’t look right to me. When I switched to encoding as “10″ and “1″ suddenly the data was a lot clearer – 10 groupings of 8 bits, each separated by a “1″ bit with extra starting and terminating “1″ bits – see the table toward the bottom of this post. It makes scanning the columns for changes much clearer. The 16 nibbles are just 16 of the 21 possible bytes which have exactly two “0″s in and the “0″s aren’t touching: https://gist.github.com/benjie/4698300 – I’m not sure why they picked the ones they did though.

    Our actual understanding of the commands comes out the same – which is great validation – and I’ll add your lock/close relay/open relay/stop relay commands to my list at some point, since I hadn’t got this far :) (I don’t have any relays… yet.)

    What does the lock functionality even do? I’ve never had success with it.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.

ABOUT Chris

Chris works as a techie for a large IT service provider. He is a geek at heart and loves nothing more than trying to automate his home. The problem is, his wife simply doesn't get it and can't understand why they can't have 'normal' lights like everyone else! Chris is dedicated therefore to implementing automation in a family friendly way.

View all posts by