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:
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.
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
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
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!
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.
You must be logged in to reply to this topic.