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