FHEM, KNX und Notify

Begonnen von MikeR, 30 April 2017, 16:04:39

Vorheriges Thema - Nächstes Thema

MikeR

Hallo,

ich muss zugeben, das mein Hauptgebiet eher EIB/KNX ist, als FHEM. Ich möchte FHEM primär als Gateway zwischen verschiedenen Welten und dem KNX nutzen.

<VORSPIEL ON>
Habe einen Raspberry mit KNXD der als Gateway/Master fungiert und mehrere weitere Raspis, die jeweils den Bridge-Head zu anderen Welten. z.B. einen im Keller mit einem PiFace zum Schalten, weil dort keine KNX-Leitung liegt (ETW im Mehrfamilienhaus), der per Devolo/Powernet angebunden ist, weil mir zwei KNX-Gateways für Kabel<->EIB-Powernet zu teuer waren.Sowie einige weitere.
<VORSPIEL OFF>
...und einen mit einem ZWave-Modul. Der "Hinweg" also ZWave-Raspi zum KNX-Master funktioniert. Auch der im Keller usw. ABER beim Versenden eines KNX-Telegrammes zu einem der Client-Raspis geht nur der im Keller alle anderen bekommen davon nichts mit.

Es läuft auf jedem der Client-Raspis ein TUL-Device, das jeweils gleich konfiguriert ist, bis auf die physikalische (KNX)Adresse, die habe ich fortlaufend in einem freien Bereich vergeben. Die Definition mit Attributen sieht also so aus:

   define tul TUL knxd:192.168.1.210 1.1.23x
   attr tul do_not_notify 0
   attr tul room Flur,_EIB/KNX
   attr tul useEIB 0


Auf dem ZWave-Client kann ich mit

   knxtool vbusmonitor1 ip:knx-master | grep 5/6/7

sehen das die KNX-Telegramme, um die es geht, auch beim Master ankommen und vom KNXD "rausgerückt" werden nur eben im FHEM tul des Clients nicht.

Der KNXD auf dem KNX-Master hat folgenden Konfiguration:

   /usr/bin/knxd --Tunnelling --eibaddr=1.1.254 --client-addrs=1.1.230:24 --Name=MasterKNXD
   --Server=239.1.2.3:3671 --layer2=tpuarts:/dev/ttyKNX1


Der geänderte Port (3671) im KNXD-Server-Parameter rührt daher, das ich noch eine weitere kommerzielle KNX-IP-Schnittstelle im System habe, dies aber nicht mit den Raspberries "belasten" wollte. Aber so wie ich das verstanden habe funktioniert ja die Kommunikation vom (Soft)-TUL des Clients auf den Master eh anders. Spielt also keine Rolle.

Wie gesagt so ganz rudimentär  funktioniert auch alles. Nur eben die KNX-Telegramme kommen nicht beim ZWave-FHEM-Raspi an .

Hat da jemand vielleicht einen Tipp für mich, oder fehlt noch Information?

Liebe Grüße aus Wiesbaden
Mike

MikeR

Meine Definition für ein KNX Objekt und das zugehörige Notify sehen so aus:

   define Test_EinAus KNX 5/6/52:dpt1
   attr Test_EinAus IODev tul
   attr Test_EinAus answerReading 1
   attr Test_EinAus room _EIB/KNX
   
   
   define n_Test_EinAus_Changed notify Test_EinAus:*
   {
      fhem( "set dummy $EVENT" );
   }
   attr n_Test_EinAus_Changed room _EIB/KNX


Hoffe jetzt hab ich an Infos alles zusammen.

Ich weiß halt auch nicht so genau ob mein Problem eher auf der FHEM oder auf der knxd Seite liegt.

Ach so: Meine Versionen:
   FHEM 12691 (???)
   knxd 0.12.15


Würde mich über jeden Tipp freuen, da ich, was FHEM angeht eher Newbie bin.

Gruß
Mike

Andi291

Servus!

Ich persönlich arbeite auch mit mehreren FHEM-Instanzen, hab aber auf jeder Maschine einen eigenen KNXD am laufen. Die laufen (wie bei Dir) alle im Multicast-Betrieb und telefonieren zum IP-Gateway.

Mir sind aktuell keine Konfigs bekannt, an denen mehrere TUL's remote auf den gleichen KNXD zugreifen. Und schon gar nicht auf non-Default-ports.
Deshalb würd ich damit Schritt für Schritt beginnen.

So ganz habe ich Deine Konfig noch nicht durchschaut.
Ich würd obige Variante vorschlagen oder mal mit HelloWorld anfangen:
Master auf "normal" (3670) und Gerät für Gerät die angeschlossenen TUL's in Betrieb nehmen.

Grüße, Andi

P.S.: Vielleicht malst Du mal ein Bild Deiner Konfig...

MikeR

OK, hier ein Schaubild. Hab's als Anhang gemacht, weil ich nix gefunden habe, wie man das hier einfügt.  :-[


Ich habe für verschiedene "Verwendungen" mehrere Raspberries mit FHEM und einen Raspberry mit knxd und einem TPUART.
Davon "logisch" getrennt noch einen IP-Router, den ich ausschließlich für meinen Gira Homeserver und die ETS5 benutzen möchte.


MikeR

Das mit dem geänderten Ports war Quark!

Evtl. ist mir das IP-KNX-Routing auch noch nicht völlig klar. So wie ich es verstanden habe geht das doch über Multicasts.
Da ich wie im Bild oben die logische Trennung haben will, habe ich den KNXd auf eine andere Multicast-Adresse gelegt, die nicht die Standardadresse, aber sehr wohl eine in der Spezifikation erlaubte Adresse ist. Weil auf der Standard-Multicast-Adresse ja schon der IP-Router läuft.

So ganz klar ist mir noch nicht was im FHEM die Definition define tul TUL knxd:192.168.1.210 1.1.234
bedeutet.
Die IP ist klar, aber welches Protokoll wird denn benutzt?
Dem KNXd sage ich ja nur benutze den TPUART und stelle den Server auf Broadcast 239.1.2.3:3671 bereit. Wobei ich letzteres je nach Kommunikation zwischen FHEM und knxd (Frage vorher?) gar nicht brauche, aber im knxd ja immer zwei Interfaces brauche...

smurfix

ZitatDer geänderte Port (3671) im KNXD-Server-Parameter
Äh, der Port ist derselbe. Nur die Multicast-Adresse nicht. Ist aber egal, weil du eh nicht Multicast-routest.

KNX wird entweder über Multicast auf die Leitung geblasen (-R) oder über UDP direkt an einen Server geschickt (-T).

Du hast eh zwei Interfaces. Nämlich deinen tpuart und den Tunnelserver. (Eigentlich sogar beliebig viele – weil seit Version 0.12 jeder Client, der sich mit dem Server verbindet, ein eigenes Interface ist.)

Die diversen FHEMs haben alle dieselbe Konfig, abgesehen von der knx-Adresse (die im Übrigen irrelevant ist, weil sie die beim Tunneln vom knxd zugeteilt bekommen)?

Als Nächstes solltest du wohl mal im knxd (welche Version?) Logging einschalten ...

Andi291

Moin!

Ich würde keinen separaten TPUART einsetzen und an jedem Raspi einen eigenen KNXD im Multicastbetrieb einrichten.

Konfig der KNXD (xxx entspricht der Geräteadresse):
KNXD_OPTS="-e 1.0.xxx -c -b ip:224.0.23.12"
oder
KNXD_OPTS="--allow-forced-broadcast -e 1.0.xxx -c -b ip:224.0.23.12"

FHEM-Config:
define knxd TUL knxd:127.0.0.1

Alternativ reicht Dir auch ein KNXD. Den würd ich aber in jedem Fall per Multicast, und nicht per TPUART anbinden. Entsprechend ist in der FHEM-Config nicht die 127.0.0.1 zu verwenden, sondern die IP des knxd.

Grüße, Andi

smurfix

ZitatAlternativ reicht Dir auch ein KNXD
Definitiv. Wozu braucht man mehrere, wenn man nur eine Hardware bedient? wenn das Ding tot ist, geht eh nix.

Das Problem mit Multicast und mehreren knxd-Prozessen ist, dass KNX-Hutschienen-Schnittstellen sich gerne mal überfordert fühlen, wenn mehrere Clients gleichzeitig was vom Bus wollen und zB nach Reboot jeder 20 read-Telegramme absendet.

Daher empfehle ich einen aktuellen knxd. Der taktet die Multicastpakete entsprechend.

Ob du ihn mit Multicast oder via TPUART mit dem Bus reden lässt, finde ich zweitrangig. Hauptsache nur eines von beiden :-P
Ich würde ihm auch keine andere Multicastadresse verpassen, denn ohne -R ignoriert er die Pakete sowieso.

MikeR

#8
Also könnte ich bei meinem KNXd-Gateway, was ja nur zwischen den FHEM-Client-Raspberrys und dem TPUART "vermittelt" bei meinem Parametern:

   /usr/bin/knxd --Tunnelling --eibaddr=1.1.254 --client-addrs=1.1.230:24 --Name=MasterKNXD
   --Server=239.1.2.3:3671 --layer2=tpuarts:/dev/ttyKNX1


das

   --Server=239.1.2.3:3671

weglassen, weil ich ja gar kein Multicast brauche. Richtig?

Nachtrag;
Ach so, meine knxd Version ist 0.12.15
"Logging" bedeutet den Parameter --error=x auf welchen sinnvollen Wert zu stellen und dann stdout und stderr in eine Datei umzuleiten?

smurfix

Nein, --Server kannst du nicht weglassen. Multicast aktivierst du mit --Router. Du kannst aber die Argumente hinter --Server weglassen. --Server aktiviert die vorherigen -D, -R und -T-Optionen auf der Multicastadresse und dem Port, den man dahinter angibt. (Oder dem Default.) (Der Tunnel-Client redet natürlich nicht mit der Multicastadresse, aber -S braucht man trotzdem. Mit v0.14 und dessen Konfiguration via .ini-Datei ist das Ganze ein bisschen logischer strukturiert.)

Nein, du leitest stdout/stderr nicht in eine Datei um. Du startest den knxd wie gewohnt via systemd und lässt dir das Log mit journalctl ausgeben.

MikeR

Erstmal sorry für die späte Antwort, war geschäftlich unterwegs und am WE auf Familienfeier...

Es ist schon seltsam, aber ich hab vom KNXd nun die aktuelle Version (0.14.13) übersetzt und installiert. Und was soll ich sagen, es funktioniert. Alle Client Raspberries können nun mit dem Master mit dem TUL kommunizieren, und zwar alle bidirektional.

Entweder wurde da von meiner v.12 ausgehen ein Bug behoben, oder ich hatte eine irgendwie "schräge" Version (auch selbst kompiliert, keine dubiose Quelle) erzeugt.

Bin auf jeden Fall super dankbar für die Hilfestellungen!!!

Liebe Grüße
MIKE