Neues Modul HMCCU für Homematic CCU

[wolfgang99]

Danke! Mit 1. geht das wieder!! (hätte ich selbst sehen können (müssen)!

[zap]

EDIT erst wenn ich event-on-update-reading .* auf das device setzte logged es auch die per (+) erstellten readings was aber sicher nicht sinn der sache ist oder?

Ich kann das Problem nicht nachstellen. Ich habe bei einem meiner Temperatursensoren folgendes definiert:

ccureadingname 1.TEMPERATURE:+temp;1.HUMIDITY:+hum

Außerdem beide "event-on-" Attribute gelöscht. Danach zeigt der Eventmonitor wie erwartet folgende Events an:

2017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH 1.TEMPERATURE: 14
2017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH temp: 14
2017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH 1.DEWPOINT: 6.1
2017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH 14
2017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH hmstate: 14
2017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH 1.HUMIDITY: 57
2017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH hum: 57
2017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH 1.DEWPOINT: 6.1
2017-01-27 14:55:28 HMCCUDEV HM_KL_WR_TH hmstate: 14

Die beiden zusätzlichen Readings sind also enthalten.

[chris1284]

Ich habe nur ccudef-readingsname definiert, nichts in den devices selber. Evtl ist das der Grund . Ich teste morgen mal mit ccureadingasname

[zap]

Ich habe nur ccudef-readingsname definiert, nichts in den devices selber. Evtl ist das der Grund . Ich teste morgen mal mit ccureadingasname

wie sieht das ccudef-readingname aus?

[chris1284]

so

Code Auswählen Erweitern

^(.+\.)?AES_KEY$:sign;^(.+\.)?LOW_?BAT$:+battery;^(.+\.)?BATTERY_STATE:+batteryLevel;^(.+\.)?UNREACH$:Activity;^(.+\.)?SET_TEMPERATURE$:+desired-temp;^(.+\.)?HUMIDITY$:+humidity;^(.+\.)?LEVEL$:+pct;^(.+\.)?CONTROL_MODE$:+controlMode;^(.+\.)?ACTUAL_HUMIDITY:+humidity;^(.+\.)?ACTUAL_TEMPERATURE:+temperature;

[Loredo]

Die Attribute hmstatevals in HMCCUCHN/HMCCUDEV sowie das Attribut ccudef-hmstatevals in HMCCU erlauben nun eine weitgehend flexible Konfiguration der Ermittlung des HomeMatic Status.

Ganz herzlichen Dank dafür! Das klingt jetzt genau richtig 👍🏼

Kann es sein, dass es noch ein paar Bugs dabei gibt? Mir scheint es so, als wenn auch bei Nutzung des Datapoints trotzdem ccuscaleval vorher nicht berücksichtigt wird (weder bei der Regexp noch als resultierender Wert). Zum Beispiel werden Temperaturen mit den üblich vielen Nachkommstellen angezeigt, LEVEL hat nur Werte zwischen 0 und 1 und MOTION wird mit true/false dargestellt.
Aus irgendeinem Grund, den ich mir wiederum gar nicht erklären kann, wird DIRECTION gar nicht bei mir beachtet; WORKING hingegen schon, obwohl es erst nach DIRECTION aufgeführt ist.

Mache ich was falsch?

Dies sind meine Definitionen im I/O Device, an den HMCCU.+ Geräten selbst habe ich keine. (Der Übersicht halber hier mit Zeilenumbruch; vielleicht noch eine kleine Anregung die beim Einlesen aus den Attributen zu entfernen, dann könnte man das auch so übersichtlicher im Attribut direkt ablegen)

Code Auswählen Erweitern


attr CCU2 ccudef-hmstatevals UNREACH!(1|true):unreachable;\
FAULT_REPORTING!#1-3:err_f_${value};\
FAULT_REPORTING!5:err_f_${value};\
FAULT_REPORTING!#7-9:err_f_${value};\
ERROR_OVERHEAT!(1|true):err_overheated;\
ERROR_OVERLOAD!(1|true):err_overloaded;\
ERROR_REDUCED!(1|true):err_reduced;\
ERROR!#1-3:err_${value};\
ERROR!#5-9:err_${value};\
INHIBIT!(1|true):locked;\
DIRECTION!1:up;\
DIRECTION!2:down;\
DIRECTION!3:undefined;\
WORKING!(1|true):working;\
MOTION!.*:${MOTION};\
LEVEL!#0-0:off;\
LEVEL!#1-99:${LEVEL};\
LEVEL!#100-100:on;\
STATE!.*:${STATE};\
VALVE_STATE!.*:${VALVE_STATE};\
(ACTUAL_TEMPERATURE|ACTUAL_HUMIDITY)!.*:T: ${ACTUAL_TEMPERATURE} °C H: ${ACTUAL_HUMIDITY} %;\
CONTROL_MODE!.*:${CONTROL_MODE};\
(TEMPERATURE|HUMIDITY)!.*:T: ${TEMPERATURE} °C H: ${HUMIDITY} %;\
FAULT_REPORTING!6:warn_battery;\
LOW_?BAT!(1|true):warn_battery;\
ERROR!4:warn_battery;\
UNREACH!0:ok;\

attr CCU2 ccudef-readingformat datapoint
attr CCU2 ccudef-readingname ^(.+\.)?ACTUAL_HUMIDITY$:humidity;\
^(.+\.)?ACTUAL_TEMPERATURE$:measured-temp;\
^(.+\.)?AES_KEY$:sign;\
^(.+\.)?BATTERY_STATE$:batteryLevel;\
^(.+\.)?BRIGHTNESS$:brightness;\
^(.+\.)?CONTROL_MODE$:controlMode;\
^(.+\.)?DIRECTION$:direction;\
^(.+\.)?ENERGY_COUNTER$:energy;\
^(.+\.)?FREQUENCY$:frequency;\
^(.+\.)?HUMIDITY$:humidity;\
^(.+\.)?INHIBIT$:lock;\
^(.+\.)?LEVEL$:+pct;\
^(.+\.)?LEVEL$:level;\
^(.+\.)?LOW_?BAT$:battery;\
^(.+\.)?MOTION$:motion;\
^(.+\.)?PARTY_START_TIME$:partyStart;\
^(.+\.)?PARTY_STOP_TIME$:partyEnd;\
^(.+\.)?PARTY_TEMPERATURE$:partyTemp;\
^(.+\.)?POWER$:consumption;\
^(.+\.)?SET_TEMPERATURE$:desired-temp;\
^(.+\.)?TEMPERATURE$:temperature;\
^(.+\.)?UNREACH$:Activity;\
^(.+\.)?VALVE_STATE$:valve;\
^(.+\.)?VOLTAGE$:voltage;\
^(.+\.)?WORKING$:working;\

attr CCU2 ccudef-substitute AES_KEY!(0|false):off,(1|true):on;\
CONTROL_MODE!0:auto,1:manual,2:party,3:boost;\
DIRECTION!0:stop,1:up,2:down,3:undefined;\
INHIBIT!(0|false):unlocked,(1|true):locked;\
LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;\
MOTION!(0|false):noMotion,(1|true):motion;\
UNREACH!(0|false):alive,(1|true):dead;\
WORKING!(0|false):false,(1|true):true;\

attr CCU2 rpcinterval 2
attr CCU2 rpcport 2001,2010,9292
attr CCU2 rpcserver on
attr CCU2 stateFormat rpcstate/state


[zap]

Ganz herzlichen Dank dafür! Das klingt jetzt genau richtig 👍🏼

Bitte schön. Ich habe schon mit dem Gedanken gespielt, es Loredo-Release zu nennen

Kann es sein, dass es noch ein paar Bugs dabei gibt? Mir scheint es so, als wenn auch bei Nutzung des Datapoints trotzdem ccuscaleval vorher nicht berücksichtigt wird (weder bei der Regexp noch als resultierender Wert). Zum Beispiel werden Temperaturen mit den üblich vielen Nachkommstellen angezeigt, LEVEL hat nur Werte zwischen 0 und 1 und MOTION wird mit true/false dargestellt.
Aus irgendeinem Grund, den ich mir wiederum gar nicht erklären kann, wird DIRECTION gar nicht bei mir beachtet; WORKING hingegen schon, obwohl es erst nach DIRECTION aufgeführt ist.

Mache ich was falsch?

Für die Definitionen in hmstatevals greifen ccuscaleval, substitute und stripnumber nicht. HMCCUDEV und HMCCUCHN speichern die aktuellen Werte all ihrer Datenpunkte im hash des jeweiligen Gerätes (mach mal ein list). Dabei werden die Originalwerte gespeichert, nicht die umformatierten. Ich schau mir das mal an ...

Bei DIRECTION fällt mir auf, dass das in Deinem Regelset mehrfach vorkommt. Sollte eigentlich kein Problem darstellen, aber ändere es trotzdem mal ab (hinter einem Datenpunktnamen kann eine Liste von Ersetzungen angegeben werden, analog substitute):

DIRECTION!1:up,2:down,3:undefined

[Loredo]

Bitte schön. Ich habe schon mit dem Gedanken gespielt, es Loredo-Release zu nennen

Ich gehe ja noch immer davon aus, dass es auch andere brauchen können

Dabei werden die Originalwerte gespeichert, nicht die umformatierten. Ich schau mir das mal an ...

Ok, das wäre prima!

DIRECTION!1:up,2:down,3:undefined

Wenn ich so zusammenfasse, geht es in der Tat. Habe ich auch mit den anderen Dopplungen jetzt mal vorsichtshalber gemacht.

[scm35768]

Hallo zusammen,

gibt es irgendwo eine Übersicht, welche HM-Devices mit dem Modul HMCCU funktionieren? Ich versuche seit einiger Zeit erfolglos folgende Wired-Typen einzubinden:

HMW-IO-12-Sw7-DR
HMW-IO-12-Sw14-DR

folgende Wired-Typen funktionieren ohne Probleme bei mir:

HMW-LC-Bl1-DR
HMW-Sen-SC-12-DR

Wenn ich ein get ccu3 devicelist dump absetze, sehe ich die HMW-IO-12-Sw7-DR und HMW-IO-12-Sw14-DR mit allen channels, ansprechen kann ich Sie aber nicht. Bei diesen beiden Typen kommt auf ein

get ccu3 device info MEQ0278851

nur folgendes:

DPT {i} Gateway-DP = 28 [RWE]
DPT {s} Gateway-IPDP =  [RWE]
DPT {s} SMS =  [W]
DPT {s} EMail =  [W]


bei einem get ccu3 dump devtypes erscheinen die beiden Typen gar nicht.

Kann mir bitte jemand sagen, ob diese Devices unterstützt werden? Oder mir einen Tipp geben, wie ich diese beiden Typen einbinden kann?

Vielen Dank und viele Grüße

[zap]

Grundsätzlich sollten alle Devices, die in der CCU angelernt sind, auch aus HMCCU ansprechbar sein. Ich habe da keine Device spezifischen Sachen drin.

Die Ausgabe von get devicinfo sieht jedenfalls seltsam aus. Die Kanalangaben fehlen.

Kannst Du für die Devices in FHEM Geräte anlegen (mit HMCCUDEV)? Oder kommt da eine Fehlermeldung?

Mach mal bitte ein get ccu3 devicelist ohne "dump" und danach nochmal ein get ccu3 deviceinfo <name>
Stehen nach der Ausführung dieses Befehls Fehlermeldungen im FHEM Log?

[scm35768]

Hallo zap,

erstmal Danke für die Antwort. Wenn ich get ccu3 devicelist absetze, dann kommt als Antwort

Read 172 devices/channels from CCU

Hier werden alle Devices erkannt. Auch der HMW-IO-12-Sw7-DR ist dabei. Im Log File kommt dazu keine Fehlermeldung oder sowas.


Beim get ccu3 devicelist dump sieht man die Channels:

Device "12SW7001" [MEQ0278851] Type=HMW-IO-12-Sw7-DR
  Channel 0 "12SW7001:0" [MEQ0278851:0]
  Channel 1 "12SW7001:T1" [MEQ0278851:1]
  Channel 2 "12SW7001:T10" [MEQ0278851:10]
  Channel 3 "12SW7001:T11" [MEQ0278851:11]
  Channel 4 "12SW7001:T12" [MEQ0278851:12]
  Channel 5 "12SW7001:L1" [MEQ0278851:13]
  Channel 6 "12SW7001:L2" [MEQ0278851:14]
  Channel 7 "12SW7001:L3" [MEQ0278851:15]
  Channel 8 "12SW7001:L4" [MEQ0278851:16]
  Channel 9 "12SW7001:L5" [MEQ0278851:17]
  Channel 10 "12SW7001:L6" [MEQ0278851:18]
  Channel 11 "12SW7001:L7" [MEQ0278851:19]
  Channel 12 "12SW7001:T2" [MEQ0278851:2]
  Channel 13 "12SW7001:T3" [MEQ0278851:3]
  Channel 14 "12SW7001:T4" [MEQ0278851:4]
  Channel 15 "12SW7001:T5" [MEQ0278851:5]
  Channel 16 "12SW7001:T6" [MEQ0278851:6]
  Channel 17 "12SW7001:T7" [MEQ0278851:7]
  Channel 18 "12SW7001:T8" [MEQ0278851:8]
  Channel 19 "12SW7001:T9" [MEQ0278851:9]


Was mich halt stutzig macht ist die seltsame ausgäbe von get ccu3 deviceinfo MEQ0278851.

Vielleicht habe ich ja auch nur ein Verständnisproblem:

Ist es richtig, für das ganze HMW-IO-12-Sw7-DR einmal ein Device anzulegen, z.B. so:

defmod Licht1 HMCCUDEV BidCos-Wired.MEQ0278851
attr Licht1 IODev ccu3
attr Licht1 event-on-change-reading .*
attr Licht1 event-on-update-reading .*
attr Licht1 room KG.Raum1
attr Licht1 statevals on:true,off:false

Oder für die einzelnen Channels ein eigenes Device?

Mit der obigen Definition sehe ich einzelne Readings nach Betätigung der Taster:

Readings
1.PRESS_LONG
1
2017-01-28 22:51:22
1.PRESS_SHORT
1
2017-01-28 22:55:04
13.STATE
0
2017-01-28 22:55:06
13.WORKING
0
2017-01-28 22:55:06
14.STATE
0
2017-01-28 22:54:54
14.WORKING
0
2017-01-28 22:54:54
15.STATE
0
2017-01-28 22:54:52
15.WORKING
0
2017-01-28 22:54:52
16.STATE
0
2017-01-28 22:54:52
16.WORKING
0
2017-01-28 22:54:52
17.STATE
0
2017-01-28 22:54:50
17.WORKING
0
2017-01-28 22:54:50
18.STATE
0
2017-01-28 22:54:50
18.WORKING
0
2017-01-28 22:54:50
19.STATE
0
2017-01-28 22:54:56
19.WORKING
0
2017-01-28 22:54:56

Ich kann aber keine States verändern, oder ich stelle mich zu dumm:

set Licht1 datapoint 13.STATE on

kommt immer

HMCCUDEV: Licht1 Invalid datapoint


Nochmals vielen Dank für die Hilfe!!!!

[ukobusch]

Hallo zusammen,

eine Frage als Newbie, da ich scheinbar nicht die richtigen Stellen im Forum und in der commandref finde.
Ich nutze mit Schwerpunkt die CCU2 und habe mit HMCCU diverse andere Elemente angebunden (Harmony, Bose Soundtouch etc). Das klappt alles prima.
Nun möchte ich einfach nur zyklisch alle 60 min die Aussentemperatur vom Yahoo-Wetter (Device: Wetter, reading: temp_c) jede Stunde in eine Variable auf der CCU2 (mit Namen Aussentemperatur) schreiben, damit ich sie dort nutzen kann.
Genutzt habe ich den at-Befehl:

define aussen_temperatur_zyklisch at +*00:60:00 set my_ccu var Aussentemperatur temp_c

Wie sage ich FHEM, dass es sich bei "temp_c" um das ReadingVal von "Wetter" handelt? Ein Link an die richtige Stelle der commandref oder ins Forum fände ich auch super.

Vielen Dank
Gruß
Ulli

[chris1284]

Die Antwort hast du schon selbst genannt ReadinsVal("Wetter","temp_c", 99.0) statt temp_c nehmen

[zap]

@scm35768

Bitte mach mal ein get Licht1 update

Danach ein list Licht1  sowie ein get Licht1 deviceinfo

Die Ergebnisse bitte posten

[ukobusch]

@chris1284: funzt leider nicht. Irgendwo habe ich einen Gedanken- oder Schreibfehler. Ich erhalte in der Systemvariable in der CCU2 immer nur eine 0. Also wird der falsche Wert gelesen.
Aber das device heisst tatsächlich "Wetter".