Homegear and SDR

English Forums Hardware
#1

Hi,

I’ve written a module [1] for GNU Radio that can receive, demodulate and decode messages sent with a CC1100 transceiver. I’ve tested them with a Homematic door/window sensor. Until now its only a receiver so I can’t transmit anything but a 10€ RTL-SDR dongle is all you need. Would it still be possible to connect this sensor to Homegear without actually transmitting anything, would pairing still be needed in some way? The GNU Radio module that I have simple pipes the payload of the received frames to a UDP socket. Would it be possible to have a UDP or TCP virtual physical device for Homegear to test it with?

Thanks
Andre

[1] github.com/andrepuschmann/gr-cc11xx

#2

Hey Andre,

the module won’t work with the current drivers, but it should be easily implemented. Adding the source code for a new TCP or serial device is done in a few minutes. Tell me a few specifics about the communication and I will implement it :wink:. It doesn’t matter, it doesn’t transmit anything. And only for sniffing, pairing is not needed. You can even add devices manually, then Homegear will even log the data, print variable information and send XML RPC events with the changed variables :wink:.

Cheers,

Sathya

#3

Hey Sathya,

thanks for the quick reply. Basically a simple UDP server listening on an port would be sufficient for me. My current module simply sends the received message as a array of bytes to a user definable port, i.e. Homegear in that case. From the packet description in [1] I see that the first byte (called byte 0 here) is the length byte. Is Homegear also expecting this byte? I am asking because the length byte is transmitted by the CC1100 but is not included in the actual payload.

Thanks
Andre

[1] homegear.eu/index.php/BidCo … nformation

#4

A UDP server would be a little more complicated, as I don’t have a template for it. Would a TCP client do, too?
If the length byte is needed or not depends on the driver. But I would transmit it to Homegear.

#5

Yeah, a TCP client should be fine too. I could then be the server. Here are two frames I captured from that sensor. The first is the length byte, then there are 12 payload bytes and two CRC bytes. So I would send the first 13 bytes then over the TCP socket?

Frame length (Bytes): 15
Payload length (Bytes): 12
0C 88 E0 FD C3 85 F2 CE AA 86 63 C2 4C 54 5B

SYNC FOUND!

Frame length (Bytes): 15
Payload length (Bytes): 12
0C 8B E3 FE C0 86 F1 CD A9 85 60 C0 84 88 BB

#6

ok, then it’s easy :wink:. I will post a version with the driver here later this evening. The first 13 bytes of the packet are ok - it doesn’t really matter, I only need to know what is received over the socket :wink:.

#7

ok, it’s on GitHub and the Raspberry Pi Debian package is compiling :wink:. Or do you need it for a different system?

#8

ok, here’s the Debian package.

Put this in physicalinterfaces.conf:

[HomeMaticBidCoS] devicetype = rtlsdrlan host = 192.168.1.123 port = 1234

I hope, it works :wink:. There are still a few issues with version 0.5.0 as I changed tons of code! But for sniffing everything should work fine.

Cheers,

Sathya

Edit: I just released Homegear 0.5.0-1 Testing and included the RTLSDR driver. See: https://www.homegear.eu/index.php/Downloads#Homegear_0.5.0-1_Testing