update for standard command parsing

[martinp876]

eine eher interne Funktion zum parsen der kommandos ist ab morgen am Start.
Hierzu sind HMInfo (minimale Änderung) und HMConfig auf Stand zu bringen (update).
Die Beschreibung dern Kommandos folgt dann deren Beschreibung. Optionale Parameter sind klar gekennzeichnet.
Ein
get <entity> cmdList long
gibt die Beschreibung /Bedeutung zu [optional] (listItem1|listItem2) und {default} sowie -myval- (kurz, aber hoffentlich verständlich)

Interessant sollte sein, das die Defaults sind, so man einen Parameter nicht angibt.

[martinp876]

noch ein Nachtrag und eine Schlussbetrachtung zu CUL_HM.

Schlussbetrachtung? nun ja, es wird sicher noch Maintenance geben, keine Frage. Aber seit der Einführung von HM-IP sollte jedem klar sein, dass HM-RF seitens eq3 noch eine cache-cow ist, aber ansonsten nicht weiter entwickelt werden wird.

Die letzten (leider zu holprigen, sorry) Anpassung war notwendig um das beliebteste Kommando ever (set <entity> ? und get <entity> ?) zu optimieren. Wie mir (wieder einmal) aufgefallen ist, werden diese Kommandos bei jeder Webseite und bei jeder Gelegenheit MEHRFACH aufgerufen werden. Bei einer "room" Darstellung wird das mindestens einmal je entity aufgerufen.
Somit habe ich die Performance bestmöglich optimiert, was ich glaube beim Aufbau der Webseiten auch fühlen zu können.

der Status CUL_HM:
Die Kommunukation ist recht stabil. Beim Timing, das Basisproblem der HM-RF Kommunikation - haben wir 85% des Optimums erreicht (dank sicher auch an Ansgar für die Pflege der CUL-IOs). 10% sind nicht wirklich erreichbar ohne die FW der eq3Module zu analysieren, welche ich nicht habe. Und 5% ist ein Rückstand welcher kaum lösbar sein wird - Sonderfälle. Over-all sehe ich die Stablität im "Realen Leben" bei 96%plus. Die übrigen 4% sollten durch den Kommunikations-status der Devices signalisert werden.

Die Struktur -
der  FW basiert auf den Grundzügen, welche ich vor Jahren vorgefunden haben - dank an Rudi, steht ihm zu! Funktioniert immer noch.
der Entities ist umstritten, aber ich stehe 120% dahinter. CUL_HM ist ausgelegt als möglichst wartungsarmes interface welches die Devices und Funktionen abbilden soll. Somit ist die (von eq3 mit bedacht definierte) Struktur der Device in der Zentrale abzubilden. Daraus erklären sich die "Kanäle". Das macht die Implementierung "smooth", strukturiert, straight und wartugsarm. Seit der Implementierung war strukturell keine Anpassung notwendig, ein paar Optimierungen, klar.
CUL_HM bieter weiter einige wenige "higher-level" Methoden, die vorgegebenen Funktionen sinnvoll zu bedienen (RT-Teams, SD-Teams, Groupings...).
Bei RTs scheinen die Kanäle etwas strange, ok. Bei Switches und Buttons sind die Kanäle definitiv der korrekte weg, funktionen abzubilden!

Controlling the crowed
FHEM als Multi-System fähig sollte die Sammel-funktionen über Entites uns installationen ermöglichen. Als Platform ist dies aber schwer und eine "Familien-abhängige" Prüfung/Überwachung wäre angesagt. Leider ist keine übergreifende "CUL_HM" entity vorgesehen - eine klare Schwachstelle von FHEM. Hierzu habe ich HMInfo erstellt, welches versucht, das abzubilden.
FHEM würde m.E. gut daran tun, zu jeder "Familie" einen Top-level zu fordern. Diese liefern dann Alarme unterschiedlicher level und Config-checks. Der Anwender sollte nur einen FHEM-Config-Check starten und alle Installationen prüfen lassen. Schade... aber HMInfo liefert alles, was mit eingefallen ist zu diesem Thema.
Das Controlling der Devices findet über Templates statt. Wer diese nicht nutzt muss ein device/entity/funktion faktisch manuell kontrollieren. Da kann man nicht helfen. Die Ablehnung der Templates verstehe ich nicht, erinnert mich aber an die Skepsis gegenüber der VCCU, welche mittlerweile (nach lager Träger anlauf-Phase) auf breiter Basis empfohlen wird.
Frank's sehr gute Erweiterung zu Registern ist ein prima Interface - ersetzt aber das Controlling nicht!

Higher level Funktionen
CUL_HM war nie gedacht, Funktionalitäten zu realisieren. Es stellt nur Funktionen zu Verfügung. Mein plan war immer, Funktionalitäten zu erstellen. Allerdings wird es hier schwierigen, da die Granularität nicht auf dern Hand liegt.
Ich sehe bspw eine Entity "Heizung" je Raum. Dies beinhaltet dann alle enties (Kanäle) welche hierzu beitragen. Das sind alle RT und TC Kanäle welche ich brauche plus die Fensterkontakte oder ein Fenster-öffner (wenn man so etwas hat). Was man hier abfragen und kontrollieren will ist "geschmackssache" und von der Installation abhängig. Aber am Ende des Tages ist es nur Das, was ein "Smart-Room-Climate" ausmacht. Dies überwacht dann, dass bei geöffnetem Fenster nicht geheizt wird, zumindest nicht "lange". Dass alle RTs "ge-team-ed" sind , dass die Fensterkontakte gekopplet sind und der RT/TC korrekt reagiert. Hier beginnt dann Smart. Ich stelle dann nur noch, oder sehe "Klima-Abend", "Klima-Parts" und erhalte "alarm-Fenster offen, heizt aber"

Im Gegensatz sind die Umfassenden, flachen Überwachungen einfach: Sind alle Fenster zu? Sind alle Lichter aus?

Somit mein Resümee: CUL_HM ist "Fertig". Alles (das Meiste, ok) , was dieser Level der Programmierung bieten sollte ist  vorhanden. Der Rest sollte in Überliegenden Modulen bereitgestellt werden.