HMCCU: Version 4.3 verfügbar

[Weisswurstverkäufer]

Hallo,

mit dem Update von 88_HMCCU.pm meldet sich mein HomeMatic Fenstersensor jetzt alle paar Minuten ein paar mal mit einem Event des aktuellen Status. Dazu kommt dann im Log

Code Auswählen Erweitern

2020.01.30 10:21:11 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:21:12 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:21:13 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:21:14 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:21:30 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:21:31 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:22:26 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:22:27 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:22:37 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:22:39 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:22:54 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:22:54 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:22:55 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:22:56 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:22:56 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:22:57 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:23:00 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:23:00 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:23:01 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:23:01 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:23:03 4: CUL_HM Garagentor_Sensor dupe: dont process
2020.01.30 10:23:05 4: CUL_HM Garagentor_Sensor dupe: dont process

Da ich mir das per Push senden lasse ist das ein bisschen nervig. Ist das ein Fehler bei mir (es ist ein einfaches notify mit Garagentor_Sensor:open.*) oder liegt hier ein neuer Bug vor? Ich habe sofort wieder

Code Auswählen Erweitern

#  $Id: 88_HMCCU.pm 20644 2019-12-02 15:55:44Z zap $
#
#  Version 4.3.020

auf dem Backup wiederhergestellt, seitdem ist wieder alles top.

[Ralli]

Das ist keine Log-Meldung von HMCCU sondern von CUL_HM!

[Weisswurstverkäufer]

Hm, ja. Scheint wohl echt nur ein dummer Zufall gewesen zu sein dass es nach dem Update von HMCCU passiert ist und mit dem Restore der alten Version weg war. Habe jetzt nochmal HMCCU updated und es scheint nicht mehr aufzutreten (logisch, wenn ich es offenbar gar nicht nutze).

Sorry

[Dirk070]

Es gibt ein kleines Update für HMCCU, HMCCUCHN und HMCCUDEV im SVN mit folgenden Änderungen:

• Der Befehl set datapoint im HMCCU I/O Device akzeptiert nun Standard FHEM Devspecs

Hallo zusammen,

ich habe ein Problem mit der Syntax beim set datapoint. Mit einem Device funktioniert es:

Code Auswählen Erweitern

set ccu3 datapoint CCU_OG_BD_FDT_WC 4.LEVEL=15

Aber sobald es mehrere werden:

Code Auswählen Erweitern

set ccu3 datapoint CCU_OG_BD_FDT_WC 4.LEVEL=15 CCU_OG_BD_BSL_FLUR 8.COLOR=4

Fehlermeldung:

Code Auswählen Erweitern

HMCCU: ccu3 Invalid channel number specified for device CCU_OG_BD_FDT_WC

Frage: Wie muss ich die Devices trennen?

Vielen Dank und schöne Grüße
Dirk

[zap]

Bei zwei Ziel Devices musst Du auch zwei set Befehle verwenden. Das liegt an der Art und Weise, wie FHEM die Kommandozeile auswertet. Dadurch ist eine eindeutige Zuordnung von Datenpunkt zu Device nicht möglich.

Ausnahme: wenn der erste Devicename eine FHEM Devspec ist, kann sich diese natürlich auf mehrere Devices beziehen. Einzige Bedingung ist dann, dass alle Devices auch die danach angegebenen Datenpunkte enthalten.

Sowas würde also funktionieren:

set ccu3 datapoint CCU_OG_BD_FDT_WC,CCU_OG_BD_BSL_FLUR 4.LEVEL=15 8.COLOR=4

[Dirk070]

Hallo zap,

Danke für die Info, probiere ich gleich aus.

Ich hatte aus Deinem post #344 eine andere Syntax verstanden, auch mit Punkt zwischen Device und Channel:

Code Auswählen Erweitern

set d_ccu datapoint HmIP_pr_wz.1.DETECTION=0 HmIP_pr_bz.1.DETECTION=0

Nun müssen aber erst alle Devices aufgelistet werden (mit Komma getrennt) und danach die Channels (mit Blank getrennt).
Da muss ich meine Füll-Logik umbauen. Wird auch gehen, ich teste heute mal im laufe des Tages. Danke nochmal.

[Dirk070]

Schnelltest:

Code Auswählen Erweitern

set ccu3 datapoint CCU_EG_WZ_Bl1PBU_GAL,CCU_EG_WZ_Bl1PBU_GAR 4.LEVEL=100 4.LEVEL=50

Beide Rolladen fahren auf 50, offenbar zieht der 2. Channel für beide Devices....

Hiermit

Code Auswählen Erweitern

set ccu3 datapoint CCU_EG_WZ_Bl1PBU_GAL,CCU_EG_WZ_Bl1PBU_GAR 4.LEVEL=90,4.LEVEL=50
fahren beide Rolladen auf 90....

Grundsätzlich sollte die Funktion doch für mehrere Devices mit unterschiedlichen Set-Befehlen sein, oder?
Zumindest hatte ich den post #302 so interpretiert:

Code Auswählen Erweitern

set ccuIODev datapoint Rollo1.1.LEVEL=10 Rollo2.LEVEL=20 LampeWohn.1.STATE=0

[zap]

Ich muss mir das im Code nochmal anschauen, wie ich es implementiert habe

[Dirk070]

Danke zap, ich teste dann gerne wieder.

[Dirk070]

Ich muss mir das im Code nochmal anschauen, wie ich es implementiert habe

Das müsste die Routine HMCCU_SetMultipleDatapoints im 88_HMCCU.pm sein, oder?

Code Auswählen Erweitern

######################################################################
# Set multiple datapoints on CCU in a single request.
# Parameter params is a hash reference. Keys are full qualified CCU
# datapoint specifications in format:
#   no.interface.{address|fhemdev}:channelno.datapoint
# Parameter no defines the command order.
######################################################################

[zap]

Das ist die allgemeine Funktion um beliebige Datenpunkte zu setzen.

Ich habe nochmal nachgeschaut. Die Funktion setzt bei allen angegebenen Devices die angegebenen Datenpunkte. Da die Datenpunkte von FHEM an HMCCU in einem Hash übergeben werden, weiß HMCCU nichts über die Reihenfolge in der Kommandozeile. Daher greift manchmal die 90% und manchmal die 50%. Einige Besipiele zum Verständnis:

set d_ccu datapoint a,b 4.LEVEL=50
=> a.4.LEVEL=50
=> b.4.LEVEL=50

set d_ccu datapoint a,b 4.LEVEL=50,4.LEVEL=100
=> a.4.LEVEL=50
=> a.4.LEVEL=100
=> b.4.LEVEL=50
=> b.4.LEVEL=100

Wobei 50 und 100 auch in umgekehrter Reihenfolge gesetzt werden können (Zufall).

Wenn das Deine Anforderungen nicht abdeckt: was hättest Du gerne?

Völlige Flexibilität bietet nur die Ausführung von Homematic Script.

[Dirk070]

Ich habe neue Versionen der HMCCU Module eingecheckt.

Neue Funktionen:

• HMCCU: Neuer Befehl set datapoint für das gleichzeitige Setzen von Datenpunkten in mehreren FHEM HMCCUDEV/HMCCUCHN Devices. Beispiel siehe unten.

Gleichzeitiges Setzen mehrerer Datenpunkte für mehrere FHEM HMCCUCHN/HMCCUDEV Devices:

Der Befehl "set datapoint" im Modul HMCCU erlaubt das Setzen mehrerer Datenpunkte in verschiedenen Geräten in einem einzigen CCU-Request. Dadurch können Timing Probleme beim getrennten Ausführen mehrerer "set datapoint" Befehle ggf. verringert oder umgangen werden.

Beispiel: 1 Rollladen (Rollo1, Typ HMCCUDEV) soll auf 10%, 1 Rollladen (Rollo2, Typ HMCCUCHN) auf 20% gesetzt werden. Außerdem soll die Lampe LampeWohn (Typ HMCCUDEV) ausgeschaltet werden.

Code Auswählen Erweitern

set ccuIODev datapoint Rollo1.1.LEVEL=10 Rollo2.LEVEL=20 LampeWohn.1.STATE=0

Die Angabe eines Datenpunkts folgt dem Schema:

HMCCUDEV: FHEMDevName.Kanal.Datenpunkt=Wert
HMCCUCHN: FHEMDevName.Datenpunkt=Wert

Hallo zap,

Danke für's Nachschauen. Ich bräuchte eine Funktion, wie ich Sie aus Deinem Post (s.o.) verstanden habe.

Hintergrund:
Ich habe 10 Rolladen und einige Lampen. Wenn ich abends oder morgen die Rolladen ansteuere, kommen dabei recht viele SET's zusammen.
Ich prüfe in einer eigenen Funktion, ob die Rolladen nicht schon tiefer oder höher sind, als diese nun fahren sollen, und noch so einiges.
Da es dadurch eine zentrale Funktion gibt, wollte ich die Last der Requests an die CCU reduzieren und die SET's sammeln.

Lange Rede, kurzer Sinn:
Ich bräuchte die Möglichkeit, diverse HMCCU-Devices mit teils unterschiedlichen Datapoints auf unterschiedliche Werte zu setzen.
Also genauso, wie Du es im Beispiel geschrieben hast: Rollo1 auf 10, Rollo2 auf 20 und die Lampe auf 0

Wenn ich das zu unklar beschreibe, melde Dich gerne.

Danke schon mal und viele Grüße
Dirk

PS: Du hattest geschrieben "Da die Datenpunkte von FHEM an HMCCU in einem Hash übergeben werden, weiß HMCCU nichts über die Reihenfolge in der Kommandozeile."
Könnte es sein, dass Du dieses Problem damit umgehen wolltest, die gesamte Befehlskette pro Device mit Punkten zu trennen? Dann blieben die Devices, Datapoints und Values ja immer korrekt zusammen.

[zap]

Das ist seltsam: anders umgesetzt als dokumentiert. Echt krass. Was hat mich da geritten ....

Ich denke, da kann ich kurzfristig was liefern, vielleicht schon morgen

[Dirk070]

Abweichungen zwischen Functional- und Technical-Design sind in der IT doch gar nicht so selten [emoji6]

Danke und schöne Grüße
Dirk

[zap]

Ich habe gerade ein Update für HMCCU eingecheckt. Damit geht nun sowas:

set d_ccu HM_ST_WR_Trockner.3.STATE=true HM_LI_KU_Decke.STATE=true HM_ST_WZ_Lampe1.1.STATE=true HM_RO_WZ_Terrasse.1.LEVEL=100

Bei HMCCUDEV Devices muss man eine Kanalnummer angeben, bei HMCCUCHN Devices nicht (siehe im Beispiel HM_LI_KU_Decke)