HMCCU 5.0 Beta verfügbar

[zap]

So, nun habe ich hoffentich wieder etwas Zeit zu experimentieren.

Oje ... Spaß beiseite: Deine fundierten Kommentare sind jederzeit willkommen

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

Schwierig ... das sind mir zu viele Definitionen, die eigentlich das gleiche bedeuten. Anderer Vorschlag: Ich verwende die Begriffe ParameterSet bezogen, also so, wie sie auch in der CCU verwendet werden. Ich unterscheide nicht zwischen control, states und value (in der CCU gibt es da keinen Unterschied):

- config: remanente Einstellungen, Konfiguration (=> ParameterSets "MASTER", "LINK")
- values (states, datapoints, control): Werte, die für die Steuerung der Geräte verwendet werden und/oder den aktuellen Status der Geräte anzeigen. Values kann man lesen und/oder schreiben und sie werden von der CCU per Push aktualisiert (=> ParameterSet "VALUE")

Darauf beziehen sich auch die Befehle, die für alle Gerätetypen identisch sind:

- set config: Einzelne Einstellungen setzen (=> MASTER, LINK)
- get config: Alle Einstellungen lesen (=> MASTER, LINK)
- get values: Alle Werte lesen (=> VALUES)
- set datapoint: Ein oder mehrere Wert(e) schreiben (=> VALUES)
- get datapoint: Einen Wert lesen (=> VALUES)
- get update: Alle Einstellungen und alle Werte lesen, Abkürzung für "get config" + "get values" (=> MASTER, LINK, VALUES)

Je nach Gerätetyp gibt es zusätzliche Befehle, die aber eigentlich nichts anderes als Abkürzungen für "set/get config" und "set/get datapoint" sind. Diese Befehle werden dynamisch in Abhängigkeit von der HM-Rolle eines Kanals in der CCU bereitgestellt (z.B. SHUTTER_CONTACT).

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].

Ok, ist so umgesetzt.

- 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.

Ist eigentlich ganz einfach:
DeviceInfo zunächst die Definition der VALUE ParameterSets aus (Datentypen, aktueller Wert). Außerdem die DeviceDescription (CCU Nomenklatur)
paramDesc: Gibt die Definition der Werte aller Parametersets aus. Auch hier wieder CCU Nomenklatur. In der CCU und in der HM-Doku sind alle Werte in diesen ParameterSets "Parameter". Angewendet auf das weiter oben definierte:
- config => Parameter des ParameterSets MASTER
- values / datapoint => Parameter des ParameterSets VALUES

Ist halt ein Spagat zwischen EQ-3/CCU Begriffen und FHEM-Begriffen.

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

Siehe erster Beitrag in diesem Thread. Am besten von Github updaten. Das SVN (contrib) aktualisiere ich nur ab und zu.

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!

Wenn HMCCUDEV oder HMCCUCHN die Kanalrolle erkennt, werden alle Defaults automatisch gesetzt und Befehle, die vom Gerätetyp abhängen, dynamisch ergänzt. Der Befehl "set defaults" ist für die Geräte gedacht, deren Rollen ich noch nicht in HMCCUConf.pm definiert habe. Die verwenden dann erst mal die alten Defaults aus 4.3, sofern vorhanden.

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

Vermutlich ein Thermostat mit den Wochenprogrammen, oder? Vorschlag? Die Einstellungen von Channel 0 nie anzeigen? Nur als Readings speichern?

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.

Mal sehen, ob ich das etwas vereinfachen kann. Vielleicht bietet sich auch ein erweiterter Modus oder Expertenmodus an. Diese Infos sind halt sehr nützlich für mich, wenn ein Benutzer ein neues, noch nicht automatisch erkanntes Gerät nutzt. Dann kann ich mit diesen Infos eine Konfiguration in HMCCUConf.pm ergänzen.

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

Analog deviceinfo ... mal sehen.

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

Es gibt - glaube ich - mehr Module, die "disable" nutzen als "ignore". Ich halte mich daran: https://wiki.fhem.de/wiki/DevelopmentModuleAPI#IsDisabled

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

Verstehe nicht, was Du meinst. Für jedes Device (HMCCUCHN, HMCCUDEV) kann IODev gesetzt werden. Wieso sollte das ein Problem sein?

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?

attr ccuflags showLinkReadings



Ansonsten: Ich teste gerade die 4.4 intensiv mit allen Gerätetypen, die ich selbst im Einsatz habe. Danach nochmal ein Testlauf mit meiner alten 4.3 fhem.cfg mit 70 Geräten. Wenn das alles läuft, ist die 4.3 Geschichte.

Der Wechsel vom alten auf's neue MacBook kostet jetzt aber erst mal etwas Zeit, bis wieder alles eingerichtet ist

[BadenPower]

Hallo zap,

- set config: Einzelne Einstellungen setzen (=> MASTER, LINK)
- get config: Alle Einstellungen lesen (=> MASTER, LINK)
- get values: Alle Werte lesen (=> VALUES)

Das Parameterset SERVICE fehlt noch!?

.

[zap]

Muss ich mir anschauen (im Code). Das Paramset gibt es ja nur bei HmIP und HmIP-Wired. Falls es fehlt. ergänze ich es. Solle relativ einfach sein.

[kjmEjfu]

Wäre es möglich SABOTAGE als Standard durchkommen zu lassen? Ich muss das aktuell bei jedem Gerät (HMCCUDEV) in das ccureadingfilter-Attribut packen, was irgendwo unnötig ist, da die Sabotage ja schon eher zu den Standardwerten gehören dürfte.

Wobei ich gerade feststelle, dass weder

Code Auswählen Erweitern

ccureadingfilter 0.SABOTAGE

noch

Code Auswählen Erweitern

ccureadingfilter SABOTAGE

überhaupt funktionieren. Wodurch könnte das denn unterdrückt werden?

[zap]

Du musst in ccuflags showDeviceReadings setzen, damit alle Readings vom Kanal 0 angezeigt werden. Die meisten dieser Readings werden allerdings sowieso in battery, activity usw. abgebildet.
SABOTAGE, ERROR und andere Fehlerzustände landen in hmstate.

[kjmEjfu]

Du musst in ccuflags showDeviceReadings setzen, damit alle Readings vom Kanal 0 angezeigt werden. Die meisten dieser Readings werden allerdings sowieso in battery, activity usw. abgebildet.
SABOTAGE, ERROR und andere Fehlerzustände landen in hmstate.

Aaaah, das sich ein ccuflags auch in den jeweiligen Devices versteckt ist mir bisher entgangen. Danke.

[zap]

Ich habe die 4 Flags show(Device|Config|Link|Service)Readings spendiert, um die Anzahl der Readings per Default etwas einzudämmen. Gerade die Config-Readings aus dem Parameterset MASTER ufern doch ziemlich aus. Wer die unbedingt benötigt, muss eben das Flag setzen.

Es gibt übrigens seit heute / gestern eine Update auf github sowie im Contrib (version im I/O Device = 4.4.057). Damit habe ich vor allem die Device-Erkennung verbessert.
Die Beschreibung auf Seite 1 dieses Threads ist nun auch etwas aktueller und ausführlicher.

https://forum.fhem.de/index.php/topic,107077.0.html

[kjmEjfu]

Ich habe gerade mal hmstate in Verbindung mit HOMEMODE ausprobiert. Das ist uncool
Ein eigenes Reading sabotage hilft da schon enorm weiter. Das kann ich mir per ccureadingname aber tatsächlich nur definieren, wenn ich auch showDeviceReadings setze. Womit ich dann aber alle Kanal 0 Readings habe, hmm.

[juemuc]

Hallo zap,

leider misslingt das update von 4.4.052 auf 4.4.057.
Ich erhalte diese Info:

Code Auswählen Erweitern

2020.12.31 17:27:31 1 : Downloading https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
2020.12.31 17:27:32 1 : UPD FHEM/HMCCUConf.pm
2020.12.31 17:27:32 1 : saving fhem.cfg
2020.12.31 17:27:32 1 : saving ./log/fhem.save
2020.12.31 17:27:32 1 :
2020.12.31 17:27:32 1 : New entries in the CHANGED file:
2020.12.31 17:27:32 1 : 404: Not Found
2020.12.31 17:27:32 1 :
2020.12.31 17:27:32 1 : update finished, "shutdown restart" is needed to activate the changes.
Viele Grüße
Jürgen

[juemuc]

Hallo zap,
nach einem downgrade auf die 4.3 war nun ein update auf die 4.4.057 möglich.

Ich habe aktuell folgende "Lücke" gefunden. Für den Klingelsensor fehlen die "default-Attribute".

Code Auswählen Erweitern

HMCCUDEV: HM_Sen_DB_PCB_NEQ0956261 No default attributes found

Welche Infos benötigst Du hierfür?
Ein get deviceinfo liefert:

Code Auswählen Erweitern

Device channels and datapoints
CHN NEQ0956261:0 HM_Sen_DB_PCB_NEQ0956261:0
  DPT {b} BidCos-RF.NEQ0956261:0.UNREACH = false [RE]
  DPT {b} BidCos-RF.NEQ0956261:0.STICKY_UNREACH = false [RWE]
  DPT {b} BidCos-RF.NEQ0956261:0.CONFIG_PENDING = false [RE]
  DPT {b} BidCos-RF.NEQ0956261:0.LOWBAT = false [RE]
  DPT {n} BidCos-RF.NEQ0956261:0.RSSI_DEVICE = 1 [RE]
  DPT {n} BidCos-RF.NEQ0956261:0.RSSI_PEER = 1 [RE]
  DPT {b} BidCos-RF.NEQ0956261:0.DEVICE_IN_BOOTLOADER = false [RE]
  DPT {b} BidCos-RF.NEQ0956261:0.UPDATE_PENDING = false [RE]
  DPT {n} BidCos-RF.NEQ0956261:0.AES_KEY = 0 [R]
CHN NEQ0956261:1 HM_Sen_DB_PCB_NEQ0956261:1
  DPT {b} BidCos-RF.NEQ0956261:1.PRESS_SHORT =  [WE]
  DPT {b} BidCos-RF.NEQ0956261:1.INSTALL_TEST =  [E]
  DPT {b} BidCos-RF.NEQ0956261:1.PRESS_CONT =  [E]

Device detection:
StateDatapoint = 1.PRESS_SHORT KEY
ControlDatapoint = 1.PRESS_SHORT KEY

Recommended module for device definition: HMCCUCHN

Current state datapoint = 1.PRESS_SHORT

Current control datapoint = 1.PRESS_SHORT
Device description
Device NEQ0956261 HM_Sen_DB_PCB_NEQ0956261 [HM-Sen-DB-PCB]
  CHILDREN: NEQ0956261:0,NEQ0956261:1
  FIRMWARE: 1.0
  FLAGS: Visible
  INTERFACE: PEQ1950749
  PARAMSETS: MASTER
  RF_ADDRESS: 5112799
  ROAMING: 0
  RX_MODE: LAZY_CONFIG,BURST
  UPDATABLE: 1
Channel NEQ0956261:0 HM_Sen_DB_PCB_NEQ0956261:0 [MAINTENANCE]
  AES_ACTIVE: 0
  DIRECTION: NONE
  FLAGS: Visible,Internal
  PARAMSETS: MASTER,VALUES
  PARENT: NEQ0956261
  PARENT_TYPE: HM-Sen-DB-PCB
Channel NEQ0956261:1 HM_Sen_DB_PCB_NEQ0956261:1 [KEY] known
  AES_ACTIVE: 1
  DIRECTION: SENDER
  FLAGS: Visible
  LINK_SOURCE_ROLES: KEYMATIC,REMOTECONTROL_RECEIVER,SWITCH,WINMATIC
  PARAMSETS: LINK,MASTER,VALUES
  PARENT: NEQ0956261
  PARENT_TYPE: HM-Sen-DB-PCB

Defaults

Support for role KEY of device type HM-Sen-DB-PCB is built in.



Viele Grüße
Jürgen

[juemuc]

Hallo zap,

auch beim Bewegungsmelder gibt es noch ein "Problem". Unter 4.3 konnte man set BWM dedection-on/off setzen. Das geht unter 4.4 (noch) nicht.

Code Auswählen Erweitern

Device channels and datapoints
CHN 00091A498F0907:0 BWP Antje:0
  DPT {b} HmIP-RF.00091A498F0907:0.CONFIG_PENDING = false [RE]
  DPT {b} HmIP-RF.00091A498F0907:0.DUTY_CYCLE = false [RE]
  DPT {n} HmIP-RF.00091A498F0907:0.ERROR_CODE = 0 [RE]
  DPT {b} HmIP-RF.00091A498F0907:0.INSTALL_TEST = false [RW]
  DPT {b} HmIP-RF.00091A498F0907:0.LOW_BAT = false [RE]
  DPT {f} HmIP-RF.00091A498F0907:0.OPERATING_VOLTAGE = 3.000000 [RE]
  DPT {i} HmIP-RF.00091A498F0907:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
  DPT {n} HmIP-RF.00091A498F0907:0.RSSI_DEVICE = 208 [RE]
  DPT {n} HmIP-RF.00091A498F0907:0.RSSI_PEER = 211 [RE]
  DPT {b} HmIP-RF.00091A498F0907:0.SABOTAGE = false [RE]
  DPT {b} HmIP-RF.00091A498F0907:0.UNREACH = false [RE]
  DPT {b} HmIP-RF.00091A498F0907:0.UPDATE_PENDING = false [RE]
CHN 00091A498F0907:1 HmIP-SMI 00091A498F0907:1
  DPT {f} HmIP-RF.00091A498F0907:1.CURRENT_ILLUMINATION = 0.000000 [RE]
  DPT {i} HmIP-RF.00091A498F0907:1.CURRENT_ILLUMINATION_STATUS = 0 [RE]
  DPT {f} HmIP-RF.00091A498F0907:1.ILLUMINATION = 31.100000 [RE]
  DPT {i} HmIP-RF.00091A498F0907:1.ILLUMINATION_STATUS = 0 [RE]
  DPT {b} HmIP-RF.00091A498F0907:1.MOTION = false [RE]
  DPT {b} HmIP-RF.00091A498F0907:1.MOTION_DETECTION_ACTIVE = true [RWE]
  DPT {b} HmIP-RF.00091A498F0907:1.RESET_MOTION =  [W]

Device detection:
StateDatapoint = 1.MOTION MOTIONDETECTOR_TRANSCEIVER
ControlDatapoint = 1.MOTION_DETECTION_ACTIVE MOTIONDETECTOR_TRANSCEIVER

Recommended module for device definition: HMCCUCHN

Current state datapoint = 1.MOTION

Current control datapoint = 1.MOTION_DETECTION_ACTIVE
Device description
Device 00091A498F0907 BWP Antje [HmIP-SMI]
  AES_ACTIVE: 1
  AVAILABLE_FIRMWARE: 0.0.0
  CHILDREN: 00091A498F0907:0,00091A498F0907:1,00091A498F0907:2,00091A498F0907:3
  DIRECTION: NONE
  FIRMWARE: 1.4.8
  FIRMWARE_UPDATE_STATE: UP_TO_DATE
  FLAGS: Visible
  PARAMSETS: MASTER,SERVICE
  RF_ADDRESS: 6122220
  ROAMING: 0
  RX_MODE: ALWAYS,LAZY_CONFIG,BURST
  SUBTYPE: SMI
  UPDATABLE: 1
Channel 00091A498F0907:0 BWP Antje:0 [MAINTENANCE]
  AES_ACTIVE: 1
  DIRECTION: NONE
  FLAGS: Visible
  PARAMSETS: MASTER,VALUES,SERVICE
  PARENT: 00091A498F0907
  PARENT_TYPE: HmIP-SMI
  RF_ADDRESS: 0
  ROAMING: 0
  RX_MODE:
  UPDATABLE: 1
Channel 00091A498F0907:1 HmIP-SMI 00091A498F0907:1 [MOTIONDETECTOR_TRANSCEIVER] known
  AES_ACTIVE: 1
  DIRECTION: SENDER
  FLAGS: Visible
  LINK_SOURCE_ROLES: CONDITIONAL_SWITCH
  PARAMSETS: MASTER,VALUES,LINK,SERVICE
  PARENT: 00091A498F0907
  PARENT_TYPE: HmIP-SMI
  RF_ADDRESS: 0
  ROAMING: 0
  RX_MODE:
  UPDATABLE: 1

Defaults

Support for role MOTIONDETECTOR_TRANSCEIVER of device type HmIP-SMI is built in.


Viele Grüße
Jürgen

[zap]

@juemuc:

Zum Bewegungsmelder: Die Befehle heißen jetzt einfach set on/off statt set detection-on/detection-off. Schau mal, ob Du die beiden Befehle hast.

Zur Klingel: Kommt diese Fehlermeldung mit den fehlenden Defaults beim Starten von FHEM? Kann ich mir nicht erklären, da laut get deviceInfo HMCCU das Gerät erkennt. Kannst Du mal ein List von dem Device machen?

[juemuc]

Hallo zap,

beim Klingelsensor kommt die Meldung, wenn ich den Befehl "set SENSOR defaults reset" aufrufe. Das Device wurde ja bereits unter 4.3 definiert. Ich wollte hier auch Deiner Empfehlung nachkommen 

Beim Bewegungsmelder sind die Befehle schon da. Es passiert aber nichts. Auch unter 4.3 musste "set BWM dedection-on/off" verwendet werden. Da gab es ja auch schon on/off.

Viele Grüße

Jürgen

[juemuc]

Hallo zap,

kleine Korrektur beim Bewegungsmelder:

"off" setzen funktioniert. "on" leider nicht.

Viele Grüße
Jürgen

[zap]

Machst Du mal bitte ein list für beide Geräte?