Schade dass Diskussionen zum Thema VIS scheinbar immer zu einer Art Religionskrieg ausarten. Es wird gerne pauschalisiert und vieles nur sehr oberflächlich :lol: betrachtet.

Primär versteht sich iobroker (oder auch openHAB, FHEM, …) als Heimautomatisierungslösung. Der Fokus liegt auf der Automatisierung (also ohne Fremdeingriff). Keine Ahnung wie das bei den anderen Usern so war, aber zumindest ich habe anfangs all meine Anstrengungen auf die eigentlichen Aufgaben meiner Geräte/Sensoren/... gelegt. Die UI war bestenfalls zweitrangig.

Dann kam aber irgendwann die Zeit, wo das Backend einen vernünftigen Stand hatte. Auf einmal war Zeit da, sich um Visualisierung und den berüchtigten WAF zu machen :mrgreen:

Also ran an VIS und erst mal durch das tiefe Tal der Tränen gewandert... Mit relativ viel Aufwand und Einarbeitung in HTML, CSS und Javascript habe ich eine einigermaßen anschauliche Oberfläche zusammengebastelt.

Aber natürlich ist es immer gut, auch mal die "Mitbewerber" anzuschauen. IP-Symcon+IPSView, openHAB, ... es gibt ja inzwischen ziemlich viele Systeme.

Inzwischen kann ich sagen, dass ich in einer Woche mit HABpanel eine wesentlich ansprechendere Oberfläche zusammengebaut habe, als in mehreren Monaten mit VIS. Das liegt natürlich zu einem nicht unerheblichen Teil an meinen nicht allzu großen Fähigkeiten in Sachen "Webdesign". Aber genau deswegen kann ich das Argument bezüglich mangelnder Einsteigerfreundlichkeit von VIS absolut unterschreiben. Ein paar hübschere Standardwidgets könnten hier eventuell Abhilfe schaffen und würden die "Alles-selbst-Macher" trotzdem nicht in ihren Möglichkeiten einschränken.

Aber warum nicht gleich HABpanel? Wer glaubt, diese Lösung sei viel zu limitiert, hat sich damit noch nicht wirklich befasst. Mit den Custom-Widgets, welche mit einer Mischung aus HTML, CSS, AngularJS und Bootstrap befüllt werden können, ist ebenfalls fast alles möglich. HABpanel ist auch verhältnismäßig leicht auf verschiedene Displaygrößen anpassbar. Ich behaupte ja nicht, das wäre mit VIS unmöglich, aber für den Laien definitiv schwerer.

Immerhin bietet iobroker ja mehrere unterschiedliche Oberflächen an. Wäre der Bedarf nach Alternativen zu VIS nicht vorhanden, hätten Bluefox (und andere) da sicherlich keine Minute seiner (ihrer) wertvollen Zeit investiert.

Bitte nehmt davon Abstand, jeden der VIS nicht mag gleich als "Jünger der Konkurrenz" zu verunglimpfen. Bleibt bitte auch weiterhin offen für Veränderungen. Sonst würden wir ja heute noch mit FHEM rumfrickeln :lol:

Sehr interessanter Vergleich! Einige Erfahrungen kann ich bestätigen, andere dürften sich inzwischen schon alleine durch funktionelle Updates verändert haben.

Mein Weg bisher: (ganz kurz) openHAB 2 als Beta -> ioBroker -> openHAB 2.4 + ioBroker parallel

openHAB:

In der Beta und als Smarthome-Frischling konnte ich mit openHAB gar nichts anfangen. Der Einstieg war irgendwie "konfus" PaperUI noch nicht ganz fertig, BasicUI, Bindings, Things, Items …?! :?

Mit der aktuellen 2.4 finde ich das Ganze schon sehr gelungen. Das Setup ist jetzt auch weitreichend über die UI möglich und relativ logisch. Das System nimmt sich weniger Ressourcen als der ioBroker und läuft ebenso stabil.

Ein absoluter Traum ist die Entwicklung in VSCode + openHAB-Extension! Das macht einem das (Entwickler-)Leben wirklich leicht.

Die Rules sind ziemlich logisch und funktionieren bei mir einwandfrei. Ich habe inzwischen alle meine ioBroker-Javascript-Entwicklungen zu Rules portiert.

Dann natürlich das HABpanel...entweder man liebt es oder man findet es doof. Mir gefällt, dass man sich mit überschaubarem Aufwand auch selbst wiederverwendbare Widgets bauen und diese auch an andere User weitergeben kann. HABpanel für ioBroker wurde aber ja auch gerade erst aktualisiert...

Die Community von OH ist gewöhnungsbedürftig. Gefühlt sind 90% der Mitglieder im offiziellen Forum Deutsche, müssen sich aber auf englisch unterhalten. Das ist zwar verständlich, wenn man auf internationale Nutzung aus ist, man kommt sich aber dennoch affig vor.

Was die Aktualität und den Entwicklungsfortschritt betrifft, ist ioBroker - zumindest für meine bisherigen Anforderungen - immer ein Stück voraus. MQTT ist jetzt aber auch als Binding in OH verfügbar.

ioBroker:

Schnell aufgesetzt, für alles Adapter vorhanden, stabil, beste Community (zudem in deutscher Sprache).

Man kommt hier immer relativ schnell zum Ziel. Adapter installieren, Instanz erstellen, ein paar Parameter setzen und schon sieht man die ersten Werte reinkommen. Ein wenig unangenehm finde ich nur den Javascript-Editor. Der wurde jüngst zwar um Faktor 10 (gefühlt) besser, aber sowas wie bei openHAB ist eine andere Welt.

VIS ist sehr mächtig, aber auch mächtig anstrengend

Fazit:

Aktuell tendiere ich eher zu openHAB - vor allem wegen VSCode. Aber dank Docker laufen die beiden Systeme brav nebeneinander und können sogar kooperieren. Von daher kann ich mir das Ganze ja in aller Ruhe anschauen.

HABpanel hat mir auf Anhieb gefallen. Man kommt sehr schnell zu einem sehr schicken Interface.

Material UI gefällt mir leider überhaupt nicht und wenn ich das richtig sehe, muss man da all seine Datenpunkte streng mit den passenden Enums versehen (Raum, Funktion).

Seis drum. Mache ich eben mit VIS weiter und schaue mir openHAB auch mal wieder genauer an.

Leider ist die Möglichkeit der Visualisierung über HABpanel komplett an mir vorbei gegangen.

Bisher habe ich alles über VIS gemacht, aber die Optik ist bei mir eher zweckmäßig als elegant.

Mit HABpanel sieht - zumindest das Wenige, was jetzt schon geht - auf Anhieb professionell aus. Leider scheint die Entwicklung jedoch eingestellt worden zu sein (letzter Chckin im Mai 2017).

Das finde ich extrem schade. Ist das Interesse an diesem Adapter wirklich so schwach?

@Segway:

Mal generell die Frage:

Warum ist das Standard-Einstellung ? Sollte der wirklich jeden Tag gestartet werden ? Bei mir läuft der bisher ohne Neustart auch einwandfrei - ich frage deswegen, weil Standardeinstellung ja eine Empfehlung ist, dass man es so machen sollte :shock: `
Berechtigte Frage. Wenn man sich das Changelog des Adapters anschaut, dann sieht man, dass ganz am Anfang der Adapter jede Stunde neu gestartet wurde.

Ich schätze mal das dient der Vorbeugung irgendwelcher Fehler, die mit der Zeit auftreten können. Da der Neustart so flott vonstatten geht, habe ich das ehrlich gesagt nie hinterfragt.

5:04 Uhr ist wie bereits geschrieben wurde die Standard-Restart-Einstellung für den Telegram-Adapter. Ist bei mir genauso. Dauert auch nur wenige Augenblicke bis der wieder "online" ist.

Ich bin jetzt auch schon eine Weile mit dabei und kann von einigen Höhen und Tiefen berichten.

Mein Fazit nach all der Zeit ist, dass die Stabilität fast ausschließlich vom "Unterbau" abhängt!

Ich bin damals auf einem Raspberry Pi2 gestartet, weiter auf den Pi3, dann auf meinen alten Mac Mini (Late 2010). Dann habe ich es auf einem Odroid C2 versucht. So richtig glücklich war ich mit all den Varianten nie. Die Systeme mit SD-Card zicken gelegentlich nach einem Stromausfall rum, andere reagieren allergisch auf Linuxupdates. Das ist aber alles nicht die Schuld von ioBroker. Zum einen muss der User wissen, was er da gerade updated (und was die Folgen sein könnten) zum anderen gibt es eben Hardwarebeschränkungen.

Dennoch war ich kurz vor dem Aufgeben, bis ich ioBroker in Docker auf meinem NAS gepackt habe. Seither schnurrt das System wie ein Kätzchen. Dass ein Adapter mal - je nach Entwicklungsstand - zickt ist zu erwarten, aber der Kern selbst ist inzwischen erstaunlich stabil.

Und auch ein dickes fettes Lob an die Community und alle Adapter-Entwickler! Nicht nur das Thema "Harmony Hub" spricht Bände…

Die Timer, die auf der Bridge laufen sind aber meines Wissens nicht über die offizielle API zugänglich.

Dass das mit Node-RED funktioniert liegt an der per default eingestellten Pollingrate von 3 Sekunden.

Das erzeugt Last auf ioBroker- und Bridgeseite.

Das muss nicht schlimm sein, aber kann je nach Ressourcenlage und Anzahl an Hue-Geräten zu Nebenwirkungen führen.

Die Bewegungsmelder tauchen im Hue-Adapter nicht auf.

Das Problem mit den Dingern ist, dass die nur ein paar Sekunden Bewegung signalisieren und dann wieder in den Ursprungszustand zurück wechseln.

Damit man mit dem Bewegungssignal etwas anfangen kann, müsste man das Pollingintervall auf wenige Sekunden setzen (am besten 1 Hz). Das würde aber mit ziemlicher Sicherheit die Bridge überfordern.

Ich frage über Javascript die Temperatursensoren der Bewegungsmelder ab. Das ist recht einfach. Allerdings frage ich die nur alle 60s ab.

Okay danke, das macht Sinn.