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 :D.
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.
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
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?
http://forum.fhem.de/index.php?topic=40189.0
Ja, ich meinte doch sowas gelesen zu haben. Blöde Forumsuche.
Danke!
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.
Zitat von: Pfriemler am 13 September 2015, 23:35:31
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
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.
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.
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.
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 ...
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 :-)
Zitat von: Pfriemler am 15 September 2015, 14:22:19
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
Das ist auch mal interessant, danke. Mal sehen, wie ich dann darüber denke in sechs Monaten...
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
und immer im auge behalten:
angriffe auf homematic sind im mischbetrieb dann nicht mehr erkennbar. bzw melden die devices dann permanent angriffe.
Zitat von: Pfriemler am 15 September 2015, 14:22:19
HM IP über die CCU2? Das wäre mir aber neu bzw. angenehm ...
geht nich Gips nich ...
Soll in Q4/2015 kommen.
Hach. Wird kein Spaziergang. Dennoch: für meinen Anwendungsfall vielleicht machbar ... Zentrales Bedienpanel plane ich sowieso nicht, und letztlich sind ein Dutzend Werte von HM für FHEM intern relevant, die kann ich ggf. auch von der CCU2 aus schicken, dann bliebe der HMLAN aus. Ist eigentlich doof, zwei Zentralen wenn man eine haben kann.
An die Angriffe hatte ich noch gar nicht gedacht ...
geht nich Gips nich ...
Hallo,
Zitat von: Pfriemler am 15 September 2015, 18:01:41
letztlich sind ein Dutzend Werte von HM für FHEM intern relevant, die kann ich ggf. auch von der CCU2 aus schicken, dann bliebe der HMLAN aus.
Das geht wahrscheinlich am besten mit zaps (http://forum.fhem.de/index.php/topic,40189.0.html) oder henryks (http://forum.fhem.de/index.php/topic,41060.0.html) Modul. Ansonsten kannst Du auch Fhem eine andere HMID geben, dann lauscht es sicher nur passiv mit. Und selbst wenn Fhem senden sollte, wird es von den Geraeten ignoriert.
Viele Gruesse
Michael
Dem hmlan muss man jedes device einzeln bekannt machen, dann werden acks automatisch gesendet.
Hat man mehr hmlan darf man das device nur einem hmlan bekannt machen. Die vccu leistet das, also eintragen und löschen der IDS in den IOS.
Man könnte ein dummy io einrichten und es dem device als io zuordnen. Dann kann man nicht mehr senden, was gewünscht ist. Parallel ist schwierig. Attack geht garnicht zu erkennen
@Martin: is ne gute Idee - aber funktioniert das? Ein zugeordnetes IO zu einem HM-Gerät legt doch m.W. nur eine (bevorzugte) Sende-IO fest - das ACK sendet doch aber stets das empfangende IO? So könnte man zumindest verhinden, dass FHEM mit dem HM willentlich redet.
Martin, isses in der Tat so, dass das HMLAN eine Liste der Pair-Partner geschickt bekommt und dann autark ACKs sendet?
Hingegen finde ich Michaels Idee spannend - wenn ich mich recht entsinne, sind "Fremdgeräte" etwa vom Nachbarn schon immer ein "Störfaktor" in FHEM - also ist Mitlesen des Status anscheinend kein Thema. Und wenn sich das HMLAN an sich nicht angesprochen fühlt, sollte es auch keine ACKs schicken ... und wenn es reden will oder soll, ignorieren die HM-Geräte den Fremdling mit der falschen ID sowieso.
Zitat von: mgernoth am 15 September 2015, 18:06:27
Hallo,
Das geht wahrscheinlich am besten mit zaps (http://forum.fhem.de/index.php/topic,40189.0.html) oder henryks (http://forum.fhem.de/index.php/topic,41060.0.html) Modul. Ansonsten kannst Du auch Fhem eine andere HMID geben, dann lauscht es sicher nur passiv mit. Und selbst wenn Fhem senden sollte, wird es von den Geraeten ignoriert.
Viele Gruesse
Michael
Der Vorteil vom HMRPC Modul ist, dass es die RPC Schnittstelle der CCU anzapft bzw. sich dort registriert. Dadurch bekommt es Änderungen in der CCU (Status der Geräte) sofort mit. HMCCU hingegen muss aktiv die CCU pollen oder man muss von der CCU aus einen Trigger an FHEM schicken (z.B. per netcat auf den Socket Port von FHEM).
HMRPC ist allerdings mit Vorsicht zu genießen, da die Implementierung von RPC nicht vollständig ist.. So werden z.B. Nachrichten von der CCU nicht bzw. nicht korrekt bestätigt. Das führt zu vielen Fehlermeldungen im Syslog der CCU. Ich habe das nie richtig zum Laufen bekommen und daher HMCCU entwickelt.
Das empfangende io? Funk ist broadcast. Es wird immer alles empfangen, selbst die Adresse ist egal.
Ja, die hmlan,hmusb werden mit den IDS der device versorgt. Cul natürlich nicht, die unterstützt das nicht. Bei iowechsel wird die ID in einem gelöscht und im 2. gesetzt.
Wie sollte es sonst funktionieren, zwei hmlan an einem system zu betreiben? Die ccu2 macht das identisch. Ausser, dass ich nicht gesehen habe, dass sie einen Automodell unterstützt. Das ist bei plug&play etwas kompliziert.
Du kannst ein io mit der hmid der vccu anlegen, es nicht der vccu zuordnen. Das device setzt attr iodev des io, auch hier nicht der vccu zuordnen. Nun hast du ein dummy io mit ID der zentrale. Du könntest im io noch dummy setzten, dann wird nicht nach ihm gesucht.
Nur mal so'n Zwischenbericht:
Zentrale läuft und ich paire nach und nach die HM-Geräte von FHEM auf die CCU2 um. Dann gibt es ATTACKs bis zu einem FHEM-Neustart - dann ist Ruhe. Die Definitionen lasse ich in FHEM stehen, ändere nur "autoReadReg" auf 0-none - die Geräte hören ja eh nicht mehr auf FHEM und HMLAN, also hat das Registeauslesen eh keinen Zweck.
Der Status der HM-Geräte wird aber sauberst und flink mitgelesen und angezeigt (schneller als auf der CCU2). Keine Fehler, nichts. Nun fehlt mir nur noch eine Steuermöglichkeit von FHEM aus, aber das ist ja prinzipiell klar.
Warum auch Fehler? Fhem ist ein Spion. Sollten sich devices steuern lassen ist es ein bug in der fw. Wenn fhem die ID der zentrale bekommt kannst du auch steuern.
Alles schon durch gesprochen.
Den Sinn verstehe ich nicht. Entweder nutze ich die ccu. Oder ich steuerte die ccu durch fhem. Oder ich erweitere fhem um den Komfort der ccu zu erhalten. Aus meiner Sicht ist das erreicht. Wenn man templates einsetzt, sinnvoll, ist man sogar weit ueberlegen. Was die verknuepfbarkeit angeht auch mit anderen Systemen kommt die ccu garnicht mit.
Nettes Experiment, den Sinn werde ich nie verstehen. Aber jeder wie er will
Ich habe das nur als Hinweis platziert, dass es einfach ist und kein Hexenwerk, FHEM als "Spion" mitlaufen zu lassen und so den Status einzelner Geräte quasi ohne Anfrage bei der CCU2 mitzubekommen. Obendrein ist FHEM in der Aktualisierung schneller als das Webinterface der CCU2.
Wenn FHEM die ID der Zentrale bekommt, hagelt es ATTACKS. Das kann keine Lösung sein.
Zitat von: martinp876 am 11 November 2015, 19:47:42
Nettes Experiment, den Sinn werde ich nie verstehen. Aber jeder wie er will
Sagtest Du schon, verlangt auch keiner. Ich will einfach alles, was Homematic unter sich ausmachen will, auslagern. Für mich wäre das ein Produktivsystem und FHEM das Sahnehäubchen - und alles läuft, wenn ich FHEM mal versehentlich totkonfiguriert habe...
ZitatWenn FHEM die ID der Zentrale bekommt, hagelt es ATTACKS. Das kann keine Lösung sein.
dann ist es ein Fehler. Die Attacks sollte es auch Hageln, wenn die CCU an devices einstellungen vornimmt, von welchen FHEM vermutet dass sie ihr gehören.
ansonsten, wie gesagt: jeder wie er will.
Zitat von: martinp876 am 14 November 2015, 08:20:33
dann ist es ein Fehler. Die Attacks sollte es auch Hageln, wenn die CCU an devices einstellungen vornimmt, von welchen FHEM vermutet dass sie ihr gehören.
War das WE weg ...
Ich habe meine HM-Devices von FHEM geunpairt und an der Zentrale mit differierender ID angemeldet. FHEM weiß also, dass die Geräte nicht mehr FHEM "gehören". Dadurch erkennt das HMLAN auch keine fremden Funktelegramme der FHEM-ID und sendet keine Attacks. Alle ACK kommen nur noch von der CCU.
Die bisher mit FHEM gepairten Geräte werden jedoch trotzdem in ihren Statusmeldungen weiter problemlos mitgelesen.
Eine Steuerung von FHEM direkt funktioniert jetzt natürlich nicht, aber das ist ja auch nicht von mir vorgesehen. Dafür sende ich dann Befehle an die CCU, die das erledigt.
Muss ich erlich gesagt nachsehen. Korrekt ist es aber so nicht.
Fhem kümmert sich nicht darum, ob gepairt ist oder nicht. Das interessiert das device.
Fhem gleicht es mit der ID des assigned io ab.
Hminfo sollte merken, wenn pairedto nicht dem io entspricht.
Fhem geht bei allen devices die nicht ignore sind davon aus, das sie dazu gehören.
Einen sniffermode gibt es in der Form nicht.
ZitatMuss ich erlich gesagt nachsehen. Korrekt ist es aber so nicht.
Schade. Mir gefällt der Zustand so sehr gut.
ZitatFhem kümmert sich nicht darum, ob gepairt ist oder nicht. Das interessiert das device.
Dem Device ist es erst mal auch ziemlich egal. Es arbeitet stand-alone, bis sich eine Zentrale als Herr und Meister meldet.
ZitatHminfo sollte merken, wenn pairedto nicht dem io entspricht.
Das blieb anfangs auf der FHEM-ID stehen (und in R-pairCentral stand "set_0x000000"). Nach ein paar Neustarts kann ich nun feststellen, dass z.B. meine SCo's brav in PairedTo "0x000000" melden (und nicht etwa die ID der CCU2). Für meinen Dimmer im Esszimmer sieht FHEM aber noch immer
Internals:
DEF 266A77
HMLAN1_MSGCNT 17
HMLAN1_RAWMSG E266A77,0000,8CBCC8AB,FF,FFC1,A9A410266A773B4DAD060100008000
HMLAN1_RSSI -63
HMLAN1_TIME 2015-11-18 21:29:30
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 17
NAME WzDimmer1
...
channel_01 EsstischLampe
...
protState CMDs_done_Errors:1
...
Readings:
...
2015-07-06 04:03:58 PairedTo 0x1411AB
...
2015-11-11 00:17:02 R-pairCentral set_0x000000
Ein Auslesen der Register des Dimmers via FHEM funktioniert auch nicht mehr - der Dimmer ignoriert den Befehl ja (sieht so aus als wenn er von einer fremden Zentrale käme). So bleibt R-pairCentral wohl für immer auf "set_0x000000" stehen ...
Natürlich bekommt FHEM mit, dass die mit der CCU verheirateten Geräte z.B. mit dieser reden ("contact closed (to CCU2)") (wobei CCU2 bei mir ein HM-Dummy mit der ID der CCU ist). Insofern kann ich zumindest bei den SCo's keinen Unterschied zwischen einem Gerät feststellen, welches etwa per Autocreate (oder manuell) in FHEM angelegt, aber noch nicht gepairt wurde (außer dass hier die Pakete an broadcast gehen), und meinen von FHEM abgelernten Geräten. Auch bei den Pair-Fehlversuchen, bei denen das Device den Paarungsbefehl partiell "missachtet", würde man bei ATTACKs eher hellhörig werden.
ZitatEinen sniffermode gibt es in der Form nicht.
Ich würde das Verhalten eher mit "Einbahnstraßen-Geräten" vergleichen, wie etwa WS-Sensoren über einen CUL. Hier protokolliert FHEM für ein einmal angelegtes Gerät alle Statusmeldungen mit, ohne überhaupt eine Chance zur Gegenreaktion zu haben. So ähnlich ist es hier. Ich darf natürlich nicht versuchen, das Gerät aktiv zu steuern. Dann wächst der cmd_error-Stapel ...
ZitatFhem geht bei allen devices die nicht ignore sind davon aus, das sie dazu gehören.
Verstehe ich.
ZitatHminfo sollte merken, wenn pairedto nicht dem io entspricht.
Das ist in der Tat ein Schönheitsfehler - die Liste der möglichen Fehler ist jetzt schon ellenlang, exemplarischer Auszug:
peer list incomplete. Use getConfig to read it.
incomplete: HM_UWS1:
incomplete: OGNFenster:
incomplete: OGOFenster:
incomplete: OGWFenster:
peer not defined
FB4Alarm_disarm id:ABC12301
PairedTo missing/unknown
CCU2
OGNFenster
OGOFenster
OGWFenster
PairedTo mismatch to IODev
8BattAktor1 paired:set_0x000000 IO attr: 1411AB.
EGHaustuer paired:0x000000 IO attr: 1411AB.
EGWzTerassentuer paired:0x000000 IO attr: 1411AB.
EnMonitorStecker1 paired:set_0x000000 IO attr: 1411AB.
FB4V paired:0x000000 IO attr: 1411AB.
OGBadFenster paired:0x000000 IO attr: 1411AB.
SchalterSensorSCI3_1 paired:0x000000 IO attr: 1411AB.
WzDimmer1 paired:set_0x000000 IO attr: 1411AB.
Last but not least: ATTACKs sollte es eigentlich nur dann geben, wenn FHEM bzw. das entsprechende IO feststellen, dass Pakete unterwegs sind, die als Absender die eigene ID tragen, aber definitiv nicht von FHEM stammen (wie wenn jemand mit einer zweiten Zentrale gleicher ID die Geräte zu kapern versucht). Meine "umgelernten" Geräte sollte FHEM wie "welche vom Nachbarn" behandeln - tut es ja auch, ist für mich kein Fehler.
Pairedto ist sicher falsch.
Fhem dekodiert das lesen der Register, auch wenn die ccu diese liest. Wenn fhem etwas nicht mit bekommt oder die Register nach dem lesen nicht gespeichert werden ist der Inhalt unsicher. Ich klassifizieren die Register somit als zufällig und unzuverlässig.
Der mode ist ein reiner sniffermode. Du kannst nur lauschen. Mit ein paar Tricks könntest du virtuelle tasten in fhem definieren und trigger auslösen. Das einrichten wird aber holprig, da eines über die ccu machen must.
Einem wettersensor lauscht man auch nur. Man kann nichts einstellen, ist also sniffen.
Ich muss dummy noch einmal ansehen. War eine alternative zu ignore, lange her.
Was immer du machen willst mit den gesammelten daten
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.
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!
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.
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. 8)
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 (http://heinz-otto.blogspot.de/2016/02/cul-stick-flashen.html) 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
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.
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 ... 8) 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?
Zitat von: martinp876 am 13 März 2016, 15:31:40
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?
ZitatIch 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.
ZitatScheinbar ist ein sinnvoller level der Zufriedenheit erreicht.
Sehe ich anders ;D ... Die Frage ist eher, wo Aufwand und Nutzen gegeneinander liegen.
ZitatUm 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.
@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.
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.
Zitat von: martinp876 am 19 März 2016, 09:09:28
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?
Ein eigenes Widget geht natürlich. Das ist aber kein Standard Web Interface in fhem.
Mal sehen, wie man fhemweb erweitern kann.