Beolink Gateway über KNX über IP-Symcon an Homematic

Hallo zusammen,
in meinem derzeitigen Bauprojekt wurde eine komplette Homematic Haustechnik für Licht und Klima eingebaut. Als Multiroom-System für Audio und Video kommt das Bang & Olufsen Beolink zum Einsatz. Um aus der BeoLink-App auch die Haustechnik zu steuern, habe ich das Beolink Gateway erworben. Dies soll nun über KNX an den IP-Symcon Server angebunden werden und die Aktoren der Homematic steuern. Gemäß der Dokumentation habe ich beide Geräte über LAN nicht verbunden bekommen. Das Beolink Gateway ist übrigens der Nachfolger vom Masterlink Gateway. Beide unterstützen von Haus aus KNX.

Hat jemand eine ähnliche Konfiguration im Einsatz und kann Tipps zur Inbetriebnahme geben? Mit der Homematic bin ich bestens vertraut, während sich meine KNX Kenntnisse noch in Grenzen halten.

Meine nächste Frage wäre dann, wenn die Verbindung beider Komponenten klappt, wie die Adressierung funktioniert, da ich keine Geräteliste aus einer KNX Programmierung habe.

Wie erfolgt das Routing vom KNX auf die Homematic, inklusive der Rückmeldung des Aktorzustandes?

Frage über Fragen…

Freue mich auf Antworten.

Hast du IP-Symcon?
Hast du ein KNX Gateway?
Hast du dein KNX Gerät mittels ETS programmiert?

paresy

Hallo beolink … so wie ich das sehe wird das eine sehr teure und komplizierte „Verbindung“. Du würdest nur einen KNX-Bus aufbauen um an IPS zu koppeln. Du solltest bei B&O nachfragen ob das nicht direkt zu IPS oder Homematic geht.

Hallo,
ich habe IP-Symcon in der Version 3.4. Die Idee war eigentlich folgende:
IP-Symcon sollte die Homematic-Komponenten dem Beolink-Gateway über iKNX sprich über LAN mit KNX Protokoll bereitstellen, da KNX über LAN vom Beolink Gateway nativ unterstützt wird. Dabei sollte das IP-Symcon quasi ein KNX/EIB Gateway simulieren, auf das das Beolink Gateway zugreift. Dem zu Folge gibt es keine KNX Programmierung. Alternativ unterstützt das Beolink Gateway folgende Protokolle:

Lauritz Knudsen, IHC-Schneider, LexControl
KNX - EIB
Clipsal
Legrand - Bticino
SmartHouse
Lutron

  • Lutron HomeWorks Interactive
  • Lutron Homeworks QS - Radio Ra2 - Grafik QS
  • Lutron Graphic Eye
  • Lutron Radio Ra
    Vantage
    Dynalite
    Conson XP
    Custom Strings
    Velux
    Philips Hue

IP-Symcon ist auch nur ein KNX „Nutzer“. Als Server brauchst du ein KNX IP Gateway. Theoretisch kannst du also ein KNX Gateway nutzen, welches gar kein KNX dran hat. Die Vorstellung das zu tun ist aber ganz schön ekelig :smiley: Würde aber zum Ziel führen, da du im B&O einfach Adressen angibst, welche du wiederum in IP-Symcon abgreifen könntest.

Schau mal hier.
http://mlgw.bang-olufsen.dk/source/documents/mlgw_1.90e/ML%20Gateway_Installation%20Guide%201v9.pdf

paresy

Hallo,
genau diese KNX Gateway Funktionalität wollte ich im IPS abbilden. Das Beolink Gateway kann auch Custom Strings verarbeiten. Gibt es eine Befehlsliste für IP-Symcon, die ich im Beolink Gateway implementieren kann?

Das klingt mir so pauschal erstmal wie der bessere Weg. Klingt so als wenn man das evtl. mit einem TCP Client Socket ansprechen könnte. Hast Du da mehr Infos zu?

EDIT: Hab mal selbst gegoogelt und im Installationshandbuch zum Beolink folgendes gefunden:

Custom strings
The Custom strings driver is intended to enable limited communication with unsupported home automation systems. Use of this driver requires
knowledge of the protocol for the external system. ML Gateway supports up to 4 custom strings drivers.
Resources
This driver is based on matching incoming byte strings from the external system, and sending back byte strings to it. Therefore resources are
generic strings used for matching and for sending to the system.
There are 3 parameters to each resource:

  • Name for the resource.
  • Whether it should be available for matching (INPUT), for sending (OUTPUT), or for both (BOTH).
  • A generic character string.
    In order to allow arbitrary byte values to be defined, the following coding is used:
  • Any character except for backslash () will be given it’s corresponding vaule. Non-ASCII (international) characters are interpreted as Unicode UTF-8
    byte sequences.
  • Backslash is used as an escape character, which gives special meaning to the character o characters that follow:
    \ (double backslash) is interpreted as a single backslash.
    \r is interpreted as a carriage return character (0x0D). It will be immediately redisplayed as \0D.

is interpreted as a newline character (0x0A). It will be immediately redisplayed as \0A.
" is equivalent to a double quote ("). This notation is required for import/export of resources in text form.
\xx (where x is a hexadecimal digit [0-9, a-f, A-F]) is interpreted as a hexadecimal byte value. E.g. \0A is equivalent to
.
Any non-printable or non ASCII character entered by the user will be redisplayed as a hexadecimal sequence. Illegal or truncated escape sequences
will be marked as errors.
In order to ease the editing and sharing of string definitions, the list of resources can be exported to a text file, and imported back from a text file.
Imported resources can replace all defined resources, or be appended to the current list.
Continues on next page…
Supported devices 36
The format for the text file is specified below. This format is compatible with the standard CSV or TSV (comma / tab separated values) formatting,
so it can be processed by spreadsheet software, text editors or command-line utilities.

  • Lines starting with # will not be interpreted.
  • Each valid line corresponds to one resource.
  • Lines must have at least 2 quoted fields. A quoted field consists of a starting double quote character (") followed by escaped string data as defined
    above, followed by an end double quote character.
  • If a line contains only 2 quoted strings, they will be interpreted as name and match/command string, and the resource type will default to BOTH.
  • If the line contains at least 3 quoted strings, the third will be interpteted as the type. Accepted values are uppercase I for input, uppercase O for
    output, and uppercase B for both. Defaults to both.
  • Extra quoted fields, as well as any non-quoted data will be ignored.
  • Lines with no quoted fields will be ignored.
    Events and commands
    Resources marked for input (or both input + output) will be searched for in all incoming data. As soon as a match is found, the corresponding
    event will be generated and search will continue after the match. If the incoming channel becomes idle, then all partial matches will be discarded.
    Also, whenever the channel is connected (or reconnected), a special CONNECT event will be generated in case some session-setup is needed.
    Commands are all resources marked as output (or both input + output) that can be transmitted to the channel.
    TCP connection maintenance (read this section if you experience periodic TCP reconnections)
    In order to rapidly detect broken TCP connections, MLGW uses the standard TCP Keepalive probes mechanism: when a TCP connection is idle,
    probe packets are sent periodically over the connection and an acknowledge is expected. The probe is an empty TCP packet with the request for
    acknowledge flag set.
    There are products with non-compliant TCP implementations which do not respond to these acknowledge requests. In such cases, MLGW will
    detect a broken TCP connection and reconnect. This may happen as frequent as every 20 seconds if there is no other data on the connection.
    If you experience this problem, then you must somehow force some data to be sent back to MLGW periodically, so as to keep the channel active.
    For example, you can set up a scheduler loop to send a status request to the 3rd party product, or a ping/pong message. On command-line based
    protocols that echo all characters typed, probably sending a carriage return character is enough for getting data back to MLGW.
    What to do strongly depends on the protocol of the 3rd party system.

Das klingt mir in der Tat nach einem Custom IP Interface.
Das würde ich benutzen, ist aber nicht trivial und ich hab leider keine Zeit zu helfen. Aber vlt. findet sich ja jemand?

Das Gateway kann auf einem beliebigen Port eine Verbindung mit einem anderen Netzwerkgerät herstellen. Für die Bedienung können im Gateway Dimmer, Taster oder Temperaturregler angelegt werden. Bei Bedienung wird dann vom Beolink Gateway der gewählte Custom-String abgeschickt. Weiter kann zur Zustandsübermittlung von Aktoren auf bestimmte Befehle gewartet werden.

Ja, das ist genau das was Du brauchst. Vergiss das mit dem KNX-Gateway. :slight_smile:

Leg Dir mal eine TCP Client Instanz an und trag IP und Portnummer Deines Beolink ein. Dann schick einfach mal einen Custom String. Der sollte nun bei der Instanz im Debugger auftauchen.
Dann kannst Du darauf entsprechend reagieren (Deine Homematic-Aktoren steuern).

D. h. ich kann mir meine eigenen Befehle bauen?

So liest sich das für mich, ja.