Neues Modul HMCCU für Homematic CCU

Spielmann · 16 Dezember 2016, 10:11:13

Hallo,
ich experimentiere gerade bei HMCCU mit dem Exportieren und Importieren der Attribute, da ich diese bei mir anders standardisieren möchte (Ich habe smartVisu und damit andere Widgets und möchte auch den Sabotagekontakt am HM-SEC-SCo noch einbeziehen).
Ich habe die Defaultliste exportiert, mit file edit auf der FHEM Weboberfläche bearbeitet, wieder importiert und funktioniert soweit. Das File habe ich unter dem Verzeichnis /FHEM abgelegt und mit der Dateiendung .layout versehen, dass ich es komfortabel auf der Weboberfläche mit file edit bearbeiten kann.
Meine "custom Defaults" werden allerdings nur übernommen, wenn ich das Device lösche und neu createn lasse. Ist das so angedacht um die vergebenen Attribute vor versehentlichen überschreiben zu schützen? Es wäre praktisch wenn man nachträglich die Attribute per Default ändern könnte (z.B. wenn man grundsätzlich eine andere Darstellung haben möchte).
Ansonsten bin ich von diesem System begeistert da ich es für das beste bezüglich HM-Komponenten Verfügbarkeit halte (immer kompatibel zu FHEM da CCU als Schnittstelle, die von eq3 unterstützt wird)

Gruß
Spielmann

tagedieb · 16 Dezember 2016, 11:34:24

Hallo zap

danke für die Rückinfo

Gruss tagedieb

zap · 16 Dezember 2016, 11:52:19

Zitat von: Spielmann am 16 Dezember 2016, 10:11:13
Meine "custom Defaults" werden allerdings nur übernommen, wenn ich das Device lösche und neu createn lasse. Ist das so angedacht um die vergebenen Attribute vor versehentlichen überschreiben zu schützen? Es wäre praktisch wenn man nachträglich die Attribute per Default ändern könnte (z.B. wenn man grundsätzlich eine andere Darstellung haben möchte).

Beim Import der Custom Defaults werden nicht automatisch die Attribute der vorhandenen Devices neu gesetzt bzw. überschrieben. Dazu musst Du für jedes Device den Befehl "set xyz defaults" ausführen.

Glücklicherweise ermöglicht FHEM ja die Ausführung eines set Befehls für mehrere Devices "in einem Rutsch". Ich könnte dem Import Befehl aber auch noch eine Option verpassen, mit der für alle vorhandenen Geräte die Attribute überschrieben werden.

Spielmann · 16 Dezember 2016, 12:27:56

Hallo zap,
dass die Attribute ganz automatisch unkontrolliert überschrieben werden, sobald die Liste importiert wird würde ich auch nicht wollen. Ich habe nur mit den Befehlen in der set / get drop-down-Liste gespielt und da hat der "defaults" nichts aus der custom Liste geholt. Mir würde es schon reichen wenn ich im Device per Auswahlliste die Attribute aktualisieren könnte. Den Befehl in die Eingabezeile eingeben geht natürlich auch. Wenn ich das jetzt richtig verstehe, dann holt der Befehl set <Name> defaults in der Auswahlliste im Device die ursprünglichen defaults und in der Eingabezeile die "custom defaults". Ich werde das heute Abend mal testen.

Gruß
Spielmann

zap · 16 Dezember 2016, 16:14:34

Nein, zumindest ist das so nicht gewollt. Set defaults soll immer erst in der Custom Liste nachschauen. Erst wenn da kein passender Eintrag existiert, soll Default verwendet werden. Muss ich mir anschauen, möglicherweise ein Bug.

zentis666 · 16 Dezember 2016, 17:11:57

Hi zap,

vielen Dank, funktioniert!

Zitat von: zap am 16 Dezember 2016, 10:08:23
Prüfe mal, ob Du mit einem der folgenden Befehle einer der LEDs einschalten kannst.

Code Auswählen Erweitern
set HM-OU-LED16_Flur datapoint 1.LED_STATUS 1 --> 1. LED rot set HM_OU_LED16_Flur datapoint 1.LED_STATUS 2 --> 1. LED grün set HM_OU_LED16_Flur datapoint 1.LED_STATUS 3 --> 1. LED gelb set HM-OU-LED16_Flur datapoint 2.LED_STATUS 1 --> 2. LED rot

Muss ich nur noch die 3 Stati auf die Farben mappen.

Gruß
Sven

Spielmann · 17 Dezember 2016, 00:08:28

Hallo zap,
inzwischen habe ich etwas herausgefunden. Ich habe die Devices HM-Sec-SC und HM-Sec-SCo getrennt in der Liste aufgeführt, da ich nur die HM-Sec-SCo besitze und den magnetischen Fensterkontakt nicht kenne.

Wenn ich:

Code Auswählen

device:HM-Sec-SC
_description=Tuer/Fensterkontakt magnetisch
ccureadingfilter=(^UNREACH|LOWBAT|LOW_BAT|STATE)
statedatapoint=1.STATE
substitute=STATE!(0|false):closed,(1|true):open;UNREACH,LOWBAT,LOW_BAT!(0|false):no,(1|true):yes

device:HM-Sec-SCo
_description=Tuer/Fensterkontakt optisch
ccureadingfilter=(^UNREACH|LOWBAT|ERROR|STATE)
statedatapoint=1.STATE
substitute=STATE!(0|false):closed,(1|true):open;UNREACH,LOWBAT!(0|false):no,(1|true):yes;ERROR!(7):sabotage,(0|false):ok

in die Liste eintrage, werden für meinem HM-Sec-SCo die defaults von HM-Sec-SC übernommen. Nachdem ich den HM-Sec-SCo in der Liste vorangestellt habe

Code Auswählen

device:HM-Sec-SCo
_description=Tuer/Fensterkontakt optisch
ccureadingfilter=(^UNREACH|LOWBAT|ERROR|STATE)
statedatapoint=1.STATE
substitute=STATE!(0|false):closed,(1|true):open;UNREACH,LOWBAT!(0|false):no,(1|true):yes;ERROR!(7):sabotage,(0|false):ok

device:HM-Sec-SC
_description=Tuer/Fensterkontakt magnetisch
ccureadingfilter=(^UNREACH|LOWBAT|LOW_BAT|STATE)
statedatapoint=1.STATE
substitute=STATE!(0|false):closed,(1|true):open;UNREACH,LOWBAT,LOW_BAT!(0|false):no,(1|true):yes

klappts. Anscheinend stimmt etwas mit dem Devicenamen nicht. Wie sich das mit den Channels verhält habe ich nicht getestet, da ich HMCCUCHN wegen der Übersichtlichkeit nicht nutze .

Gruß
Spielmann

zap · 17 Dezember 2016, 09:02:31

Danke, Du hast den Bug gefunden! Der Devicetype ist ein regulärer Ausdruck. Da in Deinem Fall der eine Typ im anderen enthalten ist, matched der kürzere zuerst.

zap · 18 Dezember 2016, 11:35:35

Zitat von: Spielmann am 17 Dezember 2016, 00:08:28
in die Liste eintrage, werden für meinem HM-Sec-SCo die defaults von HM-Sec-SC übernommen. Nachdem ich den HM-Sec-SCo in der Liste vorangestellt habe
Code Auswählen Erweitern
device:HM-Sec-SCo _description=Tuer/Fensterkontakt optisch ccureadingfilter=(^UNREACH|LOWBAT|ERROR|STATE) statedatapoint=1.STATE substitute=STATE!(0|false):closed,(1|true):open;UNREACH,LOWBAT!(0|false):no,(1|true):yes;ERROR!(7):sabotage,(0|false):ok device:HM-Sec-SC _description=Tuer/Fensterkontakt magnetisch ccureadingfilter=(^UNREACH|LOWBAT|LOW_BAT|STATE) statedatapoint=1.STATE substitute=STATE!(0|false):closed,(1|true):open;UNREACH,LOWBAT,LOW_BAT!(0|false):no,(1|true):yes
klappts. Anscheinend stimmt etwas mit dem Devicenamen nicht. Wie sich das mit den Channels verhält habe ich nicht getestet, da ich HMCCUCHN wegen der Übersichtlichkeit nicht nutze .

Gruß
Spielmann

Ich muss mich korrigieren. Es ist kein Bug sondern so gewollt. Die Angaben hinter "device" und "channel" sind reguläre Ausdrücke. Du hast mehrere Möglichkeiten:

1. Du lässt den nicht benötigten Gerätetyp weg
2. Du drehst die Reihenfolge um, wie Du es schon gemacht hast
3. Du belässt es bei HM-Sec-SCo|HM-Sec-SC

RainerG · 18 Dezember 2016, 20:50:55

Leider wollen nun meine 3 wired IO-Module überhaupt nicht mehr (Ich hatte eine längere Zeit kein FHEM-Update). Zum Ergründen hab ich mir nen extra-Raspi gegönnt. und das Fhem neu aufgesetzt und nur die HMCCU angedockt. (alle Updates auf Stand heute)

Code Auswählen

defmod HMCCU2 HMCCU 192.168.yyy.xxx
attr HMCCU2 room HM,Unsorted
attr HMCCU2 rpcport 2000,2001
attr HMCCU2 rpcserver on
attr HMCCU2 stateFormat rpcstate/state

setstate HMCCU2 running/OK
setstate HMCCU2 2016-12-18 15:56:43 rpcstate running
setstate HMCCU2 2016-12-18 19:08:12 state OK

Dann einen der HMW-IO-12-Sw7-DR erkennen lassen

Code Auswählen

get HMCCU2 devicelist create 7-2
ergibt folgendes

Code Auswählen

defmod 7_2 HMCCUDEV MEQ02789xx
attr 7_2 IODev HMCCU2

Danach versucht mir die

Code Auswählen

get 7_2 deviceinfo anzeigen zu lassen, das liefert:
HMCCUDEV: 7_2 Execution of CCU script or command failed
Andere Versuche, die "früher" gingen, liefern "Invalid datapoint"
Ein Versuch mit nem HM-Funkschalter HM-ES-PMSw1-Pl funktioniert problemlos!

zap · 19 Dezember 2016, 08:13:15

Also das Device heißt in der CCU 7-2? Das ist wirklich das Device und kein Kanal?

Versuche mal ein

Code Auswählen


get HMCCU2 deviceinfo 7-2

Hier musst Du den Namen in der CCU angeben. Ich habe hier angenommen, dass der 7-2 ist.

Spielmann · 19 Dezember 2016, 12:31:05

Zitatzap:
Ich muss mich korrigieren. Es ist kein Bug sondern so gewollt. Die Angaben hinter "device" und "channel" sind reguläre Ausdrücke. Du hast mehrere Möglichkeiten:

1. Du lässt den nicht benötigten Gerätetyp weg
2. Du drehst die Reihenfolge um, wie Du es schon gemacht hast
3. Du belässt es bei HM-Sec-SCo|HM-Sec-SC

Ich lasse das einfach mal so stehen. Ich weis ja inzwischen wo ich bei solchen Fällen suchen muss und kann jetzt die Zusammenhänge besser verstehen (und vielleicht auch andere). Danke.

Gruß
Spielmann

RainerG · 19 Dezember 2016, 18:31:21

Hallo zap,
jo heist so

Code Auswählen

Name: 7-2
Typenbezeichnung:	HMW-IO-12-Sw7-DR
Seriennummer:	MEQ0278xxx

auf "get HMCCU2 deviceinfo 7-2" antwortet "HMCCU: HMCCU2 Execution of CCU script or command failed"
Ich habs mal auf IO7-2 umgetauft, FHEM neugestartet und es kommt ein brauchbares Ergebnis vom DeviceInfo!
Also sollten die CCU Dev Namen mit nem Buchstaben beginnen - OK.
Danke! & Harzliche Grüße Rainer

zap · 19 Dezember 2016, 19:27:26

Könnte daran liegen, dass HMCCU sowohl Namen als auch Adressen akzeptiert. Ich vermute, dass die Prüfroutine bei 7-2 fälschlicherweise von einer Adresse ausgeht. Ich nehme es mal in die "zu prüfen" Liste auf.

Yil · 20 Dezember 2016, 20:12:59

Hab mir grad ne Fernbedienung Typ HM-RC-Dis-H-x-EU gegönnt. Hat die jemand schonmal jemand mit diesem neuen Modul hier angebunden?

Neues Modul HMCCU für Homematic CCU

RainerG

RainerG