FHEM - Hausautomations-Systeme > Homematic

HMCCU 5.0 Beta verfügbar

(1/159) > >>

zap:
Die Version 4.4 von HMCCU steht nun als Beta im SVN zur Verfügung. Die Beta-Phase wird bald enden (Stand Ende 2020). Da aber noch nicht alles getestet ist und stabil läuft, habe ich die 4 Module zunächst unter


--- Code: ---contrib/HMCCU/FHEM
--- Ende Code ---

sowie auf Github abgelegt.

Installation und Konfiguration


--- Code: ---update all https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
--- Ende Code ---

oder


--- Code: ---update all https://svn.fhem.de/trac/browser/trunk/fhem/contrib/HMCCU/controls_HMCCU.txt
--- Ende Code ---

Zurück zur alten Version 4.3

Dazu einfach FHEM Update ohne separate Quellenangabe ausführen.

Fehler und Erweiterungswünsche

Auf Github gibt es eine Liste der bekannten Fehler und Erweiterungswünsche: https://github.com/zapccu/HMCCU/issues

Vorgehen bei der Konfiguration:

* IO-Device mit Angabe der IP-Adresse der CCU definieren: define myCCU HMCCU IP-Addresse
* Zu verwendenden Schnittstellen auswählen: Aus Dropdown-Liste beim Attribut 'rpcInterfaces' die gewünschten Einträge auswählen
* RPC-Server starten: set myCCU on
* Optional: Autostart der RPC-Server aktivieren: attr myCCU rpcserver on
* Nachdem die RPC Server gestartet wurden (Status ist "running"), die FHEM Config speichern, da beim ersten Start der RPC-Server automatisch für jede ausgewählte Schnittstelle ein FHEM Device vom Typ HMCCURPCPROC angelegt wird
Autodetect von Homematic Geräten

Beim Starten von FHEM liest HMCCU nun alle Geräteparameter von der CCU. Diese Parameter werden verwendet, um bei der Definition eines Device in FHEM anhand der Kanalrolle das neue Device automatisch zu konfigurieren. Dadurch entfallen viele der bisher notwendigen Attribute. Die vorhandenen Devices der HMCCU Version 4.3 kann man auf das neue Verfahren umstellen, indem man für jedes Device einmal den Befehl
--- Code: ---set defaults reset
--- Ende Code ---
ausführt. Dabei werden alle HMCCU 4.3 relevanten Attribute gelöscht. Grundsätzlich werden die bisherigen Attribute weiterhin unterstützt, sind aber nicht mehr explizit erforderlich.
Empfehlung: Wer keine allzu große Homematic-Installation hat, sollte überlegen, seine Geräte einfach neu zu definieren. Dann wird man bei der Gerätedefinition auch darauf hingewiesen, HMCCUCHN statt HMCCUDEV zu verwenden, sofern dies möglich und sinnvoll ist.

Definition von FHEM Devices für Homematic Geräte (Autodetect)

Wenn möglich sollte für die Definition von FHEM-Devices das Modul HMCCUCHN verwendet werden. Die meisten Homematic Geräte können über einen einzelnen Kanal gesteuert werden. Wenn HMCCUDEV verwendet wird, obwohl HMCCUCHN möglich ist, weist HMCCU darauf hin, dass HMCCUCHN verwendet werden sollte. Diese Empfehlung kann durch Angabe der Option 'force' beim 'define' ignoriert werden.

Hinweis: Der Kanal 0 ist sowohl bei HMCCUCHN als auch bei HMCCUDEV immer enthalten. Es ist also nicht notwendig, HMCCUDEV zu verwenden, nur im die Datenpunkte aus dem Kanal 0 als Readings darstellen zu können.

Automatische Definition von FHEM Devices mit 'get create' oder 'get createDev'

Der Autodetect-Mechanismus wird nun auch von den Befehlen get create und get createDev verwendet. Daher entfällt hier die Option 't=dev/chn'. Der bei diesen Befehlen anzugebende reguläre Ausdruck bzw. Name für den CCU Gerätenamen bezieht sich nun immer(!) auf Geräte, niemals auf Kanäle. HMCCU erkennt selbständig, ob ein HMCCUDEV oder ein/mehrere HMCCUCHN Device(s) angelegt werden müssen.

Der Befehl get deviceInfo in HMCCU (IO-Device) wurde erweitert. Er zeigt für das abgefragte Gerät eine Empfehlung an, ob HMCCUCHN oder HMCCUDEV für eine Gerätedefinition verwendet werden sollte.

Beispiel: Wenn alle Heizungsgruppen in der CCU mit "G-Heizung" beginnen, legt der folgende Befehl ein FHEM Device für jede Heizungsgruppe an und weist ihm die Attribute 'room' und 'group' zu. Die Geräte in FHEM werden mit dem Präfix "HM_" angelegt:

--- Code: ---get myCCU create G-Heizung.* p=HM_ room=Homematic group=Heizung
--- Ende Code ---

Hinweis: Für die Heizungsgruppen wird HMCCUDEV verwendet, da bei diesen neben dem eigentlichen Kanal zur Temperatursteuerung ein weiterer Kanal existiert, der den Zustand der eingebundenen Fenstersensoren abbildet.

Auch wenn HMCCU den Gerätetyp nicht exakt identifizieren kann, werden die Attribute 'statedatapoint' und 'controldatapoint' nun mit Auswahllisten vorbelegt, die verhindern, dass ungeeignete Datenpunkte für die Steuerung bzw. Statusanzeige ausgewählt werden. Wenn eines der beiden Attribute nicht verfügbar ist, hat das jeweilige Gerät keine lesbaren (statedatapoint) bzw. schreibbaren (controldatapoint) Datenpunkte. Wenn man die FHEM Eingabezeile für das Setzen dieser Attribute verwendet, kann jeder Datenpunkt angegeben werden. Ein 'statedatapoint' muss lesbar, ein 'controldatapoint' beschreibbar sein.

Sonderfälle

Sonderfall Fernbedienungen

Für Geräte mit mehreren identischen Kanälen wie z.B. Fernbedienungen empfehle ich, für jeden Kanal ein HMCCUCHN Device anzulegen. Wenn HMCCUDEV verwendet wird, setzt HMCCU die Attribute 'statedatapoint' und 'controldatapoint' auf den ersten verwendbaren Kanal. Um einen anderen Kanal (eine andere Taste) zu verwenden, müssen beide Attribute entsprechend angepasst werden.
Bei Verwendung von get create oder get createdev legt HMCCU automatisch ein HMCCUCHN Device je Schaltkanal an. An den Devicenamen wird die Kanalnummer angehängt.

Sonderfall Mehrfachschalter mit Kanalgruppen

Ein weiterer Sonderfall sind Mehrfachschalter mit Kanalgruppen, wie sie m.W. nur bei HmIP-Wired vorkommen. Bei diesen Geräten sind immer 2 oder 4 Kanäle zu einem Schaltausgang zusammengefasst. Hier muss zwingend HMCCUDEV verwendet werden, wenn sich Status- und Steuerungskanal unterscheiden. Auch hier erfolgt die Auswahl der gewünschten Kanäle über die Attribute 'statedatapoint' und 'controldatapoint'.

Neue / geänderte Befehle

Neue Befehle des Moduls HMCCU:


* set on/off: Startet oder stoppt die RPC-Server Prozesse, Abkürzung für set rpcserver on/off
* get ccuConfig: Liest die Konfigurationsparameter der CCU (Geräte, Programme, ...) neu ein
* get ccuDevices: Zeigt eine Liste aller Geräte der CCU an
* get create: Definiert FHEM Geräte für eine Gruppe von CCU Geräten. Die Auswahl von HMCCUDEV oder HMCCUCHN erfolgt automatisch
* get createDev: Definiert ein oder mehrere FHEM Gerät(e) für ein CCU Gerät. Die Auswahl von HMCCUDEV oder HMCCUCHN erfolgt automatisch
* get deviceinfo: Zeigt Detailinformationen zu einem CCU Gerät an inkl. Empfehlung für das für die FHEM Gerätedefinition zu verwendende Modul (HMCCUDEV oder HMCCUCHN)
* get paramsetDesc: Zeigt Detailinformationen zu den Parametern eines CCU Gerätes an
Standard Befehle der Module HMCCUDEV und HMCCUCHN:

Die Befehle der Module HMCCUDEV und HMCCUCHN wurden komplett überarbeitet. Viele redundanten Befehle sind weggefallen oder wurden durch andere ersetzt. Sorry, wenn dadurch Aufwand bei der Anpassung von Notifies oder DOIFs entstehen.


* set clear: Readings löschen
* set config: Ein oder mehrere Konfigurations- oder Link-Parameter setzen
* set datapoint: Einen oder mehrere Datenpunkte setzen
* set defaults: Default Attribute setzen. Sollte nur verwendet werden, wenn ein Gerät nicht automatisch von HMCCU erkannt wurde
* set readingFilter: Vereinfacht die Definition des Attributs 'ccureadingfilter'. Die gewünschten Datenpunkte können aus einer Liste ausgewählt werden. Das Attribut 'ccureadingfilter' wird automatisch aus der Auswahl heraus gesetzt
* get config: Liest Konfigurations- und Linkparameter und zeigt sie an. Damit alle Parameter als Readings erscheinen, müssen im Attribut 'ccuflags' die Flags 'showMasterReadings', 'showLinkReadings' 'showServiceReadings' und/oder 'showDeviceReadings' gesetzt werden
* get datapoint: Liest einen Datenpunkt
* get deviceInfo: Zeigt Informationen zu Kanälen und Datenpunkten eines Gerätes an. Die Ausgabe dieses Befehls zusammen mit der Ausgabe von get paramsetDesc hilft mir, nicht automatisch erkannte Geräte in HMCCU zu integrieren. Wenn also ein Gerät nicht erkannt wird, bitte diese beiden Befehle ausführen und die Ausgabe an mich schicken. Beide Befehle können auch direkt im I/O Device ausgeführt werden (also ohne vorher ein HMCCUDEV/CHN Device zu definieren)
* get paramsetDesc: Zeigt Detailinformationen zu den Parametern eines Gerätes an. Zur Verwendung s.o.
* get update: Aktualisiert alle Parameter und Datenpunkte eines Gerätes
* get values: Aktualisiert nur die Datenpunkte eines Gerätes
Für die genaue Syntax der Befehle siehe FHEM Commandref.

Readings

Per Default werden nur Readings zu Datenpunkten (Parameterset VALUES) angezeigt. Die Voreinstellung für 'ccureadingfilter' ist nun '.*'. D.h. es werden keine Datenpunkte gefiltert. Die Anzeige von Readings zum Device, zu Links oder zu Konfigurationsparametern wird über das Attribut 'ccuflags' im jeweiligen FHEM-Device gesteuert. Hier können die Flags 'showDeviceReadings', 'showMasterReadings', 'showLinkReadings' und/oder 'showServiceReadings' gesetzt werden, um die entsprechenden Readings anzeigen zu lassen.
Hinweise:

* Nur die Readings zu Datenpunkten werden von der CCU automatisch aktualisiert (sofern die RPC-Server gestartet sind). Alle anderen Readings müssen mit dem Befehl 'get config' explizit aktualisiert werden.
* Wenn Reading bezogene Attribute geändert werden und die betroffenen Readings bereits intern vorhanden sind, werden die Readings automatisch mit den intern gespeicherten Werten aktualisiert bzw. ergänzt
Einige wichtige Änderungen:

* HMCCU: Der interne RPC Server wurde entfernt. Es wird nur noch HMCCURPCPROC unterstützt. Das Flag procrpc muss nun nicht mehr gesetzt werden. Es wird immer der externe RPC Server verwendet.
* HMCCU: Neues globales Flag 'logCommand' für das Attribut 'ccuflags'. Dadurch werden alle set und get Befehle im FHEM Logfile protokolliert.
* Alle Module: Die Logfile Einträge wurden vereinheitlicht. Neben dem Modulnamen wird nun auch immer die Prozess-ID ausgegeben. Das hilft, Fehler in RPC Server Prozessen zuzuordnen
* HMCCURPCPROC: Jedes RPC-Device liest während der Definition bzw. der Initialisierung Gerätebeschreibungen von der CCU und speichert sie im I/O Device. Dies dauert auf einer CCU3 mit 80 Geräten einige Sekunden. Auf einer CCU2 dürfte es deutlich länger dauern. Dies verzögert den Start von FHEM
* HMCCURPCPROC: Fehler im Handling binärer RPC-Requests (CUxD) behoben.

martinp876:
Bei mir funktioniert es nicht. Seit dem test, welcher schief ging, bekomme ich die RPC interfaces nicht mehr zum Laufen. Ich bin auf die 4.3 zurückgegangen - ohne Erfolg.
State "inactive/Error"
RPCState inactive

--- Code: ---Internals:
   CCUNum     1
   CFGFN      ./setup/c_hmCCU.cfg
   Clients    :HMCCUDEV:HMCCUCHN:HMCCURPC:HMCCURPCPROC:
   DEF        192.168.178.46
   FUUID      5c95d10d-f33f-1a31-fbb0-16b25dbd514f7621
   NAME       HMccu
   NOTIFYDEV  global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)
   NR         733
   NTFY_ORDER 50-HMccu
   RPCState   inactive
   STATE      inactive/Error
   TYPE       HMCCU
   ccuip      192.168.178.46
   ccustate   active
   ccutype    CCU2/3
   host       192.168.178.46
   prot       http
   version    4.3.020
   READINGS:
     2020-01-06 11:33:16   battery_count   154
     2020-01-06 11:33:16   battery_list    Batterien OK
     2020-01-06 11:33:16   battery_match   0
     2020-01-06 11:33:16   battery_state   ok
     2020-01-05 16:02:45   count_channels  259
     2020-01-05 16:02:45   count_devices   28
     2020-01-05 16:02:45   count_groups    0
     2020-01-05 16:02:45   count_interfaces 3
     2020-01-05 16:02:45   count_programs  5
     2020-01-06 12:48:39   rpcstate        inactive
     2020-01-06 13:35:14   state           Error
   hmccu:
     defInterface BidCos-RF
     defPort    2001
     evtime     0
     evtimeout  0
     rpccount   0
     rpcports   
     updatetime 0
     adr:
     agg:
       battery:
         fcoll      comment
         fcond      any
         fdflt      Batterien OK
         felse      ok
         fexcl     
         fexpr      ^HMc_.*
         fpref      battery_
         fread      battery
         ftrue      low
         ftype      name
       voltage:
         fcoll      comment
         fcond      le
         fdflt      Batteriespannung OK
         felse      0
         fexcl     
         fexpr      (HM-CC-RT-DN|HM-TC-IT-WM-W-EU)
         fpref      voltage_
         fread      BATTERY_STATE
         ftrue      2.2
         ftype      type
     ccu:
       delay      180
       delayed    1
       timeout    1
     dev:
     ifports:
     interfaces:
     rpc:
Attributes:
   ccuaggregate name:battery,filter:name=^HMc_.*,read:battery,if:any=low,else:ok,prefix:battery_,coll:comment!Batterien OK;
name:voltage,filter:type=(HM-CC-RT-DN|HM-TC-IT-WM-W-EU),read:BATTERY_STATE,if:le=2.2,else:0,prefix:voltage_,coll:comment!Batteriespannung OK;
   ccudef-readingfilter .*
   ccudef-readingformat datapointlc
   ccudef-readingname 0.(LOWBAT|LOW_BAT):battery;..LEVEL:+pct;..SET_TEMPERATURE:desired-temp;..ACTUAL_TEMPERATURE:measured-temp;4.control_mode:controlMode
   ccudef-substitute AES_KEY!(0|false):off,(1|true):on;
LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;
UNREACH!(0|false):alive,(1|true):dead;
MOTION!(0|false):noMotion,(1|true):motion;
DIRECTION!0:stop,1:up,2:down,3:undefined;
WORKING!0:false,1:true;
INHIBIT!(0|false):unlocked,(1|true):locked
   ccuflags   procrpc
   cmdIcon    on:general_an off:general_aus
   eventMap   /rpcserver on:on/rpcserver off:off/
   group      IOdev
   room       HMccu,Homematic
   rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
   rpcport    2001,2010
   rpcserver  on
   stateFormat rpcstate/state
   stripnumber 2


--- Ende Code ---

zap:
Lösche mal das Attribut rpcport und am besten auch eventuell vorhandene HMCCURPCPROC Devices. Dann FHEM neu starten.

Der Hash vom I/O Device enthält keine Interfaces. Das ist seltsam. Auch das Internal ccuinterfaces fehlt im I/O Device.

martinp876:
Hat nicht funktioniert.
Ich werde erst am Wochenende wieder Zeit investieren können

zap:
ok, bis dahin wird es noch das eine oder andere Update geben

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln