OBS - ein neuer Player in der Serverlandschaft?

[CaptainFuture]

Meine persönliche Einschätzung:

Das Konzept, Instanz von Interface nicht zu trennen ist mein größter Schmerz mit HA -- und damit meine größte Motivation OBS auszuprobieren. Gleichzeitig wird es eine große Hürde für DIY-Automatisierer sein, denen genau dieses Konzept sehr umständlich, fast barock erscheinen wird.

Was imho das größte Problem von OBS ist, ist dass es Home Assistant sehr, sehr ähnlich ist: Durch die Nutzung von Python und all der vielen Python-Bibliotheken kommt man natürlich schnell vom Fleck, holt sich aber auch das aufgeblähte, von Tests statt von Beweisen dominierte Entwicklungsmodell ins Haus. Auch ist der Ressourcennutzung von Python wenig optimal (Memory-Overhead, GIL, ..). Wenn der minimale Host sowieso ein Raspberry-Pi ist, spielt dies keine Rolle; hier wäre aber gerade im Schaltschrank eine "richtige" Embedded-Hardware eine Vision gewesen.
Hier wäre ein signifikantes Alleinstellungsmerkal zu heben gewesen, OBS bspw. in Rust zu implementieren. Natürlich ist es heutzutage extrem schwierig Programmierer zu finden, die andere Sprachen als Python beherrschen.

Das A und O von OSS-Projekten ist mMn die Gewinnung von Mitstreitern. Einmal um das langfristige Überleben der Software zu sichern, aber auch um die Entwicklung zu beschleunigen. Hier wird es extrem schwierig, da OBS zwangsläufig in Konkurrenz zu HA tritt. 99% der potentiellen Enwickler, die sowieso HA laufen haben, werden sich kein zweites System ans Bein binden wollen, da die Pflege von zwei Systemen immer mehr Aufwand sein wird. Übrig bleiben also die Profi-Nutzer -- denen wiederum in 80% der Fällen die o.g. Embedded-Lösung vermutlich sehr viel mehr Einsatzfälle liefern würde. Übrig bleiben als Schnitt also große Installationen die auch eine professionelle IT-Infrastruktur (mit bspw. Proxmox) haben.

Ich finde OBS sehr interessant, habe aber große Bauchschmerzen um die langfristige Entwicklung, da die Nische imho zu klein geschnitten ist. Ggf. wäre es zwar anstrengender, aber nachhaltiger gewesen, sich bei HA zu engagieren um die fehlenden Features dort zu implementieren. Oder eben mehr radikale Andersheit zu wagen.

[r4id]

Cooles Projekt.
---

hier wäre aber gerade im Schaltschrank eine "richtige" Embedded-Hardware eine Vision gewesen.

ch finde OBS sehr interessant, habe aber große Bauchschmerzen um die langfristige Entwicklung, da die Nische imho zu klein geschnitten ist.

Sehe ich auch so.


Wie ist denn geplant, wie eine Visu erstellt wird? Läuft das dann wie bei HA oder ist das ein eigener Webserver mit viel html und css spielerei`?

[Tokamak]

Ich ziehe den Hut vor so viel Engagement, sehe es aber ähnlich wie die Vorposter.

OBS is derzeit "von Entwicklern für Entwickler". Ohne Visu und Entwicklung von Code/Regeln im gleichen Kontext sehe ich nicht, wo OBS wirklich benötigt wird. Und hier stellt sich mir die Frage, warum nicht etwa die Entwickler von OBS und smarthomeNG ihre Kräfte bündeln?

[abeggled]

hier wäre aber gerade im Schaltschrank eine "richtige" Embedded-Hardware eine Vision gewesen.

Ich denke heute halten eher leistungsfähigere Systeme Einzug in den Schaltschrank. Daher die RPi, bzw. ARM64 Basis. Siehe auch neue Entwicklungen wie den Phoenix Catan C1 mit der Option zur Verwendung von IP-Symcon.

Das A und O von OSS-Projekten ist mMn die Gewinnung von Mitstreitern.

Aktuell können wir uns nicht beklagen, es kommen laufend neue dazu.

da OBS zwangsläufig in Konkurrenz zu HA tritt. 99% der potentiellen Enwickler, die sowieso HA laufen haben, werden sich kein zweites System ans Bein binden wollen

Nein, überhaupt nicht. HA ist eine Smart-Home Lösung, der OBS ist ein Multiprotokollserver für die Gebäudeautomation. Zudem haben wir heute schon HA Entwickler im Boot.

Übrig bleiben also die Profi-Nutzer -- denen wiederum in 80% der Fällen die o.g. Embedded-Lösung vermutlich sehr viel mehr Einsatzfälle liefern würde.

Profi-Nutzer brauchen ein Gesamtpaket, HW SW und Support. Dies ist das Ziel, der Weg dorthin dauert noch etwas.

Ggf. wäre es zwar anstrengender, aber nachhaltiger gewesen, sich bei HA zu engagieren um die fehlenden Features dort zu implementieren.

Naja, ich glaube nicht dass sich HA die Architektur auf den Kopf schmeissen lässt, zudem sind es ganz andere Zielgruppen.

Wie ist denn geplant, wie eine Visu erstellt wird? Läuft das dann wie bei HA oder ist das ein eigener Webserver mit viel html und css spielerei`?

Hast du dier die Demo mal angeschaut? In Kurzform, ganz einfach: Du erstellst in der VISU Hierarchie eine neue Seite, definierst wer oder wie darauf berechtigt wird, ziehst die Widgets per Drag&Drop auf die Seite, konfigurierst die Widgets nach Lust und Laune in der GUI, speicherst und geniesst deine neue VISU Seite.

OBS is derzeit "von Entwicklern für Entwickler".

Es wäre schon spannend zu verstehen woher solche Ideen kommen. Aktuell ist das Verhältnis rund 5 aktive User pro Entwickler und es gibt den OBS noch keine 100 Tage und erst seit Freitag einem grösseren Publikum bekannt.

Ohne Visu und Entwicklung von Code/Regeln im gleichen Kontext sehe ich nicht, wo OBS wirklich benötigt wird.

Ohne Visu? Wie kommst du darauf? Hast du den Eingangspost gelesen?

Und hier stellt sich mir die Frage, warum nicht etwa die Entwickler von OBS und smarthomeNG ihre Kräfte bündeln?

Es steht jedem Entwickler frei, sich beim open bridge Projekt zu beteiligen. Die Projekte sind, auch wenn beide Python als Basis haben und möglicherweise gewisse Parallelen im Objektmodell vorhanden sind, fundamental verschieden. OBS basiert auf einem API-first Ansatz und ist daher komplett offen.

[r4id]

Hast du dier die Demo mal angeschaut?

Ja, aber in der Demo kann man in der Visu nichts erstellen oder bearbeiten.

OBS ist ein Multiprotokollserver für die Gebäudeautomation

Für mich ist das klar ein HA "Konkurrent". Für einen Multiprotokollserver benötige ich per se ja keinen Logikeditor oder eine Visualisierung. Oder verstehe ich die Definition von Multiprotokollserver falsch?

[Tokamak]

Der User, das bin nicht ich, das ist meine Familie oder der Käufer unseres Hauses. Meine Familie hat mir in meinem höheren Alter klargemacht, dass sie in der Lage sein müssen, das Haus zu verwalten, wenn ich mich nicht mehr kümmern kann, wann immr das ist.

Jede Lösung, die auf dem Markt kommt, muss ich dahingehend prüfen. Aus diesem Grund verlege ich derzeite zentrale Funktionalität von openHAB auf den EibPC, weil der im Haus verbleibt, aber sich nach mir niemand mit Proxmox/Raspi, openHAB und habApp auseinandersetzen kann und will, erst recht nicht ein Käufer. Die Männerspielereien bleiben hingegen in openHAB.
Beim EibPC kann ich bei Hardwareausfall für meine Familie oder einen Käufer eine Anleitung schreiben: Kaufe einen EibPC, installiere ihn, lade EibStudio runter, lade (mein) Backup, mache einen Uplaod. Fertig, läuft. Ggf. kaufe ich noch einen EibPC und lege ihn neben die anderen bereits vorhandenen Ersatzgeräte (KNX-Netzteil, Aktoren, Taster, ...).
Aus meiner Warte müssen Lösungen gegen Geräte wie einen EibPC bestehen, und dazu gehört letztlich das Aufsetzen im Ernstfall.

Eure User sind Entwickler so wie ich, denke ich. Und für Menschen wie mich gibt es viele Tools und Umgebungen, HA; openHAB usw.

Das ist ein sehr persönlicher Blick, denke aber, dass das jeden früher oder später hier in irgendeiner Weise betrifft.

Bitte nicht missverstehen, ich finde es toll, was ihr da macht, und beeindruckend, was bereits da ist.

[abeggled]

Ja, aber in der Demo kann man in der Visu nichts erstellen oder bearbeiten.

Mea Culpa, ja das geht mit dem Demo User nicht. Die Erklärung wie es funktioniert habe ich ja erläutert.

Für mich ist das klar ein HA "Konkurrent". Für einen Multiprotokollserver benötige ich per se ja keinen Logikeditor oder eine Visualisierung. Oder verstehe ich die Definition von Multiprotokollserver falsch?

Darf deine Einschätzung bleiben, wie gesagt wir wollen hier niemanden überzeugen. Jeder darf für sich die Einschätzung machen zu wem der OBS ein Mitbewerber sein kann und was die grundlegenden Funktionen eines Multiprotokollservers sind.

Jeder soll bitte die Lösung nutzen die für ihn den grössten Mehrwert bietet.
Ich entwickle lieber das Produkt weiter als mich hier um Rechtfertigungen zu bemühen, daher wird es meinerseits keine Rückmeldungen mehr zu Diskussionen wie zu welchem System der OBS nun ein Mitbewerber sei und in welchem Projekt die Ressourcen besser eingesetzt seien geben.

[abeggled]

Beim EibPC kann ich bei Hardwareausfall für meine Familie oder einen Käufer eine Anleitung schreiben: Kaufe einen EibPC, installiere ihn, lade EibStudio runter, lade (mein) Backup, mache einen Uplaod. Fertig, läuft. Ggf. kaufe ich noch einen EibPC und lege ihn neben die anderen bereits vorhandenen Ersatzgeräte (KNX-Netzteil, Aktoren, Taster, ...).
Aus meiner Warte müssen Lösungen gegen Geräte wie einen EibPC bestehen, und dazu gehört letztlich das Aufsetzen im Ernstfall.

Da bin ich bei dir, für diesen Fall wird es irgendwann das bereits oben erwähnte Modell geben:

Profi-Nutzer brauchen ein Gesamtpaket, HW SW und Support. Dies ist das Ziel, der Weg dorthin dauert noch etwas.

[Noschvie]

Danke für die Vorstellung – das Konzept mit dem zentralen Objektmodell klingt überzeugend.

Mich interessiert eine grundsätzlichere Frage, die der Thread vielleicht aufwerfen kann: Welche Rolle spielt die KNX IoT 3rd Party API (KNX IoT Spec, 3rd Party API v2.1.0) in der aktuellen Serverlandschaft?

Die Spec definiert ein standardisiertes, herstellerunabhängiges REST-Interface inklusive Semantik- und Topologiemodell – eigentlich genau das, was viele Integrationen brauchen würden. Trotzdem scheint sie in keinem der bekannten Server wirklich implementiert zu sein.

Ist das ein Zeichen, dass die Spec am Markt vorbei entwickelt wurde? Oder fehlt schlicht die Nachfrage aus der Anwenderseite?

[abeggled]

Danke für die spannende Fragestellung. Zumindest bei uns ist KNX IoT kein direktes Thema. Wir sind auf verschiedenen Ebenen dabei die ein Semantik-Modell zu implementieren. Dies in Kombination mit der dem API-first Ansatz mach den OBS zum prädestinierten KNX IoT Kandidaten. Ganz ehrlich abgesehen von wenig konkretem Material bei der KNXA und ein paar Youtube Videos habe ich noch nichts "handfestes" gefunden, also Produkte die KNX IoT mitbringen würden (3rd Party) oder Lösungen bei den etablierten KNX Herstellern.

Ist das ein Zeichen, dass die Spec am Markt vorbei entwickelt wurde? Oder fehlt schlicht die Nachfrage aus der Anwenderseite?

Hier dürfte der Hund begraben sein.

[thewhobox]

Welche Rolle spielt die KNX IoT 3rd Party API (KNX IoT Spec, 3rd Party API v2.1.0) in der aktuellen Serverlandschaft?

Ich hätte den OBS jetzt nicht mit IoT in KNX Verbindung gebracht.

Oder fehlt schlicht die Nachfrage aus der Anwenderseite?

Die KNXA hat erst vor kurzem damit angefangen KNX-IoT bei den Herstellern zu Pushen.
Es gibt auch erst seit kurzem Überhaupt die Möglichkeit KNX-IoT Standardisiert zu zertifizieren.

Ich gehe davon einfach aus, dass das einfach noch etwas zeit benötigt.
Die KNXA macht hier ja auch viel mit OpenSource, evtl wird das in nächster Zeit nochmal einen push für KNX-IoT geben.

herstellerunabhängiges REST-Interface inklusive Semantik- und Topologiemodell

Damit das aber auch alles funktioniert, muss in der ETS mit dem Gebäude, Funktionen und auch Applikationen mit Semantik gearbeitet werden.

[CaptainFuture]

Ich entwickle lieber das Produkt weiter als mich hier um Rechtfertigungen zu bemühen, daher wird es meinerseits keine Rückmeldungen mehr zu Diskussionen wie zu welchem System der OBS nun ein Mitbewerber sei und in welchem Projekt die Ressourcen besser eingesetzt seien geben.

Dein Eingangspost drehte sich doch genau darum zu erklären "Wieso ein neuer Server" (sic) erfunden wurde. Du musst Dich vor niemandem hier rechtfertigen, aber der Sinn unserer Fragen ist ja nicht, Deine oder unsere Zeit zu verschwenden, sondern um genau herauszuarbeiten, was der Sinn eures Unterfangens ist. Ich denke die meisten hier werden sich fragen, ob eure Software für sie nützlich ist, ggf. so nützlich, dass sie einen Beitrag leisten würden. Wenn Du mit Deinem Anliegen und genau dieser Frage hierher in ein Forum kommst, dann aber keine Muse hast, Dich mit uns dazu auseinanderzusetzen, dann erweckt das den Eindruck, dass wir die entscheidenen Fragen gestellt haben.

Die alten Hasen kennen das Spiel, dass der xkcd 927 sehr schön auf den Punkt bringt: Der Verdacht liegt nahe, dass statt dem mühsamen Weg HA, OpenHAB o.Ä. zu fixen, lieber etwas neues erfunden wurde. Das Ergebnis ist dann eine weitere Spaltung der vorhanden Entwickler-Ressourcen und unterm Strich weniger Entwicklung; und dass bei zukünftigen Problemen (von OBS) der mühsame Weg -- wie initial -- gescheut werden wird und eure User das dann ausbaden werden müssen.

Ich will hier niemanden vorführen oder flamen. Betrachte mein Gerede lieber als Wetzstein für eure Projektbeschreibung, als Marketingtip oder meinetwegen als Lebenshilfe. Ich wünsch euch von Herzen viel Erfolg und dass mein Verdacht sich nicht erhärtet. standards_2x.png

[gbglace]

er Verdacht liegt nahe, dass statt dem mühsamen Weg HA, OpenHAB o.Ä. zu fixen,

Wenn mir deren Grundkonzept nicht gefällt warum sollte ich mich da ran setzen das zu fixen? Wo ich mit deutlich weniger Aufwand parallel schneller etwas neues aufziehe.

Wenn man innerhalb HA die Grundmechanik komplett umbaut, dann muss auch jeder der irgendwelche Zusatzkomponenten gebaut hat das umbauen. Und da wären auf dem Weg bis zum OBS Konzept mehrere Braking Changes notwendig. Wozu?

So kann man ein System daneben hinstellen und wenn so ein plugin maintainer vom OBS halt eher überzeugt ist, stellt er einmal um und schon geht es weiter.

Bis dahin bietet der OBS halt die native API um jedwede Entität zu der OBS noch keinen nativen Adapter hat diese von HA zu übernehmen.


Ansonsten kann ich einfach nur wiederholen. HA ist mir zu umständlich im Umgang mit Entitäten. Das Ding hat seine Vorteile beim automatischen generieren von Entitäten, dann aber was sinnvolles mit Anfangen ist nix wo man mal eben schnell zum Ziel kommt.

[henfri]

Wo ich mit deutlich weniger Aufwand parallel schneller etwas neues aufziehe.

Ja, klar.

[beauty]

In aller Kürze:

Synology mag wohl keine eingebetteten configs in der compose. Ich bekam jedenfalls einen Fehler:

configs.mosquitto_conf Additional property content is not allowed

Ich habe daher den Teil ausgelagert in eine separate Datei und diese dann wieder eingebunden über:

volumes:
- /volume1/docker/obs/mosquitto.conf:/mosquitto/config/mosquitto.conf:ro​

Ich muss wegen der persistenten Daten aber noch weiter forschen. Das scheint so auch noch nicht zu funktionieren....

Viele Grüße,
Mucki

MuckiLegden kannst du das evtl. etwas genauer in einer Anleitung zusammen fassen? Wäre für mich als Synology User zum testen auch sehr interessant.