HMCCUCHAN generischer Ansatz

[martinp876]

kein problem. ich habe nicht erwartet dass du den code so übernimmst. das ergebnis ist entscheident. das konzept als 2.
alle kanäle darzustellen ist kein overkill. funktioniert super in culhm. es hat schon seinen grund, dass eq3 es so organisiert hat. so lange du es nicht torpedierst bin ich dabei. es macht die struktur einfach,  homogen und kompatibel. für mich gibt es keinen anderen Weg.
direktverknüpfungen sind ein muss. ich habe auch schon alle ausgelesen und dargestellt.geht doch super einfach. ohne geht es für mich nicht. einrichten ist prio 2, aber Pflicht.
ich will immernoch von Konfiguration im ccu frontend unabhängig werden. bestmöglich.  bisher sieht es gut aus. 2 consolen ist nicht mein plan.

wichtig ist auch, dass die kommandos einfach, sehr einfach sind. besser automatich. in der frühen phase ist es bei mir normal, dass kommandos komplexe parameter haben. aber am ende, in der finalen version ist es inakzeptabel . beispiel ist dein kommando devicelist. es darf nur einen parameter haben. keine weiteren optionen. list listet alle entities. nicht dessen anzahl -was will ich damit? ich will bei der eingabe nicht die syntax nachsehen müssen. und ein createchn legt alle neuen kanäle an, update.. wie beschrieben.
ich sage es einmal so: die developer sind nerds und machen oft nerd frontends. wir müssen aber mehr "Steve Jobs". "max 1 button .
konfiguriere also alles automatisch und komplett. der nerd kann es dann verpfuschen. wenige können optimieren, wenn du gut warst. und es wird immer besser!

wieder einmal meine Sicht. 

[Ralli]

Kurze Zwischenfrage: kann die jeweilige RF-Adresse der Devices aus der CCU mit ausgelesen und in den Internals der fhem-Definitionen der Devices mit dargestellt werden?

Ich hatte in der Vergangenheit immer mal wieder einen Dauersender, den ich dann mit einem CUL und einem Skript ausfindig gemacht hatte. Die verursachende RF-Adresse musste ich dann immer in dezimal umrechnen und in der /etc/config/homematic.regadom suchen, um auf die SN des Devices zu kommen.

[marvin78]

So als Richtschnur: Dinge, die man nur einmal macht (Geräte anlernen, verknüpfen, ...) sollte man in der CCU machen. Alles andere, also Nutzung der Geräte, in FHEM. So ist es auch in anderen Smarthome Plattformen gelöst (ioBroker, OpenHab).

Das heißt aber nicht, dass das der bessere Ansatz ist. Es ist im Gegenteil einer Bequemlichkeit der Entwickler geschuldet und nicht der Notwendigkeit oder Einfachheit.

[martinp876]

Die RF Adresse wird natürlich ausgelesen. Sie muss auch "abfragbar" sein. Ich würde sie entweder in meiner "Chan 0" darstellen oder über ein "get info" kommando zusammen mit sekundär Informationen ausgeben. Ich versuche immer, die Liste der Internals nicht endlos anwachsen zu lassen.
Dirk hat das letzte Wort zur offiziellen Implementierung

[Ralli]

Alles klar. Wie, ist mir eigentlich egal, Hauptsache, ich kann gezielt nach der RF-Adresse suchen (am liebsten im Hex-Format) und bekomme das zugehörige Device mit der SN zurück.

[martinp876]

Hallo Dirk,
Die hmccu ist nicht korrekt angelegt.
Die ccu ist das übergeordnete device. Allerdings ist sie als bidcos device angelegt. Das macht schlussendlich probleme.

Defacto hat jedes rpc interface  ein (wichtiges) virtueles device mit 50 kanälen. Zumindest ist das für bidcos und hmip so.
Da es nun 2 (oder 4) devices gibt mit je 50 kanäle welche gepeert werden können macht es keinen sinn, dies als HMCCU zu instanziieren.
Die seriennummer  (Adresse) des bidcos darf nicht der ccu zugeordnet werden.
Kannst mdu das bereinigen?

Gruß Martin

[martinp876]

Hallo Dirk,
ich habe die neue version nun eingespielt. Mir ist nicht klar, was jetzt alles funktionieren soll.
Vorab:
wenn ich über RPC ein getValue absetze bekomme ich als Antwort "0" und die Info, dass Parameter fehlen. Weit du, was hier fehlt?

Code Auswählen Erweitern

{HMCCURPCPROC_SendRequest ($defs{d_rpc178046BidCos_RF},"setValue", "OEQ0693948:1","LEVEL","1.0")}
sollte mein device einschalten. was könnte das Problem sein?

Zu deinen Anpassungen - ich habe einmal die "gets" aus HMCCUCHN probiert. Bist du hier am Ziel oder noch am Umbauen?
config
Definition: get <name> config [device] [<filter-expr>]
- Filter sind wohl nicht notwendig. "device" würde ich entfernen. Der Kanal "0" sollte immer device und kanal 0 auf einmal anzeigen.
- ich bekomme AES = 0. Sollte "false" sein, da bool.
configdesc
Definition:perfekt
- bei Kanal "0" (MAINTENANCE) sollte immer das "Device" enthalten sein. Leider kommt da keine Antwort. Wenn keine Daten da sind sollte zumindest ein "none" zurück kommen.

configlist
was ist der Unterschied und warum braucht man 2 Kommandos?

alle Config
- werden die Daten aus dem cache von fhem gelesen? oder dem cache der ccu?
- Kann man den cacheupdate erzwingen? Fhem? CCU?
- Die konfigurationen der Links fehlen komplett. In definition und bei den Parametern
- die Peers sind nicht ersichtlich

deviceinfo
- im Channel brauche ich das nicht für alle Kanäle. Nur den einen Anzeigen

CHN MEQ0649984:0 las:0
  DPT {b} BidCos-RF.MEQ0649984:0.UNREACH = false [RE]

- Den ccu-namen hätte ich weg gelassen. Dafür den fhem namen eingetragen. Diesen nutzen wir hier
- "BidCos-RF.MEQ0649984:0." schlicht weglassen. Das ist doch schon klar.
- mir fehlt die eigentliche Beschreibung der Werte in der Form mit

MIN  |MAX    |TYPE   |UNIT   |DEF    |OPER   |FLAGS  |VALUE_LIST
INHIBIT                 :      |1      |BOOL   |-      |       |RWE    |Visible        |-      |
INSTALL_TEST            :      |1      |BOOL   |-      |       |RW     |Visible,Internal       |-      |
ON_TIME                 :0     |8580000        |FLOAT  |s      |0      |W      |Visible        |-      |
STATE                   :      |1      |BOOL   |-      |       |RWE    |Visible        |-      |
WORKING                 :      |1      |BOOL   |-      |       |RE     |Internal,Visible       |-      |
                           MIN  |MAX    |TYPE   |UNIT   |DEF    |OPER   |FLAGS  |VALUE_LIST

SHORT_OFF_TIME_MODE     :      |2      |ENUM   |-      |-      |RW     |Visible        |TIME_IS_ABSOLUTE,TIME_IS_MINIMAL       |
SHORT_ONDELAY_TIME      :0     |111600 |FLOAT  |s      |0      |RW     |Visible        |-      |
SHORT_ON_TIME           :0     |108000 |FLOAT  |s      |111600 |RW     |Visible        |-      |
SHORT_ON_TIME_MODE      :      |2      |ENUM   |-      |-      |RW     |Visible        |TIME_IS_ABSOLUTE,TIME_IS_MINIMAL       |
UI_HINT                 :-     |-      |STRING |-      |-      |RW     |Visible        |-      |

Generell ist dies dann aber in configdesc enthalten, also duplikate.

devstate
keine Reaktion bei mir. "none" oder "fail" ist das Mindeste.
Warum aber nicht gleich ein Update aller "VALUES" Parameter? Du sparst fast nix und kannst nur einen Parameter updaten.
Dann ist auch der Hinweis auf "STATE" egal. Alles einfacher, weniger einzustellen.
Das kommando kommt nicht in einem saparaten Fenser - warum? Nicht konsistent.

update
was ist mit "State" queried? Verstehe ich nicht.
Was bedeuted "nicht so genau aber schneller"?  Will jemand auch ungenaue updates?
Mir sind diese Kommentare komplett unverstädlich. Im code will ich es nicht nachlesen müssen. Allerdings muss ich wohl, will ich es verstehen.

Gruß Martin

[zap]

Ich schreibe morgen an dieser Stelle einiges zu den Änderungen in 4.4 in Bezug auf die internen Datenstrukturen sowie MEthoden, um auf sie zuzugreifen.

Was meinst Du mit neuer Version? Die Beta findest Du in contrib/HMCCU/FHEM.

[zap]

Guten Morgen Martin,

gestern habe ich die 4.4 Beta im contrib eingecheckt: https://forum.fhem.de/index.php/topic,107077.0.html

Intern hat sich einiges getan. Die wichtigsten Änderungen gibt es bei der Aktualisierung der CCU Geräte per RPC Schnittstellen.

Im Modul HMCCURPCPROC gibt es einen neuen Befehl get devicedesc. Damit wird die Device- sowie die Paramset-Description aller CCU Geräte, die der Schnittstelle des aktuellen HMCCURPCPROC Device zugeordnet sind, per RPC abgefragt und im Hash vom I/O Device gespeichert. Wenn der Befehl mit einer Geräteadresse aufgerufen wird, wird nur dieses Gerät inklusive seiner Kanäle synchronisiert.
Diese Synchronisation wird auch während der Initialisierung des HMCCURPCPROC Device ausgeführt. Ausnahme ist CUxD. Eine Synchronisation aller Geräte bewirkt hier, dass die CCU nicht mehr reagiert.
Intern verwendet der Befehl "get devicedesc" die Funktionen HMCCURPCPROC_GetDeviceDesc() und HMCCURPCPROC_GetParamsetDesc().

Wie gesagt, die Informationen werden dann im Hash vom I/O Device gespeichert:

Device Description: $hash->{hmccu}{device}{Interface}{Address}
Paramset Description: $hash->{hmccu}{model}{Type}{Fw_Ver}{Channel}{Paramset}

Platzhalter in kursiv. "Fw_Ver" ist eine Kombination aus Firmware Version und Version der Beschreibung. Das musste ich einführen, da sich die Paramsets je nach Firmware Version unterscheiden können. Die Device Description habe ich um einige Parameter ergänzt, die alle mit "_" beginnen. z.B. "_model" und "_fw_ver" als Einsprung in die "model" Datenstruktur.

Es gibt einige Funktionen in HMCCU, die den Zugriff auf diese Datenstrukturen ermöglichen:

HMCCU_AddDeviceDesc(): Fügt eine Device Description hinzu
HMCCU_GetDeviceDesc(): Liefert eine Hash-Referenz für die interne Device Description. Akzeptiert auch den Hash eines HMCCUCHN/HMCCUDEV Device als Parameter.
HMCCU_GetDeviceAddresses(): Liefert die Adressen aller Geräte und/oder Kanäle. Filterung möglich.

HMCCU_ExistsDeviceModel(): Prüft, ob ein Gerätetyp bereits bekannt ist.
HMCCU_AddDeviceModel(): Fügt einen Gerätetyp hinzu.
HMCCU_GetDeviceModel(): Liefert eine Hash-Referenz für die interne Gerätetyp Beschreibung.
HMCCU_GetClientDeviceModel(): Wie oben, allerdings genügt als Parameter der Hash eines HMCCUDEV oder HMCCUCHN Device.
HMCCU_FlagsToStr(): Wandelt einige Bitmasks in lesbare Springs um.

Zur Anwendung kommen die neuen Funktionen und Datenstrukturen im Modul HMCCUCHN bei den Befehlen get config, get configlist, get configdesc, get devicedesc. Diese Befehle verwenden soweit möglich die im I/O Device gespeicherten Informationen. Sie unterstützen außerdem alle Paramsets eines Device oder Kanals.
Alle anderen Befehle sowie HMCCUDEV habe ich noch nicht angefasst.

Zu Deinen anderen Fragen aus Deinem vorherigen Beitrag:

- Bei vielen RPC Requests muss der richtige Datentyp übergeben werden. Das könnte das Problem beim Setzen von LEVEL sein. Du übergibst einen String, erwartet wird aber FLOAT. Versuche es doch mal mit dem (leider schlecht dokumentierten) Befehl set rpcparameter, z.B. set xy rpcparameter VALUES LEVEL=100:DOUBLE.
- Die RPC Schnittstelle gibt bei BOOL Werten immer 0/1 zurück, auch bei den Events. Die ReGa hingegen interpretiert die RPC Werte und liefert dementsprechend true/false. Daher immer die Substitute Attribute bei vielen Devices, die das "normieren". Ich würde das auch nicht automatisieren. Es gibt User, die stehen auf "Raw Values".
- Die Ausgabe von Device Info kann ich noch anpassen
- get update: Ein "Value()" liefert immer den Wert, den die CCU gecacht hat. Daher entspricht er nicht unbedingt dem aktuellen, tatsächlichen Wert im Gerät. Ein State() hingegen zwingt die CCU, explizit beim Gerät den aktuellen Wert zu holen. Das dauert etwas länger. Ich würde mir darüber aber keine großen Gedanken machen, da alle Befehle zum Lesen von Datenpunkten wie "get update" sowie auch "get datapoint" oder "get devstate" eher selten bis nie genutzt werden, da die Werte von der CCU sowieso per RPC-Server automatisch aktualisiert werden. Wer möchte schon regelmäßig manuell oder per AT die Werte abfragen.

[martinp876]

Ah - das es in Contribute zu finden ist, ist mir entgangen.

HMCCURPCPROC finde ich nicht in contribute.

Wenn der Befehl mit einer Geräteadresse aufgerufen wird

Warum Geräteadresse? alles (ALLES) sollte mit den FHEM Namen aufgerufen werden. alles andere ist "nerd" - kann sich keiner merken.

Ich habe die Dateien aus contribute eingepflegt. Nun habe ich kein RPC Interface mehr. Auch das Attribut der CCU rpcinterfaces ist nicht mehr verfügbar. Somit kann ich es erst einmal nicht testen. Was ist bei mir falsch?

Wenn der Befehl mit einer Geräteadresse aufgerufen wird, wird nur dieses Gerät inklusive seiner Kanäle synchronisiert.

da ich nicht testen kann ist mir einiges unklar:
- evtl will ich die Spec nur "einsehen". Wie geht dies? Wenn FHEM es also "gecached" hat reicht dies zu 99,99% da es sich um die Spezifikation handelt. Diese ist gleich für alle Devices dieses Type und ändert sich nur bei einem SW-Update der CCU. 
=> nach einem Update der CCU kann ich einmalig alles lesen. Die Spec wird ja auch für alle anderen Operationen genutzt (enums,...) - muss also sowieso gelesen werden
==> warum also so komplex? das kannst du doch alles im Hintergrund ohne Kommando machen!

Eine Synchronisation aller Geräte bewirkt hier, dass die CCU nicht mehr reagiert.

den Fall habe ich nicht. Hast du berücksichtigt, dass du nur einmal je "model-typ"  lesen musst?

Paramset Description: $hash->{hmccu}{model}{Type}{Fw_Ver}{Channel}{Paramset}

Du hast auch die FW-Version berücksichtigt - sehr gut! hatte ich immer vernachlässigt.

Die Datenstruktur hört sich gut an. Allerdings kann ich es noch nicht testen.

Die RPC Schnittstelle gibt bei BOOL Werten immer 0/1 zurück ....,

das kannst (und solltest) du automatisch ersetzen, da du ja den Datentyp kennst. genauso wie Enums kannst du bool ersetzen. Der Anwender muss ich nicht kümmern.

Ich würde das auch nicht automatisieren. Es gibt User, die stehen auf "Raw Values".

Da stimme ich nicht überein. Die Anwender können genauso auf true/false parsen. Nerds können das. Normale Anwender wollen es lesbar. Meine tiefe Überzeigung.

get update: Ein "Value()"...

das ist eine sehr wichtige Info. Die solltest du genauso in der Beschreibung verankern. Es beeinflusst den Duty-cycle,...

Ich würde mir darüber aber keine großen Gedanken machen,

sehe ich anders. Durch deinen Kommentar erzwingst du, dass ich mir überlegen muss was das soll. Typisch reicht sicher der cache-wert.
Die Namensgebung halte ich für wenig intuitiv. Ein "cached" oder "CCU-cached" vs "forceRead" oder "readDevice" wären für mich deutlicher als Value/State. Das merke ich mich auf dauer noch nicht einmal.

Sobald ich infos habe, wie ich den contribute-code zum Laufen bekomme teste ich einmal

[martinp876]

noch etwas: die Defintition der "HMCCURPCPROC" entites funktioniert nicht mehr

2020.01.06 12:48:41.122 1: define d_rpc178046BidCos_RF HMCCURPCPROC http://192.168.178.46 BidCos-RF: Invalid port or interface BidCos-RF
2020.01.06 12:48:41.189 1: define d_rpc178046HmIP_RF HMCCURPCPROC http://192.168.178.46 HmIP-RF: Invalid port or interface HmIP-RF

Was ist zu tun? Was mache ich falsch?

[zap]

HMCCURPCPROC ist hier: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/HMCCU/FHEM/88_HMCCURPCPROC.pm.

Ich habe alle Module im contrib von meiner laufenden Entwicklungsumgebung kopiert. Das sollte sich zumindest starten lassen.

Der Befehl get devicedesc im RPC Device mit einer Geräteadresse aufzurufen, ist eher zum Testen gedacht. Normalerweise würde man alles syncen. Aber ich baue noch den FHEM Namen ein.

Die Daten werden ja im Hintergrund bzw. bei der Initialisierung der RPC Devices synchronisiert. Der Befehl get devicedesc im RPC Devices ist für die manuelle Synchronisierung gedacht. Dazu wird es mal ein Pendant im I/O Device geben, das dann für alle RPC-Devices die Synchronisation durchführt.

Das Problem, dass die CCU hängen bleibt, gibt es nur für das CUxD Interface. Aber das ist sowieso speziell, da binary RPC.

Zum Thema automatische Konvertierung 0/1 zu true/false: Manche bevorzugen true/false, manche aber auch on/off oder an/aus oder ... Wenn ich letzteren true/false vorschreibe, muss ich nicht lange auf die Beschwerden warten. Daher für jeden konfigurierbar. Ok, zumindest 0/1 true/false könnte man vereinheitlichen. Akzeptiert

[martinp876]

Ok. Ich plane hoffentlich am Wochenende zu testen.
Die Beschwerden zu on\off kommen sowieso.
In fhem gibt es quasi-Standarte für readings wie batterie. 0\1 ist kein mir bekannter.
Auch wenn das etwas Aufwand kostet würde ich es implementieren. Der user sollte ein möglichst einheitliches Interface präsentiert bekommen.

Aber ich bin schon auf das neue modul gespannt. Das mit contribute hatte ich natürlich übersehen