HMCCU 5.0 im SVN verfügbar

[zap]

Würde es evtl. Sinn machen für den HmIP-WRC6 folgendes im default zu hinterlegen:

Code Auswählen Erweitern

attr $DEVICE event-on-update-reading PRESS_LONG,PRESS_LONG_RELEASE,PRESS_LONG_START,PRESS_SHORT
Das ist ja so ziemlich die einzige Funktion des Gerätes.

Für die Rollen KEY und KEY_TRANSCEIVER passiert das schon. Welche Rollen hat den das Device? Ggf. "get deviceinfo" ausführen

[DaDiGi]

Für die Rollen KEY und KEY_TRANSCEIVER passiert das schon. Welche Rollen hat den das Device? Ggf. "get deviceinfo" ausführen

Code Auswählen Erweitern

Device channels and datapoints

DEV WZ_Wandschalter 000B58A9938C5E interface=HmIP-RF type=HmIP-WRC6
CHN 000B58A9938C5E:0 WZ_Wandschalter:0
   0.CONFIG_PENDING = false {b} [RE]
   0.DUTY_CYCLE = false {b} [RE]
   0.INSTALL_TEST = true {b} [RW]
   0.LOW_BAT = false {b} [RE]
   0.OPERATING_VOLTAGE = 2.500000 {f} [RE]
   0.OPERATING_VOLTAGE_STATUS = 0 {i} [RE]
   0.RSSI_DEVICE = 169 {n} [RE]
   0.RSSI_PEER = 0 {n} [RE]
   0.UNREACH = false {b} [RE]
   0.UPDATE_PENDING = false {b} [RE]
CHN 000B58A9938C5E:1 WZ_Wandschalter:1
   1.PRESS_LONG =  {b} [E]
   1.PRESS_SHORT = false {b} [E]
   1.PRESS_LONG_RELEASE =  {b} [E]
   1.PRESS_LONG_START =  {b} [E]
CHN 000B58A9938C5E:2 WZ_Wandschalter:2
   2.PRESS_LONG =  {b} [E]
   2.PRESS_SHORT = false {b} [E]
   2.PRESS_LONG_RELEASE =  {b} [E]
   2.PRESS_LONG_START =  {b} [E]
CHN 000B58A9938C5E:3 WZ_Wandschalter:3
   3.PRESS_LONG = false {b} [E]
   3.PRESS_SHORT = false {b} [E]
   3.PRESS_LONG_RELEASE = false {b} [E]
   3.PRESS_LONG_START = false {b} [E]
CHN 000B58A9938C5E:4 WZ_Wandschalter:4
   4.PRESS_LONG =  {b} [E]
   4.PRESS_SHORT = false {b} [E]
   4.PRESS_LONG_RELEASE =  {b} [E]
   4.PRESS_LONG_START =  {b} [E]
CHN 000B58A9938C5E:5 WZ_Wandschalter:5
   5.PRESS_LONG =  {b} [E]
   5.PRESS_SHORT = false {b} [E]
   5.PRESS_LONG_RELEASE =  {b} [E]
   5.PRESS_LONG_START =  {b} [E]
CHN 000B58A9938C5E:6 WZ_Wandschalter:6
   6.PRESS_LONG = false {b} [E]
   6.PRESS_SHORT = false {b} [E]
   6.PRESS_LONG_RELEASE = false {b} [E]
   6.PRESS_LONG_START = false {b} [E]


Device detection:
StateDatapoint = 1.PRESS_SHORT [KEY_TRANSCEIVER]
StateDatapoint = 2.PRESS_SHORT [KEY_TRANSCEIVER]
StateDatapoint = 3.PRESS_SHORT [KEY_TRANSCEIVER]
StateDatapoint = 4.PRESS_SHORT [KEY_TRANSCEIVER]
StateDatapoint = 5.PRESS_SHORT [KEY_TRANSCEIVER]
StateDatapoint = 6.PRESS_SHORT [KEY_TRANSCEIVER]
No control datapoint detected

Recommended module for device definition: HMCCUCHN

Current state datapoint = 1.PRESS_SHORT

Current control datapoint = .

Device description

Device 000B58A9938C5E WZ_Wandschalter [HmIP-WRC6]
  AES_ACTIVE: 1
  AVAILABLE_FIRMWARE: 0.0.0
  CHILDREN: 000B58A9938C5E:0,000B58A9938C5E:1,000B58A9938C5E:2,000B58A9938C5E:3,000B58A9938C5E:4,000B58A9938C5E:5,000B58A9938C5E:6
  DIRECTION: NONE
  FIRMWARE: 1.0.19
  FIRMWARE_UPDATE_STATE: UP_TO_DATE
  FLAGS: Visible
  PARAMSETS: MASTER,SERVICE
  RF_ADDRESS: 10323672
  ROAMING: 0
  RX_MODE: CONFIG
  SUBTYPE: WRC6
  UPDATABLE: 1
Channel 000B58A9938C5E:0 WZ_Wandschalter:0 [MAINTENANCE]
  AES_ACTIVE: 1
  DIRECTION: NONE
  FLAGS: Visible
  PARAMSETS: MASTER,VALUES,SERVICE
  PARENT: 000B58A9938C5E
  PARENT_TYPE: HmIP-WRC6
  RF_ADDRESS: 0
  ROAMING: 0
  RX_MODE:
  UPDATABLE: 1
Channel 000B58A9938C5E:1 WZ_Wandschalter:1 [KEY_TRANSCEIVER] known
  AES_ACTIVE: 1
  DIRECTION: SENDER
  FLAGS: Visible
  LINK_SOURCE_ROLES: REMOTE_CONTROL
  PARAMSETS: MASTER,VALUES,LINK,SERVICE
  PARENT: 000B58A9938C5E
  PARENT_TYPE: HmIP-WRC6
  RF_ADDRESS: 0
  ROAMING: 0
  RX_MODE:
  UPDATABLE: 1

Defaults

Support for role KEY_TRANSCEIVER of device type HmIP-WRC6 is built in.



[zap]

@DaDiGi

Dann sollte event-on-update-reading spätestens nach einem "set defaults reset" auf ".*" gesetzt werden.

[zap]

Sorry, ist schon eine Weile her, dass ich daran rumkonfiguriert habe und habe nicht mehr alles detailliert im Kopf, wie das alles funktioniert: Wie müsste denn das homebridge Mapping jetzt idealerweise aussehen?

eventmap hab ich gelöscht, dann ccuflags im Device auf trace gesetzt.
Aber ich sehe im Log nach Aufrufen des lock Befehls nur:

Code Auswählen Erweitern

2021.12.19 12:03:26 1: PERL WARNING: Argument "open" isn't numeric in addition (+) at ./FHEM/88_HMCCU.pm line 7294.

Der lock Befehl hat auch ohne eventmap das Fenster nur zugezogen, aber nicht verschlossen.

Du musst FHEM neu starten, wenn Du eventMap veränderst. Die internen Strukturen in FHEM enthalten leider immer noch die alten Definitionen ohne Neustart.

Mach danach bitte nochmal ein list vom Device. Irgendetwas ist da total schräg.

[zap]

Hallo zap,

in der pivccu wird ja angezeigt wenn es von deimos eine neue Version gibt. Kannst Du diese Info mit Deinem Modul auslesen und anzeigen?

Viele Grüße
Jürgen

Keine Ahnung, wie ich an die Info rankomme. Habe hier auch kein piVCCU im Einsatz, um das zu testen.

[DaDiGi]

@DaDiGi

Dann sollte event-on-update-reading spätestens nach einem "set defaults reset" auf ".*" gesetzt werden.

Ja schon, aber im Log waren keine Events zu sehen außer "state:pressed".
Erst nachdem ich die reading explizit angegeben habe.

[zap]

Code Auswählen Erweitern

Results of create command:
Not detected CCU devices:
  Garage_Abstandssensor = DIST000010 [Garage_Abstandssensor]



Homebrew Devices kann ich nicht (so einfach) einbauen, da sie natürlich in der EQ-3 Doku nicht beschrieben sind. Aber wie schon das eine oder andere Mal erwähnt: HMCCU unterstützt alle Gerätetypen, man muss sie halt manuell definieren, wenn sie von "get createDev" nicht erkannt werden.

Bei so einem Sensor ist das extrem einfach: Du definierst ein HMCCUCHN für den Kanal 1 und setzt noch das Attribut statedatapoint auf den DISTANCE Datenpunkt. That's it.


@Borkk

Gleiches gilt für Deinen Sensor: Einfach für jeden der 3 Kanäle ein HMCCUCHN definieren und statedatapoint auf den Datenpunkt setzen, den Du in STATE sehen möchtest.

[zap]

Hallo,

hab mich zuerst ins BETA-Topic verirrt und hoffe, hier nun richtig zu sein.
Hab gestern meine HMCCU Version 4.3.025 auf 5.0 per FHEM per update hochgezogen.
Der RPC-Server liefert auch weiterhin updates, es kommen regelmäßig Events rein.
Per get update bekomme ich die Datapoints auch angezeigt:

Bitte ein list vom Device + die Ausgabe von "get deviceInfo"

[Lippie]

Bitte ein list vom Device + die Ausgabe von "get deviceInfo"

Bin nun doch noch auf das Problem gekommen:

Ich hatte UserReadings für zB. brightness angelegt, um Sonderfälle berücksichtigen zu können. Das hat dazu geführt, dass die Werte vom Device, was ab HMCCU 5.0 nun die selben Readings-Bezeichnungen nutzt, überschrieben wurden. Dadurch konnte ich nicht erkennen, dass das Device im Hintergrund schon tut.
Ich gehe nun alle Devices durch, lösche meine inzwischen überflüssigen UserReadings raus und dann sollte es wieder funktionieren. Die Devices, welche ich bereits umgestellt habe, sehen alle gut aus.
Gibt es schon irgendwo (zB im Wiki) eine Übersicht zur Zuordnung der Homematic-Reading-Bezeichnungen zu den neuen Namen der Readings (zB. UNREACH == activity)?
Ansonsten such ich natürlich hier im Forum, wenn mir was fehlt.

Viele Grüße
Sebastian

[zap]

Noch nicht, aber hier mal ein Auszug aus dem Code:

Code Auswählen Erweitern


my %newReadings = (
'0.AES_KEY'           => 'sign',
'0.RSSI_DEVICE'       => 'rssidevice',
'0.RSSI_PEER'         => 'rssipeer',
'0.LOW_BAT'           => 'battery',
'0.LOWBAT'            => 'battery',
'0.OPERATING_VOLTAGE' => 'voltage',
'0.UNREACH'           => 'activity',
'0.SABOTAGE'          => 'sabotage',
'0.ERROR_SABOTAGE'    => 'sabotage'
);


Folgende Datenpunkte werden im Reading "devstate" abgebildet (auch mehrere möglich bzw. durch Komma getrennt):

Code Auswählen Erweitern


my %stName = (
'0.CONFIG_PENDING'       => 'cfgPending',
'0.DEVICE_IN_BOOTLOADER' => 'boot',
'0.STICKY_UNREACH'       => 'stickyUnreach',
'0.UPDATE_PENDING'       => 'updPending',
'0.SABOTAGE'             => 'sabotage',
'0.ERROR_SABOTAGE'       => 'sabotage'
);


[tommitiger75]

Ich habe auch noch ein Problem mit einem Virtuellen Schalter aus CUxD.
Hier bekomme ich im Logfile folgende Einträge:

Code Auswählen Erweitern

2021.12.12 16:46:06 2: HMCCU [d_ccu] Can't get device description for CUX2801001:1  HMCCU_DetectDevice:7968 HMCCU_SetDefaultSCDatapoints:8087 HMCCU_GetSCDatapoints:4640 HMCCU_UpdateParamsetReadings:4853 HMCCU_UpdateMultipleDevices:827 HMCCURPCPROC_Read:3895 CallFn:773
hier die Geräte Einstellungen, Readings und Infos:
Was muss hier noch zusätzlich eingetragen werden oder geändert werden? Grundsätzlich funktioniert der Schalter.

@Zap hast du dir das schon mal anschauen können. Nach dem letzten Update bekomme ich immer noch diese Einträge im LogFile.

Code Auswählen Erweitern

2021.12.22 19:36:13 2: HMCCU [d_ccu] Can't get device description for CUX2801001:1  HMCCU_DetectDevice:8025 HMCCU_SetDefaultSCDatapoints:8142 HMCCU_GetSCDatapoints:4654 HMCCU_UpdateParamsetReadings:4865 HMCCU_UpdateMultipleDevices:827 HMCCURPCPROC_Read:3895 CallFn:773
2021.12.22 19:36:13 2: HMCCU [d_ccu] Can't get device description for CUX2801001:2  HMCCU_DetectDevice:8025 HMCCU_SetDefaultSCDatapoints:8142 HMCCU_GetSCDatapoints:4654 HMCCU_UpdateParamsetReadings:4865 HMCCU_UpdateMultipleDevices:827 HMCCURPCPROC_Read:3895 CallFn:773
2021.12.22 19:36:13 2: HMCCU [d_ccu] Can't get device description for CUX2801001:3  HMCCU_DetectDevice:8025 HMCCU_SetDefaultSCDatapoints:8142 HMCCU_GetSCDatapoints:4654 HMCCU_UpdateParamsetReadings:4865 HMCCU_UpdateMultipleDevices:827 HMCCURPCPROC_Read:3895 CallFn:773
2021.12.22 19:36:13 2: HMCCU [d_ccu] Can't get device description for CUX2801001:4  HMCCU_DetectDevice:8025 HMCCU_SetDefaultSCDatapoints:8142 HMCCU_GetSCDatapoints:4654 HMCCU_UpdateParamsetReadings:4865 HMCCU_UpdateMultipleDevices:827 HMCCURPCPROC_Read:3895 CallFn:773
2021.12.22 19:36:13 2: HMCCU [d_ccu] Can't get device description for CUX2801001:1  HMCCU_DetectDevice:8025 HMCCU_SetDefaultSCDatapoints:8142 HMCCU_GetSCDatapoints:4654 HMCCU_UpdateParamsetReadings:4865 HMCCU_UpdateMultipleDevices:827 HMCCURPCPROC_Read:3895 CallFn:773
2021.12.22 19:36:13 2: HMCCU [d_ccu] Can't get device description for CUX2801001:2  HMCCU_DetectDevice:8025 HMCCU_SetDefaultSCDatapoints:8142 HMCCU_GetSCDatapoints:4654 HMCCU_UpdateParamsetReadings:4865 HMCCU_UpdateMultipleDevices:827 HMCCURPCPROC_Read:3895 CallFn:773
2021.12.22 19:36:32 2: HMCCU [d_ccu] Can't get device description for CUX2801001:3  HMCCU_DetectDevice:8025 HMCCU_SetDefaultSCDatapoints:8142 HMCCU_GetSCDatapoints:4654 HMCCU_UpdateParamsetReadings:4865 HMCCU_UpdateMultipleDevices:827 HMCCURPCPROC_Read:3895 CallFn:773
2021.12.22 19:36:32 2: HMCCU [d_ccu] Can't get device description for CUX2801001:4  HMCCU_DetectDevice:8025 HMCCU_SetDefaultSCDatapoints:8142 HMCCU_GetSCDatapoints:4654 HMCCU_UpdateParamsetReadings:4865 HMCCU_UpdateMultipleDevices:827 HMCCURPCPROC_Read:3895 CallFn:773

Danke für deine Arbeit und deine Unterstützung!

[juemuc]

Keine Ahnung, wie ich an die Info rankomme. Habe hier auch kein piVCCU im Einsatz, um das zu testen.

Hallo zap,
ich habe dazu nun zwei Variablen in der CCU defininiert, die ich jeweils um 00:01 Uhr neu setzen und dann in FHEM per "at" um 00:02 Uhr auslese.

In der CCU sehen beide Werte identisch aus. In FHEM kommt aber nur der Wert der zweiten Variable (Version_neu) an. Es sieht so aus, als ob der Wert der ersten Variable (ersion_aktuell) aus der CCU in FHEM zum Problem wird.

Das Skript in der CCU lautet:

Code Auswählen Erweitern

string V_a;
system.Exec("grep VERSION= /VERSION | cut -d= -f2", &V_a);
dom.GetObject (ID_SYSTEM_VARIABLES).Get ("Version_aktuell").State (V_a);
string V_n;
string cmd = "wget -qO- 'https://update.homematic.com/firmware/download?cmd=js_check_version&version=1234&product=HM-CCU3&serial='#######'";
system.Exec(cmd, &V_n);
V_n = V_n.StrValueByIndex("'",1);
dom.GetObject (ID_SYSTEM_VARIABLES).Get ("Version_neu").State (V_n);

Kannst Du helfen?

Viele Grüße
Jürgen

[Ryker]

Wie ist das eigentlich bei Variablen die ich mir per "attr ccuGetVars ..." rüberhole. Da steht im Manual nur dabei, dass ich ein intervall angeben muss. Geht das auch irgendwie, dass das in Realtime angezeigt wird.
Weil ich hab nun meine Tageslichtsimulation fürs Aquarium in die CCU verlagert, weil das dort recht cool geht mit der verzögerten Ausführung.
Dort schreibe ich mir auch ein paar sysVariablen, die ich aber gerne in RealTime im FHEM hätte. Geht das irgendwie ? - weil so dauerhafte Intervalle aller paar Sekunden für Variablen, die sich nur paar mal am Tag ändern, ist halt auch nicht so toll.

Dann der 2. Punkt.: Wenn ich mir im FHEM mit "define HM_RCV_50_xxxx HMCCUCHN BidCoS-RF:1" einen virtuellen Taster erstelle, dann ist da immer nur die Rede überall von PRESS_SHORT. Wenn ich aber mit set ein PRESS_LONG hinschicke, dann funktioniert das genauso einwandfrei. Ist das so gewollt? 
Das erstellte Virt. Taster-Object im FHEM zeigt mir als default steuerelemente ein "on" und "off" an. Hier wäre es gut, wenn man die sich per attr belegen könnte. Ich hab mir mit eventMap derweil geholfen, dass das "off" ein PRESS_LONG auslöst.

Gruß
Ryker

[meier81]

Wie ist das eigentlich bei Variablen die ich mir per "attr ccuGetVars ..." rüberhole. Da steht im Manual nur dabei, dass ich ein intervall angeben muss. Geht das auch irgendwie, dass das in Realtime angezeigt wird.
Weil ich hab nun meine Tageslichtsimulation fürs Aquarium in die CCU verlagert, weil das dort recht cool geht mit der verzögerten Ausführung.
Dort schreibe ich mir auch ein paar sysVariablen, die ich aber gerne in RealTime im FHEM hätte. Geht das irgendwie ? - weil so dauerhafte Intervalle aller paar Sekunden für Variablen, die sich nur paar mal am Tag ändern, ist halt auch nicht so toll.

Das würde mich auch interessieren ob dies nicht in Realtime funktioniert, bei Geräten z.B. tut´s das ja.
Hab bei mir nämlich auch 3 sysVariablen die sich nur 2x am Tag ändern, die benötige ich dann aber zeitnah, deswegen habe ich bei mir auch das Attribut

Code Auswählen Erweitern

ccuGetVars auf 10 Sekunden gestellt, bräuchte ich aber eigentlich die meiste Zeit nicht die Aktualisierung.

Gruß Markus

[Ryker]

Ich übergebe die Variablen-Inhalte derweil über Virtuelle-Taster über so eine Art MoorseCode in PRESS_SHORT und PRESS_LONG. Der ersten 10 PRESS_LONG Tasten ergeben Zahlen von 1 bis 0 (Taste 10 = 0) und ersten 26 PRESS_SHORT Tasten ergeben das Alphabet. und auf FHEM Seite wird das dann wieder interpretiert. Ein 11.PRESS_LONG ist quasy das End-of-Variable-Content. Das alles wird in entsprechenden Dummys+Notifies entsprechend zusammengebaut. Das geht zwar so gut wie in RealTime, aber ist absolut unübersichtlich. War eigentlich nur eine Spielerei.

Ryker