HMCCU 5.0 Beta verfügbar

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

Vorheriges Thema - Nächstes Thema

martinp876

Nächstes Thema:
Die "config" Kommandos beziehen sich auf "Register"
Die "device" kommandos auf "Zustände"
=> korrekt soweit?

Bei der Namensgebung habe ich (wieder einmal) ein Problem. Welche Bedeutung willst du dem Anwender mitgeben? Hier mein Vorschlag
- "config" bezieht sich auf Renamente Daten (hatten wir schon, scheint auch so durchgezogen
- "device" sollte nur ein einer Bedeutung im UI genutzt werden. In der CHN Welt sehe ich es erst einmal garnicht. Bestenfalls wenn wir von CHN0/Device reden.
- "Zustände" brauchen einen Namen. Da datapoint für Config und Zustände als Sammelbegriff genutzt wird ist es "verbraten". "State" ist nicht passend, schon zu häufig genutzt. "Value" wäre noch frei.
=> damit wären die Kommandos
* devicedesc => "description"
* devstate => "values"

Mir klar, es ist eine lästige Änderung zum Zeupunkt nach der einführung. Allerdings ist eine unsaubere Nomenklatur ein ewiges Problem.
Natürlich können auch andere Namen gewählt werden, nur eben eindeutig und FHEM passend.

Noch ein Problem bei mir:
ein
set <device> datapoint LEVEL 1
funktioniert genaus wenig wie ein "on". Keine Fehlermeldung, keine Reaktion.

zap

#16
Ich würde gerne bei der EQ-3 Logik bleiben:

- Ein Device verfügt über kein oder ein Paramset MASTER.
- Ein Kanal verfügt über ein oder mehrere Paramsets aus der Menge MASTER, LINK, VALUES, SERVICE.
- Ein Device entspricht NICHT(!) dem Kanal 0.
- Das Paramset MASTER von Kanal 0 ist NICHT(!) identisch mit dem Paramset MASTER vom Device. Daher ist eine Zusammenlegung von device und channel 0 zwar möglich, aber für den erfahrenen Nutzer eventuell verwirrend. => Ich setzte es jetzt aber mal so um, wohlwissend, dass es Chaos gibt, sobald EQ-3 ein Device rausbringt, das auch in Kanal 0 einen MASTER verwenden.!
- Ich unterscheide Datenpunkte (VALUES), Konfigurationsparameter (MASTER) und Linkparameter (LINK)

Zuordnung der Befehle zu Paramsets:

set/get config, get configlist => MASTER, LINK
set/get datapoint, get update => VALUES
set/get paramset, get paramsetlist => Alle Paramsets.

Folgende Befehle dienen der reinen Informationsanzeige:

get devicedesc, get paramsetdesc


=> Kanal 0 und 'device' in HMCCUCHN Devices ist eine Krücke, damit der Nutzer nicht auch noch ein HMCCUDEV definieren muss, um Parameter in MASTER abfragen und setzen zu können. Am liebsten würde ich HMCCUCHN entfernen, da HMCCUDEV alles eigentlich viel logischer implementiert. Ist allerdings Overhead, wenn man z.B. ein einfaches Device wie einen Fenstersensor einbinden möchte.

Das Paramset VALUES entspricht den Datenpunkten (Datapoints). Die Befehle get/set datapoint und get update beziehen sich auf das Paramset VALUES. Das Paramset VALUES ist das einzige, dessen Werte von der CCU per RPC Server automatisch aktualisiert werden. Die Befehle get datapoint und get update sind daher nur notwendig, wenn man mal explizit Werte von der CCU holen möchte. get datapoint ist dabei die "kleinste" Einheit. Es entspricht im Prinzip der State() bzw. Value() HMScript-Methode eines Datenpunktes. get update hingegen ruft Value()/State() für alle Datenpunkte eines Kanals oder aller Kanäle eines Gerätes auf (HMCCUDEV).
Die Datapoint Befehle verwenden nicht RPC sondern HMScripts. Das hat den Vorteil, dass man mit einem Befehl Datenpunkte aus mehreren Kanälen / Paramsets setzen kann. Der RPC Request setParamset kann immer nur Parameter innerhalb eines Paramsets setzen.

Zitat von: martinp876 am 12 Januar 2020, 12:08:32
get <HMccuChn> paramsetdesc
Ich würde die Auswahl channel/device streichen. Mein Vorschlag ist wie schon vormals erwähnt, das "Device" im "Chan0" zusammenzufassen.
Wähle ich "Channel" als Option bei einem Kanal >0 bekomme ich immer auch Kanal0. Das macht keinen Sinn und ist typisch eh wenig interessante Info. Ch0 bezieht sich auf "die Kommunikation" und ist bei 90% aller Geräte identisch.
Antrag 1) Kanal 0 wird nur für Kanal 0 ausgegeben.
Antrag 2) Device wird immer automatisch bei Kanal 0 ausgegeben
Antrag 3) als Überschrift wäre der DeviceTyp und der KanalTyp schön

Ch0 unterscheidet sich je nach Interface (BidCos, IP, ...). Ch0 enthält z.B. auch LOWBAT, ist also durchaus hilfreich. Als User möche ich nicht für jedes Device auch noch ein HMCCUCHN Device für Kanal 0 definieren, um diese Infos zu bekommen. Die Bildschirmausgaben kann ich alle noch anpassen (auch Dinge wie short / long bei Links). Im Moment liegt die Prio auf funktionalen Dingen bzw. die v4.4. benutzbar zu machen.

Zitat
get <HMccuChn> config/configList
- Ich sehe nicht, dass bei config die Register als Readings gespeichert werden
- ich verstehe nicht, warum man speichern in Readings manuell anstossen muss. Das sollte immer passieren, wenn gelesen wurde.

Vielleicht noch ein Fehler. Normalerweise sollten die Readings mit "R-..." auftauchen.

Zitat
Zum Inhalt: Link Readings
Im Gegensatz zu Parameter-Description gibt es den Link Satz bei den eigentlichen Parametern. Link bedeutet, dass das Device gepeert ist und zu diesem peering ein Registersatz existiert.
=> für jedes einzelne Peering existiert ein Link-Datensatz.
=> du musst also zuerst die Links auslesen, dann die Link-Parametersätze

Kommt, nur nicht alles auf einmal. Muss nebenher noch arbeiten.
Links haben im Moment niedrige Prio. Bis ich das implementiert haben, kann man sie in der CCU einfach und komfortabel einrichten.

Zitat
get <HMccuChn> deviceinfo
das wird, nehme ich an, obsolet.

Ja.

Zitat
get <HMccuChn> datapoint
klappt bei mir nicht. Muss ich etwa besonderes tun?

Vermutlich das leidige ccureadingfilter Thema. Setze mal das Attribut auf .* oder lösche ccudef-readingfilter im I/O Device.

Zitat
Eingeltlich sollten die Readings automatisch, ohne Kommando, upgedated werden. Ein "force-read-device-states" wäre notwendig, wenn es bedenken beim automatischen update gibt. Sonst ist es obsolet.

Genau das macht ja der RPC-Server.

2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Ralli

Zitat von: zap am 12 Januar 2020, 16:57:07
... Am liebsten würde ich HMCCUCHN entfernen, da HMCCUDEV alles eigentlich viel logischer implementiert. Ist allerdings Overhead, wenn man z.B. ein einfaches Device wie einen Fenstersensor einbinden möchte

Genau - und speziell bspw. dann, wenn man ein Wired-Device mit 12 Kanälen eingebunden hat, von denen jeder Kanal einem anderen Raum für einen Fensterkontakt zugeordnet ist. Und deswegen plädiere ich dafür, grds. auch nur einen Kanal als fhem-Device definieren zu können.
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

zap

#18
Ok, das ist jetzt ein Argument für HMCCUCHN. Für HMCCUDEV spricht, dass es Geräte gibt, deren Datenpunkte in verschiedenen Kanälen liegen (HmIP Steckdosen mit Energiemessung, Thermostate,  ...). Da macht dann HMCCUDEV das Leben leichter.

Vielleicht finde ich ja mal eine Lösung, die beidem gerecht wird.

Beispiel:


CHN 0001D3C990BC3C:1 ST-WR-Trockner:1
  DPT {b} HmIP-RF.0001D3C990BC3C:1.PRESS_LONG =  [E]
  DPT {b} HmIP-RF.0001D3C990BC3C:1.PRESS_SHORT =  [E]
CHN 0001D3C990BC3C:3 ST-WR-Trockner:3
  DPT {f} HmIP-RF.0001D3C990BC3C:3.ON_TIME =  [W]
  DPT {i} HmIP-RF.0001D3C990BC3C:3.PROCESS = 0 [RE]
  DPT {i} HmIP-RF.0001D3C990BC3C:3.SECTION = 0 [RE]
  DPT {i} HmIP-RF.0001D3C990BC3C:3.SECTION_STATUS = 0 [RE]
  DPT {b} HmIP-RF.0001D3C990BC3C:3.STATE = false [RWE]
CHN 0001D3C990BC3C:6 ST-WR-Trockner:6
  DPT {f} HmIP-RF.0001D3C990BC3C:6.CURRENT = 0.000000 [RE]
  DPT {i} HmIP-RF.0001D3C990BC3C:6.CURRENT_STATUS = 0 [RE]
  DPT {f} HmIP-RF.0001D3C990BC3C:6.ENERGY_COUNTER = 89936.700000 [RE]
  DPT {b} HmIP-RF.0001D3C990BC3C:6.ENERGY_COUNTER_OVERFLOW = false [RE]
  DPT {f} HmIP-RF.0001D3C990BC3C:6.FREQUENCY = 49.970000 [RE]
  DPT {i} HmIP-RF.0001D3C990BC3C:6.FREQUENCY_STATUS = 0 [RE]
  DPT {f} HmIP-RF.0001D3C990BC3C:6.POWER = 0.000000 [RE]
  DPT {i} HmIP-RF.0001D3C990BC3C:6.POWER_STATUS = 0 [RE]
  DPT {f} HmIP-RF.0001D3C990BC3C:6.VOLTAGE = 233.100000 [RE]
  DPT {i} HmIP-RF.0001D3C990BC3C:6.VOLTAGE_STATUS = 0 [RE]
CHN 0001D3C990BC3C:8 ST-WR-Trockner:8
  DPT {i} HmIP-RF.0001D3C990BC3C:8.WEEK_PROGRAM_CHANNEL_LOCKS = 0 [RE]
  DPT {i} HmIP-RF.0001D3C990BC3C:8.WEEK_PROGRAM_TARGET_CHANNEL_LOCK =  [W]
  DPT {i} HmIP-RF.0001D3C990BC3C:8.WEEK_PROGRAM_TARGET_CHANNEL_LOCKS =  [W]


Um das mit HMCCUCHN abzubilden, bräuchte ich also mindestens 4 Devices. Mit HMCCUDEV habe ich alles an einer Stelle.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Ralli

Verstehe.

Ich habe noch ein Argument: Der 2-Kanal-Switch. Den verwende ich bspw. für Licht in zwei verschiedenen Räumen.
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

martinp876

#20
Mal die ersten antworten :
Hnccudev und chn parallen ist aufwändig.
Für mich gibt es nur chn. Ggf muss ich es mir selbst basteln. Als ich vor jahren anfing und mit rudi diskutierte hat er klar gesagt, dass fhem funktionen Einzel verwaltet. Devices sind nicht wirklich konform.
Deine Entscheidung. Gib mir rechtzeitig Bescheid.

Klar sind die master sets des device und chn0 unterschiedlich. Wo ist das problem? Alles kaum ein Aufwand. Nur eine Festlegung.
Ein paar "erfahrene" user sind einfacher umgestellt als hoffentlich viele neulinge. Das device und chn0 sind notwendig. Aber sehen will sie der user fast nie.

Wie gesagt, nenne deine Ziele. Wenn sie zu mir passen, ok. Sonst werde ich den Chanel layer selbst umsetzen. Keine Drohung, nur eine Klarstellung. Es sind schlicht 2 Wege. Der device-ansatz findet mit Sicherheit Freunde!

Nachtrag: genau wie ralli gesagt hat ist fhem nach funktionen getrennt. All Darstellungen. Wäre schade ( für mich nicht nutzbar) wenn hmccu das nicht unterstützt und sei  eigenes ding dreht.

zap

Ich habe kein Problem damit, HMCCUDEV und HMCCUCHN parallel zu unterstützen. Beide Module sind einfach gehalten. Die "Intelligenz" steckt in HMCCU und HMCCURPCPROC. Wenn jemand nur HMCCUCHN nutzen möchte, kann er das gerne tun.

Als Nutzer ist es für mich logischer, wenn ein Homematic Gerät einem FHEM Gerät entspricht => HMCCUDEV.
Keine Regel ohne Ausnahme: Es gibt Geräte (Fernbedienungen, Mehrfachschalter), bei denen HMCCUCHN die bessere Wahl ist.

Aber als Nutzer möchte ich nicht für die Steuerung eines Thermostaten oder einer Steckdose mehrere Devices definieren und verwenden müssen, um Temperatur und Wochenprogramm zu steuern, nur weil EQ-3 diese Funktionen in verschiedene Kanäle gepackt hat. Wenn ich die Fragen in diesem Forum zu HMCCU sehe, sehen das die Nutzer genauso und nutzen hauptsächlich HMCCUDEV.

Und wenn jetzt das Argument kommt, dass man das in FHEM ja alles schön mit Readinggroups und ähnlichen Konstrukten abbilden kann: Warum sollte man sich das antun? Das macht die Welt dann eher noch komplexer. Man baut etwas nach, was rein logisch in der CCU und in HMCCUDEV schon existiert.

Das Motto von HMCCU ist: Best of both worlds (FHEM + CCU). Soll heißen: Dinge, die die CCU gut kann und/oder die man eher selten anfassen muss, macht man in der CCU. Alles andere in FHEM.

Beispiel:
CCU: Anlernen von Devices, Verknüpfung von Devices, Anlegen von Wochenprogrammen, ...
FHEM: Steuerung, Anzeige von Zuständen, ...

Der Vorteil dieser Aufteilung zeigt sich am besten bei HmIP und HmIP-Wired: Ich musste so ziemlich genau 2 Zeilen Code in HMCCU ändern, damit die beiden neuen Protokolle unterstützt werden (damit das neue Adressformat erkannt wird).

Je mehr man von den Funktionen der CCU in FHEM nachbaut, desto anfälliger und vor allem aufwändiger werden diese Lösungen bei Änderungen auf Herstellerseite.

Ich hoffe, damit wird klarer, welche Ziele ich mit HMCCU verfolge.

@Martin: Was sind Deine Ziele? Wofür möchtest Du HMCCUCHN / HMCCU verwenden? Schwebt Dir eine Integration in VCCU vor? Vielleicht kannst Du darauf mal etwas genauer eingehen.
Ich muss bei der Weiterentwicklung von HMCCU alle User berücksichtigen.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

zap

Nächste Iteration der 4.4 ist im contrib eingecheckt. Die HMCCUCHN Befehle habe ich nochmal angepasst. Kurze Zusammenfassung weiter unten. Sonstige Änderungen.

Die Readings werden nun einigermaßen intelligent aktualisiert:
- Wenn eine Regel im Attribut substitute existiert, greift diese zuerst
- Wenn nicht, werden Default Werte eingesetzt, z.B. true/false bei BOOL Parametern. Außerdem werden ENUM Werte übernommen, z.B. beim Datenpunkt ERROR (z.B. NO_ERROR, SABOTAGE). Dafür muss man also keine substitute Regel mehr erstellen.

Die (geänderten) Befehle aus der CommandRef:

set <name> paramset [device] [<paramset>] <parameter>=<value[:<type>]> [...]

Set multiple datapoints or config parameters by using RPC interface instead of Rega. With option 'device' a parameter set of the device is set instead of the current channel. Parameter paramset is a valid parameter set name (i.e. MASTER, LINK, ...). The default parameter set is 'VALUES'. Supports attribute 'ccuscaleval' for datapoints. Parameter parameter must be a valid datapoint or config parameter name. If type is not specified, it's taken from parameter set definition. The default type is STRING. Valid types are STRING, BOOL, INTEGER, FLOAT, DOUBLE

set values => Alias für set paramset mit paramset = VALUES

set link => Alias für set paramset mit paramset = LINK

set config => Alias für set paramset mit paramset = MASTER

get <name> paramset [<paramset>[,...]] [<filter-expr>]
Get parameters from all or specific parameter sets of device and channel. If attribute 'ccureadings' is 0 results are displayed in browser window. Otherwise they are stored as readings beginning with "R-" for MASTER parameters and "L-" for LINK parameters. Values from other parameter sets are stored without prefix. Prefixes can be modified with attribute 'ccuReadingPrefix'. If no paramset is specified, all parameter sets will be read. Parameters can be filtered by filter-expr. If option 'device' is specified parameters of device are read. Without option 'device' parameters of current channel and channel 0 are read.

get values => Alias für get paramset mit paramset = VALUES

get links => Alias für get paramset mit paramset = LINK

get config => Alias für get paramset mit paramset = MASTER
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

martinp876

Hört sich gut an.

A) braucht man den parameterset im komando? Die parameter sind m.e eindeutig. Die zuordnung kannst du selbst machen.
B) mir ist nicht klar, ob du LINK verstanden hast. Es gibt schlicht keinen Parametersatz LINK. es gibt einen parametersatzTYP LINK. Jedes (JEDES) direkte peering erzeugt einen eigenen parametersatz vom typ LINK. Als Adresse des jeweiligen link satzen musst du die Adresse des peers angeben. Steht im dokument zu den Datenpunkten von eq3 beschrieben. Funktioniert genau so. Auch in culhm.
Für link brauchst du somit in jedem fall eine 2 stufige Adressierung. Peeraddr:Parameter.
Natürlich muss als peeradresse der name der gepeerten hmccuchn entity genutzt werden. Wir arbeiten ja auf hochsprache und nicht im maschinencode :)

Am Wochenende werde ich es testen. Danke

zap

#24
get links liest Link spezifische Parameter, die im Parameterset LINK liegen. Die sind immer da, auch wenn ein Kanal gar nicht verknüpft ist. Beispiel für einen Fensterkontakt:

1.EXPECT_AES = false
1.PEER_NEEDS_BURST = false

Links an sich (also Verknüpfungen wie Fensterkontakt mit Thermostat) werden (noch) nicht unterstützt.
Und ich bin mir auch nicht sicher, ob die kurzfrisitg unterstützt werden, s.a. meinen vorvorherigen Post ("best of both worlds").

Vielleicht ist "get links" hier etwas misleading. Ich denke mir nen anderen Befehl aus. Oder es kommt irgendwann ein "get peer"
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

martinp876

#25
Ich bin ein Freund von getallconfig in einem Schuss. 
Da es aus dem Cache gelesen wird ist es kein funkproblem.

Was link ohne Adresse soll ist mir nicht klar.  Evtl das senden an die zentrale.
Bei hm rf existiert es nicht.

Um die Anforderung mit dem auslesen zu präzisieren: einzeln lesen ist Mist. Ich hole sowieso immer alles. Am ende will ich wieder templates zu anwenden und prüfen. Es muss ein Kommando geben, welches am schluss meine komplette hmccu konfiguration auf Probleme prüft. Hat sich in culhm sehr gut bewährt.
Bei hmccu ist es erst einmal einfacher, da es um den abgleich mit dem ccu cache geht. Kein funk.
Ein forceReadDevice ist dann noch ein weiteres Thema.
Ein getConfig liest demnach die configuration was da ist MASTER plus alle LINKS.

Values sind nicht konfiguration sondern operational. Diese erwarte ich sowieso komplett in den readings.
Ein updateValues sollte also den kompletten readable value satz der ccu entlocken und in readings packen. So meine vorstellung.
Der anwender kommt mit den begriffen master\values\link hier nicht in kontakt.

Bezüglich des set datapoint sehe ich ein leichtes problem. Die aktuelle, flexibele Implementierung ist für mich zu flexibel und nicht userführend. Wir sind hier auf Assembler level, knapp über machinencode. Aber es fehlt noch ein gutes stück zur hochsprache. Und da müssen wir hin.
Ich würde i einem set nur Daten eines typs zulassen. Master parameter ODER link parameter EINES peers ODER operational values.
Für operational values sehe ich eigentlich keine setdatapoint. Das sind typisch eigenständige komandos. Der user muss hier geführt werden, was zusammen gehört. Beispiel ein set level (also "ON") . Das ist ein wert. Aber in dem kommando kann man eine einschaltdauer mitgeben. Oder bei dimmern einen level.
Einfache, einzelne kommandos kann man selbst generierent machen. Andere muss man im verbund anbieten. Das ist dann handarbeit.
Bspw kann man parameter aus value wie inhibit aus dem parametersatz lesen. Man erkennt dass es bool ist und der code generiert selbständig ein set inhibit On/off oder true/false.

Und, es ist mir klar, dass alles zeit braucht. Ich arbeite auch nebenbei ;) .Mich interessiert erst einmal was dein plan und die architektur sowie das look and feel sein soll.

zap

Die Config wird ja jetzt schon automatisch und in einem Rutsch gelesen, teilweise schon bei der Definition von IO und RPC Device, teilweise nach dem Start der RPC Server. Ebenso stehen sowohl in HMCCURPCPROC als auch HMCCU Befehle zur Verfügung, um die Daten zu aktualisieren.

Die "Einzelbefehle" in HMCCUCHN und HMCCUDEV sind insbesondere dafür gedacht, wenn ein neues Gerät bzw. ein neuer Gerätetyp erstmalig konfiguriert werden soll. Die angezeigten Informationen sollen eine Hilfe für den Nutzer sein, wenn er die für ihn interessanten Datenpunkte und Parameter ermitteln will. Dadurch muss er nicht darauf warten, dass ein neuer Gerätetyp komfortabel von HMCCU unterstützt wird. Durch den generischen Einsatz kann ein Nutzer einen neuen Gerätetyp sofort nutzen, sobald er auf den Markt kommt.

Ich möchte eben nicht wie in CUL_HM jeden einzelnen Wert für den Nutzer hardcoded im Modul implementieren.

Einige Dinge erledigt HMCCUCHN / HMCCUDEV jedoch heute schon dynamisch. So werden automatisch pct oder on-for-timer BEfehle bereitgstellt , wenn bestimmte Datenpunkte verüfgbar sind.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

martinp876

ZitatDie Config wird ja jetzt schon automatisch und in einem Rutsch gelesen, teilweise schon bei der Definition von IO und RPC Device, teilweise nach dem Start der RPC Server. Ebenso stehen sowohl in HMCCURPCPROC als auch HMCCU Befehle zur Verfügung, um die Daten zu aktualisieren.
Super!
Warum sind die Kommandos in HMCCURPCPROC  zu finden? Mein Wunsch wäre, mich im die "PROC" nicht zu kümmern. Ich will HMCCU und HMCCUCHN als bedin-interfaces. "PROC" sollten aus meiner Sicht "hidden" sein. Wenn du sie benötigt, ok. Aber muss mich (als Anwender) das interessieren?

ZitatDie angezeigten Informationen sollen eine Hilfe für den Nutzer sein, wenn er die für ihn interessanten Datenpunkte und Parameter ermitteln will
Dadurch muss er nicht darauf warten, dass ein neuer Gerätetyp komfortabel von HMCCU unterstützt wird
Verstehe ich nicht. Du musst doch kein Gerät manuell eintragen. Du solltest das Pauschal machen. In CULHM habe ich die XML Dateien nicht gehabt und somit alles manuell eintragen müssen. Allerdings zusammengefasst. Weiter ist HM-RF quasi tot. Die  Maintenance hat also ein Ende - sowieso. Ist auch schon lange Stabil.

Du - mit der CCU im Hintergrund - kannst jede Menge "Services"  wie Kommandos und Readings automatisch generieren. Die CCU bietet dir alle Optionen. Wenn in der CCU ein neues Device erscheint DARF es KEINER Aktion deinerseits benötigen, das Device per default zu unterstützen. Und das geht!!!

So - hier einmal meine Betrachtung der "Operational Parameter". Ich hatte mich schon über Konfigurations-parameter ausgelassen und meine Vorstellungen grob skiziert. Jetzt also "Operational"
1) Definition
Operational parameter sind alle Parameter im Set "VALUES". Welche ein Kanal besitzt und welche Readable sind bekommst du von der CCU mitgeteilt. Diese parameter sollten (müssen) alle in Readings dargestellt werden. Immer und gnadenlos.
2) Update der Oper-param
dies funktioniert typisch automatisch. Das ist schon jetzt so -zumindest habe ich noch keine Ausnahme gesehen. Also prima.
3) Manueller Update
Der User könnte den Verdacht haben, dass etwas nicht stimmt. Dann braucht er die Möglichkeit, einen Update anzustossen. Das will er nicht reading-für-reading machen. Macht auch keinen Sinn, da du die Werte mit einem einzigen Kommando en-bloc geliefert bekommst.
Schön wäre es, sich an die Kommandos der CUL_HM zu halten. In FHEM gibt es immer wieder (sinnvolle) Bestrebungen den Wildwuchs der Kommandos einzudämmen. CUL_HM nutzt hier "set <entity> statusRequest". Es ist ein "set" kommanod, da Rudi festgelegt hat dass ein "get" einen direkten Return-wert liefert. Also eine System-festlegung ... nicht immer beachtet (schade). Wenn du dich für ein anderes kommando entschiedest, auch gut. Hauptsache es gibt one-shot ein webCmd zum Update aller Oper-Param.
4) System-start
startet FHEM oder startet die CCU nach FHEM sind diese nicht Synchron. Ach wenn es andere Stimmen gibt ist es in meiner Welt ZWINGEND notwendig, die Systeme zu Synchronisieren!!!. Um den vorsichtigen Usern entgegen zu kommen habe ich es abschaltbar gemacht. Über ein Attribut kann man die Schärfe der Synchronisation einstellen. Nach einem Anfänglichen Schreck nutzen wohl die meisten Anwender den Service. Die Schärfe unterscheidet OperValue vs ConfigParam. Thema heute ist "OperValue".
Um dies zu realisieren braucht es a) ein Attribut in HMCCU welches die "autoReadValues" funktion steuert. Per Defaults "syncAllOperParams" b) braucht es möglicherweise eine Steuerung, die Abfrage zeitlich zu entzerren. In CUL_HM bspw ist es als Hintergrund-Job angelegt und wird verzögert wenn bspw der credit-value einen Wert unterschreitet. Das ist einstellbar - braucht aber auch niemand - klappt mit den Default-Werten.

5) Reading-Validity
Nur Readings mit nach bestem wissen gültigen Werten werden angezeit. Der "Ersteller" des Readings trägt die Verantwortung. In der Konsequenz heist dies, wenn eine Option angeboten wird die Readings lower-case oder upper-case darzustellen dann muss (MUSS) mit der Umstellung auf die neuen Werte der alte Bestand gelöscht werden.

6) Device-readings
im Kanal macht es Sinn, den Operationellen Zustand des Device (Kanal-0) darzustellen. Allerdings nur als Zusammenfassung.
Ich stelle mir das so vor:
Reading deviceState [ok|dead|unreachable|configPending|...]
Hierbei gibt es eine Prio, welche du festlegst. Ist bspw dass Device unreachable dann wird ein config-pending unterdrückt.
Welche Werte es gibt ist offen. Sollte und kann für alle aber gleich sein. Die abstrakten Darstellungen sind einfach. Das Reading sagt dem Anwender, dass es notwendig ist, im Device sich im Maintenance zu kümmern.


Noch eines zum Channel0: eq3 fasst kanal0 und "das Device" in einer Entity zusammen. Habe ich gerade noch einmal nachgesehen. Ich spreche vom User-Interface. Damit liege ich mit eq3 auf einer Line.
Der Anweder muss nicht, an keiner Stelle - zwischen "Kanal 0 " und "device" unterscheiden. Der Programmierer schon, das bist du.
Das will ich auch in HMCCUCHN.
Deine Anmerkung, EQ3 würde devices verwalten ist falsch. Es werden nur Kanäle verwaltet - welche ggf Abhängigkeiten haben. Im Web-Interface gibt es neben der "Room" Ansicht (wie fhem) auch eine "device" Ansicht ( nicht in FHEM verfügbar). Die Architektur und organisation, zuordenbarkeit, filter-optionen, benamung ist ausschliesslich auf Kanal-Ebene organisert.
Genau so wünsche ich es mir auch. 


martinp876

Noch ein Satz zum Service-Kanal. Dieser ist in jeder Entity verfügbar. Ich habe mir den Inhalt angesehen - er ist identisch für alle. Inhalt ist auch nur Information über den FW Stand. Diese Information würde ich nur im Kanal-0 CHN anbieten um die Schwemme an sinnlosen Informationen einzudämmen.

martinp876

Anbei die Ergebnisse meines (kurzen) Tests der HMCCUCHN get kommandos

get config: keine Antwort. Es sollte ein Feedback geben.
get datapoint: ein get allOperParams muss es geben.
get deviceinfo: Nachkomma -nullen sollten bei Float gelöscht werden. Sonst ist es erst einmal ok
get links: Funktioniert  nicht.
get paramset: Funktioniert  nicht.
get paramsetList: Funktioniert  nicht.
get paramsetdesc: funktioniert gut. Die Temperaturliste eines RT/TC kann man so nicht darstellen. Das muss man konsolidieren!
get update: sieht prima aus
get vales: sieht prima aus - was ist der Unterschied zu get update?

Attr stripbumber funktioniert bei den Registern nicht. Auch sonst scheint es nicht zu klappen.... mus weiter testen.


Hier noch die Ausgabe zum Kanal und welche Werte ich korrigieren würde um sinnlose info zu entfernen. Das sehe ich als einen generellen Filter welchen du hart kodierst. Es geht keine Information verloren!
Device 000E9A498DFE15 HmIP-STHD 000E9A498DFE15 [HmIP-STHD]
   Type: HmIP-STHD                                     #dieses Datenfeld fehlt im Kanal 0
   AES_ACTIVE: 1                                       # sinnlos bei IP. AES ist immer aktiv => filtern     
   AVAILABLE_FIRMWARE: 0.0.0                           # ok
   CHILDREN: 000E9A498DFE15:0,000E9A498DFE15:1,000E9A49# ok
   DIRECTION:                                          # sinnlos bei CHN0. Kann bei NULL weggelassen werden  oder nur bei CH0
   FIRMWARE: 2.2.2                                     # ok
   FIRMWARE_UPDATE_STATE: UP_TO_DATE                   # ok
   FLAGS: Visible                                      # ok
   INDEX: 0                                            # sinnlos - steht schon in der Definition
   PARAMSETS: MASTER,SERVICE                           # ok
   RF_ADDRESS: 10548197                                # ok - sollte in hex dargestellt werden
   ROAMING: 0                                          # ok
   RX_MODE: ALWAYS,LAZY_CONFIG,BURST                   # ok
   SUBTYPE: STHD                                       # ok
   UPDATABLE: 1                                        # ok
   VERSION: 3                                          # sinnlos. Kann keiner etwas mit anfangen
Channel 000E9A498DFE15:0 HmIP-STHD 000E9A498DFE15:0 [M# Type muss in die Liste der Attribute. Wird dringend benötigt
   AES_ACTIVE: 1                                       # sinnlos bei IP. AES ist immer aktiv => filtern   
   DIRECTION:                                          # sinnlos bei CHN0. Kann bei NULL weggelassen werden  oder nur bei CH0
   FLAGS: Visible                                      # ok
   INDEX: 0                                            # sinnlos - steht schon in der Definition
   PARAMSETS: MASTER,VALUES,SERVICE                    # ok
   PARENT: 000E9A498DFE15                              # fraglich. CHN0 wird eh mit device zusammengefasst - damit ist es obsolet
   PARENT_TYPE: HmIP-STHD                              # holt man vom Master - hier sinnlos
   RF_ADDRESS: 0                                       # holt man vom Master - hier sinnlos
   ROAMING: 0                                          # holt man vom Master - hier sinnlos
   RX_MODE:                                            # holt man vom Master - hier sinnlos
   UPDATABLE: 1                                        # holt man vom Master - hier sinnlos
   VERSION: 3                                          # sinnlos. Kann keiner etwas mit anfangen
Channel 000E9A498DFE15:1 HmIP-STHD 000E9A498DFE15:1 [H# Type muss in die Liste der Attribute. Wird dringend benötigt
   AES_ACTIVE: 1                                       # sinnlos bei IP. AES ist immer aktiv => filtern   
   DIRECTION: SENDER                                   # ok
   FLAGS: Visible                                      # ok
   INDEX: 1                                            # sinnlos - steht schon in der Definition
   LINK_SOURCE_ROLES: CLIMATE_CONTROL_WTH_TRV          # ok
   PARAMSETS: MASTER,VALUES,LINK,SERVICE               # ok
   PARENT: 000E9A498DFE15                              # holt man vom Master - hier sinnlos
   PARENT_TYPE: HmIP-STHD                              # holt man vom Master - hier sinnlos
   RF_ADDRESS: 0                                       # holt man vom Master - hier sinnlos
   ROAMING: 0                                          # holt man vom Master - hier sinnlos
   RX_MODE:                                            # holt man vom Master - hier sinnlos
   UPDATABLE: 1                                        # holt man vom Master - hier sinnlos
   VERSION: 3                                          # sinnlos. Kann keiner etwas mit anfangen