Vergleich HomeServer Visu vs.SmartVisu

[henfri]

Hallo,

ich bin mit der Geschwindigkeit meiner SmartVisu nicht zufrieden. Konkret stört mich, dass es sehr lange (3s) dauert, bis alle Statii angezeigt werden. Sind die Statii erstmal angezeigt läuft aber alles flüssig. Das liegt daran, dass ich die Visu nach Gewerk und nicht nach Raum sortiert habe. So gibt es dann Seiten mit sehr vielen Statii/Werten, hinzu kommen noch Diagramme. (Dennoch verstehe ich nicht, warum das ganze so lange dauert).
Hinzu kommt, dass ich auf das Quad-Design gesetzt habe, welches nicht wirklich weiter entwickelt wird.
Wie auch immer: Ich muss die Visu neu designen und da frage ich mich, ob es nicht effizienter ist, einfach den Gira Homeserver mit Quad Client zu nutzen.

Ich möchte jetzt nicht den x-ten "Welche Visu ist die Beste" Thread eröffnen und richte mich hier v.a. an diejenigen von euch, die Erfahrung mit beiden Visualisierungen haben (zumindest Bernd/BMX und Niko/2ndsky fallen mir da ein.

Welche Vor/Nachteile seht ihr in der Praxis mit den Beiden Varianten?

Für mich sieht es momentan so aus:

Pro HS:

• Kommerzielle Lösung, bei der ich von einer Weiterentwicklung auch in den nächsten Jahren rechnen kann
• Erstellung der Visu mit Editor/GUI -aber nicht WYSIWYG
• Import der GAs, Zuordnung per Drag&Drop
• Schnelle Darstellung der Visu auch auf Mobilgeräten
• Meldungen als Liste
• Schulungsvideos

Kontra HS:

• Was nicht geht, geht nicht. Funktionsvorlagen/Widgets(oder wie das beim QC heisst) werde ich nicht schreiben (können/mich einlesen wolle; begrenzte Zeit)
• Kosten (im Vergleich zu der Zeit, die man reinsteckt für mich aber zweitranging)
• Visu nur per APP

Pro SmartVisu:

• Vieles alles gibt es schon out of the box (Meldungen als Liste fehlen mir noch), was es nicht gibt ist -für mich- sicher einfacher hinzuzufügen als beim QC
• OpenSource
• Hübscher als der QC

Contra SmartVisu:

• Die Entwicklung scheint seit einer ganzen Weile zu stocken
• Abhängigkeit von einer/wenigen Entwicklern (kein (!) Vorwurf)
• Performance

Viele Grüße,
Hendrik

[JuMi2006]

Ich baue seit ein paar Monaten um ... also weg von smartvisu/smarthome.py hin zum HS.

Eigentlich hast Du die wichtigsten Punkte schon genannt, man muss nur seine eigenen Prioritäten festlegen. Ich bin bislang auch mit keiner Visu richtig fertig geworden, sei es die CometVisu, smartvisu (Standard) oder smartvisu Quad. Wenn meine wichtigsten Funktionen liefen verließ mich meist die Lust.

Wichtige Punkt in Bezug auf Homserver sind für mich noch folgende:
++ durch (erfahrene) Elektriker/SI zu warten (man bedenke ein unerwartetes Ableben)
- große Updateintervalle

Wenn man sich aber mal mit dem HS beschäftigt und Sachen wie "ByteCode" verstanden hat, dann ist der HS gar nicht so schlecht und starr wie man glaubt.
Mir reicht eine einfache Visu wie sie der QuadClient bringt, ich muss keinen Nachbarn beeindrucken sondern möchte lieber schnell und von überall mal eben gucken was los ist. Wir haben auch noch Taster im Haus ... die finde ich teilweise schneller als mein Smartphone .

Zu meiner "Serverhistorie":
2011 - 2013 WireGate
2013 - 2015 smarthome.py
2015 - ??? Homeserver

Wobei smarthome.py auf kleinerer Hardware mit weniger Aufgaben immer noch läuft und auch weiter laufen wird um die Lücke zum HS zu schließen.

[mumpf]

Hi Hendrik,

ich habe zwar keinen HS, werde mir aber sicherlich keinen zulegen. Das hat nicht primär was mit dem Preis zu tun, sondern mit der Tatsache, dass es kein open source ist. Letztendlich macht man mit dem HS das, was man bei KNX immer verpönt: Man macht sich von einem Hersteller abhängig.

Mir ging es bisher auch ähnlich wie JuMi2006: Ich hatte mehrere Visus/Logik-Engines am Start (FHEM, CometVisu/Wiregate, SmartVisu/smarthome) und bin mit keiner so richtig fertig geworden bzw. war auch mit keiner so richtig zufrieden. Deswegen bin ich mir sicher, dass es bei HS nicht anders sein wird. Und dann bin ich dort eingeschränkt auf das, was GIRA "vorgedacht" hat. Ist nichts für mich. Selbst wenn ich kein Stück an der smartvisu erweitern werde - mich beruhigt das Wissen, dass ich alle sourcen habe und es notfalls könnte.

Wichtige Punkt in Bezug auf Homserver sind für mich noch folgende:
++ durch (erfahrene) Elektriker/SI zu warten (man bedenke ein unerwartetes Ableben)

Diesen Punkt durfte ich bei einem Freund von mir leider miterleben. Er hatte sich einen HS gekauft, mit dem Argument "Da weiß man, was man hat". Er hat bei einem Fehler das Gerät einschicken dürfen (<ironie>Ersatzgerät kam immerhin schon nach 2 Wochen</ironie>), sprich: Er wusste nicht, was er hat (Ich kann meinen 2. Pi starten und/oder von der Reserve-SD booten). Inzwischen ist er leider durch einen Unfall verstorben, seine Frau hat einen Elektriker kontaktiert um zu erfahren, was Änderungen an dem System kosten würden. Ich weiß die Preise nicht, sie meinte nur "astronomisch". Glücklicherweise konnte sie ihren Sohn dazu bewegen, sich da einzuarbeiten.

Muss jeder selbst entscheiden, ich versuche, meine sh.py/sv-Kombi komfortabel auszubauen und mein Haus so zu automatisieren, dass ich die Visu möglichst nicht brauche - dann stört es mich auch nicht, wenn sie nicht so schnell ist.

Just my 5 ct,
Gruß, Waldemar

[Jever]

Daher auch die hier oft gelesene Empfehlung, wichtige Funktionen nicht auf Server zu legen (Single Point of Failure), sondern eben dezentral, so ist der Standard ja auch konzipiert. Nur die Kür zentral, niemals die Pflicht...

[StefanW]

Sehr interessanter Thread,

es bestätigt was ich mir schon sehr lange denke. Am Ende erfüllen sich die Erwartungen in die Community-Projekte / Open-Source-Produkte nicht, da die Entwickler sehr häufig (wenn nicht fast immer) die Lust am Projekt verlieren und es nicht mehr pflegen.

So ist der Mensch eben. Nur die finanzielle Basis bei den kaufbaren Produkten motiviert langfristig den Hersteller und seine Entwickler zu Weiterentwicklung und Pflege.

Genau so wird auch der Weg für unsere Server Produkte sein. Abkehr von OS, hin zu geschlossen um die nötigen Einnahmen zu erzielen um damit eine kompetente Entwicklermannschaft zu beschäftigen, die auch langfristig weiterentwickelt.

lg

Stefan

[mumpf]

Hi Stefan,

ich verstehe zwar Dein kommerzielles Interesse, aber für mich käme so etwas nicht in Frage. Ich hätte mir das WireGate nie gekauft, wenn es hierzu keinen root-Zugang gegeben hätte. Und es mach mir noch immer große Bauchschmerzen, dass ich keine komplette Kopie der CF-Karte im WG habe. Ich versuche bei so einem langlebigen Projekt wie einem Haus alles zu sichern.

• Bei den KNX-Geräten sind die Applikation und die Parametrierung in der ETS, die Projektdatei wird regelmäßig gesichert
• sh.py/smartvisu sind über einen redundanten PI und eine redundante SD-Karte abgesichert
• ETS und Entwicklungsumgebung für sh.py/smarthome sind auf einer VM, die wiederum regelmäßig gesichert wird.
• Beim WG habe ich das von euch angebotene backup aus dem Webmin, aber das wird voraussichtlich nicht reichen (eigene Plugins + eigene Skripts), um ein Austauschgerät schnell in Betrieb zu nehmen.

Ich persönlich sehe geschlossene Systeme immer kritischer, kommerzielles Interesse hat in der heutigen Zeit immer mehr die Tendenz zum Datensammeln und ein Server, der mein Haus steuert und dem ich über Regeln meine Gewohnheiten bzw. die meiner Familie beibringe, soll möglichst unter meiner Kontrolle und nicht unter der irgendwelcher Anbieter sein, die ein kommerzielles Interesse haben.

Gruß, Waldemar

[evolution]

Sicherlich ist es nicht jedermanns Sache einen zentralen Server programmieren zu müssen. Das mag für Informatiker oder denjenigen die dies ständig tut sinnvoll sein. Für jemanden, der hingegen nicht auf das Erstellen von Programmzeilen steht, mag das aber ganz anders aussehen. Dies ist in meinen Augen der Grund warum serverbasierte Systeme, die mit einer Oberfläche bedient ("programmiert") werden, ihre Darseinsberechtigung haben und zunehmend Verbreitung finden werden.

[johnnychicago]

Ich bin weder HS- noch Smartvisu-Nutzer, habe mit keinem der Systeme Erfahrungen. Zu der Ausgangsfrage kann ich nicht wirklich viel beitragen.

Aber der Open-Source-Ansatz wäre für mich relativ wichtig. Nicht, weil in dem Bereich die Entwicklung schneller voranschreitet als bei den geschlossenen Systemen (in dem Falle scheint es ja eher andersrum zu sein), sondern weil ich halt notfalls die Möglichkeit hätte, die Sache jemand anderem zu überantworten, wenn der/die originalen Entwickler nicht mehr da sind.

Generell denke ich, dass man nie 'hoffen' sollte, was noch an Entwicklungen kommt. Sich ein System zuzulegen, das 'warscheinlich in der Zukunft' Dinge kann, die ich haben will, ist immer ein Risiko. Entweder kann es das jetzt, oder ich suche mir was anderes aus.

Ich nutze ein Wiregate, und das konnte zum Kaufzeitpunkt die Dinge, die ich wollte (1-wire-Einbindung, vernünftig ausgelegte Hardware und die Möglichkeit, eine kleine Logikengine mitlaufen zu lassen). Dank der offenen Auslegung habe ich seitdem zwei massive neue Pluspunkte mitgenommen - den Logikprozessor und die CometVisu.

StefanW's Pläne gefallen mir nicht, tangieren mich aber auch nicht wirklich - mein Wiregate kann nicht weniger, weil er zukünftige Funktionen nicht offenlegt. Ob ich die Funktionen haben will und dafür Geld ausgebe, werde ich zu gegebenem Zeitpunkt entscheiden. Seit der Heartbeat-Geschichte gehe ich beruhigt davon aus, dass Probleme im (offenen) Basis-System von Elabnet analysiert/behoben werden, d.h. mein Wiregate würde nicht zum Sicherheitsproblem. Mehr würde ich von Gira beim HS wohl auch nicht erwarten

[JuMi2006]

Nun wird ja doch einiges durcheinander gewürfelt .

Ich bin mit dem HS zufrieden, habe ihm jetzt Sachen beigebracht die er vorher nicht konnte.
Gleiches habe ich sowohl beim WireGate als auch smarthome.py getan.

Jetzt kann hier jeder um die Gunst seines Produktes buhlen, wird es aber nicht allen recht machen können. Dies kann bis dato keiner der kommerziellen Anbieter ansatzweise. Und der Appetit kommt bekanntlich beim Essen.

Der Root-Zugang beim WireGate ist ja mittlerweile auch ein kleines Märchen. Keine Gewährleistung mehr wobei bestimmte Features jahrelang nur mit root-Rechten vernünftig ans laufen zu bekommen waren (Comet-Visu). Ich verstehe aus finanzieller Sicht auch Elabnet, aber während die Werbetrommel hier und da laut dröhnte geschah Monatelang hinter den Kulissen nichts vernünftiges (Patches/Bugfixes aus der Community). Für mich war das der Grund auszusteigen.

Warum bin ich von sh.py weg? Nicht weil meine Wünsche nicht erfüllt wurden oder die Entwicklung zu langsam ist ... hier entsteht ein falsches Bild. Ich bin (teilweise) weg weil meine Installation wahnsinnig komplex geworden ist. Hier ist was abhängig davon und dann wieder nach hier und da usw.. Damit meine ich keine Kernfunktionen im Haus. Sind HS und sh.py down geht hier ganz normal das Licht an und aus und niemand muss frieren. Aber jeder der so ein System betreut darf sich mal vorstellen was ein Dritter damit anfangen kann.

Ich bin mittlerweile soweit dass ich auf bestimmte Features eben verzichte anstatt sie komplex und für Dritte unverständlich umzusetzen. Eine Projektdoku die sich von alleine erstellt und Zusammenhänge vermittelt bildet der Logikeditor vom HS zumindest ansatzweise ab. Ich hatte am Ende selbst Probleme meinen (auch gut kommentierten) Code in Logiken und items zu folgen wenn diese mehr als ein Jahr nicht angefasst wurden .

Das macht mir Angst.

[DirtyHarry]

Am Ende erfüllen sich die Erwartungen in die Community-Projekte / Open-Source-Produkte nicht, da die Entwickler sehr häufig (wenn nicht fast immer) die Lust am Projekt verlieren und es nicht mehr pflegen.
So ist der Mensch eben. Nur die finanzielle Basis bei den kaufbaren Produkten motiviert langfristig den Hersteller und seine Entwickler zu Weiterentwicklung und Pflege.

Naja, selbst bei den kaufbaren Produkten ist die Motivation des Herstellers nicht immer gegeben. Zugegeben, die Wahrscheinlichkeit mag geringer sein, jedoch ist sie vorhanden.

Vorteil der Open Source ist halt wirklich, es kann jemand anders die Entwicklung weiterführen. Theoretisch könnte eine Firma das auch ermöglichen, wenn sie das Produkt einstellen (oder die ganze Firma), die Lizenz zu OS wechseln und die Sourcen online stellen. Wenn es Nachfolgeprodukte gibt, geben soll oder auch nur die Option dazu offen gehalten werden soll, sieht’s damit wieder schlecht aus.

[johnnychicago]

Ich bin mittlerweile soweit dass ich auf bestimmte Features eben verzichte anstatt sie komplex und für Dritte unverständlich umzusetzen. Eine Projektdoku die sich von alleine erstellt und Zusammenhänge vermittelt bildet der Logikeditor vom HS zumindest ansatzweise ab. Ich hatte am Ende selbst Probleme meinen (auch gut kommentierten) Code in Logiken und items zu folgen wenn diese mehr als ein Jahr nicht angefasst wurden .

Das macht mir Angst.

Das ist ein Problem, dessen wir uns immer bewusst sein müssen - schon alleine die Tatsache, dass wir KNX verwenden, reduziert die Support-Optionen. Das können bei weitem nicht alle Elektriker.

Dann trauen wir uns auch noch, Hersteller zu mischen und die Möglichkeiten unserer Geräte auszunutzen. Auch wenn das ETS-Projekt vorliegt, wird es für viele schon schwierig, wenn mehr als nur ein Gerät eins-zu-eins auszutauschen wäre.

Und wenn wir dann auch noch zusätzliche Hardware nutzen - und ausnutzen - dann wird die Luft schnell sehr, sehr dünn. Da müssen wir schon sehr gut dokumentieren, und trotzdem ist's dann schnell vorbei, oder prohibitiv teuer.

Andererseits - die Funktionalität, die wir uns bauen, würde vom freundlichen Systemintegrator nebenan halt auch mindestens 5-stellig kosten, und wenn der mal den Schlüssel unter den Teppich legt und verschwindet, wären wir genauso doof dran.

Meine Frühstücksszene zum Beispiel schaltet nicht nur die Lichter, sondern auch das Radio. Dazu braucht es ein Squeezebox-Plugin, eine kleine Logik im Logikprozessor, und ein Stück Bash-Script auf meinem Medienserver (um den Verstärker zu schalten). Das hätte vom Profi gut dreistellig, wenn nicht vierstellig, gekostet, und hat soviel Lebensdauer wie mein aktuelles Audio-Setup. Für SWMBO ist es allerdings ein Killerfeature des Smart Home.

[johnnychicago]

Naja, selbst bei den kaufbaren Produkten ist die Motivation des Herstellers nicht immer gegeben. Zugegeben, die Wahrscheinlichkeit mag geringer sein, jedoch ist sie vorhanden.

A priori nicht - der Verkauf ist gemacht, was bringt es dem Hersteller, das System weiterzuentwickeln? Sicher gibt's da weiche Faktoren, aber wenn man sich die Unwilligkeit der Telefonhersteller ansieht, ihre Modelle aktuell zu halten, gibt das schon ein trauriges Bild ab.

Anders ist es natürlich, wenn man den Kunden motivieren kann, weiterhin Geld auszugeben - sei es, um bestimmte Features zu erhalten, sei es im Rahmen eines Abos o.ä.

Vorteil der Open Source ist halt wirklich, es kann jemand anders die Entwicklung weiterführen. Theoretisch könnte eine Firma das auch ermöglichen, wenn sie das Produkt einstellen (oder die ganze Firma), die Lizenz zu OS wechseln und die Sourcen online stellen. Wenn es Nachfolgeprodukte gibt, geben soll oder auch nur die Option dazu offen gehalten werden soll, sieht’s damit wieder schlecht aus.

Passiert nicht. Wo ist das Interesse für den Hersteller?

[2ndsky]

Hallo zusammen,

wenn auch etwas spät, so will ich doch auch noch meine Beweggründe festhalten, in der Hoffnung, anderen damit vielleicht bei ihrer Entscheidungsfindung zu helfen.

Ich vertrete ebenfalls die Ansicht, dass die Grundfunktionalität im Bus stecken sollte und nur erweiterte Komfortfunktionen von einer zentralen Logikmaschine übernommen werden sollten (weshalb ich auch langsam alle Lampen von DALI auf reine KNX LED Dimmer umstelle). So wird bei mir das Licht per PM automatisch an- und ausgeschaltet. smarthome.py kümmert sich nur um einen zeit- und situationsabhängigen, angenehmen Dimmwert. Oder um die passende musikalische Untermalung bestimmter KNX Szenen.

Weiter verwende ich smarthome.py nach wie vor um andere Systeme anzubinden wie z.B. meinen Russound, meine Luxtronic Heizung etc. Eben weil es Open Source ist und mir das Programmiermodel und die Architektur besser gefällt als die des HS. Zum Thema Weiterentwicklung von sh.py: Bugfixes habe ich schon fast ein Jahr nicht mehr eingespielt und dennoch läuft meine Anlage problemlos. Es funktioniert und ist für mein Empfinden einfach erweiterbar. Das ist für mich die richtige Basis für Komforterweiterungen meines smarthomes.

Den Homeserver verwende ich rein für die Visualisierung und steuern der Anlage übers Smartphone, Tablet oder Wandpanels. Da ist der QC für mich perfekt. Ich brauche keine Wetteranzeige, Müllerinnerungen, Anruflisten, Sportergebnisse oder sonstiges darauf. Solche Informationen rufe ich mit der dafür vorgesehenen App direkt ab anstatt sie aufwendig und fehleranfällig irgendwo zu integrieren. Logiken, die im HS ablaufen, dienen rein zur Berechnung zusätzlicher Informationen zur Visualisierung (Anzahl leuchtender Lampen z.B.). Die QC Visu und die Gira App starten schnell und laden alle Stati zügig. Auch remote über VPN. Da die App Port 80 verwendet, kann ich sogar weiterhin VPN on demand auf dem iPhone nutzen. Das funktioniert sogar bei schlechter Datenverbindung ausreichend gut. Ein weiterer wichtiger Pluspunkt des HS ist die sehr gute und umfangreiche Zeitschaltuhr!

Und genau das war, was mich auf Dauer an der smartVISU gestört hat:
- langsamer Aufbau von unterwegs (nativ ist einfach performanter)
- begrenzte UZSU
- sehr zeitaufwendig die mobile Version für meine Bedürfnisse anzupassen