Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[wintermute]

Ich finde ein Forum ist auch dazu da, dass man einem Blinden mal einen Schubs gibt...

Blinde schubsen? *SCNR*

Da ich um EDOMI ja ohnehin nicht rumkommen werde - oder alternativ an meinem HS sterbe - mache ich mir grad Gedanken drum, wie und wo ich am sinnvollsten einen eibd integriert bekomme, den EDOMI dann zum tunneln benutzen kann. Ich hab zwar das CG hier und man könnte das auch auf nem Pi oder so realisieren, ich möchte aber so gut es geht auf weitere Hardware verzichten - besonders wenn es darum geht etwas wie die Wago durch einen Pi zu ersetzen...
Ich bin zwar die nächsten Tage berufsbedingt ausgelastet, aber das kann (zumindest für mich) nicht das letzte Wort gewesen sein. Pah!

gruesse :: Michael

[SeatSLF]

@Wagoklemme: das graue ist ein Request, das grüne die Antwort, das weiße ist der normale Busverkehr.
Das reine ACK siehst du so nicht.

[WagoKlemme]

Blinde schubsen? *SCNR*
gruesse :: Michael

Du weisst schon wie ich das gemeint habe !

CG ?

Eine Wago durch einen Pi ersetzen, ist ungefähr so wie einen Porsche gegen einen Dacia zu tauschen - ist auch ein Auto.

Ich habe, wie vorher bereits erwähnt, einen BeagleBone mit cape von Robert, das ich im Moment per IP und Smarthome.py (und knxd) auf die Wago (Router) zugreifen lasse wie Edomi es macht. Funktioniert perfekt und Modbus TCP, 1-wire .. geht auch gut.
Aber das nützt mir nichts, da 1. der BeagleBone 32Bit ist und zweitens die Wago erstmal weiterarbeiten muss.

Wie könnte also eine Lösung aussehen ?

[WagoKlemme]

@Wagoklemme: das graue ist ein Request, das grüne die Antwort, das weiße ist der normale Busverkehr.
Das reine ACK siehst du so nicht.

Danke. Ok.

[wintermute]

Du weisst schon wie ich das gemeint habe !

Ja, weiss ich

CG ?

CommunityGate - also nachgebautes WireGate...

Eine Wago durch einen Pi ersetzen, ist ungefähr so wie einen Porsche gegen einen Dacia zu tauschen - ist auch ein Auto.

Und auch da verstehen wir uns

Wie könnte also eine Lösung aussehen ?

Nujo... da man ja eh das EDOMI auf dedizierter Hardware laufen hat, wäre es wohl am sinnvollsten dort einen eibd anzuwerfen. EDOMI könnte dann über localhost tunneln und der eibd reicht das entsprechend weiter - entweder über Multicasts oder lokal angeschlossenem seriellem oder USB-Interface... zum Beispiel.
Jedenfalls muss der eibd auf dem EDOMI Server laufen, finde ich...

gruesse :: Michael

[gaert]

@Wagoklemme: das graue ist ein Request, das grüne die Antwort, das weiße ist der normale Busverkehr.
Das reine ACK siehst du so nicht.

Genau so ist es!

Zum eibd:
Mein Anspruch war irgendwann, auf den eibd verzichten zu können, da ich keine "Fremdsoftware" nutzen wollte. Außerdem wird eibd nicht mehr weiterentwickelt, soweit ich weiß.

Es wäre grundsätzlich überhaupt kein Problem, den eibd "nativ" zu implementieren - also direkt über seine Sockets zu kommunizieren. Anfangs in der EDOMI-Urversion war dies sogar der Fall. Die Sache hat aber diverse Nachteile: Neben einer komplizierteren Installation (Compilieren ist i.d.R. angesagt) wäre es vor allem eine Menge Overhead - also z.B. Fehlerquellen in der Kommunikation zwischen eibd und EDOMI. Und: eibd läßt sich nicht so wirklich von EDOMI kontrollieren (nur über die PID abschießen und überwachen - aber halt nicht "richtig" per API ansprechen). Daher hatte ich mich für eine eigene Implementierung entschieden, die auf's wesentliche beschränkt ist (IP-Router), aber dafür (bei den meisten zumindest) stabil und performant läuft.

[DiMa]

gaert , du weisst, ich bin wirklich beeindruckt von Edomi, aber hör' doch mal auf, immer von IP-Routern zu reden, wo Edomi doch ausschliesslich tunnelt

Sonst haben wir hier demnächst die urban legend, dass Edomi nur mit KNX-IP-Routern funktioniert...

[gaert]

Ok, IP-Router bzw. IP-Schnittstellen...

"Tunnelfähige KNX/IP-Geräte"

[wintermute]

Zum eibd:
Mein Anspruch war irgendwann, auf den eibd verzichten zu können, da ich keine "Fremdsoftware" nutzen wollte. Außerdem wird eibd nicht mehr weiterentwickelt, soweit ich weiß.

Dann halt knxd

Neben einer komplizierteren Installation (Compilieren ist i.d.R. angesagt) wäre es vor allem eine Menge Overhead - also z.B. Fehlerquellen in der Kommunikation zwischen eibd und EDOMI. Und: eibd läßt sich nicht so wirklich von EDOMI kontrollieren (nur über die PID abschießen und überwachen - aber halt nicht "richtig" per API ansprechen).

Sorry, aber die Argumentation hinkt irgendwo
Einen Tunnel der "irgendwo anders" läuft kann man noch weniger kontrollieren und muss sich auch drauf verlassen, dass das irgendwie funktionieren wird. Neustarten oder "anschubsen" kann man den noch weniger.
Compilieren? Ja, schon. Aber wenn zB für das CentOS Pakete verfügbar wären, könnte man die dann nicht zB ins EDOMI Installations-Skript integrieren und einfach per EDOMI den Start/Shutdown realisieren und evtl überwachen ob er noch läuft? Eine CFG Zeile mehr in der edomi.ini die vorgibgt mit welchen Parametern er gestartet wird und das ganze täte schon deutlich mehr Möglichkeiten eröffnen... so zB direkt lokal per RS-232 oder USB angebunden - sofern man es denn möchte. Wenn nicht, dümpelt der eibd/knxd einfach unbenutzt nebenher...
Entsprechende Binärpakete könnte ich zur Verfügung stellen.

gruesse :: Michael

[WagoKlemme]

Oder den Quellcode der KNX PHPs, auch wenn ich kein PHP kann. Python konnte ich vor 2 Wochen nicht mal schreiben und mein sh.Plugin funktioniert. Dann lerne ich halt ne 7. Sprache.

[gaert]

Wo hinkt's denn?! Dein Tunnel-Argument verstehe ich ehrlich gesagt nicht...?

Ich versuch's mal deutlicher: Ich wollte die VOLLE KONTROLLE über EDOMI haben - schließlich soll dat Ding meine Hütte steuern (einschl. Alarmanlage, etc.). Und die Buskommunikation ist nunmal ein essentieller Bestandteil des Ganzen - ausgerechnet das soll ich also an eine Drittsoftware abgeben und dazu noch unkontrolliert mit jener Software kommunizieren?! Nein! Mach' ich nicht.

[wintermute]

Ich versuch's mal deutlicher: Ich wollte die VOLLE KONTROLLE über EDOMI haben - schließlich soll dat Ding meine Hütte steuern (einschl. Alarmanlage, etc.). Und die Buskommunikation ist nunmal ein essentieller Bestandteil des Ganzen - ausgerechnet das soll ich also an eine Drittsoftware abgeben und dazu noch unkontrolliert mit jener Software kommunizieren?! Nein! Mach' ich nicht.

Dann versuch ich es auch deutlicher
Es macht doch keinen Unterschied, ob Du die Kommunikation an ein IP-Interface/Router/Tunnel-Device vom Hersteller "xyz" abgibst oder an einen eibd. Oder liegt es einfach daran, dass Du "xyz" mehr vertraust als dem eibd? Beide stellen doch dieselbe Funktionalität zur Verfügung und entziehen sich beide in gleicher Art der Kontrolle von EDOMI - man geht einfach davon aus, dass es funktioniert.
Ich rede doch jetzt garnicht über EDOMI - das soll doch alles so bleiben wie es ist. Ich meinte nur, dass WENN man einen eibd verwendet, dann wäre es vllt sinnvoller, wenn der auch auf demselben Server läuft.
EDOMI soll so bleiben wie es ist...

[gaert]

Aber wie schon angedeutet steige ich jetzt hier mal aus...

EDOMI funktioniert mit (einigen) Routern/Schnittstellen - das sollte genügen. Es gibt ja genügend Erfolgsmeldungen engagierter Tester hier. Im Sinne Aller ist es m.E. besser, wenn ich mich der Weiterentwicklung von EDOMI widme - also neue Features implementiere und die GUI fertigstelle/optimiere. Und die Doku...

Ich bitte um Verständnis dafür, dass ich mit diesen lückenhaften Informationen und Fehlerbeschreibungen nicht wirklich weiter kommen kann. Die Buskommunikation funktioniert mit einem passenden Router/Schnittstelle - ggf. ist ein solchen Gerät eben zu beschaffen. Irgendwann werde ich den gesamten Quelltext offenlegen, dann kann sich natürlich jeder Qualifizierte an einer Wago-Implementierung oder RS232/USB/Firewire/Centronics/... versuchen.

[gaert]

Dann versuch ich es auch deutlicher
Es macht doch keinen Unterschied, ob Du die Kommunikation an ein IP-Interface/Router/Tunnel-Device vom Hersteller "xyz" abgibst oder an einen eibd. Oder liegt es einfach daran, dass Du "xyz" mehr vertraust als dem eibd? Beide stellen doch dieselbe Funktionalität zur Verfügung und entziehen sich beide in gleicher Art der Kontrolle von EDOMI - man geht einfach davon aus, dass es funktioniert.
Ich rede doch jetzt garnicht über EDOMI - das soll doch alles so bleiben wie es ist. Ich meinte nur, dass WENN man einen eibd verwendet, dann wäre es vllt sinnvoller, wenn der auch auf demselben Server läuft.
EDOMI soll so bleiben wie es ist...

Naja... Jetzt wird's aber etwas albern, oder? Ein Router/Schnittstelle ist nunmal erforderlich als Tor zu KNX. eibd ist ein Software(!)-Layer, der noch dazwischen hängen würde.

[wintermute]

Aber wie schon angedeutet steige ich jetzt hier mal aus...

Also so schwer zu verstehen war doch jetzt garnicht was ich meinte, oder? Ist das so eine Art Beissreflex wenn Du "eibd" hörst?
Echt schade, wirklich