HMCCU 5.0 Beta verfügbar

Begonnen von zap, 05 Januar 2020, 19:49:52

Vorheriges Thema - Nächstes Thema

zap

Die normale Version wird es nicht mehr lange geben. Aber wenn Du zurück willst: einfach FHEM per update befehl aktualisieren. Wenn Du bei update keine Quelle angibst, installiert er wieder den Standard.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

The-Holgi

Hallo,
habe eine HmIP-ASIR-B1 funktioniert soweit auch.

Internals:
   CFGFN     
   DEF        000AD99396C98D
   FUUID      5fb7e524-f33f-6571-526d-1edebf7f90a72293
   IODev      d_ccu
   NAME       Sirene
   NR         88717
   STATE      ok
   TYPE       HMCCUDEV
   ccuaddr    000AD99396C98D
   ccudevstate active
   ccuif      HmIP-RF
   ccuname    HmIP-ASIR-B1 000AD99396C98D
   ccutype    HmIP-ASIR-B1
   readonly   no
   receiver   Sirene
   sender     Sirene
   OLDREADINGS:
   READINGS:
     2020-11-20 17:59:42   0.CONFIG_PENDING false
     2020-11-20 17:59:42   0.DUTY_CYCLE    false
     2020-11-20 17:59:42   0.ERROR_CODE    0
     2020-11-20 17:57:55   0.INSTALL_TEST  true
     2020-11-20 17:59:42   0.LOW_BAT       ok
     2020-11-20 17:59:42   0.OPERATING_VOLTAGE 4.6
     2020-11-20 17:59:42   0.OPERATING_VOLTAGE_STATUS NORMAL
     2020-11-20 17:59:42   0.RSSI_DEVICE   -69
     2020-11-20 17:57:55   0.RSSI_PEER     0
     2020-11-20 17:59:42   0.SABOTAGE      false
     2020-11-20 17:59:42   0.UNREACH       alive
     2020-11-20 17:57:55   0.UPDATE_PENDING false
     2020-11-20 17:59:42   3.ACOUSTIC_ALARM_ACTIVE false
     2020-11-20 17:59:42   3.OPTICAL_ALARM_ACTIVE false
     2020-11-20 17:57:55   3.ZONE_1_ACTIVE 0
     2020-11-20 17:57:55   3.ZONE_1_ALARM  0
     2020-11-20 17:57:55   3.ZONE_2_ACTIVE 0
     2020-11-20 17:57:55   3.ZONE_2_ALARM  0
     2020-11-20 17:57:55   3.ZONE_3_ACTIVE 0
     2020-11-20 17:57:55   3.ZONE_3_ALARM  0
     2020-11-20 17:57:55   3.ZONE_4_ACTIVE 0
     2020-11-20 17:57:55   3.ZONE_4_ALARM  0
     2020-11-20 17:57:55   3.ZONE_5_ACTIVE 0
     2020-11-20 17:57:55   3.ZONE_5_ALARM  0
     2020-11-20 17:57:55   3.ZONE_6_ACTIVE 0
     2020-11-20 17:57:55   3.ZONE_6_ALARM  0
     2020-11-20 17:57:55   3.ZONE_7_ACTIVE 0
     2020-11-20 17:57:55   3.ZONE_7_ALARM  0
     2020-11-20 17:59:42   activity        alive
     2020-11-20 17:59:42   battery         ok
     2020-11-20 17:59:42   devstate        ok
     2020-11-20 17:59:42   hmstate         false
     2020-11-20 17:49:56   state           false
   hmccu:
     channels   4
     devspec    000AD99396C98D
     nodefaults 0
     role       0:MAINTENANCE,1:KEY_TRANSCEIVER,2:ALARM_COND_SWITCH_RECEIVER,3:ALARM_SWITCH_VIRTUAL_RECEIVER
     semDefaults 0
     cmdlist:
       get       
       set        press:noArg on:noArg off:noArg
     control:
       chn        1
       dpt        PRESS_SHORT
     dp:
       0.ARR_TIMEOUT:
         MASTER:
           OSVAL      10
           OVAL       10
           SVAL       10
           VAL        10
         VALUES:
       0.CONFIG_PENDING:
         VALUES:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
       0.CYCLIC_INFO_MSG:
         MASTER:
           OSVAL      1
           OVAL       1
           SVAL       1
           VAL        1
         VALUES:
       0.CYCLIC_INFO_MSG_DIS:
         MASTER:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
         VALUES:
       0.CYCLIC_INFO_MSG_DIS_UNCHANGED:
         MASTER:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
         VALUES:
       0.CYCLIC_INFO_MSG_OVERDUE_THRESHOLD:
         MASTER:
           OSVAL      2
           OVAL       2
           SVAL       2
           VAL        2
         VALUES:
       0.DUTYCYCLE_LIMIT:
         MASTER:
           OSVAL      180
           OVAL       180
           SVAL       180
           VAL        180
         VALUES:
       0.DUTY_CYCLE:
         VALUES:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
       0.ENABLE_ROUTING:
         MASTER:
           OSVAL      true
           OVAL       1
           SVAL       true
           VAL        1
         VALUES:
       0.ERROR_CODE:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       0.INSTALL_TEST:
         VALUES:
           OSVAL      true
           OVAL       true
           SVAL       true
           VAL        true
       0.LOCAL_RESET_DISABLED:
         MASTER:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
         VALUES:
       0.LOW_BAT:
         VALUES:
           OSVAL      ok
           OVAL       0
           SVAL       ok
           VAL        0
       0.LOW_BAT_LIMIT:
         MASTER:
           OSVAL      3.3
           OVAL       3.3
           SVAL       3.3
           VAL        3.3
         VALUES:
       0.OPERATING_VOLTAGE:
         VALUES:
           OSVAL      4.6
           OVAL       4.6
           SVAL       4.6
           VAL        4.6
       0.OPERATING_VOLTAGE_STATUS:
         VALUES:
           OSVAL      NORMAL
           OVAL       0
           SVAL       NORMAL
           VAL        0
       0.RSSI_DEVICE:
         VALUES:
           OSVAL      -67
           OVAL       -67
           SVAL       -69
           VAL        -69
       0.RSSI_PEER:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       0.SABOTAGE:
         VALUES:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
       0.UNREACH:
         VALUES:
           OSVAL      alive
           OVAL       0
           SVAL       alive
           VAL        0
       0.UPDATE_PENDING:
         VALUES:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
       1.ALARM_MODE_TYPE:
         MASTER:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
         VALUES:
       1.ALARM_MODE_ZONE_1:
         MASTER:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
         VALUES:
       1.ALARM_MODE_ZONE_2:
         MASTER:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
         VALUES:
       1.ALARM_MODE_ZONE_3:
         MASTER:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
         VALUES:
       1.ALARM_MODE_ZONE_4:
         MASTER:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
         VALUES:
       1.ALARM_MODE_ZONE_5:
         MASTER:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
         VALUES:
       1.ALARM_MODE_ZONE_6:
         MASTER:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
         VALUES:
       1.ALARM_MODE_ZONE_7:
         MASTER:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
         VALUES:
       2.SD_MULTICAST_ZONE_1:
         MASTER:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
         VALUES:
       2.SD_MULTICAST_ZONE_2:
         MASTER:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
         VALUES:
       2.SD_MULTICAST_ZONE_3:
         MASTER:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
         VALUES:
       2.SD_MULTICAST_ZONE_4:
         MASTER:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
         VALUES:
       2.SD_MULTICAST_ZONE_5:
         MASTER:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
         VALUES:
       2.SD_MULTICAST_ZONE_6:
         MASTER:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
         VALUES:
       2.SD_MULTICAST_ZONE_7:
         MASTER:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
         VALUES:
       2.SILENT_ALARM_ZONE_1:
         MASTER:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
         VALUES:
       2.SILENT_ALARM_ZONE_2:
         MASTER:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
         VALUES:
       2.SILENT_ALARM_ZONE_3:
         MASTER:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
         VALUES:
       2.SILENT_ALARM_ZONE_4:
         MASTER:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
         VALUES:
       2.SILENT_ALARM_ZONE_5:
         MASTER:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
         VALUES:
       2.SILENT_ALARM_ZONE_6:
         MASTER:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
         VALUES:
       2.SILENT_ALARM_ZONE_7:
         MASTER:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
         VALUES:
       3.ACOUSTIC_ALARM_ACTIVE:
         VALUES:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
       3.EVENT_DELAY_UNIT:
         MASTER:
           OSVAL      S
           OVAL       1
           SVAL       S
           VAL        1
         VALUES:
       3.EVENT_DELAY_VALUE:
         MASTER:
           OSVAL      1
           OVAL       1
           SVAL       1
           VAL        1
         VALUES:
       3.EVENT_RANDOMTIME_UNIT:
         MASTER:
           OSVAL      S
           OVAL       1
           SVAL       S
           VAL        1
         VALUES:
       3.EVENT_RANDOMTIME_VALUE:
         MASTER:
           OSVAL      1
           OVAL       1
           SVAL       1
           VAL        1
         VALUES:
       3.OPTICAL_ALARM_ACTIVE:
         VALUES:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
       3.ZONE_1_ACTIVE:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       3.ZONE_1_ALARM:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       3.ZONE_2_ACTIVE:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       3.ZONE_2_ALARM:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       3.ZONE_3_ACTIVE:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       3.ZONE_3_ALARM:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       3.ZONE_4_ACTIVE:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       3.ZONE_4_ALARM:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       3.ZONE_5_ACTIVE:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       3.ZONE_5_ALARM:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       3.ZONE_6_ACTIVE:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       3.ZONE_6_ALARM:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       3.ZONE_7_ACTIVE:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       3.ZONE_7_ALARM:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
     roleCmds:
       get:
       set:
         off:
           channel    1
           role       KEY_TRANSCEIVER
           subcount   0
           syntax     V:PRESS_SHORT:1
           usage      off
         on:
           channel    1
           role       KEY_TRANSCEIVER
           subcount   0
           syntax     V:PRESS_SHORT:1
           usage      on
           subcmd:
         press:
           channel    1
           role       KEY_TRANSCEIVER
           subcount   0
           syntax     V:PRESS_SHORT:1
           usage      press
     state:
       chn        1
       dpt        PRESS_SHORT
Attributes:
   IODev      d_ccu
   ccuflags   showDeviceReadings
   room       CCU_HM
   stateFormat devstate


Was mich nur stört ist, das im webinterface on und off angezeigt werden. das ist ja so sowieso nicht nutzbar.
Alarm löse ich in der form aus:
set Sirene datapoint 3.ACOUSTIC_ALARM_SELECTION 0 3.OPTICAL_ALARM_SELECTION 1 3.DURATION_UNIT 0 3.DURATION_VALUE

Gruß Holger
Raspberry Pi 5

zap

Zitat von: The-Holgi am 20 November 2020, 18:06:14
Hallo,
habe eine HmIP-ASIR-B1 funktioniert soweit auch.

Was mich nur stört ist, das im webinterface on und off angezeigt werden. das ist ja so sowieso nicht nutzbar.

Bitte die Alarmsirene erst mal als HMCCUCHN definieren. Bei HMCCUDEV kann sich HMCCU nicht zwischen den zwei Kanälen KEY_TRANCEIVER und ALARM_SWITCH_VIRTUAL_RECEIVER entscheiden. Beide sind gültige Kanaltypen. Daher die on/off Befehle.
Alarm auslösen baue ich noch ein.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

kjmEjfu

Zitat von: zap am 21 November 2020, 16:43:51
Bitte die Alarmsirene erst mal als HMCCUCHN definieren. Bei HMCCUDEV kann sich HMCCU nicht zwischen den zwei Kanälen KEY_TRANCEIVER und ALARM_SWITCH_VIRTUAL_RECEIVER entscheiden. Beide sind gültige Kanaltypen. Daher die on/off Befehle.

Ist das eine Übergangslösung oder wird das für den ASIR/ASIR-O, und eventuell auch andere, eher die Standardlösung werden?
Migriere derzeit zu Home Assistant

zap

Zitat von: kjmEjfu am 21 November 2020, 17:50:37
Ist das eine Übergangslösung oder wird das für den ASIR/ASIR-O, und eventuell auch andere, eher die Standardlösung werden?

Ziel ist natürlich, dass auch HMCCUDEV mit den ASIRs korrekt funktioniert. Allerdings genügt für diese Geräte ein HMCCUCHN, da sowieso alle relevanten Datenpunkte in einem einzigen Kanal liegen.
HMCCUCHN ist in diesem Fall zu bevorzugen, da nicht die Gefahr besteht, dass HMCCU mehrere Kanäle erkennt, die potenziell nutzbar sind.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

kjmEjfu

Ich glaube, ich habe noch immer nicht ganz verstanden, wie HMCCU funktioniert ;-)

CHN XXXX:0 XXXX:0
  DPT {b} HmIP-RF.XXXX:0.CONFIG_PENDING = false [RE]
  DPT {b} HmIP-RF.XXXX:0.DUTY_CYCLE = false [RE]
  DPT {b} HmIP-RF.XXXX:0.ERROR_BAD_RECHARGEABLE_BATTERY_HEALTH = false [RE]
  DPT {n} HmIP-RF.XXXX:0.ERROR_CODE = 0 [RE]
  DPT {b} HmIP-RF.XXXX:0.INSTALL_TEST = true [RW]
  DPT {b} HmIP-RF.XXXX:0.LOW_BAT = false [RE]
  DPT {f} HmIP-RF.XXXX:0.OPERATING_VOLTAGE = 4.300000 [RE]
  DPT {i} HmIP-RF.XXXX:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
  DPT {n} HmIP-RF.XXXX:0.RSSI_DEVICE = 185 [RE]
  DPT {n} HmIP-RF.XXXX:0.RSSI_PEER = 0 [RE]
  DPT {b} HmIP-RF.XXXX:0.SABOTAGE = false [RE]
  DPT {b} HmIP-RF.XXXX:0.UNREACH = false [RE]
  DPT {b} HmIP-RF.XXXX:0.UPDATE_PENDING = false [RE]
CHN XXXX:3 HmIP-ASIR-O XXXX:3
  DPT {b} HmIP-RF.XXXX:3.ACOUSTIC_ALARM_ACTIVE = false [RE]
  DPT {i} HmIP-RF.XXXX:3.ACOUSTIC_ALARM_SELECTION =  [W]
  DPT {i} HmIP-RF.XXXX:3.DURATION_UNIT =  [W]
  DPT {i} HmIP-RF.XXXX:3.DURATION_VALUE =  [W]
  DPT {b} HmIP-RF.XXXX:3.OPTICAL_ALARM_ACTIVE = false [RE]
  DPT {i} HmIP-RF.XXXX:3.OPTICAL_ALARM_SELECTION =  [W]


da habe ich doch in :0 jede Menge relevante Datenpunkte und in :3 (weshalb auch immer es :3 ist), dann die ganzen Funktionen.
Migriere derzeit zu Home Assistant

The-Holgi

Zitat von: zap am 21 November 2020, 16:43:51
Bitte die Alarmsirene erst mal als HMCCUCHN definieren. Bei HMCCUDEV kann sich HMCCU nicht zwischen den zwei Kanälen KEY_TRANCEIVER und ALARM_SWITCH_VIRTUAL_RECEIVER entscheiden. Beide sind gültige Kanaltypen. Daher die on/off Befehle.
Alarm auslösen baue ich noch ein.

Hm, wenn ich als HMCCUCHN definiere läßt sich die Sirene nicht mehr mittels:
set Sirene datapoint 3.ACOUSTIC_ALARM_SELECTION 0 3.OPTICAL_ALARM_SELECTION 1 3.DURATION_UNIT 0 3.DURATION_VALUE 3
ansprechen. Meldung:
HMCCUCHN: Sirene Invalid datapoint
Raspberry Pi 5

zap

#262
Ok, mal ein paar erklärende Worte zu HMCCUCHN und HMCCUDEV.

Ein HMCCUCHN Device bezieht sich immer auf einen einzelnen Kanal. Nämlich der Kanal, der beim Define angegeben wurde. Daraus ergeben sich 2 Vorteile:

1. HMCCU weiß automatisch, wie das Gerät (über welchen Kanal) gesteuert werden kann
2. Man kann sich die Kanalnummer bei den Befehlen sparen. @The-Holgi: Du kannst "3." vor den Datenpunkten im set Befehl weglassen.

Trotzdem beinhaltet HMCCUCHN immer den Kanal 0 (@kjmEjfu). Denn das ist gar kein richtiger Kanal sondern beinhaltet Geräte bezogene Datenpunkte. Wenn man ccuflags auf showDeviceReadings setzt, sieht man also auch im HMCCUCHN Device die Readings vom Kanal 0. Einige Werte aus Kanal 0 sind sogar ohne ccuflags sichtbar, da sie HMCCU automatisch anzeigt (battery, activity = LOW_BAT, UNREACH).

Es gibt eigentlich nur noch einen Grund, HMCCUDEV zu verwenden: wenn bei einem Gerät notwendige Datenpunkte über mehrere Kanäle verteilt sind (ohne Kanal 0). Das kann z.B. eine Steckdose mit Energiemessung sein, die über eine  Kanal geschaltet wird und über einen anderen Kanal die Messwerte liefert.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

kjmEjfu

Mir ist noch was aufgefallen.

Beim HMIP-SWDO (nur da?) wird SABOTAGE (  DPT {b} HmIP-RF.0000D709953DE4:0.SABOTAGE = false [RE] ) rausgefiltert. Sollte der nicht besser standardmäßig durchgelassen werden?

Internals:
   DEF        XXXX
   FUUID      yy
   FVERSION   88_HMCCUDEV.pm:v4.4.34-s18552/2019-02-10
   IODev      d_ccu
   NAME       Sensor_EG_Gaeste_Sued_Kontakt
   NR         162
   STATE      closed
   TYPE       HMCCUDEV
   ccuaddr    XXXX
   ccudevstate active
   ccuif      HmIP-RF
   ccuname    HM-Kontakt-EG-Gaeste-Sued
   ccutype    HMIP-SWDO
   readonly   no
   READINGS:
     2020-11-26 08:13:43   1.STATE         closed
     2020-11-26 08:13:43   activity        alive
     2020-11-26 08:13:43   battery         ok
     2020-11-26 08:13:43   control         closed
     2020-11-26 08:13:43   devstate        ok
     2020-11-26 08:13:43   hmstate         sabotage
     2020-11-26 08:13:43   state           closed
   hmccu:
     channels   3
     devspec    XXXX
     nodefaults 1
     role       0:MAINTENANCE,1:SHUTTER_CONTACT,2:ALARM_COND_SWITCH_TRANSMITTER
     semDefaults 0
     cmdlist:
       get       
       set       
     control:
       chn        1
       dpt        STATE
     dp:
       0.CONFIG_PENDING:
         VALUES:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
       0.DUTY_CYCLE:
         VALUES:
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
       0.ERROR_CODE:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       1
           VAL        1
       0.INSTALL_TEST:
         VALUES:
           OSVAL      true
           OVAL       true
           SVAL       true
           VAL        true
       0.LOW_BAT:
         VALUES:
           OSVAL      ok
           OVAL       0
           SVAL       ok
           VAL        0
       0.OPERATING_VOLTAGE:
         VALUES:
           OSVAL      1.1
           OVAL       1.1
           SVAL       1.2
           VAL        1.2
       0.OPERATING_VOLTAGE_STATUS:
         VALUES:
           OSVAL      NORMAL
           OVAL       0
           SVAL       NORMAL
           VAL        0
       0.RSSI_DEVICE:
         VALUES:
           OSVAL      -69
           OVAL       -69
           SVAL       -60
           VAL        -60
       0.RSSI_PEER:
         VALUES:
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       0.SABOTAGE:
         VALUES:
           OSVAL      false
           OVAL       0
           SVAL       true
           VAL        1
       0.UNREACH:
         VALUES:
           OSVAL      alive
           OVAL       0
           SVAL       alive
           VAL        0
       0.UPDATE_PENDING:
         VALUES:
           OSVAL      false
           OVAL       false
           SVAL       false
           VAL        false
       1.STATE:
         VALUES:
           OSVAL      closed
           OVAL       0
           SVAL       closed
           VAL        0
     roleCmds:
       get:
       set:
     state:
       chn        1
       dpt        STATE
Attributes:
   HomeContactType window
   HomeModeAlarmActive armaway
   HomeOpenDontTriggerModes home|gotosleep|asleep
   HomeOpenDontTriggerModesResidents xyz
   IODev      d_ccu
   alias      Fenster Gästezimmer Süd
   devStateIcon closed:fts_window_1w open:fts_window_1w_open@red
   event-on-change-reading state,sabotage,control,battery,Activity
   group      Kontaktsensoren
   hmstatevals ERROR!7:sabotage;SABOTAGE!1:sabotage
   room       Homematic
   statedatapoint 1.STATE
   subType    threeStateSensor
   userattr   HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes subType
Migriere derzeit zu Home Assistant

kjmEjfu

Und noch was ist mir aufgefallen :-)

Bei Schaltern wird ja kein not-pressed geschickt, weshalb man event-on-update-reading setzen muss. Mit HMCCU 4.3 hat das auch funktioniert, mit 4.4 funktioniert es beim HMIP-WRC2 problemlos, aber beim HM-PB-2-WM55-2 nicht. Beide sind als HMCCUDEV angelegt.
Der WM55-2 aktualisiert alle paar Stunden komplett seine Readings und behauptet dann "1.PRESS_SHORT pressed", was natürlich wegen event-on-update-reading entsprechend auslöst.

Attribute sind bei beiden Schaltern gleich gesetzt:

Attributes:
   IODev      d_ccu
   alias      Schalter ABC
   ccureadingfilter (LOWBAT|UNREACH|PRESS)
   event-on-update-reading .*
   room       Homematic
   stateFormat B: battery S: activity
   substitute PRESS_SHORT,PRESS_LONG!(1|true):pressed


Readings:

1.PRESS_SHORT pressed 2020-11-26 14:44:53
2.PRESS_SHORT pressed 2020-11-26 14:44:53
activity alive 2020-11-26 14:44:53
battery ok 2020-11-26 14:44:53
devstate sign 2020-11-26 14:44:53
hmstate Initialized 2020-11-26 14:44:53
state Initialized 2020-01-04 11:44:17


Letzter Tastendruck war aber heute morgen um halb sieben ;-)


Das Device-Info vom WM55-2 sieht so aus:

CHN XXXX:0 HM-Schalter-OG-1:0
  DPT {b} HmIP-RF.XXXX:0.CONFIG_PENDING = false [RE]
  DPT {b} HmIP-RF.XXXX:0.DUTY_CYCLE = false [RE]
  DPT {b} HmIP-RF.XXXX:0.LOW_BAT = false [RE]
  DPT {f} HmIP-RF.XXXX:0.OPERATING_VOLTAGE = 2.800000 [RE]
  DPT {n} HmIP-RF.XXXX:0.RSSI_DEVICE = 164 [RE]
  DPT {n} HmIP-RF.XXXX:0.RSSI_PEER = 0 [RE]
  DPT {b} HmIP-RF.XXXX:0.UNREACH = false [RE]
  DPT {b} HmIP-RF.XXXX:0.UPDATE_PENDING = false [RE]
  DPT {b} HmIP-RF.XXXX:0.INSTALL_TEST = true [RW]
  DPT {i} HmIP-RF.XXXX:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
CHN XXXX:1 HM-Schalter-OG-1:1
  DPT {b} HmIP-RF.XXXX:1.PRESS_LONG =  [E]
  DPT {b} HmIP-RF.XXXX:1.PRESS_SHORT = false [E]
CHN XXXX:2 HM-Schalter-OG-1:2
  DPT {b} HmIP-RF.XXXX:2.PRESS_LONG =  [E]
  DPT {b} HmIP-RF.XXXX:2.PRESS_SHORT = false [E]


Also es steht auch tatsächlich ein false im PRESS_SHORT.
Migriere derzeit zu Home Assistant

zap

#265
Zitat von: kjmEjfu am 26 November 2020, 08:21:11
Mir ist noch was aufgefallen.

Beim HMIP-SWDO (nur da?) wird SABOTAGE (  DPT {b} HmIP-RF.0000D709953DE4:0.SABOTAGE = false [RE] ) rausgefiltert. Sollte der nicht besser standardmäßig durchgelassen werden?


Wenn tatsächlich SABOTAGE anspricht, sollte eigentlich hmstate entsprechend gesetzt werden.

Wegen dem PRESSED: bei manchen Devices schickt die CCU die Events nur, wenn die Datenpunkte zB in einem Dummy Programm abgefragt werden
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

kjmEjfu

#266
Zitat von: zap am 26 November 2020, 19:35:32
Wenn tatsächlich SABOTAGE anspricht, sollte eigentlich hmstate entsprechend gesetzt werden.

Leider auch nicht passiert.
Wobei ich es gut fände, wenn in dem Fall auch weiterhin das Reading geschrieben wird. Ist z.B. für Homemode ganz hilfreich.

Zitat von: zap am 26 November 2020, 19:35:32
Wegen dem PRESSED: bei manchen Devices schickt die CCU die Events nur, wenn die Datenpunkte zB in einem Dummy Programm abgefragt werden

Nee, nee, falsch verstanden :-) Die CCU schickt die Events schon, das hat ja auch vorher mit HMCCU 4.3 schon einwandfrei geklappt.
Beim WM55-2 kommt aber periodisch (alle 8 Stunden?) ein Update an und beim WM55-2 werden dann alle Readings (inklusive den PRESSED) aktualisiert. Dadurch sprechen die NOTIFYS/DOIFS an.
Beim HMIP-WRC2 (anderer Schalter) passiert dieses Update nicht bzw. es kommt intern(?) irgendwelche Filter zum Tragen, wodurch PRESSED nicht aktualisiert wird - außer natürlich, der Schalter wird tatsächlich gedrückt. Der macht es also so wie er soll.

WM55-2 aktualisiert bei mir periodisch:
hmstate, devstate, battery, activity, 2.PRESS_SHORT, 1.PRESS_SHORT

WRC2 hingegen nur:
hmstate, devstate, battery, activity

Wobei dieses Update inhaltlich auch noch falsch ist, da in dem Fall 1.PRESS_SHORT gar nicht gedrückt ist und sogar das DeviceInfo ein "false" anzeigt.
Migriere derzeit zu Home Assistant

fredje

Hallo, ich möchte gerne auf die Version 4.4 wechseln. Momentan habe ich nur ein paar Geräte
an einer pivccu3 angeschlossen. Die meisten Geräte hängen direkt an fhem
Wie gehe ich am besten vor ?

- löschen aller Geräte und HMCCU aus fhem
- Installation V 4.4 über "update https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt"
- HMCCU und Geräte neu in fhem installieren

Danke und Grüße ...

zap

Warte bitte noch ein paar Tage. Ich lade noch ein Update hoch, das einige Fehler behebt.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

martinp876

So, nun habe ich hoffentich wieder etwas Zeit zu experimentieren. Ich fange wieder mit "get" an:

Ich würde mich freuen, wenn wir eine Begriffsdefinition erstellen könnten. Aus meiner Erfahrung erleichtert dies die Kommunikation und das Verständniss der Kommandos. Bei CUL_HM habe ich das nicht sauber durchgezugen, nur teilweise - was ich bereue.
Bei den aktuellen Kommandos komme ich immer wieder durcheinander - aus genanntem Grund. Hier meine Vorschläge (FHEM hat sich auf littleCamelLetter Nomenklatur festgelegt!)

Ich unterscheide zwischen
- config [Cfg]: remanente Einstellungen, Konfiguration
- control [Ctrl]: Dynamische Einstellungen, also 'ein', 'Aus', Level, desired-temp,...
- states [Cond]: Zustände wie actual-temp, OS-Version, timed-on, Overload,... . States ist schon abgegriffen, so könnte man alternativ "condition" nutzen
- value [Val]: werte, also Inhalte Cfg, Ctrl oder Cond

Wie bekannt arbeite ich auf "Channel" ebene. Aber auch auf Device Ebene kann man die Begriffe sauber nutzen (so man will):
- Channel [Chn]: ein Kanal wie von HM festgelegt (das ist noch einfach)
- Device [DEVall]: Die physikalische Einheit mit allen Kanälen
- Channel0 [Dev]: Der Kommunikations-kanal des Device.
- xxx: Das Device betreffende Parameter. Ich habe keinen guten Namen hierfür
=> ich würde Chn0 und xxx zusammenfassen - für den User macht dies 100% sinn
==> in der Channel Darstellung HMCCUCHN brauche ich dann Entities für [CHN] und [DEV].

???> Es liegt bei dir, die Definitionen abzuändern - allerdings solltest du die Defintionen erstellen und in der Doku verankern.


Begriffsbestimmung gemäß deinen Kommandos
- config: Einstellungen im Device - remanent. Übersetzt zu CUL_HM wären es register Register. Passt gut, finde ich.
- Datapoint: Aktuelle Daten, dynamisch. Typisches Beispiel: Level oder State. Eine Mischung aus Control und State... unschön in der Nutzung
- DeviceInfo: Unklar. Eine wilde Sammlung aus Daten, mit und ohne Werte. Sollte überdacht und klar definiert werden um es einordnen zu können.
- pramDesc: Beschreibung der Parameter. Stellt sich die Frage, was Parameter sind.
- Parameter: Werte welche in "Config" und "datapoint" genutzt werden. Also eigentlich "Werte" oder "Value". Parameter sind semanitsch eher "Einstellungen", also "Config-Values" und "control-Values"
=> "valueDesc" wäre besser oder "valueDef" für Werte definition. Oder kurz [Val]


zu den aktuellen Tests

Version 4.4 - wie kann ich die Stabil bekommen? Beim Update ist auf 4.3 zurückgesprungen

Default parameter: Diese sollten per default gesetzt sein - ohne jede user-aktion. Der User überschreibt ausschliesslich, wenn er non-devault wünscht. An die Usability denken!

get <name> config:
    das Dev sollte nicht angedruckt werden. Ich lese 350 Zeilen zu Channel 0 und nur 52 Zeilen interessante Info zu Channel 3. Das ist schlicht nicht anwenderfreundlich

get deviceInfo:
    gemäß den namen "device" würde es sich auf alle kanäle beziehen. Es macht sinn, das auch für den Kanal anzubieten, also "ChnInfo"
    Inhaltlich ist mir unklar, welche "Info" hier zu suchen sein soll. Es ist nicht sauber abgegrenzt. Config, Condition oder control? Die Liste ist in keiner Richtung komplett. Weiter sind einige Daten mehrfach vorhanden und somit obsolet. Rx-Mode ist nicht kanalspezifisch ebenso wie Roaming, Updatable, Parent. Im rahmen der Usability sollte es unterdrückt werden. Der User hat schon genur zu lernen.
   
get parasetDesc
    auch hier überdeckt channel 0 alles. Das ist schlicht eine Katastrophe bei mir. Ich sehe alles, habe aber Probleme, das zu finden, was interessant ist.
    Paramset SERVICE ist doppelt. Es ist nur für channel 0 sinnvoll und wird aktuell doppelt ausgegeben

Allgemein:
   
Attribute
disable - in FHEM wird "ignore" zum disable genutzt. Man sollte sparsam sein mit zusützlichen Parametern. Dummy ist ein 2. allgemeines Attribut.

IODev: kann ich für jedenKanal setzen Wie soll das gehen?

Update der Daten:
   ich haben einen Kanal in der HHCU gepeert und sehe keine Information zu den Settings oder dem peering in den Readings oder per get.
   => wie und wo sollte ich das sehen/updaten können?