Neue Homematic IP Serie

Fischei · 11 Oktober 2017, 12:07:46

danke euch alle. jetzt funktioniert es. hab mich zwar jetzt drei Tage damit gespielt aber jetzt geht es.
Ein Problem hab ich noch. Wenn ich den Raspberry restarte, dann kommt folgende Meldung:

Code Auswählen

2017.10.11 11:14:54 1: HMCCU: 500 Can't connect to 192.168.1.105:8181
und somit können die Geräte auch nicht ausgelesen werden.
Wenn ich aber dann FHEM manuell neu starte, dann funktioniert alles.
Hat hier jemand eine Idee? Oder soll ich hier besser mal einen neuen Thread aufmachen?
Für mich hört sich das nicht Timing Problem an.

Pfriemler · 11 Oktober 2017, 12:51:36

Zitat von: Fischei am 11 Oktober 2017, 12:07:46
... und somit können die Geräte auch nicht ausgelesen werden.
Wenn ich aber dann FHEM manuell neu starte, dann funktioniert alles.
Hat hier jemand eine Idee? Oder soll ich hier besser mal einen neuen Thread aufmachen?

Ich glaub, dafür gibt es schon diese Diskussion hier.

zap · 11 Oktober 2017, 16:27:58

Zitat von: Fischei am 11 Oktober 2017, 12:07:46
Für mich hört sich das nicht Timing Problem an.

Ja, ist es. Die CCU Services sind noch nicht gestartet. Das dauert immer 1-2 Minuten.

Ich checke voraussichtlich noch heute ein Update ein. Damit kann man HMCCU dazu veranlassen, beim Define eine bestimmte Zeit auf die CCU zu warten. Das verzögert dann zwar den Start von FHEM entsprechend lange, sollte aber die Probleme beheben.

Fischei · 11 Oktober 2017, 21:44:48

Super, danke dir! Ich teste es morgen gleich und geb dir bei dem anderen Thread Rückmeldung.

ext23 · 12 November 2017, 20:02:13

Nabend,

ich hätte jetzt auch ein HM IP Gerät was mich interessieren würde. Da ich nur ein HM-LAN habe (den ganz alten runden), benötige ich jetzt also eine CCU2 oder ein RPi mit diesem HM Aufsteckadapter. Warum wird denn das HM-IP nicht nicht direkt von FHEM unterstützt? So wie ich das verstehe gibt es doch da dieses occu Projekt und dort müsste man doch an die Funktionen kommen um das zu "kopieren" oder was ist das eigentliche Problem? Kann mir das jemand erklären?

Und weiß zufällig jemand ob ich diesen HM Audsteckadapter wirklich brauche oder ob mein HM-LAN Adapter (In Verbindung mit dieser CCU2 Simulation auf dem RPi) auch ausreichen würde für HM-IP Geräte? Trotz des blödsinnigen Namen "IP" ist es doch trotzdem 868 MHz und eine Art BidCos oder wie? Die eigentliche Umsetzung in IP macht doch dieser Access Point und die Wolke, sofern man das nutzt oder?

Irgendwie weiß ich nicht so richtig wie ich das am besten machen soll. Nur wegen einem Gerät jetzt eine extra CCU2 hinstellen und alle anderen "alten" HM Geräte sind direkt an FHEM angelernt ist nicht unbedingt sinnvoll oder?

/Daniel

chris1284 · 12 November 2017, 22:00:14

ZitatUnd weiß zufällig jemand ob ich diesen HM Audsteckadapter wirklich brauche oder ob mein HM-LAN Adapter (In Verbindung mit dieser CCU2 Simulation auf dem RPi) auch ausreichen würde für HM-IP Geräte?

Nö, der kann das nicht. Auch nicht wenn man ihn an einer echten ccu2 als entferntes Gateway nutzen will. Du brauchst ne occu oder ne CCU2 um HM-IP in fhem nutzen zu können.
Das wird sich wohl auch nicht ändern und meiner Meinung nach wird CUL_HM wohl auf lange Sicht von HMCCU abgelöst werden weil gerade das HMIP-Segment sich bisher in eine interessante Richtung entwickelt und Bidcos ehr stagniert

ext23 · 12 November 2017, 22:54:29

Mhh macht die Sache dann vermutlich nicht einfacher wenn man jedes Gerät mit der CCU koppeln muss und dann wiederum irgendwie jedes einzeln an FHEM durchreichen muss. Dann ist FHEM natürlich überflüssig, zumindest für die die nur HM benutzen und keine anderen Systeme. Und dann wird es auch mit dem Asksin Eigenbauten schwer wenn man nur noch eine CCU hat oder?

Mhh naja dann schau ich mir mal diese CCU2 RPi Implementierung an. Werd ich mir mal ein RPi besorgen und dieses HM Modul und dann schau ich mal.

/Daniel

zap · 13 November 2017, 07:34:10

ZitatTrotz des blödsinnigen Namen "IP" ist es doch trotzdem 868 MHz und eine Art BidCos oder wie? Die eigentliche Umsetzung in IP macht doch dieser Access Point und die Wolke, sofern man das nutzt oder?

Irgendwie weiß ich nicht so richtig wie ich das am besten machen soll. Nur wegen einem Gerät jetzt eine extra CCU2 hinstellen und alle anderen "alten" HM Geräte sind direkt an FHEM angelernt ist nicht unbedingt sinnvoll oder?

/Daniel

.

Das ist nicht blödsinnig sondern tatsächlich IP über 868 MHz Funk (du weißt schon, OSI Layer und so)

Wenn du eine CCU hast, kannst du alles daran anlernen. FHEM behält seine Existenzberechtigung für alle nicht Homematic Sachen. Obwohl sich hier einiges getan hat. Mittlerweile kann die CCU Enocean, OSRAM, Sonos usw

chris1284 · 13 November 2017, 07:40:26

Naja, Fhem macht schon noch sinn. Auch wenn die CCU2 einige weitere Protokolle und Addons unterstützt ist FHEM um einiges umfangreicher.
Ich habe zb einen pi mit CCU2 (YAHM) und fhem am laufen weil die CCU2 kein BT-Dongle zur Anwesenheit direkt nutzen kann oder auch die Darstellungs- und Bedienmöglichkeiten über FHEM besser sind

ext23 · 13 November 2017, 07:49:21

Zitat von: zap am 13 November 2017, 07:34:10
Das ist nicht blödsinnig sondern tatsächlich IP über 868 MHz Funk (du weißt schon, OSI Layer und so)

Mit riesen Overhead oder wie? hast du hier bitte die Protokoll Beschreibung zu Hand, ich finde nichts im Netz dazu außer Sales Kram der ja nun naja, wenig Aufschlussreich ist.

ich werd mir dann mal diese RPi Aufsteckadapter holen und eine CCU2 und dann schau ich mir das mal an. Ich hab ein bissel Angst, dass ich dann zwei Stellen habe an denen ich alles konfigurieren muss. Erst alles auf der CCU einrichten und dann auch noch in FHEM. (ich hab mir das CCU Modul noch nicht angesehen wie komplex das ist). Diese ganzen anderen Funktionen der CCU brauche ich nicht da ich eh in der Regel nie HM mit HM koppel sondern eher irgend etwas anderes mit HM was die CCU vermutlich nicht versteht.

Gruß
Daniel

chris1284 · 13 November 2017, 08:03:58

Ja, an 2 Stellen zu konfigurieren bleibt nicht aus:
-CCU2: mind. Geräte anlernen und verknüpfen und konfigurieren (geht gerade mit YAHM / Raspberrymatic wesentlich schneller und einfacher als in FHEM mit registerschupsen)
-FHEM: Geräte anlegen und konfigurieren (geht fast von allein mit den default Tempates)

karl0123 · 13 November 2017, 08:07:20

Es gibt noch andere Dinge, die nicht wirklich in die Richtung gehen, dass man in FHEM auf CUL_HM verzichten könnte. Die Anzahl der IODevs als Beispiel. Ich sehe diesen Weg nicht. HMIP ist für mich kein Grund. Zwave ist die bessere Alternative.

ext23 · 13 November 2017, 08:09:00

Zitat von: chris1284 am 13 November 2017, 08:03:58
Ja, an 2 Stellen zu konfigurieren bleibt nicht aus:
-CCU2: mind. Geräte anlernen und verknüpfen und konfigurieren (geht gerade mit YAHM / Raspberrymatic wesentlich schneller und einfacher als in FHEM mit registerschupsen)
-FHEM: Geräte anlegen und konfigurieren (geht fast von allein mit den default Tempates)

Vom Preis her ist CCU2 und RaspberryPi plus das Modul ja im Prinzip gleich. Du würdest also dennoch eher zum RPi tendieren? (Mein FHEM läuft auf einem anderen System, das bleibt auch so. Also auf den RPi soll kein FHEM rauf).

/Daniel

herrmannj · 13 November 2017, 10:32:25

Zitat von: ext23 am 13 November 2017, 07:49:21
Mit riesen Overhead oder wie? hast du hier bitte die Protokoll Beschreibung zu Hand, ich finde nichts im Netz dazu außer Sales Kram der ja nun naja, wenig Aufschlussreich ist.

ich werd mir dann mal diese RPi Aufsteckadapter holen und eine CCU2 und dann schau ich mir das mal an. Ich hab ein bissel Angst, dass ich dann zwei Stellen habe an denen ich alles konfigurieren muss. Erst alles auf der CCU einrichten und dann auch noch in FHEM. (ich hab mir das CCU Modul noch nicht angesehen wie komplex das ist). Diese ganzen anderen Funktionen der CCU brauche ich nicht da ich eh in der Regel nie HM mit HM koppel sondern eher irgend etwas anderes mit HM was die CCU vermutlich nicht versteht.

Gruß
Daniel

Genau wie beim klassischen Bidcos gibt es keine Beschreibung.

Geht nur via reverse Engineering. Wobei HMIP vmtl (gegenüber Bidcos) einen drauf setzt und anstelle der XOR Verschleierung eine echte Verschlüsselung (imho AES) verwendet. IP V6 (Adressen) und Transportsecurity machen schon Sinn. Das mit dem Overhead ist relativ (IP wurde mal erfunden um im Falle eines Atomkriegs Signale über einen nassen Schnürsenkel von A nach B zu bekommen).

Ich würde mir das SDK (https://github.com/eq-3/occu) anschauen. Von dort aus gibt es imho verschiedene Ansätze. Entweder man lernt genug über das Protokoll um es (per fhem modul) nachzubilden - oder (besser?) - es lassen sich Einstiegspunkte via API (dokumentiert, undokumentiert) finden um ein fhem modul (auch in c mgl) "anzudocken". Ich meine: fhem muss ja nicht den IO direkt ansprechen. Genauso wenig den RPC der CCU. Dazwischen liegt ja eine (per GIT) verfügbare Bibliothek von eq3

vg
joerg

zap · 13 November 2017, 11:45:20

Man muss sich aber schon mal fragen ob es Sinn macht, so etwas zu entwickeln.

APIs gibt es ja schon lange und die sind auch dokumentiert: RPC und Homematic Script (und JSON, wer es braucht). Diese APIs nutzt HMCCU und auch andere Plattformen wie OpenHab oder IOBroker.

Wenn ich jetzt mal die 2 Varianten vergleiche:
1. FHEM mit CUL Stick und einem hypothetischen HMIP Software Modul
2. FHEM mit Funkmodul und OCCU sowie HMCCU

Das gibt sich kostenmäßig nichts. Der Vorteil von 2 ist aber das einfache Anlernen und Peeren von Geräten. Warum sollte man das Rad neu erfinden? Ok, mit CUL_HM ist das schon mal so passiert. Aber das muss sich mit HMIP ja nicht wiederholen.