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).
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.
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.
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.
Vielleicht geht es inzwischen mit SubProcess.pm besser zu lösen und man könnte den polling-Mechanismus wieder gehen ein pull ersetzen?
Zitat von: Yil am 12 Dezember 2016, 00:16:05
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
Zitat von: Loredo am 29 Dezember 2016, 17:32:42
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.
ZitatIch 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 ... ;)
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!
Habe den Taster bei mir eingebunden. Funktioniert. Poste mal bitte ein list des Device.
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
Zitat von: hein21 am 03 März 2017, 08:08:19
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
list Lichtschalter_E bringt dich zum Ziel
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
Versuche es mal mit folgenden Attributen:
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):
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.
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 ?
Das Reading automatisch auf "released" oder false zurück zu setzen, macht bei einem Taster wenig sinn. Du würdest dann das "pressed" im Zweifel übersehen.
Wenn Du event-on-updte-reading wie oben beschrieben setzt, generiert FHEM ein Event bei jedem Tastendruck. Dieses Event kannst Du per Notify abfangen und als Reaktion darauf ein programm ausführen oder irgendwas anderes auslösen.
Tja, Deine Worte in FHEM-Anfängers Ohren... wenn das mal alles so einfach wäre, für mich zumindest nicht ???
Ich habe jetzt folgendes umgesetzt:
define Lichtschalter_E dummy
attr Lichtschalter_E event-on-update-reading state
attr Lichtschalter_E room Homematic
define Licht_E_an notify 1.PRESS_SHORT:* set Lichtschalter_E on
define Licht_E_aus notify 2.PRESS_SHORT:* set Lichtschalter_E off
Lichtschalter_E zeigt immer nur "pressed", und die notifys "Licht_E_an" und Licht_E_aus" zeigen "active", sonst tut sich nichts.
Nachtrag:
Der Eventmonitor zeigt immerhin beim Betätigen des Tasters folgendes an: HMCCUCHN Button1_E 1.PRESS_SHORT: pressed
Ich habe dann mal genau das in den Notify übernommen:
define Licht_E_an notify HMCCUCHN Button1_E 1.PRESS_SHORT:pressed set Lichtschalter_E on
define Licht_E_aus notify HMCCUCHN Button2_E 2.PRESS_SHORT:pressed set Lichtschalter_E off
Leider genau das gleiche... nix. Lichtschalter_E bleibt "pressed", und aktualisieren tut sich da auch nichts.
HMCCUCHN Button1_Elias 1.PRESS_SHORT: pressed
Hallo,
ich nochmal. Nach längerer Probiererei hat dann das hier funktioniert. Vielleicht hilft es jemandem weiter:
define Lichtschalter_E HMCCUDEV NEQxxxx
attr Lichtschalter_E IODev CCU2
attr Lichtschalter_E event-on-update-reading [1-2].PRESS_.*
attr Lichtschalter_E room Homematic
attr Lichtschalter_E statevals on:off
define Licht_E dummy
attr Licht_E event-on-update-reading state
attr Licht_E room Homematic
define Licht_E_an notify Lichtschalter_E.1.PRESS_SHORT:.* set Licht_E on
define Licht_E_aus notify Lichtschalter_E.2.PRESS_SHORT:.* set Licht_E off