gibt es schon einen Plan, ob und wann die HomeMatic CCU von IPS unterstützt wird?
Informationen zur Ansteuerung der CCU von Außen gibt es ja inzwischen im FHZ-Forum, so dass es technisch keine grundsätzlichen Probleme mehr geben sollte.
Ich möchte ja nicht wählerisch klingen, aber das was dort vorgestellt wird ist leider nix für IPS.
Weil:
a) Die FW der CCU verändert werden muss (Garantieverlust!)
b) Das Protokoll damit immernoch nicht klar ist und das Beispiel nur zeigt, wie man eine Temperatur mitloggt.
Option B, die Homeputer verwendet, scheint nach den dort vorhandenen Informationen keine Rückmeldungen zu senden, was die Schnittstelle aus meiner Sicht vollständig disqualifiziert. (Ich will mal von der Tatsache absehen, dass die einen Standard verändert haben)
Die Firmware (=Linux) muss nicht verändert werden. Es muss lediglich ein Paket-Sniffer installiert werden, die die interne Kommunikation der CCU (über TCP-Ports mittels xmlrpc) abhört. Dies wurde bereits demonstriert. Zustandsänderungen werden damit sofort gemeldet.
Die Installation erfolgt über die Option „Zusatzprogramme“ der CCU. Die Garantie wird dadurch nicht verloren gehen, da die Zusatzprogramme durch einen Reset wieder verschwinden.
ich werde mir auch die Homematic CCU kaufen, aber in erster Linie wegen der HomeMatic Wandthermostate (habe da keine alternative gefunden auch bei xcomfort nicht!), und der möglichkeit der Stromzählerablesung.
Ich habe jetzt einmal das C#-Programm aus dem FHZ-Forum ausprobiert. Mit Hilfe des Programms ist es problemlos möglich, den Zustand von Aktoren abzufragen oder zu ändern.
Etwas Arbeit ist noch erforderlich, um das Protokoll der CCU zu studieren, das über Zustandsänderungen von Aktoren und Sensoren informiert. Das Abgreifen des Protokolls mit C# ist inzwischen problemlos möglich. Aus meiner Sicht ließe sich das Protokoll innerhalb kürzester Zeit anlaysieren, so dass dann der Integration in IPS nicht im Wege stehen würde.
Die Super-Simpel-Lösung wäre, im Kommunikationsprotokoll einfach nach einer Device-ID Ausschau zu halten und danach den Zustand abzufragen.
Wie bereits in meinem vorhergehenden Post erwähnt: Technische Probleme zur Anbindung von IPS an die CCU gibt es kaum noch. Allerdings kann ich nicht beurteilen ob es mit den Entwicklungswerkzeugen von IPS möglich ist, die CCU ähnlich wie mit C# über das Netzwerk anzusprechen.
Hallo, IPS Programmierer ? Sind das neue Infos für euch ?
Ich bin zwar nicht wirklich scharf auf diese CCU, aber ich ziehe in Sachen Preis/Leistung die Homematic Komponenten aktuell den anderen BiDi fähigen Funkkomponenten vor ! Würde mich also freuen wenn sich hier „reingehängt“ wird um eine Zusammenarbeit zu ermögliche. Ich denke das sehr viele Leute über FS20 an IPS gekommen sind und FS20 bzw. Homematic wird wahrscheinlich auch weiterhin das Einstiegsprodukt bleiben mit dem die Leute dann Lust auf mehr, sprich IPS bekommen !
mal einen ganz dezenten Hinweis: Die Analyse des Protokolls ist rechtlich nicht erlaubt. Das ist gleichzusetzen mit der Recompilation von Codeteilen, da das Protokoll integrierter Bestandteil der Software ist. Solange also ELV das Protokoll nicht offiziell herausgibt, um dann eigenen Anwendungen / Anbindungen zu realisieren oder Herstellern wie IPS dieses Protokoll bereitstellt, ist die Analyse dessen strafbar. Ich wuerde Euch also bitte, etwas Zurueckhaltung zu ueben, auch schon der Aufruf dazu kann fuer Euch zu Problemen fuehren. Und dazu ist dieses Forum nicht gedacht und wird dies auch nicht unterstuetzen.
Das ist meiner Meinung nach in diesem Fall falsch. Die CCU basiert auf Linux, die Kommunikation erfolgt auf der Basis von xmlrpc. Dies ist ebenfalls Open Source.
Die Analyse eines Protokolls ist nur verboten, wenn die Lizenz des Hersteller des Protokolls dies untersagt (wie z.b. ELV/Contronics bei der FHZ1300 PC). Dies ist jedoch bei der CCU meiner Information nach nicht der Fall (und wäre auch bei den verwendeten OpenSource-Komponenten sehr zweifelhaft). Ich lasse mich aber gerne durch einen entsprechenden Ausschnitt aus dem Lizenzvertrag zur CCU eines Besseren belehren.
Nur zur Info: Die Hersteller der Homematic haben sogar Quellcode zum xmlrpc-Protokoll beigesteuert, da Sie aus Performance-Gründen eine Binary-Erweiterung eingebaut haben, um den XML-Overhead einzusparen. Die Erweiterungen stehen ebenfalls unter der OpenSource-Lizenz.
Außerdem kann über einen Befehl eine Liste aller Befehle abgerufen werden, die die CCU versteht. Es ist also alles offen. xmlrpc ist übrigens der Vorgänger von WebServices, ohne den overhead von SOAP.
Das einzige Problem bei der CCU ist, dass das Protokoll noch nicht dokumentiert ist.
Das halte ich ebenfalls für falsch. Wenn, dann wird nicht ELV sondern eQ3 das Protokoll „herausgeben“ (was immer dies bedeuten soll). Ausserdem kann ich mir nicht vorstellen, wie es jemand verbieten kann, unter einer auf Linux basierten Hardware eine Anwendung zu installieren.
@Torro: Weißt Du, das eQ3 den kompletten Quellcode der CCU auf ihrer Internet-Seite ganz offiziell zum Download anbietet, so wie es die OpenSource-Lizenz vorschreibt? Zur „Protokollanalyse“ müßte man sich also nur den Quellcode ansehen und verstehen. Keine einfache Aufgabe, aber machbar (auch ohne Dokumentation) und definitiv erlaubt.
hier bist Du aber (wie ich immer wieder merke auch viele andere) auf dem Holzweg. Grundsaetzlich ist es so, dass Software (und dazu gehoert auch das Protokoll) urheberrechtlich geschuetzt sind. Wenn man jetzt in eigenen Projekten Open Source Software verwendet, so sind zwei Sachen dabei zu beachten: Fliessen in ein Binaerfile Open Source Teile direkt ein, so sind die Sourcen dieses Binaerteiles ebenso als Open Source zu betrachten. Ist dies aber nicht der Fall, dann bleiben alle Rechte an diesem Binaerteil bestehen. In einem Projekt muss der Hersteller lediglich alle Open Source Komponenten offen legen, auch die von ihm veraenderten - alles andere muss er nicht und das bleibt auch urheberrechtlich weiterhin unter Schutz.
Nur zur Info: Die Hersteller der Homematic haben sogar Quellcode zum xmlrpc-Protokoll beigesteuert, da Sie aus Performance-Gründen eine Binary-Erweiterung eingebaut haben, um den XML-Overhead einzusparen. Die Erweiterungen stehen ebenfalls unter der OpenSource-Lizenz.
Außerdem kann über einen Befehl eine Liste aller Befehle abgerufen werden, die die CCU versteht. Es ist also alles offen. xmlrpc ist übrigens der Vorgänger von WebServices, ohne den overhead von SOAP.
das alles spielt bei der rechtlichen Betrachtung zum Protokoll keine Rolle.
Das einzige Problem bei der CCU ist, dass das Protokoll noch nicht dokumentiert ist.
tja, und genau das ist vielleicht sogar beabsichtigt. Solange der Hersteller das Protokoll nicht veroeffentlich bzw. unter GPL stellt, ist es nicht verwendbar.
Das halte ich ebenfalls für falsch. Wenn, dann wird nicht ELV sondern eQ3 das Protokoll „herausgeben“ (was immer dies bedeuten soll).
herausgeben = veroeffentlichen
Ausserdem kann ich mir nicht vorstellen, wie es jemand verbieten kann, unter einer auf Linux basierten Hardware eine Anwendung zu installieren.
man muss sowas nicht verbieten. Es ist in Deutschland immmer wieder ein Irrglaube, dass man etwas darf, weil es nicht verboten ist. Gerade im Softwarerecht ist vieles nur moeglich, wenn es erlaubt ist, also genau umgedreht. Ich hoffe, diese Kurzform verstehst Du.
@Torro: Weißt Du, das eQ3 den kompletten Quellcode der CCU auf ihrer Internet-Seite ganz offiziell zum Download anbietet, so wie es die OpenSource-Lizenz vorschreibt? Zur „Protokollanalyse“ müßte man sich also nur den Quellcode ansehen und verstehen. Keine einfache Aufgabe, aber machbar (auch ohne Dokumentation) und definitiv erlaubt.
Christoph
wie paresy schon sagte, es ist nicht der komplette Quellcode, bestimmte Teile wie auch das Protokoll fehlen. Und mit Protokoll ist nicht nur die Implementierung gemeint, sondern dazu gehoert auch die Dokumentation. Und die Protokollanalyse ist nun mal eben die Art und Weise, wie man Rechte des Herstellers missachtet.
Ich habe mich nochmal schlau gemacht und das hier gefunden:
Zitat: „Die Analyse von Protokollen ist davon rechtlich nicht betroffen, weil dabei die Software selbst gar nicht Gegenstand der Untersuchung ist. Zudem sind solche Lizenzklauseln in vielen Ländern generell ungültig, da den Nutzern einer Sache gesetzlich das Recht zusteht, zur Überprüfung der Anwendungssicherheit (siehe auch Trojanisches Pferd) oder zur Fehlerbehebung ein von ihnen erworbenes Softwareprodukt einem Reverse Engineering zu unterziehen.“
Ich habe hier nur einen Ausschnitt zitiert, der Rest ist aber auch noch relevant/interessant.
@Torro: Gibt es irgendwo im Internet Informationen darüber, dass die Anlalyse eines Protokolls in Deutschland strafbar bzw. eine Straftat ist?
Generell würde mich einmal interessieren, woher Deine Informationen zu diesem Thema stammen, da ich gerne einmal einen genaueren Blick auf die Quelle(n) werfen möchte.
Ich habe im Internet noch einige Beiträge von Rechtsanwälten zum Thema „Protokollanalyse“ gefunden, die jedoch alle nicht eindeutig waren. Die Frage ist in der Regel, ob die reine Anordnung von unverschlüsselten Daten in einer bestimmten Struktur überhaupt schützenswert ist, ohne das die betreffenden Daten als Datei irgendwo abgelegt werden.
Eindeutige Klarheit für den erlaubten Einsatz des Protokolls in einem kommerziellen Produkt wird wohl nur eine Aussage von eQ3 schaffen.