Neues Board für HMCCU

[1.fhemtester]

Auf Grund der stark abweichenden Implementierung von HMCCU und der FHEM Philosophie verglichen mit CUL_HM, votiere ich für eine eigenes Board.

Hier ein kurzer Rückblick zu FHEM aus Sicht eines FHEM Users der ersten Stunde zum Verständnis.

Begonnen hat alles mit der FHZ, FS20, HMS und WS300 von ELV. Die dazugehörigen Module 00_FHZ, 10_FS20, 12_HMS und 13_WS300 sind auch heute noch Teil von FHEM.
FHZ ist dabei das pysikalische Sende/Empfangsgeräte, FS20, HMS und WS300 die unterstützten Protokolle.
2008 gabe es die erste Altenative zur FHZ, die CUL entwickelt von Dirk Tostmann (https://busware.de/tiki-index.php). Das dazugehörige FHEM Modul ist 00_CUL.
CUL unterstützt neben FS20, HMS und WS300 eine Reihe von weitern Protokollen wobei die bestehenden Module 10_FS20, 12_HMS und 13_WS300 wiederverwendet werden.

Im Laufe der Zeit kamen viele weitere pysikalische Geräte und Protokolle dazu. Die meisten Modulauthoren haben die Logik und das Bezeichnungsschema übernommen.

Umgelegt auf HMIP bedeute das, es sollte ein 00_HMCCU Modul geben, dass die Kommunikation mit der CCU macht und die Daten so bereit stellt, dass das Modul 10_CUL_HM diese für das HM Protokoll verarbeiten kann.
Für HM_IP könnte es ein 10_HMCCU_HMIP geben oder aber 10_CUL_HM ergänzt werden.

HMCCU folgt der Idee der Wiederverwendung von Modulen jedoch nicht.

Aus Endusersicht und erst recht für einen Newcomer ist es schwierig, wenn unterschiedliche Implementierungen in einen Board behandelt werden.

Aus meiner Sicht sollte daher das Homematic Board auf die Implementierung von CUL_HM beschränkt bleiben. Zumindest so lange es kein kompatibles 00_HMCCU Modul gibt.

[martinp876]

 

[zap]

Warum sollte ich auf eine antiquierte Architektur aufbauen? Die HMCCU Module orientieren sich an der CCU Architektur. Die CUL Module implementieren selbst das Protokoll und steuern die Geräte an. Das ist ein komplett anderer Ansatz und führt in eine Sackgasse, sobald sich das Protokoll ändert oder ein neues, nicht reverse engineer-bares hinzukommt. Siehe HmIP.

Warum FHEM für die Homematic Integration nicht von Anfang an die vorhandenen und dokumentierten Homematic Schnittstellen verwendet hat, ist mir ein Rätsel. Aber ist halt so historisch gewachsen. Da jetzt noch hmip irgendwie dranzubasteln, um es mit den CUL Modulen irgendwie zum Laufen zu bekommen? Da bekomme ich als Informatiker und Software-Entwickler Hautausschlag und Schnappatmung

Ich wäre auch für eine Trennung von HMCCU und CULHM im Forum. Bisherige Vorstöße anderer Nutzer in diese Richtung sind jedoch verhallt.

Die Architektur von HMCCU orientiert sich an der FHEM Logik von IO und Client Devices:

- HMCCU bildet das IO Device und damit die CCU ab
- Die einzelnen Schnittstellen der CCU bzw Protokolle (BidCos-RF + Wired, CUxD, HmIP-RF + Wired usw) werden mit HMCCURPCPROC Client Devices abgebildet. Über diese Devices kommuniziert das IO Device mit der CCU.
- HMCCUCHN (Client Device) schließlich bildet die Kanäle der Geräte ab.
- HMCCUDEV (Client Device) bildet Geräte ab, die über mehrere Kanäle gesteuert werden (Sonderfall, v.a. für HMip Wired Schaltaktoren, die bis zu 4 Kanäle je angebundenes Gerät verwenden)

Bitte lies mal die XML RPC Doku der CCU. Dann wird vielleicht klarer, weshalb das mit dem Dranbasteln der CCU an die CUL Module nicht sinnvoll ist.

[1.fhemtester]

Sorry, kam wohl nicht klar genug raus: Als Enduser möchte ich HM und HMIP möglichst als Blackbox sehen und die Geräte gleichartig einfach bedienen und den Status bekommen können.
Die XML RPC Doku der CCU ist für Entwickler nicht für Enduser.

Das die existierende CUL_HM Lösung eine Sackgasse ist bezweifle ich. Jedenfalls brauche ich da keine Tricks wie Userreadings und Attribute für Grundfunktionalitäten.
Der SW Reifegrad und die Benutzbarkeit für Enduser ist aktuell höher.

Für mich wird da gerade das Rad neu erfunden.

Das SIGNALduino Projekt zeigt eindrucksvoll wie es richtig geht.
00_SIGNALduino ist pysikalische Gerät und 14_SD_xx die jeweils neuen Protokolle bzw. werden mit 14_CUL_TX und 14_CUL_WS bereits bekannte Protokolle unterstützt.
Nahezu alle Temperatursensoren, unabhängig welches Funkprotokoll bzw. über welches pysikalische Geräte empfangen wird, haben
einen state der Form T: 16.3 H: 69 und ein temperature 16.3 und (wenn vorhanden) humidity 69 Reading.

Aus Endusersicht ideal, falls beispielsweise ein Temperatursensor getauscht werden muß, kann ich Grafiken, notifys ect. weiterverwenden.

HMIP Geräte haben oft nahezu die selben Eigenschaften wie die korrespondierenden HM Geräte. Dazu kommen noch die nachgebauten HM Geräte aus dem AskSin++ Projekt ( https://asksinpp.de/ ).
Viele askSin++ Geräte haben eine CCU Integration über ein Addon (https://github.com/jp112sdl/JP-HB-Devices-addon).

Hier bespielhaft was es für Kontaktschnittstellen Tür/Fenster (TFK) im HM/HMIP gibt:

HM: HM-Sec-SC-2, HM-Sec-SCo, HM-Sec-RHS
HMIP: HMIP-SWDO, HmIP-SWDM, HmIP-SRH, HmIP-SCI
AskSin++: HM-SEC-SC_WDS, HM-Sec-RHS

Wir haben also 9 verschiedene Geräte (wenn man den Wassermelder für HM und HMIP dazuzählen 11), die 2 oder 3 Zustände melden.
Aus Endusersicht sollten funktionsgleiche Geräte in FHEM gleichartig benutzbar sein. Wie das genau implementiert wird, ist mir als Enduser eigentlich egal.
Ich möchte z.B. den HM Wassermelder direkt mit dem HMIP Wassermelder ersetzen können.

Daher hätt ich gerne für alle TFKs

State open/tilt/closed bzw. dry/damp/wet
und Readings für
contact open/tilt/closed, optional an wen die letzte Antwort gegangen ist also z.B. (to vccu)
cover open/closed

Aus FHEM Sicht, kann ja die HMCCU Lösung und 00_HMCCU / 10_HMCCU_HMIP parallel existieren.
Welche Lösung besser passt, sollte jeder User, auch abhängig vom individuellen Interesse/Wissenstand entscheiden können.
Letzlich ist das der Grund, warum ich unterschiedliche Boards befürworte.

Die Verdienste für FHEM von martinp876 und zap sind davon unbetroffen.

[isy]

Aus Sicht der Modul Entwicklung kann das Ansinnen unrealistisch sein, das kann ich nicht beurteilen.

Für mich  als Anwender wäre es eine deutliche Erleichterung, wenn sich HM-IP Geräte in FHEM so darstellen würden, wie HM-BidCos Geräte.

[MadMax-FHEM]

Für mich  als Anwender wäre es eine deutliche Erleichterung, wenn sich HM-IP Geräte in FHEM so darstellen würden, wie HM-BidCos Geräte.

Wenn du von Beginn an (bzw. eben "nur") HMCCU nutzen würdest wäre das ja so...

Ebenso weiä ich als (langjähriger) CUL_HM Nutzer was du meinst...
Bzw. "schreckt" mich auch das (total) andere "Verhalten" und Readings etc. (selbst) "spasseshalber" mal eine CCU aufzusetzen und "rumzuspielen"...
Geschweige denn umzusteigen.

Wenn ich neu beginnen würde und Homematic wollte, würde ich wohl mit HMCCU angefangen haben...

Aber Homematic IP ist (auch aus anderen Gründen) aktuell keine Alternative für Erweiterungen, da sehe ich mich aktuell.eher bei ZWave, EnOcean und Zigbee um...

Aber: wer weiß...

EDIT: ein getrenntes Board wäre aber wohl hilfreich. Außer die Fragenden merken (im Betreff) an, ob CUL_HM oder HMCCU. Hab oft schon gelesen und geantwortet, bis dann rauskam: HMCCU und da bin ich als Helfer halt (komplett) raus... Wobei viele (trotz Unterforum) ja einfach in Anfänger Fragen posten, dann hat sich das mit getrennten Boards auch schon wieder...

Gruß, Joachim

P.S.: was du bzgl. Entwicklersicht schreibst wird verm. so sein wie vermutet. Es sind halt total andere Ansätze:
- CUL_HM (ZWave, EnOcean, ...): Funkmodul wird von fhem "kontrolliert" und fhem "kümmert" sich um "alles"...

- HMCCU (Zigbee): eigentlich ist die CCU (oder das Zibee Gateway) "Herr" über die Geräte, fhem "nutzt" das "nur"... Und bildet vermutlich ab, was es "dort" gibt... (oder so)...

[1.fhemtester]

Rudolf König hat ein geniales Konzept aufgebaut, vieles ist hier möglich.

Technisch gesehen geht's um eine Kompatibilität der FHEM Kernfunktionalitäten

Internals
Readings
Attributes

zwischen CUL_HM und HMCCU.

Die ist aktuell bei HMCCU nicht gegeben, aber durchaus umsetzbar. Zusätzliche HMCCU Einträge sind da möglich.
Das hat gar nichts mit dem XML Protokoll oder einem direkten HW Zugriff zu tun.

Für mich ist HMCCU aktuell ein PoC. Der Nachweis, dass HMCCU mit FHEM spielt ist geführt.
Jetzt könnte eine Anforderungsphase starten, in der jeder interessierte Forumuser seine Ideen einbringen kann.
Danach käme dann ein Anforderungsdokument raus. Aufbauend darauf eine Übersicht, was schon geht, was angepasst werden muß und was neu entwickelt werden muß.
Idealerweise finden sich dann Forumuser die mithelfen wollen und Teilfunktionalitäten übernehmen bzw. diese testen wollen.
Eine Releaseplanung wäre der nächste Schritt.

Also ein vereinfachter Softwareentwicklungsprozess mit dem HMCCU Board als Kommunikationsmedium.
Ich würd es sehr begrüßen, wenn zap das HMCCU Board moderieren würde.

[zap]

Mit Hinweis auf die XML RPC Doku war nur als Fingerzeig gedacht, dass HMCCU ein völlig anderes Konzept als CUL_HM verfolgt (verfolgen muss):

- CULxx erledigt die Kommunikation mit den Geräten, bei HMCCU macht das die CCU
- HMCCU ist eigentlich kein IO sondern ein "O" Device (Output only), denn die andere Richtung übernimmt die CCU. Dadurch ist die Kommunikation asynchron und mit CUL überhaupt nicht vergleichbar
- HMCCU verfolgt einen generischen Ansatz, d.h. Spezialbehandlung für jeden Gerätetyp wie kn CUL_HM habe ich mir gespart. Das hat den großen Vorteil, dass neue Geräte direkt mit HMCCU verwendet werden können, ohne dass ich irgendetwas anpassen muss.

In einem Punkt hast Du recht: in HMCCU 4.3 wurden sehr viele Attribute verwendet. Mit der 4.4 Beta haben sich die Attribute fast auf 0 reduziert. Damit wird die Einstiegshürde für neue Nutzer viel niedriger.
Ein neuer Nutzer von Homematic wird sicherlich mit HmIP beginnen. Für Bidcos gibt es keine neuen Geräte mehr und das Protokoll ist unsicher und veraltet. Von daher wird ein neuer Nutzer mit HMCCU beginnen. Da diese Nutzer die alte Welt nicht kennen, wird ihnen das nicht schwerfallen.

Für Nutzer, die ihre BidCos Welt um HmIp erweitern wollen, gibt es 2 Möglichkeiten:
1. Sie betreiben CUL_HM und HMCCU parallel (eigentlich kein Problem)
2. Sie migrieren nach und nach ihre CUL in die HMCCU Welt

[Horti]

Als CUL_HM-Nutzer würde ich es auch begrüßen, wenn HMCCU sich "kompatibler" verhalten würde. Als Endnutzer interessieren mich diverse Feinheiten und Unterschiede nicht. Ich würde gerne die CCU, in welcher Gestalt auch immer, als IO-Device sehen und die Weboberfläche nur noch zum Anlernen der neuen Geräte nutzen oder noch nicht mal das, wenn sich auch das wegkapseln lässt. Ich will mir eigentlich auch keine Gedanken machen müssen, ob HMCCUDEV oder HMCCUCHN, sondern so, wie es im Moment CUL_HM macht, mit sinnvollen Annahmen für den User anlegen. Passen die Annahmen nicht, so kann man immer noch mit Dummy-/DoIf-Devices oder ReadingGroups das ganze an die eigenen Vorstellungen anpassen.

Auf der anderen Seite ist es natürlich zap's Entscheidung, wer es gerne anders haben will, darf selber Hand anlegen Ich kann's leider nicht, deswegen werde ich wohl noch eine Weile zweigleisig fahren, wobei aber fehlende Unterstützung vieler HB-Geräte in CUL_HM schon schmerzhaft ist.

Was die Aufteilung der Boards angeht: würde ich unabhängig von der weiteren Gestaltung von HMCCU machen. Wobei sich aber schon die Frage stellt, wo man die Grenze zieht: zw. BidCos und HmIP oder CUL_HM und HMCCU?

[1.fhemtester]

Ist schon klar dass HMCCU ein anderes Konzept verfolgt.

Was ich aber nicht fair finden, wenn martinp876 für seine Implementierung, noch dazu im von ihm betreuten Forum, zumindest indirekt kritisiert wird.
Er hat als Modulauthor und Forumsmoderator Hervorragendes geleistet.

In der Urzeit der FHEM Entwicklung, war nicht mal klar ob Sourcecode für den Zugriff auf ELV Geräte veröffentlicht werden kann, ohne dass die Modulauthoren mit rechtlichen Konsequenzen seitens ELV rechnen müssten.
"vorhandenen und dokumentierten Homematic Schnittstellen" gab es damals nicht.

Dass ELV heute von Partnerimplementierungen spricht, ist eine relativ neue Entwicklung.
Das heist aber nicht, dass Internals, Readings, Attributes nicht kompatibel sein sollten.

Viele Details sollten sich einfach umbauen lassen z.B.
Internals ccutype HmIP-SCI nach Attributes model HmIP-SCI

oder

Internals ccuaddr abcdefghijk:1 nach Attributes serialNr abcdefghijk:1

Ja, piVCCU ist ein interessanter Ansatz.
Ob 1. tatsächlich so problemlos ist, kann ja jeder Forumsteilnehmer selbst beurteilen ...

Neben der Implementierung entscheidet auch die Doku ob User zurecht kommen.
Wenn ich mir die Postings zu HMCCU so ansehen, ist die Welt der Datenpunkte nicht nur für mich eine Herausforderung.

Eine FHEM kompatible Internals-, Readings-, Attributesimplementierung würde das Leben erleichtern und auch den Supportaufwand reduzieren.

[Christoph Morrison]

Was die Aufteilung der Boards angeht: würde ich unabhängig von der weiteren Gestaltung von HMCCU machen. Wobei sich aber schon die Frage stellt, wo man die Grenze zieht: zw. BidCos und HmIP oder CUL_HM und HMCCU?

Bisher hat sich die Aufteilung anhand von Modulen doch auch bewährt, also könnte man das durchaus auch so weiter machen. Im Prinzip brauchen wir ja mind. 3 Bereiche:
- Nutzung von HM-Classic mit CUL_HM
- Nutzung von HM-Classic und Hm-IP mit HMCCU
- Homematic-Hardware, egal ob HB, Hm-IP oder HM-Classic (beide inkl. Wired)

Es ist aktuell ja so, dass der Homematic-Bereich mit Abstand die höchste Anzahl an Beiträgen im Forenbereich enthält, insofern kann man imho da durchaus auch mal eine Unterstruktur schaffen. Mich als HMCCU-User interessieren die ganzen CUL_HM-Sachen z.B. überhaupt nicht, genauso wenig wie mich HMCCU interessiert hat, als ich noch CUL_HM verwendete. Hardware etc. interessiert mich unabhängig vom Modul.

Das sehe ich übrigens völlig losgelöst von irgendwelchen Wünschen nach einer (zwanghaften) Kompatibilität zwischen CUL_HM und HMCCU oder Designentscheidungen bezüglich HMCCU, sondern lediglich am Volumen der Beiträge und der Verwirrung, die durch zwei Module und die Unfähigkeit, passende Markierungen im Titel zu wählen, entsteht. Das eine hat mit dem anderen nichts zu tun.

[justme1968]

was die trennung angeht: eine trennung von cul_hm und hmccu finde ich gut. ob man drei bereiche draus macht weiss ich nicht da man diskutieren kann ob das mit der hardware in der praxis dann wirklich sinnvoll ist. da wird vermutlich hardware öfter mal in einem der anderen beiden bereiche landen.

was das zumindest halbwegs unterstürzen von vorhanden fhem konventionen angeht: das sehe ich nicht als zwanghafte kompatibilität sondern eigentlich als grundlage um module in kombination wieder zu verwenden ohne groß nachdenken zu müssen. reading namen wie temperature, ... und gleiche wertebereich erleichtern allen das leben. alternative frontends sowie sprach ein und ausgabe sind nur dann automatisch möglich wenn man sich an standarts hält.es gibt absolut keinen grund sich auf dieser ebene unterscheiden zu wollen. anders ist nicht automatisch besser.

[Christoph Morrison]

es gibt absolut keinen grund sich auf dieser ebene unterscheiden zu wollen. anders ist nicht automatisch besser.

Ich finde, dass diese Diskussion in einer um Boards off topic ist (und die Ableitung im ersten Posting auch logisch nicht verfängt). Mein Vorschlag wäre deshalb, die Design-Entscheidungen was HMCCU angeht, erstmal außen vor zu lassen, auch weil sie deutlich kritischer ist als die um Boards. Diese Diskussion kann man dann ja im HMCCU-Board führen (oder auch nicht).

[zap]

Ist schon klar dass HMCCU ein anderes Konzept verfolgt.

Was ich aber nicht fair finden, wenn martinp876 für seine Implementierung, noch dazu im von ihm betreuten Forum, zumindest indirekt kritisiert wird.
Er hat als Modulauthor und Forumsmoderator Hervorragendes geleistet.

Es liegt mir fern, Martin (auf unfaire Weise) zu kritisieren. Von ihm habe ich viele Impulse und Ideen für HMCCU 4.4 bekommen. Es muss aber erlaubt sein, auch mal alte Dinge (wie auch immer die entstanden sind) anders zu machen, denn die Welt dreht sich weiter.

In der Urzeit der FHEM Entwicklung, war nicht mal klar ob Sourcecode für den Zugriff auf ELV Geräte veröffentlicht werden kann, ohne dass die Modulauthoren mit rechtlichen Konsequenzen seitens ELV rechnen müssten.
"vorhandenen und dokumentierten Homematic Schnittstellen" gab es damals nicht.
Dass ELV heute von Partnerimplementierungen spricht, ist eine relativ neue Entwicklung.

Keine Ahnung, was "Urzeit von FHEM" ist. "neue Entwicklung" ist relativ. Die Doku von EQ-3 gibt es (mindestens) seit 2008.

Das heist aber nicht, dass Internals, Readings, Attributes nicht kompatibel sein sollten.

Viele wichtige Readings (temperature, humidity, ...) sind inzwischen in HMCCU vorhanden. Zusätzliche Readings - sofern sinnvoll - sind eher kleine Baustellen.

Viele Details sollten sich einfach umbauen lassen z.B.
Internals ccutype HmIP-SCI nach Attributes model HmIP-SCI

oder

Internals ccuaddr abcdefghijk:1 nach Attributes serialNr abcdefghijk:1

Es ist eben keine Seriennummer sondern tatsächlich eine Adresse und wird auch in der CCU als ADDRESS geführt.

Ja, piVCCU ist ein interessanter Ansatz.
Ob 1. tatsächlich so problemlos ist, kann ja jeder Forumsteilnehmer selbst beurteilen ...

Den Schwenk zu piVCCU verstehe ich jetzt nicht. Was hat das mit HMCCU zu tun?

[1.fhemtester]

Zu piVCCU siehe mein Posting Erste erfolgreiche Tests mit piVCCU.

Ja, sehe ich auch so, HMCCU Designfragen sind hier offtopic.
Mein erstes Posting sollte nur darstellen warum ich für ein eigens HMCCU Board bin.

Tatsächlich ist die Größe des Homematic Board ein viel stärkeres Argument für einen Split.