Homematic Thermostat und Fenstersensor. Ich bin zu blöd.

[lenn1]

Hallo,
bin seit einem Jahr mit zwave dabei und habe nun einen nanoCUL und erste homematic Komponenten gekauft.

Funkthermostat
Fenstersensor optisch

Das Funkthermostat konnte ich mit dem Sensor verbinden, dann das Funkthermostat auch mit dem CUL, aber den sensor halt nicht mit dem CUL.
Brauche ich da zwingend eine VCCU für?
Probiert hatte ich das auch nach der Anleitung im Wiki (aes..
Irgendwas)
Aber mit dem VCCU Device  krieg ich gar nix verbunden.

Wie gehe ich vor? Was verbindet man üblicherweise miteinander?
Soll der Sensor evtl gar nicht mit dem CUL funken?

Ziel ist es den Fensterstatus in Fhem abfragen zu können.

Naja war ein langer Abend gestern. Hoffe ihr könnt mich aufklären.

[lenn1]

Ich versuche es mal selbst: Vielleicht könnt ihr mir ja zumindest nur sagen ob es richtig ist oder nicht.


1. VCCU anlegen (hmkey usw definieren)
2. Thermostat anlernen (an VCCU)
3. Fensterkontakt anlernen (an VCCU)

ODER

1. VCCU anlegen (hmkey usw definieren)
2. Fensterkontakt an Thermostat anlernen
3. Thermostat anlernen (an VCCU)
4. Fensterkontakt anlernen (an VCCU)

ODER

...?

[Pfriemler]

Keine Antwort bisher? Dann versuche ich es mal ...
Deine beiden Varianten sind eigentlich wurscht. Variante 2 enthält die empfehlenswerte Kopplung des Fensterkontaktes direkt mit dem Thermostaten, das bedeutet Absenkung bei offenem Fenster ganz ohne Zutun von FHEM (wenn man es richtig macht). Ob man die Teile zuerst direkt koppelt und dann an die Zentrale (sprich: FHEM) anlernt oder die Kopplung hinterher via FHEM macht, ist am Ende das Gleiche.

Den nanoCUL hast Du ja bereits im Homematic-Modus, sonst hätte das mit dem Thermostaten nicht funktioniert.

Du hast aber richtig erkannt, dass die Fensterkontakte AES voraussetzen. Dafür braucht es unterhalb von FHEM auf Linuxebene eine spezielle Krypto-Bibliothek, sonst klappt AES nicht. Infos im Wiki-Artikel zu AES.
Hier speziell "I/O-Device <--> Gerät".

Wenn das auch installiert ist ... Es gibt dann noch eine spezialisierte Firmware für die CULs, die speziell auf HomeMatic zugeschnitten ist bezüglich zeitkritischer Aktionen. Da zählen aber eher kompliziertere Gerätschaften wie der Thermostat zu den Problemkandidaten, wenn umfangreiche Konfigurationen übertragen werden müssen. Das könnte auch auf Dich zukommen...

[darkness]

Hallo,

(nano)CUL und HM Fensterkontakte machen wohl gerne mal Probleme.
Ansonsten ist auch ein list <DEVICE> immer recht hilfreich bei der Fehlersuche.

Gruß

[pc1246]

Moin
Da will ich mich schnell noch einmischen. AES muss man nicht aktivieren, kann man aber! Meine Fensterkontakte sind alle ohne!
Und darkness hat wohl recht, hier ist definitiv die a-CulFW zu bevorzugen!
Gruss Christoph

[darkness]

AES muss man nicht aktivieren, kann man aber! Meine Fensterkontakte sind alle ohne!

Ich dachte bei allen HM-Sec-* ist AES immer aktiviert?

[pc1246]

Moin
Nagelt mich jetzt nicht fest. Aber man kann bei "allen" das AES aktivieren/nutzen. Zwingend sind meines Wissens nur Winmatic und Keymatic. Ich habe in der Bucht 3(4) gebrauchte Bewegungsmelder gekauft gehabt, wo bei 2 Stueck das AES aktiviert war. Die sind dann von ELV kostenpflichtig zurueckgesetzt worden. Deshalb ist das bei mir auch aus, da man sich da schnell verfummeln kann!
Gruss Christoph

[Grinsekatze]

Bei meinen beiden optischen Fensterkontakten musste ich 2x pairen, bis FHEM sie richtig gefunden hat. Auch müssen sie im geschlossenen Zustand sein (also das Fenster vorher schließen).

[Pfriemler]

Also mit der alternativen Firmware meine ich nicht die a-culfw, sondern die hier beschriebene. Interessanterweise ist der Faden nicht mehr gepinnt, ich musste erst suchen. Keine Gewähr also für Aktualität. Da ich mit HMLAN und HMUART arbeite, sind mir Timing- und AES-Probleme von vornherein fremd. Und gerade die SCo gehören zu meinen unproblematischsten Geräten, komisch.

Ich dachte bei allen HM-Sec-* ist AES immer aktiviert?

Sehe ich auch so. Das wurde bei mir auch immer von allein gesetzt (Register "R-sign" ist "on"). Benutzt wird hier der System-Default-Schlüssel, der aber bekannt und damit nicht mehr sicher ist. "Sicher" wird man erst mit einem eigenen AES-Schlüssel - und dann erst werden die Geräte ein Servicefall, wenn man sie ohne Kenntnis des Schlüssels nicht mehr zurücksetzen kann.
Man kann das Signieren aber auch ganz ausschalten. Den Funkverkehr mitlesen kann man ohnehin, auch bei geändertem AES-Schlüssel. Lediglich ein "Angriff" mit gefakten Fernbedienungen etwa auf eine Keymatic klappt dann nicht mehr.

[pc1246]

Grosse Steine! Kleine Steine!

Ja ist ja gut, ich habe es jetzt auch verstanden. Das R_sign on war mir auch schon aufgefallen, und ich habe mich immer gewundert. Heisst im Unkehrschluss, dass die Signierung an ist, mit einem immer bekannten Schluessel. (Also eigentlich doch aus!) Das war dann mein Trugschluss.
Der Hinweis/link von Pfriemler ist dann uebrigens sehr gut, da steht dann auch gleich, dass es mit eine CUL halt diese Timingprobleme gibt. Ich habe das noch nie bemerkt, da ich zwar auch CULs im Einsatz habe, aber auch "echte" HM-IOs.
Sorry und dankende Gruesse
Christoph

[MadMax-FHEM]

Der im Link verlinkte Artikel/Thread ist (noch) aktuell

Habe auch (auf dem Testsystem) einen nanoCUL und ebenfalls Probleme mit den optischen Fenstersensoren...
...habe sie zum Test (ob das mit dem Löten geklappt hat ) mal angelernt bzw. versucht und auf dem Testsystem eben nanoCUL.

Bin mir aber gar nicht mehr sicher, glaube aber noch ohne die spezielle "Timing-FW".
Die habe ich erst für den Klingelsensor aktivieren müssen...
...bzw. habe ich den Fenstersensor einfach ins Hauptsystem integriert ohne zu testen, hab mal angenommen, dass das Löten schon gepasst haben wird

Im Hauptsystem habe ich auch HM-CFG-USB bzw. HMUART...
...und keine Probleme.

CUL und Homematic ist nicht wirklich empfehlenswert...

Gruß, Joachim

[Tedious]

Nur als Randnotiz - bei mir laufen 3 HM Rolladenaktoren am MapleCUN mit aculfw tadellos. Ist aber auch kein komplexes Setting mit 100en Aktoren, die Komfortschaltungen triggern günstige Max!-Fensterkontakte.

[lenn1]

Wow, hier ist ja richtig Fahrt reingekommen.

Hab es mittlerweile geschafft ! War etwas gefrustet, dass niemand geantwortet hat, daher hab ich das wohl nciht als gelöst markiert.


Der Grund warum es nicht so funktionierte, wie ich wollte: Der CUL stand ungünstig im HWR. Er hat die Signale vom Fensterkontakt nicht zuverlässig empfangen. Hab das Ding umgestellt und konnte dann das Tutorial durchziehen.

Die Krypto Bibliothek hab ich installiert, aber den HMKey nicht eingerichtet. Ging irgendwie so.

Mein Weg war am Ende:

VCCU einrichten,
Beide Geräte an VCCU anlernen
Und dann eben wie im Wiki (über FHEM) die beiden miteinander bekannt gemacht.


Temperatur springt sofort auf den gewünschten Wert und man sieht auch alles in FHEM.

Grüße
Lennart

[Pfriemler]

Hallelujah, es spielt.

@pc1246: nix für ungut, bitte. Ich wollte es nur ganz klarstellen.

... bei mir laufen 3 HM Rolladenaktoren am MapleCUN mit aculfw tadellos.

Wär auch schlimm wenn nicht. 

Als Ergänzung: Wenn CUL mit Homematic generell Probleme machen würden, bräuchte es keine so spezielle Firmware. Aber manche Geräte reden sehr schnell und sehr umfänglich mit der Zentrale, wie eben alle Geräte mit Wochenschaltplänen wie die Thermostate oder mit umfangreichen Konfigurationen (wie etwa die 8-Kanal-Module). Da bringen ein paar Knoten in der Zeitlinie den Dialog schnell zum Erliegen. Gewöhnliche Geräte wie Sensoren und Schaltaktoren machen dagegen keine Probleme. Eigentlich. Vom Klingelsensor habe ich auch schon öfter gehört. Das Ding macht ohnehin einen etwas unreifen Eindruck, wie auch der RGB-Controler ...
Inwieweit sich die a-culfw in Bezug auf Homematic besser verhält als die Orginale, erschließt sich mir ganz und gar nicht, für mich waren die immer gleichwertig.

[MadMax-FHEM]

Die Krypto Bibliothek hab ich installiert, aber den HMKey nicht eingerichtet. Ging irgendwie so.

Weil der Standard-Key schon hinterlegt ist.
Ist aber dann praktisch wie mit ohne Sign...

Daher (nur Tipp am Rande) entweder gleich ohne Sign, spart Funktelegramme und somit Batterie...
...oder einen echten/eigenen Schlüssel vergeben und dann tatsächliche Signierung und somit (etwas) Sicherheit...

Gruß, Joachim