CCU2 neben FHEM

[lukasbastelpeter]

Hi,

ich würde gerne(aus Performance,Stabilitätsgründen, und Zuverlässigkeit) meine Homematickomponenten, sowie die "kleinere" Logik in eine CCU2 stecken, parallel dazu soll FHEM laufen, für IT, Diagramme, Push, Email usw...
Bis jetzt läuft FHEM auf nem BananaPi, dadran HMLan, CUL868 und CUL433, das ist alles so komplex zusammengestrickt auf der "kleinen" Kiste... Hoffe ihr versteht was ich meine .

Das die Hardware der CCU nicht besser ist als die Banane denke ich mir schon, aber da ist alles "bis ins letzte Detail engeneered"?

Alternativ könnte ich FHEM auf einen uralten MacMini auslagern, die kosten mittlerweile auch nicht viel mehr als ne CCU2, aber Hardwaremäßig gibt das nicht mehr her als der BananaPi?! Ich hätte halt gerne eine "Out-Of-The-Box"Lösung mit FHEM-Schnittstelle, meint ihr das bekomme ich mit dem Grundgedanken hin?



Hat da jemand schon Erfahrung gemacht? Ratsam, eher nicht ratsam?

PS: Kann auch gerne verschoben werden, wusste nicht wo's hingehört.

[Otto123]

Hi,

wozu den HMLAN am BananaPi?

Du kannst FHEM natürlich parallel machen. Und für alles andere nutzen und Homematic auf der CCU2 machen. Du kannst auch über XMPLAPI Aufrufe beides "etwas" koppeln.

Gruß Otto

[Pfriemler]

Ich hole den Fred mal hoch, weil ich nichts vergleichbares finde. Jetzt, wo der Bausatz nur noch 70 Euro kostet, überlege ich in der Tat ebenfalls, einen Teil meiner Steuerungen auf ne CCU2 auszulagern, eben weil sich manches irgendwie doch logischer zusammenklicken lässt.

Praktische Erfahrungen gibt es hier aber keine, oder?

[Ralli]

http://forum.fhem.de/index.php?topic=40189.0

[Pfriemler]

Ja, ich meinte doch sowas gelesen zu haben. Blöde Forumsuche.
Danke!

[martinp876]

Mit klicken wird es schwer. Welche Dinge gehen einfacher mit der ccu2?
Parallelbetrieb "geht" sicher, aber mit den acks wird es .... Unpräzise. Auch ist mir unklar welchen Stand ccu2 annimmt, wenn man ein Register ober einen peer über fhem aendert. Zieht die ccu das nach? Fhem liest mit, ein automatisches getcfg kommt nicht. Für mich gibt es nur eine zentrale, damit scheidet die ccu ausser für Experimente, aus.
Ich denke templates aus hminfo sollten den level der ccu2 in etwa nachstellen. Da kann man entsprechende "vorlagen" erstellen und anwenden. Ein paar gibt es schon, versierte user können weitere erstellen und veröffentlichen. Ich hatte mir vorgestellt, dass hier eine Art library entsteht. Einfache user müssen dann keine Register mehr verstehen. Scheint keinen Anklang zu finden.

[Otto123]

Jetzt, wo der Bausatz nur noch 70 Euro kostet, überlege ich in der Tat ebenfalls, einen Teil meiner Steuerungen auf ne CCU2 auszulagern, eben weil sich manches irgendwie doch logischer zusammenklicken lässt.

Willst Du meine CCU1 mit verbesserter Antenne "geschenkt" haben?
Also ich trauere der Klick Oberfläche von Homematic nicht im Ansatz nach. Und logischer? Naja ist sicher Ansichtssache.

Gruß Otto

[zap]

M.E. Kann man CCU und FHEM durchaus parallel betreiben. Man muss aber die Geräte klar zuordnen, d.h. Nicht versuchen, einen Aktor über beides zu steuern.

Ich mache alle nativen Homematic Sachen über die CCU. Die exotischen Dinge sind über FHEM integriert. Mein Modul HMCCU erledigt die Kommunikation zwischen beiden Welten (Richtung FHEM -> CCU). Z.B. beliefert FHEM die CCU mit Infos aus meiner Wetterstation. Dann kann die CCU reagieren wenn es regnet und die Dachfenster sind offen.
Analog dazu die Anwesenheitserkennung. Presence Modul stellt fest, ob iPhone in der Nähe und setzt eine Variable in der CCU.

Aber auch der umgekehrte Weg geht: Die CCU kann z.B. Per Socket Kommunikation Befehle an FHEM schicken.

Alles in allem finde ich die Performance der CCU besser (Native C Programme vs. Perl Interpreter). Gerade bei vielen Geräten lahmt FHEM deutlich (ich hatte damit mal einen ziemlichen FS20 Zoo am laufen).

Deshalb: Best of both worlds.

P.S. Mit der Freigabe des CCU Codes durch EQ3 dürfte die CCU Software bald auf vielen der üblichen Verdächtigen Plattformen wie Raspi laufen. Dann werden auch andere Protokolle wie Zwave oder Zigbee nicht lange auf sich warten lassen. Immer vorausgesetzt es finden sich genügend Entwickler.

PPS ich suche noch nach einer geeigneten gemeinsamen Oberfläche für die Anzeige von Statusinfos auf einem Tablet. Hier hat FHEM die Nase etwas vorn, wenn auch viele gute Ansätze wie z.B. Infopanel nach gutem Start irgendwie auf halber Strecke liegen geblieben sind.

[Pfriemler]

Jaja ...
@Otto123: Nein, die CCU will ich nicht. Nur ne CCU2.
Es ist wirklich schwer zu vergleichen, der Ansatz ist einfach anders. FHEM stellt die HM-Geräte sehr gut dar mit all ihren Feinheiten, die Oberfläche ist gerade bei Automatisierung und Verknüpfung fein, gerade das "Probably associated with" hat mir schon öfter den A... gerettet.
Trotzdem kenne ich auch einfache Konfigurationserfahrung mit dem Konfigurator und dem USB-Stick. Wie simpel auch das läuft, hat mich schon ein wenig beeindruckt.
@Martin: Die Templates sind eine tolle Sache, gar keine Frage, aber ich persönlich habe noch nie eins benutzt, weil ich auch mit den Registern recht gut klar komme. Aber bei den etwas komplizierteren Sachen wie dem logischen Verknüpfen von Helligkeit und Bewegung auf Aktoren kriege ich mit FHEM irgendwie noch keinen Zugang. Trotz aller Dokus. Darf man auch auf meine Blödheit schieben.
Letztlich stelle ich mir auch nur vor, den HM-Kram so autark wie möglich laufen zu lassen, d.h. auch auf der Zentrale nicht tausende Programme zu nutzen, aber die Konfiguration der Geräte nicht mehr über FHEM, sondern nur noch über die CCU2 zu machen. Und was sich nicht direkt konfigurieren lässt, dann über ein Zentralenprogramm.

ACKs stelle ich mir wenig problematisch vor - die HMs melden an die CCU2, FHEM liest nur mit, die Kopplung mit virtuellen Buttons oder dem HMLAN wird aufgehoben. Ich denke, der Status wird mir in FHEM reichen. Warum soll ein getConfig aber ggf. nicht funktionieren?
Der Aktor/Sender müsste doch gar nicht unterscheiden können, von wem die Anforderung kommt.

Wirklich kritisch stelle ich mir nur den Umgang mit allen SEC-Geräten vor, da sehe ich noch kein Land.

[martinp876]

Wenn man die config sauber trennt und weiss, welche Daten man wo verwaltet kommt man sicher im Mischbetrieb zurecht.
Die acks sendet ein hmlan automatisch. Du müsstest die ID des device aus den hmlan fernhalten. Sehen kannst eines nicht, es passiert trotzdem.  Kein Genickbruch, unsauber.
Fhem ist in der tat langsam und für Echtzeitbetriebssystem nicht gemacht. Rudi will daran auch nichts aendern. Insbesondere Bei grossen Installationen oder langsamen Plattformen ein Problem, für die Verhältnisse erstaunlich gut.

Eine ccu könnte also unterschiedliche Anforderungen unterstützen:
Konfiguration: keine Echtzeit, nur Komfort. Kann man in fhem nachbauen, nicht klicken aber entsprechende higlevel Kommandos. Wenn ich die Problematik sehe kann ich mir gedanken machen. Kannst du hierzu dein Problem beschreiben? Was genau ist schwer zu erstellen?

Echtzeit: meine entities arbeiten unter einander. Komplexe Aktionen könnte man auslagern, aber dann hat man 2 ebenen, einmal ccu und nachgelagerten fhem. Moeglich, aber unschön... Nicht für mich.
Die ccu als io nutzen mit besseren Echtzeit Eigenschaften. Die ccu ist nicht transparent genug für meinen Geschmack.

Mit hmip könnte eine ccu2 wieder wertvoll werden. Da ich davon ausgehe, dass das Protokoll nicht offengelegt wird (ist ja das aktuelle nicht einmal) und es durch das verschlüsseln schwer wird benötigt man wohl eine ccu als io. Sollte IP also über die ccu steuerbar sein werde ich mir so ein device zum testen anschaffen.

Wie man sieht gibt es nicht nur einen weg.

[Pfriemler]

M.W. sendet ein HMLAN nicht automatisch ACKs, z.B. definitiv nicht bei mehrkanaligen Fernbedienungen - hier bedarf es ja gerade virtueller "Buttons" um die LED grün zu sehen. Bei einkanaligen Devices wie Fenstersensoren gibts das ACK allerdings automatisch, das wird sicher spannend ...
FHEM läuft inzwischen auf Cubietrucks und Raspbi 2 adäquat schnell, oder? Ich kann mich jedenfalls nicht beschweren.  Spannend wird das eher bei solchen Geräten wie dem Display-Wandtaster.

FHEM bietet in vielen Punkten bereits Klickkomfort - attr ... disabled 1 etwa bekommt man gänzlich ohne Tastatur hin. Regexe bei Notifys oder FileLogs gehen ebenso komfortabel. Beim Setzen von Registern in HM ist nach Regset aber wieder der Kopfcache oder ein zweites Fenster mit der regList gefragt. Wo war die 0, kommt erst dual oder erst der peer usw ...
Spätestens wenn es an Halbautomatiken per Verknüpfung mit virtuellen Kanälen der HM-Devices geht, kommt man ohne Templates schnell in die Hexenküche.
Ich würde aber mal sagen, dass ich das mal an einem konkreten Beispiel erläutere, z.B. wenn ich mich endlich um das Dimmen meiner Wohnzimmerdeckenbeleuchtung in Abhängigkeit von generellem Schaltzustand, Helligkeit und Bewegung im Raum kümmern kann.

HM IP über die CCU2? Das wäre mir aber neu bzw. angenehm ...

geht nich Gips nich ...

[mgernoth]

Hallo,

ich hatte kurz mal eine CCU2 neben Fhem betrieben, habe es aber u.a. wegen der ACK-Problematik aufgegeben. Solche Dinge wie getConfig liefen z.B. nicht immer sauber durch. Und AES führt zu totalem Chaos.

Jetzt fahre ich die CCU2 (wieder mit ihrer eigenen HMID) nur hoch, wenn ich Dinge ausprobieren möchte.

So überzeugt hat mich auch die Oberfläche der CCU2 nicht und die Logikschicht dahinter (RegaHSS, zugekauft, nicht von eQ-3 entwickelt) ist wohl nicht unbedingt stabil (hatte damit selbst keine Probleme, allerdings auch nicht wirklich viele Programme zusammengeklickt).
Allerdings gibt es schon tolle Beschreibungen zu Problemen:
http://homematic-forum.de/forum/viewtopic.php?p=219803#p219803
http://homematic-forum.de/forum/viewtopic.php?f=34&t=20563
http://homematic-forum.de/forum/viewtopic.php?f=34&t=25310
http://homematic-forum.de/forum/viewtopic.php?f=34&t=24543

Da ist Fhem jetzt nicht wirklich frickeliger dagegen, das kann man wenigstens debuggen wenn was schiefgeht

M.W. sendet ein HMLAN nicht automatisch ACKs, z.B. definitiv nicht bei mehrkanaligen Fernbedienungen - hier bedarf es ja gerade virtueller "Buttons" um die LED grün zu sehen.

Doch, ein HMLAN sendet automatische ACKs an alle ihm bekannten Geräte, wenn er eine an seine HMID gerichtete Nachricht mit gesetztem BIDI-Flag empfängt. Fhem überträgt beim Start die Liste der bekannten Geräte an das präferierte IO-Device.

Fernbedienungen senden im ungepeerten Modus aber an Broadcast (000000) ohne BIDI.

Viele Grüße
  Michael

[Pfriemler]

Das ist auch mal interessant, danke. Mal sehen, wie ich dann darüber denke in sechs Monaten...

[Otto123]

Ich habe keine Erfahrung mit der CCU2, ich hatte auf der CCU1 ganz wenige Programme laufen. Das "Schreiben" bzw. editieren fand ich gruselig. Und alle paar Wochen tat die CCU zwar ihren Dienst aber die Oberfläche reagierte in Teilen nicht mehr, obwohl ich nicht dran war -> minutenlanger Neustart.
FHEM läuft absolut stabil wenn ich nichts dran mache.

Ich hatte ne Weile Mischbetrieb und war sehr froh wo ich alles umgestellt hatte.

Gruß Otto

[frank]

und immer im auge behalten:
angriffe auf homematic sind im mischbetrieb dann nicht mehr erkennbar. bzw melden die devices dann permanent angriffe.