HMCCU Version 4.1 im SVN

[zap]

Die Version 4.1 bringt einige Änderungen und Erweiterungen. Die neue Version sollte morgen per update verteilt werden.

Dutycycle

HMCCU: Der Befehl get dutycycle erzeugt nun je Interface 3 Readings: iface_type_n = Interface Typ, iface_ducy_n = Dutycyle und iface_conn_n = Connection Status, wobei n eine laufende Nummer ist.

CCU Systemvariablen

HMCCU: Der Befehl set var unterstützt nun auch das Anlegen von Systemvariablen in der CCU. Dazu wird als erster Parameter der Typ der Variablen übergeben. Gültige Typen sind bool, number, text und list. Wenn eine Variable existiert, wird lediglich der Wert überschrieben. Der Befehl steht in folgenden Varianten zur Verfügung:

set var Name Value
set var bool Name Value [valtrue=Value] [valfalse=Value] [desc=Description] [unit=Unit]
set var number Name Value [min=Value] [max=Value] [desc=Description] [unit=Unit]
set var text Name Value [desc=Description] [unit=Unit]
set var list Name Value [list=Value1,...,ValueN] [desc=Description] [unit=Unit]

CCU Objekte löschen

HMCCU: Mit dem Befehl set delete kann ein Gerät oder eine Systemvariable in der CCU gelöscht werden. Zu beachten: Es gibt kein Undo, d.h. weg ist weg . Der Aufruf sieht so aus:

set delete Name [{ OT_VARDP | OT_DEVICE }]

Peering

Die umfangreichste Neuerung ist die Möglichkeit, Devices zu peeren. Damit ist eine rein logische Verbindung in FHEM gemeint. Es werden keine Geräte in der CCU verknüpft! Die Aktualisierung eines oder mehrerer Datenpunkte eines HMCCUCHN oder HMCCUDEV Devices löst eine Aktion aus, sofern eine hinterlegte Bedingung erfüllt ist. Klingt kompliziert, ist es aber eigentlich nicht. Diese Funktion erspart Notifies und DOIFs. Das Peering eines HMCCUCHN oder HMCCUDEV Devices wird mit dem Attribut peer eingerichtet:

attr peer datapoints:condition:{ccu:object=value | hmccu:object=value| fhem:command}

Der Parameter datapoints ist eine Liste von Datenpunkten im Format Kanalnummer.Datenpunktname. Das Peering greift nur, wenn einer dieser Datenpunkte aktualisiert wird. Mit condition wird eine Bedingung definiert, die erfüllt sein muss, damit die festgelegte Aktion ausgeführt wird. Diese Bedingung ist ein gültiger Perl-Ausdruck. Der Ausdruck kann Datenpunkte als Variablen im Format Kanalnummer.Datenpunktname enthalten. Diese Variablen beginnen mit den Zeichen '$', '$$', '%' oder '%%'. Mit '$' wird auf den konvertierten Wert eines Datenpunktes zugegriffen (also z.B. "on" statt true oder 1). Mit '%' wird der Originalwert eingesetzt (also z.B. true bzw. 1). Bei '$$' oder '%%' wird auf die vorherigen Werte zugegriffen. Wenn die Bedingung zutrifft, kann als Aktion entweder ein Datenpunkt in der CCU (ccu) oder in einem HMCCUCHN/HMCCUDEV Device ("hmccu") auf einen Wert gesetzt oder ein FHEM-Befehl ausgeführt werden ("fhem").

Beispiele:

Code Auswählen Erweitern


# Peering depends on datapoint 1.STATE. Execute FHEM command if formatted value of 1.STATE is 'on'
attr mydev peer 1.STATE:'$1.STATE' eq 'on':fhem:set mydummy $value

# Peering depends on datapoint 1.STATE. Set 2.LEVEL of FHEM device myBlind to 100 if raw value of 1.STATE is 1
attr mydev peer 1.STATE:'%1.STATE' eq '1':hmccu:myBlind:2.LEVEL=100

# Peering depends on datapoint 1.LEVEL. Set 1.STATE of CCU device LEQ1234567 to true if 1.LEVEL < 100
attr mydev peer 1.LEVEL:%1.LEVEL < 100:ccu:LEQ1234567:1.STATE=true

# Peering depends on datapoint 1.LEVEL. Set 1.STATE of CCU device LEQ1234567 to true if current level is different from old level
attr mydev peer 1.LEVEL:$1.LEVEL != $$1.LEVEL:ccu:LEQ1234567:1.STATE=true


Das Attribut peer ist für Fälle gedacht, die direkt in der CCU nicht lösbar sind bzw. für die Verknüpfung von HMCCUCHN/HMCCUDEV Devices mit anderen FHEM Devices. Meine Empfehlung: Peerings zwischen Homematic Geräten sollten in der CCU angelegt werden. Der Vorteil: diese funktionieren unabhängig von CCU und FHEM.

[Garbsen]

Klingt super gut, mal sehen, wann ich Zeit finde es auszuprobieren
Zunächst Danke für Deine Bemühungen

[Garbsen]

Habe es natürlich heute Abend gleich ausprobieren müssen. Funktioniert super, erspart mir etliche doif (2 je Device)
Ich habe es wie folgt umgesetzt:

Code Auswählen Erweitern

1.LEVEL:'$1.LEVEL' eq 'closed':fhem:set RolloU1_1 on;
1.LEVEL:'$1.LEVEL' eq 'open':fhem:set RolloU1_1 off
1.LEVEL:$1.LEVEL < 100 :fhem:set RolloU1_1 Sonnenschutz;
1.LEVEL:'$1.LEVEL' eq 'Inf':fhem:set RolloU1_1 stop

Die ersten beiden Optionen sind selbsterklärend.
Die dritte sorgt dafür, dass immer wenn Werte zwischen 50 und 100 gesendet werden, der Rolläden in die definierte Position Sonnenschutz fährt. Ich habe dafür an den HM-Taster-Fernbedienungen eine Taste so programmiert, das ein langer Druck den Befehl auf POS 54 sendet.
Die 4. Zeile ist ein workaround für den fehlenden Stop-Befehl, die Fernbedienung sendet bei langen Druck auf 2. Taste den Befehl pos=25, der kommt in FHEM ja unbekannterweise mit Level=Inf an, und Peer deutet das halt als stop.

Für mich eine brauchbare Lösung, zumindest bis das Stop-Problem und das Inf Problem irgendwie gelöst wird.

Kann man im Peer-Attr. Den Wert von Level (Wenn Zahl zwischen 0 und 100, bzw. 50 und 100) an FHEM weitergeben?

[zap]

Für mich eine brauchbare Lösung, zumindest bis das Stop-Problem und das Inf Problem irgendwie gelöst wird.

Kann man im Peer-Attr. Den Wert von Level (Wenn Zahl zwischen 0 und 100, bzw. 50 und 100) an FHEM weitergeben?

Bei mir funktioniert STOP. Ich poste bei Gelegenheit mal meine ganze Config (CUxD in der CCU, Devices in FHEM).

Den Wert kannst Du momentan mit $value übergeben. Beispiel

Code Auswählen Erweitern


1.LEVEL:%1.LEVEL < 100 :fhem:set RolloU1_1 position $value;


Du solltest bei der nummerischen Prüfung (<100) das '%' verwenden. Sonst könnte es Probleme geben, wenn $1.LEVEL = "closed" oder "open" ist.

Was auch geht:

Code Auswählen Erweitern


1.LEVEL:%1.LEVEL != %%1.LEVEL :fhem:set RolloU1_1 position $value;


Das greift, wenn sich LEVEL geändert hat. Habe schon ein Update in der Pipeline, mit dem man in der Aktion statt $value auch $1.LEVEL usw angeben kann.

[Garbsen]

Danke, probiere ich baldmöglichst aus
Seltsam, dass bei mir bei Stop bzw. unter 50 immer Inf steht
Wäre in der Tat an Deiner configuration interessiert, kann wohl nur beim Anlegen des Devices in der CCU liegen

[Ralli]

Du hast für den RPC u.a. das Attribut rpcEventTimeout eingeführt.

Was soll es bewirken? Welcher Wert ist default? Ist das Attribut nur global für alle RPC-Schnittstellen zu definieren oder individuell?

[Garbsen]

Den Wert kannst Du momentan mit $value übergeben. Beispiel

Code Auswählen Erweitern


1.LEVEL:%1.LEVEL < 100 :fhem:set RolloU1_1 position $value;


Du solltest bei der nummerischen Prüfung (<100) das '%' verwenden. Sonst könnte es Probleme geben, wenn $1.LEVEL = "closed" oder "open" ist.

Gerade ausprobiert, bei mir funzt es mit $ problemlos, mit % reagiert er auf die "normalen" Auf/Ab Befehle "seltsam", er scheint dann nur noch eine Richtung zu kennen:abwärts. Dh. Closed Befehl führt zu on und Open Befehl führt auch zu on, wobei er manchmal kurz zu zucken scheint, als ob er hochfahren will und gleich kehrt macht.
Die Übergabe von $value erfordert bei meinen Somfy Rollläden ein pos kein position

[zap]

@Ralli: Wenn innerhalb des mit rpcEventTimeout definierten Zeitraums keine Updates von der CCU kommen, wird ein FHEM Event "No events from CCU interface xxxx since yyyy seconds" generiert. Default ist 600 Sekunden. Der Wert gilt für alle Interfaces.
Wenn das Attribut ccuflags auf reconnect gesetzt ist, versucht der RPC Server sich nach Ablauf des Timeouts automatisch neu mit der CCU zu verbinden. Leider kann ich momentan wegen eines Bugs in der CCU Firmware momentan nicht prüfen, ob die CCU RPC Schnittstellen aktiv sind.

@garbsen: vergiss das mit dem %. Damit erhält man die Originalwerte, und die liegen zwischen 0 und 1. daher auch das seltsame Verhalten.

[Ralli]

Ok, das habe ich mir fast so gedacht. Ein Attribut, welches für alle RPC-Schnittstellen gleichermaßen gilt, ist in manchen Fällen jedoch eher suboptimal.

Konkretes Beispiel: die BidCoS und HmIP senden - je nach Device-Anzahl und Konfiguration ! - recht regelmäßig etwas, so dass normalerweise innerhalb von 10 Minuten immer mal was über den Äther gekommen sein sollte. Bei Wired sieht das aber anders aus. Da kommen normalerweise keine zyklischen Statusmeldungen sondern nur dann, wenn es ein Update gibt. Bei Wired kommt teilweise über mehrere Stunden nix über den Draht.

[zap]

Sobald EQ3 den RPC Ping repariert hat, kommt das als zusätzliche Absicherung mit rein. Das erzwingt dann ein regelmäßiges PONG Event für alle Schnittstellen.

[Ralli]

get CCU2 dutycycle ist gut so gelöst. Somit kann man mittels notify oder DOIF reagieren, wenn ein Gateway nicht mehr verbunden ist, und man kann den Dutycycle schön grafisch auswerten.

[Chris8888]

Hallo Zap,

da ich über die CCU nur meine IP-Heizung steuere habe ich dort derzeit nicht viele Events.
Im Log taucht seit dem Update auf 4.1 alle 10 Min der "no event"-Eintrag auf.
Daher dachte ich "rpcevtimeout 1800" würde das deutlich verbessern, aber die 10 Min-Einträge bleiben:
HMCCU: Received no events from interface CB2001 for 600.940394878387 seconds

Habe ich das falsche Attr erwischt bzw falsch verstanden?

Viele Grüße
Christian

PS: Ansonsten läuft 4.1 wie gewohnt. TOP!

[zap]

Nutzt du den internen oder den externen RPC Server? Möglicherweise habe ich beim internen noch einen Bug drin. Falls Du den externen Nutzt (HMCCURPC), musst du auch dort das Attribut setzen.

[Chris8888]

Hallo Zap,

ich nutze den externen Server. Nachdem ich das Attr auch bei dem HMCCURPC gesetzt habe bleinbt es ruhig im Log.

Besten Dank!

VG
Christian

[Chris8888]

Hallo,

ich habe eben die CCU2 auf 2.29.18 upgedatet. Bisher läuft alles wie sonst auch.
Keine besonderen Einträge im Log, Austausch zwischen FHEM und CCU2 scheint normal.

VG
Christian

Update: Mit der Firmware ist u.a. endlich das Routing über die IP-Steckdosen konfigurierbar. Sieht ebenfalls bisher gut aus.