CCU2 neben FHEM

[Pfriemler]

Mal ein kleines Update:
Vorweg: Der Parallelbetrieb von CCU2 und FHEM funktioniert erst einmal ziemlich super. Ich habe allerdings noch keine Kopplung per HMRPC oder HMCCU eingebaut, sondern in einer Testphase lediglich die Außenhautkontkakte des Hauses und ein paar wenige derzeit entbehrliche Aktoren dort gekoppelt. Die ID der CCU2 unterscheidet sich von der von FHEM. Ich habe keinerlei Probleme mit ATTACKs, außer ich greife mit dem Konfigurationsstick (und der ID von FHEM) auf Komponenten zu - aber dann ist das ja völlig normal.
Alle umgelernten Devices wurden von FHEM sauber gesnifft und ich hatte - bis auf die fehlende Steuermöglichkeit - keinerlei Probleme, deren Status zu verfolgen und auszuwerten.
Allerdings ist es extrem unpraktisch, zwischen den beiden Familien Direktverknüpfungen herzustellen, und das kommt hier öfter vor als gedacht. (Generell setze ich sehr viel auf Direktverknüpfungen.) Ich bin die temporäre Umlernerei jetzt leid. Zudem habe ich inzwischen festgestellt, dass die vermisste Zusammenklickerei genauso gut mit dem Konfigurationstool funktioniert und FHEM nach einem getConfig die (peer-)Daten ebenfalls zur Verfügung stehen. Umgekehrt ist das leider nicht möglich. Zudem ist die Konfigurierbarkeit über die CCU2-Oberfläche bei näherer Betrachtung auch außerordentlich ... beschränkt. Zudem habe ich einige Vorhaben, für die eine CCU2 bzw. eine zweite hochstabile Steuerumgebung hilfreich gewesen wäre (wie etwa eine Alarmanlage) wieder verworfen. Und das Peeren virtueller Kanäle bekomme ich sogar mit FHEM inzwischen hin, wenn auch mit mehreren Anläufen ... Die Performance meines Raspi 2B reicht mir auch völlig.

Das nette Experiment ist daher beendet und die Sensoren ziehen wieder zu FHEM zurück...

Nach wie vor vermisse ich aber eine komfortable Peermöglichkeit mit der FHEM-Oberfläche. Das können CCU2 und das Konfigtool wirklich (noch) deutlich besser.

[martinp876]

Die Beschreibung bestätigt meine Erwartungen eigentlich komplett. Da ich durchaus betriebsblind sein koennte ist dies eine nette Bestätigung.
In der Tat bin ich der Meinung, dass fhem deutliche Vorteile in der konfigurierbarkeit gegenüber ccu bietet. Die ccu setzt auf fertige scenarien und Ideen wobei, zur besseren Handhabung für einfach User , einige Zugriffe auf Funktionen auf der Strecke bleiben (sollen?)
Auch kann die ccu nicht mit multimaster Betrieb umgehen. Ich kann den zustand (Register,...) eines device nicht explizit auslesen..... Das nervt zumindest mich. Wenn ein 2. Master (fhem) ein device verändert bleibt die ccu auf der Strecke.
In Sachen performance ist fhem sicher schlechter und bei Einbau unterschiedlicher Module sicher fragil. Perl ist nicht wirklich ein Echtzeit system, fhem ist definitiv nicht Echtzeit geeignet. Dank guter performance aktueller Prozessoren klappt es dann doch sehr gut.

Was ich verbessern will ist die einfachere Einrichtung von Standardfunktionen. Das angesprochene peeren vorneweg:
Man peert mit einem Kommando. Was ist daran kompliziert, was kann man verbessern?

Das zweite "Feld" sind Funktionen. Beispiel Treppenhauschaltung. Eine ccu bietet dies an. Fhem eigentlich auch. Nur habe ich das Gefühl es wird nicht ausreichend wahrgenommen. Die Methode heißt template. Da ich nicht vor habe mir alle möglichen Anwendungen auszudenken ist der Ansatz, templates selbst zu programmieren. Diese kann man zu Verfügung stellen.
Den Treppenhauschaltung gibt es als Standard. Heisst autooff. Der User kann einstellen, dass ein aktor bei trigger des Sensors nach x sec ausgeht. Autooff 10: nach 10 sec Licht aus. Weiter reduzieren kann ich es nicht. Der User muss vorgeben welcher aktor Kanal, welcher Sensor, long oder short und welches Template also welche Aktion. Die Parameter sind template abhängig von keine bis zu 10.
Jetzt müssen nur noch templates generiert werden.

Nebenbei sind templates extrem sinnvoll zur Überwachung und Wiederherstellung einer Anlage.

Anregungen? Wie kann man es verbessern? Anfänger ergehen sich oft in Details. Sie sollten mit templates beginnen!

[zap]

Ich stand vor einem Jahr vor der Frage, ob ich von der CCU auf FHEM umsteigen soll. Letztendlich habe ich mich für den Parallelbetrieb entschieden. Hauptgründe waren:

- wenn neue Homematic Geräte auf den Markt kommen, werden die von der CCu sofort unterstützt. Bei FHEM muss ich auf die Implementierung und im Anschluss auf die Beseitigung der Kinderkrankheiten warten.
- das Unterforum hier und die vielen Fragen, Probleme und Unwägbarkeiten bei der Anbindung von Geräten via CUL_HM und HMLan. Bitte nicht falsch verstehen: Du machst einen tollen Job und der Support ist vorbildlich. Aber bei der CCU hatte ich noch nie Probleme mit Peering, Pairing oder Steuerung. Das funktioniert einfach. Ich habe einfach nicht den Nerv, tagelang rumzubasteln, bis etwas funktioniert. Aber das isr meine persönliche Meinung. Basteln kann ja auch ein Hobby sein und viel Spaß machen.

Für mich ist Smarthome teil des häuslichen Lebens. Das muss einfach funktionieren und auch von nicht IT Experten bedienbar sein. Sonst sinkt der WAF ins Bodenlose und dafür ist der Kram einfach zu teuer.

[Otto123]

Martin, ich glaube ein Hauptproblem für den Anfänger ist: FHEM ist quasi erstmal "leer", da springt einen nichts an, da finde ich nichts durch suchen in der Oberfläche.
Da brauch ich den Tipp, dass die Treppenhausschaltung autooff heisst. 
Da brauche ich den Tipp, dass ich einen Taster mit einer Lampe über notify verbinden muss/kann (Wenn nicht beides HM ist).
Das ist auch schwierig mit Handbüchern und Dokumentationen rüberzubringen, da wollen heute alle einen Wizard haben.

Konkret zum peeren, da würde so ein kleiner Wizard ähnlich RegExp wahrscheinlich der Knaller sein! Zumindest für die einfachen Aufgaben wie das die CCU auch bereithält. Also einfach zweiten Channel auswählen noch ein Haken für dual oder single, both als standard.

Wenn ich mir gerade die aktuelle commandref ansehe merke ich, Du hast peerchan vereinfacht?
Das ist auch so was, die Anfänger plagen sich meist mit Beschreibungen aus dem Internet von 2013 - wo doch mittlerweile soviel in FHEM passiert ist und vieles viel einfacher und "einfach so" geht. Ich habe mich letztens auch gemüht als ich für einen Kumpel einen CUL Stick flashen sollte, man findet als erstes nur alte und komplizierte Beschreibungen.

Aber ich finde auch nicht, dass es der Ansatz von FHEM ist die CCU zu ersetzen. Es ist gut, dass es beides gibt. Und das nicht beide denselben Lösungweg beschreiten.

Schönen Sonntag
Otto

[martinp876]

Ein Wizard wäre cool. Leider gibt es in fhem nur einen level dropdown. Wenn ein Kommando mehr als einen Parameter hat ist Schluss.
Ein Wizard mit mehrstufigen Pulldown wäre cool. Noch besser context sensitiv. Hat man die erste Auswahl getroffen wird die Liste des 2. angepasst. Ein Wizzard eben.
Ich habe kein Gefühl wie viele sich 2 Systeme antun , fhem und cul. Komfortabel ist das m.e. nicht.
Scheinbar ist ein sinnvoller level der Zufriedenheit erreicht.
Um mich zu wiederholen: templates haben einen Namen. Die Library und die Beschreibung wäre in wiki cool. Der User sucht was er braucht, here you go.
Übrigens gibt es eine ganze Reihe built-in docu. Templatelist hat auch zu autooff einen Satz Beschreibung. Da muß man nicht deuten oder bleattern.

[Pfriemler]

So sind die Unterschiede: zap möchte möglichst sofortige Unterstützung von neuen Homematic-Geräten. Da halte ich die CCU ganz ebenso für noch unverzichtbar. Ich bin eben der Mensch, der für sein bisschen Hausautomatisation nicht gleich zwei System lernen möchte - sagen wir mal ich bin so faul und warte bis die Unterstützung durch FHEM da ist, bevor ich mir das Gerät dann auch kaufe ...  Wie kompliziert und langwierig das werden kann und wieviel Hirnschmalz da bewegt werden muss, zeigt sich für mich an dem 55er Wandtaster mit dem OLED-Display. Wer den konfigurieren möchte, macht das einfach in der CCU - oder er muss erst die Dutzenden Seiten des zugehörigen Threads in FHEM durchlesen ... für mich ist das Ding deswegen schlicht uninteressant, obgleich ich immense Arbeit dafür wirklich sehr bewundere - ich bin wohl zu doof dafür.

Was mich genauso wie Martin nervt ist, dass die CCU2 keinen Status von Geräten nachlesen kann. Das ist schlicht DER Mangel. Dass die CCU2 kein unpair kennt und man Geräte zum (temporären) Umpairen löschen und hinterher neu anlegen muss, auch. Sieht das Konzept einfach nicht vor, ok, war aber für mich unpraktikabel.

Wer mit FHEM anfängt, MUSS das Einsteigerdoc lesen, wer mit HomeMatic anfängt, MUSS den Anhang von Martin lesen. Damit habe ich gar keine Probleme. Das sollte man auch jedem FHEM-Novizen abverlangen.
Die Funktionen, die inzwischen in FHEM als Unterstützung eingebaut sind, sind über viele Zweifel erhaben, gerade die Templates sind durchaus ein Segen - wenn man erst mal begriffen hat, wie die Dinger zu verwenden sind, dann ist alles sehr einfach. All diese Dinge wie Registersets lesen, prüfen, sichern, auf andere Geräte übertragen fehlen in der CCU2 komplett. Aber auch die wollen erst einmal bedient sein. Ich habe gestern die commandref zu CUL_HM zum x. Mal gelesen und verstehe langsam immer mehr, aber wo der Unterschied zwischen "configSave" und "saveConfig" ist, erschließt sich mir ohne weiteres Nachbohren auch nicht...
Otto hat das Peer-Problem genau auf den Punkt gebracht - Wenn also hinter dem Auswählen von peerChan Dropdowns auftauchen, die mögliche peer-Partner auflisten, dann "single - Einkanalbetrieb"/"dual - Tastenpaar" und schließlich "both - beide Partner einrichten"/"remote - Nur Sender"/"actor - Nur Empfänger", dann wäre die Reihenfolge endlich geklärt. Bliebe noch die 0 für die Auswahl des aktuellen Channels, der zu 99% vermutlich normale Fall - Peeren von Tastenpaaren mit der entsprechenden Auswahl ist ohnehin aus dem Device heraus sinnvoller als aus dem Channel (man muss ja schon den richtigen der beiden erwischen).
Wie eben schon angedeutet: Hilfreich wäre auch eine sprachliche Unterstützung für die weniger Englischaffinen - die Erklärtexte hinter den drögen Zahlen, die "autoReadReg" seit kurzem bietet, sind für mich der perfekte Weg dahin, ich hab's mal eben schon versucht anzudeuten.

Die CCU bietet von vornherein eigene Konfigurationsseiten für Direktverknüpfungen. hminfo könnte ähnliches bieten.
Das wäre sogar noch besser als aus den Kanälen heraus zu peeren.
In hminfoD gibt es ja bereits "set <hminfo> templateSet". Ein einfaches oder duales peeren ist letzlich auch mit einem template zu erschlagen (wenn es nicht längst eins gibt). Dann bliebe dort nur noch die Wahl der peer-Partner.
Eine Konfigurationsseite, in der man eine Direktverknüpfung nachträglich bearbeiten kann, gefiele mir aber noch besser.

Auch das Handeln von Temperaturlisten ist für mich noch alles andere als klar. Welche Datei und wo sollte man nehmen, was als Vorsteinstellung ... Plotdateien von Tabellen zu erstellen ist auch schön anschaulich - ein eigener Editor für Templates wäre hier ebenfalls besser. (Übrigens habe ich in der CCU2 dazu ja dermaßen von gar nichts ab Werk gefunden).

Viele Wünsche. Realisierungszeitraum vermutlich eher Jahre, Hauptsache überhaupt. Mithilfe?

[Pfriemler]

Leider gibt es in fhem nur einen level dropdown. Wenn ein Kommando mehr als einen Parameter hat ist Schluss.
Ein Wizard mit mehrstufigen Pulldown wäre cool. Noch besser context sensitiv. Hat man die erste Auswahl getroffen wird die Liste des 2. angepasst. Ein Wizzard eben.

Aber mehrere Dropdowns auf einmal anzubieten geht doch schon? Also könnte man nicht beim Auswählen von "peerChan" bereits mehrere Dropdowns (0... für den channel, alle peerpartner, single/dual, both/remote/actor) in der richtigen Reihenfolge anbieten, der User sucht die passenden aus und der Button "set" sammelt sie am Stück auf?

Ich habe kein Gefühl wie viele sich 2 Systeme antun , fhem und cul. Komfortabel ist das m.e. nicht.

Du meinst sicher CCU. Werden sicher nicht viele sein. Komfortabel ist das auch aus meiner Sicht nicht, aber für manches der bessere Weg. Wie zap sagt: Neue Geräte sofort in der CCU, per HMCCU Modul einfach gleich auf hohem Niveau "anzapfen". Prinzipiell ist EINE Zentrale natürlich besser.

Scheinbar ist ein sinnvoller level der Zufriedenheit erreicht.

Sehe ich anders  ... Die Frage ist eher, wo Aufwand und Nutzen gegeneinander liegen.

Um mich zu wiederholen: templates haben einen Namen. Die Library und die Beschreibung wäre in wiki cool. Der User sucht was er braucht, here you go.

Und last but not least: Templates definieren übergeordnet Beziehungen zwischen Geräten und können die richtige Programmierung dieser durchführen, prüfen und wiederherstellen. So weit so praktisch. Für eine anderweitig erstellte und/oder nach FHEM "mitgebrachte" oder nachträglich feingetunte Direktverknüpfung fehlt dann aber jegliche "Rückübersetzungshilfe". Das kann sogar der Konfigurationsadapter mit Software, wenn man die Geräte einmal angelernt hat.
peerXRef listet zwar die Beziehungen, aber es fehlen alle Feineinstellungen. Ändern geht nur auf regSet-Level. Oder man bügelt eigene oder vorhandene Templates drüber.

[zap]

@Pfriemler: Ich gebe Dir in vielen Punkten Recht. Allerdings musst Du unterscheiden zwischen Dingen, die in der CCU WebGUI nicht gehen und solchen, die auch auf API- bzw. Homematic Script Ebene nicht gehen.

Unterhalb des WebUI kann man sehr wohl Geräte aktiv anfragen, Links löschen, jeden verfügbaren Parameter einer Komponente ansprechen, usw.

EQ-3 hat bestimmte Funktionen für den "Normal-Benutzer" nicht per Web-Interface bereitgestellt. Wahrscheinlich vermissen sie die meisten auch nicht.

BTW: Die CCU fragt natürlich regelmäßig die Komponenten ab. Zwischen diesen Intervallen kann es durchaus sein, dass der Status im WebUI nicht korrekt ist. Auf Script Ebene sieht das aber anders aus (im Übrigen auch aus dem WebUI heraus nutzbar): Hier kann man entscheiden, ob man den CCU Wert verwenden (Value) oder das jeweilige Gerät abfragt (State). Diese Wahl hat man in HMCCU auch. Das eine geht schneller, das andere ist verlässlicher.

[martinp876]

die ccu fragt den Status der Devices ab (regelmäßig? keine Ahnung) aber nicht die Config. Das kann ich nicht steuern.

Ganz klar: wer 2 Systeme betreiben will (FHEM und CCU) dem sei das umbenommen. Jedenfalls ist das nicht im Focus von FHEM dies zu unterstützen.

Dass Devices nicht unterstützt werden, schon aber in der CCU... sehe ich so nicht. wenn eq3 die neue FW für die CCU ausgibt wird die in FHEM eingebaut. eq3 ist gut beraten die FW deutlich vor der Markteinführung eines Device zu veröffentlichen. FHEM kann somit mithalten. Manchmal sehe ich es nicht, dann sind wir zu spät.
Probleme gibt es natürlich bei neuen Typen - wenn man noch nicht weiss, wie das Device funktioniert. Und wenn eQ3 das nicht (wirklich) im xml hinterlegt.

Interessant finde ich multi-drop-downs. Die habe ich in FHEM noch nicht gesehen. Wo ist ein Beispiel? dann werde ich sicher etwas implementieren.

An einfacherer Bedienbarkeit für "simple-user" bin ich interessisert.

[joshi04]

Interessant finde ich multi-drop-downs. Die habe ich in FHEM noch nicht gesehen. Wo ist ein Beispiel? dann werde ich sicher etwas implementieren.

Ich versuche gerade weekprofile mit meinen Homematic-Komponenten zum Laufen zu bekommen... Im Modul unter der Verwendung von Topics gibt es im Widget ein doppeltes Dropdown-Feld, bei dem der Inhalt des 2. vom gewählten des ersten abhängig ist.
Außerdem, ohne Verwendung von Topics kann ich ein Profil per Dropdown auswählen und dann für das Übertragen an einen Thermostaten bekomme ich eine Liste an kompatiblen Thermostaten angezeigt.
Meinst Du so etwas als Beispiel und ließe sich daraus ggf. etwas übertragen?

[martinp876]

Ein eigenes Widget geht natürlich. Das ist aber kein Standard Web Interface in fhem.
Mal sehen, wie man fhemweb erweitern kann.