[FHZ] Re: Homematic

[rudolfkoenig]

Originally posted by: <email address deleted>

Hi,

Sven Geggus:
> Weiterhin fehlen auch die Quellen für eine Reihe von Userland
> Applikationen. AFAIK kann qemu Linux binaries von anderen Plattformen
> aber nativ ausführen. D.h. man könnte da zumindest mal mit strace ran.
>
Ja, schon, aber die Hardware kann qemu natürlich nicht abbilden.
Die müsste man darin irgendwie simulieren, oder Zugriff auf die
"richtige" Hardware durchreichen.

Mich würden für den Anfang eher die Protokoll-Grundlagen interessieren.

Sind die Funkmodule denn immer noch FS20-kompatibel (d.h. 868.35 MHz,
an/aus-Modulation), oder haben sich die Entwickler was Sinnvolleres
überlegt? (Verschlüsselung etc. braucht eigentlich mehr Bandbreite, als
mit dem alten Protokoll möglich ist ... und heutzutage gibt es bessere
Verfahren, gerade zu em Preis.)

--
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
I do not know how it is with you, but for myself I generally give up at the
outset. The simplest problems which come up from day to day seem to me quite
unanswerable as soon as I try to get below the surface.
               -- Justice Learned Hand

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Matthias Urlichs wrote:
> Hi,
>
> Sven Geggus:
>  
>> Weiterhin fehlen auch die Quellen für eine Reihe von Userland
>> Applikationen. AFAIK kann qemu Linux binaries von anderen Plattformen
>> aber nativ ausführen. D.h. man könnte da zumindest mal mit strace ran.
>>
>>    
> Ja, schon, aber die Hardware kann qemu natürlich nicht abbilden.
> Die müsste man darin irgendwie simulieren, oder Zugriff auf die
> "richtige" Hardware durchreichen.
>
> Mich würden für den Anfang eher die Protokoll-Grundlagen interessieren.
>
> Sind die Funkmodule denn immer noch FS20-kompatibel (d.h. 868.35 MHz,
> an/aus-Modulation), oder haben sich die Entwickler was Sinnvolleres
> überlegt? (Verschlüsselung etc. braucht eigentlich mehr Bandbreite, als
> mit dem alten Protokoll möglich ist ... und heutzutage gibt es bessere
> Verfahren, gerade zu em Preis.)
>
>  
Guys, i am realy willing to help and contribute, but i cant read much
german....

anyway, homematic uses a CC1100 FM transceiver. so its in no way
compatible with FS20.
i have packetsniffed the data between the micro controller and the
tranceiver of the 4-ch relai module, but its gonna be VERY complicated
to reverse-engineer the protocol. Just a simple click of a button
produces 12 bytes and all of them are completely different every time
you press the same button. that does not include a acknowledge which is
send for every command and does not include the encryption either.

Other detail: i opened my CCU (of course hehe) and they did make room
for a FS20 compatible transmitter and receiver, but its not installed.

Remco

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Hi,

Remco:
> Guys, i am realy willing to help and contribute, but i cant read much
> german....
>
Sorry about that.

> anyway, homematic uses a CC1100 FM transceiver. so its in no way
> compatible with FS20.

Good.

> i have packetsniffed the data between the micro controller and the
> tranceiver of the 4-ch relai module, but its gonna be VERY complicated
> to reverse-engineer the protocol. Just a simple click of a button
> produces 12 bytes and all of them are completely different every time
> you press the same button.

Hmm. I find that somewhat hard to believe. Looking at the CC1100
documentation (http://www.ti.com/lit/gpn/cc1100), the first byte on the
SPI interface should be 0xFF (burst read of the receiver FIFO).

... unless they're using one of the compatibility modes to talk to the
CC1100. In any case, I'd look at the wires with a 'scope, to make sure
that the sniffed data is correct.

--
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Religions are like fireflies. They require darkness in order to shine.
      -- Arthur Schopenhauer

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Matthias Urlichs wrote:
> Hi,
>
> Remco:
>  
>> Guys, i am realy willing to help and contribute, but i cant read much
>> german....
>>
>>    
> Sorry about that.
>
>  
>> anyway, homematic uses a CC1100 FM transceiver. so its in no way
>> compatible with FS20.
>>    
>
> Good.
>
>  
>> i have packetsniffed the data between the micro controller and the
>> tranceiver of the 4-ch relai module, but its gonna be VERY complicated
>> to reverse-engineer the protocol. Just a simple click of a button
>> produces 12 bytes and all of them are completely different every time
>> you press the same button.
>>    
>
> Hmm. I find that somewhat hard to believe. Looking at the CC1100
> documentation (http://www.ti.com/lit/gpn/cc1100), the first byte on the
> SPI interface should be 0xFF (burst read of the receiver FIFO).
>
> ... unless they're using one of the compatibility modes to talk to the
> CC1100. In any case, I'd look at the wires with a 'scope, to make sure
> that the sniffed data is correct.
>
>  
Matthias, i used a logic analyser with SPI-decoding function, and
already removed the protocol bytes. there are 12 bytes over the air (2
of which are transmitted a bit later then the first 10. i think its
calculating the CRC in that time, but i could not match the first 10
bytes with the last 2 as crc with any common crc16 standard

Remco


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[Dr. Boris Neubert]

Originally posted by: <email address deleted>

Hi,
If they claim the sources are GPL, they simply HAVE to provide them, or they can (will?) get sued. There are similar cases where much larger companies had to oblige.
I don't remember the exact cases, but I remember that if they based their sw on GPL:ed works, they will have to comply. There are obviously open-software agencys looking out for such cases, and ready to take on the fight, if necessary. Maybe someone on this group can remember how to proceed?
/Pjotrek
P.S: I think Level-One and DLink were two of the cases. Most of their Linux sw is open now.

----------------------------------------
> Date: Sat, 19 Jan 2008 19:15:50 +0100
> From: remcohn@gmail.com
> To: FHZ1000-users-on-unix@googlegroups.com
> Subject: [FHZ] Re: Homematic
>
>
> Matthias Urlichs wrote:
>> Hi,
>>
>> Remco:
>>  
>>> Guys, i am realy willing to help and contribute, but i cant read much
>>> german....
>>>
>>>    
>> Sorry about that.
>>
>>  
>>> anyway, homematic uses a CC1100 FM transceiver. so its in no way
>>> compatible with FS20.
>>>    
>>
>> Good.
>>
>>  
>>> i have packetsniffed the data between the micro controller and the
>>> tranceiver of the 4-ch relai module, but its gonna be VERY complicated
>>> to reverse-engineer the protocol. Just a simple click of a button
>>> produces 12 bytes and all of them are completely different every time
>>> you press the same button.
>>>    
>>
>> Hmm. I find that somewhat hard to believe. Looking at the CC1100
>> documentation (http://www.ti.com/lit/gpn/cc1100), the first byte on the
>> SPI interface should be 0xFF (burst read of the receiver FIFO).
>>
>> ... unless they're using one of the compatibility modes to talk to the
>> CC1100. In any case, I'd look at the wires with a 'scope, to make sure
>> that the sniffed data is correct.
>>
>>  
> Matthias, i used a logic analyser with SPI-decoding function, and
> already removed the protocol bytes. there are 12 bytes over the air (2
> of which are transmitted a bit later then the first 10. i think its
> calculating the CRC in that time, but i could not match the first 10
> bytes with the last 2 as crc with any common crc16 standard
>
> Remco
>
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Peter Kling wrote:
> Hi,
> If they claim the sources are GPL, they simply HAVE to provide them, or they can (will?) get sued. There are similar cases where much larger companies had to oblige.
> I don't remember the exact cases, but I remember that if they based their sw on GPL:ed works, they will have to comply. There are obviously open-software agencys looking out for such cases, and ready to take on the fight, if necessary. Maybe someone on this group can remember how to proceed?
> /Pjotrek
> P.S: I think Level-One and DLink were two of the cases. Most of their Linux sw is open now.
>
>  
They DO provide sources for everything except:
1) theire own device drivers (wired, wireless, lcd and buttons)
2) theire own 4 device control deamons
3) the firmware for the external I/O controller

so they dont release anything usefull for us well, we could compile
our own linux for the device, but it wont be a homematic CCU anymore

remco

> ----------------------------------------
>  
>> Date: Sat, 19 Jan 2008 19:15:50 +0100
>> From: remcohn@gmail.com
>> To: FHZ1000-users-on-unix@googlegroups.com
>> Subject: [FHZ] Re: Homematic
>>
>>
>> Matthias Urlichs wrote:
>>    
>>> Hi,
>>>
>>> Remco:
>>>  
>>>      
>>>> Guys, i am realy willing to help and contribute, but i cant read much
>>>> german....
>>>>
>>>>    
>>>>        
>>> Sorry about that.
>>>
>>>  
>>>      
>>>> anyway, homematic uses a CC1100 FM transceiver. so its in no way
>>>> compatible with FS20.
>>>>    
>>>>        
>>> Good.
>>>
>>>  
>>>      
>>>> i have packetsniffed the data between the micro controller and the
>>>> tranceiver of the 4-ch relai module, but its gonna be VERY complicated
>>>> to reverse-engineer the protocol. Just a simple click of a button
>>>> produces 12 bytes and all of them are completely different every time
>>>> you press the same button.
>>>>    
>>>>        
>>> Hmm. I find that somewhat hard to believe. Looking at the CC1100
>>> documentation (http://www.ti.com/lit/gpn/cc1100), the first byte on the
>>> SPI interface should be 0xFF (burst read of the receiver FIFO).
>>>
>>> ... unless they're using one of the compatibility modes to talk to the
>>> CC1100. In any case, I'd look at the wires with a 'scope, to make sure
>>> that the sniffed data is correct.
>>>
>>>  
>>>      
>> Matthias, i used a logic analyser with SPI-decoding function, and
>> already removed the protocol bytes. there are 12 bytes over the air (2
>> of which are transmitted a bit later then the first 10. i think its
>> calculating the CRC in that time, but i could not match the first 10
>> bytes with the last 2 as crc with any common crc16 standard
>>
>> Remco
>>
>>
>>    
>
> >
>  


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[rudolfkoenig]

Originally posted by: <email address deleted>

Hi,

Remco:
>
> 1) their own device drivers (wired, wireless, lcd and buttons)

That's not allowed, because (a) the module info states that they're
licensed under the GPL, and (b) these modules are written specifically
for a Linux kernel and thus are required to be open source anyway.

> >> Matthias, i used a logic analyser with SPI-decoding function, and
> >> already removed the protocol bytes. there are 12 bytes over the air (2
> >> of which are transmitted a bit later then the first 10.

So you do see the initial 0xFF? Owch. Maybe they use the first byte (or
the first two, or the last two ...) as a key to scramble the rest of the
packet? In other words, if you generate enough packets to see identical
pre- or postfix byte(s), is the rest the same?

--
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Jacquin's Postulate:
No man's life, liberty or property are save when legislature is in session.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Matthias Urlichs wrote:
> Hi,
>
> Remco:
>  
>> 1) their own device drivers (wired, wireless, lcd and buttons)
>>    
>
> That's not allowed, because (a) the module info states that they're
> licensed under the GPL, and (b) these modules are written specifically
> for a Linux kernel and thus are required to be open source anyway.
>
>  
is that true? i mean, there are loads of modules written for the linux
kernel (graphics cards, vmware stuff) that is not GPL
>>>> Matthias, i used a logic analyser with SPI-decoding function, and
>>>> already removed the protocol bytes. there are 12 bytes over the air (2
>>>> of which are transmitted a bit later then the first 10.
>>>>        
>
> So you do see the initial 0xFF? Owch. Maybe they use the first byte (or
> the first two, or the last two ...) as a key to scramble the rest of the
> packet? In other words, if you generate enough packets to see identical
> pre- or postfix byte(s), is the rest the same?
>
>  
My next plan was to make a device with 2 SPI-inputs that is capable of
monitoring data flows in both directions, and a app on the pc to decode
them (strip the CC1100 commands).
but the problem is that they are using SPI at 2MHz so a simple micro
(apart from the fact that most dont have 2 spi interfaces), doesnt have
much time to process each byte. a 16MHz AVR would have only 9 clockticks
to process every byte!
i think its time to finaly learn VHDL, and put the whole thing (2x spi,
buffer and uart) in a FPGA

Remco

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[rudolfkoenig]

Originally posted by: <email address deleted>

Hi,

Remco:
> > That's not allowed, because (a) the module info states that they're
> > licensed under the GPL, and (b) these modules are written specifically
> > for a Linux kernel and thus are required to be open source anyway.
> >
> >  
> is that true? i mean, there are loads of modules written for the linux
> kernel (graphics cards, vmware stuff) that is not GPL

These typically use an open-source adapter module plus a closed-source
kernel that's (supposed to be) not specific to Linux, much less to one
exact Linux kernel.

Do they do that? If so, the module can at least be instrumented
(i.e. log what it does), if not disassembled.

Otherwise you won't even be able to rebuild their kernel with different
build parameters, much less upgrade it. That'd be really ugly.

Anyway, this is a moot problem because they *state* that they're
licensing the module code under the GPL, so they need to provide
source. Marking non-GPL modules as GPL licensed is not allowed,
regardless of any gray areas that are otherwise associated with
loadable modules and their licensing.

> but the problem is that they are using SPI at 2MHz

That's a lot.

If I were you, I'd use an Atmega with one built-in SPI for monitoring
the host side, and simply drive the transceiver side at lower speed in
software. :-P

> i think its time to finally learn VHDL, and put the whole thing (2x spi,
> buffer and uart) in a FPGA
>
Good luck!

--
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
"It runs like x, where x is something unsavory"
      -- Prof. Romas Aleliunas, CS 435

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-