ist vielleicht etwas off-topic, aber evtl. könnte das doch schneller von Interesse werden als man denkt.
eq-3 hatte sich in der Vergangenheit ja schon den Unmut der Homematic-Käufer zugezogen, weil unangekündigt, ganze Produkte kurzfristig abgekündigt wurden (4-fach Wandtaster PEHA z.B.). eq-3 hatte ein Einsehen hatte diese dann ja nochmals für die Nachbesteller für kurze Zeit aufgelegt.
mal erst einmal die Produkte abwarten. Die offiziellen Gateways werden wir aber zumindest sehr wahrscheinlich unterstützen können. Ob’s dann noch ohne Weiteres mit freier Hardware geht ist natürlich fraglich - mal sehen .
ja. Die Geräte liegen schon einmal auf meinem Schreibtisch . Ich werd mir das zeitnah anschauen - bin selbst neugierig. Da ich gerade sehr viel zu tun habe, möchte ich aber keine Zeitvorhersage machen .
in den nächsten Wochen kommt das CCU2 Update, damit Homematic-IP Geräte mit der CCU2 (via BidCoS) quatschen können. Daher ist meine Frage ob demzufolge auch die Planung besteht das der Homegear (CC1101) eine kommunikation mit den neuen HM-IP Koponenten erlaubt??
über den CC1101 wird es wohl nicht gehen (selbst wenn es ginge, bekämen wir Ärger mit eQ-3). Aber es wird hoffentlich mit den offiziellen Modulen von eQ-3 gehen. Ich hatte bisher noch nicht die Zeit, mir das Protokoll genau anzusehen. Anfang nächsten Jahres komme ich hoffentlich dazu .
Ich bin mir nachwievor nicht ganz sicher, ob wir proprietäre Protokolle gegen den ausdrücklichen Willen der Hersteller implementieren dürfen (eQ-3 möchte ausdrücklich nicht, dass wir HomeMatic-IP auf physikalischer Ebene implementieren und hat uns auch bereits eine Klage angedroht, sollten wir dies tun). Wenn jemand hierzu etwas weiß, wäre ich für jede Information dankbar. Laut einem Rechtsanwalt, mit dem ich darüber gesprochen habe, wäre es aber problematisch. Das Thema HomeMatic BidCoS ist aber geklärt und für eQ-3 ist das Thema erledigt.
Ehrlich gesagt halte ich das für einen plumpen, völlig substanzlosen Einschüchterungsversuch. Reverse engineering ist völlig legal, und Software ist nicht patentierbar, erst recht nicht, wenn es eine reine Implementierung des Stands der Technik ist (was bei AES der Fall ist).
Bzgl. Reverse Engineering und Patenten gibt die Wikipedia einen recht guten Überblick über den Stand der Dinge (insbesondere in Deutschland, was ja für uns relevant ist). Diesbezüglich lassen sich aber auch immer wieder mal Aspekte aus der einschlägigen Presse entnehmen (z.B. Heise).
Darüber hinaus ist mir kein einziger Fall bekannt, wo jemand in Deutschland aufgrund Reverse Engineerings, Nachimplementierung von proprietären Protokollen oder „Knacken“ von Verschlüsselung belangt worden wäre, obwohl es da ausreichend Beispiele gibt (z.B. DECT, SMB, Mifare-Karten usw.). Da steckt auch in allen drei Beispielen wesentlich mehr Finanzkraft und Verbreitung hinter den Herstellern bzw. den Produkten.
Mal die Gegenfrage: was, ausser der Drohung des Herstellers, lässt euch denken, dass es hier ein rechtliches Problem geben könnte?
Was ich wissen möchte - alles natürlich… ich werde mir bei Gelegenheit die Informationen die Du referenzierst mal zusammenlesen.
Mir bekannte Fälle: das Geplänkel um den Adobe Verschlüsselungsalgorithmus “RC4” beispielsweise. Die Veröffentlichung wollten sie um jeden Preis verhindern (sehr wahrscheinlich war Ihnen zu peinlich was dabei dann rausgekommen ist). Oder der von Adobe verwendete PrivateKey für die Freischaltung der Lifecycle Features. Solche Firmen schreiben schnell einen Cease&Desist. Ich denke auch, dass sich viele weitere Fälle auflisten lassen, in denen solche Konflikte auftraten und allein die Energie die Du dafür aufwenden musst, selbst wenn es verpufft, ist enorm.
Und DU warst lange genug in dem riesigen Graubereich tätig um zu wissen was im Ernstfall für den Schädiger rauskommt? Urheberrechtsverletzung, Patentverletzung, Verrat von Firmengeheimnissen, keine Ahnung in was die Winkeladvokaten das alles verkleiden können?
Ich denke, dass nicht umsonst die meisten Klone in “rechtsfreien” Gebieten erstellt werden, wo dann vielleicht mal der eine oder andere im Zoll hängenbleibt (oder auf der Messe konfisziert wird!!). Welcher deutsche Hersteller beteiligt sich nochmal an dem lukrativen Geschäft um Mifare Klone? Richtig, keiner.
Was, ausser der Drohung des Herstellers brauchst Du, um Dich davon überzeugen zu lassen, dass es ein rechtliches Problem geben könnte? Warum sollte jemand wie Sathya ein Risiko eingehen, damit wir Lampen aus- und einschalten können?
Mal ganz abgesehen von einem anderen Standpunkt. Eine Firma entwickelt Hardware und ein Protokoll und baut darauf ein Geschäft auf. Ganz Wurst wie grottig die Hardware, das Protokoll und die Preise sind. Warum glaubst Du umgekehrt, dass WIR das uneingeschränkte Recht haben uns aus diesem Angebot herauszupicken was wir möchten. Rein philosophisch sozusagen…
Eine Möglichkeit, die vermutlich keine Probleme machen wird, ist die Implementierung der eQ-3-eigenen Funkmodule. Das werden wir also sehr wahrscheinlich machen. Alles darüber hinaus müssen wir auf jeden Fall vorher sicher klären.
Kurze Frage: Die neuen HM-IP Geräte sprechen ja auch BidCos. Ich überlege mir die Schalt und Messteckdose aus der HM-IP Serie zu holen (HMIP-PSM).
Könnte ich die mit meinem HM-CFG-USB2 und hmland mit aktuellem Homegear Build anlernen und ansteuern? Oder ist das zur Zeit nicht möglich (wegen des proprietären Protokolls)?
Meines Wissens sprechen die HM-IP-Geräte nicht BidCoS. Oder sind Direktverknüpfungen zwischen HomeMatic-IP- und HomeMatic-BidCoS-Geräten möglich? Falls letzteres der Fall ist, ließe sich die Anbindung an Homegear natürlich realisieren.
Ich hab gesehen, in der aktuellen CCU2 Firmware ist HM IP integriert. Wenn ich den aktuellen Homematic Lan Gateway verwende, sollte es doch theoretisch möglich sein ohne großen Aufwand HM IP in Homegear zu nutzen. Solange Sathya den Anlernvorgang implementiert
.
. Ich werd mir das zeitnah anschauen - bin selbst neugierig. Da ich gerade sehr viel zu tun habe, möchte ich aber keine Zeitvorhersage machen 