Neues Modul HMCCU für Homematic CCU

[aski71]

Habe die Ursache gefunden. Die CUxD Devices werden in der CCU mit einem bestimmten Typ angelegt (einem original Homematic Typ). Leider unterscheiden sich die Datenpunkte des CUxD Devices von denen des original Homematic Typen.

In Deinem Fall hat also die CUxD Steckdose andere Datenpunkte als eine Homematic Steckdose, wird aber als solche von der Zentrale verwaltet. Wenn HMCCU nun mit get devicelist alle Geräte der CCU abfragt, merkt es sich die verfügbaren Datenpunkte je Gerätetyp. Da hier 2 Devices sich als gleicher Gerätetyp ausgeben aber unterschiedliche Datenpunkte liefern, überschreiben sie sich gegenseitig. Das ist echt übel. Da muss ich erst mal drüber nachdenken, wie man das umgehen kann. Jedenfalls nicht ohne Update.

Oha. 
Und wieso ging das dann vorher?

[zap]

Oha. 
Und wieso ging das dann vorher?

Weil HMCCU bisher nicht geprüft hat, ob ein Datenpunkt gültig ist. Der Befehl wurde einfach an die CCU geschickt. Leider hat das in einigen Fällen die CCU ins Straucheln gebracht. Daher habe ich die Prüfung eingebaut.

Bitte gedulde Dich bis morgen. Ich checke heute noch ein Update ein. Habe zwar etwas Bedenken wegen eventueller Seiteneffekte, läuft aber bei mir momentan stabil.

Oder Du ziehst Dir die alte Version aus dem bisherigen Contrib-Pfad.

[aski71]

Weil HMCCU bisher nicht geprüft hat, ob ein Datenpunkt gültig ist. Der Befehl wurde einfach an die CCU geschickt. Leider hat das in einigen Fällen die CCU ins Straucheln gebracht. Daher habe ich die Prüfung eingebaut.

Bitte gedulde Dich bis morgen. Ich checke heute noch ein Update ein. Habe zwar etwas Bedenken wegen eventueller Seiteneffekte, läuft aber bei mir momentan stabil.

Oder Du ziehst Dir die alte Version aus dem bisherigen Contrib-Pfad.

Ah, verstehe. Das macht natürlich Sinn.
Ich warte auf die neue Version.

[zap]

Die Version mit den Anpassungen für CUxD Datenpunkte sollte jetzt im Update sein. Bitte beachten: nach dem Neustart von FHEM bzw nach einem get Devicelist muss sich das Internal ccutype der FHEM Devices in "CUX-..." ändern. Falls das nicht passiert, müssen die Devices per Click auf DEF neu angelegt werden. Hat bei mir aber automatisch funktioniert.

[Hellspawn]

Hallo Miteinander,
habe heute Devices per AutoCreate angelegt. Hat auch soweit gut funktioniert.
Wäre es denn aber nicht sinniger wenn die Templates in HMCCUConf.pm automatisch gegriffen werden ?
Das hat bei mir nicht funktioniert (wenn es denn so gewünscht ist).
Ich musste mit einem get / set Default die Templates laden, natürlich für die jeweiligen Devices.

Ich hab auch noch eine Erweiterung für die Templates nämlich die alten Homematic Steckdosen.

Code Auswählen Erweitern

"HM-LC-Sw1-Pl-DN-R1" => {       # Steckdose     
        ccureadingfilter => "(STATE|UNREACH)",
        controldatapoint => "1.STATE",
        statechannel     => 1,
        statevals        => "on:true,off:false",
        substitute       => "STATE!(1|true):on,(0|false):off;(true|1):yes,(false|0):no",
        webCmd           => "control",
        widgetOverride   => "control:uzsuToggle,off,on"
        },

Ich hab das bei mir eingetragen, funktioniert genauso wie die neuen Steckdosen. Könnte man ja generell übernehmen ?

Gruß
Carsten

[aski71]

Die Version mit den Anpassungen für CUxD Datenpunkte sollte jetzt im Update sein. Bitte beachten: nach dem Neustart von FHEM bzw nach einem get Devicelist muss sich das Internal ccutype der FHEM Devices in "CUX-..." ändern. Falls das nicht passiert, müssen die Devices per Click auf DEF neu angelegt werden. Hat bei mir aber automatisch funktioniert.

Topp! Funktioniert wieder!
Vielen Dank für die schnelle Behebung! 

[zap]

Hallo Miteinander,
habe heute Devices per AutoCreate angelegt. Hat auch soweit gut funktioniert.
Wäre es denn aber nicht sinniger wenn die Templates in HMCCUConf.pm automatisch gegriffen werden ?

Ja wäre hilfreich. Habe ich schlicht vergessen. Werde es einbauen.

Dein Konfigurationsbeispiel nehme ich gerne auf.

[Hellspawn]

Hey Super, Dankeschön

[aski71]

Hi,

ich steh auf dem Schlauch.

Ich würde gerne von meinem Thermostat das Reading CONTROL_MODE aus fhem ändern und Richtung CCU zurück schicken.
Geht das irgendwie?
Ich hätte vermutet, dass es mit "set Thermostat datapoint 1.CONTROL_MODE <wert>" vielleicht geht?
Tut es aber nicht. Egal, wie ich den datapoint formuliere, taucht die mir so beliebte Meldung "Invalid datapoint" auf.

Danke für Hilfe.
VG Alex

[zap]

Wenn Du get deviceinfo für das Thermostat Device aufrufst, wirst Du feststellen, dass bei CONTROL_MODE [RE] steht. Das steht für Read und Event. Der Datenpunkt ist also nicht beschreibbar.

Du musst den Mode über die beschreibbaren Datenpunkte MANU_MODE, AUTO_MODE usw. einstellen. Beachte auch den Datentyp des Datenpunktes (steht bei get deviceinfo am Anfang, b=bool, f=float, i=integer).

Bei AUTO_MODE schreibst Du true oder false, das ist vom Typ bool.

Bei MANU_MODE gibst Du die Temperatur mit (5-30 Grad). Wenn Du hier 4.5 angibst, geht der Thermostat auf OFF. Bei 30.5 geht er auf ON.

All diese Infos findest Du bei Google unter dem Begriff "Homematic Datenpunkte". Einer der Treffer ist ein PDF von EQ-3, in dem alle Geräte mit allen Datenpunkten, den Typen und Wertebereichen beschrieben sind.

List eines meiner Wandthermostate:

Code Auswählen Erweitern


Internals:
   CHANGED
   DEF        KL-SZ-TH
   IODev      d_ccu
   NAME       HM_KL_SZ_TH
   NR         76
   STATE      T: 21.1° H: 58% D: 21.0° P: 12.5°
   TYPE       HMCCUDEV
   ccuaddr    LEQ0000647
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    KL-SZ-TH
   ccutype    HM-TC-IT-WM-W-EU
   channels   6
   statevals  devstate
   Readings:
     2016-09-21 20:53:01   DEWPOINT        12.5
     2016-09-20 19:00:28   KL-SZ-TH.0.STICKY_UNREACH false
     2016-09-20 19:00:28   KL-SZ-TH.0.UNREACH false
     2016-09-21 20:53:01   KL-SZ-TH.1.HUMIDITY 58
     2016-09-21 20:53:01   KL-SZ-TH.1.TEMPERATURE 21.1
     2016-09-21 17:01:01   KL-SZ-TH.2.CONTROL_MODE AUTO
     2016-09-21 20:52:40   KL-SZ-TH.2.SET_TEMPERATURE 21.0
     2016-09-21 20:52:40   control         21.0
     2016-09-21 20:52:40   state           21.0
Attributes:
   IODev      d_ccu
   ccureadingfilter (UNREACH|^HUMIDITY|^TEMPERATURE|^SET_TEMPERATURE|^LOWBAT1^WINDOW_OPEN|^CONTROL)
   cmdIcon    Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
   comment    Wand-Thermostat Schlafzimmer
   controldatapoint 2.SET_TEMPERATURE
   devStateIcon OK:10px-kreis-gruen Error:10px-kreis-rot Initialized:10px-kreis-gelb
   event-on-change-reading .*
   eventMap   /datapoint 2.MANU_MODE 20.0:Manu/datapoint 2.AUTO_MODE 1:Auto/datapoint 2.BOOST_MODE 1:Boost/datapoint 2.MANU_MODE 4.5:off/datapoint 2.MANU_MODE 30.5:on/
   group      Klima
   icon       rc_HOME
   room       Homematic
   stateFormat T: KL-SZ-TH.1.TEMPERATURE° H: KL-SZ-TH.1.HUMIDITY% D: KL-SZ-TH.2.SET_TEMPERATURE° P: DEWPOINT°
   statedatapoint 2.SET_TEMPERATURE
   stripnumber 1
   substitute LOWBAT!(0|false):no,(1|true):yes;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed
   userReadings DEWPOINT {HMCCU_Dewpoint($name,"KL-SZ-TH.1.TEMPERATURE", "KL-SZ-TH.1.HUMIDITY","n/a")}
   webCmd     control:Auto:Manu:Boost:on:off
   widgetOverride control:slider,10,1,25


[aski71]

Super! Danke für die Infos.
Das mit dem Read-only hatte ich auch inzwischen rausgefunden. 

[torlan]

Hallo Zusammen,

ich bin neu hier und bin seit einiger Zeit dabei mein Haus mit fhem "zu vernetzen". Ich habe mittlerweile den Raspberry3 am Laufen mit Anbindung an Fritzbox und Steuerung der Sonos.
Allerdings bin ich seit Längerem an einer Sache am rätseln und benötige Hilfe (das Forum habe ich "rauf und runter" gelesen  - Vielen Dank für die vielen nützlichen Infos hier!)
Meine CCU2 ist verbunden und der RPCState läuft. Ich kann auch Steckdosen per fhem schalten und sehe im Eventmonitor die Events vom Schalter / Taster.
Mein Problem ist nun, daß meine notify nicht auf die Events der Taster oder Bewegungsmelder reagieren?! Im Log wird auch nichts eingetragen - obwohl im Eventmonitor alles angezeigt wird.

Beispiel eines Tasters:
Readings:
Bei HM-PB-2-WM55-2_MEQ1767068.1.PRESS_SHORT on  wird brav das Event mit Uhrzeit angezeigt, wenn ich den Taster drücke.

Wenn ich ein notify definiere mit
s_schalter1:HM-PB.PRESS_SHORT:.* set sd_Dose1 on
oder
s_schalter1:HM-PB.PRESS_SHORT:.on set sd_Dose1 on

reagiert er nicht. Das "HM-PB." habe ich schon weggelassen - geht auch nicht.
Mir ist nun nicht klar, was ich hier falsch mache? Der Schalter1 steht zusätzlich noch auf "Initialized"?!
Kann mir evtl. jemand einen Tipp geben, wo ich ansetzen kann?

Vielen lieben Dank und Gruß,
Torlan

[zap]

Was bei dem notify schief geht weiß ich leider nicht. Wenn Du das Attribut statedatapoint auf 1.PRESS_SHORT setzt (bei Verwendung von HMCCUDEV) oder auf PRESS_SHORT (bei HMCCUCHN) wird auch state bzw. STATE aktualisiert und das "initialized" verschwindet.

Du kannst auch das Attribut ccureadingformat auf 'datapoint' setzen. Dann werden die Readingnames kürzer.

Hier mal ein Beispiel, das bei mir funktioniert:

Code Auswählen Erweitern


define no_test notify HM_FB_BA_1:pressed set d_test $EVENT


Einen Readingnamen gebe ich hier gar nicht an. Könnte daran liegen, dass bei mir STATE aktualisiert wird.
"HM_FB_BA_1" ist das FHEM Device des Schalters, "pressed" das Event. Als Reaktion wird ein Dummy Device (d_test) auf das Event gesetzt. Das Attribut substitute steht auf PRESS_SHORT!(1|true):pressed

[torlan]

Klasse! Nun geht es!!! Vielen Dank - nachdem ich Deine Anweisungen probiert habe, geht es nun. Ob es das statedatapoint oder  das ccureading war, kann ich leider nicht sagen.

Aber Du hast mir den Abend gerettet 

Gruß,
Torlan

[zap]

Hinweis: Unterschiedliche Skalierung von Werten bei "get update/datapoint" und RPC-Events.

Ich habe jetzt bei 2 meiner Geräte (Dimmer und Stromzählersensor) festgestellt, dass sich die Skalierung der Werte / Datenpunkte unterscheidet zwischen einer CCU Abfrage mit get update oder get datapoint und von der CCU per RPC-Server gesendeten Werte.

Beim Dimmer Datenpunkt LEVEL:

Get Wertebereich: 0-1
Event Wertebereich: 0-100

Beim Stromzählersensor, Datenpunkte ENERGY_COUNTER und POWER:

Get Einheiten: Watt bzw. Wattstunden
Event Einheiten: Kilowatt bzw. Kilowattstunden

Beim Dimmer lässt sich das durch das Attribut ccuscaleval relativ leicht abfangen (0:1:0:100). Beim Stromzählersensor kann man das ebenfalls durch ccuscaleval umrechnen lassen. Allerdings muss man sich hier auf eine Übertragungs-/Abfragemethode festlegen.

Leider ist dieses Verhalten wieder mal nicht einheitlich über alle Gerätetypen. EQ3/ELV Murks eben.