HMCCU Beispiel Geräte-Definitionen

[zap]

Wenn mich mein Mieter fragen würde, würde ich es ihm sogar erlauben

[Macblock]

Hallo zusammen,

hat vielleicht jemand schon den Neigungssensor HM-Sec-TiS über HMCCU angeschlossen und kann mir sagen, wie das aussehen muss?

Vielen Dank und viele Grüße

Markus

[zap]

Grundsätzliche Vorgehensweise beim Einbinden neuer Geräte:

* In CCU anlernen
* Namen des Gerätes und seiner Kanäle in der CCU2 nach eigenen Bedürfnissen anpassen
* Im I/O Device von HMCCU einmal "get devicelist" ausführen
* Im I/O Device einmal "get deviceinfo CCU2-Devname" ausführen mit CCU2-Devname = Name des neuen Gerätes in der CCU2. Das gibt einen ersten Indikator, welche Datenpunkte nützlich sind. Ggf. kann man auch hier nachlesen: http://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/hm_devices_Endkunden.pdf
* Aufgrund der Infos vorher entscheiden, ob man nur einen Kanal benötigt (HMCCUCHN verwenden) oder mehrere Kanäle (HMCCUDEV)
* Device in FHEM definieren
* Attribute setzen wie z.B. ccureadingfilter, um nur die notwendigen Datenpunkte in Readings zu speichern. Vielleicht noch ccureadingformat auf datapoint setzen, damit die Readingsnames kürzer werden. Dann noch event-on-change-reading auf .* setzen (bei Tastern event-on-update-reading = .*).

Damit dürftest Du ziemlich weit kommen. Speziell beim Neigungssensor

Code Auswählen Erweitern


define mysensor HMCCUCHN Kanalname
attr mysensor ccureadingformat datapoint
attr mysensor ccureadingfilter (LOWBAT|STATE)
attr mysensor event-on-change-reading .*
attr statedatapoint 1.STATE
attr substitute LOWBAT!(0|false):no,(1|true):yes


Leider weiß ich nicht, welche Werte STATE annehmen kann. Das musst Du ausprobieren und substitute entsprechend ergänzen.

[Yil]

Hi zap,

sehr gute Mini-Anleitung. Verlink diesen letzten Beitrag von Dir mal ganz an den Anfang - das hilft sicherlich vielen beim Einstieg in dieses Modul! 

VG Yil

[eddie8]

Ich habe einen HM-PB-2-WM55. Für jede der beiden Tasten habe ich ein HMCCUCHN Device definiert:

Code Auswählen Erweitern


define meinetaste HMCCUCHN TasterKanal1
attr meinetaste ccureadingfilter (LOWBAT|UNREACH|PRESS)
attr meinetaste ccureadingformat datapoint
attr meinetaste statedatapoint PRESS_SHORT
attr meinetaste statevals  press:true
attr meinetaste substitute 1|true:pressed


Wichtig ist, in diesem Fall nicht event-on-change-reading zu setzen sondern ggf. event-on-update-reading = .*

Es ist zwar schon ein Weilchen her, aber ich hab mich jetzt erst an die endgültige Umsetzung gemacht. Es funktioniert, ich hab aber noch eine Frage zum notify:

Code Auswählen Erweitern


define N_WoZiHeimkinoOn notify WoZi_Taster_oben set WoZi_Heimkino on


Funktioniert, unterscheidet aber nicht zwischen long_press/short_press (völlig logisch!)

Das sind in der "DeviceOverview" die "Readings":
1.PRESS_LONG                   pressed   2017-01-07 16:48:10
1.PRESS_LONG_RELEASE  pressed   2017-01-07 16:48:10
1.PRESS_SHORT                pressed    2017-01-07 16:49:05
state                                   pressed    2017-01-07 16:49:05

Klappt also auch prima! Nun bin ich der Meinung, dass es zB so funktionieren sollte:

Code Auswählen Erweitern


define N_WoZiHeimkinoOn notify WoZi_Taster_oben:1.PRESS_LONG set WoZi_Heimkino on


Dann passiert aber gar nichts mehr (testhalber auch mal ohne das "1." versucht).
Das Attribut "statedatapoint", das oben zum Device angelegt wurde, bleibt immer auf "PRESS_SHORT" stehen. Vermutlich hängt es damit zusammen, dass das Notify hinter dem Doppelpunkt nicht die Readings, sondern dieses Attribut ausliest, das aber nicht gesetzt wird?

[zap]

Schau doch erst mal im FHEM Eventmonitor, welche Events kommen, wenn Du die Taste kurz/lang drückst. Dann kannst Du schon mal prüfen,, ob die Events korrekt kommen.

[Vorhand]

Hab' auch den Bewegungsmelder mit den Tasten HM-Sen-MDIR-WM55 im Einsatz.
MOTION nimmt 1 oder 0 an. Deshalb wird es wohl auch mit "event-on-change-reading" erfasst.

Bei den Tastern geht das leider nicht.
PRESS_SHORT bleibt immer auf 1 stehen. Es kann auch nur mit  "event-on-update-reading" erfasst werden, aber die 1 bleibt immer - lediglich an Datum und Zeit erkennt man das Ereignis.
Das Gleiche gilt bei PRESS_LONG, auch hier immer 1.
Als attr genügt IODev und event-on-change-reading.

Damit kann ich kein StateIcon - wie bei MOTION - ansteuern.
Was mache ich bei der Abfrage evt. falsch?

[zap]

devStateIcon ersetzt ja den Inhalt von STATE durch ein Symbol. Grundsätzlich geht das, allerdings wird bei MOTION immer das gleiche Icon angezeigt werden, weil sich der Inhalt ja nie ändert.

Zunächst musst Du Deinem Device mitteilen, welchen Datenpunkt er in state/STATE übernehmen soll. Bei einem HMCCUDEV Device setzt Du folgendes Attribut:

statedatapoint n.MOTION

wobei n die Kanalnummer des Datenpunktes MOTION ist. Bei einem HMCCUCHN Device läßt Du "n." weg.

Dann solltest Du den Wert von MOTION ersetzen, da hier 0/1 oder false/true kommen kann. Das machst Du mit

substitute MOTION!(0|false):noMotion,(1|true):motion

Nun kannst Du das Stateicon setzen:

devStateIcon motion:xyz noMotion:abc

Problem: abc wird niemals angezeigt werden.

[Vorhand]

Danke für die schnelle Antwort, die leider nicht mein Problem treffen. Offensichtlich hab ich das missverständlich formuliert.
Neuer Versuch:
Motion ist kein Problem. Hier kommt 1/0, so dass ich das StatIcon ansteuern kann.

Probleme habe ich bei der Auswertung der Tasterfunktionen, die bleiben immer auf 1 stehen - sowohl beim state SHORT_PRESS als auch LONG_PRESS.

Die readings kann man schön im Eventmonitor sehen. Leider kommt nie eine 0, wenn man die Taste loslässt.
Im Moment hab' ich keine Idee, wie ich die Tastfunktionen in fhem verwenden kann.

[zap]

Probleme habe ich bei der Auswertung der Tasterfunktionen, die bleiben immer auf 1 stehen - sowohl beim state SHORT_PRESS als auch LONG_PRESS.

Die readings kann man schön im Eventmonitor sehen. Leider kommt nie eine 0, wenn man die Taste loslässt.
Im Moment hab' ich keine Idee, wie ich die Tastfunktionen in fhem verwenden kann.

Ach so. Das kenne ich. Die CCU2 schickt leider keine 0-Werte, wenn die Taste losgelassen wird. Verwenden kannst Du es in FHEM aber trotzdem. Du setzt event-on-update-reading auf PRESS_.*. Jedes entsprechende PRESS-Event ist dann ein Tastendruck. So nutze ich das selbst auch.

Einzige Ausnahme: es gibt ein PRESS_LONG_RELEASE. Das geht auf 1 wenn nach einem langen Tastendruck die Taste losgelassen wird (angeblich, nicht getestet). Das könnte ich Modul intern so auswerten, dass in dem Fall PRESS_LONG auf 0 zurück gesetzt wird. Leider gibt es kein PRESS_SHORT_RELEASE

[thomas.kregelin]

Ich habe mir kürzlich ein paar HMIP Geräte zugelegt, an eine neue CCU2 angelernt und per HMCCU in Fhem eingebunden.

Vielen Dank an zap und die vielen Beitragenden für die tolle und mit Sicherheit sehr mühsame Arbeit die in Fhem einfließt! Klasse, was man inzwischen mit Fhem alles machen kann.

Hier eine neue Konfiguration, die ich zu großen Teilen von DaDiGi abgeleitet habe.

Wandthermostat HMIP-WTH-2

Device-Info:

Code Auswählen Erweitern

CHN 000A9569A32F96:0 Guestroom_1.HMIP-WTH-2:0
  DPT {b} HmIP-RF.000A9569A32F96:0.CONFIG_PENDING = false [RE]
  DPT {b} HmIP-RF.000A9569A32F96:0.DUTY_CYCLE = false [RE]
  DPT {b} HmIP-RF.000A9569A32F96:0.LOW_BAT = false [RE]
  DPT {f} HmIP-RF.000A9569A32F96:0.OPERATING_VOLTAGE = 3.000000 [RE]
  DPT {n} HmIP-RF.000A9569A32F96:0.RSSI_DEVICE = 197 [RE]
  DPT {n} HmIP-RF.000A9569A32F96:0.RSSI_PEER = 206 [RE]
  DPT {b} HmIP-RF.000A9569A32F96:0.UNREACH = false [RE]
  DPT {b} HmIP-RF.000A9569A32F96:0.UPDATE_PENDING = false [RE]
CHN 000A9569A32F96:1 Guestroom_1.HMIP-WTH-2:1
  DPT {i} HmIP-RF.000A9569A32F96:1.ACTIVE_PROFILE = 1 [WE]
  DPT {f} HmIP-RF.000A9569A32F96:1.ACTUAL_TEMPERATURE = 21.300000 [RE]
  DPT {b} HmIP-RF.000A9569A32F96:1.BOOST_MODE = false [WE]
  DPT {f} HmIP-RF.000A9569A32F96:1.CONTROL_DIFFERENTIAL_TEMP =  [WE]
  DPT {i} HmIP-RF.000A9569A32F96:1.CONTROL_MODE =  [WE]
  DPT {i} HmIP-RF.000A9569A32F96:1.DURATION_UNIT =  [W]
  DPT {i} HmIP-RF.000A9569A32F96:1.DURATION_VALUE =  [W]
  DPT {b} HmIP-RF.000A9569A32F96:1.FROST_PROTECTION = false [RE]
  DPT {i} HmIP-RF.000A9569A32F96:1.HEATING_COOLING = 0 [RWE]
  DPT {i} HmIP-RF.000A9569A32F96:1.HUMIDITY = 58 [RE]
  DPT {b} HmIP-RF.000A9569A32F96:1.PARTY_MODE = false [RE]
  DPT {f} HmIP-RF.000A9569A32F96:1.PARTY_SET_POINT_TEMPERATU = 0.000000 [RE]
  DPT {s} HmIP-RF.000A9569A32F96:1.PARTY_TIME_END =  [RWE]
  DPT {s} HmIP-RF.000A9569A32F96:1.PARTY_TIME_START =  [RWE]
  DPT {i} HmIP-RF.000A9569A32F96:1.SET_POINT_MODE = 0 [RWE]
  DPT {f} HmIP-RF.000A9569A32F96:1.SET_POINT_TEMPERATURE = 15.500000 [RWE]
  DPT {b} HmIP-RF.000A9569A32F96:1.SWITCH_POINT_OCCURED = false [RE]
  DPT {i} HmIP-RF.000A9569A32F96:1.WINDOW_STATE = 0 [WE]

Definition:

Code Auswählen Erweitern

define CCU2.Guestroom_1.HMIP_WTH_2 HMCCUDEV 000A9569A32F96
attr CCU2.Guestroom_1.HMIP_WTH_2 IODev CCU2_0
attr CCU2.Guestroom_1.HMIP_WTH_2 ccureadingfilter (ACTUAL_TEMPERATURE|ACTIVE_PROFILE|BOOST_MODE|SET_POINT|PARTY|HUMIDITY|WINDOW_STATE|LOW_BAT)
attr CCU2.Guestroom_1.HMIP_WTH_2 controldatapoint 1.SET_POINT_TEMPERATURE
attr CCU2.Guestroom_1.HMIP_WTH_2 event-on-change-reading .*
attr CCU2.Guestroom_1.HMIP_WTH_2 room CCU2
attr CCU2.Guestroom_1.HMIP_WTH_2 stateFormat measured temperature: Guestroom_1.HMIP-WTH-2.1.ACTUAL_TEMPERATURE
attr CCU2.Guestroom_1.HMIP_WTH_2 statedatapoint ACTUAL_TEMPERATURE
attr CCU2.Guestroom_1.HMIP_WTH_2 substitute LOW_BAT!(0|false):ok,(1|true):low;;;;WINDOW_STATE!(true|1):Open,(false|0):Closed
attr CCU2.Guestroom_1.HMIP_WTH_2 webCmd control
attr CCU2.Guestroom_1.HMIP_WTH_2 widgetOverride control:slider,10,1,25

@zap:
Nimmst du solche Konfigurationen in ein Template auf, damit man beim Einbinden weiterer Geräte der gleichen Art Standardeinstellungen erhält?
Brauchst du dafür noch weitere Informationen?

[Spielmann]

Probleme habe ich bei der Auswertung der Tasterfunktionen, die bleiben immer auf 1 stehen - sowohl beim state SHORT_PRESS als auch LONG_PRESS.

Die readings kann man schön im Eventmonitor sehen. Leider kommt nie eine 0, wenn man die Taste loslässt.
Im Moment hab' ich keine Idee, wie ich die Tastfunktionen in fhem verwenden kann.

Ich habe das so gelöst, dass ich das Reading per setreading wieder auf 0 setze.

Gruß
Spielmann

[Vorhand]

Du setzt event-on-update-reading auf PRESS_.*. Jedes entsprechende PRESS-Event ist dann ein Tastendruck.

Auch dieses attr ändert nichts an state - im Gegenteil - in den Readings passiert dann gar nichts mehr.
Nur wenn ich statedatapoint auf z.B. PRESS_SHORT setze ändert sich state, allerdings nur der timestamp.

Ich habe das so gelöst, dass ich das Reading per setreading wieder auf 0 setze.

Wie müsste der Code für das "setreading" genau aussehen?

Frage: Hat denn schon jemand den HM-Sen-MDIR-WM55 komplett ausgewertet mit den 4 Unterfunktionen 0...3 ?
:0 keine Ahnung?
:1 steht für untere Taste - klappt nicht
:2 steht für obere Taste - klappt nicht
:3 steht für MOTION - das klappt bei mir mit folgendem Code:
define HM_BM_Bwm HMCCUCHN MEQ185xxx9:3
attr HM_BM_Bwm IODev d_ccu
attr HM_BM_Bwm devStateIcon 0:message_presence_disabled 1:motion_detector@red
attr HM_BM_Bwm devStateStyle style="text-align:right;;"
attr HM_BM_Bwm event-on-change-reading .*
attr HM_BM_Bwm icon message_presence
attr HM_BM_Bwm room Homatic
attr HM_BM_Bwm statedatapoint MOTION

[Spielmann]

Wie müsste der Code für das "setreading" genau aussehen?

Ich mache viel mit DOIF. Hier mal exemplarisch wie ich das meine:

define licht_einschalten DOIF ([HM_BM_Bwm] == 1) (set licht on, setreading HM_BM_Bwm 0) DOELSE (set licht off)

Ich bin noch nicht so Syntaxfest dass ich es aus dem Kopf kann und habe jetzt kein Zugriff auf mein fhem (vemutlich sind hier noch Fehler drin).

Frage: Hat denn schon jemand den HM-Sen-MDIR-WM55 komplett ausgewertet mit den 4 Unterfunktionen 0...3 ?

Ich habe auch so ein Teil zum Experimentieren und schon teilweise Attribute gesetzt. Vielleicht komme ich heute Abend dazu es zu posten.

Gruß
Spielmann

[zap]

Frage: Hat denn schon jemand den HM-Sen-MDIR-WM55 komplett ausgewertet mit den 4 Unterfunktionen 0...3 ?
:0 keine Ahnung?
:1 steht für untere Taste - klappt nicht
:2 steht für obere Taste - klappt nicht
:3 steht für MOTION - das klappt bei mir mit folgendem Code:
define HM_BM_Bwm HMCCUCHN MEQ185xxx9:3
attr HM_BM_Bwm IODev d_ccu
attr HM_BM_Bwm devStateIcon 0:message_presence_disabled 1:motion_detector@red
attr HM_BM_Bwm devStateStyle style="text-align:right;;"
attr HM_BM_Bwm event-on-change-reading .*
attr HM_BM_Bwm icon message_presence
attr HM_BM_Bwm room Homatic
attr HM_BM_Bwm statedatapoint MOTION

Das Teil ist hier beschrieben: http://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/hm_devices_Endkunden.pdf

Kanal 0 ist immer der Statuskanal. Der enthält solche Datenpunkte wie LOWBAT oder UNREACH. Einfach mal get deviceinfo ausführen.

Wenn Du sowas in ein HMCCUDEV Device packen möchtest, versuch doch mal das (nicht getestet, habe das Gerät nicht):

Code Auswählen Erweitern


ccureadingformat datapoint
ccureadingname 1.PRESS_(SHORT|LONG):press_one,2.PRESS_(SHORT|LONG):press_two
event-on-update-reading ^press.*
eventMap /datapoint 1.PRESS_SHORT true:press-one/datapoint 2.PRESS_SHORT true:press-two/
ccureadingfilter (LOWBAT|UNREACH|PRESS|MOTION)
statedatapoint 3.MOTION
substitute MOTION!(0|false):nomotion,(1|true):motion;PRESS_SHORT,PRESS_LONG!(1|true):pressed


Sollte Dir jedes Mal ein Event schicken, wenn Du eine der Tasten drückst. ccureadingname mappt hier PRESS_LONG und PRESS_SHORT auf ein Reading press_one bzw. press_two.
Da MOTION vom Typ BOOL ist, nehme ich an, hier schickt die CCU tatsächlich true oder false bzw 1 oder 0.