Virtueller Fensterkontakt i.V.m. CCU2 und damit gepairten Devices

Begonnen von RaspiCOC, 13 November 2017, 13:09:57

Vorheriges Thema - Nächstes Thema

RaspiCOC

Hallo,
wenn ich mich nicht komplett täusche beziehen sich alle Postings / Wiki-Einträge zum Thema "virtueller Fesnterkontakt" nur auf HM-Devices, die via CUL oder HM-LAN-Konfigurationsadapter angebunden sind. Da letzterer abgekündigt ist und ich neben letzterem auch eine CCU2 habe, möchte ich nun so langsam alles in Richtung CCU2 migrieren.

Testweise habe ich das für einen Raum bereits getan. Auffallend ist, dass die HM-Devices anders aussehen als bei einer Anbindung über den HM-LAN-Konfigurationsadapter. Ein Versuch einen virtuellen Fensterkontakt in Analogie zu den bestehenden Anleitungen mit einem HM-TC-IT-WM-W-EU zu peeren, schlug fehl.

Gibt es hier eine Möglichkeit, den virtuellen FK in der CCU2 händisch anzulegen? Z.B. durch Edit eines Konfigfiles? Oder wie gelingt ansonsten ein Peering?

zap

Ich kenne keine virtuellen Fensterkontakte in der CCU. Wenn Du einen echten Fensterkontakt mit einem Wandthermostat und Heizkörperthermostaten in der CCU "verheiraten" willst, packst Du alles in eine virtuelle Gerätegruppe (Einstellungen -> Gruppe). Die CCU kümmert sich dann um alle notwendigen Peerings. Danach erfolgt die komplette Steuerung über das virtuelle Gruppendevice.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

CoolTux

Wäre diese Frage in einem Homematic Forum nicht besser aufgehoben. Immer hin geht es hier um Homematic Komponenten unter FHEM.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

RaspiCOC

@CoolTux: Hmm? Der Post ist doch im Homematic Forum:

    FHEM Forum »
    FHEM - Hausautomations-Systeme »
    Homematic (Moderator: martinp876) »

@zap: Ja, das ist mir durchaus klar, dass es in der CCU2 keine virtuellen FKs gibt. Nichts desto trotz stellt sich mir hier die Frage, ob auf Ebene von FHEM ein Peering möglich wäre oder ob ich aus FHEM heraus einem Device, das in der CCU2 angelegt ist, den Status "Fenster ist offen" schicken kann. Ich kann doch auch Zeiten, Temperaturen etc. aus FHEM an die CCU2 schicken.

Wenn hier gar nichts in der Richtung geht, mache ich erst mal wieder einen Rollback auf HM-LAN, auch wenn mir die Vorteile der CCU2 durchaus bewusst sind.




zap

Also wenn ich dich richtig verstehe, möchtest Du bei Änderung des Status eines FHEM-Device (kein HMCCUDEV oder HMCCUCHN Device) ein Device der CCU auf einen bestimmten Wert setzten (z.B. am Thermostat den Datenpunkt WINDOW_OPEN_REPORTING = true / false).

Das geht leider nicht, da dieser Datenpunkt Read Only ist. Bei beschreibbaren Datenpunkten könnte man es einfach per Notify realisieren.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

CoolTux

Zitat von: RaspiCOC am 14 November 2017, 08:23:01
@CoolTux: Hmm? Der Post ist doch im Homematic Forum:

    FHEM Forum »
    FHEM - Hausautomations-Systeme »
    Homematic (Moderator: martinp876) »

@zap: Ja, das ist mir durchaus klar, dass es in der CCU2 keine virtuellen FKs gibt. Nichts desto trotz stellt sich mir hier die Frage, ob auf Ebene von FHEM ein Peering möglich wäre oder ob ich aus FHEM heraus einem Device, das in der CCU2 angelegt ist, den Status "Fenster ist offen" schicken kann. Ich kann doch auch Zeiten, Temperaturen etc. aus FHEM an die CCU2 schicken.

Wenn hier gar nichts in der Richtung geht, mache ich erst mal wieder einen Rollback auf HM-LAN, auch wenn mir die Vorteile der CCU2 durchaus bewusst sind.

Da Du nichts weiter geschrieben hat als das Du auf eine CCU um ziehst und da alles anders aus sieht bin ich davon ausgegangen das Du Deine Fragen komplett auf CCU2 beziehst. Daher meinte ich ein richtiges Homematic Forum
https://homematic-forum.de/
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

RaspiCOC

@CoolTux: Nein, ich meinte, dass die Devices via CCU2 in FHEM durch das entsprechende Modul anders angelegt werden. Insofern sehe ich schon, dass das ein FHEM-Thema ist. Ich werde in keiner Weise den Abschied von FHEM nehmen. Dafür macht das viel zu viel Spaß  :)

@Zap: Ok, danke, damit wäre geklärt, dass ich von FHEM aus nicht den Fensterstatus an die CCU2 geben kann.

Interessant wäre es jetzt allenfalls noch darüber nachzudenken, ob ich z.B. über den HM-Lan oder CUL einen Fensterkontakt so simulieren kann, dass die CCU2 diesen als ein legitimes Device erkennt. Dann könnte das Peering in der CCU2 passieren. Ein beliebiger Fensterkontakt könnte dann seinen Status per notify als den simulierten HM-SEC-SCo via HM-Lan / CUL / ... an die CCU2 senden, die dann den Status an die gepeerten Devices weitergibt. Gerade bei Zimmern mit mehreren Fenstern könnte man dann die verhältnismäßig teuren HM-SEC-SCo durch günstigere Kontakte ersetzen. Wäre so etwas denkbar (muss allerdings zugeben, dass das meine IT-Fähigkeiten bei weitem überschreitet, es würde jedoch die Vorteile die ein HM-Lan gegenüber CCU2 hat mit den Vorteilen der CCU2 verbinden).


zap

Da muss ich leider auch passen. Grundsätzlich ist das Handwerkszeug vorhanden (Asksin, CUL, BidCos Protokoll). Aber damit müsste sich ein Spezialist befassen.

Solltest du aber Enocean Fensterkontakte nutzen wollen, könntest du diese mit Hilfe von CUXD direkt an die CCU anlernen.

Was für dich vielleicht eine Alternative sein könnte, wäre eine Simulation des Peerings über Notify oder DOIF. Also zB wenn ein Fenster aufgemacht wird, setze Zieltemperatur eines Thermostaten in der CCU auf 10 Grad.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

RaspiCOC

Über den Workaround mit der Zieltemperatur hatte ich auch schon nachgedacht. Das würde natürlich gehen, führt aber im Hinblick auf den WAF zu Problemen, denn was ist, wenn das Fenster-Zu-Telegramm eines 433 MhZ Sensors nicht angekommen ist, und die Zieltemperatur auf 10 Grad steht und so bleibt. Dann ist am Thermostat der Fenster-ist-auf-Zustand nicht sichtbar und der Ärger vorprogrammiert ;-)

Enocean ist ja doch auch noch recht teuer. Da kann ich dann auch die HM Fenstersensoren nehmen. Vielleicht habe ich da aber auch preiswerte Alternativen übersehen.

Vielleicht stößt ja jemand mit dem Spezialisten-Know-How auf diesen Thread und findet an der Idee grundsätzlich gefallen. Wie schon geschrieben könnten die Nachteile der CCU2 damit ein wenig beseitigt werden und damit das Beste beider technischen Lösungen erreicht werden.

Danke für das stets prompte Feedback!!