CCU2 oder CUL (Empfangsverzögerung Wandtaster)?

[SFAB]

Ich bin derzeit noch auf der Suche nach passenden Wandtastern, die sich idealerweise in meine bestehende Jung CD500-Installation integrieren lassen.
Wenn ich in erster Linie Homematic-Sender/-Taster in FHEM einbinden möchte, ist es dann besser eine CCU2 via HMCCU zu verwenden, oder einen CUL an meinen Raspberry anzuschließen?

Aktuell teste ich eine CCU2 mit einer 4-fach Tastschnittstelle, allerdings ergibt sich über HMCCU eine Verzögerung von 1 bis 3 Sekunden. Würde diese Verzögerung wegfallen, wenn ich stattdessen einen CUL einsetzen würde?

Welche Nachteile außer der fehlenden Kompatibilität zu Homematic IP hätte der CUL gegenüber CCU2?
Ausfallsicherheit mittels CCU2 ist bei mir kein Vorteil, da das Ansteuern der Aktoren eh über FHEM laufen muss (Intertechno).

[Yil]

Ich habe und hatte exakt die gleiche Fragestellung. Sogar die Jung-Schalterreihe ist die gleiche *grins*

Mit der HM Cul ging das alles sehr flott. Ich hatte einen 6-fach Schalter, der meist sehr schnell seine Befehle übertragen konnte. Es war nie Echtzeit, aber meist nahe dran.

Als der Cul kaputt ging, kaufte ich die CCU2 und gewann dadurch ne Menge Vorteile, aber eben auch den Nachteil der Zeitverzögerung. Der Entwickler des dazugehörigen Moduls hat mir jüngst den Tipp gegeben, in der CCU2 bei FHEM das attr rpcinterval auf 2 zu setzen. Damit ist die Zeitverzögerung erträglich, aber leider immer noch nicht so gut wie mit der Cul. Eine weitere Performancesteigerung besteht in der Möglichkeit, HM-Geräte direkt miteinander zu koppeln (sofern die das zulassen). Hab ich zum Beispiel mit einem Fenster-/Türschließer und einem Funk-UP-Schalter gemacht. Das reagiert dann wirklich in Echtzeit.

[SFAB]

Es scheint die schwäbische Alb ist Jung-CD500-Gebiet

Vielen Dank für Dein Feedback! Direktes Peeren ist leider aufgrund unterschiedlicher Protokolle nicht möglich (die HM-Unterputz-Aktoren sind zu groß für meine Bedingungen).

Aktueller Plan ist die 6-Fach-Aufputz-Taster von HM zu kaufen und an den sichtbaren Stellen von Jung CD500 auf AS500 umzusteigen und den Taster so zu integrieren. Dazu dann vermutlich noch ein CUL, aber erstmal schaue ich mir das ganze mit HMCCU und der CCU2 an.

[zap]

Grundsätzlich ist es möglich, im IO Device von HMCCU das Attribut rpcinterval auf 1 zu setzten, allerdings nur per Kommandozeile, nicht per Dropdown Menü.

Könnt ihr ja testweise mal machen. Wenn es den Rest von FHEM nicht merklich ausbremst, wird die Reaktionszeit der Taster dadurch beschleunigt. Die beste Variante ist natürlich das direkte peeren des Tasters mit dem Aktor in der CCU2. Geht natürlich nur, wenn wir uns in der Homematic Welt bewegen.

Derzeit sind die Eventbenachrichtigung durch die CCU und die Weitergabe an FHEM 2 asynchrone Prozesse, die über eine Filequeue kommunizieren. Daher keine Echtzeit. Ich hatte mal mit SubProcess und DevIO in FHEM experimentiert. Aber leider konnte FHEM die Daten nicht schnell genug verarbeiten und es kam zum Verlust von Events.

[Loredo]

Vielleicht geht es inzwischen mit SubProcess.pm besser zu lösen und man könnte den polling-Mechanismus wieder gehen ein pull ersetzen?

[chris1284]

HM-Geräte direkt miteinander zu koppeln (sofern die das zulassen)

das sollte eh immer erte wahl sein wenn das geht nicht nur wegen der performance sondern weil, egal ob cul oder ccu, die geräte trotz fehlendem server imme rnoch das tun was sie sollten (zb taster -> steckdose on). die anzeige in fhem ist ehr nebensächlich, nur wenn in fhem davon weitere vorgänge abhängen wird das timing wirklich interessant (taster -> notify -> nicht hm aktion zb)

@zap: gefühlt funktioniert rpcinterval 1 einwandfrei und die statusänderungen sind um einiges schneller da als per default einstellung

[zap]

Vielleicht geht es inzwischen mit SubProcess.pm besser zu lösen und man könnte den polling-Mechanismus wieder gehen ein pull ersetzen?

Soweit ich weiß war ich der letzte, der SubProcess etwas angepasst und mit diversen Timeouts experimentiert hat (in Abstimmung mit Boris). SubProcesss war auch nie das Problem. Vielmehr gab es Fehler beim schreiben der Events in den Filedescriptor, der in FHEM für die großen select-IO Schleife registriert war. Insbesondere, wenn sehr viele Events von der CCU kamen. Ich habe mit verschiedenen Socket I/O Puffereinstellungen und Timeouts gespielt (auf Betriebssystemebene). Das hat alles nix gebracht. FHEM/Perl ist hier einfach zu langsam.

Mittlerweile benutze ich SubProcess nur noch, um die RPC-Server Prozesse zu starten.

Ich plane jedoch eine etwas größere Umstellung mit einer der nächsten HMCCU Versionen, die die Reaktionszeit verbessern sollte. Statt Subprozesse will ich es mal mit Threads versuchen, die über Queues im Shared Memory kommunizieren.

[Yil]

Ich plane jedoch eine etwas größere Umstellung mit einer der nächsten HMCCU Versionen, die die Reaktionszeit verbessern sollte. Statt Subprozesse will ich es mal mit Threads versuchen, die über Queues im Shared Memory kommunizieren.

Bin gespannt ... 

[hein21]

Hallo,
ich versuche gerade (erfolglos), einen HM-Funkwandtaster 2-fach (HM PB 2 WM 55 2) in FHEM mit HMCCU einzubinden. Ich habe den Taster zunächst an die Homematic-Zentrale angelernt, und anschließend mittels "get CCU2 devicelist create ^Licht.* t=dev f=%n room=Homematic" in FHEM eingebunden (so hatte ich das mit allen anderen Devices bisher auch gemacht). Das klappt auch soweit (state ist "initialized"), aber beim Betätigen des Tasters leuchtet die LED nur orange auf, und an den Readings in FHEM ändert sich rein gar nichts.

Hat jemand eine Beispielkonfiguration für mich ? Ich möchte in FHEM nur erkennen, ob der Taster betätigt wurde oder nicht, also eine Veränderung im Reading (z.B. bei 1.Press_Short true/false) herbeiführen. Anschließend komme ich alleine weiter (ich möchte die Zustandsänderung an einen Loxone-Miniserver übergeben. Mit meinen anderen Homematic-Devices (z.B. Tür/Fensterkontakte oder Aktoren) klappt das auch alles, nur beim Taster stehe ich komplett auf dem Schlauch...)

Ich bin für jede Anregung dankbar!

[zap]

Habe den Taster bei mir eingebunden. Funktioniert. Poste mal bitte ein list des Device.

[hein21]

Hmm,
mit dem list TYPE-Befehl bekomme ich nichts angezeigt (ich habe list TYPE=HMCCUDEV NEQxxxx eingegeben).
Die raw Definition gibt folgendes aus:

defmod Lichtschalter_E HMCCUDEV NEQxxxx
attr Lichtschalter_E IODev CCU2
attr Lichtschalter_E room Homematic

setstate Lichtschalter_E 2017-03-02 22:26:59 1.PRESS_SHORT false
setstate Lichtschalter_E 2017-03-02 22:20:56 2.PRESS_SHORT false
setstate Lichtschalter_E 2017-03-02 22:26:59 hmstate false
setstate Lichtschalter_E 2017-03-02 23:02:32 state Initialized

[Wuppi68]

Hmm,
mit dem list TYPE-Befehl bekomme ich nichts angezeigt (ich habe list TYPE=HMCCUDEV NEQxxxx eingegeben).
Die raw Definition gibt folgendes aus:

defmod Lichtschalter_E HMCCUDEV NEQxxxx
attr Lichtschalter_E IODev CCU2
attr Lichtschalter_E room Homematic

setstate Lichtschalter_E 2017-03-02 22:26:59 1.PRESS_SHORT false
setstate Lichtschalter_E 2017-03-02 22:20:56 2.PRESS_SHORT false
setstate Lichtschalter_E 2017-03-02 22:26:59 hmstate false
setstate Lichtschalter_E 2017-03-02 23:02:32 state Initialized

ein

Code Auswählen Erweitern

list  Lichtschalter_E
bringt dich zum Ziel

[hein21]

Danke
Manchmal kann es so einfach sein...

Internals:
   DEF        NEQxxxx
   IODev      CCU2
   NAME       Lichtschalter_E
   NR         125
   STATE      Initialized
   TYPE       HMCCUDEV
   ccuaddr    NEQxxxx
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    Lichtschalter E
   ccutype    HM-PB-2-WM55-2
   channels   3
   statevals  devstate
   Readings:
     2017-03-02 22:26:59   1.PRESS_SHORT   false
     2017-03-02 22:20:56   2.PRESS_SHORT   false
     2017-03-02 22:26:59   hmstate         false
     2017-03-02 23:02:32   state           Initialized
Attributes:
   IODev      CCU2
   room       Homematic

[zap]

Versuche es mal mit folgenden Attributen:

Code Auswählen Erweitern


attr Lichtschalter_E ccureadingfilter PRESS
attr Lichtschalter_E event-on-update-reading [1-2].PRESS.*
attr Lichtschalter_E substitute (1|true):pressed


Hintergrund: Die PRESS_XX Datenpunkte werden nach dem Drücken des Schalters nicht wieder auf false gesetzt, sondern bei jedem Tastendruck mit true bzw. 1 aktualisiert. Wenn Du event-on-update-reading nicht setzt, gibt es keine Events, da sich der Inhalt des Readings nicht mehr ändert.

m.E. ist es besser, für die beiden Tasterkanäle jeweils an HMCCUCHN Device zu definieren. Dann kann man neben den Attributen oben noch folgende setzen (Beispiel geht davon aus, dass Lichtschalter_E1 sich auf Kanal 1 des Tasters bezieht):

Code Auswählen Erweitern


attr Lichtschalter_E statedatapoint 1.PRESS_SHORT
attr Lichtschalter_E statevals press:true
attr Lichtschalter_E webCmd press


Damit bekommst Du einen zusätzlichen Set-Befehl "press", mit dem ein Tastendruck simuliert werden kann.

Damit wird dann STATE auch immer korrekt gesetzt. Bei der HMCCUDEV Lösung kann müsste man ja 2 Kanäle auf STATE abbilden. Das funktioniert nicht.

Habe den Typ jetzt in die Liste der Default-Templates aufgenommen. Dann wird die Definition zukünftig einfacher.

[hein21]

Danke zap,
das hat jetzt soweit funktioniert, in beiden Varianten. Und ich habe wieder was dazugelernt.
Dennoch bleibt eine Frage: wie bekomme ich damit jetzt etwas angesteuert ? Momentan wird immer nur das Reading zeitlich aktualisiert, wenn ich den Button 1 oder 2 betätige, im Reading steht aber jeweils "Pressed". Wir kann ich dafür sorgen, dass dort nur "Pressed" steht (oder 1/true), wenn ich den Button auch tatsächlich presse (bzw. das Reading sich aktualisiert). Wenn ich den Button nicht betätige, soll das Reading am besten bei "Unpressed" (oder 0/false) bleiben.

Wie gesagt, ich möchte das im nächsten Schritt per UDP an einen Loxone-Miniserver weitergeben. Da reicht mir ein (kurzzeitiges) Signal, das anzeigt, dass der Button gerade eben betätigt wurde. Wenn das Reading des Buttons sofort nach loslassen wieder auf 0/false springt, wäre das völlig ok.
Geht sowas, oder gibt es alternative Möglichkeiten um eine wirkliche Zustandsänderung im Reading zu erfassen ?