Homematic Funkmodul oder nanoCUL

[stonecold_mario]

Hallo,

ich habe gerade damit begonnen Zuhause mittels Raspi und 433MHz Sender/Empfänger ein paar Dinge zu automatisieren (Hatte "kürzlich" einen Artikel in der c't gelesen). Ich würde den Raspi gerne auch für 868MHz Protokolle nutzen. Erste Idee war ein Homematic Funkmodul zu kaufen. Dann bin ich auf die Eigenbau nanoCULs gestoßen. Preislich tun sich die beiden Lösungen nichts.

Nun zu meiner Frage: Kann das Homaticmodul auch für andere Protokolle genutzt werden? Oder ist Homematic "fest eingebrannt". Hat es weitere Vorteile einen nanoCUL selbst zu bauen? Sind mit einer nanoCUL unterschiedliche Protokolle möglich?

Danke und VG

[MadMax-FHEM]

Homematic ist fest in der FW verankert.

Ob man umflashen kann weiß ich nicht und was dann damit geht auch nicht...

ABER: wenn du Homematic willst dann lass besser die Finger von einem CUL!!

Nimm ein "originales" HM-IODev, z.B. eben den erwähnten Adapter.

Preislich kein Unterschied...
...Vorteil funktioniert mit HM ohne Probleme auch bzgl. Timing etc.
..."Nachteil": geht halt nur für Homematic...

Wenn du dich doch/trotzdem für einen CUL entscheidest, dann eher gleich hierfür als FW (zumindest bei Nutzung von Homematic):

https://forum.fhem.de/index.php/topic,24436.0.html

Gruß, Joachim

[DeeSPe]

Ich würde auch für HomeMatic das originale UART Modul benutzen.
Bei Bedarf kann man auch noch weitere CULs für kleines Geld selber bauen und zusätzlich mit einbinden.
Habe bei meinen Eltern neben dem HM Modul noch einen 433CUL zu laufen, ohne Probleme!

Gruß
Dan

[Ralf9]

Nimm ein "originales" HM-IODev, z.B. eben den erwähnten Adapter.
Preislich kein Unterschied...
...Vorteil funktioniert mit HM ohne Probleme auch bzgl. Timing etc.

Ich würde auch für HomeMatic das originale UART Modul benutzen.

Ich finde, der Hinweis, daß ein CUL für Homematic nicht die beste Wahl ist, gehört auch ins Homematic Wiki.
Soll ich dazu was unter "Allgemeine Informationen - Wiki" schreiben oder ist mein Wunsch hier ausreichend?

Gruß Ralf

[Otto123]

Ich finde, der Hinweis, daß ein CUL für Homematic nicht die beste Wahl ist, gehört auch ins Homematic Wiki.
Soll ich dazu was unter "Allgemeine Informationen - Wiki" schreiben oder ist mein Wunsch hier ausreichend?

Gruß Ralf

Hallo Ralf,

naja ich habe vor einiger Zeit schon mal diesen Punkt etwas "erneuert" aktualisiert und neu geordnet. Ich wollte niemandem auf den Schlips treten und habe keine Wertung hinterlassen.
Ich habe auch an allen möglichen Stellen im Wiki vorsichtig drauf hingewiesen, das original HM IOs dem Cul zu bevorzugen sind. Eigentlich sollte das auch irgendwie klar sein.
Uli baut an einem neuen Einsteigerdokument.

Am Ende wird eh "die Empfehlung aus dem Internet" von 2013 genommen und die Leute kaufen einen Cul, weil überall steht damit geht es. Und weil alle eine Eierlegendewollmilchsau haben wollen.


Gruß Otto

[Ralf9]

Ich wollte niemandem auf den Schlips treten und habe keine Wertung hinterlassen.

Ich fände eine vorsichtige Wertung sinnvoll. Ich habe den Eindruck, daß bei vielen nicht klar ist, daß original HM IOs dem Cul zu bevorzugen sind.

Vorteil funktioniert mit HM ohne Probleme auch bzgl. Timing etc.

Ist mit denTiming Problemen dies gemeint?

TSCUL versucht nun Befehle an ein device 3 mal abzusetzen, bis eine Antwort kommt.
Wenn ein device ein AES Signing anfordert, so führt dies TSCUL mit den verfügbaren Keys aus. Der Default Key ist natürlich auch in der Firmware hinterlegt.
Dies ist im Gegensatz zu HMLAN etc. auch das einzige automatische ACK seitens TSCUL, d.h. 10_CUL_HM.pm muss die sonstigen ACKS/NACKS weiterhin senden (rechtzeitig an TSCUL schicken).

Damit sind die Timing Probleme weiter entschärft, da Kommunikation von TSCUL zum device bezüglich Timing im Wesentlichen behandelt wirdt.
Bei Kommunikation eines devices zu TSCUL muss weiterhin FHEM via 10_CUL_HM.pm schnell genug eine Antwort liefern.

Je nach CUL Hardware werden bis zu 8 Sendepuffer verwaltet (einer wird stets für AES Signing genutzt). Mittels eines Flags wird stets eine "Unterhaltung"ssequenz zu einem device abgeschlossen, bevor Puffer mit Daten für andere Devices abgearbeitet werden. Aus diesen Sendedaten wird auch die eigene HMID "gelernt".
Bei Empfang eines unaufgefordeten Datenpakets von einem device an diese gelernte HMID mit Antwortanforderung wird von TSCUL ebenfalls eine "Unterhaltung" für ca. 400ms gesetzt, so dass eine Antwort von 10_CUL_HM.pm direkt entsprechend Antworttiming gesendet wird und so lange nichts an ein anderes device gesendet wird.

Ich sehe beim CUL nur Nachteile. Hat der CUL gegenüber den original HM IOs auch Vorteile?

Da es beim CUL keine Keepalive Routine gibt, kann es bei remote Anbindung des CUL z.B. mit socat, ser2net oder WLAN zu timeouts der LAN-Anbindung kommen. Oder habe ich da was übersehen?

Gruß Ralf

[Thorsten Pferdekaemper]

Ich sehe beim CUL nur Nachteile. Hat der CUL gegenüber den original HM IOs auch Vorteile?

Ich glaube, dass manche es als Vorteil sehen, dass man mit einem CUL auch noch andere Protokolle sprechen kann. Dass das dann in der Praxis Blödsinn ist, sehen viele Anfänger erst einmal nicht.
Hier: https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale
...wird aber überhaupt keine Empfehlung gegeben.

Ich sehe auch gerade, dass hier für Wired nur HMW-LGW-O-DR-GS-EU steht. Das werde ich auch mal ändern. Hier ist nämlich die Empfehlung genau anders herum. Die Original eq3-Teile gehen anscheinend dauernd kaputt oder funktionieren erst gar nicht.

Gruß,
   Thorsten

[Otto123]

Hallo Thorsten,

ja, ich habe jede Bewertung weggelassen, ich habe in dem Abschnitt nur ergänzt und eine Reihenfolge angelegt.
Vorher war es auf einem Stand von 2013 

Ich habe keine CUL ich habe nur RPI/HMUART und HMLAN. Ich scheue mich dort Dinge reinzuschreiben die ich nur von Anderen erfahre.

Gruß Otto

[Ralf9]

Da es sich anscheinend noch nicht herumgesprochen hat, daß man den CUL nicht für Homematic nehmen sollte, möchte ich das Thema nochmals hochholen.

Der HM-MOD-RPI-PCB kann nur Homematic Funk, dafür aber richtig.

Was genau verstehst Du darunter  ? (Außer die AES Signierung zusätzlich ?)

Da ich dies mangels CUL nicht so richtig beantworten kann, gebe ich die Frage hier weiter.

Wie wirken sich die Timing Probleme des CULs in der Praxis aus?

Welche Einschränkungen hat der CUL beim AES?

Eine weitere Einschränkung vom CUL könnte sein:

Da es beim CUL keine Keepalive Routine gibt, kann es bei remote Anbindung des CUL z.B. mit socat, ser2net oder WLAN zu timeouts der LAN-Anbindung kommen.

Hat der CUL gegenüber dem HM-MOD-RPI-PCB noch weitere Nachteile?

Gruß Ralf

[LuckyDay]

Timing Probleme des CULs in der Praxis aus?

der Cul arbeitet nach wie vor transparent, also das timing macht Fhem. mit der ts Software werden Zeitstempel mitgeschickt
etwas genauer, leider ist Fhem selber nicht Zeitgenau (single)

Hm device erledigen das selber Hmlan Hmuart, usw...

[martinp876]

Nachdem insbesondere ACK und AES antworten zeitkritisch sind ist es von. Vorteil, dass hmios dies intern erledigen. Das Timing ist SEHR präzise.
Bei cul macht dies fhem. Ohne Zeitstempel ist dies nicht zu leisten, da die Varianz der Verzögerung auf dem Übertragungsweg (lan und USB gleichermaßen) deutlich zu schlecht ist.

Mit dem seitstempel kann man gegen Rechnung.
Die Berechnungen sich neben ACK und AES auch für weitere Messages notwendig. Hmios liefern auch Zeitstempel welche von fhem ausgewertet werden .

Hm passt besser für hm. Cul ist auch ok - und kann Universal eingesetzt werden. Allerdings nicht zeitgleich.

[Thorsten Pferdekaemper]

der Cul arbeitet nach wie vor transparent, also das timing macht Fhem. mit der ts Software werden Zeitstempel mitgeschickt
etwas genauer, leider ist Fhem selber nicht Zeitgenau (single)

Könnte man das nicht mit einem separaten Server-Programm erledigen, wie auch bei HM-Wired?
Gruß,
   Thorsten

[zap]

Dann kann man auch gleich OCCU nehmen, oder? Das wäre ja ein separater Prozess.

[martinp876]

Das timingproblem liegt an den Verzögerungen der Schnittstellen. Hinreichend genaue Zeitstempel kann nur das io in fw erzeugen.
Unabhängig von fhem addiert ein nicht-echtzeitfaehigen OS unbekannte Verzögerungen. Ein separater Prozess würde den Einfluss von fhem selbst eliminieren, allerdings nicht die des OS und aller anderen Prozesse. Besser aber nicht wasserdicht.
Es reicht nicht, den io Treiber auszulagern, da einige Antworten von fhem generiert werden, anhand der zu Verfügung stehenden Daten.

Der Aufwand wäre erheblich die Kommunikation umzustellen. Aktuell funktioniert es eigentlich gut -so der nutzen die TS Version einer cul einsetzt. Weiter werden ALLE Protokollprobleme ausgegeben. Der User muss sich diese ansehen, was auch nach einer Umstellung der Fall wäre. Das macht sogar die ccu von hm so.

Was also rechtfertigt den Aufwand, das Risiko einer Umstellung und die Komplexität (welche in fhem nicht gut unterstützt wird)?

[Otto123]

Da es sich anscheinend noch nicht herumgesprochen hat, daß man den CUL nicht für Homematic nehmen sollte, möchte ich das Thema nochmals hochholen.
...
Hat der CUL gegenüber dem HM-MOD-RPI-PCB noch weitere Nachteile?

Moin,

sollten wir jetzt hier jeden Tag einmal sagen, das EierlegendeWollmilchsäue nicht die erste Wahl sind?  Ich habe den Eindruck, dass jeder der mit Homematic beginnt, der Meinung ist einen CUL einsetzen zu müssen. Geht es dabei um ein paar Euro um sich dann mit Komponenten mit einem Wert von vielen Hundert Euro nur rumzuärgern?

Auf alle Fälle habe ich mit der Erklärung von Martin verstanden warum offenbar bei einigen HM mit CUL gut läuft und ansonsten viele Probleme auftauchen.
Schnelles System, wenig Last von FHEM, "einfache" HM Komponenten -> CUL geht gut.
Stark belastetet FHEM System, komplexe HM Komponenten (z.B. HM-PB-4DIS-WM) + AES -> mit CUL geht es wahrscheinlich gar nicht.
Dazwischen ist sicher jede Variante möglich.
Die TS Firmware ist eigentlich Pflicht, auch das weiß so gut wie niemand von den CUL Anfängern.

Ist es aus eurer Sicht legitim, als Standard Antwort bei Pairing Problemen mit CUL die Empfehlung auf einen HM IO zu geben? Bzw.auch mal zu sagen CUL geht eben nicht?

Gruß Otto