Schleife bei 2 definierten KNX-Geräten?

[JoeALLb]

Hallo,

ich scheine ein Verständnisproblem zu haben.
Ich habe einen knx-Bus, den ich über ein Device in fhem empfange. Das funktioniert soweit!
Dann habe ich jedoch eine Heizung, die einen EIGENEN KNX-Bus hat, also nicht verbunden ist.
Diese hat ein IP-Gerät enthalten und sendet KNX-Telegramme über dieses IP-Interface.

die IP des RPI ist: 10.1.1.30
Die der Heizung ist 10.1.1.29

2 Devices, die ich FHEM angelegt habe:

Code Auswählen Erweitern

define KNX TUL eibd:10.1.1.30 1.1.255
und zum Auslesen der Heizung

Code Auswählen Erweitern

define HEIZUNG TUL eibd:10.1.1.29 1.1.254


KNXD-Optionen

Code Auswählen Erweitern

KNXD_OPTS="-e 1.1.251 -u /tmp/eib -D -T -R -S -b tpuarts:/dev/TUL"

Nun, wenn ich auf dem KNX-HEIZUNG etwas empfange, scheint sich fhem aufzuhängen, der eventmonitor spuckt jedoch noch
jede Menge Heizungspakete aus.

Wenn ich knxd auf das hier ändere

Code Auswählen Erweitern

KNXD_OPTS="-u /tmp/eib -b ip:"
habe ich die Schleife nicht....
Ich möchte aber per ETS5 drauf zugreifen und möchte es deshalb als Multicast laufen haben....


Konfiguriere ich mir damit eine Schleife?

[Andi291]

Abend!

Das kann nicht gehen - die TUL ist nicht Multiinstanzfähig. Zum Koppeln der Busse empfiehlt sich ein Linienkoppler. AN einer FHEM-Instanz kann jedenfalls nur ein Bus hängen.

Sorry dafür...

Grüße, Andi

[JoeALLb]

Das kann nicht gehen - die TUL ist nicht Multiinstanzfähig. Zum Koppeln der Busse empfiehlt sich ein Linienkoppler. AN einer FHEM-Instanz kann jedenfalls nur ein Bus hängen.

Danke für die Antwort, aber zum Verständnis: Warum benutze ich in diesem Beispiel den TUL mit mehreren Instanzen?
In meinem Verständnis benutze ich das KNX-Modul innerhalb FHEM mit 2 Instanzen, der TUL wir nur von knxd 1x verwendet, oder? (für den ersten Fall).
Im zweiten Fall wird ja direkt zu einem externen KNX-IP Gateway verbunden und von dort die Daten empfangen.
In diesem Fall empfange ich Daten von 1xBus und 1x IP-interface.

Für letzteren Fall ist doch kein TUL notwendig, oder?
Wenn ja, wird er in diesem Fall vom KNX-Modul aus FHEM-heraus angesteuert, denn im 1. Fall wird er ja vom knxd angesteuert...

[Andi291]

Abend!

Du definierst innerhalb einer FHEM-Instanz zwei TUL-Instanzen (Heizung und KNX). Das wird ab den unteren Schichten nicht mehr funktionieren.
Was gehen KÖNNTE ist, wenn Du zwei FHEM-Instanzen aufmachst und die Querkommunikation mit FHEM-zu-FHEM-Kommunikation umsetzt.

Theoretisch wäre es auch machbar, die TUL Multiinstanzfähig zu machen, aber das ist ein Aufwand, den ich momentan nicht abschätzen kann. Kann wenig sein, aber auch ein Kapitalumbau.

Das Problem liegt hier primär auf der Lesen-Seite. Hier ist weder die TUL noch das Modul KNXD sauber. Ganz konkret wird TUL_Read von FHEM aufgerufen und mit einer Menge an Nachrichten versorgt. Die erstaufgerufene TUL-Instanz reicht alle (!) Telegramme ans Modul KNX durch (kann nicht unterscheiden, wer der Adressat ist). Im Modul KNX werden dann widerum alle Nachrichten auf alle potentiellen Adressaten zugeordnet.
Kriegst Du also die Gruppenadresse 1/1/1 vom Bus Heizung, aber die TUL für den KNX wird zuerst aufgerufen, wird die Adresse 1/1/1 versucht, auf die mit KNX assoziierten devices zu Mappen.

Wenn Du fit in Pearl bist:
FHEM ruft TUL_Read ruft TUL_SimpleRead auf
FHEM ruft KNX_Parse auf
dann passiert: foreach my $deviceName (keys %{$modules{KNX}{defptr}})

Verstehst Du meine unpräzisen Erklärungsversuche?

Grüße, Andi 

[JoeALLb]

Hallo Andi,

danke für die Erklärung! Ja, ein bisschen verstehe ich Perl, und verstehe schon grob, was du schreibst.
Um bei Deinem Beispiel zu bleiben: Wenn es die Adresse 1/1/1 jedoch nur am Bus "Heizung" gibt, versucht er es dann nachdem er bei KNX nicht fündig geworden ist,
dort nochmal, oder landet das Telegramm dann im Nirvana? Es nochmal am anderen Bus zu versuchen würde ja ausreichen, da ich den Heizungsbus (erstmal) ausschließlich auslesen, nicht schreiben möchte.
Die Adressen kann ich definieren, ich habe bewußt 1/x/x für den Bus KNX genommen, und 2/x/x für den Heizungsbus. Wenn ich es recht verstehe wäre es am einfachsten,
für jede Instanz einfach festzulegen, für welche Adressen sie zuständig ist. Genau das, wofür eigentlich das IOdevice gedacht (aber im Moment nicht implementiert) ist, oder?

Hintergrundfrage: Wenn ich die Busse nun mit fhem oder was auch immer koppeln wollen würde:
Wäre es dann am besten, die 2/x/x Telegramme vom Heizungsbus auf den KNX-Bus 1:1 zu spiegeln (also neu zu senden) oder sollte man dafür dort eine eigene
Adresse im 1/x/x-Bereich definieren? Mein technisches Verständis lässt mich vermuten, dass das erste leichter ist wie das zweite... ohne es zu wissen.
Das ist im Moment nicht mein Vorhaben... ich würds nur gerne verstehen! Danke!

[Andi291]

Hallo,

wenn Du heute sicherstellen kannst, dass die Gruppenadressen und Geräteadressen (letztere sind zweitrangig und dienen nur Deiner Logik), in beiden Linien unterschiedlich sind, dann passt alles und Du kannst das von Dir angedachte Konstrukt ohne Probleme verwenden.

Wenn dem allerdings so ist (Also Gruppenadressen bereits getrennt), kannst Du auch die beiden Linien mit einem Strunzdummen Linienkoppler (Ebay 50€) gleich vereinen und nur einen Zugang schaffen. Das nimmt (unnötige) Komplexität raus...

Grüße, Andi

P.S.: Genau das ist übrigens der Sinn des Linienkonzepts - galvanisch getrennte Busse zu einem logischen Konstrukt vereinen. Schau mal hier:
https://www.knx.org/media/docs/downloads/Marketing/Flyers/KNX-Basics/KNX-Basics_de.pdf

[JoeALLb]

Hallo Andi, danke.

Danke für die Info!
Ja, die getrennten Adressen kann ich sicherstellen, ein Linienkoppler geht bei mir nicht, da ich auf einer Seite keinen Zugang zum KNX-Bus direkt habe.
Ich habe lediglich Zugang zum IP-Konverter.

[JoeALLb]

... die TUL ist nicht Multiinstanzfähig.

Nochmal eine Rückfrage: Würde es funktionieren, wenn ich die TUL.pm-Datei kopiere, umbenenne und als TUL2 ein eigenes Device einbinde?
(Natürlich mit ggf. noch ein paar weiteren Anpassungen im Code?)
Hätte ich dadurch 2 funktionierende Instanzen?

[Andi291]

Nein, das wäre zu einfach. Kannst mal versuchen, glaub aber nicht, dass es hinhaut.

Andersrum:
Welche IP-Interfaces nutzt Du gleich wieder?

[JoeALLb]

Das kenne ich gar nicht, denn die Heizung hat einfach direkt eines eingebaut... und darüber bekomme ich die Heizungsdaten übermittelt.
Quasi ein geschlossenes System wo ich anders nicht ran darf.
Mein Versuch mit dem Emfangen der Daten über fhem hat jedoch bestens geklappt, lediglich das Senden über knxd machte dann schwierigkeiten....

[Andi291]

Naja, dann mal raus - welche Heizung, und welches Interface ist an der andere nSeite?

[JoeALLb]

Die Heizung ist eine Weider, und bietet mir lediglich einen RJ45-Stecker. Der Rest ist alles fest eingebaut, da müsste ich mal aufschrauben...
Hinter dem System ist wohl ein Debian-System in verwendung, ob das knxd verwendet, kann ich nicht sagen....

[Andi291]

Dann schraub mal, bitte.
Wenn Du einen vernünftiges IP-GW hast, kann man das auch als Linienkoppler auf Ethernet-Ebene konfigurieren. Wenn ein Raspi als Zugang verbaut ist, würd ich auf ein IP-GW wechseln. Dann hast Du einen Bus mit zwei Linien und bist sauber.
Wenn ich nach Wieder Google, find ich eigentlich nur ein Loxone-GW. Die Loxone widerum KÖNNTE die Umsetzung auf KNX machen. Wenn dem so ist, ist die Loxone diskret angebunden - hier könnte dann widerum ein "günstiger" Linienkoppler zum Einsatz kommen.

Mal mal bitte ein Bild und identifiziere alle Komponenten auf beiden Seiten - sonst kann ich nicht wirklich helfen.

Grüße, Andi

[JoeALLb]

Sorry, da ist ein Siegel-Kleber drauf, den öffne ich nicht. Es ist auch nicht meine Heizung, sondern die für die gesamte Hausanlage, ich bin also nicht Eigentümer.
Ich werde wohl doch einen zweiten RPI aufsetzen, um die Werte zu empfangen und an fhem weiterzugeben....

Vielleicht klappts ja irgendwann doch mit der mutlinstanz von TUL ....

Danke jedenfalls!