Support für BiDiB-Distributed (Verteilte Steuerung)

Was ist BiDiB-Distributed

BiDiB-Distributed ist eine Erweiterung des BiDiB-Protokolls, um Geräte wie Handregler oder Stellpulte in ein bestehendes BiDiB-System einzubinden. Nachfolgend sind Message-Abläufe beschrieben, welche die Anwendung in einigen Situationen verdeutlichen sollen.

Target-Mode BIDIB_TARGET_MODE_BOOSTER

Ein Gastknoten möchte eine Subscription auf alle Booster-Knoten im System machen. Dazu kann der Target-Mode BIDIB_TARGET_MODE_BOOSTER verwendet werden. Die MSG_GUEST_REQ_SUBSCRIBE wird vom Gastgeber mit einer MSG_GUEST_RESP_SUBSCRIPTION pro Booster-Knoten im System beantwortet. In der Antwort wird die Knoten-ID des Booster-Knoten mitgeliefert, welche der Gast für die weitere Addressierung verwenden kann. Die Anzahl der zu erwartenden Antworten wird durch MSG_GUEST_RESP_SUBSCRIPTION_COUNT mitgeteilt. 


>> MSG_GUEST_REQ_SUBSCRIBE MODE_BOOST Bit 11 = 1

<< MSG_GUEST_RESP_SUBSCRIPTION_COUNT MODE_BOOST 3
<< MSG_GUEST_RESP_SUBSCRIPTION MODE_BOOST IdNode1 Result = 0 SUB = 0 8
<< MSG_GUEST_RESP_SUBSCRIPTION MODE_BOOST IdNode2 Result = 0 SUB = 0 8
<< MSG_GUEST_RESP_SUBSCRIPTION MODE_BOOST IdNode3 Result = 0 SUB = 0 8

Falls kein Booster im System gefunden wurde, wird die MSG_GUEST_RESP_SUBSCRIPTION_COUNT mit dem Count Parameter gesendet. 


>> MSG_GUEST_REQ_SUBSCRIBE MODE_BOOST Bit 11 = 1

<< MSG_GUEST_RESP_SUBSCRIPTION_COUNT MODE_BOOST 0

Um alle Booster-Knoten einzuschalten, kann die MSG_BOOST_ON Message mit dem gesetzten Broadcast-Flag verwendet werden. Wenn diese Message an den __Interface__-Knoten gesendet wird, werden alle Booster eingeschaltet. Im nachfolgenden Beispiel hat der __Interface__-Knoten die IdNode3. Die Status-Meldungen aller 3 Booster im System werden über MSG_GUEST_RESP_NOTIFY an den Gast gemeldet. 


>> MSG_GUEST_REQ_SEND MODE_UID IdNode3 BOOST_ON (mit Broadcast)

<< MSG_GUEST_RESP_NOTIFY MODE_UID IdNode1 BOOST_ON STATE_ON
<< MSG_GUEST_RESP_NOTIFY MODE_UID IdNode2 BOOST_ON STATE_ON
<< MSG_GUEST_RESP_NOTIFY MODE_UID IdNode3 BOOST_ON STATE_ON

Target-Mode BIDIB_TARGET_MODE_TOP

Falls das OpenDCC IF2 als Interface-Knoten verwendet wird, muss vor dem Senden der MSG_BOOST_ON eine Subscription auf den Interface-Knoten gemacht werden. Dies ist mittels Target-Mode BIDIB_TARGET_MODE_TOP möglich. Anschliessend kann die MSG_BOOST_ON Message an den Interface-Knoten gesendet werden.

Thema "Additive Subscription"

Ursprünglich sollten keine additiven Subscriptions möglich sein, d.h. jede MSG_GUEST_REQ_SUBSCRIBE hätte die bestehende Subscription überschrieben (weiterhin gesetzte Bits wären natürlich übernommen worden). Dadurch wäre die nachfolgend beschriebene Ausgangslage nicht gut lösbar gewesen.

Ausgangslage:
Als Gastgeber habe ich für jeden Gast, eine UID-Liste, der UID's am Bus mit Bitfeld aus sub_down und sub_up speichere. 3 x Knoten mit Accessories. Davon ist auch ein Booster. Dann kommt eine Subscription von Gast 1: 


>> MSG_GUEST_REQ_SUBSCRIBE BIDIB_TARGET_MODE_ACCESSORY 0x00 0x80 (Accessory Upstream)

<< MSG_GUEST_RESP_SUBSCRIPTION_COUNT BIDIB_TARGET_MODE_ACCESSORY 3
<< MSG_GUEST_RESP_SUBSCRIPTION BIDIB_TARGET_MODE_ACCESSORY  0x01 0x00 0x80
<< MSG_GUEST_RESP_SUBSCRIPTION BIDIB_TARGET_MODE_ACCESSORY  0x01 0x00 0x80
<< MSG_GUEST_RESP_SUBSCRIPTION BIDIB_TARGET_MODE_ACCESSORY  0x00 0x00 0x80

Damit habe ich dann in der Knotenliste drei Einträge: 


  0x00 0x80
  0x00 0x80
  0x00 0x80

Da der Gast den Knoten-Baum nicht kennt, aber auch die Booster-Upstream-Messages haben will, schickt er: 


>> MSG_GUEST_REQ_SUBSCRIBE BIDIB_TARGET_MODE_BOOSTER 0x00 0x08 (Booster Upstream)

Antwort: 


<< MSG_GUEST_RESP_SUBSCRIPTION_COUNT BIDIB_TARGET_MODE_BOOSTER 1
<< MSG_GUEST_RESP_SUBSCRIPTION BIDIB_TARGET_MODE_BOOSTER  0x01 0x00 0x08

Aber der Eintrag in der Tabelle hätte die Accessory-Subscription verloren. 


  0x00 0x80
  0x00 0x08
  0x00 0x80

Thema "Vorkonfigurierte Subscription"

Unter dem Begriff Vorkonfigurierte Subscription wird die persistente Speicherung von Subscriptions im Gast-Knoten definiert. Der Gast-Knoten registriert nach dem Start für jede vorkonfigurierte Subscription eine Subscription beim Gastgeber. Die Subscription muss dann zwingend mit dem BIDIB_TARGET_MODE_UID angelegt werden, damit der Gastgeber für nicht vorhandene Knoten "vormerken" kann.