OBS - ein neuer Player in der Serverlandschaft?

[BadSmiley]

Ich habe es nicht mehr weiter verfolgt. Sollte vom Duke nicht noch eine 3D-Version raus gebracht werden oder gibt es diese schon?

https://de.wikipedia.org/wiki/Duke_Nukem_Forever

[Alex]

Hallo OBS-Entwickler,

ich schaue mir aktuell Euren OpenBridgeServer (Nightly 32c74b2, in Proxmox auf einem NUC) etwas an und finde es beeindruckend, was Ihr bisher entwickelt habt - toll.

Im ersten Schritt würde ich den OBS dazu verwenden wollen, Informationen zwischen verschiedenen Welten (knx, onewire, mqtt) auszutauschen und ein paar Logiken einzubauen. owserver bzw. ein separater, externer mosquitto laufen bereits auf einem anderen PC und sind per Adapter in OBS eingebunden.

An einer Stelle stehe ich jedoch etwas auf dem Schlauch und bitte um Hilfestellung.

Aufgabe: Ein Onewire-Sensor liefert eine Temperatur, die auf eine KNX-GA und in ein MQTT-Topic geschrieben werden soll.
Unabhängig vom Lesezyklus des OneWire-Adapters soll der letzte Wert stets per MQTT-Topic und in der KNX-GA zur Verfügung stehen.

Ich hätte daher gedacht, dass bei dem OBS-Objekt bei den Adapter-Verknüpfungen folgende Eigenschaften sinnvoll sind:
Onewire: "direction": "SOURCE
MQTT: "direction": "DEST", "retain": true
KNX: "direction": "DEST", "respond_to_read": true

Damit wäre m.E. klar, dass OBS die Hoheit über den aktuellen Wert hat, diesen vom Onewire-Adapter liest und bei Änderung auf den MQTT- und KNX-Adapter schreibt.

MQTT-seitig wäre der letzte Wert wegen des Retain-Flags jederzeit lesbar.

KNX-seitig hätte ich erwartet, dass ich mit dem Flag "respond_to_read": true erreichen kann, dass der Wert jederzeit per KNX-Leseanfrage vom OBS erfragt werden kann. Leider ist es mir jedoch nicht möglich, dieses Flag "Antworte auf Leseanfragen "im Frontend zu setzen , wenn als Richtung "Schreiben (to adapter)" gewählt ist, da dann diese Checkbox nicht sichtbar ist.

Natürlich könnte ich im KNX-Binding die Richtung "BOTH" setzen, um die "Antwort auf Leseanfragen" auch anhaken zu können. Dies würde es jedoch erlauben, die Temperatur auch über KNX zu setzen, was in diesem Szenario nicht gewünscht ist.

Daher möchte ich fragen, wie bei einem Datenpunkt zu verfahren ist, über den der OBS durch den OneWire-Adapter die Hoheit hat und der nur zur KNX-Adresse bzw. MQTT-Topic geschrieben werden soll?

Vielen Dank, Alex

PS: Ein noch einfacheres Szenario mit derselben Fragestellung ergibt sich, wenn über MQTT Werte von Datenpunkten empfangen werden und diese einfach nach KNX weiter gereicht werden sollen, von dort jedoch nicht geändert werden können.

[gbglace]

Dies würde es jedoch erlauben, die Temperatur auch über KNX zu setzen, was in diesem Szenario nicht gewünscht ist.

Naja das KO muss auch Direction Source sein, weil sonst kann auch die Leseanfrage selbst nicht am virtuellen KO ankommen.

Mal schauen ob man da an der Adaptereinstellung noch etwas ändern kann, sodass ein Source-KNX-Objekt nur als Eingang für Leseanfragen genutzt wird und kein eingehender Datenwert dann in den OBS durchgereicht wird.

Bis dahin es dennoch so einrichten mit BOTH und halt in der ETS ganz normal darauf achten das es eben nur ein KO im Projekt gibt (jenes des OBS), welches für diese GA effektiv Werte sendet und alle anderen KOs nur Empfänger sind. Den Fehler kann Dir der OBS nicht verhindern, das noch wer anderes mit der GA Datenwerte auf den Bus sendet.

Ist das gewollt und nur der OBS soll diese anderen Werte nicht abnehmen, dann sind es meines Erachtens auch nicht die selben Daten-Informationen (Temperaturen) und es sollten nicht die selben GA benutzt sein.

Ein noch einfacheres Szenario mit derselben Fragestellung ergibt sich, wenn über MQTT Werte von Datenpunkten empfangen werden und diese einfach nach KNX weiter gereicht werden sollen, von dort jedoch nicht geändert werden können.

Wenn der Satz so schon fertig ist, ist es ja kein Problem, nur wenn da noch ein "sollen" ans Ende gehört und der OBS das regeln soll, dann ja ist es vergleichbar. Ansonsten wenn kein anderes Gerät am KNX mit der GA Datenwerte sendet ist es ja egal das der OBS potentielle Datenwerte via dem virtuellen KO mit der GA entgegennehmen kann.

Am besten ist es dafür einen Issue aufzumachen.

Du wünscht Dir also ein virtuelles KO das der Funktion der Flag-kombination K,L,Ü entspricht, du aber derzeit nur K,Ü oder K,S,L,Ü eingestellt bekommst?

[Alex]

Hallo gbglace,
hab vielen Dank, für Deine Antwort.

Du wünscht Dir also ein virtuelles KO das der Funktion der Flag-kombination K,L,Ü entspricht, du aber derzeit nur K,Ü oder K,S,L,Ü eingestellt bekommst?

Ja, ich denke das fasst mein Anliegen gut zusammen.

Probehalber habe ich mal in ein leeres ETS-Projekt einige Geräte eingefügt und finde die Kombination KLÜ tatsächlich bei diversen Kommunikationsobjekten, wie etwa Messwerten von Wetterstationen, Spannungsversorgungen, Tasterschnittstellen und Status-Objekten von Schaltaktoren. Die Kombination KLÜ scheint also nicht ganz ungewöhnlich zu sein.

Um dieses Verhalten nachzubilden, wäre es meiner bescheidenen Meinung nach sinnvoll, wenn man bei der KNX Adapter-Verknüpfung eines Objekts als 'direction: "DEST"' (Ü) und 'respond_to_read: true' (L) setzen könnte.

Dies hätte m.E. folgende Vorteile:
1. Sendet ein anderes KNX-Gerät *fälschlicherweise* auf der GA einen Wert, dann würden die anderen KNX-Geräte diesen Wert zwar erhalten, aber zumindest die interne Repräsentation im OBS (der ja eigentlich die Hoheit über die Information haben soll) würde nicht beeinflusst.
2. Es würde verhindern, dass eventuell verknüpfte Logiken innerhalb des OBS angestossen und ggf. weitere Aktionen ausgelöst werden.
3. Auf der Details-Seite des Objekts im Frontend würde man bei den "Adapter-Verknüpfungen" auf einen Blick sehen, dass der Wert von Onewire gelesen und auf KNX und MQTT nur geschrieben wird.

Bis dahin es dennoch so einrichten mit BOTH...

Ok, so werde ich es erst einmal machen, hab vielen Dank.

...und halt in der ETS ganz normal darauf achten das es eben nur ein KO im Projekt gibt (jenes des OBS), welches für diese GA effektiv Werte sendet und alle anderen KOs nur Empfänger sind. Den Fehler kann Dir der OBS nicht verhindern, das noch wer anderes mit der GA Datenwerte auf den Bus sendet.

Ist das gewollt und nur der OBS soll diese anderen Werte nicht abnehmen, dann sind es meines Erachtens auch nicht die selben Daten-Informationen (Temperaturen) und es sollten nicht die selben GA benutzt sein.

Würde ein anderes KNX Gerät Werte auf einer solchen Gruppenadresse senden, so wäre das klar ein Konfigurationsfehler und ist natürlich nicht gewünscht.

In der ETS lässst sich dies zumindest für andere KNX-Geräte leicht kontrollieren. Sollten aber andere 'Steuerungsgeräte' an KNX hängen (bsp. EibPC, SmarthomeNG, o.ä.), dann ist ein solcher Fehler nicht ganz so leicht zu erkennen. Es sollte natürlich trotzdem nicht vorkommen, ist mir aber bei der Migration solcher Verknüpfungen von anderen Systemen zu OBS schon passiert.

Von daher wäre es hilfreich, wenn der OBS sich gegen diese ungewollten Wertänderungen schützen könnte (Punkt 1 und 2) und dies auch im Frontend leicht erkennbar wäre (Punkt 3).

Viele Grüße, Alex

[starwarsfan]

Hallo miteinander

Hier noch der Link zum Thread für das neue Release 2026.8.0. Weiterhin viel Spass mit dem OBS!

[jensgulow]

Hi allerseits....mal eine Frage zum Verständnis: Ich habe einen Timberwolf-Server, welcher die 1-wire Kommunikation aktuell macht. Kann ich mit dem aktuellen OBS automatisiert an diese Daten ran, oder geht das nur, wenn ich den PBM direkt an den OBS anstecken würde.

[starwarsfan]

Hi

Das geht in deinem Fall nur indem Du den PBM mit dem OBS verbindest.

[gbglace]

bissl umständlich und per Medienwechsel wäre es , wenn du die 1-wire Werte im TWS auf MQTT sendest und der OBS das per Subscription in sich aufnimmt.

[jensgulow]

Danke für die Erklärung. Kein Problem - dann lasse ich erstmal alles so wie es ist. Komplettumbau ist mir noch nix. Der Wolf läuft ja noch.

[Sunshinemaker]

Moin,

Ich versuche mich grade ein bisschen an OBS. Die frage die ich habe: Ich habe auf dem TWS teils recht komplexe Custom-Logiken laufen. Könnte ich die auf den OBS migrieren? Also würde da funktionieren wenn man sie neu Schreibt? Und wenn ja gibt es schon eine Doku dazu?

[gbglace]

Die Logikmodule sollten auf Github beschrieben sein, da der ganze OBS eine gut dokumentierte API hat >> Kippe der KI Deiner Wahl den TWS Code rein, und dazu das Repo vom OBS und dann baut dir die KI die Logik in den OBS.

[Ing-Dom]

ich fange gerade an etwas mit obs herumzuspielen. Ziel: edomi Ablösung.
Ich betreibe recht intensives Logging was edomi ja immer zerstört hat.
Parallel hab ich schon influx am laufen mit telegraf.

jetzt wollteich das logging zentral über obs machen, stelle aber fest dass dadurch in influx alles anonym ist.. ich will da eigentlich auch mit data explorer und grafana ran, aber ohne name und alles.. wie habt ihr euch das gedacht?
kein szeanrio für externen zugriff auf die history ?

[Stanis]

Ich finde den Ansatz schon echt super. Mit dem Logikteil tue ich mich noch schwer.

[starwarsfan]

Hallo miteinander

Die Logik-Engine wird im kommenden Release diverse Verbesserungen erfahren. Wer mag, kann gerne schonmal in den Releasenotes stöbern.

[Ing-Dom]

ich hab mich daran versucht meine PV Wechselrichter per Modbus TCP / Sunspec einzulesen.
Grundsätzlich geht das, aber die Vielzahl der Register, dynamische Skalierungen und das exzessive Logging wenn die WR Nachts aus sind sind nicht ideal.

Was haltet ihr von einem SunSpec Adapter ? Hier kann man dann "Bulk" einlesen, dynamische Skalierungen anwenden und auch die Nicht-Erreichbarkeit besser handhaben.

Generell - wie stellt ihr euch das bei contributions vor? Direkt den PR? Vorher absprechen? Mit wem? Wo?